09. Judge 설계: 요약 품질을 보조 평가하는 방법

SeSAC:Note에서 Judge는 정답 판별기가 아닙니다. Judge는 Summarizer가 만든 노트를 원본 segment와 비교해 groundedness, note quality, multimodal use를 보조적으로 점검하는 gate입니다.

이 구분이 중요합니다. Judge 수치를 잘못 쓰면 생성 품질을 최종 판정한 것처럼 보일 수 있습니다. 이 글에서는 Summarizer와 Judge를 왜 나눴는지, benchmark 수치를 어떻게 제한해서 해석해야 하는지 정리합니다.

Summarizer와 Judge를 분리한 이유

Summarizer의 역할은 노트를 생성하는 것입니다. Judge의 역할은 생성된 노트가 근거에 맞는지 점검하는 것입니다. 둘을 분리하면 생성과 평가의 책임이 나뉩니다.

flowchart LR
    A[Segments: STT + VLM] --> B[Summarizer]
    B --> C[AI Note]
    A --> D[Judge]
    C --> D
    D --> E[Scores / Feedback]
    E --> F[Revision or Accept]

Summarizer가 좋은 문장을 만들더라도 원본 근거와 맞지 않으면 학습 노트로는 위험합니다. 반대로 원본 근거만 나열하면 읽기 좋은 노트가 되지 않습니다. 그래서 생성과 평가를 분리해 서로 다른 관점으로 보게 했습니다.

Judge는 기준 점수에 미달한 결과에 대해 피드백을 만들고, 그 피드백을 바탕으로 요약을 보완하거나 재생성하는 loop로 설명할 수 있습니다. 다만 최종 판정 장치가 아니라 위험을 줄이는 보조 점검 loop로 보는 것이 맞습니다.

flowchart LR
    A[Summary Draft] --> B[Judge]
    B --> C{Score >= 7.0?}
    C -->|Yes| D[Accept]
    C -->|No| E[Feedback]
    E --> F[Revise / Regenerate]
    F --> B

여기서 7.0은 프로젝트 기록에 남은 gate 기준이다. 모든 강의에서 이 기준이 절대적인 품질 기준이라는 의미는 아니다.

평가 축

Judge는 요약을 하나의 점수로만 보지 않는다. 프로젝트 기록에서는 다음 축이 중요하게 다뤄졌다.

평가 축	의미
groundedness	생성 내용이 원본 segment 근거와 맞는가
note quality	학습자가 읽기 좋은 구조인가
multimodal use	화면 정보와 음성 정보가 함께 반영됐는가
rule compliance	출력 형식과 작성 규칙을 지켰는가

이 축들은 품질 보증이 아니라 점검 기준이다. LLM Judge 역시 LLM이므로 실수할 수 있다. 따라서 Judge 결과는 자동 검사의 한 종류로 보고, 제한된 benchmark 기준으로만 해석한다.

평가 모듈의 입력·출력과 가중치

Judge 모듈은 생성된 요약 콘텐츠의 품질을 보증하는 단계

• 입력 : 생성된 요약본 segment_summaries.jsonl+ 원본 STT/이미지 싱크 데이터 segments_units.jsonl
• 평가 : 정해진 항목으로 평가
• 산출 : 가중치가 적용된 종합 점수와 개선 사항이 담긴 한국어 한 줄 피드백.

src/judge/judge.py: 요약 결과 평가

• 생성된 요약 콘텐츠가 신뢰 가능(groundedness, multimodal_use)하고, 규칙 준수(compliance) 및 교육적 가치(note_quality)가 있는지 평가
• 처리 로직
  1. 요약본과 원본 근거 데이터를 로드하고 ID 매칭 수행
  2. segments_units를 batch_size 단위로 분할
  3. Gemini 모델로 평가 요청(병렬 처리 지원)
  4. LLM이 반환한 3가지 항목의 점수를 가중치를 적용해 계산 후 정규화를 통해 최종 점수를 계산
  5. 최종 리포트 및 세그먼트별 상세 리포트를 JSON으로 저장

config/judge/prompts.yaml: 평가 기준 프롬프트

