표 전체를 관통하는 세 문장 (어느 버전으로 설명하든 이 셋으로 닫으면 된다)
- 11종 중 2종만 결정론·무비용(자로 재기) — 나머지 9종은 AI 심판이라 비용과 비결정성이 따라온다.
- 4종은 GCP 없으면 아예 안 돈다 (safety_v1 + multi-turn 3종). 폐쇄망·로컬 전용 환경 사용 불가.
- threshold 기본값이 있는 건 2종뿐(1.0 / 0.8) — 나머지는 직접 명시해야 PASS/FAIL이 나온다.
V0 치트시트 — 메트릭당 한 줄씩
| Metric | 한 줄 정의 | 왜 중요한가 | 함정 한 줄 |
|---|
| tool_trajectory_avg_score | 도구 호출(이름+인자+순서)을 정답 궤적과 1:1 대조 후 평균 | 과정 검증의 기본선. 에이전트 평가에서 유일하게 "행동"을 결정론으로 재는 자 | 인자 공백·타입 차이도 0점, 개수 다르면 조용히 잘림(zip) |
| response_match_score | 최종 응답과 정답의 단어 겹침(ROUGE-1 F1) | 무비용 회귀 테스트. 매 커밋마다 돌려도 부담 없는 결과 검증 | 같은 뜻 다른 표현이면 감점. 영어 stemmer라 한국어 신뢰도 낮음 |
| final_response_match_v2 | AI 심판이 응답·정답의 "의미 동치"를 5회 다수결 판정 | ROUGE의 표현 취약성 보완. 의미가 맞으면 통과 | 호출당 judge 5회 = 비용·지연. 동점은 불통과(보수적) |
| rubric_based_final_response_quality_v1 | 사람이 쓴 기준표(rubric)별 yes/no 채점 후 평균 | 정답이 없는 태스크의 품질을 원하는 기준으로 채점 | rubric 품질 = 점수 품질. 포맷 위반 항목은 평균에서 조용히 빠짐 |
| rubric_based_tool_use_quality_v1 | 도구 사용 "논리"를 rubric으로 AI 채점 (reference-free) | exact match의 유연한 대안 — 순서·의존관계를 규칙으로 명세 | judge가 property 문구를 바꿔 쓰면 해당 rubric 드롭+경고 |
| hallucinations_v1 | 응답을 문장 분해 → 각 문장이 근거(context)에 기반하는지 라벨링 | 환각 감지 = 신뢰의 최전선. RAG/tool 응답의 faithfulness | 근거 자료가 부실하면 판정도 부실. 1회 실행이라 다수결 안정화 없음 |
| safety_v1 | 유해성 여부를 Vertex SAFETY 메트릭으로 판정 | 출시 전 무해성 게이트 | GCP 필수·유료. 판정 로직이 Vertex 내부라 감사 불가 |
| per_turn_user_simulator_quality_v1 | 가상 사용자가 시나리오·페르소나를 지켰는지 턴별 검증 | 측정 장비 캘리브레이션. 이게 낮으면 나머지 멀티턴 점수 전부 무효 | 첫 턴은 문자열 완전일치 — 한 글자만 달라도 0 |
| multi_turn_task_success_v1 | 멀티턴 끝에 사용자 목표 달성 여부를 AI 판정 | 멀티턴의 최종 성과 지표 ("예약 됐나 안 됐나") | GCP 위임 — 루브릭 불투명, 비결정 |
| multi_turn_trajectory_quality_v1 | 목표까지의 "경로"가 효율적·논리적이었는지 정성 평가 | 성공했어도 비효율(우회·반복)을 잡는 과정 지표 | GCP 위임. reference-free라 기준이 judge 재량 |
| multi_turn_tool_use_quality_v1 | 멀티턴 전반의 도구 선택·인자 정확성을 AI 평가 | 멀티턴에서의 도구 사용 감사 | GCP 위임. 정밀 검증은 단일턴 rubric 버전이 더 감사 가능 |
V1 3분 발표 대본 — 표를 위에서 아래로 훑는 흐름
도입 — 프레임 잡기 20초
"이 표의 11종은 결국 두 개의 축으로 정리됩니다.
무엇을 재는가 — 과정(도구 궤적)이냐, 결과(응답)냐, 대화 전체(멀티턴)냐.
무엇으로 재는가 — 자(결정론 코드)냐, AI 심판(LLM judge)이냐, GCP 위임이냐.
표를 위에서 아래로 읽으면 정확히 이 순서로 배치되어 있습니다."
블록 1 — Programmatic 2종 40초
"맨 위 두 줄이 유일한 '자'입니다.
tool_trajectory_avg_score는 에이전트가 부른 도구의 이름·인자·순서를 정답 궤적과 1:1로 대조합니다. LLM을 안 쓰니 공짜고 재현 가능하지만, 그만큼 융통성이 없어서 인자에 공백 하나만 달라도 그 구간은 0점입니다. 기본 임계가 1.0, 즉 완전 일치를 요구합니다.
response_match_score는 응답과 정답의 단어 겹침(ROUGE-1)입니다. 매 커밋마다 돌리는 회귀 테스트용으로는 최적이지만, 같은 뜻을 다른 말로 하면 감점됩니다.
이 둘의 약점을 보완하려고 나머지 9종이 존재합니다."
블록 2 — ADK 자체 LLM Judge 60초
"가운데 블록은 AI 심판입니다. 기본 심판은 gemini-2.5-flash, 5회 샘플링 다수결.
final_response_match_v2는 방금 본 ROUGE의 직접 개선판 — 표현이 달라도 의미가 같으면 통과시킵니다. 대신 호출당 judge 5회라 비용이 붙습니다.
rubric 2종은 발상이 다릅니다. 정답이 없어도 평가합니다. 사람이 '정중한가', 'GeoCoding 다음에 GetWeather를 불렀는가' 같은 기준표를 쓰면, AI가 항목별 yes/no로 채점해 평균합니다. 응답 품질용 하나, 도구 사용 논리용 하나.
hallucinations_v1은 응답을 문장 단위로 쪼개서, 각 문장이 도구 출력 같은 근거 자료에 실제로 기반하는지 검사합니다. 근거 있는 문장의 비율이 점수 — RAG 환각 감지의 표준 구조입니다."
블록 3 — Vertex 위임 + 멀티턴 50초
"아래 블록은 성격이 다릅니다. ADK가 직접 채점하지 않고 Vertex AI에 위임합니다 — GCP 프로젝트와 과금이 전제됩니다.
safety_v1은 무해성 필터.
멀티턴 3종은 가상 사용자(simulator)를 붙여 여러 턴 대화를 시킨 뒤 — 결과(목표 달성했나), 과정(경로가 효율적이었나), 도구(제대로 골라 썼나)를 각각 봅니다.
그리고 그 앞의 per_turn_user_simulator_quality_v1이 특이한데, 에이전트가 아니라 가상 사용자 자신을 검증합니다. 측정 장비가 고장 나 있으면 측정값 전부가 무효니까요 — 멀티턴 평가의 캘리브레이션 게이트입니다."
클로징 — 실무 함의 20초
"실무 도입 순서는 표의 순서 그대로입니다: 먼저 programmatic 2종으로 무비용 회귀선을 깔고, 표현 다양성이 문제 되면 v2로, 정답이 없는 태스크는 rubric·hallucination으로, 멀티턴은 GCP를 전제로 확장합니다.
주의점 하나만 꼽자면 — threshold 기본값이 있는 건 2종뿐입니다. 나머지는 설정에 임계값을 직접 명시해야 PASS/FAIL이 나옵니다."
V2 개념·배경 — 각 메트릭의 계보 ("어디서 온 아이디어인가")
계보 서술은 학계/업계 통설 수준의 학습 지식 기반(근거등급 표기: 논문·벤치명은 참고용). 채점 동작 자체는 소스 확인 완료(본편 참조).
tool_trajectory_avg_score— "mock assertion의 에이전트판" Programmatic
개념
에이전트의 행동 로그(tool-call 궤적)를 기대 궤적과 exact match. 응답 텍스트가 아니라 행동 자체를 채점.
계보
전통 소프트웨어 테스트의 mock 검증(assert_has_calls)과 같은 발상. 에이전트 벤치마크로는 BFCL(Berkeley Function-Calling Leaderboard)의 AST/exact-match 채점, τ-bench의 액션 검증 계열.
왜 있나
에이전트 평가에서 유일하게 결정론으로 잴 수 있는 "행동" 지표. CI에 넣을 수 있는 몇 안 되는 메트릭.
response_match_score— "요약 평가의 고전, ROUGE" Programmatic
개념
응답·정답 간 unigram 겹침의 F1. 의미가 아닌 표면(lexical) 유사도.
계보
ROUGE는 Lin(2004)이 문서 요약 평가용으로 만든 지표. BLEU(기계번역)와 함께 20년간 NLG 자동 평가의 표준이었고, ADK는 그중 ROUGE-1을 그대로 가져옴(rouge_scorer, stemmer 사용).
왜 있나
LLM 없이 도는 결과 검증이 필요해서. 단, 요약 평가용 지표를 에이전트 응답에 전용(轉用)한 것이라 paraphrase 취약성도 그대로 상속.
final_response_match_v2— "LLM-as-a-judge + 다수결 안정화" LLM Judge
개념
judge LLM이 "이 응답이 정답과 의미상 동치인가"를 valid/invalid로 판정. 반올림·단위 변환·표 vs 문장 같은 형식 차이는 관대히 허용.
계보
LLM-as-a-judge 패러다임(MT-Bench/Chatbot Arena, Zheng et al. 2023)의 적용. 5회 샘플링 다수결은 self-consistency(Wang et al. 2022) 기법으로 judge 비결정성을 완화하는 표준 처방.
왜 v2
v1(ROUGE)의 치명적 약점 — "정답인데 표현이 달라서 FAIL" — 을 의미 판정으로 교체한 세대 교체판.
rubric_based_* 2종— "기준표(rubric) 평가, reference-free의 시작" LLM Judge
개념
정답 대신 평가 기준 목록을 입력으로 받는다. judge가 기준별 yes/no → 평균. 응답용과 도구 사용용 두 갈래.
계보
교육 평가학의 루브릭 채점 + NLP의 체크리스트 평가(CheckList, G-Eval 계열). "정답이 하나로 정해지지 않는 태스크"를 평가하려는 흐름.
왜 중요
실제 서비스 태스크 대부분은 golden answer가 없다. rubric은 평가 기준을 사람이 완전 제어하면서 채점만 자동화하는 절충점. tool 버전은 "GeoCoding→GetWeather 순서" 같은 의존 관계를 자연어 규칙으로 명세 — exact match와 자유 정성평가의 중간 지대.
hallucinations_v1— "claim 분해 + groundedness 판정" LLM Judge
개념
응답을 문장(claim) 단위로 분해(Segmenter) → 각 문장을 근거 context와 대조해 supported/unsupported/contradictory 라벨(Validator) → supported 비율이 점수.
계보
RAG faithfulness 평가의 표준 구조 — RAGAS의 faithfulness, attribution 평가(AIS, Rashkin et al.) 계열. NLI(함의 판정)를 LLM으로 대체한 형태.
우리 자체 발견과 직결. 인용판정 메타평가에서 같은 구조의 판정기(문장 분해→supported 판정)가 fail-open으로 supported를 부풀리고, 2-hop 추론 문장에서 대량 오판(FN)함을 실측했다. hallucinations_v1도 구조가 동일 — 판정기 자체를 gold 셋으로 메타평가하기 전엔 신뢰 금지. 보고에서 강한 차별화 포인트.
safety_v1— "Responsible AI 필터의 위임" Vertex AI
개념
유해·폭력·혐오 등 무해성 판정. ADK 자체 로직 없음 — Vertex Gen AI Eval SDK의 SAFETY 메트릭에 완전 위임.
계보
클라우드 벤더의 Responsible AI 안전 필터 제품군. 자체 구현 대신 위임한 것은 안전 판정의 지속 업데이트·책임 소재를 벤더에 두려는 설계.
함의
판정 기준을 소스로 감사할 수 없다. 폐쇄망·로컬 환경에서는 사용 불가.
per_turn_user_simulator_quality_v1— "측정 장비의 캘리브레이션" Hybrid
개념
멀티턴 평가에서 에이전트가 아니라 가상 사용자(simulator)를 채점한다. 시나리오의 시작 발화를 그대로 던졌는지(첫 턴, 문자열 일치), 중간·종료 턴에서 페르소나·시나리오를 지켰는지(judge 다수결).
계보
goal-oriented dialogue 연구의 user simulation + τ-bench류 시뮬레이터 기반 에이전트 평가에서 "시뮬레이터 품질이 평가 타당성을 좌우한다"는 문제의식.
왜 중요
실험 과학의 대조군 개념. 이 점수가 낮으면 그 대화로 계산한 다른 멀티턴 메트릭이 전부 오염된 것 — 반드시 함께 실행하는 게이트 메트릭.
multi_turn_* 3종— "결과·과정·도구의 3분해" Vertex AI
개념
같은 멀티턴 대화를 세 관점으로 나눠 채점 — task_success(목표 달성 여부), trajectory_quality(경로의 효율·논리), tool_use_quality(도구 선택·사용의 질). 모두 Vertex 위임.
계보
task success rate는 goal-oriented dialogue(MultiWOZ 등)의 고전 지표. 과정/결과 분리는 "성공했지만 비효율" vs "실패했지만 합리적 경로"를 구분하려는 에이전트 평가의 최근 흐름.
왜 3개
결과만 보면 운 좋은 성공을 못 거르고, 과정만 보면 목표 미달을 못 거른다. 세 지표의 조합이 진단력을 만든다 — 성공↓+경로↑ = 능력 부족이 아니라 태스크 난이도, 성공↑+경로↓ = 기술 부채성 성공.
V3 계산식 + 수집 trajectory 매트릭스 (기술 심화)
| Metric | 계산식 (소스 확인 기준) | 판정 단위 |
|---|
| tool_trajectory_avg_score | score = (1/N) Σᵢ 𝟙[toolsᵢactual = toolsᵢexpected] — EXACT는 이름·인자(dict ==)·개수·순서 모두 일치 시 1, 아니면 0. IN_ORDER/ANY_ORDER 옵션 | invocation별 0/1 → 평균 |
| response_match_score | score = (1/N) Σᵢ ROUGE-1-F1(respᵢ, refᵢ), F1 = 2PR/(P+R), unigram+stemmer | invocation별 연속값 → 평균 |
| final_response_match_v2 | invocation 판정 = majority(judge×5, valid/invalid; 동점=invalid) → score = #valid / #evaluated | 5샘플 다수결 → 비율 |
| rubric_based_* 2종 | rubric별 다수결(yes=1/no=0, 파싱실패=None 제외) → invocation = mean(rubrics) → overall = mean(전체 rubric 점수 pool) | rubric×5샘플 → 이중 평균 |
| hallucinations_v1 | score = (#supported + #not_applicable) / #sentences. Segmenter→Validator 2단계, 1회 실행(다수결 없음) | 문장별 라벨 → 비율 |
| per_turn_user_simulator_quality_v1 | 첫 턴 = 𝟙[strip(actual)=strip(starting_prompt)]; 중간·종료 턴 = majority(judge×5) → score = #valid턴 / #평가턴 | 턴별 하이브리드 → 비율 |
| safety_v1 · multi_turn 3종 | Vertex SDK 내부 (수식 비공개) — task_success는 마지막 turn 평가의 mean_score | Vertex 반환값 |
| Metric |
질의
(user_content) |
actual
응답 |
reference
응답 |
actual tool
호출/응답 |
expected
tool_uses |
rubrics |
scenario |
judge LLM |
GCP |
| tool_trajectory_avg_score | · | · | · | ✅ | ✅ 필수 | · | · | 없음 | · |
| response_match_score | · | ✅ | ✅ 필수 | · | · | · | · | 없음 | · |
| final_response_match_v2 | ✅ | ✅ | ✅ 필수 | · | · | · | · | gemini | · |
| rubric_based_final_response_quality_v1 | ✅ | ✅ | · | ✅ (신뢰근거) | · | ✅ 필수 | · | gemini | · |
| rubric_based_tool_use_quality_v1 | ✅ | · | · | ✅ | · | ✅ 필수 | · | gemini | · |
| hallucinations_v1 | ✅ | ✅ | · | ✅ (context) | · | · | · | gemini ×2단계 | · |
| safety_v1 | ✅ | ✅ | · | · | · | · | · | Vertex | ✅ |
| per_turn_user_simulator_quality_v1 | ✅ (멀티턴) | · | · | · | · | · | ✅ 필수 | gemini | · |
| multi_turn_task_success_v1 | ✅ (멀티턴) | ✅ | · | · | · | · | ✅ (파이프라인) | Vertex | ✅ |
| multi_turn_trajectory_quality_v1 | ✅ (멀티턴) | ✅ | · | ✅ | · | · | ✅ (파이프라인) | Vertex | ✅ |
| multi_turn_tool_use_quality_v1 | ✅ (멀티턴) | ✅ | · | ✅ | · | · | ✅ (파이프라인) | Vertex | ✅ |
읽는 법 (보고 멘트용).
① 빨간 ✅ = 사람이 미리 만들어야 하는 자산. reference가 필요한 건 3종뿐 — 나머지 8종은 reference-free라서 골든셋 제작 비용이 없다. 대신 rubric(2종)·scenario(멀티턴 4종)라는 다른 형태의 사람 작업으로 치환된다.
② judge 열이 "없음"인 2종만 완전 오프라인·재현 가능. gemini 5종은 API 키만, Vertex 4종은 GCP 프로젝트까지 필요.
③ trajectory 수집 관점: 런타임이 남겨야 하는 로그는 결국 4가지 — 사용자 발화 · 최종 응답 · 중간 tool 호출/응답 쌍 · (멀티턴이면) 턴 경계. 이 4가지가 trace에 있으면 11종 전부 계산 가능하다.
| 구분 | 메트릭 | LLM 호출 수 (invocation당) | 재현성 |
|---|
| 무비용 | tool_trajectory · response_match | 0 | 완전 결정론 |
| 중비용 | final_response_match_v2 | 5 | 다수결로 완화 |
| 고비용 | rubric 2종 | 5 (rubric 전체를 한 프롬프트에) | 다수결로 완화 |
| 중비용 | hallucinations_v1 | 2 (Segmenter+Validator) | 1회 실행 — 다수결 없음 |
| 대화 비례 | per_turn_simulator | (턴 수−1) × 5 | 첫 턴만 결정론 |
| 외부 과금 | safety + multi_turn 3종 | Vertex 내부 | 비결정 + 루브릭 불투명 |
V4 30초 엘리베이터 버전 — 비유 중심 (비기술 청중용)
| Metric | 비유 |
|---|
| tool_trajectory_avg_score | 레시피 대조 — 정해진 조리 순서·재료 그대로 요리했는지 한 단계씩 확인. 소금 1g만 달라도 그 단계는 빵점 |
| response_match_score | 단어 맞춰보기 채점 — 답안지와 정답지를 겹쳐 놓고 같은 단어가 몇 개인지 세는 방식. 빠르지만 "같은 뜻 다른 말"을 모름 |
| final_response_match_v2 | 채점 선생님 — "표현은 달라도 뜻이 맞으니 정답 인정". 대신 선생님(AI) 인건비가 든다 |
| rubric_based_final_response_quality_v1 | 심사위원 채점표 — "정중한가 ✓, 근거 있는가 ✓…" 항목별 체크 후 평균. 정답이 없어도 심사 가능 |
| rubric_based_tool_use_quality_v1 | 작업 절차서(SOP) 감사 — "A 승인 후 B 결재했는가" 같은 절차 준수를 점검 |
| hallucinations_v1 | 문장별 팩트체크 — 기사의 모든 문장에 "출처 있어?"를 묻고, 출처 있는 문장의 비율을 점수로 |
| safety_v1 | 방송 심의 — 내보내도 되는 내용인지 외부 심의기관(GCP)에 맡김 |
| per_turn_user_simulator_quality_v1 | 모의고사 감독 — 고객 역할 '배우'가 대본대로 연기했는지 확인. 배우가 애드립 치면 그 모의고사 결과는 전부 무효 |
| multi_turn_task_success_v1 | 결과 보는 사장님 — "그래서 예약 됐어, 안 됐어?" |
| multi_turn_trajectory_quality_v1 | 과정 보는 코치 — "됐는데, 세 번 빙 돌아갔잖아" |
| multi_turn_tool_use_quality_v1 | 공구 사용 감사 — 맞는 연장을 맞는 용도로 썼는가 |
V5 예상 Q&A 10문
Q1LLM judge 점수는 돌릴 때마다 다르지 않나? 그걸 지표라고 할 수 있나?
맞다, 비결정적이다. ADK의 완화책은 5회 샘플링 다수결(final_response_match_v2, rubric 계열, simulator). 단 hallucinations_v1은 1회 실행이라 이 안정화가 없다. 완전 재현이 필요한 회귀 게이트에는 programmatic 2종만 쓰고, judge 계열은 추이(trend) 지표로 쓰는 게 정석.
Q2비용은 어느 정도인가?
programmatic 2종은 0. judge 계열은 invocation당 judge 5회(gemini-2.5-flash), 멀티턴 simulator는 턴 수에 비례해 폭증. Vertex 4종은 GCP 과금 별도. → "전수는 programmatic, 샘플링은 judge"가 실무 배합.
Q3한국어 응답에도 쓸 수 있나?
주의 필요. response_match_score는 영어 stemmer 기반이라 한국어에서 신뢰도가 낮고, judge 계열도 프롬프트가 영어라 다국어 응답 판정에 편향 가능성이 있다. 한국어 태스크면 judge 계열 위주 + 메타평가(사람 라벨과 일치율 확인)를 먼저 권장.
Q4exact match(기본 임계 1.0)는 너무 엄격하지 않나?
의도된 엄격함이다 — "정해진 시퀀스의 회귀 방지"가 목적. 유연성이 필요하면 두 가지 완화 경로: ① match_type을 IN_ORDER/ANY_ORDER로 낮추기, ② rubric_based_tool_use_quality_v1으로 논리 규칙만 검증(reference-free).
Q5response_match_score(v1)와 final_response_match_v2 중 뭘 쓰나?
포맷이 고정된 응답(수치, ID, 고정 문구)은 v1 — 공짜·결정론. 자연어로 풀어 쓰는 응답은 v2 — paraphrase 허용. 공식 권장도 "표현이 다양할 수 있으면 v2".
Q6hallucinations_v1이 1.0이면 환각이 없다고 믿어도 되나?
안 된다. 두 가지 이유: ① 점수는 "context 대비" supported 비율 — context 자체가 부실하면 판정도 부실. ② 판정기(Validator)의 오판 — 우리가 자체 인용판정기 메타평가에서 실측한 바로는, 같은 구조의 판정기가 2-hop 추론 문장을 대량 오판하고 fail-open으로 supported를 부풀렸다. 판정기를 gold 셋으로 먼저 채점해 본 뒤에 믿어야 한다.
Q7GCP 없이 쓸 수 있는 건 몇 종인가?
완전 로컬 2종(programmatic). gemini API 키만 있으면 +5종(v2, rubric 2, hallucinations, simulator). Vertex 4종(safety + multi_turn 3종)은 GCP 프로젝트 필수라 폐쇄망 불가.
Q8threshold는 어떻게 정하나?
기본값은 tool_trajectory 1.0, response_match 0.8뿐이고 나머지는 명시 필수 — 안 하면 PASS/FAIL 판정 자체가 안 나온다. 실무는 baseline 실행으로 점수 분포를 먼저 보고, 회귀 감지 목적이면 baseline보다 약간 아래에 긋는 방식.
Q99종에 @experimental이 붙어 있는데 프로덕션에 써도 되나?
API(클래스·필드)가 바뀔 수 있다는 뜻이지 채점이 부정확하다는 뜻은 아니다. 단 버전 핀 고정 + 업그레이드 시 스코어 호환성 확인은 필요.
Q10우리 평가 체계와의 관계는?
개념 대응이 거의 1:1이다 — 우리 tool 궤적/성공 판정 ↔ tool_trajectory·task_success, 우리 인용 F1 ↔ hallucinations_v1(faithfulness). 차이는 우리는 trace를 DB에 남겨 메트릭을 사후에 재계산·신설할 수 있고, 판정기 자체를 메타평가한다는 점. ADK 표는 "업계 표준이 무엇을 재는가"의 레퍼런스로 쓰고, 수집(trajectory 로깅)은 우리 스키마가 이미 상위 호환.
＋ 부록 — 보고 상황별 조합 가이드