How to Test AI Agents When No Benchmark Exists — Nathanael Weill, Air Canada

한 줄 핵심

공개 벤치마크와 도메인 전문가가 부족한 상황에서도, 정답을 먼저 만들고 코드로 채점 가능한 테스트 세트를 설계하면 AI 에이전트를 빠르게 개선할 수 있다는 평가 방법론을 제시한다.

시간별 요약

1. 0:00
   소개 평가 없이 에이전트를 배포해 온 경험을 돌아보며, 실제 업무 환경에서 검증 가능한 평가 체계를 만드는 이야기를 다룬다. Air Canada에서 특정 비즈니스 문제에 맞는 AI를 만들며 겪은 시행착오가 핵심 배경이다.
2. 0:47
   벤치마크도, 전문가도 없다 특정 업무용 에이전트는 공개 벤치마크가 없는 경우가 많고, 내부 도메인 전문가도 바빠서 충분히 접근하기 어렵다. 이 조합 때문에 평가 기준을 만들기 자체가 가장 큰 난제다.
3. 1:41
   통신 RAG 프로젝트에서 얻은 교훈 통신 엔지니어용 Q&A RAG 프로젝트에서도 문서가 방대하고 전문가 접근이 제한되어 정답을 사람이 직접 채점하기 어려웠다. 복잡한 파이프라인은 자주 다른 부분을 망가뜨렸고, 결국 제대로 된 테스트 세트가 있었는지가 성패를 갈랐다.
4. 4:43
   주간 전문가 검토는 너무 느렸다 전문가 검토를 일주일에 한 번씩 모아서 진행하는 방식은 서로 다른 판단이 나와도 정리하기 어렵고 너무 느렸다. 하루하루 실험하면서 개선하려면 이렇게 느린 피드백 루프는 병목이 된다.
5. 5:38
   발상을 뒤집어 답을 먼저 쓴다 문제를 질문→답변이 아니라, 먼저 정답이 있는 페이지를 만들고 그로부터 질문을 생성한 뒤 에이전트가 찾은 답을 비교하는 방식으로 바꾼다. 이렇게 하면 사람의 주관 대신 코드로 자동 채점할 수 있다.
6. 6:33
   주 1회 테스트에서 하루 수십 회로 정답 생성-검증 구조로 바꾸자 평가 빈도가 일주일 1회에서 하루 수십 회로 늘어났다. 불필요한 복잡성을 줄이고 핵심 요소인 embedding model, chunking, BM25 조정에 집중하면서 정확도도 함께 개선됐다.
7. 7:30
   공급업체 계약 검토 Air Canada의 새로운 과제는 공급업체 계약서를 검토해 조항 위반이나 수정 필요 사항을 찾아내는 에이전트를 만드는 일이었다. 법률 비용이 크고 실수의 대가도 커서, 빠르게 실험하고 검증할 수 있는 평가 체계가 다시 필요해졌다.
8. 10:08
   계약 에이전트의 동작 방식 계약 에이전트는 조항을 찾고, 수정 근거 문서를 찾고, 수정안을 작성한 뒤, 마지막에 유지 여부를 분류하는 4단계로 구성된다. 이 중 일부는 RAG처럼 문서 검색 문제로 풀 수 있지만, 나머지 단계는 별도의 평가 설계가 필요하다.
9. 10:39
   테스트 세트를 만드는 다섯 가지 방법 기존 계약과 변경본을 비교하는 방식, 규칙을 심어 넣는 방식, 조항을 삭제하는 방식, 영향 없어야 할 변경을 가하는 방식, 템플릿의 빈칸을 활용하는 방식의 다섯 가지 테스트 생성 전략을 소개한다. 핵심은 실제 업무에서 정답을 알고 있는 입력을 많이 만들어 평가 가능하게 만드는 것이다.
10. 12:31
    규칙 위반 심기 예를 들어 100만 달러 상한 같은 규칙을 정하고, 그 규칙을 어기는 조항을 의도적으로 넣어 에이전트가 이를 찾아내는지 확인한다. 규칙과 문서가 확보될수록 자동으로 생성 가능한 테스트가 늘어난다.
11. 13:39
    조항 삭제하기 승인된 계약에서 조항 하나를 지워 놓고 에이전트가 누락을 감지하는지 검사한다. 다양한 템플릿과 내용 차이를 고려해야 해서 어렵지만, 실제로는 누락 탐지 능력을 가장 강하게 검증하는 방식이다.
12. 14:42
    영향이 없어야 할 변경 공급업체 이름이나 주소처럼 결과에 영향을 주면 안 되는 요소를 바꾸거나 조항 순서를 뒤섞어도 결과가 같아야 한다. 이런 불변성 검사는 코드만으로 확인할 수 있어 LLM 심판이 필요 없다.
13. 15:38
    빈칸이 있는 템플릿 전문가가 이미 쓰는 계약 템플릿의 빈칸을 여러 값으로 채워 다양한 계약을 자동 생성한다. 어떤 조합은 위반을 만들고 어떤 조합은 만들지 않기 때문에, 정답이 명확한 대량 테스트를 빠르게 만들 수 있다.
14. 16:39
    코드로 확인할 수 있으면 LLM 심판은 피한다 정확한 일치 여부나 규칙 위반처럼 코드로 판정 가능한 문제는 최대한 코드로 검사해야 한다. LLM-as-a-judge는 유연하지만 잡음이 많고, 판정 설계 자체가 원 문제만큼 어려워질 수 있다.
15. 18:07
    전문가 피드백으로 더 나은 테스트를 만든다 전문가 피드백은 에이전트를 바로 고치는 데 쓰기보다, 더 좋은 테스트와 프롬프트, 더 나은 실패 케이스를 만드는 데 활용해야 한다. 정답을 먼저 만들고 검증 루프를 짧게 돌릴수록 에이전트 품질이 꾸준히 올라간다.

실무 인사이트

• 도메인 정답이 불명확할수록 모델 개선보다 먼저 평가 가능한 입력과 정답을 설계하는 일이 우선이다.
• 사람 채점 대신 코드 채점으로 바꿀 수 있는 문제를 최대한 찾아내면 실험 속도가 급격히 빨라진다.
• 전문가 피드백은 모델 수정보다 테스트 세트 확장에 재투자할 때 장기적으로 더 큰 품질 향상을 만든다.