벤치마크가 없어도 AI 에이전트를 검증하는 법

URL: https://www.youtube.com/watch?v=c_SPW__jF9w 날짜: 2026-10-22 채널: aiDotEngineer 발표자: Nathanael Weill (Air Canada) 재생 시간: 19분 50초

📌 핵심 질문 / 이 발표가 다루는 핵심 논점

==공개 벤치마크와 도메인 전문가의 시간이 모두 부족한 업무에서, 정답을 먼저 알고 입력을 거꾸로 생성하면 AI 에이전트를 어떻게 빠르고 재현 가능하게 평가할 수 있는가?== 답을 알고 있는 자료·규칙·계약 템플릿에서 테스트 입력을 합성하고, 가능한 판정은 코드로 자동화하면 주간 1회에 그치던 전문가 평가를 하루 수십 회의 테스트 루프로 바꿀 수 있다.

• 사내 특수 업무에는 가져다 쓸 공개 벤치마크가 없고, 개발팀은 도메인 전문가가 아니다.
• 전문가 검토는 시간이 오래 걸리고 평가자 간 의견도 달라 빠른 반복을 막는다.
• 정답이 알려진 테스트를 만들 수 있다면 복잡한 LLM judge보다 코드 판정을 우선할 수 있다.

1. 공개 벤치마크와 전문가 접근성이 없는 환경

1.1. 항공사 업무별 AI와 도메인 지식의 간극

1. Air Canada의 여러 사업 부문은 서로 다른 특수 업무를 가진다.
   1. 사업 영역: 운영(operations), 기업(corporate), 상업(commercial), 로열티(loyalty) 부문마다 해결해야 할 문제가 다르다.
   2. AI 팀의 역할: Nathanael Weill은 2026년 6월 Air Canada에 합류했으며, 그의 팀은 각 부문을 위한 AI 솔루션을 제공한다.
2. 개발 역량만으로는 업무 정답을 평가할 수 없다.
   1. 역할의 분리: 데이터 과학자와 AI 엔지니어는 에이전트를 만들 수 있지만 해당 업무의 도메인 전문가는 아니다.
   2. 전문가 접근 제약: 전문가는 서로 다른 사업 부문에서 본업을 수행하며 매우 바쁘다. 팀이 전문가에게 요청할 수 있는 시간도 제한적이다.
   3. 결과: 공개 벤치마크가 없다는 문제와 정답을 판단할 전문가 시간이 부족하다는 문제가 함께 평가·벤치마크 구축을 어렵게 만든다.

1.2. 통신 엔지니어용 RAG에서 확인한 동일한 문제

1. 문서가 많아도 정답 문서를 찾으면 답은 대부분 해결된다.
   1. 업무: 이전 직장에서 통신 엔지니어가 질문하면 답하는 Q&A assistant를 만들었다. 통신 분야는 범위가 넓고 문서는 약 10,000건에 이르렀으며, 공급업체 문서도 많이 추가됐다.
   2. 검색의 난점: 질문에 따라 어떤 문서를 찾아야 하는지 결정하는 로직이 필요했다. RAG의 기본 흐름은 질문을 받고 관련 문서를 검색한 뒤 그 문서를 근거로 답을 작성하는 것이다.
   3. 병목의 위치: 관련 페이지나 문서를 찾으면 답 자체는 약 90% 확률로 맞았으므로, 핵심 난제는 정답 근거 문서를 검색하는 일이었다.
2. 전문가가 부족해 개발팀은 자기 답을 채점하지 못했다.
   1. 2024년의 환경: 모두가 RAG를 만들던 시기였지만, LinkedIn의 성공 사례가 실제 업무에서 그대로 통한다는 보장은 없었다.
   2. 비교 프로젝트: 같은 문서와 같은 과제를 두고 외부 팀 2개와 내부 팀 1개가 구간별로 경쟁했다. Weill의 팀 솔루션은 실제 가치를 내고 사용자들이 사용했지만, 당시에는 왜 다른 팀보다 잘 작동했는지 알지 못했다.
   3. 평가의 공백: 팀이 답의 정확성을 스스로 채점할 수 없었고 전문가 접근도 제한됐다.

