jevals: LLM 심사 대신 타입 지정 판정을 쓰는 에이전트 평가

jevals README가 설명하는 내용

jevals는 GitHub의 openlayer-ai 조직에서 공개한 오픈소스 Python 라이브러리입니다. README는 이를 "에이전트를 위한 eval과 가드레일"이라고 소개하며, LLM 심사 대신 Jev 계열 결정 모델을 쓴다고 밝힙니다. 핵심 주장은 비용과 속도입니다. 에이전트 트레이스 하나에 대한 모든 eval이 한 번의 요청으로 나갑니다. README에 따르면 이 요청은 1센트의 수천분의 1 정도가 들고, 응답은 수백 밀리초 안에 돌아옵니다. 그래서 모든 트레이스에 대해 돌릴 수 있고 에이전트 루프 안에서도 쓸 수 있다는 것이 README의 설명입니다.

이 글은 README만을 근거로 합니다. 우리는 이 도구를 설치하거나 실행하지 않았습니다. 아래의 모든 숫자는 작성자 본인의 주장이며, README가 스스로 추정치나 예시라고 표시한 곳은 그렇게 짚어 두겠습니다.

README의 핵심 사실

모델의 발상. README는 Jev가 텍스트를 생성하지 않는다고 말합니다. 상태와 타입이 지정된 질문 묶음(예/아니오, 여러 선택지 중 하나 고르기, 채점 기준에 따른 점수)을 보내면, 한 번의 순전파로 각 질문에 대해 보정된 확률을 돌려줍니다. 질문은 서로 독립적으로 병렬 평가되므로 40개를 물어도 지연은 하나를 물을 때와 비슷합니다. README가 제시하는 가격은 입력 토큰 100만 개당 0.042달러이고 출력 토큰은 없습니다. Vercel 게이트웨이를 거친 요청당 p50은 244ms, p95는 371ms로 측정되었다고 합니다. 퀵스타트. `evaluate()`를 한 번 호출하면서 메시지와 도구 스키마, 그리고 `ToolChoice`, `UsedToolResult`, `Grounded`, `StayedInScope`, `AnswerRelevancy`, `Completeness`, `IndirectInjection`, `PHI` 같은 eval 객체 목록을 넘깁니다. README는 eval 여덟 개가 HTTP 요청 한 번으로 처리되었고 1,388토큰, 0.00006달러, 0.33초가 들었다고 보고합니다. 백엔드. 라이브러리는 환경 변수를 보고 백엔드를 고릅니다. 선택지는 `TYPESAFE_API_KEY`를 통한 Jev 직접 연결(README에 따르면 현재는 대기자 명단 접근이 필요), Vercel AI Gateway를 거치는 Jev, 직접 호스팅하는 Kev, Apple Silicon에서 프로세스 안에서 도는 Laya, 그리고 OpenRouter를 거치는 일반 채팅 LLM입니다. 마지막 것은 확률을 답하라고 요청하는 프롬프트로 흉내 냅니다. README는 백엔드를 바꾸면 `jevals calibrate`를 다시 실행하라고 경고합니다. 모델이 다르면 확률이 서로 맞지 않기 때문입니다.

eval 목록. README는 에이전트 eval(`ToolChoice`, `Grounded`, `StayedInScope`, `LoopDetection`, `GoalCompletion`, `ToolCallRisk` 등), 보안 eval(`PromptInjection`, `IndirectInjection`, `Jailbreak`, `PII`, `PHI`, `SecretsExposure` 등), 그리고 Ragas 스타일의 품질 지표(`Faithfulness`, `AnswerRelevancy`, `ContextPrecision`, `ContextRecall` 등)를 나열하고, 전체가 37개라고 적습니다. 벤치마크 표. README는 작은 RAG 데이터셋의 같은 20행으로 jevals와 Ragas를 비교합니다. 측정일은 2026-09-20입니다. gpt-4.1-mini를 쓰는 Ragas는 샘플당 LLM 요청 6.0회와 임베딩이 필요하고, 1,000개 샘플당 약 2.60달러, 20개 샘플에 22~35초가 걸립니다. Jev를 쓰는 jevals는 샘플당 요청 1.0회, 1,000개당 약 0.03달러, 0.8초입니다. gpt-4.1-mini로 Jev를 흉내 낸 jevals는 요청 1.0회, 1,000개당 0.46달러, 4초입니다. Kev-4B와 Laya 행은 추정치로 표시되어 있습니다. 실측한 세 행 모두에서 faithfulness는 0.90~0.92, context precision과 recall은 1.0으로 나왔습니다.

