최종 답변만 확인하는 방식으로는 에이전트를 평가할 수 없습니다. 다단계(multi-step) 에이전트는 잘못된 경로를 거치거나, 잘못된 도구(tool)를 호출하거나, 운 좋게 복구하거나, 단 두 단계면 충분할 일을 여덟 단계나 거쳐서 결국 정답에 도달할 수 있으며, 최종 답변 체크는 이를 통과시켜 버립니다. 그러면 동일한 잘못된 경로가 다음 입력에서는 실패하게 되고, 당신은 그 이유를 알 수 없게 됩니다. 에이전트 평가는 목적지뿐만 아니라 궤적(trajectory)을 채점해야 합니다.

우리는 AI 에이전트를 구축하고 출시하며, 평가 하네스(eval harness)는 모델 업그레이드 시 살아남는 에이전트와 제공업체가 새 버전을 출시하는 날 조용히 성능이 퇴보(regress)하는 에이전트를 구분하는 핵심 요소입니다.

정답뿐만 아니라 경로를 채점하세요

유용한 에이전트 평가는 단 하나의 숫자가 아니라 여러 차원으로 전체 궤적을 다룹니다:

• 도구 정확성 (Tool correctness): 올바른 도구를 호출했는가? 예상되는 도구 이름과 대조하는 결정론적(deterministic) 체크입니다.
• 인자 정확성 (Argument correctness): 파라미터(parameters)가 올바른가? 필수 필드를 지정할 수 있는 경우 마찬가지로 결정론적입니다.
• 단계 효율성 (Step efficiency): 합리적인 단계 수를 소요했는가, 아니면 방황했는가?
• 계획 준수 및 계획 품질 (Plan adherence and plan quality): 합리적인 계획을 따랐는가, 그리고 애초에 그 계획이 좋았는가?
• 작업 완료 및 추론 품질 (Task completion and reasoning quality): 실제로 작업을 완료했는가, 그리고 추론이 타당했는가?

중요한 구분점은 다음과 같습니다: 명확한 정답이 있는 모든 것(도구 이름, 필수 파라미터, 예상 출력)에는 **결정론적 체크 (deterministic checks)**를 사용하고, 주관적인 부분에는 LLM-as-judge를 남겨두세요. 문자열 비교(string comparison)로 확인할 수 있는 것을 확인하기 위해 판사 모델(judge model)에 비용을 지불하지 마세요.

멀티 에이전트 성능 퇴보는 서브 에이전트 속에 숨어 있습니다

서브 에이전트(sub-agents)를 가진 오케스트레이터(orchestrator)를 운영 중이라면, 최상위 점수는 당신에게 거짓말을 할 것입니다. 시스템이 복구되었거나 잘못된 출력이 평균화되어 사라졌기 때문에, 서브 에이전트의 성능이 조용히 저하되는 동안에도 오케스트레이터는 괜찮아 보일 수 있습니다. 당신에게는 **스팬 수준 평가 (span-level evaluation)**가 필요합니다. 각 서브 에이전트의 스팬(span)을 개별적으로 채점해야 합니다. 멀티 에이전트 시스템에서 발생하는 대부분의 운영 환경 성능 퇴보는 정확히 아무도 평가하지 않았던 서브 에이전트 내에서 발생합니다.

LLM-as-judge는 유용하지만 은밀한 편향을 가지고 있습니다

LLM-as-judge(판단자로서의 LLM)는 주관적인 기준을 평가하는 데 적합한 도구이지만, 적극적으로 대응해야 하는 여러 편향(biases)이 가득합니다:

• 위치 편향 (Position bias). 판단자는 어떤 답변이 먼저 나왔는지에 따라 선호도를 보이며, 때로는 매우 심하게 나타납니다. 순서를 바꾸면 판결이 뒤집힐 수도 있습니다. 해결책: 두 가지 순서를 모두 평가하여 평균을 내거나, 위치를 무작위화(randomize)하십시오.
• 자기 선호 (Self-preference). 판단자는 자신이 속한 모델 제품군(model family)의 출력물을 선호하는 경향이 있습니다. 해결책: 평가하려는 모델과 최대한 다른 모델을 판단자로 사용하거나, 모델 제품군 간의 합의(cross-family consensus)를 요구하십시오.
• 장황함 편향 (Verbosity bias). 내용의 실질적인 측면과 관계없이 답변이 길수록 더 높은 점수를 받습니다. 해결책: 길이를 통제하거나, 판단자에게 길이를 무시하도록 지시한 뒤 실제로 무시하는지 점검(spot-check)하십시오.

편향을 제어하고 인간의 라벨(human labels)을 통해 검증하여 적절히 보정(calibrate)한다면, LLM-as-judge는 인간들이 서로 동의하는 수준만큼 인간의 선호도와 강력한 일치도를 보입니다. 판단자는 보정 작업을 마친 후에야 신뢰할 수 있습니다. 별도의 설정 없이 바로 사용(out of the box)해서는 신뢰할 수 없습니다.

