How to Write Your First AI Eval - SallyAnn DeLucia, Arize AI

한 줄 핵심

AI 에이전트의 품질 관리는 감으로 하는 “vibe check”가 아니라, 트레이스와 명확한 기준을 바탕으로 eval을 설계·데이터화·검증해 나가는 반복 과정이다.

시간별 요약

1. 0:00
   소개와 아젠다 eval을 AI 에이전트의 핵심 신호로 보고, 무엇이 eval인지 정의한 뒤 직접 기준을 쓰고 Arize에서 작동하는 judge를 만드는 흐름으로 워크숍이 진행된다. 오늘의 목표는 개념 정리, 기준 작성, 실제 평가기 구축과 개선 방법을 얻는 것이다.
2. 2:06
   감각적 판단이 확장되지 않는 이유 프롬프트를 바꿨을 때 “좋아 보인다”는 감각만으로는 회귀를 잡을 수 없고, 모델 버전 간 비교도 객관적으로 할 수 없다. eval이 없으면 CI에 품질 게이트를 넣기 어렵고, 배포 후 성능 악화를 증명하기도 힘들다.
3. 3:08
   eval은 단위 테스트와 같은가 AI eval은 전통적인 단위 테스트와 비슷해 보이지만, 하나의 입력에 하나의 정답만 있는 구조가 아니라 여러 개의 유효한 출력이 존재한다는 점이 다르다. AI에서는 코드보다 트레이스가 더 중요하며, eval을 하려면 관측성과 트레이스가 함께 있어야 한다.
4. 4:13
   에이전트가 eval을 더 어렵게 만드는 이유 에이전트는 여러 단계의 LLM 호출과 도구 사용이 얽힌 트레이스로 동작하므로, 단일 테스트로는 실제 복잡도를 포착하기 어렵다. 각 span은 에이전트가 수행한 작업 단위이며, 이 흐름 전체를 봐야 응답의 질을 판단할 수 있다.
5. 5:15
   eval의 종류 오늘은 LLM as a judge에 집중하지만, 코드 기반 평가, 주석 데이터, agent as a judge, 사용자 피드백, 비즈니스 지표 등 다양한 평가 방식이 있다. 개발과 운영 전반에서 함께 쓸 수 있는 평가를 설계해야 시간이 지나도 일관된 품질 관리를 유지할 수 있다.
6. 7:29
   워크숍 준비 참가자는 demo project에 접속해 Arize AX와 원하는 LLM provider를 연결한 뒤 트레이스를 볼 수 있어야 한다. 다양한 provider를 쓸 수 있고, 핵심은 실제 LLM 호출이 가능한 API key를 넣어 실습 환경을 준비하는 것이다.
7. 10:16
   여행 에이전트의 트레이스 살펴보기 여행 계획 에이전트는 사용자 요청을 받아 후속 질문을 하고 도구를 호출해 일정을 만든다. 좋은 결과는 사용자의 후속 질문에 답하고, 여행 일수와 예산을 지키는 것이며, 트레이스를 보며 무엇을 측정할지 먼저 감을 잡아야 한다.
8. 14:20
   트레이스를 읽는 방법 root span은 최상위 입력과 최종 출력을 담고, 그 아래의 span들은 각 작업 단위를 나타낸다. 연구 agent, tool span, LLM span이 순서대로 연결되며, 어떤 데이터가 어디서 생성되고 어떻게 다음 단계로 전달되는지 추적할 수 있다.
9. 19:03
   무엇이 좋은지 정의하기 좋은 기준은 “helpful”처럼 모호한 표현이 아니라, 사용자의 후속 질문에 답한다, 요청한 일수를 맞춘다, 예산을 넘지 않는다처럼 구체적이어야 한다. 특히 LLM as a judge에서는 한 번에 하나의 품질만 판단하는 것이 더 안정적이며, 기준은 작은 것부터 시작해 점진적으로 늘리는 편이 좋다.
10. 22:02
    합격과 불합격 기준 쓰기 평가하려는 task, 성공의 의미, 실패의 의미, judge가 무엇을 판단할지, pass와 fail의 구체적 조건을 적어 두어야 한다. 이 내용은 그대로 prompt로 옮겨질 가능성이 높기 때문에, 사람에게 설명하듯 분명하고 구체적으로 써야 한다.
11. 25:19
    트레이스로 데이터셋 만들기 평가할 span을 골라 데이터셋으로 저장하는 것이 다음 단계이며, root span이나 특정 tool call처럼 평가 대상에 맞게 필터링하면 된다. 이렇게 만든 데이터셋이 이후 playground에서 eval prompt를 시험하는 기반이 된다.
12. 26:53
    LLM judge 만들기와 테스트하기 prompt playground에서 criteria를 평가용 prompt로 바꾸고, 데이터셋을 연결해 실제로 judge를 실행해 본다. variable mapping으로 입력 이름을 유연하게 연결할 수 있고, 결과를 보며 prompt를 반복 개선한 뒤 evaluator로 저장해 재사용할 수 있다.
13. 32:08
    다음 단계: 정렬, 온라인 eval, Signal 초기 eval을 만든 뒤에는 human feedback과 맞는지 정렬하고, traces마다 자동으로 돌리는 online eval로 확장하는 흐름이 중요하다. 다양한 이해관계자가 각각 성공 기준을 정의해야 하며, metric은 문제를 감지하고 eval은 실패 원인을 드러낸다는 점이 핵심이다.

실무 인사이트

• 실무에서는 “좋아 보인다” 수준의 판단을 버리고, 사용자 요구·예산·일수처럼 측정 가능한 기준으로 평가 항목을 먼저 정의해야 한다.
• eval 품질은 prompt만으로 결정되지 않고, 트레이스 수집과 span 단위 데이터셋 구성까지 포함한 관측 설계에 크게 좌우된다.
• 초기에는 한 가지 품질 기준과 소수의 트레이스로 시작해, human feedback과 운영 데이터를 반영하며 점진적으로 확장하는 방식이 가장 안정적이다.