지난 글에서는 답 하나를 몇 점으로 칠지 정하는 기준표를 다뤘다. 그 기준표는 입력 하나에 출력 하나가 나오는 모델을 전제로 한다. 에이전트는 그렇지 않다. 질문 하나를 받고 도구를 부르고, 그 결과를 읽고, 또 부르고, 어느 시점에 스스로 멈춘다. 채점할 대상이 답 하나가 아니라 궤적이다.
궤적은 에이전트가 한 번 실행되는 동안 남긴 걸음의 기록을 말한다. 걸음마다 세 가지가 붙는다 — 모델이 무엇을 하기로 했는지, 어떤 도구를 어떤 인자로 불렀는지, 그래서 무엇이 돌아왔는지. 이 셋이 순서대로 쌓인 목록이 궤적이다.
최종 정답률이 감추는 것
가장 먼저 재게 되는 것은 최종 정답률이다. 필요한 수치이고 계속 재야 하지만, 이것만으로는 에이전트를 운영할 수 없다.
두 실행 모두 정답을 냈다. 최종 답만 채점하는 평가에서 둘은 구별되지 않는다. 그런데 B는 토큰을 2.8배 썼고, 도중에 부르지 않아도 될 도구를 불렀고, 그 도구가 오류를 냈기 때문에 다시 방향을 잡을 수 있었다. 오류가 안 났다면 계산기 결과를 그대로 믿고 틀린 답을 냈을 수도 있다. B는 운이 좋아서 맞은 것이고, 정답률은 운과 실력을 구별하지 못한다.
반대 방향으로도 감춘다. 최종 답이 틀린 실행 100건이 있을 때 정답률은 「0%」 하나를 알려 줄 뿐, 그 100건이 한 가지 이유로 틀렸는지 열 가지 이유로 틀렸는지 말해 주지 않는다. 한 가지 이유라면 그 자리 하나를 고치면 되고, 열 가지 이유라면 접근을 바꿔야 한다. 이 둘은 완전히 다른 작업인데 같은 숫자로 보인다.
무엇을 재는가
궤적에서 뽑을 수 있는 지표는 계층이 있다. 위쪽은 「잘 되고 있나」를 답하고 아래쪽은 「어디를 고칠까」를 답한다.
| 층 | 지표 | 무엇을 말해 주나 |
|---|---|---|
| 결과 | 과제 성공률 | 사용자가 원한 것을 얻었는가 |
| 결과 | 걸음 수 · 토큰 · 지연 | 얼마를 치르고 얻었는가 |
| 과정 | 도구 선택 정확도 | 그 자리에서 부를 도구를 골랐는가 |
| 과정 | 인자 정확도 | 도구를 맞게 채워 불렀는가 |
| 과정 | 불필요 걸음 비율 | 결과에 기여하지 않은 걸음이 몇이었나 |
| 과정 | 복구율 | 도구가 실패했을 때 다시 일어섰는가 |
| 안전 | 위험 호출 발생률 | 하지 말라고 한 도구·인자를 불렀는가 |
과정 지표는 결과 지표보다 먼저 움직인다. 프롬프트를 바꾸거나 도구 설명을 고쳤을 때 성공률은 표본이 모여야 흔들리지만, 도구 선택 정확도는 같은 표본에서 곧바로 갈린다. 회귀를 빨리 알아채고 싶은 자리에 과정 지표를 둔다.
안전 축은 다른 셋과 성격이 다르다. 루브릭 때와 같은 이유로, 점수로 세지 말고 통과·실패로 센다. 삭제 API를 한 번 부른 실행은 나머지가 아무리 좋아도 실패다.
실패에 이름을 붙인다
「실패 30%」는 고칠 자리를 알려 주지 않는다. 실패를 나눠야 하는데, 나누는 축은 임의로 정할 것이 아니라 에이전트가 한 걸음을 밟는 순서에서 나온다.
이 다섯이 고치는 방법을 각각 다르게 요구한다는 것이 이 분류의 쓸모다.
- 계획 오류는 시스템 프롬프트와 과제 설명의 문제다. 도구를 아무리 고쳐도 줄지 않는다
- 도구 오선택은 도구 이름과 설명이 서로 겹칠 때 는다. 도구 목록을 줄이거나 설명에 「언제 쓰지 않는가」를 적으면 줄어든다
- 인자 오류는 스키마 문제다. 필드 설명, 예시 값, 열거형 제약으로 대부분 잡힌다
- 결과 오독은 도구가 빈 결과나 부분 실패를 애매하게 돌려줄 때 는다. 도구 쪽 응답 모양을 고치는 편이 빠르다
- 멈춤 실패는 종료 조건이 명시되지 않았을 때 생긴다. 최대 걸음 수와 「이 조건이면 끝」을 못 박는다
분류는 사람이 손으로 해도 되고 모델에게 시켜도 되는데, 어느 쪽이든 분류기 자체를 한 번 검증해야 한다. 사람이 나눈 실패 50건과 모델이 나눈 것을 맞춰 보고, 어긋나는 자리가 어느 갈래인지 확인한다. 대개 「계획 오류」와 「도구 오선택」의 경계에서 갈린다.
궤적을 대조하는 세 가지 방법
궤적을 채점하려면 무엇과 비교할지 정해야 한다. 방법이 셋이고, 셋 다 쓰게 된다.
정답 궤적과 대조한다. 사람이 이상적인 걸음을 적어 두고 실제 궤적과 맞춰 본다. 문제는 정답 궤적이 하나가 아니라는 것이다. 검색을 두 번 나눠 해도 되고 한 번에 해도 되는데 글자 그대로 대조하면 후자가 틀린 것이 된다. 그래서 순서를 무시하고 집합으로 비교하거나, 도구 이름만 보고 인자는 따로 보는 식으로 느슨하게 맞춘다.
규칙으로 검사한다. 「삭제 도구를 확인 없이 부르지 않는다」, 「같은 인자로 같은 도구를 세 번 이상 부르지 않는다」, 「검색 결과가 비었으면 그 위에 답을 쌓지 않는다」 같은 조건을 코드로 적어 궤적에 돌린다. 정답 궤적이 필요 없고 결과가 흔들리지 않는다는 것이 장점이다. 안전 축은 거의 전부 이 방식으로 잰다.
모델에게 궤적을 읽히고 채점시킨다. 정답 궤적을 만들 수 없는 열린 과제에 쓴다. 이때 궤적을 통째로 던지고 「잘했나」를 물으면 답이 흔들리므로, 걸음마다 「이 걸음이 목표에 가까워지게 했는가」를 묻고 그 결과를 모으는 편이 안정적이다. 그리고 지난 글의 규칙이 그대로 적용된다 — 근거를 먼저 쓰게 하고, 출력 모양을 고정하고, 채점기도 채점한다.
로그가 없으면 아무것도 못 잰다
여기까지의 지표는 전부 궤적이 남아 있다는 것을 전제로 한다. 그런데 에이전트를 만들면서 로그를 나중에 붙이는 경우가 많고, 그러면 이미 지나간 실패를 다시 재현해야 한다.
걸음마다 최소한 이만큼을 남긴다.
{
"run_id": "r-8814",
"step": 3,
"tool": "search_docs",
"arguments": {"query": "환불 기한", "top_k": 5},
"status": "ok",
"result_size": 5,
"latency_ms": 412,
"tokens": {"in": 2180, "out": 96},
"parent_step": 2
}status와 result_size가 특히 중요하다. 이 둘이 없으면 「도구가 성공했지만 빈 결과였다」는 자리를 나중에 찾을 수 없는데, 결과 오독은 정확히 그 자리에서 생긴다. parent_step은 여러 도구를 동시에 부르는 에이전트에서 걸음을 나무 모양으로 되살릴 때 쓴다.
실행 단위 식별자를 하나 정해 전부에 붙인다. 이것이 없으면 지표를 실행별로 묶을 수 없어서, 「걸음 수 평균」 같은 값이 실행 경계를 넘나들며 계산된다.
회귀로 굳힌다
궤적 평가는 한 번 재고 끝나는 것이 아니라 프롬프트나 도구를 고칠 때마다 다시 돌리는 자리다. 실패를 갈래로 나눠 두었으면 그것을 그대로 회귀 세트로 쓸 수 있다.
- 갈래마다 실패했던 실행을 몇 건씩 골라 고정 세트로 만든다. 고친 다음 이 세트가 통과하는지 본다
- 통과한 실행도 넣는다. 도구 설명을 고쳐 인자 오류를 잡았더니 도구 선택이 나빠지는 일이 흔하다
- 지표는 갈래별로 나란히 본다. 전체 성공률 하나로 합치면 한 갈래가 좋아지고 다른 갈래가 나빠진 것이 상쇄되어 안 보인다
돌리는 비용이 문제가 되는데, 과정 지표는 실행을 끝까지 안 돌려도 잴 수 있는 것이 많다. 첫 세 걸음까지만 돌려 도구 선택과 인자를 보는 짧은 세트를 따로 두면 고칠 때마다 부담 없이 돌릴 수 있다.
정리
에이전트 평가에서 최종 정답률은 필요하지만 충분하지 않다. 같은 정답이라도 세 걸음에 도착한 것과 다섯 걸음을 헤매다 도착한 것은 다른 시스템이고, 다음번에도 도착할 확률이 다르다.
그러니 재는 순서는 이렇다. 걸음을 남기고, 걸음에서 과정 지표를 뽑고, 실패에 고칠 수 있는 이름을 붙인다. 「실패 30%」가 「인자 오류 18%, 멈춤 실패 9%, 나머지 3%」로 바뀌는 순간 다음에 무엇을 할지가 정해진다.
읽어주셔서 감사합니다. 😊