Jev는 더 나은 에이전트 평가기가 될 수 있을까?

https://www.langchain.com/blog/jev-agent-evals-langsmith

현재 에이전트 평가 방식은 코드 기반 평가와 LLM을 심사자로 활용하는 평가(LLM-as-a-judge), 두 가지로 나뉩니다. 두 방식에는 각각 한계가 있습니다. 코드 기반 평가기는 입력이 정해져 있는 제한된 범위의 문제에만 사용할 수 있고, LLM 심사자는 느리고 비용이 많이 들며 신뢰하기 어려울 수 있습니다. TypeSafe AI의 Jev가 출시되어 주목받으면서, 저희는 이 ‘System One’ 모델이 제3의 에이전트 평가 방식이 될 수 있을지, 에이전트 엔지니어링에는 어떤 영향을 줄 수 있을지 알아보고 싶었습니다.

Jev란?

Jev는 TypeSafe AI가 새로 출시한 모델입니다. 사실 Jev는 전통적인 LLM이 아닙니다. 텍스트를 생성하지 않습니다. TypeSafe AI 팀은 이를 ‘System One’ 모델이라고 부릅니다.

📖 System One 모델은 소프트웨어가 바로 활용할 수 있는 구조화된 판단을 빠르게 내리도록 설계한 AI 모델의 한 유형입니다. System One 모델은 상태(state)를 평가하고, 타입이 지정된 답변과 확률을 반환합니다.

자기회귀 LLM과 System One 모델(Jev)이 같은 질문에 답하는 방식.

TypeSafe AI에 따르면, 이런 방식 덕분에 Jev는 LLM보다 빠르고 저렴하며, 분류 작업에서는 비교 대상 LLM보다 추론 속도가 최대 200배 빠르고 비용은 최대 400분의 1 수준이라고 합니다.

Jev로 에이전트를 만드는 방법을 더 알고 싶다면, 9월 22일 화요일에 TypeSafe AI 팀과 함께 진행하는 라이브 방송에 참여해 주세요. https://events.langchain.com/webinar/building-a-harness-with-jev/

Jev가 좋은 에이전트 평가기가 될 수 있는 이유는?

현재 에이전트 평가에는 코드 기반 방식과 LLM을 심사자로 활용하는 방식이 있으며, 각각 장점과 한계, 절충해야 할 점이 있습니다.

코드 기반 평가는 코드가 등장한 때부터 존재했습니다. 저렴하고 빠르며 신뢰할 수 있지만, 할 수 있는 일이 제한적이라는 점이 가장 큰 단점입니다. 전통적인 함수는 정해진 결정론적 입력을 필요로 하므로, 확률적으로 동작하는 에이전트의 행동을 평가하는 데 한계가 있습니다. 예를 들어 전통적인 함수로 에이전트가 첫 실행에서 도구를 호출했는지는 평가할 수 있지만, 그 도구의 결과를 활용해 사용자의 질문에 제대로 답했는지를 평가하기는 더 어렵습니다. 답이 하나로 정해져 있지 않은 작업에서는 같은 도구 결과를 올바르게 활용하는 방법이 여러 가지일 수 있습니다. 따라서 허용할 수 있는 모든 답변을 결정론적 로직으로 표현하려 하면, 코드 기반 평가가 다룰 수 있는 범위의 한계에 금세 부딪힙니다.

이때 등장하는 것이 LLM을 심사자로 활용하는 평가입니다. LLM이 에이전트의 실행 기록(trace)이라는 비정형 입력을 바탕으로 추론하고 점수를 매기는 방식입니다. LLM 심사자는 질문, 실행 기록, 근거를 비정형 입력으로 받아, 프롬프트에 따라 응답이 사용자의 요청에 부합했는지 평가할 수 있습니다.

LLM 심사자가 평가를 위한 구조화된 결과를 생성하는 방식.

