AI 에이전트 평가가 하네스(Harness)를 조종한다 | Focused Labs

에이전트 평가(Agent evaluation)가 에이전트의 성능을 점수화하는 것과 혼동되고 있습니다. 그러한 점수화는 유용하지만, 그 점수화를 통해 얻는 것은 하네스(Harness)에 대한 수정 사항입니다.

만약 평가가 사후에 하네스에 영향을 미치지 못한다면, 팀에게는 그저 더 나은 언어로 작성된 대시보드만이 남게 됩니다. LangChain은 그들의 Deep Agents 기술 문서에서 더 날카로운 버전을 제시하는데, 그곳에서는 모든 평가가 에이전트 시스템의 동작을 변화시키는 벡터라고 설명합니다.

그 문장이 논거를 담고 있습니다.

평가 스위트(Eval suite)는 시스템의 일부입니다. 평가 스위트는 에이전트가 특정한 방식으로 동작하도록, 그리고 다른 방식으로는 동작하지 않도록 유도합니다. 허술한 평가는 실행 비용이 저렴합니다. 광범위한 벤치마크(Benchmark)는 리뷰에 포함하기 좋은 요소입니다. 하지만 광범위한 벤치마크는 실제 사용자가 마주치는 작업 분포(Task distribution)에서 시스템이 잘 수행하도록 밀어붙이지 못합니다.

저는 사람들이 AI 에이전트의 평가를 에이전트의 성능을 점수 매기는 방식과 유사하게 취급하는 것을 봅니다. 네, 그것도 중요합니다. 하지만 그 평가에서 얻은 점수로 무엇을 얻을 수 있습니까? 하네스(Harness)에 대한 수정입니다. 단 하나의 실패한 트레이스(Trace)가 팀에게 가치 있는 것을 제공했습니다. 하네스의 구조에 대한 통찰력 말입니다.

하네스는 교훈이 안착하는 곳입니다

에이전트 하네스(Agent harness)는 모델 주변의 요소들입니다: 도구(Tools), 도구 설명(Tool descriptions), 프롬프트(Prompts), 라우팅 규칙(Routing rules), 메모리(Memory), 검색(Retrieval), 런타임 정책(Runtime policy), 상태 형태(State shape), 그리고 모델이 실제로 무엇을 할 수 있는지 결정하는 모든 기묘한 연결 조직(Connective tissue)들입니다. 우리는 AI 에이전시(AI agency) 개발의 맥락에서 이에 대해 작성한 바 있는데, 이는 모델 교체(Model swaps)는 너무 많은 공을 받는 반면 하네스 변경(Harness changes)은 너무 적은 책임(Ownership)을 부여받기 때문입니다.

에이전트 평가는 바로 그곳에 속해야 합니다.

LangChain의 Better-Harness 글은 이 루프(loop)를 명시적으로 설명합니다: 평가(evals)는 프롬프트(prompts), 도구(tools), 도구 설명(tool descriptions), 지침(instructions), 그리고 런타임 스캐폴딩(runtime scaffolding)을 반복적으로 개선하기 위한 학습 신호(learning signal)를 생성합니다. 유용한 부분을 요약하자면 다음과 같습니다: 평가를 설계하고, 평가를 실행하고, 평가로부터 학습 신호를 얻은 다음, 그 학습 신호를 사용하여 모델 주변의 구성 요소들을 개선하는 것입니다. 즉, 평가는 하네스(harness)를 위한 학습 데이터(training data)입니다.

이러한 문제는 모호하게 작성된 지침 때문일 수도 있고, 잘못된 파라미터(parameters)로 설정된 도구 때문일 수도 있으며, 에이전트를 쓸모없는 정보의 늪 속에서 헛수고하게 만드는 검색(retrieval) 구성 요소 때문일 수도 있습니다. 혹은 정답에 도달하기까지 인내심이 필요한 모델임에도 불구하고 저렴한 모델에게 먼저 기회를 주는 라우팅 규칙(routing rule) 때문일 수도 있고, 에이전트가 무언가로부터 복구하려고 시도하는 바로 그 잘못된 순간에 에이전트의 상태(state)가 사라져 버리기 때문일 수도 있습니다.

점수(score)는 이러한 문제들을 해결해주지 않습니다. 점수는 오직 하네스를 수정할 권리를 얻을 뿐입니다.

