에이전트 평가(Agent Evals)에 관한 가장 흔한 질문들, 답변

핵심 요약

• 평가(Evals)는 에이전트의 실행 결과에 점수를 매겨, 에이전트가 기대한 대로 동작하는지 확인할 수 있게 해줍니다. 시작하려면 하나의 동작을 선택하고, 실제 트레이스로 작은 데이터셋을 만들고, 베이스라인을 실행하세요. 출시 전에는 오프라인 평가를, 프로덕션에서는 온라인 평가를 사용하고, 새로운 실패 사례를 데이터셋 예제로 전환하세요.
• 가능한 곳에는 코드 평가기를 사용하고, 불가능한 곳에는 LLM 심판을 사용하며, 인간 검토로 이 둘을 모두 확인하세요. 여러 단계를 거치는 에이전트의 경우 전체 스레드, 궤적 및 최종 상태를 평가하십시오.
• Terminal-Bench와 같은 벤치마크는 더 긴 작업과 자체 환경을 갖춘 오프라인 평가입니다. Harbor가 이를 실행하고 결과를 LangSmith 실험에 기록합니다.

에이전트를 빌드하고 출시할 때, 개발 단계에서부터 실제 사용자가 이를 사용하기 시작한 이후까지 에이전트가 기대한 대로 작동하는지 확인할 방법이 필요합니다.

기존 소프트웨어에서는 동일한 입력이 동일한 출력을 만들어내므로 단위 테스트로 정확한 결과를 검증할 수 있습니다. 에이전트는 몇 가지 이유로 테스트가 더 어렵습니다:

• 출력은 실행할 때마다 다릅니다, 동일한 요청에 대해서도 마찬가지입니다
• 정답은 두 개 이상일 수 있습니다, 따라서 정확히 일치하는지 확인하는 것만으로는 부족합니다
• 에이전트가 자체 단계를 선택합니다, 따라서 올바른 출력이 '잘못된' 경로에서 나올 수도 있습니다. 예를 들어, 에이전트가 필요 없는 도구를 호출하거나 사용자의 허가 없이 어떤 조치를 취할 수 있습니다.

에이전트 평가(agent evals)가 해결책입니다. 에이전트 평가는 이러한 변동성을 고려하는 검증 항목으로 에이전트의 실행을 채점합니다. 평가 대상인 에이전트와 마찬가지로 이러한 테스트도 일률적인 것이 아니며, 최적의 평가 스위트는 팀, 팀의 제품, 그리고 팀이 최적화하려는 목표에 따라 달라집니다.

지난 몇 년간 작업하면서 LangSmith, LangChain의 에이전트 엔지니어링 플랫폼인 LangSmith를 운영하면서 저희 팀은 수많은 다양한 평가 관련 질문들을 접해 왔습니다. 이 블로그에서는 에이전트 평가를 시작하는 방법과 워크플로에서 사용할 수 있는 다양한 유형의 평가에 대해 가장 자주 묻는 질문들을 살펴봅니다.

어디서부터 시작해야 할까요?

모든 평가는 여러분의 에이전트가 실제로 무엇을 하는지 이해하는 것에서 시작됩니다. 트레이스(trace)는 에이전트의 한 번의 실행 기록으로, 입력, 출력 및 그 사이의 모든 모델 호출과 도구 호출을 포함합니다. 트레이스 샘플을 읽어 보면서 에이전트가 요청을 어떻게 처리하는지, 어디서 문제가 발생하는지 파악하세요. 발견한 내용이 무엇을 먼저 테스트할지 알려줍니다. 작게 시작하세요.