• 목적: 토큰 소모를 최소화하면서 핵심만 빠르게 평가.
• 구조 :
  1. System : "엄격한 AI 평가자" 페르소나 부여.
  2. Criteria (채점 기준표) :

  항목	가중치	설명
  groundedness	45%	주장이 근거에 의해 완벽히 지지되는가? (Hallucination 방지)
  note_quality	35%	영상 없이도 이해 가능한 독립적인 학습 노트인가?
  compliance	20%	JSON 스키마 및 금지어 규칙을준수했는가?
  multimodal_use	참고	시각 정보(cap_ids)를 적절히 활용했는가?

  1. Protocol: Validation Report 확인 -> 의미론적 근거 검증 -> JSON 출력 순서 강제.

최종 정리

{
"pass": true, // 최종 통과 여부 (boolean)
"final_score": 10.0, // 최종 점수 (10점 만점)
"min_score": 7.0, // 통과 기준 점수
"model": "gemini-3-flash-preview", // 사용된 Judge LLM 모델
"prompt_version": "v3", // 프롬프트 버전
"generated_at_utc": "...", // 생성 시간 (UTC)
"feedback": [ // 세그먼트별 피드백 (선택적일 수 있음)
{
"segment_id": 1,
"feedback": "VLM 텍스트와 레이아웃 정보를 바탕으로..."
},
    ...
  ],
"report": { // 상세 평가 리포트
"scores_avg": {
"groundedness": 10.0, // 근거 기반 점수 (환각 여부 등)
"multimodal_use": 10.0, // 멀티모달 정보 활용도
"note_quality": 10.0, // 노트 품질
"compliance": 10.0, // 지시 이행도
"final": 10.0 // 최종 평균점
},
"segments": {
"matched": 3,
"missing_summaries": [],
"missing_units": []
}
}
}

Judge prompt 개선 흐름

초기 Judge prompt는 평가 조건이 많고 모호하면 모델의 판단이 흔들릴 수 있다. 평가 기준이 복잡하면 토큰 사용량도 늘고, 응답 시간도 늘어난다.

개발 과정에서는 평가 축을 줄이고, 출력 구조를 단순화하고, retry/self-correction 흐름을 조정하는 방향이 정리됐다.

개선 방향	목적
평가 축 축소	모델이 무엇을 봐야 하는지 명확히 함
출력 구조 단순화	parsing과 downstream 처리를 쉽게 함
prompt 압축	토큰 사용량과 응답 시간을 줄임
retry 조건 정리	불필요한 재시도를 줄임

프로젝트 기록 기준으로 별도 실험에서는 Judge 통과율이 80%에서 95%로 개선된 사례가 정리되어 있다. 이 수치는 해당 문서의 실험 조건 기준이며, 전체 서비스 품질을 의미하지 않는다.

요약 쪽에서는 항목마다 참고한 VLM unit id를 evidence로 남기는 방식도 정리됐다. 이렇게 하면 Judge가 생성 문장을 원본 segment와 비교하기 쉬워지고, 나중에 사용자가 “이 요약이 어디서 왔는가”를 추적할 수 있다. 핵심은 환각을 없앴다고 말하는 것이 아니라, 근거 추적 가능성을 높였다고 말하는 것이다.

제한된 benchmark 결과

Judge benchmark는 세그먼트 8개, batch size 4, worker 2개, 합격 임계값 7.0점, Summarizer 5개 설정을 기준으로 정리된 제한된 비교다. 먼저 scoring rule부터 다르다.

Judge v1/v2 = 0.45 * groundedness + 0.20 * compliance + 0.35 * note_quality
Judge v3    = 0.50 * groundedness + 0.50 * note_quality

v3는 compliance 축을 제거하고 groundedness와 note quality에 집중한다. 따라서 v1, v2, v3의 점수는 같은 시험지의 절대 점수처럼 비교하면 안 된다. 더 안전한 해석은 “같은 프로젝트 benchmark 조건에서 prompt 버전별 평가 시간, 토큰 사용량, 통과 여부를 비교했다”이다.

Judge 버전	평균 점수	점수 범위	평균 평가 시간	평균 토큰	benchmark 통과
v1	7.78	6.96~8.88	31.6초	16,370 토큰	4/5
v2	9.72	9.45~9.96	28.2초	15,478 토큰	5/5
v3	9.67	9.44~10.00	14.7초	14,734 토큰	5/5