하지만 에이전트 엔지니어라면 누구나 공감하듯, LLM 심사자도 완벽한 해결책은 아닙니다. 본질적으로 비결정론적인 시스템이므로, 신뢰할 만한 테스트 체계의 기반으로 삼기에는 불안정합니다. 또한 전통적인 코드 기반 평가보다 실행 속도가 느리고 비용도 더 많이 듭니다.

에이전트 평가는 판단을 내리는 작업입니다. 에이전트의 상태와 행동을 보고 피드백이 될 점수를 부여합니다. Jev는 이런 작업 방식에 맞게 설계되었습니다. 구조화된 상태를 바탕으로 타입이 지정된 질문을 평가하고, 타입이 지정된 답변과 확률을 반환합니다. 반면 자기회귀 모델은 토큰을 하나씩 생성하면서 판단에 도달합니다. 이번 실험에서 판단을 우선하는 이러한 설계는 더 짧은 지연 시간, 더 낮은 비용, 더 작은 분산과 함께 나타났습니다.

Jev 심사자가 평가 결과를 생성하는 방식. 모델 자체가 구조화된 출력을 지원한다는 점에 주목하세요.

Jev는 세 가지 질문 유형을 지원합니다.

• Choice는 선택지 하나를 고르고 확률과 신뢰도를 반환합니다.
  • 예: “이번 실행의 검색 결과를 가장 잘 설명하는 것은 무엇인가요?”
    • 응답: searched_appropriately, searched_unnecessarily, failed_to_search 중 하나와 확률, 신뢰도
• Score는 순서가 있는 평가 척도에 따라 답변에 점수를 매기고 확률과 신뢰도를 반환합니다.
  • 예: “답변이 얼마나 유용한가요?”
    • 응답: 1(도움이 되지 않음)부터 5(매우 유용함)까지의 평가 점수와 확률, 신뢰도
• Noul은 예/아니요로 답할 수 있는 판단이 참일 확률을 반환합니다.
  • 예: “최종 답변이 검색으로 얻은 근거에 기반하고 있나요?”
    • 응답: 0.0부터 1.0까지의 float 값. 1.0은 전적으로 근거에 기반한다는 뜻입니다.

같은 상태를 대상으로 여러 개의 개별 질문을 병렬로 평가할 수 있습니다.

Jev가 답할 수 있는 세 가지 질문 유형과 이를 평가에 적용하는 방법.

실행할 때마다 에이전트의 행동이나 검색으로 얻은 데이터, 실행 기록의 맥락이 달라지면 심사자들을 비교하기 어렵습니다. Deep Agents와 LangSmith를 이용하면 에이전트의 한 번의 실행을 데이터셋으로 기록하고, 각 모델에 동일한 기록을 다시 입력할 수 있습니다.

Jev로 평가하기

Jev를 검증하려면 먼저 점수를 매길 에이전트가 필요했습니다. 저희는 오픈 소스 에이전트 하네스인 Deep Agents로 평가 대상 에이전트를 만들었습니다. 이어서 각 평가기가 동일한 질문과 기대 행동을 기준으로 평가하도록 테스트 세트를 LangSmith 데이터셋으로 정의했습니다. 테스트 세트는 다섯 가지 날씨 요청으로 구성됩니다.

데이터셋의 각 사례에 대해 날씨 에이전트의 응답을 기록하고, 전체 출력을 LangSmith에 고정된 예제로 저장했습니다. 각 심사자는 기록된 다섯 번의 실행을 두 가지 지표로 평가했습니다. 하나는 연속형 점수인 quality이고, 다른 하나는 이진 판단인 does_pass입니다.

반복성(repeatability)과 별개로 판단의 정확성을 측정하기 위해, 사람이 같은 평가 기준에 따라 각각의 고정된 응답에 레이블을 부여했습니다. 사람이 부여한 레이블을 정답 기준(oracle)으로 삼아, 정밀성과 정확성이 평가기의 전반적인 효과에 미치는 영향을 더 폭넓게 분석할 수 있었습니다.

