Sharing LangSmith Benchmarks

🖼️ 인포그래픽

Sharing LangSmith Benchmarks 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

LangChain 팀은 LangSmith에서 평가 데이터셋·결과·실행 트레이스를 공유하고, LangChain 문서 Q&A 벤치마크와 langchain-benchmarks 패키지로 LLM 애플리케이션 아키텍처를 재현·비교할 수 있게 했다고 설명한다.

📌 핵심 요약

글은 LLM 앱을 프로덕션으로 가져갈 때 개발자들이 가장 크게 겪는 어려움이 테스트와 평가이며, 새로운 모델·검색 기법·에이전트 유형·인지 아키텍처가 빠르게 등장하면서 이 문제가 더 심해졌다고 진단한다.
LangSmith는 기존의 테스트 비교 뷰와 데이터셋 큐레이션에 더해 평가 데이터셋과 결과를 공유할 수 있게 하며, 단순한 최종 점수뿐 아니라 각 평가 결과에 포함된 전체 실행 트레이스를 공개해 세부 동작을 검토할 수 있게 한다.
첫 공개 벤치마크는 LangChain 파이썬 문서 기반 Q&A 데이터셋으로, 여러 문서의 정보를 논리적으로 종합해야 하거나 질문이 문서 지식과 충돌하는 상황에서 RAG 시스템이 올바르게 답하는지 시험하도록 설계됐다.
새로운 langchain-benchmarks 패키지는 사용자가 자신의 아키텍처를 같은 데이터셋에서 실험하고, LLM·프롬프트·인덱싱 기법·도구 구성의 성능과 트레이드오프를 빠르게 비교하도록 돕는다.
초기 결과에서는 대화형 검색 체인, 에이전트, OpenAI Assistant API를 비교했으며, 자동 지표와 수동 검토를 함께 사용해 정확도, 코사인 거리, 환각, 검색 문서 관련성, 문서 순서 같은 실패 원인을 분석하는 흐름을 보여준다.

🧩 주요 포인트

글은 LLM 앱을 프로덕션으로 가져갈 때 개발자들이 가장 크게 겪는 어려움이 테스트와 평가이며, 새로운 모델·검색 기법·에이전트 유형·인지 아키텍처가 빠르게 등장하면서 이 문제가 더 심해졌다고 진단한다.
LangSmith는 기존의 테스트 비교 뷰와 데이터셋 큐레이션에 더해 평가 데이터셋과 결과를 공유할 수 있게 하며, 단순한 최종 점수뿐 아니라 각 평가 결과에 포함된 전체 실행 트레이스를 공개해 세부 동작을 검토할 수 있게 한다.
첫 공개 벤치마크는 LangChain 파이썬 문서 기반 Q&A 데이터셋으로, 여러 문서의 정보를 논리적으로 종합해야 하거나 질문이 문서 지식과 충돌하는 상황에서 RAG 시스템이 올바르게 답하는지 시험하도록 설계됐다.
새로운 langchain-benchmarks 패키지는 사용자가 자신의 아키텍처를 같은 데이터셋에서 실험하고, LLM·프롬프트·인덱싱 기법·도구 구성의 성능과 트레이드오프를 빠르게 비교하도록 돕는다.
초기 결과에서는 대화형 검색 체인, 에이전트, OpenAI Assistant API를 비교했으며, 자동 지표와 수동 검토를 함께 사용해 정확도, 코사인 거리, 환각, 검색 문서 관련성, 문서 순서 같은 실패 원인을 분석하는 흐름을 보여준다.

🧠 상세 정리

1. 프로덕션 LLM 앱에서 평가가 가장 큰 병목

글은 개발자들이 LLM 애플리케이션을 실제 서비스로 가져갈 때 가장 크게 호소하는 문제가 테스트와 평가라고 시작한다. 이 어려움은 단순히 모델을 한 번 고르는 문제가 아니라, 새로운 모델, 검색 방식, 에이전트 유형, 인지 아키텍처가 계속 등장하기 때문에 더 복잡해진다. LangChain 팀은 지난 몇 달 동안 LangSmith를 LLM 아키텍처 평가에 적합한 장소로 만들기 위해 테스트 비교 뷰와 데이터셋 큐레이션 기능을 발전시켜 왔다고 설명한다. 이번 발표의 핵심은 평가 데이터셋과 결과를 공유할 수 있게 만들어, 커뮤니티 기반 평가와 벤치마크를 더 쉽게 하려는 것이다.

