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장째에 고갈된다. 고갈분은 SEARCH_SKIPPED 0점으로 조용히 처리되므로(risk_scoring.py 가 skipped 를 운영 상태로 보고 건너뛴다) 앞쪽과 뒤쪽 이미지의 증거 밀도가 달라진다.

.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 임계가 높다).

참고 — 2026-09-22 시점의 구조적 거동 (판정 없이 측정한 것)

scripts/score_distribution.py 로 432조합을 전수 계산한 결과(스코어러 v4):

	신뢰 출처 미등록	신뢰 출처 등록
high	92%	63%
medium	6%	29%
low	0%	7%
100점 포화	80%	38%
웹 신호만으로 high	13/24	0/24

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

여기서 드러난 것 두 가지:

1. 웹 신호만으로 high 에 도달하는 조합이 있다. 2026-08-09 v2 가 세운 설계 원칙은 "웹 존재만으로는 high 가 되지 않는다. 두 번째 종류의 신호가 필요하다"였는데, presence 풀(최대 60)과 entity 풀(최대 20)의 합이 80 이라 full+partial + 엔티티 1개 만으로 high 가 된다. 두 풀이 각각 임계 아래로 캡됐지만 합은 캡되지 않는다.
2. v3 의 제공자별 풀링이 그 경향을 키웠다. 독립 제공자가 하나 더 있으면 웹 전용 조합의 high 가 4/12 → 9/12 로, 전체 high 비율이 88% → 97% 로 올라간다. 교차 확증이 high 에 도달해야 한다는 v3 의 의도대로 동작한 결과지만, 총량 통제가 없다.

대응 후보(미적용, 결정 필요): 웹 유래 점수 총합에 상한을 두어 제공자 수와 무관하게 웹 신호만으로는 high 에 닿지 않게 한다. 적용하면 SCORER_VERSION 을 올리고 이 표를 다시 측정해야 한다.