ADR 0032 — RAG 성능 평가 시스템 (사실관계 → AI → 정답 비교)

Status: Draft — 2026-04-29
Date: 2026-04-29
Tier: B (제품 품질 측정자 신규 도입, 외부 노출 0)
Decision Drivers: 사용자 발의. ADR 0024 V2 검색 품질은 internal retrieval 품질 (precision@k / NDCG / MRR) 만 측정 — 한 단계 위인 end-to-end 품질 (사실관계 → AI 분석/문서 → 실제 판결과의 일치도) 은 미측정. ADR 0018 학습 루프의 quality 측정자가 사용자 만족도(satisfaction) 만 보고 있어, "AI 가 만든 인용·청구취지가 실제 판례와 얼마나 맞는가" 의 객관 지표 없음. 영업·투자·내부 품질 회귀 감지 모두에 동일 지표 필요.
Anti-Goal Compliance: 4종 무관 (내부 측정 도구).

결정 (요약)

ops 콘솔 안에 RAG 성능 평가 러너를 둔다. 골든 평가 케이스 (사실관계 + 정답 인용·청구취지) 를 ADR 0028 패턴으로 packages/business-logic/rag-eval/ 에 추출하고, ops 시나리오 페이지에서 단일/배치 실행 → Firestore ragEvalRuns 에 결과 적재 → ops 페이지에 추세 시각화. 외부 노출 0, masterAdmin gate. ADR 0021 Platform RAG 인프라 (publicDocuments + findNearest) + ADR 0024 평가 텔레메트리 모듈을 그대로 재사용.

평가 축 두 가지 (b 는 PR-2 에 임베딩 유사도 placeholder, PR-3 에 본격 도입):

(a) 인용 일치도 — AI 가 검색·인용한 법조문 / 판례 ID 와 정답 set 비교 → precision · recall · F1
(b) 청구취지 일치도 — AI 가 생성한 청구취지 텍스트와 정답 텍스트의 임베딩 코사인 유사도 + 핵심 토큰 (금액·이자율·기산일·법조문) 매칭

평가 축 (c) 결과 (승/패/금액) 예측은 명시적으로 폐기 — 사실관계 충실도 의존성 너무 큼. 노이즈가 메트릭 드리프트를 가린다.

즉시 시행 (PR 분리)

PR	산출물	SLA
PR-1	ADR 0032 + `packages/types/src/rag-eval.ts` (RagEvalCase · RagEvalRun) + `packages/business-logic/src/rag-eval/metrics.ts` 순수 함수 (citationOverlap · normalizeStatuteCitation · normalizePrecedentId) + vitest	즉시
PR-2	`runRagEvaluation(ctx, caseInput)` mutation entry (firebase-admin) — publicDocuments findNearest + AI 청구취지 생성 + 메트릭 계산 + ragEvalRuns 적재. ops 시나리오 카드 (`run-rag-eval-scenario.ts`) + masterAdmin gate. 단일 케이스 smoke	1 세션
PR-3	Pack 1~~5 recoveryType 14종 골든 케이스 시드 스크립트 (10~~30 케이스) + 배치 실행 ops 시나리오 + 청구취지 임베딩 유사도 본 도입	2 세션
PR-4	ops 페이지 평가 추세 시각화 (precision · recall · F1 · 코사인유사도 시계열, recoveryType 별 분포) + 집계 스크립트 (Cloud Scheduler 옵션)	1 세션

배경

왜 지금 필요한가

ADR 0021 Platform RAG, ADR 0024 V2 검색 품질, ADR 0018 학습 루프 가 차례로 ship 되면서 RAG 인프라는 운영 가능 단계에 도달했다. 그러나 품질 자체를 객관 지표로 입증할 도구가 없다:

ADR 0024 의 precision@k / NDCG / MRR 은 검색 결과 순위 품질 측정. 사용자 행동 (clicked / dwellMs) 기반으로 정답 set 자체가 사용자 추정에 의존.
ADR 0018 의 만족도 (satisfaction) 는 변호사 주관 평가. 신뢰 구간 좁히려면 표본 누적 필요.
"이 AI 의 인용·청구취지가 실제 판례와 X% 일치한다" 라는 단일 숫자 지표 부재 → 영업·투자 자료에 정량 근거 못 붙임 / 내부 품질 회귀 감지 늦음.

"정답 set" 의 정의

정답 set = 합성한 골든 케이스의 기대 출력. 외부 실제 사건이 아니라 변호사 사용자(Chair) 가 직접 작성·서명한 골든 케이스 시드. 이렇게 하는 이유:

외부 실제 사건 PII 노출 위험 0 (feedback_no_pilot_mock_only.md 메모리 정합)
정답이 Chair 권위 로 고정 → 메트릭 드리프트 시 모델 변화만 원인
시드 14 recoveryType × 1~~3 변형 = 20~~40 케이스로 시작 가능

"왜 ops 인가"

이 평가는 운영팀(masterAdmin) 의 도구이자 책임. tenant 사용자에게 노출할 메트릭이 아님 (외부 노출은 영업·투자 매체로 가공 후 별도). ADR 0028 패턴 위에 자연스럽게 얹힘 — packages/business-logic/rag-eval/ 에 추출하면 web 학습 루프(ADR 0018) 도 같은 메트릭 함수를 재사용할 수 있다 (variant draft 비교 등).