2. LangSmith의 공유 평가와 전체 트레이스 공개

LangSmith의 테스트 공유 기능은 같은 작업 집합에서 여러 아키텍처가 어떻게 수행되는지에 대한 데이터와 지표를 공개할 수 있게 한다. 여기서 중요한 점은 최종 결과나 집계 점수만 기록하는 것이 아니라, 각 평가 결과에 해당 체인의 전체 트레이스가 함께 포함된다는 점이다. 사용자는 평균 점수나 시스템 출력만 보는 데서 멈추지 않고, 동일한 데이터 포인트에 대해 서로 다른 시스템이 어떤 단계로 실행됐는지 확인할 수 있다. 이 접근은 성능 차이가 어디에서 비롯됐는지, 검색 단계인지 응답 생성 단계인지, 혹은 프롬프트나 문서 구성 문제인지 추적하는 데 초점을 둔다.

3. 공개 벤치마크가 필요한 배경

원문은 LLM 기반 개발 도구와 모델 품질이 지난 1년 동안 매우 빠르게 개선됐고, 매주 새로운 프롬프트 기법과 구성 방식이 제안된다고 설명한다. LangChain 커뮤니티도 chain of density, step-back prompting, 고급 RAG 기법, RL chains, generative agents, BabyAGI 같은 다양한 구현을 다뤄 왔다. 구조화 생성 영역에서도 emotion prompting 같은 방식에서 function calling과 grammar-based sampling 같은 API 및 샘플링 기법으로 변화가 있었다. 그러나 새로운 방식이 많아질수록 실제 애플리케이션에서 무엇이 성능 향상으로 이어지는지, 각 기법이 어떤 트레이드오프를 갖는지 판단하기는 더 어려워진다.

4. 일반 모델 벤치마크와 애플리케이션 평가의 차이

글은 HELM이나 EleutherAI의 Test Harness 같은 공개 벤치마크가 일반 작업에서 언어 모델을 평가하는 데 좋은 선택지라고 인정한다. 또한 AnyScale의 LLMPerf 벤치마크는 LLM 추론 속도와 처리량을 측정하는 데 유용한 지표가 될 수 있다고 언급한다. 다만 이런 도구들은 모델 자체의 기본 능력을 비교하는 데 뛰어나지만, 특정 사용자의 애플리케이션 안에서 모델이 실제로 어떻게 행동하는지를 반드시 반영하지는 않는다. LangSmith의 평가와 트레이싱 경험은 관련 데이터셋에서 레퍼런스 아키텍처의 성능 특성을 보고, 집계 수준과 샘플 수준 모두에서 접근 방식을 비교하도록 설계됐다.

5. 첫 벤치마크: LangChain 문서 Q&A 데이터셋

첫 번째로 포함된 벤치마크 작업은 LangChain 문서에 대한 Q&A 데이터셋이다. 이 데이터셋은 LangChain 파이썬 문서를 바탕으로 직접 작성한 질문과 답변 쌍으로 구성되며, RAG 시스템이 정확히 답할 수 있는지를 시험하도록 만들어졌다. 질문은 하나의 문서에서 답을 찾는 단순한 형태에만 머물지 않고, 여러 문서의 정보를 종합해야 하거나 질문이 문서의 지식과 충돌하는 경우도 포함한다. 초기 공개에서는 OpenAI, Anthropic, 오픈소스 모델처럼 사용한 언어 모델이 다른 구현과, 대화형 검색 체인과 에이전트처럼 인지 아키텍처가 다른 구현들을 평가했다.

6. langchain-benchmarks 패키지의 역할

LangChain 팀은 사용자가 자신의 아키텍처를 Q&A 데이터셋에서 실험할 수 있도록 langchain-benchmarks 패키지를 공개한다고 설명한다. 이 패키지는 LLM으로 애플리케이션을 만들 때 중요한 기능을 실험하고 벤치마킹하기 쉽게 하는 것을 목표로 한다. 원문은 질의응답뿐 아니라 추출, 에이전트 도구 사용, 검색 기반 질문 답변 같은 작업을 위한 벤치마크도 언급한다. 각 데이터셋마다 서로 다른 LLM, 프롬프트, 인덱싱 기법, 기타 도구 구성을 쉽게 테스트할 수 있게 하여, 설계 결정의 트레이드오프를 빠르게 비교하고 애플리케이션에 맞는 해법을 선택하도록 돕는다.

