벤치마크가 없을 때 AI 에이전트를 테스트하는 법 — 나다니엘 웨일, 에어캐나다

하이라이트

• 공개 벤치마크가 없는 비즈니스 특화 AI 에이전트를 개발할 때, 테스트 세트를 구축하지 않으면 피드백 주기가 일주일에 한 번으로 제한된다.

• 정답이 되는 페이지나 계약서 데이터에서 역으로 질문과 테스트 케이스를 생성하여 자동 채점 체계를 구축하면 하루에 수십 번 테스트를 실행할 수 있다.

• 에어캐나다의 공급업체 계약 분석 프로젝트에서는 원본 계약서 비교, 규칙 기반 데이터 생성, 의도적인 조항 누락, 변수 무작위화, 템플릿 배열 활용 등 5가지 기법으로 테스트 세트를 확보했다.

• LLM을 심판(Judge)으로 사용하는 방식은 자체 노이즈가 너무 커서 에이전트 성능 측정에 방해가 되므로 최대한 코드 기반 검증을 활용해야 한다.

• 에이전트 평가 체계는 단순한 출시 여부(go/no-go) 결정 수단이 아니라, 개발 주기를 단속하고 프롬프트를 개선하기 위한 핵심 도구이다.

타임라인

1. 00:00 - 05:32

   공개 벤치마크와 도메인 전문가 부재라는 한계

   에어캐나다와 이전 통신사 프로젝트 모두에서 엔지니어들은 도메인 전문가의 부족과 벤치마크 부재라는 동일한 문제를 겪었다. 논문에서 효과가 입증된 복잡한 기법들을 무분별하게 추가하면 오히려 시스템 안정성이 떨어졌다. 전문가 회의에 의존하는 주간 평가 체계는 예산과 속도 측면에서 한계가 명확했다.

   • 특정 비즈니스 과제를 수행하는 AI 에이전트를 만들 때 의존할 수 있는 공개 벤치마크가 전혀 존재하지 않는다.
   • 도메인 전문가는 본업으로 인해 접근성이 제한되어 있어 데이터 과학자와 AI 엔지니어가 직접 답변을 평가하기 어렵다.
   • 복잡한 파이프라인에 새로운 기술을 계속 추가하더라도 기존에 잘 작동하던 기능이 망가지는 부작용이 발생한다.
   • 일주일에 한 번 전문가들과 화면을 보며 수동으로 챗봇을 평가하는 방식은 개발 속도를 극도로 저하시킨다.
2. 05:32 - 07:50

   문제를 뒤집어 테스트 세트를 구축하는 역발상

   문제를 뒤집어 페이지나 문서에서 질문을 먼저 생성하고 에이전트의 검색 결과와 비교하는 방식을 도입했다. 주관적인 평가를 코드로 자동 채점할 수 있게 되면서 피드백 루프가 획기적으로 빨라졌다. 불필요한 복잡성을 제거하고 기본 요소를 다듬는 것이 정확도 향상으로 이어졌다.

   • LLM에게 문서 내용에 대한 질문을 먼저 작성하게 만든 뒤, 에이전트가 이를 찾아내도록 유도하여 평가를 자동화한다.
   • 주관적인 전문가 평점에 의존하던 평가 주기가 하루에 수십 번으로 늘어나며 정확도가 빠르게 상승한다.
   • 복잡성을 줄이고 올바른 임베딩, 청킹, BM25 알파 값을 찾는 것이 RAG 성능 향상의 핵심이다.
3. 07:50 - 16:16

   계약서 분석 에이전트를 위한 5가지 테스트 기법

   공급업체 계약서 분석 자동화 프로젝트에서 벤치마크 부재를 극복하기 위해 다섯 가지 구체적인 테스트 생성 기법을 시도했다. 계약서 버전을 모두 보관하지 않는 한계 속에서, 규칙을 바탕으로 테스트 데이터를 직접 만들거나 정상 계약서를 일부러 훼손하여 에이전트의 탐지 능력을 검증했다. 공급업체 주소 변경이나 순서 무작위화 같은 비영향 요소 조작으로 출력 일관성도 함께 점검했다.

   • 과거 계약서 비교, 규칙 기반 생성, 의도적 계약서 파손, 메타데이터 무작위화, 템플릿 배열 활용 등 5가지 기법을 적용했다.
   • 규칙을 위반하지 않는 조항과 위반하는 조항을 조합하여 정답이 보장된 275개의 테스트 케이스를 생성했다.
   • 서명된 계약서에서 임의로 조항을 이동시키거나 제거하여 에이전트가 누락을 감지하는지 테스트하는 방식이 가장 강력하다.
4. 16:16 - 19:46

   LLM 심판의 한계와 평가 기반 개발의 본질

   LLM을 채점관으로 쓰려는 시도는 과도한 노이즈를 유발해 실효성이 낮으므로 코드 기반 검증을 우선해야 한다. 수집된 피드백은 에이전트를 즉시 수정하는 데 쓰지 않고, 더 나은 테스트 케이스와 프롬프트를 만드는 데 활용해야 한다. 평가 체계는 제품 출시 여부를 가르는 최종 관문이 아니라 지속적인 개선을 위한 출발점이다.

   • LLM을 심판으로 사용하는 방식은 시스템 자체의 노이즈보다 심판의 노이즈가 더 커서 활용하기 매우 어렵다.
   • 에이전트가 엔드포인트를 호출하는 궤적이나 Text-to-SQL 등 다양한 작업에서도 입력 생성 후 검증 패턴을 적용할 수 있다.
   • 테스트 생성은 단순한 배포 승인 여부 결정을 넘어 개발자를 지원하고 프롬프트를 개선하는 핵심 도구이다.