POSA_Copyrighter/docs/operations/calibration-corpus.md

캘리브레이션 코퍼스 — 실이미지로 밴드 임계를 검증하는 절차

이 프로젝트의 가장 큰 미검증 항목은 위험도 밴드 임계(70/30)가 실제 판정과 한 번도 대조된 적이 없다는 것이다. 판정이 0건이라 decision_stats 도 빈 표를 낸다. 이 문서는 그 공백을 메우는 절차다.

두 가지를 구분한다.

대상	도구	사람 필요?
스코어러의 구조적 거동 (어떤 신호 조합이 어느 밴드로 가나)	scripts/score_distribution.py	아니오
임계가 맞는지 (밴드 vs 운영자 판단)	scripts/sweep_thresholds.py	예 — 실이미지 + 실판정

전자는 지금 당장 돌릴 수 있고 스코어러를 바꿀 때마다 돌려야 한다. 후자는 아래 절차로 코퍼스를 만든 뒤에만 의미가 있다.

1. 이미지 구성이 성패를 가른다

기술이 아니라 여기서 갈린다. 현재 밴드 분포에 low 가 0건이고, 저위험으로 떨어지는 이미지가 섞이지 않으면 미탐 지표(lowBandRejectionRate)의 분모가 0 이 된다. 그런데 _ratio 가 0/0 → 0.0 을 돌려주므로 화면에는 "미탐 0%"로 표시된다 — 측정된 0 과 측정 불가가 구분되지 않는다(store_workflow.py:398-399).

40장 기준 권장 구성:

군	장수	기대 밴드	넣는 이유
자사 제작·오리지널 (웹에 없음)	10	low	미탐 지표의 유일한 분모
라이선스 구매·계약처 제공분	8	low~medium	신뢰 출처 기능도 함께 검증
명백한 무단 사용 후보 (뉴스 사진·연예인·캐릭터)	12	high	과탐 지표의 분모
애매한 것 (웹에 있으나 출처 불명, SNS 유통)	8	경계	임계가 실제로 가르는 지점
위 중 2~3장을 리사이즈·재저장한 재제출	4	—	선례 승계·중복 탐지 검증

2. 준비 — 안 하면 코퍼스가 오염된다

네이버 일일 한도. COPYRIGHTER_NAVER_DAILY_LIMIT=100 인데 자동 검색이 장당 최대 5콜(이미지 3 + 블로그 1 + 웹 1)이라 20장째에 고갈된다. 고갈분은 v6 부터 검토 하한 30/medium 으로 올라가고 사유에 naver 미수행 — search API usage limit reached 가 남는다 (v5 까지는 0점·무사유로 조용히 지나갔다). 보이게는 됐지만 앞쪽과 뒤쪽 이미지의 증거 밀도가 다른 것은 그대로라 코퍼스 런에서는 한도를 올린다.

.env:  COPYRIGHTER_NAVER_DAILY_LIMIT=400
       COPYRIGHTER_GOOGLE_DAILY_LIMIT=200

Google Custom Search 는 현재 꺼져 있다. GOOGLE_CUSTOM_SEARCH_CX 는 있는데 GOOGLE_CUSTOM_SEARCH_API_KEY 가 없어 어댑터가 None 이다(env_clients.py:243-246). 이 상태로 돌리면 google_search 증거가 0행이다. 키를 넣거나, 증거원 2종 (Vision+Naver)으로 간다고 코퍼스 메타에 명시한다. 키를 넣으면 COPYRIGHTER_GOOGLE_CUSTOM_SEARCH_DAILY_LIMIT=100 도 같이 넣는다 — 없으면 로컬 게이트가 무제한이라 구글 무료 한도를 막아주지 못한다.

DB 를 분리한다. 기존 제출물은 스탬프 도입 이전 행이라 판정해도 스냅샷에 scorerVersion='legacy' 로 찍혀 스윕에서 제외된다.

python run_copyrighter_server.py --db data/corpus.sqlite3 --images C:/corpus

3. 투입

파일명을 새로 매긴다. 파일명 stem 이 곧 제출 id 이고, 같은 stem 이면 조용히 1건으로 병합된다(image_store.py:94-101 이 알려진 한계로 명시). 매니페스트 (submissions.json)는 필요 없다 — 폴더를 재귀 스캔한다. HEIC/TIFF 는 미지원이다.

# 중복 검사 (결과가 비어야 한다)
Get-ChildItem C:/corpus -Recurse -File | Group-Object BaseName | Where-Object { $_.Count -gt 1 }

# 10~15장씩 나눠서 — seed 가 write lock 을 잡는다
Invoke-RestMethod -Method Post -Uri http://127.0.0.1:9500/api/submissions/reload

reload 는 멱등이다(분석된 건은 건너뛴다). 다만 LLM 서술이 seed 1회당 20건 캡 (store_constants.py MAX_LLM_SUMMARIES_PER_SEED)이라 40장이면 reload 를 2~3번 더 호출해야 전부 채워진다.

투입 시 자동으로 도는 것: 내부 분석(지문·얼굴·출처) → Vision 웹탐지 장당 1콜 → 검색결과 유사도 비교 → 얼굴 크롭 생성 → 네이버 자동 검색 → 재스코어링 → LLM 서술. 얼굴 크롭의 외부 전송은 시드에 없다 — 케이스별 재분석을 눌러야 발생한다 (COPYRIGHTER_GOOGLE_FACE_CROP_SEARCH=true 면 장당 Vision 최대 4콜을 더 쓴다).

