AI agent evaluation은 version이 있는 task를 명시적인 기대치에 따라 실행하고, agent가 올바른 도구를 선택했는지, constraint를 지켰는지, task를 완료했는지, 금지된 effect를 피했는지 기록합니다. 유용한 suite는 deterministic assertion, repeated trial, 필요한 경우 model judge, 의견이 갈리는 사례의 human review를 결합합니다.
첫 사례는 production과 무관한 trivia question 목록이 아니라 실제 failure와 high-impact workflow에서 가져와야 합니다.
OpenAI의 agent 구축 실용 가이드는 evaluation baseline을 세우고 agent가 복잡해질수록 evaluation을 사용할 것을 권장합니다. 아래 scoring design은 이 조언을 구체화합니다.
scorer를 선택하기 전에 behavior를 정의하세요
각 case에는 다음이 필요합니다.
- sanitize한 input과 initial state
- 표시되는 tool, document, permission
- 기대하거나 허용되는 tool choice
- 필수 fact 또는 task outcome
- 금지된 action 및 data exposure
- scoring method와 threshold
- model, prompt, tool, policy, fixture version
order-status agent의 경우 deterministic scorer는 get_order를 호출하고, update_order를 호출하지 않으며, 인증된 order ID를 전달하고, 기준 status를 반환했는지 assertion할 수 있습니다. model judge가 명확성을 평가할 수는 있지만 trace가 정확히 답할 수 있는 금지된 write 발생 여부까지 판단하게 해서는 안 됩니다.
주장에 맞는 scorer를 사용하세요
Deterministic assertion
tool name, argument schema, policy decision, structured field, database change, latency ceiling, prohibited call에는 code를 사용하세요. 이 check는 반복 가능하고 debug하기 쉽습니다.
Reference 또는 rubric scoring
유효한 answer가 여러 개라면 범위가 제한된 rubric을 사용하세요. 필수 fact, 허용할 수 없는 claim, tone constraint, agent가 사용할 수 있는 evidence를 명시합니다. “quality from 1 to 10”처럼 모호한 score 하나는 피하세요.
Model judge
code로 표현하기 어려운 semantic property에는 judge를 사용하고 human label을 기준으로 보정하세요. judge가 treatment name을 보지 못하게 하고 structured explanation을 요구하며 disagreement를 추적합니다. judge model은 drift할 수 있고 테스트 대상 system과 같은 bias를 공유할 수 있으므로 security나 financial effect를 판단하는 유일한 gate로 사용해서는 안 됩니다.
Human review
새 category, judge disagreement, high-impact failure는 사람에게 전달하세요. adjudication을 기록하고 안정된 decision을 더 명확한 assertion이나 rubric으로 바꿉니다.
nondeterministic case를 반복하세요
한 번 통과한 run으로 reliability를 추정할 수는 없습니다. model choice, stochastic retrieval, variable tool이 포함된 case는 반복하세요. percentage 하나만 보고하지 말고 trial 수, success 수, uncertainty를 함께 보고합니다.
release comparison을 위해 frozen core set를 유지하세요. 새 behavior에는 별도의 discovery set를 추가해 prompt mix 변경이 trend처럼 보이지 않게 하세요. production prompt monitoring에도 중요합니다. 테스트하는 question이 달라지면 system 자체의 변화보다 apparent visibility나 success rate가 더 크게 바뀔 수 있습니다.
stage를 따로 평가하세요
전체 task score는 failure가 어디에서 시작됐는지 가릴 수 있습니다. 다음 항목을 각각 평가하세요.
- retrieval 또는 context selection
- tool selection
- argument 및 authorization
- execution 및 recovery
- final answer 및 citation
- 관찰할 수 있는 경우 business outcome
wrong-tool failure라면 execution을 고정하고 selection부터 테스트하세요. duplicate write라면 isolated backend를 사용하고 operation을 중단하세요. 잘못된 도구 debugging 가이드와 production checklist는 구체적인 case를 제공합니다.
offline evaluation과 online evaluation을 구분하세요
offline suite는 release 전에 fixture, mock, isolated resource를 대상으로 실행합니다. 비교와 안전한 failure injection을 지원합니다. online evaluation은 deploy 후 실제 trace를 sampling해 traffic shift와 offline set가 놓친 case를 탐지합니다.
online judge가 consequential action을 자동으로 실행하게 하지 마세요. production data를 redaction하고 문서화된 policy에 따라 sampling하며 의심되는 regression은 review 또는 controlled rollback process로 전달하세요.
올바른 slice를 기준으로 변경을 차단하세요
model, prompt, tool, schema, retrieval, policy, retry behavior, provider version이 바뀌면 suite를 실행하세요. 같은 case와 repeated trial에서 candidate를 현재 baseline과 비교합니다.
release gate는 prohibited action 0건, deterministic regression 없음, 평가된 quality나 cost의 변화가 정해진 범위 안일 것을 요구할 수 있습니다. stable average가 workflow 하나의 심각한 regression을 숨길 수 있으므로 task family별로 결과를 나누세요.
production evidence로 suite를 키우세요
observability에서 failure가 발견되면 sanitize한 trace, initial state, expected behavior를 보존하세요. bug를 고치기 전에 case를 추가합니다. 그러면 이후 model이나 prompt 변경이 같은 문제를 다시 만들지 못합니다.
observability 가이드는 이 fixture를 재구성하는 데 필요한 trace field를 설명합니다.
첫 평가는 작고 어렵게 만드세요
모호한 prompt 수백 개보다 대표적인 case 10개로 시작하세요. normal path, missing context, unauthorized request, tool collision, provider timeout, unknown write outcome, hostile retrieved content, 어떤 도구도 호출하면 안 되는 request를 포함합니다.
아래 프롬프트는 repository를 수정하지 않고 기존 failure 하나를 완전한 case로 바꿉니다. assertion이 믿을 만해지면 구현은 반복 작업이 되고 팀에는 구체적인 regression gate가 생깁니다.