작동하는 에이전트가 있습니다. 이제 누군가 당신이 어떻게 그것을 확신하는지 묻는다면, 솔직한 대답은 약 30번 정도 시도해 보았고 괜찮아 보였다는 것입니다.

그 대답은 프로토타입(prototype) 단계에서는 괜찮습니다. 하지만 그 결과물이 그것을 직접 만들지 않은 사람들 앞에 놓이는 순간, 더 이상 괜찮은 대답이 아니게 됩니다.

AI 에이전트를 위한 평가 하네스(evaluation harness)는 바로 그 "괜찮아 보였다"라는 말을 대체하는 것입니다. 이것은 설치하는 프레임워크(framework)가 아닙니다. 네 가지 결정 사항이며, 당신은 이번 주 안에 이 네 가지를 모두 결정할 수 있습니다.

첫 번째 결정: 케이스(cases)가 어디에서 오는가

당신의 상상력에서 나오는 것이 아닙니다. 이것이 조용히 대부분의 시도를 망치는 요인입니다.

당신이 테스트 케이스(test cases)를 발명할 때, 당신은 프롬프트(prompt)를 작성할 때 사용했던 것과 동일한 멘탈 모델(mental model)을 바탕으로 그것들을 만들어냅니다. 당신은 문제를 생각하는 방식 그대로 명확하고, 잘 형성되었으며, 한 번에 하나의 요청만 담긴 입력을 생성합니다. 하지만 실제 사용자들은 한 메시지에 세 가지 질문을 보내고, 주문 번호를 빠뜨리며, 이름을 말하지 않고 사물을 설명하고, 중간에 언어를 바꿔버립니다.

그러니 지난 200개의 실제 상호작용을 가져와서 읽어보세요. 당신을 불편하게 만들었던 20개를 뽑아내세요. 실패한 20개가 아니라, 확신이 서지 않았던 20개를 고르세요. 그것들이 당신의 첫 번째 케이스들이며, 이 세트는 매주 동일한 소스로부터 영원히 확장됩니다.

아직 프로덕션 트래픽(production traffic)이 없다면, 대체재는 다른 사람의 메시지입니다. 고객 지원 티켓(support tickets), 영업 이메일, 포럼 질문 등입니다. 작성할 당시에 당신의 에이전트를 전혀 고려하지 않았던 사람이 작성한 것이라면 무엇이든 좋습니다.

두 번째 결정: 루브릭(rubric)이 견뎌내야 하는 것

에이전트가 생성한 결과물을 보기 전에, 좋은 답변에 무엇이 포함되어야 하는지를 먼저 적으세요. 이 순서는 스타일의 선호 문제가 아닙니다. 결과물을 먼저 읽으면, 결과물이 우연히 통과할 수밖에 없는 루브릭(rubric)을 작성하게 될 것입니다.

그런 다음 유일하게 중요한 테스트를 실행하세요. 동일한 결과물과 동일한 루브릭을 두 번째 사람에게 주고 점수를 매겨달라고 요청하세요. 만약 한 명은 4점을 주고 다른 한 명은 2점을 준다면, 루브릭은 완성되지 않은 것입니다. 서로 대화해 본 적 없는 두 사람이 동일한 결론에 도달할 때까지 루브릭을 계속해서 다듬으세요.

대부분의 팀은 이 단계를 건너뛰고 곧바로 점수 산정(scoring) 자동화로 넘어갑니다. 두 사람이 의견이 일치하지 않는 루브릭(rubric)을 자동화할 수도 있습니다. 그러면 매일 밤 숫자를 받게 되겠지만, 그 숫자는 아무런 의미도 없을 것이며, 당신이 그 사실을 깨닫기까지는 한 분기(quarter)가 걸릴 것입니다.

세 번째 결정: 누가 판단하는가

세 가지 유형이 있으며, 기술은 어떤 질문이 어디에 속하는지 아는 것입니다.

코드(Code)는 확인 가능한 모든 것을 판단합니다. 환불 API를 호출했는가? 합계가 정확한가? JSON이 유효한가? 단계별 예산(step budget) 내에 머물렀는가? 이것은 저렴하고, 정확하며, 지루하지만, 당신이 예상하는 것보다 더 많은 데이터 세트를 커버해야 합니다.

사람(Humans)은 판단이 필요한 모든 것을 판단합니다. 이미 화가 난 고객에게 적절한 어조였는가? 에스컬레이션(escalation)이 적절했는가? 이것은 확장(scale)할 수 없으며, 확장해서도 안 됩니다. 이것은 나머지 두 방식이 측정되는 기준이 되는 정답(ground truth)입니다.

모델(A model)은 당신이 이미 수동으로 점수를 매긴 사례들에 대해 사람과 일치한 후에만 판단합니다. 먼저 사람이 점수를 매긴 50개의 예시에 대해 모델을 실행해 보세요. 만약 일치한다면, 모델을 승격시키세요. 만약 일치하지 않는다면, 당신은 AI 판정관을 가진 것이 아니라 기록(track record)이 없는 제2의 의견을 가진 것뿐입니다. openai/evals와 같은 도구들은 이를 위한 배관(plumbing)을 제공하지만, 일치성(agreement)을 제공하지는 않습니다. 그리고 중요한 것은 바로 그 일치성입니다.

네 번째 결정: 합격 기준을 어디에 둘 것인가

합격 기준(passing bar)은 그럴싸해 보이는 숫자가 아니라, 실패가 실제로 당신에게 초래하는 비용을 바탕으로 선택하세요.

95%는 표준이 아니라 습관입니다. 실패 모드(failure mode)가 약간 어색한 문장이라면 80%도 관대한 편입니다. 만약 실패 모드가 환불해서는 안 될 돈을 환불하는 것이라면, 95%는 태만한 것이며 점수와 상관없이 경로에 사람이 개입해야 합니다.

합격 기준 옆에 비용을 적어두세요. 나중에 기준을 옮겨야 한다고 주장하는 사람은 비용에 대해 논쟁해야 하며, 이는 훨씬 더 나은 논쟁 방식입니다.

솔직한 한계

하네스 (Harness)가 당신의 에이전트가 훌륭하다고 말해주지는 않습니다. 그것은 당신의 에이전트가 변했을 때를 알려주며, 당신이 중요하게 여기기로 결정한 요소들에 대해 두 버전 중 어느 것이 더 나은지를 알려줍니다. 하네스가 볼 수 없는 모든 것은 당신이 세트에 포함하지 않은 사례입니다.

그것은 여전히 당신이 이전에 가졌던 것보다 훨씬 더 방대한 양이며, 이는 제품을 출시하는 것(shipping)과 그저 바라는 것(hoping) 사이의 차이입니다. 이것이 속한 더 넓은 분야는 하네스 엔지니어링 (harness engineering)이라 불리며, 이것은 그 분야의 첫 번째 작동하는 결과물입니다.

20개의 사례. 두 사람이 합의한 하나의 루브릭 (rubric). 가능한 곳에서는 코드 체크를, 불가능한 곳에서는 인간을 활용합니다. 비용이 옆에 적힌 하나의 기준선. 그것은 단 한 번의 오후 작업이며, 그 오후가 그 이후의 모든 주를 측정 가능하게 만듭니다.