# ADK 내장 메트릭 11종 — 보고용 다각도 브리핑

> 대상: `/apps/adk-metrics/` §1 요약표를 축으로 설명하는 보고.
> 같은 표를 6가지 깊이(치트시트 → 대본 → 개념·계보 → 계산식·데이터 → 비유 → Q&A)로 준비.
> 근거: google/adk-python `evaluation/` 소스 직접 열람(본 페이지에서 검증 완료) + 일반 계보 지식(내 학습 지식, 각 항목에 등급 표기).

---

## 버전 0 — 치트시트 (메트릭당 한 줄씩: 정의 / 왜 중요 / 함정)

| 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 버전이 더 감사 가능 |

**표 전체를 관통하는 세 문장** (슬라이드 하단 각주로 써도 됨):
1. 11종 중 **2종만 결정론·무비용**(자로 재기), 나머지 9종은 AI 심판(비용 + 비결정).
2. **4종은 GCP 없으면 아예 안 돈다** (safety_v1 + multi-turn 3종).
3. threshold 기본값이 있는 건 **2종뿐**(1.0 / 0.8) — 나머지는 직접 명시해야 PASS/FAIL이 나온다.

---

## 버전 1 — 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이 나옵니다."

---

## 버전 2 — 개념·배경 (각 메트릭의 계보 — "어디서 온 아이디어인가")

> 계보 서술은 내 학습 지식 기반(근거등급: 학계/업계 통설 수준). 논문·벤치명은 참고용.

### tool_trajectory_avg_score — "mock assertion의 에이전트판"
- **개념**: 에이전트의 행동 로그(tool-call 궤적)를 기대 궤적과 exact match. 응답 텍스트가 아니라 **행동 자체**를 채점.
- **계보**: 전통 소프트웨어 테스트의 mock 검증(`assert_has_calls`)과 같은 발상. 에이전트 벤치마크로는 BFCL(Berkeley Function-Calling Leaderboard)의 AST/exact-match 채점, τ-bench의 액션 검증 계열.
- **왜 ADK에 있나**: 에이전트 평가에서 유일하게 결정론으로 잴 수 있는 "행동" 지표. CI에 넣을 수 있는 몇 안 되는 메트릭.

### response_match_score — "요약 평가의 고전, ROUGE"
- **개념**: 응답·정답 간 unigram 겹침의 F1. 의미가 아닌 표면(lexical) 유사도.
- **계보**: ROUGE는 Lin(2004)이 **문서 요약 평가**용으로 만든 지표. BLEU(기계번역)와 함께 20년간 NLG 자동 평가의 표준이었고, ADK는 그중 ROUGE-1을 그대로 가져옴(`rouge_scorer`, stemmer 사용).
- **왜 ADK에 있나**: LLM 없이 도는 결과 검증이 필요해서. 단, 요약 평가용 지표를 에이전트 응답에 전용(轉用)한 것이라 paraphrase 취약성도 그대로 상속.

### final_response_match_v2 — "LLM-as-a-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의 시작"
- **개념**: 정답 대신 **평가 기준 목록**을 입력으로 받는다. judge가 기준별 yes/no → 평균. 응답용과 도구 사용용 두 갈래.
- **계보**: 교육 평가학의 루브릭 채점 + NLP의 체크리스트 평가(CheckList, G-Eval 계열). "정답이 하나로 정해지지 않는 태스크"를 평가하려는 흐름.
- **왜 중요**: 실제 서비스 태스크 대부분은 golden answer가 없다. rubric은 평가 기준을 **사람이 완전 제어**하면서 채점만 자동화하는 절충점. tool 버전은 "GeoCoding→GetWeather 순서" 같은 의존 관계를 자연어 규칙으로 명세 — exact match와 자유 정성평가의 중간 지대.

### hallucinations_v1 — "claim 분해 + groundedness 판정"
- **개념**: 응답을 문장(claim) 단위로 분해(Segmenter) → 각 문장을 근거 context와 대조해 supported/unsupported/contradictory 라벨(Validator) → supported 비율이 점수.
- **계보**: RAG faithfulness 평가의 표준 구조 — RAGAS의 faithfulness, attribution 평가(AIS, Rashkin et al.) 계열. NLI(함의 판정)를 LLM으로 대체한 형태.
- **주의 (우리 자체 발견과 직결)**: 우리 citation-judge 메타평가에서 **같은 구조의 판정기**(문장 분해→supported 판정)가 fail-open으로 supported를 부풀리고, 2-hop 추론 문장에서 대량 오판(FN)함을 실측했다. hallucinations_v1도 구조가 동일하므로 **판정기 자체를 gold 셋으로 메타평가하기 전엔 절대 신뢰 금지** — 보고에서 강한 차별화 포인트로 쓸 수 있음.