4. 판정

• 근거로 쓴 증거를 '사용'으로 표시한다. 안 하면 내보내기의 evidenceUsed 가 빈칸이라 "무엇을 보고 판정했나"가 사라진다.
• 판정 중에 새 이미지를 넣지 않는다. 폴더 리로드마다 전체 리스코어가 돌아 이미 판정한 케이스의 밴드가 움직이고 교차표가 소급 변동한다.
• 키보드: A 승인 · H 보류 · R→숫자 반려 · N 다음 미심사.

5. 측정

# 분모부터 — 콘솔 좌측 'S 통계' 에서 highBandDecided / lowBandDecided
# 각 5건 미만이면 비율을 해석하지 않는다 (콘솔은 색만 죽이고 숫자는 그대로 보여준다)

python scripts/sweep_thresholds.py data/corpus.sqlite3

스윕은 decisionSnapshot.riskScore(판정 시점 각인)를 쓴다. decision_stats 의 교차표는 현재 riskBand 기준이라 리스코어에 흔들리므로 확정 판단에 쓰지 않는다.

읽는 법: over = high 로 분류했는데 승인한 건수(과탐, 많으면 high 임계가 낮다). under = low 로 분류했는데 반려한 건수(미탐, 0 이 아니면 medium 임계가 높다).

참고 — 구조적 거동 실측 (판정 없이 측정한 것)

scripts/score_distribution.py 432조합 전수 + data/corpus.sqlite3 실이미지 20장. 스코어러를 바꿀 때마다 이 두 표를 다시 채운다.

이 격자는 신호 축을 균등 샘플링하므로 실제 큐 분포가 아니다. 92% 가 "실제 큐의 92% 가 high"라는 뜻이 아니며, 임계가 맞는지도 말해주지 않는다. 구조적 거동의 기준선일 뿐이고, 스코어러를 바꿀 때 전후 비교에 쓴다.

격자 432조합 — v4 → v5 (2026-09-22)

	v4 미등록	v4 등록	v5 미등록	v5 등록
high	92%	63%	75%	40%
medium	6%	29%	22%	40%
low	0%	7%	2%	18%
100점 포화	80%	38%	44%	22%
웹 신호만으로 high	13/24	0/24	0/24	0/24

(등록 = 신뢰 출처 등록.) v5 의 포화 44% 는 전부 격자의 1/3 을 차지하는 "등록 권리 대상 강한 일치(80)" 조합이다 — 등록 일치는 단독 high 로 설계했으므로 그 위의 순서는 의도적으로 포기한 것이고, 등록 일치가 없는 조합의 포화는 0 이다.

실이미지 20장 (sample/ — 전부 웹에 있는 인물 사진, 저위험 기대 이미지 0장)

	v4	v5
밴드	high 20	high 20
100점	20/20	0/20
구별되는 점수	1 (100)	4 (75 · 80 · 92 · 95)

v5 에서 20장의 순서를 만든 것은 인물 등급(배경 1장 → 75)과 이름 있는 검색 승격 유무(없음 3장 → 80, 약한 승격 4장 → 92)다. 웹 존재(40)와 라벨(10)은 20장 전부 상한에 있어 이 코퍼스 안에서는 순서를 만들지 못한다 — 웹 사본이 있는 인물 사진만 모은 코퍼스의 한계지 스코어러의 한계가 아니다. medium/low 임계 검증은 여전히 불가: 1절의 구성대로 자사 오리지널·라이선스 구매분이 들어와야 분모가 생긴다.

v4 에서 드러났고 v5 가 처리한 것

1. 웹 신호만으로 high 에 도달하는 조합이 있었다. 2026-08-09 v2 의 설계 원칙은 "웹 존재만으로는 high 가 되지 않는다. 두 번째 종류의 신호가 필요하다"였는데, presence 풀(최대 60)과 entity 풀(최대 20)의 합이 80 이라 full+partial + 엔티티 1개 만으로 high 가 됐다. 두 풀이 각각 임계 아래로 캡됐지만 합은 캡되지 않았다.
2. v3 의 제공자별 풀링이 그 경향을 키웠다. 독립 제공자가 하나 더 있으면 웹 전용 조합의 high 가 4/12 → 9/12 로 올라갔다. 교차 확증이 high 에 도달해야 한다는 v3 의 의도대로 동작한 결과지만, 총량 통제가 없었다.
3. 실이미지가 보인 세 번째 원인. 검색결과 사본 유사도가 행마다 +80, 무상한이었다 (코퍼스 평균 216점/장). 캡 없는 두 축만 캡하는 시뮬레이션(80/50, 60/40)으로도 20/20 이 그대로 100 — 축 하나가 아니라 예산 합(245 vs 100)의 문제였다.

v5 는 축 예산을 총합 기준으로 재배분했다(등록 일치 80 · 웹 존재 40 한 풀 · 인물 30/10 · 검색 승격 15 · 라벨 10 → 등록 제외 최대 95, 외부 검색 실패는 가산 대신 medium 하한). 정본은 risk_scoring.py 상단 예산표다.