평가 루프(eval loop)는 하네스를 변경하고 다음 릴리스(release)를 보호할 때에만 유용합니다.

프로덕션 트레이스(Production traces)는 원재료입니다

최고의 평가 케이스는 시스템이 스스로 망신을 당하는 상황에서 나옵니다.

환불 에이전트(refund agent) 사례를 보겠습니다. 고객이 환불을 요청했을 때 에이전트가 자격 요건을 확인하는 데 실패합니다. 리서치 에이전트(research agent) 예시의 경우, 에이전트가 연결된 파일 시리즈 중 첫 번째 파일은 읽지만 나머지 파일은 여는 데 실패합니다. 그러고 나서 사용자에게 해당 자료를 자신 있게, 하지만 틀리게 요약하여 전달합니다. 코딩 에이전트(coding agent)의 경우, 에이전트가 구현(implementation)은 변경했지만 테스트(tests)를 업데이트하는 데 실패합니다. 그러고 나서 패치(patch)가 에이전트의 머릿속에서 컴파일되었다는 이유로 성공했다고 보고합니다.

LangChain의 준비 상태 체크리스트(readiness checklist)에 따르면, 첫 번째 단계는 평가 인프라(eval infrastructure)를 구축하기 전에 20~50개의 실제 에이전트 트레이스(agent traces)를 수동으로 검토하는 것입니다. 팀이 50개의 실제 트레이스를 기꺼이 읽겠다는 사실은 이 과정이 신선할 정도로 지루하게 느껴지게 만들지만, 더 중요한 점은 팀이 느낌(vibes), 추측, 그리고 최근의 요란한 실패 사례에 기반하여 평가 스위트(eval suite)를 구축하는 일을 피함으로써 수개월의 시간을 절약할 수 있다는 것입니다.

능력 평가(capability evals)와 회귀 평가(regression evals) 사이에는 구분이 있습니다. 시스템이 새로운 일을 수행하는 능력은 팀이 힐 클라이밍(hill climbing)을 하고 있기 때문에 처음에는 자연스럽게 낮은 통과율을 보일 것입니다. 일단 시스템이 무언가를 할 수 있게 되면, 미래에도 계속해서 그 일을 수행할 수 있어야 합니다. 회귀 평가(Regression evals)는 시스템이 제품이 의존하고 있는 이전의 동작으로 되돌아가는 것을 포착합니다.

경로가 곧 제품인 경우의 경로 평가

에이전트 평가에 대한 또 다른 단순한 가정은 최종 답변(final answer)에 대해서만 점수를 매기는 것입니다.

여러 가지 이유로, 경로(path)가 제품 인터페이스의 일부인 작업 클래스(task classes)의 경우 최종 답변에 점수를 매기는 방식은 제대로 작동하지 않습니다. 환불 에이전트(refund agent)는 회사 정책에 대한 확인을 건너뛰었기 때문에 환불 요청을 거절합니다. 회의 중인 데이터 에이전트(data agent)는 운영 환경(production)에서 전체 테이블 스캔(full table scan)을 실행하여 차트를 생성합니다. 지원 에이전트(support agent)는 대화 중에 고객에게 내부 메모를 유출함으로써 티켓(ticket) 문제를 해결합니다.

Google의 에이전트 개발 키트(Agent Development Kit, ADK) 문서는 이를 명확하게 구분합니다. 에이전트 평가는 최종 출력 품질(final output quality)과 궤적(trajectory), 즉 에이전트가 사용한 단계, 도구, 추론의 순서(sequence of steps, tools, and reasoning)를 모두 평가해야 합니다. 그들의 ADK 코드랩(codelab)은 이를 사용자 쿼리, 궤적, 최종 응답을 보존하는 골든 데이터셋(golden datasets)을 활용한 테스트 워크플로(testing workflow)로 전환합니다.

릴리스 게이트(release gate)는 무엇을 테스트해야 하는지, 어떤 동작이 허용 가능한 경로(acceptable path)에 의존하는지, 그리고 어떤 동작이 주어진 입력에 대한 에이전트의 출력값에만 의존하는지를 알고 있어야 합니다. 그렇지 않으면 팀은 취약한 테스트(brittle tests)로 인해 좋은 변경 사항을 차단하거나, 최종 답변이 올바르게 보인다는 이유로 위험한 변경 사항을 배포하게 됩니다.