1.3. 복잡성을 늘려도 평가 없이는 개선을 알 수 없다

1. 논문에서 본 기법을 추가하는 일은 성능 개선을 보장하지 않았다.
   1. 복잡한 파이프라인: 시간이 지나며 검색·추론 단계를 더한 파이프라인이 복잡해졌다. 당시 발표와 논문에서 유망해 보이는 기법을 시험했지만, 팀의 실제 문제에서는 개선으로 이어지지 않았다.
   2. 회귀(regression): 새 단계를 더하면 이전에 동작하던 기능이 깨지는 경우가 생겼다. 해결 아이디어를 많이 추가할수록 기존 동작을 반복해서 망가뜨리는 문제가 커졌다.
   3. 핵심 교훈: 복잡성 자체가 품질은 아니다. 무엇이 나아졌는지 측정할 테스트가 없으면 복잡한 변경의 효과를 판단할 수 없다.
2. 주 1회 전문가 회의는 개발 속도를 제한했다.
   1. 회의 방식: 거대한 화면에 챗봇 5개의 답변을 놓고 같은 질문에 대한 결과를 비교한 뒤 전문가에게 선호 답변을 고르게 했다.
   2. 평가자 불일치: 전문가들은 항상 합의하지 않았다. 세 명에게 판단 이유를 물으면 세 가지 의견이 나올 수 있어, 선호도만으로 정답을 안정적으로 정의하기 어려웠다.
   3. 느린 검토: 전문가는 답을 모르거나 확인이 필요하면 직접 찾아봐야 했다. 에이전트는 몇 분 만에 바꿀 수 있어도 평가 회의는 주 1회뿐이어서 실험 예산은 사실상 주 1회였다.

2. 답을 먼저 정하고 입력을 역으로 만드는 평가

2.1. 문서에서 질문을 생성해 검색을 코드로 채점한다

1. 정답 자료를 출발점으로 삼으면 채점 기준을 고정할 수 있다.
   1. 역방향 생성: 질문부터 만들고 정답을 찾으려 하지 말고, 먼저 답이 들어 있는 문서나 페이지를 고른다.
   2. 질문 합성: LLM에 해당 문서의 내용을 묻는 질문을 만들게 한다. 이미 답을 아는 문서에서 질문을 만드는 일은 비교적 쉬운 작업이다.
   3. 에이전트 평가: 에이전트가 생성된 질문을 처리해 문서를 검색하고 답을 낸다. 검색 결과를 질문 생성에 사용한 정답 문서와 비교한다.
2. 기준 문서 비교는 사람의 선호 대신 코드로 판정할 수 있다.
   1. 자동 채점: 기대한 문서나 근거가 회수됐는지 코드로 비교하면 평가자 의견이 개입하지 않는다.
   2. 반복 가능성: 질문 생성과 검색 평가를 자동화해 같은 절차를 반복할 수 있다.
   3. 범용 원리: 이 방법은 발표자가 발명한 기법이 아니라 RAG에서 이미 쓰이던 접근이다. 핵심은 “답을 먼저 알고 입력을 만들기”라는 원리를 다른 업무로 옮기는 것이다.

2.2. 주간 실험을 하루 수십 회로 바꾼 효과

1. 자동 테스트 세트가 개발 피드백 루프를 크게 단축했다.
   1. 실험량: 전문가 검토에 의존하던 주 1회 평가에서 하루 수십 회 평가로 늘었다.
   2. 품질 추이: 테스트를 기반으로 개선을 반복하면서 전문가 채점의 정확도가 주 단위로 높아지는 것을 관찰했다. 발표에서는 정확도 상승의 구체적인 수치를 제시하지 않았다.