1. 관심 있는 동작 하나를 고르세요. 예를 들어, 여행 어시스턴트의 경우 사용자가 요청한 날짜와 가격 범위를 예약하는지 여부가 하나의 동작이 될 수 있습니다.
2. 트레이스로부터 작은 데이터셋을 만드세요. 데이터셋은 예시들의 모음이며, 각 예시는 입력과 보통 기대 출력을 갖춘 하나의 테스트 케이스입니다. 하나의 동작에 대해 10~20개의 예시면 시작하기에 충분하며, LangSmith에서는 트레이싱 뷰에서 바로 트레이스를 데이터셋에 추가할 수 있습니다. 아직 에이전트가 프로덕션에 배포되지 않았다면, 팀원들이나 신뢰할 수 있는 소수의 디자인 파트너에게 사용해 보도록 하고(도그푸딩) 그 트레이스를 바탕으로 작업하세요.
3. 베이스라인을 실행하세요. 현재 에이전트를 데이터셋에 대해 실행하고 결과를 실험(experiment)으로 저장하세요. 실험은 데이터셋에서 에이전트의 한 버전을 실행한 결과와 평가자(evaluator)의 점수를 포함합니다. 이후 에이전트 버전들의 성능을 이 실험과 비교하게 됩니다.
4. 새로운 실패 사례를 발견하는 대로 추가하세요. 테스트 중이나 프로덕션에서 발견하는 각각의 실패는 새로운 예시가 됩니다.

데이터셋에 실패 사례를 계속 추가하면 개선 루프가 만들어집니다. 실패를 찾아 데이터셋에 추가하고, 에이전트를 개선한 뒤 다시 실행하세요. 평가할 에이전트 동작을 더 많이 발견할수록 위와 동일한 패턴에 따라 평가 스위트를 확장하게 됩니다.

오프라인 평가와 온라인 평가의 차이점은 무엇인가요?

평가(Evals)는 변경 사항을 배포하기 전과 에이전트가 라이브로 운영된 후 모두 실행할 수 있으며, 그래야 합니다. 배포 전에는 평가를 통해 변경 사항이 에이전트를 더 좋게 만들었는지 더 나쁘게 만들었는지 알 수 있습니다. 배포 후에는 평가를 통해 에이전트가 실제 사용자와 함께 어떻게 수행되고 있는지 알 수 있습니다.

오프라인 평가 데이터셋을 대상으로 에이전트를 실행하세요 이전 변경 사항을 배포할 때 사용합니다. 예제 입력을 직접 선택하고, 기대 출력(참조 출력이라고도 함)을 포함할 수도 있습니다. 이 데이터셋을 사용하면 에이전트 버전 간에 실험 결과를 비교할 수 있습니다. 새로운 프롬프트, 모델 또는 도구를 테스트하고 사용자에게 도달하기 전에 회귀를 잡아내는 데 가장 유용합니다.

다음과 같은 벤치마크 Terminal-Bench 또한 오프라인 평가도 있는데, 이는 고정된 작업 집합을 기반으로 구축되어 에이전트, 모델 또는 버전을 비교할 수 있습니다. Harbor는 이를 실행하고 결과를 LangSmith 실험에 기록하며, 이에 대해서는 아래에서 더 자세히 다룹니다.

온라인 평가는 실제 프로덕션 트레이스에 점수를 매기며 들어오는 대로처리합니다. 비교할 참조 출력이 없는 경우가 보통이므로, 실행을 스스로 채점할 수 있는 코드 검사와 LLM 저지에 의존합니다. 온라인 평가는 품질을 모니터링하고 데이터셋이 놓친 문제를 찾는 데 가장 적합합니다.

두 가지 모두 필요하며, 서로를 보완합니다. 온라인 평가가 표시한 실패는 오프라인 데이터셋의 새로운 예시가 됩니다.

LangSmith에서 오프라인 평가를 위한 데이터셋을 구축하는 방법은 몇 가지가 있습니다. 처음부터 예시를 작성하거나, 기존 트레이스에서 실행을 추가하거나, 팀이 어노테이션 큐에서 검토한 실행을 보내거나, CSV 또는 JSONL 파일을 업로드하거나, 이미 가지고 있는 몇 가지 예시에서 합성 예시를 생성할 수 있습니다.

