Datadog AI 에이전트 평가, Jev로 비용 줄이는 법과 실무 적용 포인트

AS-IS: 평가 파이프라인이 생성 비용을 지불해온 이유

지난 2년간 평가 파이프라인은 텍스트 생성 모델에 yes/no 판정을 요청하고 그 답을 JSON 스키마로 감싸는 식으로 작동해왔어요. 사실상 1비트짜리 판단을 위해 매번 생성 비용을 지불한 셈이죠. Jev는 이 1비트 판단에 맞춰 설계된 모델이라, 텍스트 생성 없이 상태값(문자열이나 JSON 객체)과 typed 질문 세트를 주면 확률이 붙은 typed 답변만 돌려줍니다.

이번 내용: Vega Air 예시로 본 rubric 설계

Datadog은 가상의 항공사 Vega Air 고객지원 에이전트를 예로 들었습니다. 이 에이전트는 정책 문서 발췌본을 바탕으로 티켓에 답하는데, 문서에 의도적으로 구멍이 있어서 일부 티켓은 근거 있는 답이 없어요. 좋은 응답은 발췌본 안에서 답하거나 커버되지 않는다고 인정하고 사람에게 넘기는 것이고, 나쁜 응답은 발췌본에 없는 정책(주로 수수료)을 지어내는 거예요. Jev rubric은 이 구분을 다섯 개의 좁은 질문으로 쪼개 한 번의 요청에 묶어 보냅니다. 같은 요청 안의 질문들은 공유된 상태값에 대해 독립적으로 평가되기 때문에, 같은 근거를 매번 다시 보내지 않고도 여러 질문을 던질 수 있어요.

Jev는 세 가지 질문 타입을 지원해요. Noul 확률은 어떤 명제에 대한 불확실성을 표현하고, Choice와 Score는 확률 분포로 확신도를 요약합니다. 실제 응답 예시에서 실패 유형 판정은 none이 0.46, partial_answer가 0.42로 거의 동률이었고 confidence는 0.34로 나왔어요. 이걸 문자열 하나로 뭉개버리면 이런 근접 동률 신호가 사라지는데, 이런 신호 자체가 사람 검토자에게 트레이스를 넘기는 자연스러운 트리거가 될 수 있습니다. Jev는 텍스트로 된 날짜를 신뢰할 수 있게 세지 못하기 때문에 산술이나 날짜 계산은 코드에서 처리하는 게 맞고, 최종 판정(composite verdict)도 모델 판단이 아니라 애플리케이션 정책이라 코드에 두는 편이 나중에 rubric을 건드리지 않고 재조정하기 쉽습니다.

실무 적용 포인트

온라인 평가에서는 확률값을 그대로 score로 제출하고 pass/fail 기준은 assessment 필드에 따로 두는 게 핵심이에요. 제출 시점에 이진화해버리면 나중에 threshold를 바꿀 때 전체 백로그를 재채점해야 하지만, 확률을 그대로 남겨두면 threshold 변경이 쿼리 단계 작업으로 끝납니다. Choice 질문은 categorical로 제출해 UI에서 필터링 가능하게 하고, confidence는 별도 score로 분리해서 판정이 틀린 건지 평가 모델이 덜 확신하게 된 건지 구분할 수 있게 하는 게 좋아요. 모든 메트릭에는 judge_model을 태그로 남겨야 하는데, jev-latest 같은 별칭은 새 릴리스가 나오면 가리키는 대상이 바뀌기 때문에 실제로 응답한 버전을 기록해둬야 나중에 두 판정 모델을 같은 rubric, 같은 span으로 비교할 수 있어요.

실험 파이프라인에서는 evaluator 여섯 개가 붙는다고 평가 요청 60개를 보낼 필요가 없습니다. 행마다 캐시 하나로 rubric을 한 번만 실행하고 모든 evaluator가 같은 응답을 읽는 구조로 바꾸면 됩니다. 다만 동시 실행 환경에서는 네트워크 호출이 아니라 딕셔너리 자체에 락을 걸어야 하는데, 호출까지 락을 걸면 병렬 실행이 죽어버리기 때문이에요. 데이터셋에 정답 라벨이 있는 오프라인 환경에서는 에이전트의 실제 행동을 묻는 질문을 추가해 라벨과 비교하는 방식으로 에이전트와 평가 모델 양쪽을 동시에 검증하는 캘리브레이션 체크도 가능합니다. rubric을 바꾸거나 Jev 버전을 올릴 때마다 이 체크를 다시 돌려야 해요, 한 버전에서 맞춘 threshold가 다른 버전에도 그대로 통하지 않을 수 있으니까요.

자주 묻는 질문

ai 에이전트 평가 툴은 어떻게 골라야 하나요

평가 요청마다 텍스트 생성 비용을 지불하는 구조인지, 아니면 이번 Jev처럼 확률 기반 typed 답변만 반환하는 구조인지 먼저 확인하는 게 좋아요. 여러 질문을 한 요청에 묶어 처리할 수 있는지, 온라인 평가와 오프라인 experiments에 같은 rubric을 재사용할 수 있는지도 비교 포인트입니다.

ai 에이전트 비교할 때 비용은 어떻게 따지나요

텍스트 생성 방식은 판정 하나마다 생성 비용이 붙지만, Jev처럼 typed 답변만 반환하는 방식은 한 요청에 여러 질문을 묶어 요청 수 자체를 줄일 수 있어요. Datadog 사례에서는 evaluator 6개, 행 10개 기준으로 원래 60번 요청할 걸 캐시로 묶어 행당 1번으로 줄이는 구조를 썼습니다.

sentry datadog 비교는 어떤 관점에서 봐야 하나요

이번 자료는 Datadog Agent Observability의 평가 파이프라인, 즉 온라인 평가와 오프라인 experiments에서 Jev를 어떻게 연동하는지를 다루고 있어요. Sentry와의 직접 비교 내용은 원문에 없어서, 각 도구의 에이전트 관측 기능과 평가 연동 방식을 별도로 확인해보시는 걸 추천합니다.

Jev 같은 평가 전용 모델은 마케팅 ai 활용에도 쓸 수 있나요

원문은 고객지원 에이전트 사례를 중심으로 설명하고 있어서 마케팅 도메인 적용 사례가 직접 나오진 않아요. 다만 AI 에이전트 품질을 확률 기반으로 빠르게 판정하는 구조 자체는 생성형 AI를 활용하는 여러 도메인에 응용해볼 만한 접근입니다.