변경이 에이전트를 더 낫게 만들었는지 더 나쁘게 만들었는지에 숫자를 매길 수 없다면, 우리는 그것을 엔지니어링하는 것이 아니라 절차만 좀 더 붙인 추측을 하고 있는 것이다. 에이전트 프로젝트가 멈추는 가장 흔한 이유는 약한 모델이 아니라 평가 하네스의 부재다. 이것이 없으면 모든 프롬프트 수정, 도구 변경, 모델 교체는 누군가 몇 개의 출력을 눈으로 훑어보고 "더 나아 보인다"고 선언하는 방식으로 평가되며, 이는 회귀를 출시해 놓고 사용자에게서 그 사실을 알게 되는 방식이다. 점수판은 에이전트보다 먼저 존재해야 한다. 왜냐하면 점수를 매길 수 없는 것은 개선할 수도 없기 때문이다.

재구성은 이렇다. 평가 세트는 확률적 코드를 위한 테스트 스위트다. 테스트가 하나도 없는 서비스를 리팩터링하면서 "괜찮아 보인다"는 힘만으로 출시하지는 않을 것이다. 에이전트는 그 서비스보다 추론하기 쉬운 게 아니라 더 어렵다. 그러니 점수판이 덜 필요한 게 아니라 더 필요하다.

에이전트보다 먼저 하네스를 만들어라

평가 하네스는 화려하지 않고 처음에는 작다. 대표성 있는 입력 세트, 각각에 대한 좋은 출력의 정의, 그리고 현재 시스템을 그 전부에 대해 돌려 점수를 얻는 방법이다. 실제 또는 예상 트래픽에서 뽑은 20개에서 50개의 실제 예시가 천 개의 합성 예시보다 낫다. 요점은 고정된 자로 재는 것이다. 그래야 "에이전트를 개선했다"가 느낌이 아니라 확인할 수 있는 주장이 된다.

일단 이것이 존재하면 워크플로가 뒤바뀐다. 새 프롬프트든, 새 도구든, 새 모델이든 모든 변경은 먼저 하네스에 대해 돌아간다. 점수를 올리는 변경은 출시되고, 점수를 낮추는 변경은 아무리 그럴듯해 보여도 출시되지 않는다. Bedrock에서는 Model Evaluation이 자동화된 메트릭과 사람 검토가 포함된 관리형 경로를 제공하며, 이 기능은 여기서 필요해지기 훨씬 전에 정식 출시되었다. 도구 자체보다 중요한 것은 규율이다. 먼저 점수를 매기고, 그다음 결정하라.

LLM 심사자, 그리고 그것이 우리를 속이는 지점

열린 결말의 출력을 손으로 채점하는 것은 확장되지 않으므로, 표준적인 방법은 모델을 심사자로 쓰는 것이다. 강력한 모델에게 입력, 에이전트의 출력, 루브릭을 주고 채점하게 한다. Bedrock Model Evaluation은 정확히 이것을 지원한다. 이것은 진짜로 유용하며, 동시에 틀릴 수 있는 부품이기도 한데, 팀들은 그것이 깔끔한 숫자를 내놓기 시작하는 순간 이 사실을 잊어버린다.

심사자는 예측 가능한 실패 양상을 갖고 있고, 우리는 그것을 감안해 설계해야 한다.

  • 순서 편향과 장황함 편향. 심사자는 정확성과 무관하게 먼저 제시된 선택지와 더 길고 자신감 있어 보이는 답을 선호하는 경향이 있다. 순서를 무작위로 섞고 길이를 통제하라.
  • 자기 선호. 같은 모델 계열의 심사자는 같은 계열의 출력을 더 높게 평가할 수 있다. 중요한 곳에서는 테스트 대상 모델과 다른 계열의 심사자를 써라.
  • 루브릭 표류. 모호한 루브릭("이 답이 좋은가")은 모호하고 불안정한 점수를 낳는다. 구체적인 루브릭("답이 정책 조항을 인용하는가, 인용된 조항이 맞는가")은 우리가 행동으로 옮길 수 있는 점수를 낳는다.
  • 틀린 전제에 자신 있게 동의함. 입력에 거짓 전제가 포함되어 있으면 심사자는 그것에 맞장구치는 출력에 보상을 줄 수 있다. 올바른 행동이 거부하거나 정정하는 것인 적대적 사례를 포함하라.

심사자는 절대 진리가 아니다. 작은 사람 레이블 세트에 맞춰 보정하는, 빠르고 저렴한 절대 진리의 근사치일 뿐이다. 그 세트에서 심사자와 사람이 의견이 갈리면, 나머지에 대해 심사자를 신뢰하기 전에 루브릭부터 고쳐라.

답만이 아니라 궤적을 채점하라

에이전트에 한해서는 최종 답이 우리가 신경 쓰는 것의 절반일 뿐이다. 에이전트는 잘못된 경로로도 올바른 답을 낼 수 있다. 호출하지 말았어야 할 도구를 호출하거나, 두 단계짜리 작업에 열 단계를 쓰거나, 그 과정에서 로그에 데이터를 흘리거나 하면서 말이다. 출력뿐 아니라 궤적도 평가하라. 기대한 도구를 사용했는가? 허용된 행동 범위 안에 머물렀는가? 합리적인 단계 수 안에 끝났는가? 절대 건드리면 안 되는 삭제 API를 호출하면서 올바른 답을 얻은 에이전트는, 최종 텍스트가 무엇을 말하든 평가에 실패한 것이다.

결론

순서는 협상 불가다. 평가 하네스가 먼저, 에이전트는 그다음이다. 하네스는 실제 입력의 작고 고정된 세트와 정의된 좋은 출력, 반복 가능한 점수를 갖추고 있으며, 모든 변경을 감으로 하는 확인에서 측정된 결정으로 바꿔 놓는다. 채점을 확장하기 위해 LLM 심사자를 쓰되, 이것을 틀릴 수 있는 부품으로 다뤄라. 그 편향을 통제하고, 구체적인 루브릭을 주고, 사람 레이블에 맞춰 보정하라. 결과만이 아니라 경로를 채점하라. 점수를 매길 수 없는 것은 출시할 수도 없으며, 신뢰할 수 있는 에이전트를 출시하는 팀은 선수를 만들기 전에 점수판부터 만든 팀이다.

이어서 읽으면 좋은 글

평가를 배포 파이프라인에 배선하는 플랫폼 측면은 ercan.cloud의 클라우드 현장 노트에서 다루고, 허브는 ercanermis.com에 있다.