2. 테스트가 복잡한 설계보다 유효한 검색 요소에 집중하게 했다.
   1. 단순화: 파이프라인의 복잡한 단계 상당수가 필요하지 않다는 점을 확인해 제거했다.
   2. 집중 대상: 임베딩 모델(embedding model), 청킹(chunking), BM25의 alpha 값을 조정하는 데 집중했다.
   3. 결과와 한계: 정확도는 여러 주에 걸쳐 상승했다. 발표자는 성공 원인을 확정하지는 않았지만, 경쟁 팀에는 테스트 세트가 없었고 자기 팀에는 테스트 세트가 있었다는 차이가 중요했을 것이라고 추정했다.
3. 측정 불가능한 에이전트는 더 나아지게 만들 수 없다.
   1. 학습: Weill은 “에이전트를 채점할 수 없다면 더 좋게 만들 수 없다”고 정리했다.
   2. 지속성: 2024년에 얻은 이 원칙은 이후 Air Canada의 별도 업무에도 평가 설계를 적용하는 기준이 됐다.

3. 공급업체 계약 검토 에이전트

3.1. 계약 검토의 비용과 리스크

1. 계약 검토는 사람의 시간을 많이 쓰면서 지연 비용과 누락 리스크를 함께 만든다.
   1. 현재 업무: Air Canada는 많은 공급업체와 계약을 맺고, 전문가가 계약을 하나씩 읽어 각 조항을 검토한다.
   2. 검토 결과: 비준수 조항을 표시하고, 수정이 필요한 조항은 어떻게 다시 써야 하는지 피드백을 제공한다.
   3. 지연 비용: 공급업체가 즉시 납품해야 하는데 계약 검토가 끝나지 않으면 공급망 일정이 늦어진다.
   4. 누락 비용: 조항을 놓치면 나중에 Air Canada에 불리한 결과로 돌아올 수 있다. 전문가, 특히 법률 전문가의 시간은 비싸다.
2. 외부 벤치마크가 없어 기존 역방향 평가 원리를 새 업무에 적용해야 했다.
   1. 문제의 성격: 계약 조항 작성·검토는 문서에서 답을 찾는 RAG와 다르고, 바로 적용할 공개 벤치마크나 정답 데이터셋이 없었다.
   2. 목표: 주기가 느린 상태에 머무르지 않고 테스트를 반복해 정확도를 개선할 수 있는 개발 궤적을 만드는 것이 중요했다.
   3. 재사용: Air Canada의 다른 프로젝트에도 “정답을 먼저 만들고 에이전트가 그 답을 찾아가는지 확인한다”는 같은 개념을 사용한다.

3.2. 계약 에이전트의 네 단계

1. 조항 식별부터 수정안 채택 판단까지 순차적으로 처리한다.
   1. 조항 탐지(spot): 계약의 각 절(section)을 도메인별로 분류하고, 해당 절에 결함이나 변경 필요가 있는지 찾는다.
   2. 근거 검색: 수정안을 뒷받침할 관련 문서를 찾는다. 이 단계는 이전 RAG 프로젝트에서 만든 문서 검색 접근을 재사용할 수 있었다.
   3. 수정안 작성: 찾아낸 근거에 맞춰 조항의 수정 문안을 작성한다.
   4. 분류: 마지막에 수정안을 유지할지 여부를 분류한다.
2. RAG 검색에서 얻은 방법은 전체 에이전트 중 일부만 다뤘다.
   1. 재사용 가능 부분: 수정 근거 문서를 검색하는 단계에는 이미 시험해 본 방식이 있었다.
   2. 새로운 평가 과제: 조항 분류, 누락·결함 탐지, 수정안 작성과 채택 판단에는 별도의 평가 데이터 생성 방법이 필요했다.

4. 정답이 있는 계약 테스트를 만드는 다섯 가지 방법

4.1. 방법 1 — 과거 결정과 원본 계약의 차이를 이용한다

1. 서명본과 변경본이 모두 있으면 실제 전문가 결정을 재현하는 테스트를 만들 수 있다.
   1. 테스트 생성: 전문가에게 서명된 원본 계약을 받고, 협상 후 변경된 계약과 코드의 diff처럼 비교한다.
   2. 기대 결과: 에이전트는 변경 사항을 읽고 전문가가 내렸던 것과 동일한 flag를 내야 한다.