eval과 게이트의 작동 방식

eval은 메서드 세 개를 가진 클래스입니다. `state()`는 모델이 볼 내용을 고르고, `questions()`는 무엇을 물을지 정하며, `reduce()`는 돌아온 확률을 점수로 바꿉니다. 여러 eval을 `evaluate()`에 넘기면 README에 따라 상태가 병합되고 질문이 한 요청에 묶입니다. eval은 샘플에만 의존하므로 같은 클래스를 오프라인 지표, 운영 트레이스 모니터, 에이전트 내부의 게이트로 모두 쓸 수 있습니다.

게이트는 eval 하나에 정책 하나를 더한 것으로, 답을 허용, 에스컬레이션, 차단 중 하나로 연결합니다. README는 도구 호출 위험을 다루는 YAML 게이트를 보여 줍니다. 정책은 `action.approve >= 0.85`이고 `grounded >= 0.7`이면 허용하고, `action.block >= 0.6`이면 차단하며, 나머지는 에스컬레이션합니다. README에는 OpenAI Agents SDK, 일반 비동기 루프, LangGraph, Claude Agent SDK의 `PreToolUse` 훅에 연결하는 방법이 나옵니다. 재시도 후에도 백엔드가 계속 내려가 있으면 게이트는 기본적으로 호출을 통과시킵니다. 되돌릴 수 없는 작업에는 `on_error="block"`을 주어 반대로 바꿀 수 있습니다.

PII와 PHI에 대해 README는 두 단계를 설명합니다. 먼저 엔티티를 탐지하고, 그다음 모델에 질문 하나를 보냅니다. 식별 가능한 사람의 건강 정보인지, 아니면 고객지원 이메일 주소인지 묻는 것입니다. README는 엔티티 탐지만으로는 이 둘을 구분하지 못하며, 그것이 PII 오탐의 대부분을 만든다고 말합니다.

배경과 우리의 해석

*이 절은 README의 내용이 아니라 우리의 분석입니다.* LLM 심사란 범용 채팅 모델에 출력을 채점하게 하는 방식으로, 보통 추론과 JSON 답을 요구하는 프롬프트를 씁니다. README의 논지는 심사가 내리는 판단의 대부분이 세 가지 질문 유형에 들어가며, 결국 손에 남는 것은 라벨이라는 점입니다. 작은 모델이 한 번의 계산으로 확률이 붙은 라벨을 돌려줄 수 있다면, 훨씬 자주 돌릴 수 있습니다. 이는 eval의 쓰임새를 바꿉니다. 밤마다 하는 표본 검사가 모든 트레이스에 대한 검사가 되고, 모든 트레이스에 대한 검사는 요청 경로 안으로 들어올 수 있습니다.

README는 분산도 언급합니다. 동일한 트레이스에서 GPT와 Claude 심사의 점수 분산이 Jev의 92배에서 913배였다는 LangChain의 비교를 인용합니다. 우리는 그 글을 읽지 못했습니다. 또한 확률은 글 한 단락과 달리 임계값을 둘 수 있으므로 동작별로 절충점을 조정할 수 있습니다. README의 `jevals calibrate` 예시는 임계값별로 잘못 통과시킨 비율과 놓친 통과 비율을 나란히 보여 주며, 환불과 조회는 같은 임계값을 쓰면 안 되므로 모델별이 아니라 동작별로 임계값을 정하라고 권합니다.

README 자체의 예시는 여러 지표를 함께 돌릴 이유를 보여 줍니다. 도구는 오늘의 예보만 돌려주었는데 에이전트는 "이번 주 내내 맑을 것"이라고 답했습니다. `grounded` eval은 그 문장에 p=0.05를 주었고 `answer_relevancy`는 0.84로 높게 유지되었습니다. README는 RAG식 지표만으로는 이 트레이스가 통과했을 것이라고 결론짓습니다.