데이터 모델

RagEvalCase (골든 케이스 시드)

interface RagEvalCase {
  id: string;                       // 안정 식별자 (예: "debt-001")
  recoveryType: RecoveryType;       // Pack 1~5 도메인
  docKind: DocKind;                 // 기대 문서 종류 (19종 중 하나)
  factPattern: string;              // 사실관계 (PII 무 · 합성)
  expected: {
    statutes: string[];             // 정답 법조문 (정규화 전 표기 가능)
    precedents: string[];           // 정답 판례 ID 목록 (publicDocuments docId)
    claimGist: string;              // 정답 청구취지 텍스트
  };
  notes?: string;                   // 출처·변형 사유
  createdAt: Timestamp;
  createdBy: string;                // masterAdmin uid
}

RagEvalRun (실행 결과 1건)

interface RagEvalRun {
  runId: string;                    // YYYYMMDDTHHmmss-{rand}
  caseId: string;
  startedAt: Timestamp;
  elapsedMs: number;
  retrieved: { statutes: string[]; precedents: string[] };
  generated: { claimGist: string; docKind?: DocKind };
  metrics: {
    statuteOverlap: OverlapMetric;  // precision · recall · f1 · matched · missed · extra
    precedentOverlap: OverlapMetric;
    claimSimilarity?: number;       // 0~1 (PR-3 도입)
    docKindMatch: boolean;
  };
  modelVersion: string;             // 예: "gemini-2.5-flash"
  embeddingVersion: string;         // 예: "text-embedding-004"
  status: "success" | "failure";
  error?: string;
}

Firestore 경로

ragEvalCases/{caseId} — 골든 시드 (루트, masterAdmin write · read)
ragEvalRuns/{runId} — 실행 결과 (루트, masterAdmin write · read)

tenant 격리 경로 밖에 둔다 — 평가 케이스·결과는 운영 데이터이며 tenant 데이터가 아니다 (PII 무, ADR 0021 publicDocuments 와 동일 모델).

측정·성공 지표

Phase A — 인프라 (PR-1~PR-2)

PR-1 머지 후 vitest 새 메트릭 모듈 통과
PR-2 머지 후 ops 시나리오에서 단일 케이스 1건 success 적재 확인 (테스트 tenant 이외 tenant 영향 0)

Phase B — 골든 셋 (PR-3)

Pack 1~5 recoveryType 14종 각 1+ 케이스 (총 ≥14 시드)
배치 실행 후 평균 statute F1 ≥ 0.5 / precedent F1 ≥ 0.4 (초기 베이스라인 설정만, 게이트 아님)

Phase C — 회귀 감지 (PR-4)

추세 시각화 페이지에서 시계열 그래프 1주 데이터 표시
메트릭 -10% 이상 회귀 시 ops 알림 (PR-4 또는 후속 ADR)

대안 검토

대안	평가
외부 실제 사건 데이터로 평가	거부 — PII 위험 + `feedback_no_pilot_mock_only.md` 메모리. Chair 합성 시드로 충분
결과(승/패/금액) 예측 메트릭 도입	거부 — 사실관계 충실도 의존, 노이즈 너무 큼. 메트릭 드리프트를 가림
ADR 0024 텔레메트리(relatedMemoriesEvents) 만으로 대체	거부 — retrieval 품질만 측정, end-to-end 품질 미측정. 보완재이지 대체재 아님
web 콘솔에 평가 도구 노출	거부 — 운영 도구. tenant 변호사에게 raw 메트릭 노출 가치 없음 + 책임 소재 모호
Cloud Scheduler 자동 평가 (PR-1 부터)	거부 — 수동 검증 안정화 후 PR-4 에서 옵션
`evalCases` / `evalRuns` (tenant 외 prefix 없이)	거부 — `rag` prefix 로 ADR 0021 Platform RAG 자산임을 명시

리스크

골든 시드 편향 — Chair 1인 작성. 변형·교차검증 절차 (Phase B 후속) 필요. 단 PR-1~PR-3 단계에선 베이스라인 수립이 우선.
임베딩 유사도 해석 — 코사인 0.7 이 의미하는 바는 도메인마다 다름. PR-3 에서 recoveryType 별 임계값 별도 캘리브레이션.
테스트 비용 — Vertex AI 호출 1건 당 ~수 cents. 배치 30 케이스 × 일 1회 = 무시 가능. 자동 스케줄 도입 시 (PR-4 후속) cost guard 별도.

결정 (요약)​

즉시 시행 (PR 분리)​

배경​

왜 지금 필요한가​

"정답 set" 의 정의​

"왜 ops 인가"​

데이터 모델​

RagEvalCase (골든 케이스 시드)​

RagEvalRun (실행 결과 1건)​

Firestore 경로​

측정·성공 지표​

Phase A — 인프라 (PR-1~PR-2)​

Phase B — 골든 셋 (PR-3)​

Phase C — 회귀 감지 (PR-4)​

대안 검토​

리스크​

관련 ADR​