2. 계약 버전이 보존되지 않아 이 방법은 데이터 부족으로 막혔다.
   1. 기록의 한계: 팀은 계약의 모든 버전을 보관하지 않았고, 원본을 남기지 않은 채 마지막 버전만 갖고 있는 경우가 있었다.
   2. 협상 이력: 계약이 협상 과정에 들어가면 버전이 여러 개 생길 수 있으나, 비교에 필요한 원본·변경본 쌍을 확보할 수 없었다.
   3. 결론: 실제 계약 쌍을 활용하는 접근은 이상적이지만, 보존된 문서가 없으면 테스트를 만들 수 없다.

4.2. 방법 2 — 알려진 규칙을 계약에 심어 위반을 찾게 한다

1. 규칙을 아는 상태에서 준수·위반 사례를 생성하면 기대 flag를 정할 수 있다.
   1. 규칙 출처: 전문가가 알고 있는 규칙이나 관련 문서에서 규칙을 가져온다. 예시로 계약 한도를 100만 달러 초과로 두지 말아야 하는 조건이 언급됐다.
   2. 입력 생성: 특정 규칙을 만족하거나 의도적으로 깨는 조항을 만들고, 그 조항을 포함한 계약을 생성한다.
   3. 기대 정답: 위반을 심은 계약에는 해당 규칙의 flag가 나와야 하고, 위반하지 않은 계약에는 그 flag가 없어야 한다.
2. 규칙 커버리지는 불완전하지만 275개의 자동 테스트를 만들었다.
   1. 규칙 수집: 전문가와 내부 문서에서 일부 규칙을 가져올 수 있었지만 모든 규칙을 빠짐없이 다뤘다고 보장할 수 없었다.
   2. 보완: 팀은 자체적으로 규칙을 추가해 테스트 범위를 넓혔다.
   3. 규모: 실행 가능하고 기대 답을 알고 있는 테스트 275개를 만들었다. 문제를 심어 다시 찾아내게 한다는 점에서 RAG의 역방향 평가와 같은 구조다.

4.3. 방법 3 — 정상 계약에서 조항을 제거해 누락을 찾게 한다

1. 서명된 계약에서 조항 하나를 제거하면 에이전트가 결손을 탐지해야 한다.
   1. 변형: 정상적으로 서명된 계약을 바탕으로 특정 조항을 삭제한다.
   2. 기대 동작: 에이전트가 “필요한 조항이 빠졌다”고 알아채고 해당 누락을 flag해야 한다.
2. 계약별 템플릿 차이를 감안해야 하지만 가장 강한 벤치마크가 됐다.
   1. 난점: 공급업체마다 사용하는 템플릿과 내용이 다르다. 어떤 조항이 특정 계약에 반드시 있어야 하는지 정하는 데 도메인 판단이 필요하다.
   2. 음성 대조군: 조항을 바꾸지 않은 기존 계약을 섞어, 정상 계약에는 flag가 추가되지 않는지도 확인한다.
   3. 관찰: 이 접근으로 계약 테스트를 많이 만들 수 있었고, 에이전트가 삭제된 조항 대부분을 놓친다는 사실이 드러났다. 발표자는 현재까지 가장 강력한 벤치마크라고 평가했다.

4.4. 방법 4 — 결과가 바뀌면 안 되는 입력 변형을 시험한다

1. 업무상 무관한 변경은 flag 결과를 바꾸지 않아야 한다.
   1. 명칭·주소 변경: 공급업체 이름이나 주소를 바꿔도 flag 개수가 달라지면 안 된다.
   2. 조항 순서 변경: 조항을 재배열하거나 일부 무작위성을 주더라도 같은 계약의 판정은 유지돼야 한다.
   3. 반복 실행: 동일한 계약을 여러 번 처리해 결과 일관성을 점검한다.