평가 스위트가 커짐에 따라 기존 데이터셋에 예제를 추가할지 아니면 새 데이터셋을 시작할지 결정해야 합니다. 경험상 다음과 같습니다:

• 예시는 다음에 유지하세요 동일한 데이터셋 같은 평가자로 동일한 행동을 테스트할 때, 실험이 시간이 지나도 비교 가능하게 유지됩니다.
• 생성합니다 새로운 데이터셋 입력이 다르게 보일 때(예: 단일 요청 vs 전체 대화), 다른 평가기가 필요할 때, 또는 데이터셋이 다른 목적을 수행할 때, 예를 들어 모든 풀 리퀘스트마다 실행하는 소규모 집합과 릴리스 전에 실행하는 대규모 집합이 다를 때입니다.

하나의 데이터셋 내에서 split을 사용하여 예시의 일부만 실행할 수도 있습니다.

에이전트 평가기에는 어떤 종류들이 있나요?

평가기(evaluator)는 실행(run)을 채점하는 로직입니다. 일반적으로 네 가지 유형이 있습니다. 대부분의 팀은 한두 개로 시작하여 시간이 지나면서 점점 더 추가합니다.

• 코드 평가자 예약된 가격이 사용자의 예산 이하인지 확인하는 것처럼 결정론적으로 사물을 검사합니다. 이들은 빠르고, 저렴하고, 일관성이 있지만, 결정론적인 입력과 출력이 필요하다는 점이 그 유용성을 제한합니다.
• LLM-as-a-judge 코드가 판별할 수 없는 것들, 예를 들어 어시스턴트의 응답이 항공편 세부 정보를 명확히 확인했는지 여부를 평가하는 데 모델을 사용합니다.
• 사람에 의한 검토 팀이나 해당 분야 전문가가 직접 점수를 매기도록 하세요. 속도는 느리지만 주관적 품질을 평가하고 다른 평가자들을 검증하는 데 가장 좋은 신호입니다. 흔히 더 작은 표본에 대해 사용되어 이후 LLM 평가자의 판단에 참고 자료로 활용됩니다.
• 쌍별 평가기 두 출력 결과를 나란히 비교하여 더 나은 것을 선택할 수 있으며, 이는 두 프롬프트나 모델 중에서 선택할 때 유용합니다.

이러한 평가기 중 하나는 에이전트 실행의 서로 다른 부분을 대상으로 지정할 수 있습니다. 평가는 다음을 점수화할 수 있습니다:

• 한 걸음. 예: Whether search_flights 올바른 날짜로 호출되었습니다.
• 최종 답변입니다. 예: 답변이 상담원이 실제로 예약한 항공편을 확인하는지 여부.
• 전체 대화. 예: 최종 예약이 사용자가 여러 차례에 걸쳐 요청한 모든 변경 사항을 반영하는지 여부
• 환경의 최종 상태. 예. 에이전트가 자체 컨테이너에서 실행된 후 목업(mock) 예약 시스템의 예약 기록. 벤치마크는 종종 이러한 설정을 사용하며, 이를 컨테이너화된 평가(containerized evals)라고 부르는 경우도 종종 들을 수 있습니다.

LLM 판정자를 신뢰할 수 있을까요?

LLM 저지는 코드로 확인하기 어려운 출력, 예를 들어 답변이 검색된 문서에 근거하는지 여부를 평가하는 데 모델을 활용합니다. 저지는 유연하지만 일관성이 없거나 팀의 판단과 어긋날 수 있습니다. 몇 가지 습관이 저지를 신뢰할 수 있게 만들어 줍니다:

• 판사를 인간 점수와 비교하십시오. 팀원 중 한 명이 실행 결과 샘플을 채점하고 판정 모델이 어디서 다른지 확인하세요. 일치할 때까지 판정 모델의 프롬프트나 예시를 조정하세요. 주석 대기열 LangSmith에서 이를 쉽게 해줍니다. 우리의 LLM-as-a-judge 문서 이에 대해 단계별로 안내해 드리겠습니다.
• 구체적인 좁은 질문을 하세요. 여행사 에이전트 예시에서 "이 답변이 모든 경유지를 언급하고 있는가?"라고 묻는 것은 "이 답변이 좋은 답변인가?"라고 묻는 것보다 판단하기 쉽습니다.
• 명확한 평점 척도를 정의하세요. 이진 통과/실패 방식이나 소수의 레이블이 지정된 범주는 1-10 척도로 점수를 매기는 것보다 훨씬 재현성이 높습니다. 평가자는 6점과 7점을 구분하는 데 어려움을 겪을 수 있습니다.

평가(evals)는 벤치마크와 같은 것인가요?

번치마크는 일련의 작업(task)으로 구성된 오프라인 평가의 한 유형입니다. 작업은 번치마크 내의 단일 테스트 케이스로, 지침, 컨테이너 내 환경, 그리고 결과를 채점하는 테스트 스크립트를 포함합니다. 에이전트가 더 유능해짐에 따라, 단순한 LLM 판정기나 코드 기반 평가만으로는 종종 충분하지 않습니다. 이제 에이전트는 코드를 실행하고, 파일을 편집하고, 서비스와 연동할 수 있습니다. 이러한 다단계 동작을 모델링하기 위해 번치마크는 컨테이너에 격리된 인프라를 구성합니다. 이를 통해 개발자는 에이전트가 프로덕션에서 작동하는 방식과 동일하게 에이전트 동작을 오프라인에서 테스트할 수 있습니다.

벤치마크는 더 단순한 LLM 저지(LLM judge)나 코드 기반 평가와 몇 가지 측면에서 다릅니다:

• 과제는 더 많은 단계를 포함합니다. 하나의 작업을 완료하기 위해 에이전트는 수십 번의 도구 호출에 걸쳐 패키지를 설치하고, 파일을 편집하고, 명령을 실행할 수 있습니다.
• 각 작업에는 환경이 함께 제공됩니다. 이제 에이전트가 코드 저장소, 파일, 도구가 있는 샌드박스 같은 환경에서 작업을 수행할 수 있습니다. 모든 작업에는 에이전트가 작업할 수 있는 자체 격리 환경이 함께 제공됩니다.
• 스코어링은 에이전트가 수행한 작업을 점검합니다. 테스트 스크립트는 실행 후 환경의 상태를 검사합니다. 예를 들어 테스트가 통과했는지 또는 올바른 파일이 존재하는지 여부입니다. 여전히 트레이스를 검토할 수 있지만, 점수는 에이전트가 수행한 행동과 그 행동으로 남겨진 상태에서 나옵니다.

우리 여행 어시스턴트의 경우, 벤치마크 작업은 에이전트에 모의 예약 시스템과 "폭풍우로 인해 여행자의 덴버행 항공편이 취소되었습니다. 항공편을 재예약하고 호텔도 이에 맞게 변경하십시오."와 같은 요청을 제공할 수 있습니다. 에이전트가 작업을 마치면 테스트 스크립트가 데이터베이스의 예약 기록을 확인합니다.

하버 는 이러한 긴 작업에 대한 테스트를 위한 스캐폴딩을 제공하는 오픈 소스 eval 하네스입니다. Terminal-Bench를 구동하는 프레임워크이며, 동일한 작업 형식을 사용해 자신만의 에이전트용 벤치마크를 만들 수 있습니다. LangSmith 통합을 통해 각 Harbor 실행은 LangSmith 실험으로 기록됩니다. Harbor는 각 작업에 대한 컨테이너를 빌드하며, LangSmith 트레이스를 사용해 각 환경을 에이전트가 프로덕션에서 마주하는 환경에 더 가깝게 만들 수 있습니다. 벤치마크 결과는 다른 평가들과 함께 표시되며, 모든 실행을 열어 점수 옆에서 전체 트레이스를 확인할 수 있습니다.