시스템(System), 트레이스(trace), 노드(node) 평가(evals)는 서로 다른 질문에 답합니다

Agentic CLEAR라는 이름은 팀이 복잡한 작업을 완료하는 에이전트의 능력을 검토하고 평가할 수 있는 다양한 수준을 식별하는 데 사용됩니다. 이 논문은 시스템, 트레이스, 노드 수준의 세분화(system, trace, and node levels of granularity) 단계에서 통찰력을 생성하는 평가 프레임워크를 설명합니다. IBM의 프로젝트 페이지는 이를 시스템 전반의 문제(system-wide issues), 노드 또는 컴포넌트 분석(node or component analysis), 트레이스 수준의 검사(trace-level inspection)에 걸쳐 트레이스를 평가하는 오픈 소스 패키지로 확장합니다.

이러한 수준들은 서로 다른 하네스(harness) 변경 사항과 매핑됩니다.

시스템 수준의 평가(system-level eval)는 워크플로가 제품이 중요하게 생각하는 결과를 생성했는지를 묻습니다. 클레임(claims) 에이전트가 케이스를 해결했습니까? 분석(analyst) 에이전트가 근거 있는(grounded) 답변을 생성했습니까? 코딩(coding) 에이전트가 의도된 검사를 통과하는 패치를 반영했습니까? 시스템 수준의 실패는 아키텍처(architecture), 즉 라우팅(routing), 소유권(ownership), 데이터 액세스(data access), 메모리(memory), 배포 경계(deployment boundary) 또는 비즈니스 프로세스 적합성(business process fit) 문제를 가리킵니다.

트레이스 레벨(Trace-level) 평가는 에이전트가 일관된 결말까지 작업을 수행하는지 평가합니다. 에이전트가 작성하기 전에 적절한 정보를 검색하는지, 패키지를 보내기 위해 올바른 도구(tool)를 사용하는지, 병렬로 완료할 수 있는 작업을 전송하는지, 그리고 끝점이 없는 작업을 끝까지 수행하는지 등을 살펴봅니다. 트레이스 레벨의 실패는 계획(planning), 도구 사용(tool use), 인터럽트 처리(interrupt handling), 재시도 정책(retry policy), 그리고 멀티 에이전트 오케스트레이션(multi-agent orchestration)의 문제를 시사합니다. 이 단계에서 멀티 에이전트 오케스트레이션은 단순한 다이어그램을 넘어 평가 표면(eval surface)이 됩니다.

노드 레벨(Node-level) 평가는 에이전트가 작업을 수행하면서 생성하는 개별 동작을 조사합니다. 검색(retrieval) 노드가 올바른 문서를 생성했는가? 요약기(summarizer)가 제약 사항을 유지하는가? 도구 호출(tool call)에 테넌트 ID(tenant ID)가 포함되었는가? 모델이 해당 작업에 올바른 함수(function)를 생성했는가? 노드 레벨의 실패는 도구 스키마(tool schema), 프롬프트 문구(prompt wording), 검색 필터(retrieval filters), 모델 선택(model choice), 가드레일 배치(guardrail placement)를 포함하여 하네스(harness)의 로컬 부분을 변경함으로써 해결할 수 있습니다.

이러한 유형의 평가에서는 단일 통과율(pass rate)만으로는 충분하지 않습니다. 단 하나의 숫자는 에이전트 개발자에게 수정 표면(repair surface)을 명확히 보여주지 못합니다.

시스템(System), 트레이스(trace), 노드(node) 평가는 서로 다른 질문에 답하므로, 하네스의 서로 다른 부분을 변경해야 합니다.

관측성(Observability)이 평가를 제공하고, 평가가 동작을 변화시킨다

트레이스(trace) 없는 에이전트 평가는 팀들이 몇 가지 예시를 두고 논쟁하고, 합성 테스트 케이스(synthetic test cases)를 작성한 뒤, 실제 생활에서 실제로 트리거되는 것을 아무도 본 적 없는 동작에 대해 질적 평가(qualitative evaluation)를 수행하는 예시 중심의 연극(example-driven theater)이 되어버립니다.

평가(evaluation) 없는 관찰성(observability)은 저장소에 불과합니다. 저는 트레이스(traces)를 좋아합니다. 스팬(spans)도 좋아합니다. 이러한 것들이 매우 훌륭하긴 하지만, 시스템이 실행되는 과정에서 발생하는 운영 데이터(operational data)는 시스템이 해당 지점에 도달하게 된 과정에 대한 영수증이기도 합니다. 바로 이것이 평가 데이터(evaluation data)가 될 수 있는 것입니다.

