에이전트 평가 4/4 — 단계마다 검증과 재시도를 붙이면 무엇이 바뀌나
Pass@k와 Pass^k 글에서 단계가 늘수록 끝까지 성공할 확률이 곱셈으로 깎인다고 했다. 각 단계 90%짜리 6단계면 0.9⁶ ≈ 53%. 그리고 그 글 끝에서, 여러 번 생성하는 것보다 검증하고 막는 구조가 중요하다고 했다.
그런데 "검증하고 막는다"를 실제로 붙이면 숫자가 어떻게 바뀔까? 막기만 하면 일이 멈추고, 다시 시키면 비용이 든다. 이번 편은 이 둘을 같이 계산해 본다.
세 가지 결과
에이전트 업무 한 건은 이제 세 갈래로 끝난다.
- 끝까지 정답: 모든 단계가 맞은 채로 끝까지 갔다
- 조용한 오류: 어딘가 틀렸는데 검증기가 못 잡아서 그대로 고객에게 갔다
- 사람에게 넘김: 검증기가 막았고, 재시도해도 계속 막혀서 사람에게 넘겼다
이 중 가장 나쁜 건 조용한 오류다. 사람에게 넘긴 건 느리고 비쌀 뿐, 적어도 누군가 본다.
직접 해 보자
위쪽 버튼 세 개를 순서대로 눌러 보는 걸 권한다.
재시도가 앞 시도와 독립이고 성공률도 같다고 본 이론값이다. 실제로는 같은 실수를 반복하기도 하고, 오류 메시지를 주면 성공률이 오르기도 한다.
검증 없음에서는 53%가 정답이고 나머지 47%가 전부 조용한 오류다. 검증이 없으니 틀려도 아무도 모른다.
**검증만 (재시도 없음)**을 누르면 재밌는 일이 생긴다. 조용한 오류는 5.8%로 확 줄었는데, 끝까지 정답이 39%로 오히려 떨어진다. 대신 55%가 사람에게 간다. 검증기가 맞는 출력도 5%는 괜히 막기 때문에, 6단계를 지나는 동안 정상 건도 꽤 걸린다. 조용한 오류를 사람 업무로 바꿨을 뿐이다.
검증 + 재시도 2번을 누르면 그제야 원하는 그림이 나온다. 정답 86%, 사람에게 넘김 1.2%. 생성 호출은 업무당 평균 6.81회로, 검증 없을 때(6회)보다 13% 정도 늘어난다. 여기에 검증 호출이 같은 횟수만큼 붙는다.
| 설정 (6단계, 단계 성공률 90%) | 끝까지 정답 | 조용한 오류 | 사람에게 | 생성 호출 |
|---|---|---|---|---|
| 검증 없음 | 53.1% | 46.9% | 0% | 6회 |
| 검증만 (재현율 80%, 오탐 5%) | 39.1% | 5.8% | 55.1% | 4.41회 |
| 검증 + 재시도 2번 | 86.0% | 12.8% | 1.2% | 6.81회 |
재시도를 늘려도 안 줄어드는 것
여기서 재시도를 5번까지 올려 보자. 정답은 86.0%에서 87.0%로 겨우 1%p 오른다. 조용한 오류는 12.8%에서 거의 그대로다.
이유를 생각해 보면 당연하다. 재시도는 검증기가 잡은 오류에만 일어난다. 검증기가 못 본 오류는 재시도할 기회 자체가 없다. 조용한 오류의 바닥은 재시도 횟수가 아니라 검증기 재현율이 정한다. 재현율을 80%에서 95%로 올려 보면 조용한 오류가 12.8%에서 3.4%로 떨어진다.
오히려 "검증만"일 때보다 "검증 + 재시도"일 때 조용한 오류가 더 높다는 것도 눈여겨볼 만하다. 사람에게 넘어가서 멈췄을 업무가 재시도로 살아나서 다음 단계로 가고, 그 다음 단계들에서 다시 오류가 샐 기회를 얻기 때문이다. 얼핏 버그처럼 보이는데, 식을 따라가 보면 맞는 숫자다.
투자 순서
재시도 횟수는 2번 정도면 대부분 효과를 본다. 그 다음부터는 검증기 재현율을 올리는 게 조용한 오류를 줄이는 유일한 길이다. 3편에서 본 것처럼, 그건 문턱값이 아니라 검증기 설계의 문제다.
오탐이 비싼 이유
오탐을 20%로 올려 보자(재현율 80%, 재시도 2번 상태에서). 정답이 86%에서 76%로 떨어지고, 사람에게 넘김이 1.2%에서 10%로 오르고, 생성 호출도 7.6회로 늘어난다.
오탐은 맞는 출력을 버리고 다시 시키는 것이다. 단계 하나에서는 사소해 보여도, 6단계 모두에서 일어나고 재시도 한도를 갉아먹는다. 3편에서 F1 대신 비용으로 문턱값을 정하자고 했는데, 단계별 검증기에서는 "사람 검토 비용" 자리에 "재시도 비용과 넘김 증가"가 들어간다고 보면 된다.
위젯이 말하지 않는 것
이 위젯은 Pass^k 글과 같은 가정을 쓴다. 단계마다 성공률이 같고, 재시도는 이전 시도와 독립이다. 실제로는 둘 다 자주 깨진다.
- 재시도는 독립이 아니다. 같은 입력, 같은 프롬프트면 같은 실수를 반복하는 경우가 많다. 검증기가 왜 막았는지 피드백을 주면 반대로 성공률이 크게 오르기도 한다. 어느 쪽인지는 직접 재 봐야 한다
- 오류는 단계 사이에서 번진다. 2단계의 약관 검색이 틀리면 3단계의 판단은 성공률 90%가 아니라 거의 0%다. 위젯은 이걸 "조용한 오류"로 한 번에 셀 뿐, 연쇄 효과를 모델링하지 않는다
- 검증기도 실행마다 흔들린다. LLM 검증기라면 같은 출력에 다른 판정을 내릴 수 있다
그래서 이 숫자들은 설계 단계에서 "재시도와 검증 중 어디에 먼저 투자할까"를 정하는 용도로 쓰고, 실제 값은 운영 트레이스에서 단계별로 재야 한다. 단계별 성공률, 검증기가 막은 비율, 재시도 후 성공 비율. 이 세 개만 로그에 남겨도 위젯의 슬라이더를 실측값으로 채울 수 있다.
4편을 마치며
정리하면 이렇다. 평가셋이 작으면 작은 차이를 못 본다(1편). 채점을 맡긴 판정자도 측정해야 하고, 일치율 하나로는 부족하다(2편). 운영 검증기의 문턱값은 비용 비율로 정한다(3편). 검증과 재시도는 같이 붙여야 하고, 조용한 오류의 바닥은 검증기 재현율이 정한다(4편).
아직 다루지 못한 것도 많다. 최종 결과만이 아니라 궤적(어떤 도구를 어떤 순서로 불렀는지)을 채점하는 법, 사용자가 중간에 끼어드는 대화형 에이전트의 평가, 비용과 지연까지 넣은 다목적 비교. 특히 궤적 평가는 "결과는 맞았는데 과정이 위험했다"를 잡는 유일한 방법이라 따로 정리해 보고 싶다. 아직은 나도 정답을 모르겠다.
참고자료
- τ-bench (Yao et al., 2024) — 같은 작업을 여러 번 돌려 일관성을 재는 pass^k
- Demystifying evals for AI agents (Anthropic) — 결과뿐 아니라 궤적을 채점하는 얘기도 있다
- Your AI Product Needs Evals (Hamel Husain) — 트레이스를 보고 평가를 키워 가는 과정