모든 에이전트 팀의 생애 주기에는 로드맵에 아무도 기록하지 않는 특정한 순간이 있습니다. 당신은 평가(eval) 스위트를 구축합니다. 그것은 실제 버그를 잡아냅니다. 당신은 이를 CI(지속적 통합)에 연결하여 릴리스 게이트(release gate)로 사용합니다. 대시보드는 초록색으로 변합니다. 그리고 그 후 3개월 동안 어딘가에서, 모두가 여전히 의미가 있는 것처럼 취급함에도 불구하고 그 초록색은 더 이상 아무런 의미도 갖지 못하게 됩니다.

이것이 바로 굿하트의 법칙(Goodhart's Law)이며, 당신이 계획하든 그렇지 않든 당신의 에이전트 평가(agent evals)를 향해 다가오고 있습니다.

"측정치가 목표가 되는 순간, 그것은 더 이상 좋은 측정치가 아니게 된다."

당신의 평가(eval) 스위트가 무엇을 출시할지 결정하는 수단이 되는 날, 그것은 품질에 대한 중립적인 측정을 멈추고 팀이 최적화해야 할 목표가 되어버립니다. 이것은 가설적인 위험이 아닙니다. 이것은 기본 궤도이며, 대부분의 팀은 "완벽하게 통과한" 릴리스가 프로덕션에 배포되어 조용히 모든 상황을 악화시킨 후에야 이를 알아차립니다.

좋은 평가(eval) 스위트가 부패하는 방식

부패는 지루하게 진행되며, 바로 그 점 때문에 위험합니다. 일반적인 순서는 다음과 같습니다:

1. 이미 발견한 버그를 대상으로 평가(eval)를 작성합니다. 합리적입니다. 하지만 이제 당신의 스위트는 내일의 실패 모드가 아닌, 어제의 실패 모드를 측정하게 됩니다.
2. 변경 사항이 한 가지 케이스에서 실패합니다. "퇴보(regress)했는가?"라고 묻는 대신, 누군가는 "평가가 너무 엄격한가?"라고 묻고, 결과가 초록색이 될 때까지 어설션(assertion)을 수정합니다.
3. 프롬프트(Prompts)가 평가(eval) 세트에 맞춰 튜닝됩니다. 퓨샷(Few-shot) 예시들이 당신의 판정기(judge)가 보상하는 정확한 문구 쪽으로 편향됩니다. 에이전트는 실제 업무를 더 잘하게 되는 것이 아니라, _당신의 테스트 케이스_를 더 잘 수행하게 됩니다.
4. 홀드아웃 세트(held-out set)가 조용히 훈련 세트(training set)가 됩니다. 당신이 디버깅을 위해 사용하는 모든 케이스는 이제 당신이 과적합(overfit)된 케이스가 됩니다.

그 종착지는 사용자에게 측정 가능한 수준으로 더 나빠진, 통과율 98%의 에이전트입니다. 왜냐하면 점수가 이제 에이전트가 업무를 얼마나 잘 수행하는지가 아니라, 에이전트가 테스트를 얼마나 잘 만족시키는지를 측정하고 있기 때문입니다. 지도가 영토를 대체해 버린 것입니다.

징후: 설명할 수 없는 초록색 게이트

굿하트가 도착했음을 알리는 가장 명확한 신호는 이것입니다. 즉, 어떤 릴리스가 게이트를 통과했지만, 팀원 누구도 특정 경계 케이스가 왜 통과했는지 설명할 수 없는 경우입니다. 그냥 통과했을 뿐입니다. 점수는 그 배경에 서사가 없는 숫자일 뿐입니다.

이것이 진짜 문제입니다. 합격/불합격(pass/fail) 비트는 논리적으로 추론할 수 있는 측정치가 아닙니다. 그것은 오직 신뢰하거나 불신할 수 있는 측정치입니다. 그리고 감사받지 않은 신뢰는 항상 녹색 쪽으로 쇠퇴합니다.

이것이야말로 제가 의존하는 두 도구가 별개의 대시보드가 아니라 하나의 단위로 작동해야 하는 정확한 지점입니다.

agent-eval은 출력을 점수화하고 게이트를 통과시킵니다. 이는 결정론적 검사, 모델 기반 심사 기준(model-as-judge rubrics), 드리프트 및 환각 신호 등을 실행하여 에이전트가 _무엇_을 생성했는지에 대한 판결을 반환합니다.

AgentLens는 에이전트가 어떻게 그곳에 도달했는지의 흔적(trace)을 포착합니다. 모든 모델 호출과 도구 단계, 해결된 입력값(원시 템플릿이 아닌 템플릿팅 후), 그리고 어떠한 후처리(post-processing)를 거치기 전의 원시 출력을 기록합니다.

두 가지 중 어느 하나만으로는 충분하지 않으며, 이것이 핵심입니다. 순수한 평가 점수는 조작되기를 기다리는 목표물에 불과합니다. 순수한 흔적은 판결이 첨부되지 않은 법의학 데이터일 뿐입니다. 모든 게이트 결정이

해결책은 점수(score)와 추적 기록(trace)을 함께 이동하게 만드는 것입니다. 그래야 통과한 사례가 단순히 계산 가능한 것이 아니라 감사 가능한(auditable) 것이 됩니다:

import { evaluate } from "agent-eval";
import { trace } from "agentlens";

...

이 코드 스니펫에는 Goodhart의 법칙에 저항하는 두 가지 요소가 있습니다. traceId는 어떤 통과 사례도 설명할 수 없게 만들지 않는다는 것을 의미합니다. 즉, 모든 녹색(green) 표시 뒤에는 자체적인 증거를 담은 클릭 한 번의 과정이 있다는 뜻입니다. 그리고 heldOut은 평가 세트가 학습 데이터셋으로 붕괴되는 것을 막아주는 규율입니다.

측정 지표를 정직하게 유지하기 위한 세 가지 규칙

도구만으로는 Goodhart의 법칙으로부터 당신을 구원할 수 없습니다. 그 주변의 프로세스가 기준을 지켜야 합니다:

• 절대 디버깅에 사용하지 않는 별도의 테스트 세트(held-out set)를 격리하십시오. 만약 실패 사례를 수정하기 위해 추적 기록(trace)을 열어본 적이 있다면, 그 사례는 측정용으로 소진된 것입니다. 즉, 더 이상 평가가 아니라 회귀 테스트(regression test)입니다. 오직 점수만 매기고 절대 튜닝하는 데 사용하지 않는 순환 세트를 유지하십시오. 별도로 격리되어 디버깅된 점수와 실제 점수가 차이가 날 때, 그 간극이 바로 당신의 과적합(overfit)이며, 이를 직접 측정할 수 있습니다.

• 평가 수정 사항을 프로덕션 변경 사항처럼 취급하십시오. 녹색 표시를 얻기 위해 단언(assertion)을 완화하는 것은 폭발 반경을 가진 코드 변경과 같습니다. 이는 diff와 검토자, 그리고

신뢰할 수 있는 에이전트 (agent)를 출시하는 팀은 통과율 (pass rates)이 가장 높은 팀이 아닙니다. 그들은 어떤 녹색 체크 표시를 가져오더라도, 트레이스 (trace)를 통해 왜 그것이 통과 판정을 받았는지 정확하게 설명할 수 있는 팀입니다. agent-eval은 당신에게 판결을 내려주고, AgentLens는 당신에게 영수증을 제공합니다. 이 둘을 결합된 상태로 유지하고, 실제 홀드아웃 세트 (held-out set)를 유지하십시오. 그러면 당신의 대시보드는 6개월 후에도 실제로 의미를 가질 수 있을 것입니다.

대부분은 그렇지 못할 것입니다. 이제 당신은 그 이유를 압니다.