Quickly Start Evaluating LLMs With OpenEvals
Quick Summary
LangChain 팀은 LLM 애플리케이션과 에이전트를 프로덕션 수준으로 평가하기 쉽게 하기 위해 openevals와 agentevals를 공개하고, 데이터·평가지표·평가 유형별 출발점을 제시한다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
LangChain 팀은 LLM 애플리케이션과 에이전트를 프로덕션 수준으로 평가하기 쉽게 하기 위해 openevals와 agentevals를 공개하고, 데이터·평가지표·평가 유형별 출발점을 제시한다.
📌 핵심 요약
- LLM 기반 애플리케이션과 에이전트를 안정적으로 운영하려면 평가가 중요하지만, 처음부터 평가 체계를 만드는 일은 어렵기 때문에 openevals와 agentevals가 공통 프레임워크와 사전 구축된 평가기를 제공한다.
- 평가는 평가 대상 데이터와 평가 기준인 메트릭으로 구성되며, 실제 사용을 잘 반영하려면 특정 사용 사례에 맞는 고품질 데이터셋을 먼저 큐레이션해야 한다.
- openevals는 LLM-as-a-judge 평가를 쉽게 커스터마이즈하도록 돕고, 자연어 응답 품질·환각 여부·글쓰기 일관성 등을 평가하는 데 사용할 수 있는 프롬프트, few-shot 예시, 점수 스키마, 근거 코멘트를 제공한다.
- 구조화 데이터 평가는 문서나 이미지에서 추출한 정보, JSON 같은 정형 출력, 도구 호출 파라미터, 특정 형식 준수 여부를 확인하는 데 쓰이며, exact match 또는 LLM-as-a-judge 방식으로 검증할 수 있다.
- agentevals는 에이전트의 최종 답변뿐 아니라 도구 호출 순서와 LangGraph 노드 실행 흐름 같은 궤적을 평가하도록 지원하며, LangSmith는 이러한 평가 결과를 시간에 따라 추적하고 팀과 공유하는 도구로 제안된다.
🧩 주요 포인트
- LLM 기반 애플리케이션과 에이전트를 안정적으로 운영하려면 평가가 중요하지만, 처음부터 평가 체계를 만드는 일은 어렵기 때문에 openevals와 agentevals가 공통 프레임워크와 사전 구축된 평가기를 제공한다.
- 평가는 평가 대상 데이터와 평가 기준인 메트릭으로 구성되며, 실제 사용을 잘 반영하려면 특정 사용 사례에 맞는 고품질 데이터셋을 먼저 큐레이션해야 한다.
- openevals는 LLM-as-a-judge 평가를 쉽게 커스터마이즈하도록 돕고, 자연어 응답 품질·환각 여부·글쓰기 일관성 등을 평가하는 데 사용할 수 있는 프롬프트, few-shot 예시, 점수 스키마, 근거 코멘트를 제공한다.
- 구조화 데이터 평가는 문서나 이미지에서 추출한 정보, JSON 같은 정형 출력, 도구 호출 파라미터, 특정 형식 준수 여부를 확인하는 데 쓰이며, exact match 또는 LLM-as-a-judge 방식으로 검증할 수 있다.
- agentevals는 에이전트의 최종 답변뿐 아니라 도구 호출 순서와 LangGraph 노드 실행 흐름 같은 궤적을 평가하도록 지원하며, LangSmith는 이러한 평가 결과를 시간에 따라 추적하고 팀과 공유하는 도구로 제안된다.
🧠 상세 정리
1. 평가가 필요한 이유와 새 패키지의 목적
글은 LLM 기반 애플리케이션이나 에이전트를 프로덕션에 올리기 위해 평가가 필수적이라고 말하며 시작한다. 하지만 평가를 처음부터 설계하려면 어디서 출발해야 하는지 알기 어렵다는 문제가 있다. 이를 해결하기 위해 LangChain 팀은 openevals와 agentevals라는 새 패키지를 제시한다. 두 패키지는 바로 사용할 수 있는 평가기와 공통 프레임워크를 제공해, 개발자가 빈 화면에서 평가 체계를 만들지 않고도 일반적인 평가 패턴과 모범 사례를 따라 시작할 수 있게 하는 데 초점을 둔다.
2. evals의 두 구성요소: 데이터와 메트릭
원문은 평가를 애플리케이션에 중요한 기준에 따라 LLM 출력 품질을 체계적으로 판단하는 방법으로 정의한다. 평가에는 두 가지 핵심 구성요소가 있는데, 하나는 평가에 사용할 데이터이고 다른 하나는 그 데이터 위에서 적용할 메트릭이다. 평가 데이터의 품질과 다양성은 평가 결과가 실제 사용 상황을 얼마나 잘 반영하는지를 직접 좌우한다. 따라서 평가를 만들기 전에 특정 사용 사례에 맞는 데이터셋을 큐레이션하는 시간이 필요하며, 시작 단계에서는 소수의 고품질 데이터 포인트만으로도 충분하다고 설명한다.
3. 공통 평가 유형과 라이브러리의 접근 방식
글은 평가 유형이 많지만, 우선 가장 자주 쓰이고 실용적인 평가 기법에 초점을 맞췄다고 설명한다. 접근 방식은 크게 두 가지다. 첫째, 폭넓게 적용 가능한 평가기를 쉽게 커스터마이즈할 수 있도록 하는 것으로, 여기에는 LLM-as-a-judge 평가가 포함된다. 둘째, 특정 사용 사례에 맞는 기성 평가기를 제공하는 것으로, openevals와 agentevals는 문서에서 구조화 콘텐츠를 추출하는 경우, 도구 호출을 관리하는 경우, 에이전트 궤적을 평가하는 경우를 다룬다. 향후에는 RAG 애플리케이션이나 멀티 에이전트 아키텍처처럼 애플리케이션 유형별 더 구체적인 평가 기법도 확장할 계획이라고 밝힌다.
4. LLM-as-a-judge 평가의 용도와 지원 기능
LLM-as-a-judge 평가기는 LLM을 사용해 애플리케이션의 출력을 점수화하는 방식이다. 원문은 이 방식이 자연어 출력을 평가할 때 가장 흔히 쓰이는 평가 유형이라고 설명한다. 챗봇 응답의 대화 품질, 요약이나 질의응답 시스템의 환각 여부, 글쓰기 품질과 일관성을 평가할 때 사용할 수 있다. 중요한 특징으로는 정답 데이터 없이도 응답을 판단할 수 있는 reference-free 평가가 가능하다는 점이 언급된다. openevals는 커스터마이즈 가능한 사전 제작 프롬프트, 인간 선호에 더 잘 맞추기 위한 few-shot 예시, 일관된 평가를 위한 점수 스키마 설정, 특정 점수가 나온 이유를 설명하는 근거 코멘트 생성을 지원한다.
5. 구조화 데이터 평가의 필요성과 방식
많은 LLM 애플리케이션은 문서에서 구조화된 출력을 추출하거나 도구 호출을 위해 정형 데이터를 생성한다. 이런 경우 모델 출력이 미리 정의된 형식을 따르는지가 중요하다. 원문은 PDF, 이미지, 기타 문서에서 추출한 구조화 정보, 일관된 형식의 JSON 같은 정형 출력, API 호출 같은 도구 호출 파라미터, 특정 형식이나 범주에 맞아야 하는 출력을 평가 대상으로 든다. openevals는 이런 구조화 출력을 exact match 방식으로 검증하거나 LLM-as-a-judge를 사용해 확인할 수 있게 한다. 또한 feedback key별 점수를 집계해 평가기 성능을 높은 수준에서 볼 수 있는 기능도 제공한다고 설명한다.
6. 에이전트 궤적 평가와 LangSmith 기반 추적
에이전트를 만들 때는 최종 출력만 보는 것으로 충분하지 않고, 에이전트가 어떤 과정을 거쳐 결과에 도달했는지도 이해해야 한다. 궤적 평가는 에이전트가 작업을 완료하기 위해 취한 행동의 순서를 평가한다. 도구 선택이나 도구 사용 순서, LangGraph 애플리케이션의 실행 흐름을 확인할 때 사용할 수 있다. agentevals의 Agent Trajectory는 에이전트가 올바른 도구를 호출했는지, 필요하면 엄격한 순서까지 지켰는지를 확인하거나 LLM-as-a-judge로 궤적을 평가하게 한다. LangGraph 사용자는 Graph Trajectory를 통해 올바른 노드가 호출됐는지 확인할 수 있으며, 평가 결과를 장기적으로 추적하고 팀과 공유하려면 LangSmith에 기록하는 방식을 권장한다.
7. 향후 확장과 커뮤니티 참여 요청
글의 마지막 부분은 openevals와 agentevals가 평가 모범 사례를 코드화하려는 지속적인 노력의 시작점이라고 정리한다. 앞으로 몇 주 동안 더 많은 공통 사용 사례를 위한 구체적인 평가기와 에이전트 테스트용 평가기를 추가할 예정이라고 밝힌다. 또한 사용자가 보고 싶은 평가기가 있다면 openevals와 agentevals GitHub 저장소에 이슈를 열어 달라고 요청한다. 이미 애플리케이션에서 잘 작동한 평가기를 개발한 경우에는 커뮤니티와 공유할 수 있도록 pull request도 환영한다고 말한다. 이는 라이브러리가 고정된 완성품이라기보다 실제 사용 패턴을 바탕으로 확장하려는 공개 프로젝트임을 보여준다.
🧾 핵심 주장 / 시사점
- 평가 설계의 출발점은 거대한 데이터셋이 아니라, 사용 사례를 잘 대표하는 소수의 고품질 데이터와 명확한 메트릭을 먼저 갖추는 것이다.
- LLM-as-a-judge는 자연어 품질 평가를 빠르게 시작하게 해주지만, 원문은 사전 프롬프트를 그대로 쓰기보다 few-shot 예시와 점수 스키마로 사용 사례에 맞게 조정하는 흐름을 강조한다.
- 에이전트 평가에서는 최종 답변만으로는 충분하지 않으며, 어떤 도구와 노드를 어떤 순서로 호출했는지까지 확인해야 실제 동작 신뢰성을 판단할 수 있다.
✅ 액션 아이템
- LLM 기반 서비스 품질 관리를 위해 openevals와 agentevals 기반의 평가 파이프라인을 공통 구조로 정리한다.
- 평가 설계 단계에서 사용 사례별 고품질 데이터를 먼저 큐레이션하고 메트릭·점수 스키마를 함께 맞춰 기준선을 구축한다.
- 자연어 응답은 LLM-as-a-judge로 환각·일관성 점수를 얻고, 구조화 출력은 exact match와 함께 LangSmith로 시간 추세를 점검한다.
❓ 열린 질문
- LLM-as-a-judge가 유리한 평가 항목과 exact match가 유리한 항목은 어떤 기준으로 구분해야 하는가?
- 에이전트의 최종 답변뿐 아니라 도구 호출 순서와 LangGraph 노드 흐름은 어느 구간에서 별도 점검 기준을 둘 것인가?
- 사용 사례별 고품질 데이터셋의 범위는 어느 수준이 되어야 성능 편차를 신뢰성 있게 반영할 수 있는가?