### safety_v1 — "Responsible AI 필터의 위임"
- **개념**: 유해·폭력·혐오 등 무해성 판정. ADK 자체 로직 없음 — Vertex Gen AI Eval SDK의 SAFETY 메트릭에 완전 위임.
- **계보**: 클라우드 벤더의 Responsible AI 안전 필터 제품군. 자체 구현 대신 위임한 것은 안전 판정의 지속 업데이트·책임 소재를 벤더에 두려는 설계.
- **함의**: 판정 기준을 소스로 감사할 수 없다. 폐쇄망·로컬 환경에서는 사용 불가.

### per_turn_user_simulator_quality_v1 — "측정 장비의 캘리브레이션"
- **개념**: 멀티턴 평가에서 에이전트가 아니라 **가상 사용자(simulator)를 채점**한다. 시나리오의 시작 발화를 그대로 던졌는지(첫 턴, 문자열 일치), 중간·종료 턴에서 페르소나·시나리오를 지켰는지(judge 다수결).
- **계보**: goal-oriented dialogue 연구의 user simulation + τ-bench류 시뮬레이터 기반 에이전트 평가에서 "시뮬레이터 품질이 평가 타당성을 좌우한다"는 문제의식.
- **왜 중요**: 실험 과학의 대조군 개념. 이 점수가 낮으면 그 대화로 계산한 다른 멀티턴 메트릭이 **전부 오염**된 것 — 반드시 함께 실행하는 게이트 메트릭.

### multi_turn 3종 — "결과·과정·도구의 3분해"
- **개념**: 같은 멀티턴 대화를 세 관점으로 나눠 채점 — task_success(목표 달성 여부), trajectory_quality(경로의 효율·논리), tool_use_quality(도구 선택·사용의 질). 모두 Vertex 위임.
- **계보**: task success rate는 goal-oriented dialogue(MultiWOZ 등)의 고전 지표. 과정/결과 분리는 "성공했지만 비효율" vs "실패했지만 합리적 경로"를 구분하려는 에이전트 평가의 최근 흐름.
- **왜 3개로 쪼갰나**: 결과만 보면 운 좋은 성공을 못 거르고, 과정만 보면 목표 미달을 못 거른다. 세 지표의 조합이 진단력을 만든다 (성공↓+경로↑ = 능력 부족이 아니라 태스크 난이도, 성공↑+경로↓ = 기술 부채성 성공).

---