우리는 이 설정을 사용하여 Terminal-Bench 2.0에서 Deep Agents 성능 개선 트레이스를 검토하여 실패 모드를 찾은 다음 하네스를 변경하는 방식으로요. 또한 이를 활용하여 구축했습니다 IssueBench, LangSmith Engine의 벤치마크입니다. 각 IssueBench 작업은 Engine에 트레이스 배치를 제공하고, 올바른 것들을 올바른 이슈 클러스터로 그룹화하는지 평가합니다.

자신의 에이전트용 벤치마크를 구축하는 것은 위의 eval들과 동일한 단계를 따르되, 몇 가지 변경 사항이 있습니다:

• 트레이스에서 작업을 수집합니다. LangSmith 트레이스에서 오류를 찾은 뒤, 사용자의 예약 정보가 담긴 모의 예약 시스템과 같은 자체 환경을 갖춘 Harbor 작업으로 각 오류를 변환합니다.
• ‘좋음’이 무엇인지 정의하십시오. 루브릭에 따라 점수를 매기는 LLM 심사 모델이나 코드 기반 평가를 만드세요.
• 스코어(score) 위로의 언덕 등반. 에이전트를 실행하고 점수를 활용해 변경 사항을 A/B 테스트하세요. 이 과정을 자동으로 수행하는 에이전트 루프를 설정할 수 있습니다. 이 루프는 에이전트를 수정하고, 벤치마크를 다시 실행하며, 각 변경 사항을 유지하거나 되돌립니다. Andrej Karpathy의 방식과 유사합니다. autoresearch 몇 달 전의 루프입니다.

높은 비용 없이 프로덕션 트래픽을 어떻게 평가할 수 있을까요?

오프라인 평가는 고정된 데이터셋에서 실행되므로 비용을 예측할 수 있습니다. 반면 온라인 평가는 실시간 트래픽에서 실행되므로, LLM 판정기가 모든 트레이스를 채점하는 경우 새로운 사용자가 늘어날 때마다 평가 비용이 함께 증가합니다. 비용을 감당 가능한 수준으로 유지하려면:

• 샘플과 필터. 온라인 평가자 LangSmith에서는 트래픽의 일정 비율을 샘플링하거나, 부정적 사용자 피드백과 같은 필터에 일치하는 트레이스만 대상으로 채점할 수 있습니다.
• 가능한 곳에서는 코드 검사를 사용하세요. 예약이 요청된 날짜와 일치하는지, 에이전트가 예약 전에 검색을 했는지 확인하는 데에는 거의 비용이 들지 않습니다.
• 더 저렴한 심사 모델을 사용하세요. 우리의 Jev-as-a-Judge 실험에서 TypeSafe AI의 Jev는 모든 통과/실패 판정에서 인간의 라벨과 일치했으며 총 비용은 $0.34에 불과했던 반면, Claude Sonnet 4.6은 $28.17이 들었습니다.

온라인 평가 비용은 LangSmith에 시간이 지남에 따라 저장되므로 팀이 지출을 모니터링할 수 있습니다.

에이전트 평가(agent evals)를 직접 구축해야 할까요?

아니요, 특히 일반적인 에이전트 문제를 평가할 때는 그렇지 않습니다. 좋은 출발점은 우리의 LangSmith의 사전 구축된 LLM 평가기 템플릿 환각이나 PII 유출 같은 일반적인 검사용입니다. 데이터셋이나 트레이싱 프로젝트에 하나를 추가하고, 프롬프트를 여러분의 에이전트에 맞게 편집하세요. 예를 들어 판정자에게 여행 어시스턴트가 사용자의 예산을 초과해 예약해서는 안 된다고 알려줄 수 있습니다.