정확도는 사람의 정답 기준과 얼마나 일치하는지를 나타냅니다. 분산은 동일한 에이전트 행동에 대해 심사자가 일관되게 같은 판단을 내리는지를 나타냅니다. 분산이 작다고 정확도가 저절로 높아지는 것은 아닙니다. 심사자는 일관되게 틀릴 수도 있습니다. 하지만 심사자가 정확하다면, 분산이 작을수록 운영 환경에서도 그 정확도를 더 믿을 수 있습니다.

저희는 Jev를 GPT-5.6 Luna, GPT-5.6 Terra, Claude Sonnet 4.6과 비교했습니다. 각 사례를 100회씩 반복해 사례별 분산과 사람의 정답 기준에 대한 일치율을 계산했습니다.

평가 결과

정확도

이번 비교에서는 사람이 부여한 레이블을 정답 기준으로 삼아 이진 통과/실패 판단의 정확도를 계산했습니다.

이진 점수인 does_pass에서 Jev는 총 500회의 반복 판단 모두 정답 기준과 일치했습니다. Terra의 일치율은 99.8%, Luna는 96.4%, Claude는 80.0%였습니다.

정밀성

정확도는 심사자의 판단이 사람의 정답 기준과 일치했는지를 알려 줍니다. 정밀성은 에이전트의 행동이 달라지지 않았을 때 동일한 품질 점수를 내놓는지를 봅니다. 저희는 각 심사자의 점수에서 관측된 분산으로 정밀성을 측정했습니다.

Jev는 관측된 사례별 분산의 평균이 0.0000149로 가장 작았습니다. Luna는 이보다 433배, Terra는 913배, Claude는 92배 컸습니다.

이번 실험만으로는 Jev 점수의 변동이 더 작았던 이유를 알 수 없습니다. 한 가지 가설은 모델마다 최적화된 출력의 종류가 다르다는 것입니다. TypeSafe는 Jev를 보정된 확률과 타입이 지정된 답변을 반환하도록 학습한 판단 모델이라고 설명합니다. 반면 자기회귀 LLM 심사자는 먼저 텍스트를 생성하고, 평가기가 그 출력을 점수로 변환합니다. 이런 차이 때문에 Jev가 이번처럼 범위가 한정된 평가 작업에 더 잘 맞을 수는 있지만, 이는 관측 결과일 뿐 학습 목표 때문에 분산이 작아졌다는 증거는 아닙니다.

비용과 지연 시간

비용이 낮으면 대규모 에이전트 평가도 현실적으로 가능해집니다. 평가기 호출 비용이 비싸면 팀은 평가 범위와 예산 사이에서 선택해야 합니다. 이번 실험에서 Jev의 호출당 비용은 0.00035달러로, 이러한 부담을 줄여 줍니다. 팀은 같은 판단을 더 많이 반복하고 회귀 검사를 더 자주 수행할 수 있습니다. 이는 온라인 평가에서 더욱 중요합니다. 호출당 비용이 낮아지면 운영 환경의 실행 기록 중 더 많은 비율에 더 많은 심사자를 적용할 수 있고, 그만큼 더 촘촘한 피드백을 얻을 수 있기 때문입니다.

대규모 온라인 평가의 가능성

하루에 실행 기록 1만 건을 생성하는 운영 중인 에이전트라면, 이번에 관측한 호출당 비용 차이는 실제 운영에서 의미 있는 차이로 이어집니다.

저렴한 호출이 실제로 유용한지도 반영하기 위해, 저희는 **신호 가치(signal value)**를 이진 판단의 정답 기준 일치율과 이진 판단의 반복성을 곱한 값으로 정의했습니다. 반복성은 같은 실행 기록에 대해 독립적으로 두 번 호출했을 때 동일한 판정을 반환할 확률입니다. 이 지표에서는 정확하고 안정적인 심사자가 높은 점수를 받고, 일관되게 틀리는 심사자는 감점을 받습니다.