2. 불변성(invariance)과 일관성은 코드로 확인할 수 있다.
   1. 비교 기준: 원본과 의미 없는 변형본의 flag 수·출력을 비교한다.
   2. 자동 판정: 기대되는 결과가 명확하므로 이 검사는 LLM judge 없이 코드로 수행한다.

4.5. 방법 5 — 빈칸 템플릿의 조합을 만들어 테스트를 증식한다

1. 전문가가 실제 사용하는 계약 템플릿을 재사용해 여러 입력을 만든다.
   1. 기본 형식: 계약 템플릿에는 전문가가 채우는 빈칸이 있다.
   2. 값 생성: 빈칸을 직접 한 가지 값으로 채우는 대신, 각 빈칸에 들어갈 값의 배열을 만들고 조합한다.
   3. 다양한 계약: 값 조합에 따라 일부 계약은 규칙을 위반하고 다른 계약은 준수하게 만들 수 있다.
2. 조합의 정답을 알고 있으므로 코드 판정이 가능하다.
   1. 기대 flag: 어느 값 조합이 규칙을 깨는지 사전에 알기 때문에 위반 표시 여부를 코드로 점검한다.
   2. 전문가 작업과의 연결: 전문가가 이미 사용하는 템플릿을 테스트 생성에 재활용한다.
   3. 개발 주기: 전문가 피드백을 받기까지는 4주가 걸렸지만, 스크립트 실행과 자동 평가는 5분이면 끝났다.
   4. 평가 위치: exact match와 코드 기반 검사로 해결할 수 있는 부분을 먼저 다루고, 불필요하게 LLM 판단으로 넘기지 않는다.

5. LLM judge보다 결정적인 코드 평가와 전문가 피드백

5.1. LLM judge는 별도의 잡음과 엔지니어링 부담을 만든다

1. 채점 모델의 오류가 에이전트 자체의 오류보다 커질 수 있다.
   1. 관찰: 이 프로젝트에서 LLM judge는 에이전트보다 더 많은 잡음을 만들었다.
   2. 추가 설계 문제: 적절한 judge 프롬프트와 실행 하네스(harness)를 찾는 일 자체가 어렵고, 평가 시스템을 만드는 일이 원래 과제를 푸는 것만큼 어려워질 수 있다.
   3. 보완 시도: 사실 확인(fact checking) 등 잡음을 줄이는 기법을 적용할 수 있지만, 많은 추가 작업이 필요했고 이 프로젝트에 맞는 평가기를 찾지 못했다.
2. 기대 답을 코드로 판정할 수 있으면 LLM judge를 피한다.
   1. 정확한 비교: exact match, 알려진 문서 비교, 규칙·불변성 검사 등 확정된 기준부터 코드로 계산한다.
   2. 선택적 사용: LLM judge가 세련되고 유용할 수는 있지만, 코드로 답을 확인할 수 없는 상황에서만 검토할 가치가 있다.

5.2. 전문가 피드백은 테스트를 더 낫게 만드는 데 쓴다

1. 사람의 검토는 자동 테스트를 대체하는 것이 아니라 보완한다.
   1. 역할 분담: 자동 테스트를 생성해 빠르게 실행하고, 실제 결과에 대한 전문가 피드백으로 테스트의 품질을 확인한다.
   2. 피드백 활용: 전문가의 의견을 에이전트의 수정에만 쓰지 않고 더 좋은 테스트, 프롬프트, 조항 제거 아이디어를 만드는 데 활용한다.
2. 한 번에 하나씩 평가 루프를 개선한다.
   1. 반복: 새로 발견한 문제를 더 나은 테스트로 구체화하고, 그 테스트로 변경 결과를 확인한다.
   2. 경계: 모든 도메인 규칙이나 판단을 한 번에 자동화하려 하지 않는다. 유효한 테스트를 한 단계씩 확장한다.

6. 다른 에이전트에 적용할 때의 범위와 시사점

6.1. 경로(trajectory) 테스트와 Test-to-SQL

