How to Know If Your AI Agent Is Any Good: Evals With Phoenix & Claude — Laurie Voss, Arize AI

한 줄 핵심

LLM 에이전트의 품질은 감으로 판단할 수 없으며, 트레이싱·코드 평가·LLM 심사·실험·CI를 연결해 수치로 검증하고 반복 개선해야 한다.

시간별 요약

1. 0:00
   소개와 실습 환경 설정 Phoenix와 Claude를 이용해 손으로 따라 해보는 워크숍이며, Node 22 이상과 Anthropic 키, 로컬에서 실행하는 Phoenix가 필요하다. 예제 코드는 이미 준비되어 있고, 체크포인트가 있어 중간에 놓쳐도 다시 따라갈 수 있다.
2. 2:47
   "괜찮아 보인다"는 테스트가 아니다 LLM 앱은 여러 번 써보면 괜찮아 보여도, 실제 사용에서는 쉽게 깨지거나 수정 과정에서 회귀가 생긴다. eval은 이런 비결정적 출력을 사람이 매번 읽지 않고도 개선 전후를 비교하게 해주는 기준점이다.
3. 4:57
   트레이스와 평가의 관계 트레이스는 에이전트가 무엇을 했는지 기록하는 로그이고, eval은 그 트레이스가 좋은지 판단하는 테스트다. 유닛 테스트처럼 문자열을 고정할 수 없는 LLM 출력에는 트레이스 기반 평가가 필요하며, 수치로 품질을 추적할 수 있다.
4. 8:30
   코드 평가, LLM 심사, 사람 검토 코드 평가는 형식·길이·필수 필드처럼 결정적인 조건을 빠르게 검사하고, LLM 심사는 정확성·근거성·톤 같은 의미를 판단한다. 사람 검토는 가장 신뢰할 수 있지만 느리고 비싸므로, 세 가지를 조합해야 한다.
5. 11:57
   에이전트가 자신 있게 틀리는 이유 에이전트는 초반 한 번의 실수가 뒤로 전파되며, 그 결과 그럴듯하지만 완전히 잘못된 출력을 낸다. 출력에는 점수·라벨·설명이 함께 있어야 하며, 특히 설명은 무엇이 잘못됐고 무엇을 고쳐야 하는지 찾는 데 가장 유용하다.
6. 16:32
   Phoenix로 트레이싱하기 Phoenix를 연결하면 에이전트의 각 단계, 도구 호출, LLM 호출, 토큰 수, 비용이 자동으로 기록된다. TypeScript에서는 instrumentation을 올바르게 주입해야 하며, 예제 에이전트는 연구 턴과 작성 턴을 하나의 trace로 묶어 보여준다.
7. 36:36
   트레이스 읽기 eval을 쓰기 전에 먼저 트레이스를 직접 읽어 실패 양상을 이해해야 한다. 열린 코딩으로 현상을 메모하고, 그다음 축 코딩으로 범주화해야 하며, 성급하게 카테고리를 먼저 정하면 실제 실패 유형을 놓치기 쉽다.
8. 43:21
   116% 분석가 합의 버그 Tesla 사례에서 에이전트는 서로 다른 검색 결과를 잘못 합쳐 116%라는 말도 안 되는 합의를 만들어냈다. 이 예시는 잘못된 결과가 검색 실패인지, 추론 실패인지, 범위 문제인지 트레이스로 구분해야만 제대로 고칠 수 있음을 보여준다.
9. 50:36
   코드 평가 만들기 가장 쉬운 평가는 보고서에 요청한 티커가 실제로 들어 있는지 확인하는 결정적 검사다. Phoenix에서 run 데이터를 가져와 TypeScript 함수로 채점하고, 결과를 다시 trace에 붙이면 매우 빠르고 저렴한 검사가 된다.
10. 56:11
    LLM 심사 만들기 정확성은 최신 데이터 시점 때문에 오히려 부적절할 수 있고, 이 경우 faithfulness처럼 주어진 근거에 기반했는지를 묻는 평가가 더 적합하다. Phoenix의 기본 심사들은 모델·루브릭·데이터를 분리해 재사용할 수 있고, 도구 사용 평가도 함께 제공된다.
11. 1:00:30
    정확성 평가가 전부 실패한 이유 기본 correctness는 모델의 지식 컷오프 때문에 최신 주가·재무 데이터가 포함된 보고서를 전부 틀렸다고 판정했다. 반면 faithfulness는 검색 결과와 보고서의 일치 여부를 잘 잡아내며, tool selection 평가도 출력보다 도구 선택의 적절성을 따로 볼 수 있게 해준다.
12. 1:10:41
    나만의 심사 작성하기 좋은 루브릭은 역할과 맥락, 명확한 기준, XML 같은 경계 표시, 예시, 그리고 출력 제약을 포함해야 한다. 한 번에 모든 걸 재는 하나의 거대한 평가보다, faithfulness·correctness·actionability처럼 축을 나눠 따로 재는 편이 더 안정적이다.
13. 1:24:45
    심사 검증하기 심사도 분류기이므로 인간 정답과 비교해 검증해야 하며, 데이터셋은 dev와 test로 나눠야 한다. precision과 recall을 함께 보고, 인간과의 일치율이 완벽하지 않아도 실제 운영에서 유용한 수준인지 확인해야 한다.
14. 1:38:55
    실험하기 eval로 문제를 찾았으면, 같은 입력과 같은 평가로 수정 전후를 비교하는 실험을 해야 한다. 데이터 품질이 가장 중요하고, 그다음이 프롬프트, 모델 선택, 하이퍼파라미터 순이며, 개선 효과는 pass at K와 pass to the K 같은 관점으로 해석할 수 있다.
15. 1:48:30
    Claude Haiku 5.5로 업그레이드하기 평가가 준비되어 있으면 모델 교체도 감이 아니라 비교 실험으로 할 수 있다. Haiku 5.5는 일관성은 좋아졌지만 너무 보수적으로 변해 hold를 남발했고, 더 비싸졌는지까지 포함해 실제 효용을 판단해야 한다.
16. 1:50:55
    CI에 평가 넣기 eval은 테스트 러너에 그대로 붙여 CI에서 실행할 수 있으며, guardrail은 반드시 막아야 할 조건, north star는 목표로 삼을 조건으로 나눠야 한다. 빌드 실패 시에도 왜 실패했는지 설명이 남아야 하고, 이 구조를 GitHub Actions에도 그대로 올릴 수 있다.
17. 1:55:25
    월요일에 어디서 시작할까 처음부터 모든 걸 다 하려 하지 말고, 먼저 에이전트를 계측하고 몇 개의 트레이스를 읽는 것부터 시작하면 된다. 실제 서비스에서도 표본 트래스를 계속 평가해 추세가 나빠질 때만 경고를 띄우는 방식이 가장 실용적이다.

실무 인사이트

• 처음에는 코드 평가와 트레이스 읽기로 시작해도 충분하며, 의미 평가(LLM 심사)는 그다음 단계로 붙이는 편이 실패 원인을 빨리 좁힌다.
• 정답처럼 보이는 평가도 최신성·루브릭 모호성 때문에 쉽게 틀릴 수 있으므로, 심사 자체를 dev/test로 검증하는 절차가 필수다.
• 실무에서는 하나의 거대한 만능 평가보다, 티커 포함 여부·근거성·행동 가능성처럼 실패 유형별로 평가를 쪼개는 것이 유지보수와 디버깅에 유리하다.