한계와 남은 질문

README는 자신의 한계에 솔직합니다. 프로젝트는 alpha이고 공개된 지 일주일이며, 밑바탕의 모델도 일주일 되었다고 적혀 있습니다. TypeSafe 직접 백엔드는 문서화된 통신 형식에 맞춰 작성하고 목(mock)에 대해 테스트했을 뿐 아직 실제로 돌려 보지 않았습니다. 프레임워크 어댑터도 SDK 문서에 맞춰 작성해 가짜 객체로 테스트했습니다. 표의 Kev와 Laya 행은 각 모델 작성자가 공개한 수치를 곱해서 얻은 추정치입니다. 여러 출력 블록에는 "Illustrative output", 즉 예시 출력이라는 표시가 붙어 있습니다. README는 이 도구가 테스트 세트를 만들지 않고 대시보드도 없으며, 다단계 추론이나 서술형 평가가 필요한 일에서는 LLM 심사를 대체하지 못한다고도 말합니다.

정확도에 대해 README는 독립 벤치마크 JevBench를 인용합니다. 분류 과제에서 Jev의 정확도는 가장 작은 LLM들과 비슷한 수준(Banking77과 CLINC150에서 83~87%)이며 보정 수준은 과제마다 다르다는 내용입니다. LangChain에서 500회 반복에 걸쳐 사람과 100% 일치했고 Claude는 80%였다는 결과는 트레이스 다섯 개에서 나온 것이라고 README는 덧붙입니다. 또 한 번의 실행 중 게이트웨이가 일부 연결에서 멈춰 그 실행의 p95가 1분이 되었지만, 클라이언트가 재시도해서 실행은 끝났다고 보고합니다. README에서 사소한 불일치도 발견했습니다. 도입부 예시는 eval 여덟 개에 1,388토큰, 0.33초인데, 더 긴 예시는 아홉 개에 1,423토큰, 0.50초입니다. 본문은 "100분의 6센트"라고 쓰지만 출력된 비용은 0.00006달러로, 이는 1,000분의 6센트에 해당합니다. 서로 다른 실행에서 생긴 표현상의 실수로 보이며 깊은 문제는 아니지만, 숫자를 직접 다시 측정해야 하는 이유를 보여 줍니다. 우리의 해석은 이렇습니다. 절감 효과는 여러분의 질문이 세 가지 유형에 들어맞는지, 그리고 데이터가 표에 쓰인 작은 표본과 비슷한지에 달려 있습니다. 가장 날카로운 경고는 README 스스로 내놓습니다. 분류기가 승인 권한자가 되어서는 안 된다는 것입니다. 환불을 실행해야 하는지는 모델이 볼 수 없는 계정 상태와 권한에 달려 있습니다.

독자를 위한 실용적 제안

1. 이미 트래픽 일부에 LLM 심사를 돌리고 있다면, README의 LLM 에뮬레이션 백엔드가 이 API를 가장 부담 없이 시험해 보는 방법입니다. README는 지금도 동작하지만 보정된 값이 아니라 0.00 또는 1.00의 확률을 돌려준다고 말합니다.

2. 자신의 트레이스 일부에 라벨을 붙이고 `jevals calibrate`를 실행한 뒤에 임계값을 믿으세요. README는 보정용 데이터가 가장 도움이 되는 기여라고 말합니다.

3. 되돌릴 수 없는 작업에는 사람을 두고, 그 앞의 게이트에는 `on_error="block"`을 설정하세요.

4. README의 작성 요령을 따르세요. 한 질문에는 한 가지만 묻기, 선택지는 이름만 붙이지 말고 설명하기, 상태는 작게 유지하기, 상태에 답이 없을 수 있으면 "증거 불충분" 선택지를 추가하기입니다.

5. 프레임워크 어댑터는 누군가 실제로 돌려 보기 전까지 거친 부분이 있다고 보고, 비용 표는 작성자의 주장으로 다루세요. 계획에 반영하기 전에 자신의 트레이스에서 비교를 다시 해 보세요.