1. 최종 답뿐 아니라 중간 경로를 검증할 수 있는 업무도 있다.
   1. 정해진 지점: 일부 에이전트 업무는 여러 정해진 지점(handpoints)을 순서대로 거쳐야 한다.
   2. 테스트 구성: 도달해야 할 마지막 지점과 순서를 알고 있으면, 그 과정을 유도하는 시나리오를 만들고 에이전트 trace에서 경로가 맞는지 확인할 수 있다.
2. Test-to-SQL도 답을 아는 입력 생성의 한 예다.
   1. 원리: SQL 업무에서도 기대 결과를 정할 수 있다면 입력을 만들고 에이전트가 결과를 찾아내는지 확인한다.
   2. 범용성의 한계: 에이전트 종류와 관계없이 쓸 수 있는 사고방식이지만 모든 업무에 똑같이 적용되지는 않는다.

6.2. 평가 가능한 형태로 문제와 솔루션을 재설계한다

1. 원래 설계가 평가 불가능하면 평가 가능한 접근으로 바꾸기도 한다.
   1. 전제: 무엇을 찾는지, 정답을 어떻게 고를지 알 수 있어야 입력 합성이 가능하다.
   2. 재설계: 기존 솔루션 그대로는 평가할 수 없어 설계를 약간 바꾸고, 원래 접근에서 멀어지더라도 테스트할 수 있는 방식으로 전환한 사례가 있다.
   3. 이유: 배포 후 좋아졌는지 모르는 설계보다, 측정 가능한 설계가 개선 루프를 만든다.
2. 합성 테스트는 제품 출시를 승인하는 최종 판정이 아니다.
   1. 용도: 테스트 생성은 에이전트 동작을 예측하고 개발을 안내하는 출발점이다.
   2. 한계: 테스트 통과만으로 제품을 출시해도 된다는 go/no-go 결론을 내릴 수는 없다.
   3. 실천: 평가 없이 에이전트를 계속 출시하는 습관을 멈추고, 실제 피드백과 테스트를 개선 루프에 포함한다.

주요 발언 모음

“에이전트를 채점할 수 없다면, 더 좋게 만들 수 없다.”

“답을 먼저 쓰고, 에이전트가 그 답을 다시 찾아오는지 확인한다.”

“복잡성은 항상 도움이 되지 않는다.”

“테스트는 출시 여부를 결정하는 go/no-go가 아니라 시작점이다.”

핵심 데이터 & 수치

• 약 10,000건: 통신 엔지니어 Q&A RAG가 다룬 문서 수. 여기에 다수의 공급업체 문서가 더해졌다.
• 약 90%: 관련 문서를 찾으면 답이 맞는 경우가 대부분이었다는 발표자의 설명. RAG의 주요 병목은 문서 검색이었다.
• 챗봇 5개: 같은 질문에 대한 답을 전문가가 한 화면에서 비교하던 회의 방식.
• 주 1회 → 하루 수십 회: 정답 문서 기반 자동 테스트 도입 후 평가 빈도 변화.
• 275개: 알려진 규칙으로 생성해 기대 답을 가진 계약 테스트 수.
• 조항 제거 테스트: 정상 계약에서 조항을 없앤 뒤 에이전트가 누락을 탐지하는 방식. 에이전트가 제거 조항 대부분을 놓쳤다.
• 4주 vs 5분: 전문가 피드백을 얻는 데 걸리는 주기와 스크립트 자동 평가 실행 시간.
• LLM judge: 이 프로젝트에서 judge가 에이전트보다 더 큰 평가 잡음을 보였으며, 적절한 프롬프트·하네스도 해결되지 않았다.
• 정확도 수치 미공개: RAG 전문가 채점 정확도는 여러 주 동안 상승했으나 구체적인 퍼센트는 제시되지 않았다.

결론 및 시사점

