Jev가 LangSmith Evals에서 사용 가능해졌습니다

Jev는 이제 LangSmith의 평가(evaluations)를 위한 심사위원(judge)으로 사용할 수 있습니다. Jev는 팀들이 개방형 에이전트 동작을 빠르고 저렴하게 평가하고, 그 결과를 LangSmith에서 추적할 수 있는 구조화된 피드백으로 변환하는 방법을 제공합니다.

아래에서는 왜 Jev와 같은 System One 모델이 에이전트 평가에 유용한지 설명하고, 우리가 테스트했을 때 발견한 내용과, 온라인 평가를 위해 Jev-as-a-judge 평가자 설정 과정을 안내해 드립니다.

어떤 트레이싱 프로젝트의 Evaluators 탭에서든 오늘 LangSmith에서 Jev-as-a-judge를 사용해 보세요.

에이전트 평가의 간략한 역사

2023년에 우리가 처음 에이전트를 구축하기 시작했을 때(당시에는 주로 LLM 앱이라고 불렀습니다), 평가의 주된 접근 방식은 코드 기반이었습니다. 같은 해에 연구원들은 LLM-as-a-judge를 도입했고, 그 이후로 코드 기반과 LLM-as-a-judge가 에이전트를 평가하는 두 가지 주요 방법이 되었습니다.

코드 기반 평가자는 특정하고 결정론적인 조건(deterministic conditions)을 확인합니다. 에이전트가 도구를 호출했는지? 출력이 패턴과 일치하는지? 필드가 존재하는지? 이는 빠르고 신뢰성이 높지만, 에이전트가 실행되기 전에 완전히 지정할 수 있는 좁은 범위의 에이전트 동작만을 다룹니다. 에이전트는 비결정론적(non-deterministic)이기 때문에, 동일한 문제를 세 가지 다른 유효한 방식으로 해결하는 에이전트는 그중 하나만 예상하는 코드 기반 검사에서는 실패하게 됩니다.

LLM-as-a-judge 평가자는 이러한 격차를 메워줍니다. 사용자는 LLM 심사위원에게 에이전트 트레이스(agent trace)와 함께 지침 및 채점 기준표(rubric)를 제공하고, 이는 자유 형식 텍스트로 트레이스를 추론한 다음 판결을 내립니다. 하지만 이러한 유연성은 대가를 치릅니다. LLM-as-a-judge 평가자는 함수 호출보다 실행 속도가 느리고 비용이 많이 들며, 비결정론적이기 때문에 동일한 입력이라도 실행할 때마다 다른 판결을 내릴 수 있습니다. 게다가, 자유 형식 텍스트를 구조화된 출력으로 변환하는 단계 자체가 심사위원의 추론이 정확했는지 여부와는 별개로 오류의 원인이 될 수 있습니다.

이제 Jev와 같은 System One 모델은 세 번째 유형의 에이전트 평가를 도입합니다. 이 방식은 코드 기반 평가가 가진 속도를 일부 포기하는 대신, LLM 심사위원(judge) 비용의 극히 일부만으로 개방형(open-ended) 에이전트 동작을 평가할 수 있는 유연성을 제공합니다.

Jev란 무엇인가?

Jev는 전통적인 LLM이 아니며 텍스트를 생성하지 않습니다. TypeSafe AI 팀은 이를 System One 모델이라고 부릅니다:

📖 System One 모델이란 소프트웨어가 직접 사용할 수 있도록 빠르고 구조화된 결정을 내리도록 구축된 유형의 AI 모델입니다. System One 모델은 상태(state)를 평가하고, 타입이 지정된 답변과 확률을 반환합니다.

평가(evals)의 경우, 이 상태는 에이전트 추적(agent trace), 단일 메시지 또는 평가하고자 하는 다른 모든 컨텍스트가 될 수 있습니다. 질문은 응답이 PII를 유출했는지 여부, 사용자의 의도가 무엇이었는지 등 상태에 대해 평가하고 싶은 기준을 정의합니다.

비용은 팀들이 자사 에이전트를 원하는 만큼 평가하지 못하게 만드는 흔한 이유입니다. 모든 평가는 트레이드오프를 수반합니다: 더 많은 에이전트 실행을 점수화하거나, 더 많은 기준을 평가하거나, 더 많은 변경 사항을 테스트해야 하며, 테스트 비용은 비례하여 증가합니다. 여러 에이전트와 높은 사용량을 가진 경우, 평가당 몇 센트가 드는 LLM judge는 프로덕션 트래픽, 대규모 데이터셋, 그리고 모든 모델이나 프롬프트 변경에 대한 회귀 테스트를 거치면서 빠르게 비싸집니다. 팀들은 비용을 관리하기 위해 더 적은 평행을 실행하게 되고, 이는 훌륭한 에이전트를 구축하는 데 필수적인 피드백 루프를 늦춥니다. Jev judge는 그보다 훨씬 낮은 비용으로 이러한 트레이드오프를 제거할 수 있습니다.

Jev-as-a-judge를 사용하면 샘플 대신 모든 트레이스를 점수화하고, 트레이스당 더 많은 기준을 확인하며, 같은 판단을 반복적으로 실행하여 judge의 일관성을 확인할 수 있습니다. judge가 저렴할수록 에이전트의 행동을 평가할 수 있는 범위가 넓어지고, 그 에이전트 개선 루프는 더욱 단단해집니다.