우리의 오픈 소스 agentevals 패키지에는 에이전트의 메시지와 도구 호출을 위한 사전 구축된 평가기도 포함되어 있습니다. 이를 통해 에이전트가 호출한 도구를 참조 목록과 비교하거나, LLM 판정자에게 단계가 타당했는지 물어볼 수 있습니다.

오프라인 평가기를 데이터셋 전반에 걸쳐 재사용하고 프로덕션 트레이스에서 온라인 평가기로 실행할 수도 있습니다(평가기가 참조 출력을 필요로 하지 않는 경우에만 작동합니다).

여러분의 에이전트에 특화된 평가의 경우, Eval Engineering Skill 은 Claude Code나 Codex 같은 코딩 에이전트에서 실행되며, 여러분의 저장소와 트레이스를 읽고 실행 가능한 평가를 함께 작성해 줍니다.

LangSmith Engine 은 프로덕션 트레이스에서 가져와 자동으로 평가를 작성할 수도 있습니다. 문제 클러스터를 식별하면, 실패한 트레이스를 데이터셋 예제로 변환하고 그 참조 출력을 “사용자가 요청한 날짜에 항공권을 예약한다” 같은 assertions로 작성합니다.

멀티턴 대화는 어떻게 평가하나요?

많은 에이전트가 여러 턴에 걸쳐 작동합니다. 예를 들어 사용자가 여행 어시스턴트에게 항공편을 문의한 뒤 날짜를 변경하고 호텔을 추가할 수 있습니다. 대화 전체가 잘못되었음에도 각 턴은 개별적으로는 괜찮아 보일 수 있습니다.

LangSmith에서 대화를 평가하려면 트레이스 메타데이터에 thread ID를 전달하여 각 턴이 하나의 스레드. 스레드(thread)는 동일한 대화의 트레이스(trace)들을 하나로 묶은 연속입니다. 여기서 대화가 끝난 뒤 스레드 전체를 평가하는 온라인 평가자(evaluator)를 붙일 수 있으며, "최종 예약이 사용자가 요청한 모든 변경 사항을 반영했는가?" 또는 "사용자가 같은 말을 반복해야 했는가?" 같은 질문을 사용할 수 있습니다. LangSmith는 또한 각 스레드를 하나의 궤적, 모든 메시지와 도구 호출이 순서대로 한 번씩 나열됩니다.

오프라인 평가의 경우 전체 대화를 데이터셋의 예시로 저장하거나, LLM으로 사용자를 시뮬레이션하여 에이전트가 대화를 처음부터 끝까지 어떻게 처리하는지 테스트할 수 있습니다.

최종 결과물 너머에서 에이전트를 어떻게 평가할 수 있을까요?

에이전트는 여러 단계를 거치므로 최종 답변에는 실제로 일어난 일의 일부만 표시됩니다. 최종 응답 외에 다음을 확인해 보고 싶을 수 있습니다:

• 경로, 즉 에이전트가 생성한 메시지와 도구 호출의 연속을 의미합니다.
• 최종 상태여행사가 생성한 예약 기록, 에이전트가 작성한 파일, 또는 에이전트가 저장소(repo)에 가한 변경 사항 같은 것들 말입니다.

프로덕션 에이전트가 점점 더 복잡해질수록 전용 평가 하네스가 필요할 수 있습니다. 특히 에이전트의 작업이 환경에 가하는 변경 자체일 때 그렇습니다. 코딩 에이전트에게 버그 수정을 요청했다고 가정해 봅시다. LLM 판정기는 에이전트의 응답을 읽을 수 있지만, 신뢰할 수 있는 확인 방법은 에이전트가 작업을 마친 후 저장소의 테스트를 실행하는 것입니다. 이것이 작동하려면 각 테스트 실행이 서로에게 영향을 주지 않도록 저장소의 깨끗한 사본을 각각 따로 가져야 합니다. Harbor가 이 설정을 대신 해줍니다. 다음으로 만들어진 에이전트를 실행할 수 있습니다. 딥 에이전트(Deep Agents) 안에서 LangSmith Sandboxes 그리고 각 실행과 해당 트레이스를 LangSmith 실험에 기록합니다. 자세한 내용은 다음에서 확인하세요. Harbor x LangChain.