1. 도메인 전문가가 부족하고 공개 벤치마크가 없는 사내 업무에서도, 알려진 답을 출발점으로 입력을 생성해 테스트 세트를 만들 수 있다.
2. RAG는 정답 문서에서 질문을 합성하고 검색 문서를 비교한다. 계약 검토는 규칙 위반을 심거나, 조항을 제거하거나, 무관한 항목을 바꾸거나, 템플릿의 빈칸을 조합한다.
3. 정답을 기계적으로 비교할 수 있는 평가는 코드로 자동화한다. LLM judge가 내는 잡음과 이를 줄이는 프롬프트·하네스 비용을 먼저 고려한다.
4. 자동 평가는 빠른 반복을 가능하게 하고, 전문가 피드백은 에이전트뿐 아니라 테스트와 프롬프트를 개선하는 데 쓴다.
5. 테스트는 제품 출시를 자동 승인하는 증명서가 아니라 개발을 안내하는 출발점이다. 필요하면 테스트 가능한 방식으로 솔루션 자체도 재설계한다.

핵심 요약 (20줄)

Air Canada의 AI 팀은 운영·기업·상업·로열티 부문의 업무를 위해 서로 다른 특수 에이전트를 만들며, 공개 벤치마크가 없는 과제를 다룬다. 데이터 과학자와 AI 엔지니어는 도메인 전문가가 아니고, 전문가들은 바빠 평가를 위한 접근 시간이 제한된다. 통신 엔지니어용 RAG는 약 1만 건의 문서와 벤더 자료, 질문에 맞는 문서를 선택하는 복잡한 로직을 다뤘다. 관련 문서를 찾으면 답은 대체로 맞았으므로, RAG의 핵심 병목은 정답 근거 문서를 검색하는 일이었다. 논문 기법을 더한 복잡한 파이프라인은 성능을 보장하지 않았고, 기존에 되던 기능을 깨뜨리기도 했다. 다섯 개 챗봇의 답을 주 1회 전문가가 비교하는 방식은 의견 불일치와 검토 시간 때문에 실험 속도를 제한했다. 평가를 뒤집으려면 정답이 담긴 문서를 고르고, LLM으로 그 문서를 찾을 질문을 생성한다. 에이전트가 질문에 답해 회수한 문서를 정답 문서와 비교하면 사람의 선호 없이 코드로 판정할 수 있다. 이 역방향 테스트는 평가 빈도를 주 1회에서 하루 수십 회로 늘렸고, 전문가 채점 정확도의 개선과 연결됐다. 불필요한 복잡성을 걷어내고 임베딩 모델, 청킹, BM25 alpha에 집중하면서 RAG 품질이 여러 주에 걸쳐 상승했다. 공급업체 계약 검토는 비준수 조항을 찾아 수정안을 제안하는 업무이며, 검토 지연과 조항 누락 모두 비용이 크다. 계약 에이전트는 조항을 식별하고, 수정 근거를 검색하고, 수정안을 작성한 뒤 채택 여부를 분류한다. 과거 서명본과 협상본을 비교하는 테스트는 유용하지만 계약의 원본·버전 쌍이 보존되지 않아 적용이 어려웠다. 알려진 규칙을 위반하는 조항을 계약에 심는 방식으로 기대 답을 아는 테스트 275개를 만들었다. 서명된 계약에서 조항을 제거하는 방식은 가장 강력한 벤치마크였고, 에이전트는 제거된 조항 대부분을 놓쳤다. 공급업체 이름·주소나 조항 순서를 바꾸고 반복 실행해도 flag 결과가 유지되는지 코드로 확인한다. 전문가가 쓰는 빈칸 템플릿의 값을 조합해 규칙 위반·준수 계약을 만들면 기대 flag를 코드로 정할 수 있다. 자동 스크립트 평가는 5분이면 가능했지만, 전문가 피드백을 받는 개발 주기는 4주에 달했다. LLM judge는 에이전트보다 큰 잡음을 만들 수 있으므로 exact match와 코드 판정이 가능하면 우선한다. 전문가 피드백은 에이전트뿐 아니라 테스트와 프롬프트를 개선하는 데 쓰며, 생성 테스트는 출시 승인보다 개발의 출발점이다.