4b74f9577a
배포 판단에서 파일럿 전 유일한 차단으로 꼽은 구멍. 네이버 일일 한도 100 = 20장이라 21장째부터 검색이 SEARCH_SKIPPED 0점·무사유로 빠져 점수가 낮게 나왔다. 정책 거절 사유 중 하루 안에서 케이스마다 달라지고 어디에도 안 보이는 하나(usage limit reached)만 v5 의 실패 하한 30 에 합류시키고 사유에 '<provider> 미수행 — <사유>' 를 남긴다. disabled 는 키 미설정 배포와 비상 차단이 같은 사유를 쓰고 둘 다 콘솔 providerState 에 보이므로 그대로 0점·무사유 — 하한을 걸면 키 없는 배포의 큐 전체가 medium 이 된다(기본 스토어 테스트가 잡아냈다). 거버넌스 스위치(compliance·metadata logging·online mode)도 0. 라운드트립은 신선 점수·사유를 재현한다(provider 는 domain 으로 복원). 다이어그램 태그 v6. verify.ps1: ruff clean, 657 passed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BStHFrjQj2VypecSG9ex1V
159 lines
9.1 KiB
Markdown
159 lines
9.1 KiB
Markdown
# 캘리브레이션 코퍼스 — 실이미지로 밴드 임계를 검증하는 절차
|
|
|
|
이 프로젝트의 가장 큰 미검증 항목은 **위험도 밴드 임계(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'` 로 찍혀 스윕에서 제외된다.
|
|
|
|
```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` 상단 예산표다.
|