LangChain, LangGraph 또는 Deep Agents를 사용해 구축되지 않은 에이전트도 LangSmith에서 추적하고 평가할 수 있습니까?

네! LangSmith는 프레임워크에 구애받지 않으므로, 어떤 프레임워크로 빌드된 에이전트든 프레임워크 없이 빌드된 에이전트조차도 추적하고 평가할 수 있습니다. 트레이스를 전송하는 방법에는 몇 가지가 있습니다:

• 프레임워크 통합. LangSmith는 통합 다음과 같은 인기 있는 에이전트 프레임워크를 위한 OpenAI Agents SDK, Claude Agent SDK, 그리고 그 외 더 많은 내용.
• 모델 제공자 래퍼. 모델 제공자를 직접 호출하는 경우, OpenAI 또는 Anthropic 그리고 각 모델 호출은 추적됩니다.
• The @traceable 데코레이터입니다. 여행 어시스턴트의 항공편 검색 도구처럼 자신만의 함수에 추가하여 모든 단계를 추적 당신의 에이전트의.

트레이스가 LangSmith에 들어오면 evals는 어떤 프레임워크에서도 동일한 방식으로 작동합니다. 데이터셋에 트레이스를 추가하고, 에이전트를 다음에 전달하여 오프라인 실험을 실행할 수 있습니다. SDK의 evaluate() 기능을 수행하고, 온라인 평가기를 프로덕션 트래픽에 연결합니다.

기존 eval 스택에서 어떻게 벗어나나요?

처음부터 다시 시작할 필요는 없습니다. 이미 구축한 대부분의 것은 LangSmith로 그대로 가져올 수 있습니다:

• 데이터셋. 기존 테스트 케이스를 CSV 또는 JSONL 파일로 업로드하거나, SDK로 생성할 수 있습니다.
• 코드 평가기. 기존 채점 함수는 보통 약간의 수정만으로 LangSmith 평가기로 실행할 수 있습니다. eval이 이미 테스트로 실행되고 있다면 pytest 및 Vitest 통합을 통해 해당 설정을 그대로 유지할 수 있습니다.
• LLM 판정자. 기존 판정자 프롬프트를 UI의 LLM-as-a-judge 평가기에 붙여넣거나, 코드에 그대로 둘 수 있습니다.
• 트레이싱. LangSmith는 모든 프레임워크와 호환되므로, 에이전트를 다시 작성하지 않고도 현재 에이전트에서 트레이스를 보낼 수 있습니다.

결과는 어떻게 보고하나요?

오프라인 실험은 각 릴리스가 개선되었는지를 보여줍니다. 온라인 eval 대시보드는 프로덕션에서 성능이 시간이 지남에 따라 어떻게 유지되는지 보여줍니다. LangSmith에서는 실험 결과를 직접 비교하고, 토큰 비용, 지연 시간, 평가기 점수 등의 지표에 대한 시간별 커스텀 대시보드를 만들 수 있습니다. 벤치마크는 릴리스 전반에 걸쳐 모델이나 에이전트 버전을 비교할 수 있는 안정적인 점수를 제공합니다.

다음

더 깊이 알고 싶다면 다음을 읽어보세요 딥 에이전트용 평가(Evals)를 구축하는 방법, 다음을 시도해 보세요 LangSmith 평가 퀵스타트, 또는 LangChain Academy의 강좌를 확인하세요: LangSmith Essentials.

라이브 강사를 선호하시나요? 2026년 10월 28일에 에이전트 평가에 관한 가상 워크숍을 진행할 예정입니다. 등록 여기!