이 benchmark 조건에서 v3는 v1 대비 Judge 평가 단계 평균 시간이 53.5% 짧게 기록됐고, 평균 토큰 사용량은 10.0% 낮게 기록됐다. 이 수치는 전체 파이프라인 latency나 서비스 품질 개선율이 아니라 Judge 평가 단계의 비교 지표다.

상세 조합 중에는 Summarizer v3 + Judge v3가 10.00점, 14.8초, 13,980 토큰으로 기록되어 있다. 이 역시 해당 benchmark 조건의 조합 결과이며, 모든 영상 요약의 품질을 보장하는 숫자는 아니다.

실패 사례도 같이 봐야 한다. Summarizer v3.2 + Judge v1 조합은 6.96점으로 임계값 7.0점에 미달했고, 주요 원인은 compliance 축 해석 실패로 정리되어 있다. 이 사례는 Judge prompt가 길고 많은 규칙을 담는다고 항상 더 안전한 것은 아니라는 점을 보여준다.

이 표에서 가장 조심해야 할 숫자는 5/5와 53.5%다. 5/5는 제한된 benchmark 조건에서 5개 설정이 모두 통과했다는 뜻이다. 모든 강의 영상에서 정확하다는 의미가 아니다. 53.5%는 Judge 평가 단계 기준 시간 감소다. 전체 서비스 처리 시간이 그만큼 줄었다는 의미가 아니다.

수치 해석 한계

Judge benchmark는 유용하지만 한계가 있다.

한계	해석
표본 제한	일부 설정과 sample 기준 결과
scoring rule 변화	버전 간 점수 절대 비교가 어려울 수 있음
LLM Judge 자체의 불확실성	평가 모델도 오류 가능성이 있음
서비스 전체와 분리	Judge 단계 수치가 전체 UX를 대표하지 않음

따라서 “benchmark 조건에서 평가 단계 효율 개선이 관찰됐다” 정도로 해석하는 것이 안전하다.

Judge (src/judge) 개발 이력

Date	Change Bundle	Category	Evidence	Impact
01/07	Judge 초기 구성(가중치 기반 평가 + 배치 처리)	QA	465c392	품질 기준 “정의” 완료
01/08	점수 인플레이션 해결: 0~10 엄격 기준 정립	Quality	b5ba590	과대평가 방지
01/09	병렬 처리 도입(ThreadPoolExecutor)	Perf	7d35075	평가 속도 약 40% 개선
01/09	ADK UI 연동(버튼 클릭 평가)	DevEx	a7baa8a	데모/운영 편의 향상
01/10	피드백을 한 줄로 압축(토큰 절감)	Cost	723709c	평가 비용/지연 감소
01/15	프롬프트/설정 파일 분리(prompt.yaml)	DevEx	723709c	유지보수성 향상
01/16	Feedback loop 리팩토링(최대 2회 재시도)	Reliability	c64f53c	“자가 교정” 품질 보증 완성
01/19	Judge 프롬프트 v2/v3 추가	Reliability	7be6ad1 Issue #91	summarizer (v3) 조합. v2 (34.2초, 14,131) → v1 (17.6초, 14,704) → v3 (14.8초, 13,980)
02/07	배치 간 Context Chaining	Reliability	c1fe261	Summarizer→ Judge 문맥 연속성 확보, 맥락 단절 해결

Judge 해석에서 주의할 점

Judge는 품질을 높이는 데 도움을 줄 수 있지만, 생성 품질을 최종 판정하지 않는다. 특히 강의 유형이 달라지면 VLM 입력, STT 품질, Fusion 정확도, 요약 난도도 달라진다.

SeSAC:Note에서 Judge의 역할은 다음으로 제한한다.

1. 생성 요약을 원본 segment와 비교한다.
2. groundedness와 note quality를 자동 점검한다.
3. benchmark 조건에서 prompt 버전 간 차이를 관찰한다.
4. 사람이 확인해야 할 위험을 줄이는 보조 gate로 사용한다.

다음 글에서는 마지막으로 프로젝트를 마치며 남은 한계와 개선 방향을 정리한다.

• 이전 글: 08. QA 설계: 영상 근거 안에서만 답하게 만들기
• 다음 글: 10. 프로젝트 회고: 멀티모달 AI 서비스에서 배운 것