Evals in AI: A Deep Dive — Tejas Kumar, IBM

한 줄 핵심

AI 시스템의 신뢰성과 보안을 높이려면 하네스로 런타임 안전장치를 두고, eval로 사전 검증하는 체계를 함께 설계해야 한다.

시간별 요약

1. 0:00
   소개 이 강연은 개인 의견이 아니라 업계 사례와 연구를 바탕으로 AI eval의 필요성과 설계 방법을 다룬다. 하네스와 eval을 통해 AI 애플리케이션을 더 안전하고 신뢰 가능하게 만드는 과정을 실습 중심으로 설명한다.
2. 2:03
   eval과 하네스가 함께 작동하는 이유 하네스는 실행 시점의 즉시 신뢰성을 제공하고, eval은 배포 전에 사전 신뢰성을 제공한다. 둘을 함께 쓰면 낮은 비용의 모델로도 안정적인 AI 시스템을 만들 수 있다.
3. 6:09
   eval과 안전하지 않은 에이전트 행동 권한이 큰 에이전트는 잘못된 동작이 곧 보안 사고로 이어질 수 있으므로, eval이 위험 행동을 미리 드러내야 한다. Instagram 사례처럼 인증 우회나 계정 변경 같은 문제는 하네스와 eval 모두에서 잡아야 한다.
4. 9:47
   애매한 단위 테스트와 평가 구성 요소 eval은 비결정적 시스템을 위한 신뢰성 계측이며, 직관적으로는 fuzzy unit test에 가깝다. 좋은 eval은 테스트 케이스, 기대 행동, 판정자, 결과 집계라는 공통 요소를 가진다.
5. 15:21
   평가 기법 exact match, schema validation, pair-wise comparison, LLM as a judge 같은 기법이 소개된다. 이 중 pair-wise는 편향과 취약성이 커서, 가능한 경우 point-wise나 더 정교한 판정 방식이 선호된다.
6. 18:30
   판정자가 오도하는 네 가지 방식 판정자는 위치 편향, 친절 편향, 자기참조 편향, 장황성 편향 때문에 잘못된 선택을 할 수 있다. 따라서 점수가 녹색이어도 실제로는 잘못된 판단일 수 있으므로, 판정 편향을 검사하는 절차가 필요하다.
7. 21:11
   인간 판정과 비교해 판정자 보정하기 판정자를 만들 때는 인간이 매긴 정답 데이터와의 합의율을 측정해야 한다. 대략 80~85% 수준의 합의가 목표이며, 100% 합의는 오히려 과적합이나 편향을 의심해야 한다.
8. 23:30
   CI 게이트와 최신 데이터 유지 배포는 단순 통과가 아니라 합의 기준을 만족할 때만 허용되는 게이트로 설계해야 한다. 운영 중에는 실제 트래픽을 스키밍해 데이터셋을 계속 갱신하고, 모델 버전도 고정해 두어야 한다.
9. 26:15
   OpenRAG로 살아 있는 정책 검색하기 정책은 고정 문서가 아니라 조직 변화에 따라 살아 움직이는 지식이므로, 에이전트와 판정자가 같은 정책 소스를 조회해야 한다. OpenRAG 같은 도구는 비정형 문서를 검색 가능한 정책 지식베이스로 바꿔 준다.
10. 28:55
    단위 테스트에서 시작하는 라이브 코딩 먼저 결정적 단위 테스트를 만들고, 그다음 비결정적 시나리오 테스트로 확장하는 흐름을 보여 준다. 구매 후 20일이 지난 헤드폰 반품 사례를 통해 고전적인 테스트와 eval의 차이를 실습한다.
11. 31:26
    오해를 부르는 부분 문자열 매칭 부분 문자열만 검사하는 느슨한 규칙은 겉보기에는 통과하지만 의미적으로는 잘못된 답도 통과시킨다. 비결정적 출력에 단순 문자열 매칭을 쓰면 false positive가 쉽게 생긴다.
12. 32:08
    LLM 판정자 만들기와 시험하기 LLM을 판정자로 써서 시나리오와 답안을 보고 pass/fail을 판단하게 만드는 과정을 구현한다. 그러나 같은 계열 모델에 대한 자기선호와 문장 스타일 편향이 드러나며, 문맥에 정책을 넣는 것의 중요성이 확인된다.
13. 36:19
    시나리오 데이터셋으로 보정하기 30개 안팎의 사례로 구성된 데이터셋을 사용해 판정자의 합의율을 측정하고, 어떤 케이스에서 어긋나는지 분석한다. 부족한 합의의 원인이 정책 지식 부족인지, 문맥 부족인지, 모델 품질 문제인지 구분해 보완한다.
14. 43:00
    정책 정제와 모델 교체 합의가 부족하면 먼저 정책 문구를 더 명확히 하고, 그래도 부족하면 더 나은 모델로 교체한다. 사용자 친절성에 흔들리지 않도록 반품 정책의 비가변성을 명시하는 식으로 지식 간극을 메운다.
15. 46:08
    합의를 CI 게이트로 전환하기 판정자와 인간의 합의율이 80% 이상일 때만 통과시키는 CI 게이트를 만든다. 이렇게 하면 과적합을 피하면서도 실제 배포 전에 충분한 품질 기준을 강제할 수 있다.
16. 48:12
    정책 검색 데모 더 세련된 데모에서, 정책을 프롬프트에 직접 넣지 않으면 pair-wise 판단이 흔들리지만 정책을 검색해 넣으면 결과가 안정된다. Dockling과 OpenSearch 기반의 OpenRAG 파이프라인으로 문서, PDF, 오디오, 비정형 자료를 LLM이 쓸 수 있는 형태로 바꾸는 흐름도 보여 준다.
17. 51:53
    정리와 평가 비용 eval은 사전 신뢰성과 공격·장애 완화에 유용하며, deterministic test에서 시작해 점점 더 fuzzy한 방법으로 확장하는 것이 비용 효율적이다. 가장 싼 방법부터 검토하고, 결국에는 판정자와 관측성, 트레이스를 활용해 판단을 정교화해야 한다.
18. 54:36
    청중 질문 합성 데이터로 eval을 확장하는 방법, coding agent의 skill에 eval을 붙여야 하는지, 그리고 생산 환경의 정책을 judge와 agent가 어떻게 공유해야 하는지가 논의된다. 핵심은 agent와 judge가 같은 정책 소스를 보도록 만들어 합의와 재현성을 높이는 것이다.

실무 인사이트

• eval을 만들 때는 먼저 deterministic test와 trace 검증으로 해결할 수 있는지 확인하고, 그다음에만 LLM judge를 쓰면 비용과 복잡도를 크게 줄일 수 있다.
• 판정자 품질은 평균 점수보다 인간 정답과의 합의율, 편향 검사, 정책 문맥의 최신성으로 관리해야 한다.
• 운영 단계에서는 eval 데이터셋과 정책 소스를 살아 있는 자산으로 보고, 실제 트래픽과 검색형 지식베이스로 계속 갱신해야 한다.