Agent Evaluation Loop
Agent evaluation은 점수 하나를 뽑아내는 기능이 아니라, scenario 실행 → trace 수집 → rubric 평가 → regression 탐지 → 설계 수정으로 이어지는 feedback loop다. Agent Tool Use가 action trace를 만들고 Agent Safety Boundary가 금지 결과를 막는다면, evaluation은 그 허용 범위 안에서 품질과 변화 추세를 검증하는 역할을 맡는다.
Loop의 구조
flowchart LR
S[고정 scenario] --> R[Agent run]
R --> T[Response and tool trace]
T --> J[Judge rubric]
J --> D[Score and feedback]
D --> C[Version comparison]
C --> I[Prompt tool policy 개선]
I --> R- Scenario는 입력, 기대 tool, 금지 행동, 최소 근거, 성공 조건을 함께 가진다.
- Rubric은 Factuality, Tool Use, Actionability, Hallucination Risk를 분리한다.
- 결과는 scenario, model, prompt version과 함께 저장해 단일 평균이 아니라 regression을 찾는다.
LangSmith의 dataset 기반 evaluation
- Evaluation은 application, dataset, evaluator를 연결해 반복 실행하는 workflow다. agent trace를 남기면 failure가 model response, tool call, prompt, evaluator 중 어디에 있는지 분리해 볼 수 있다.
- 큰 dataset evaluation은
max_concurrency를 설정해 dataset을 여러 thread로 나눠 병렬 실행할 수 있다.[1] 다만 throughput을 높이는 것이 rate limit·tool side effect·judge 비용까지 함께 해결해주지는 않으며, evaluator의 신뢰도를 보장하지도 않는다. - Python과 JS/TS evaluation API는 async 실행 표면이 다를 수 있다. 이 페이지는 특정 SDK method signature보다 dataset 기반 regression loop를 stable model로 유지한다.
4개 차원 Judge와 파싱 실패 처리
- 모니터링 에이전트 사례는 별도 judge LLM이 응답을 채점해, 미리 정의한 4개 차원 — Factuality, Tool Use, Actionability, Hallucination Risk — 을 각 1~10점으로 평가하고 판단 근거와 함께 저장한다.[2]
- Judge 평가 실패는 agent 분석 결과에 영향을 주지 않도록 예외를 별도로 처리하고, 점수 parsing 실패는 해당 차원을 기본값 5점으로 처리한다.[2:1][3]
- 이 구현은 Gemini endpoint에서 logprobs를 얻지 못해 PPL(perplexity)을 적용하지 못했다.[2:2] Gemini API는 응답 토큰의 logprob를 제공하지 않고, OpenAI API만 옵션으로 제공한다.[3:1]
PPL 제약은 모든 LLM 평가의 일반 법칙이 아니다. 이 사례의 API 제약이며, PPL 자체도 factual grounding, tool 선택, actionability를 직접 평가하지 않는다.
왜 이것이 logging이 아니라 loop인가
- LLM-as-a-Judge는 정답 oracle이 아니라 scalable reviewer다. rubric wording, judge model, response order에 영향을 받으므로 version과 prompt를 기록해야 한다.
- 평균 점수는 치명적 scenario 실패를 숨길 수 있다. safety scenario는 hard gate로, 일반 품질은 trend metric으로 구분한다.
- evaluation 결과가 prompt, tool schema, retrieval, stopping rule, safety policy 중 수정할 layer로 연결되지 않으면, 이 loop는 loop가 아니라 단순 logging에 머문다.
이 세 가지는 두 source의 구체적 구현 사례로부터 이 페이지가 도출한 일반화이며, 특정 API나 프로젝트에 묶인 주장은 아니다.
흔히 겪는 실패
| 실패 | 원인 | 대응 |
|---|---|---|
| Self-serving judge | 같은 계열 model 선호 | 다른 model을 judge로 사용, rule check와 human sample review |
| Rubric drift | judge 변경 | rubric과 model version 저장 |
| Parse default 은폐 | 실패를 중간 점수로 대체 | parse failure rate 노출 |
| Scenario overfit | 고정 case만 최적화 | hidden scenario 병행 |
| Trace 부재 | 최종 문장만 저장 | call, observation, retry 수집 |
이 표의 "Self-serving judge"와 "Parse default 은폐" 행의 출발점은 모니터링 에이전트 사례가 한계로 언급한 두 가지다. 사례 문서는 같은 Gemini가 Judge를 맡으면 관대하게 채점할 수 있으므로 다른 model을 Judge로 쓰는 편이 더 객관적이라고 적었고,[2:3] 형식이 어긋나 parsing이 실패하면 해당 차원을 5점으로 처리한다고 적었다.[2:4][3:2] 5점 처리를 "은폐"로 규정한 것, rule check와 human sample review, parse failure rate 노출이라는 대응, 그리고 나머지 행 전체는 이 페이지가 일반화한 해석이다.
테스트 질문
- 왜 이 사례의 PPL 제약을 일반화하면 안 되는가?
- judge 실패와 agent 실패를 왜 분리해야 하는가?
관련
출처
langsmith-evaluation.md — "It is also important to configure the
max_concurrency/maxConcurrencyarg when running large jobs. This parallelizes evaluation by effectively splitting the dataset across threads." ↩︎06-에이전트-성능-평가.md — "별도의 LLM이 미리 정의된 루브릭(rubric)으로 응답을 채점한다.", 4개 차원 표(Factuality/Tool Use/Actionability/Hallucination Risk), "파싱 실패 시 해당 차원은 기본값 5점으로 처리한다. Judge 평가 실패가 에이전트 분석 결과에 영향을 주지 않도록 예외를 별도로 처리한다.", "Gemini API는 logprob를 제공하지 않는다.", "PPL을 측정하려면 각 토큰의 log probability가 필요하다.", "Judge LLM도 Gemini를 사용한다. 동일 모델이 자신의 응답을 평가하는 구조여서 관대하게 채점할 수 있다(self-serving bias). 이상적으로는 다른 모델(예: GPT-4)을 Judge로 사용하는 것이 더 객관적이다." (L142) ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
04-llm-출력-품질-측정.md — "Gemini API는 응답 토큰의 logprob를 제공하지 않는다. OpenAI API는 옵션으로 제공하지만, Gemini는 API 설계상 이 값이 없다.", "judgeEvaluator.evaluate(alert, result); // 실패해도 result 반환엔 영향 없음", "Judge 평가 실패가 운영에 영향을 주는 건 과도한 결합이라고 판단했다.", "형식이 조금이라도 달라지면 정규식 파싱이 실패하고, 그 경우 5점(중간값)으로 처리한다." (L77) ↩︎ ↩︎ ↩︎