Honeycomb의 AI 시대 관찰성(observability) 관련 글은 에이전트 워크플로(agentic workflows)가 왜 빠르게 쿼리 가능한 고카디널리티(high cardinality)의 운영 데이터에 의존하는지를 명확히 설명합니다. 에이전트가 사례별로 프로덕션 컨텍스트(production context)를 반복적으로 쿼리하기 때문입니다. 그들의 표현을 빌리자면, 에이전트 워크플로는 [단순히 대시보드(dashboards)가 아니라 가공되지 않은 프로덕션 컨텍스트를 대상으로 반복적인 질문을 던지기 때문에, 빠르고 쿼리 가능하며 고카디널리티인 운영 데이터에 의존합니다](https://www.honeycomb.io/blog/evaluating-observability-tools-for-the-ai-era). 평가 데이터셋(evaluation dataset)을 망가뜨리는 가장 쉬운 방법은 프로덕션 트레이스(production traces)에서 테넌트 ID(tenant ID), 도구 인자(tool arguments), 검색 소스(retrieval sources), 정책 결정(policy decisions), 모델 버전(model versions), 프롬프트 버전(prompt versions), 그리고 릴리스 버전(release versions)을 포함하지 않도록 만드는 것입니다.

평가 데이터셋(eval dataset)은 관찰성(observability)의 하류(downstream)이자 하네스(harness)의 상류(upstream)에 위치해야 합니다.

따라서, 에이전트 모니터링은 인프라 워크로드입니다. 모니터링, 로그 수집(log collection), 메트릭 수집(metrics collection), 그리고 트레이싱(tracing)은 워크로드(workloads)로 취급되어 서비스로서 실행되어야 합니다. 그렇지 않으면 그것들은 벤더 콘솔(vendor console)에 찍힌 스크린샷에 불과합니다. 트레이스는 에이전트가 실패했다는 것을 증명하지만, 그 후 저장소 속에서 사장되어 버립니다.

릴리스 게이트(release gate)는 지루하지만 강력한 한 수입니다

좋은 릴리스 형태란 수정된 하네스(harness)를 포함하고, 모든 변경 사항이 디프(diff)에서 확인 가능하며, 해당 변경 사항을 식별해낸 관련 평가(evaluations)가 함께 포함된 풀 리퀘스트(pull request)입니다. 디프에는 트레이스(trace) 481번이 실패했으며, 해당 실패한 트레이스와 그 평가를 사용하여 도구 설명(tool description)을 수정했다는 내용이 명시되어 있습니다. 혹은 노드 평가(node eval)를 통해 발견된 테넌트 누출(tenant leakage)을 방지하기 위해 검색 필터(retrieval filter)를 변경했다는 내용이 있을 수도 있습니다. 또는 홀드아웃 세트(holdout set)가 저가형 모델의 실패를 발견했기 때문에 라우트(route)가 이제 더 강력한 모델을 사용한다는 내용일 수도 있습니다. 릴리스는 결제 승인(payment-approval) 케이스에서 경로 위반(path violation)을 발견한 회귀 테스트 스위트(regression test suite)에 의해 차단됩니다.

이것은 올바른 의미에서 지루한 것입니다.

LangChain의 준비 상태 체크리스트(readiness checklist)는 코드 또는 프롬프트 변경이 오프라인 평가(offline evals), 프리뷰 배포(preview deployments), 온라인 평가(online evals)를 트리거하며, 품질 게이트(quality gates)를 통과한 후에만 승격(promotion)되는 CI/CD 흐름을 설명합니다. Better-Harness는 이어서 최적화 사례가 어떻게 개선을 가이드할 수 있는지, 반면 홀드아웃 평가(holdout evals)와 인간의 검토(human review)가 어떻게 하네스를 가시적인 케이스에 과적합(overfitting)되는 것으로부터 보호하는지를 다룹니다.

그러한 소유자(owner)가 없다면, AI 에이전트 평가는 숫자의 더미가 됩니다. 그러한 소유자가 있다면, 평가는 조종 핸들이 됩니다.

첫 번째 유용한 평가 스택은 작습니다

실용적인 스택이 반드시 화려하게 시작할 필요는 없습니다.