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

이 프로젝트의 가장 큰 미검증 항목은 **위험도 밴드 임계(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'` 로 찍혀 스윕에서 제외된다.

```powershell
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 는 미지원이다.

```powershell
# 중복 검사 (결과가 비어야 한다)
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. 측정

```powershell
# 분모부터 — 콘솔 좌측 '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` 상단 예산표다.