## 버전 3 — 계산식 + 수집 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_final_response_quality_v1` | rubric별 다수결(yes=1/no=0, 파싱실패=None 제외) → invocation = mean(rubrics) → overall = mean(전체 rubric 점수 pool) | rubric×5샘플 → 이중 평균 |
| `rubric_based_tool_use_quality_v1` | 위와 동일 구조. property 텍스트 정규화(lower+strip) 완전일치로 rubric 매핑, 실패 시 드롭 | rubric×5샘플 → 평균 |
| `hallucinations_v1` | score = (#supported + #not_applicable) / #sentences. Segmenter→Validator 2단계, **1회 실행**(다수결 없음) | 문장별 라벨 → 비율 |
| `safety_v1` | Vertex SDK 내부 (PrebuiltMetric.SAFETY) — 수식 비공개 | Vertex 반환값 |
| `per_turn_user_simulator_quality_v1` | 첫 턴 = 𝟙[strip(actual)=strip(starting_prompt)]; 중간·종료 턴 = majority(judge×5) → score = #valid턴 / #평가턴 | 턴별 하이브리드 → 비율 |
| `multi_turn_task_success_v1` | Vertex 멀티턴 API 위임, overall = 마지막 turn 평가의 mean_score | Vertex 반환값 |
| `multi_turn_trajectory_quality_v1` | Vertex 위임 — 수식 비공개 | Vertex 반환값 |
| `multi_turn_tool_use_quality_v1` | Vertex 위임 — 수식 비공개 | Vertex 반환값 |

### 수집 trajectory 매트릭스 — "이 메트릭을 계산하려면 어떤 데이터가 로그에 있어야 하나"

ADK 평가 데이터 단위 = EvalCase(테스트 케이스) 안의 Invocation(턴).
actual 쪽은 에이전트 실행에서 수집, expected 쪽은 테스트 파일에 사람이 작성.

| Metric | 사용자 질의 (user_content) | actual 응답 | **reference 응답** | actual tool 호출/응답 (intermediate_data) | **expected tool_uses** | **rubrics** | conversation_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 호출/응답 쌍(intermediate_data), (멀티턴이면) 턴 경계. 이 4가지가 있으면 11종 전부 계산 가능. *(우리 eval_ph1의 events 테이블이 정확히 이 4가지를 seq 순으로 남기는 구조 — 대응 가능하다는 멘트 가능)*

### 비용·재현성 스펙 요약

| 구분 | 메트릭 | 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 내부 (과금) | 비결정 + 불투명 |

---

## 버전 4 — 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 | **공구 사용 감사** — 맞는 연장을 맞는 용도로 썼는가 |

---

## 버전 5 — 예상 Q&A (10문)

**Q1. LLM 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 계열 위주 + 메타평가(사람 라벨과 일치율 확인)를 먼저 권장.

**Q4. exact match(기본 임계 1.0)는 너무 엄격하지 않나?**
의도된 엄격함이다 — "정해진 시퀀스의 회귀 방지"가 목적. 유연성이 필요하면 두 가지 완화 경로: ① match_type을 IN_ORDER/ANY_ORDER로 낮추기, ② rubric_based_tool_use_quality_v1으로 논리 규칙만 검증(reference-free).

**Q5. response_match_score(v1)와 final_response_match_v2 중 뭘 쓰나?**
포맷이 고정된 응답(수치, ID, 고정 문구)은 v1 — 공짜·결정론. 자연어로 풀어 쓰는 응답은 v2 — paraphrase 허용. 공식 권장도 "표현이 다양할 수 있으면 v2".

**Q6. hallucinations_v1이 1.0이면 환각이 없다고 믿어도 되나?**
안 된다. 두 가지 이유: ① 점수는 "context 대비" supported 비율 — context 자체가 부실하면 판정도 부실. ② 판정기(Validator)의 오판 — 우리가 자체 인용판정기 메타평가에서 실측한 바로는, 같은 구조의 판정기가 2-hop 추론 문장을 대량 오판하고 fail-open으로 supported를 부풀렸다. **판정기를 gold 셋으로 먼저 채점해 본 뒤에 믿어야 한다.**

**Q7. GCP 없이 쓸 수 있는 건 몇 종인가?**
완전 로컬 2종(programmatic). gemini API 키만 있으면 +5종(v2, rubric 2, hallucinations, simulator). Vertex 4종(safety + multi_turn 3종)은 GCP 프로젝트 필수라 폐쇄망 불가.

**Q8. threshold는 어떻게 정하나?**
기본값은 tool_trajectory 1.0, response_match 0.8뿐이고 나머지는 명시 필수 — 안 하면 PASS/FAIL 판정 자체가 안 나온다. 실무는 baseline 실행으로 점수 분포를 먼저 보고, 회귀 감지 목적이면 baseline보다 약간 아래에 긋는 방식.

**Q9. 9종에 @experimental이 붙어 있는데 프로덕션에 써도 되나?**
API(클래스·필드)가 바뀔 수 있다는 뜻이지 채점이 부정확하다는 뜻은 아니다. 단 버전 핀 고정 + 업그레이드 시 스코어 호환성 확인은 필요.

**Q10. 우리 평가 체계와의 관계는?**
개념 대응이 거의 1:1이다 — 우리 tool 궤적/성공 판정(runs·events) ↔ tool_trajectory·task_success, 우리 인용 F1 ↔ hallucinations_v1(faithfulness). 차이는 우리는 trace를 DB에 남겨 메트릭을 **사후에 재계산·신설**할 수 있고, 판정기 자체를 메타평가한다는 점. ADK 표는 "업계 표준이 무엇을 재는가"의 레퍼런스로 쓰고, 수집(trajectory 로깅)은 우리 스키마가 이미 상위 호환.

---

## 부록 — 보고 상황별 조합 가이드

| 상황 | 쓸 버전 |
|---|---|
| 시간 3분, 표만 띄우고 설명 | 버전 1 대본 그대로 |
| 임원·비기술 청중 | 버전 4 비유 + 치트시트의 "관통 세 문장" |
| 기술 리뷰어가 깊이 파고들 때 | 버전 3 계산식·매트릭스 |
| "왜 이런 메트릭이 존재하나" 질문 | 버전 2 계보 |
| 질의응답 대비 | 버전 5 Q&A 10문 |