Jev처럼 유용한 피드백을 제공하면서 비용이 낮은 심사자는 온라인 평가의 비용 대비 가치를 높일 수 있습니다. 팀은 운영 환경의 더 많은 실행 기록에서 피드백을 얻고, 품질 변화를 더 빨리 발견하며, 피드백이 좋지 않은 방향으로 흐르기 시작할 때 알림을 받도록 설정할 수 있습니다.

새로운 유형의 에이전트 평가

현재 모든 에이전트 평가에는 절충이 따릅니다. 더 많은 에이전트 실행에 점수를 매기거나, 더 다양한 측면을 평가하거나, 더 많은 변경 사항을 테스트하면 테스트 비용이 늘어납니다. 이 때문에 팀은 원하는 만큼 충분히 평가하지 못합니다.

이번 실험에서 Jev의 판단 한 건은 0.00035달러였습니다. Jev는 저렴할 뿐 아니라 정확도가 높고 분산도 작아, 신뢰할 수 있고 유용한 정보를 담은 평가 결과를 제공했습니다. 이 가격으로 우수한 심사자를 사용할 수 있다면, 개발자는 각 에이전트 실행을 여러 구체적인 기준에 따라 평가하고, 에이전트의 모든 변경 사항이 미친 영향을 측정하며, 확신이 필요할 때 판단을 반복할 수 있습니다.

훌륭한 에이전트를 만들려면 상당한 테스트와 모니터링이 필요하기 때문에 이는 중요합니다. 에이전트를 더 자주 평가할수록 개발 과정에 더 많은 유용한 피드백을 반영할 수 있습니다.

이번 실험의 결과가 다른 에이전트와 운영 워크플로에도 적용되는지는 더 확인해야 합니다. 또한 낮은 비용은 실수를 증폭시킬 수도 있습니다. 일관되게 틀리는 평가기는 잘못된 피드백을 대량으로 만들어 낼 수 있습니다. 엔지니어는 여전히 워크플로에 사람의 검토와 심사자의 판단을 의도한 평가 기준에 맞추는 절차를 포함해야 합니다.

새로운 System One 계열 모델은 고품질 평가를 풍부하게 활용할 수 있게 해 줄 수 있습니다. 이는 에이전트 개발의 전체 생애주기를 단축할 수 있습니다. 에이전트 엔지니어는 더 많은 실행 기록을 피드백으로 전환하고, 성능 저하를 더 빨리 발견하며, 에이전트를 구축하고 테스트하고 모니터링하고 배포하는 과정에서 더 빠르게 움직일 수 있습니다. 평가 비용을 낮추는 데 그치지 않고, 신뢰할 수 있는 에이전트를 만들기 위한 피드백 주기를 단축할 수 있다는 뜻입니다.

재현성

이 프로젝트의 GitHub 저장소는 여기에서 확인할 수 있습니다.

LLM 심사자인 GPT-5.6 Luna, GPT-5.6 Terra, Claude Sonnet 4.6은 LangSmith Gateway를 통해 실행했습니다. Jev는 langchain-typesafe==0.0.1a2를 통해 사용했습니다.

재현을 위해 실행 환경을 밝히면, Deep Agents 0.7.15, LangChain OpenAI 1.6.2, LangSmith 0.12.6, Tavily Python 0.8.3을 사용했습니다. LLM 심사자의 temperature, top-p, seed, max tokens는 설정하지 않았으므로 각 제공업체의 기본값을 적용했습니다. 실험 메타데이터에서는 Jev 서비스 버전을 확인할 수 없었습니다.

더 알아보고 싶다면?

Jev로 에이전트를 만드는 방법을 더 알고 싶다면, 9월 22일 화요일에 LangChain이 TypeSafe AI 팀과 함께 진행하는 라이브 방송에 참여해 주세요.