7. 단순 RAG, 에이전트, Assistant API 비교

초기 벤치마크는 대화형 검색 체인, 에이전트, Assistant API를 포함한 여러 템플릿을 대상으로 진행됐다. 대화형 검색 체인 실험에서는 입력 질문을 OpenAI의 text-embedding-ada-002로 임베딩하고, ChromaDB 벡터스토어에서 의미 유사도 기준으로 가장 관련 있는 문서 네 개를 검색한 뒤, Mistral 7B, Zephyr 7B Beta, GPT-3.5, GPT-4, Claude 2 등이 답변을 생성했다. 이 구성에서는 검색기가 동일하므로 결과 차이는 주로 검색된 데이터를 모델이 추론하고 답변으로 구성하는 능력에서 비롯된다고 설명한다. 에이전트 실험은 같은 검색기를 하나의 도구로 제공하고, 모델이 직접 응답하거나 필요한 만큼 검색 도구를 호출할 수 있게 했으며, 실제로는 대체로 한 번 도구를 호출한 뒤 답하는 경향이 있었다.

8. 평가 지표와 결과 해석

원문은 각 구성의 결과를 자동 지표로 비교할 수 있다고 설명하며, 예측 응답과 기준 응답 사이의 코사인 거리와 LangChain의 LLM 기반 scoring evaluator로 계산한 정확도 점수를 사용했다. 정확도 점수는 높을수록 좋고, 코사인 거리는 낮을수록 좋다고 명시한다. 표에서는 Assistant API 기반 구성인 openai-assistant가 테스트 중 가장 높은 성능을 얻었다고 설명한다. 또한 오픈소스 모델들은 이 실험에서 별도의 추가 프롬프트 엔지니어링 없이 독점 API들의 집계 성능을 따라잡지는 못했지만, 글은 이 차이를 단순 순위로만 보지 않고 구체적인 실패 사례를 들여다보는 것이 중요하다고 강조한다.

9. 트레이스를 통한 오류 진단과 개선 방향

결과 검토 부분은 LangSmith의 비교 뷰가 모델 동작을 수동으로 검토하고 아키텍처나 평가 방식을 조정하는 데 어떻게 쓰이는지 보여준다. 예시로 Mistral 7B 기반 RAG와 GPT-3.5 기반 RAG를 비교하면서, 어떤 질문에서는 두 모델 모두 정답을 내지 못했고 특히 GPT-3.5는 존재하지 않는 LangChain 자바 SDK 링크를 만들어내는 환각을 보였다고 설명한다. 트레이스를 확인하자 검색된 문서들이 원래 질문과 관련성이 낮았고, 이런 경우에는 검색기를 개선하거나 모델이 검색된 내용에 근거해 답하도록 시스템 프롬프트를 보강할 수 있다고 제안한다. 또 다른 사례에서는 Mistral이 덜 관련 있는 다섯 번째 문서의 내용에 과도하게 영향을 받았고, 플레이그라운드에서 문서 순서를 바꾸자 올바른 답이 나와 입력 문서 순서 조정이 개선 가설이 될 수 있음을 보여준다.

🧾 핵심 주장 / 시사점

이 글의 핵심은 벤치마크를 모델 순위표로만 쓰지 말고, 데이터셋·지표·트레이스를 함께 공개해 실패 원인을 재현 가능한 방식으로 분석하자는 데 있다.
RAG 성능은 모델 자체 능력뿐 아니라 검색 문서의 관련성, 검색 질의 생성 방식, 문서 순서, 프롬프트 제약에 크게 좌우되며, 집계 점수만으로는 이런 원인을 충분히 설명하기 어렵다.
LangSmith의 공유 평가 기능과 langchain-benchmarks 패키지는 빠르게 늘어나는 LLM 아키텍처 선택지를 실제 애플리케이션 맥락에서 비교하려는 개발자에게 실험 기반 의사결정 도구로 제시된다.