속도는 라이브 트래픽에서 judge가 점수를 매기는 온라인 평가에서 매우 중요합니다. LLM judge보다 최대 약 200배 빠르기 때문에, Jev judge는 도착하는 트래픽 속도를 따라잡는 데 더 뛰어납니다. 이는 PII 유출, 프롬프트 인젝션, 또는 독성 같은 보안이나 안전 위험을 표시하는 피드백 키에 가장 중요하며, 여기서는 웹훅을 트리거하여 응답을 자동화할 수 있는 알림을 피드백 키에 설정할 수 있습니다. judge가 빠를수록 무언가 잘못되는 것과 조치가 취해지는 것 사이의 간격이 짧아집니다.

병렬화는 단일 에이전트 트레이스에 대해 평가할 수 있는 기준의 수를 변경합니다. Jev는 요청의 모든 질문을 함께 평가하므로, PII 유출, 사용자 의도, 사용자 좌절감과 같은 여러 피드백 키를 사용하여 트레이스를 점수화하는 비용은 하나만 사용하는 경우보다 단지 약간 더 비쌀 뿐입니다.

💡 System One 모델은 요청의 모든 질문을 병렬로 평가합니다. 질문을 추가해도 응답 시간 변화가 거의 없고, 추가되는 질문에 대한 토큰 비용만 발생하며 이는 저렴합니다.

반면 LLM judge는 기준(criterion)마다 별도의 호출이 필요하거나, 모든 기준을 하나의 프롬프트에서 순차적으로 추론해야 하며 이때 출력 토큰은 기준의 수에 따라 증가합니다.

System One 모델들은 이러한 문제점들을 잘 해결하지만, 이것들이 LLM judge를 쓸모없게 만드는 것은 아닙니다. 미세 조정된(fine-tuned) 오픈 모델들은 최첨단 모델(frontier model)보다 훨씬 낮은 비용으로 효과적인 judge가 될 수 있으며, 판결과 함께 서면 추론을 원하는 개방형 기준(open-ended criteria)의 경우 LLM judge가 여전히 더 좋은 도구입니다. Jev는 필요한 결정이 좁고 유형화되어 있으며 대량으로 처리하는 경우에 적합합니다.

Jev를 judge로 사용하는 것이 실제로 작동할까요?

저희는 Agent Evals용 Jev-as-a-Judge에서 Jev를 테스트하며, 정확도(accuracy), 일관성(consistency), 속도(speed), 비용을 기준으로 GPT-5.6 Luna, GPT-5.6 Terra, 그리고 Claude Sonnet 4.6과 비교했습니다. Jev는 더 정확했고, 훨씬 더 일관적이었으며, 또한 더 빠르고 저렴했습니다.

TypeSafe API 키 추가하기. 설정(Settings)에서 Provider secrets를 열고 + Secret을 클릭합니다. Provider로 TypeSafe를 선택하고, TYPESAFE_API_KEY 필드에 TypeSafe API 키를 붙여넣습니다. 이 키는 TypeSafe AI 계정에서 생성할 수 있습니다.

---

평가자(evaluator) 추가하기. 트레이싱 프로젝트(tracing project)에서 평가자(Evaluators) 탭을 열고 + Evaluator를 클릭합니다. Create from scratch 아래에서 LLM-as-a-Judge Evaluator를 선택합니다.

Provider로 TypeSafe 선택하기. Jev-as-a-judge 평가자의 이름을 지정합니다. Prompt & Model 아래에서 Model Configuration을 열고 Provider로 TypeSafe를, Model로 jev-latest를 선택합니다.

---

상태(state) 정의하기. 모델 구성이 완료되면, Jev가 평가할 상태 또는 컨텍스트(context)를 run 변수나 thread 변수에 매핑하여 정의합니다. LLM judge와 달리, 상태에는 채점 지침을 포함해서는 안 됩니다. 해당 지침은 다음 단계의 질문에 넣습니다.

---

질문 추가하기. 피드백 구성(Feedback Configuration) 아래에서, 상태와 비교하여 평가하고 싶은 기준(criterion)마다 하나의 질문을 추가합니다. 각 질문은 피드백 키(feedback key)가 됩니다. '예/아니오' 형식의 질문이라면 높은 확률이 '예'를 의미하도록 문구를 작성하고, 선택지(choice)라면 모든 옵션 세트를 제공하며, 점수(score)라면 낮은 것부터 높은 순서대로 레벨을 부여합니다. Jev는 모든 질문을 단일 호출(single call)로 평가하기 때문에, 두 번째나 세 번째 질문을 추가해도 비용 증가는 미미합니다.

---

평가 시작하기. 평가자를 저장합니다. Jev-as-a-judge 평가자는 들어오는 run이나 thread를 점수화하기 시작하며, 각 질문은 자체 피드백 키로 나타납니다. 여기서부터는 LangSmith의 다른 피드백과 마찬가지로 해당 키들을 필터링하거나 차트화하거나 알림 또는 자동화를 설정할 수 있습니다.

시작하기

Jev-as-a-judge가 오늘 LangSmith에서 사용 가능합니다.

만약 에이전트에 Jev를 judge로 사용해 보신다면, 특히 현재 사용하고 계시는 LLM judge와 비교했을 때 어떤지 저희에게 알려주세요. 발견한 내용을 **포럼(forum)**에 공유하거나 X에 태그해주세요.

Jev가 평가(evals)를 넘어 에이전트 루프에 어떻게 적용되는지, 모델 라우팅 및 도구 위험 게이팅을 포함하여 확인하려면 Building a harness with Jev를 읽어보세요.

Jev를 사용한 에이전트 구축에 대해 더 알고 싶다면, 9월 22일 화요일에 TypeSafe AI 팀과 함께 라이브 스트림을 개최합니다: https://events.langchain.com/webinar/building-a-harness-with-jev/