인간을 기준으로 보정하고, 그 후에 자동화를 신뢰하십시오

팀들이 건너뛰는 단계는 바로 보정(calibration)입니다. 루브릭(rubric, 평가 기준)을 신뢰하기 전에, 일련의 예시들에 대해 수동 라벨링(hand-label)을 수행하고 판단자가 인간과 일치하는지 확인하십시오. 만약 일치하지 않는다면 루브릭이 모호하거나 판단자가 편향된 것이며, 어느 쪽이든 당신의 '초록색 대시보드'는 허구입니다. 인간이 채점자(grader)를 보정하고, 채점자는 인간의 능력을 확장(scale)합니다. 또한 평가 세트 오염(eval-set contamination)을 주의하십시오. 만약 벤치마크 예시가 학습 데이터에 유출되었다면, 당신은 능력이 아니라 암기력을 측정하고 있는 것입니다. 직접 생성한 별도의 홀드아웃 세트(held-out set)를 유지하십시오.

오프라인 평가(Offline evals)는 드리프트(drift)를 놓치므로, 온라인 평가도 병행하십시오

배포 전에 실행하는 테스트 스위트(test suite)는 이미 알려진 실패 사례를 잡아냅니다. 하지만 실제 트래픽이 에이전트를 망가뜨리는 새로운 방식은 잡아내지 못합니다. 드리프트 탐지(drift detection) 및 알림(alerting) 기능을 갖추고, 프로덕션 트래픽의 샘플을 대상으로 스트리밍 평가(streaming evals)를 실행하십시오. 오프라인 평가(Offline evals)가 회귀 방지망(regression net)이라면, 온라인 평가(online evals)는 테스트 코드를 작성할 생각조차 못 했던 실패 사례를 찾아내는 방법입니다. 이는 우리가 AI가 작성한 코드에 대해 주장했던 것과 동일한 투자의 런타임(runtime) 버전입니다: AI가 4배 더 많은 코드를 작성합니다, 여기 그 4배의 버그를 막아줄 QA 레이어가 있습니다.

핵심 요약 (Key takeaways)

• 궤적(trajectory)을 평가하십시오: 도구 정확성(tool correctness), 인자 정확성(argument correctness), 단계 효율성(step efficiency), 계획 품질(plan quality), 완료 여부(completion) 등을 평가해야 합니다. 단순히 최종 정답만 봐서는 안 됩니다.
• 명확한 요소(도구 이름, 파라미터 등)에는 결정론적 체크(Deterministic checks)를 사용하고, 주관적인 요소에는 LLM-as-judge를 사용하십시오.
• 서브 에이전트(sub-agents)를 스팬(span) 수준에서 평가하십시오. 최상위 점수(Top-level scores)는 서브 에이전트의 회귀(regression)를 숨길 수 있습니다.
• LLM 심판(LLM judges)은 위치 편향(position bias), 자기 선호 편향(self-preference bias), 장황함 편향(verbosity bias)을 가집니다. 이를 상쇄한 뒤에 신뢰하십시오.
• 인간의 라벨(human labels)을 기준으로 심판을 교정(calibrate)하고, 홀드아웃 세트(held-out set)를 유지하며, 드리프트(drift)를 포착하기 위해 온라인 평가를 실행하십시오.

자주 묻는 질문 (FAQ)

최종 정답 정확도(final-answer accuracy)만으로는 왜 충분하지 않나요?
에이전트가 다음번에는 실패할 수 있는 잘못된 경로를 통해 정답에 도달할 수 있기 때문입니다. 궤적 평가(Trajectory evals)는 잘못된 경로가 비용을 발생시키기 전에 이를 잡아냅니다.

LLM-as-judge를 신뢰할 수 있나요?
교정(calibration)을 거친 후라면, 주관적인 기준에 대해서는 신뢰할 수 있습니다. 위치 및 장황함 편향을 제어하고, 다른 모델 제품군(model family)을 사용하며, 인간의 라벨과 대조하여 검증하십시오.

훌륭한 오프라인 스위트(offline suite)가 있다면 온라인 평가도 필요한가요?
네. 오프라인은 알려진 회귀(regressions)를 잡아내고, 온라인은 드리프트(drift)와 테스트가 전혀 예상하지 못한 새로운 실제 환경의 실패 사례를 잡아냅니다.

에이전트를 위한 평가 하네스(eval harness)를 구축하고 심판 교정(judge calibration) 문제로 씨름하고 있다면, 이는 저희가 즐겁게 해결할 수 있는 문제입니다. Shanti Infosoft에서 에이전트를 구축하는 분들과 루브릭(rubrics) 및 하네스 설계를 기꺼이 공유하겠습니다.