영상 링크: Engineering Better Evals: Scalable LLM Evaluation Pipelines That Work — Dat Ngo, Aman Khan, Arize
채널명: AI Engineer
더 나은 LLM 평가를 위한 확장 가능한 평가 파이프라인 구축 핵심 요약
- 영상은 Arize AI의 AI 아키텍트 Dat Ngo가 LLM(대규모 언어 모델) 평가(Eval) 파이프라인을 어떻게 효율적이고 확장성 있게 구축할 수 있는지 실무적 관점에서 설명하는 발표임
- Arize AI는 Reddit, Duolingo 등 주요 고객사의 사례를 통해 대규모 AI 평가 및 관찰 시스템을 제공하는 업계 리더임을 강조
- LLM 평가의 3가지 주요 구성 요소(관찰성·Observability, 평가·Eval, Golden Dataset 등)를 구체적으로 소개하며, 각 층위별로 관찰과 평가의 방법이 다를 수 있음을 설명
- LM(as a judge) 방식이 널리 쓰이지만, 단순 LLM 채점 외에도 휴리스틱, 코드기반, 사용자 피드백, golden 데이터 셋 등 다양한 방법의 평가가 상호 보완적으로 필요함을 강조
- Duolingo의 실제 운영 사례를 들어, 하나의 트레이스마다 20회 이상 평가가 실행되며 막대한 비용과 최적화 노력이 요구된다고 소개
- 기존의 라우팅 기반 LLM 시스템 구조부터 점차적으로 복잡해지는 에이전트 기반 아키텍처까지 다양한 평가 포인트와 그 난이도 상승을 예시로 설명
- 에이전트 평가에서는 단일 트레이스가 아닌, 전체 경로 분포와 실패 모드까지 파악해야 하며, 이를 위해 Aggregated Graph 등 플랫폼 기능 활용이 필수적임을 시연
- 평가 기준이나 프로세스, 프롬프트는 out-of-the-box보다 고객/업무에 특화된 맞춤형 최적화가 가장 좋은 결과를 낸다는 업계 경험을 강조
- Guardrail 적용, 인라인 및 오케스트레이션 외부 평가의 장단점을 논의하며, 시스템의 본질적 개선(프롬프트/모델 튜닝)의 우선을 권고
- 오픈텔레메트리(OpenTelemetry) 활용, 콘피던스 스코어 계산법(log probability 및 확률적 분류 등), 자동화 프롬프트 최적화(DSPY 및 meta-prompting) 등 최신 기술을 공유하며 발표를 마침
세부 요약 - 주제별 정리
관찰성, 평가, Golden Dataset은 LLM 파이프라인의 핵심 세 기둥임을 강조함
- Arize AI의 Dat Ngo는 LLM 실무 평가 환경에서 관찰성(observability)·평가(eval)·golden 데이터셋 세 요소가 필수임을 반복적으로 강조함
- 관찰성은 모델/시스템이 실제로 “무엇을 하고 있는가”를 정량적으로 파악하게 해줌
- Traces, spans, analytics 등 다양한 방식으로 관찰 데이터 수집
- 예시: AI팀, AI PM, 플랫폼팀 등 각각이 중요하게 여기는 관찰 지표가 서로 다름
- 평가(Eval)는 “무엇이 잘 되고 있고, 무엇이 잘 안 되는가”라는 신호(signal)를 자동으로 얻기 위한 수단임
- 대규모 운영 환경에서는 개별 트레이스 수작업 검수가 불가능하므로 자동평가가 필수적으로 요구됨
- Golden 데이터셋은 신뢰도 있는 레퍼런스 데이터를 확보해, 평가의 정밀도 및 LLM judge 튜닝에 활용함
- AI 핵심팀(예: Duolingo 등)은 반드시 Golden 데이터셋과 LLM judge의 정합성을 검증하는 구조를 가짐
LLM as a Judge 방식이 주류지만, 다양한 보조 평가 도구와 병행해야 실효성이 높음
- LLM as a judge란 LLM에게 프롬프트 결과 또는 모델 출력을 채점하도록 하는 방식으로, 대다수 최신 서비스에서 사용됨
- 예시: RAG(검색 기반 생성) 워크플로우에서는 “컨텍스트의 적절성(관련성)”, “최종 답변의 품질” 등 다양한 체크포인트를 LLM judge로 평가함
- 단, LM as a judge만으로 수렴할 수 없는 평가 항목·비용·정확성 이슈가 항상 존재
- 예: Encoder-only(BERT류) 모델 적용 시, 대략 1
2자릿수(10배100배) 속도 및 비용절감 가능 - 코드 기반 휴리스틱(예: 키워드 확인, JSON 파싱 가능 여부, 정규표현식 패턴 매칭 등)은 LLM/human 평가보다 훨씬 저렴·빠르게 자동화 가능
- Human label(사용자 피드백, 휴먼 레이블링, golden data labeling)은 소규모지만 확실한 신뢰도를 제공해, 평가 튜닝의 기준(ground truth)으로 사용됨
- 예: Encoder-only(BERT류) 모델 적용 시, 대략 1
- 중요한 프로덕션 팀(약 30% 손들었음)은 적극적으로 사용자 피드백을 수집·활용하여, 인간 중심의 평가 신호를 분석
현장에서는 “평가 기준의 주기적 개선”이 필수이며, 2가지 순환적 선순환 구조가 존재함
- 왼쪽 원(메인 사이클): 기존 AI 개발의 일반적 선순환(데이터/관찰→평가→신호정제→프롬프트/모델/오케스트레이션 개선→재배포)
- 오른쪽 원(평가 개선 루프): 평가(및 프롬프트)가 처음엔 불완전할 수밖에 없으므로, 실제 신호와 오답 데이터(실패 원인, 잘못된 평가 등)를 주기적으로 수집·분석→평가 기준 및 프롬프트/평가 자체의 품질을 끊임없이 튜닝·개선
- 결과적으로, “빠른 반복 주기”가 고품질 AI 시스템 개발의 핵심 성공요소임을 실사례로 설명
복잡한 LLM 시스템(특히 에이전트 기반)으로 갈수록 평가 포인트와 복잡성이 기하급수적으로 증가함
- 예시1: Booking.com 여행 플래너 AI의 경우, 복수의 에이전트 콜, API 연계, 다양한 휴리스틱/컨트롤 플로우 등 다층적 평가항목 존재
- 평가 대상을 트레이스 내 “개별 컴포넌트 수준”, “전체 워크플로우 I/O(입출력) 수준”, “컨트롤 플로우 성공/실패 여부” 등 계층별로 세밀하게 조정할 필요
- 조건부 평가(conditional eval): 하위 컴포넌트의 필수 조건이 통과되지 않으면 하위 평가를 건너뛰어 비용·리소스 절감함
- 전체 세션(다수 트레이스) 단위 평가: “전체 대화 내내 사용자가 어느 시점에 불만족(Frustration)했는가, 문제 발생 분포는 어떠한가” 등 집합적 뷰가 필요
산업 현장에서는 평가 방법론 ‘커스터마이징’이 필수이며, ‘Out-of-the-box Eval’은 지양해야 함
- 각 기업·서비스 환경·어플리케이션 목적에 따라 평가 기준/프롬프트/프로세스를 최대한 맞춤화(customization)해야 고품질 결과 도달 가능
- Out-of-the-box(즉시 제공/일반화된) 평가 메트릭, 프롬프트, 템플릿 적용 시 결과도 평이(out-of-the-box result)에 그치므로, 반드시 환경 특화된 고도화를 추진해야 함
- 플랫폼·프로덕트별로 각기 다른 세부 구성(에이전트 도구, 워크플로우, 사용자 요구사항 등)에 최적화된 평가설계를 지속적으로 권장
최신 AI 트렌드에 맞춘 Arize의 에이전트 평가 아키텍처와 그래프 집계 기능 시연
- Arize의 AI Copilot는 자체적으로 다른 AI 시스템의 평가/추적/관찰/고장 진단을 담당하는 에이전트 기반 시스템임
- AI가 AI를 평가하는 미래 구조의 선행 프로젝트로 약 1년간 서비스 중
- 실제 Arize 플랫폼에서는 다양한 에이전트 콜 트레이스 및 그 경로를 “프레임워크에 독립적”으로 시각화 및 분석 가능
- LangGraph, CrewAI, 커스텀 코드 등 다양한 구조의 에이전트 시스템과 호환 가능
- 예: 10개 도구를 불러오는 에이전트라면 각 도구별 호출 빈도, 특정 경로에서 발생하는 에러·성능저하 등 집합적 실패 모드 분석 가능
개별 트레이스가 아닌 “Aggregate View(전체 경로 분포 및 실패 모드)“가 중요하다는 점을 산업 현장 예시로 설명
- 단일 트레이스 기반 평가만으론 전체 실패 패턴이나 경로별 문제를 발견하기 힘듦
- 예시: Agent가 1→2→3 컴포넌트 경로에서는 우수하나, 4→2→3 경로 진입 시 성능이 급락한다면, 4번 컴포넌트에 종속성/결함 가능성 존재
- 전체 트레이스 집계 분석 → 문제 경로 추출 → 원인 규명 및 평가·시스템 개선에 활용
”트래젝토리(trajectory) 평가” 개념 활용으로 복잡한 에이전트 워크플로우의 평가 효율을 극대화함
- 입력(예: 호텔 예약 요청 등)에 따라 거쳐야 하는 컴포넌트 경로(trajectory)에 대한 골든 레퍼런스 지정 가능
- 실제와 기대 트래젝토리를 LLM judge에 입력해 평가하게 하거나, 키 값 비교 등 코드 기반 평가도 가능
- 각 경로 노드 묘사가 기대 트래젝토리와 일치하는지, 혹은 기대 경로 중 핵심 부분만 도달했는지 등 다양한 평가 방식 조합 가능
인라인(Inline) 평가와 오케스트레이션 외부 평가(Guardrail 등)의 장·단점 및 적용 전략을 심층 분석함
- 평가 시점: 인라인(실행 흐름 내부) vs. 오케스트레이션 외부(Guardrail)
- 장점: Guardrail은 즉각적 위험 완화에 유리, 인라인 평가로 신속한 피드백 가능
- 단점: 인라인은 딜레이/지연(지연 시간), Guardrail-오케스트레이션 이중 시스템 운영은 복잡성 증가(특히 상호체크 구간에서)
- 권장: 문제 발생 시 대부분의 원인은 본시스템(System 1)의 프롬프트 혹은 모델 설계에 있음→Guardrail(System 2)에 집착하지 말고 본 시스템 개선이 우선
- Guardrail을 유닛 테스트처럼 “알려진 리스크(known knowns)” 방어용으로 분명히 위치시킬 것
분산/비동기 시스템에서 평가 트레이스 전체 집계는 오픈텔레메트리(OpenTelemetry, OTEL)로 해결 가능함
- 복잡한 시스템(여러 서비스, Docker/Kubernetes, Async 오케스트레이션 등)에서 평가/관찰 데이터를 전체적으로 연결하려면 OTEL 기반 추적이 필요
- OTEL은 서비스/컨테이너 전반에 걸쳐, 전체 프로세스/콜 체인을 연결·추적·계측 가능하게 해주는 업계 표준 솔루션
- Arize는 2.5년 전부터 OTEL 최우선으로 베팅
평가 신뢰도 확보를 위한 Confidence Score 산출 방식 소개 (Logprobs·분류확률 등)
- OpenAI 등 최신 LLM 서비스는 로그확률(log probability score) 등으로 자동채점 Confidence Score를 제공
- Auto-regressive(생성형) 모델은 eval label별 logprob으로 신뢰도 추정 가능
- Encoder-only(분류형) 모델은 각 클래스별 확률값을 직접 제공함
- 실제 프로덕션 현장에서는 여러 평가 도구/모델을 조합해 신뢰도 축적
프롬프트 자동 최적화(DSPY, Meta-prompting 등)와 Loop 단축 등 최신 자동화 트렌드 사례 공유
- DSPY, MIRO 등 LLM 프롬프트·데이터셋 최적화 프레임워크 활용 사례 언급
- 여러 입력·출력·평가 결과(30쌍 데이터 등)와 실패 케이스 기반으로, 다양한 모델(OpenAI, Gemini 등)을 안정적으로 거치는 적응형 프롬프트 생성
- Meta-prompting: “입력·출력·평가 데이터셋+기존 프롬프트”를 통째로 LLM에게 전달해 자동으로 신규 프롬프트/개선안 제안 및 테스트
- Arize도 prompt optimization 및 meta-prompting 기능을 직접 서비스/개발 중임