POSA_Copyrighter/docs/brainstorms/2026-05-26-evidence-quality-watchlist-requirements.md
유창욱 3f7b3a9cf2 chore: initial commit of copyrighter (rights_filter)
Image rights / copyright detection system: SQLite store, HTTP app,
search integrations (Naver, Google Custom Search, Google Cloud Vision
web detection), image analysis (fingerprints, face/person detection,
evidence enrichment, risk scoring), an admin/review layer, governance
and retention policies, batch jobs, and a browser-based operator GUI.

This baseline incorporates a full code-review remediation pass
(46 fixes; 358 tests passing). Highlights:

CRITICAL
- Prevent evidence cascade-delete during the schema-constraint
  migration by disabling FK enforcement around the table rebuild.

Security
- Sandbox served media (neutralize stored XSS from uploaded/collected
  SVGs) via CSP + nosniff on the untrusted media routes.
- Strip embedded EXIF/GPS from external image derivatives before they
  are sent to third-party APIs.
- Return a clean 404 (not an uncaught StopIteration) for PATCH on an
  unknown provider.

Correctness
- LLM-summary failures no longer add +30 to the risk score.
- Decode only explicit JS escapes so Korean image URLs are not mangled.
- Consume search quota only after a successful request.
- Naver/Google adapters map responses inside the failure boundary, so a
  malformed response degrades to evidence instead of crashing enrichment.
- Domain-aware provider attribution; face-box IoU de-duplication; count
  searches (not result items); per-box crop isolation; clamp evidence
  confidence and Google CSE num; real submittedEpoch; and more.

Robustness
- Offline LLM connect fast-fails (short connect timeout) so seed/reload
  requests are not stalled; full read timeout preserved for generation.
- Malformed numeric env vars fall back to defaults instead of crashing
  startup.

Performance
- Per-submission evidence reads (no full-table scan per rescore),
  audit-log LIMIT, lazy active-store lookup, hoisted timestamps.

Tests
- ~24 regression tests added pinning the above fixes.

Runtime data (data/, outputs/, *.sqlite3, *.log), secrets (.env), and
node_modules are gitignored.
2026-06-09 09:50:31 +09:00

148 lines
9.9 KiB
Markdown

---
date: 2026-05-26
topic: evidence-quality-watchlist
---
# Evidence Quality And Watchlist Growth
## Summary
근거 품질 관리와 기준 DB 성장을 하나의 운영 루프로 묶는다. 운영자는 케이스 판정을 먼저 내리고, 보류 또는 반려된 케이스에서 사용된 근거는 자동으로 주의 후보가 되어 이후 유사 케이스를 강하게 검출한다.
---
## Problem Frame
현재 시스템은 Google, Naver, 내부 지문, 얼굴 영역 웹 근거를 모아 운영자에게 보여줄 수 있다. 하지만 검색 결과와 약한 근거가 많아질수록 운영자는 어떤 근거를 실제 판단에 써야 하는지 구분해야 하고, 잘못된 근거가 기준 DB에 섞이면 이후 분석 품질이 흔들릴 수 있다.
반대로 이 프로젝트의 운영 목적은 최대한 많은 위험 후보를 잡아 나중의 파급효과를 줄이는 것이다. 따라서 보류와 반려 케이스를 적극적으로 다음 탐지에 반영하되, 확정 기준 DB와 주의 후보를 구분해 운영자가 근거의 출처와 확정 수준을 볼 수 있어야 한다.
---
## Actors
- A1. 운영자: 근거를 검토하고 케이스를 승인, 보류, 반려 중 하나로 최종 판정한다.
- A2. 권리 리스크 필터: 근거를 수집하고, 근거 상태와 케이스 판정을 바탕으로 위험도와 후보를 갱신한다.
- A3. 기준 DB 관리자: 주의 후보를 확정 기준 DB로 승격하거나 오탐 제외 처리한다. 초기 운영에서는 운영자가 이 역할을 겸할 수 있다.
---
## Key Flows
- F1. 근거 상태 표시
- **Trigger:** 운영자가 케이스 상세 화면에서 수집된 근거를 검토한다.
- **Actors:** A1, A2
- **Steps:** 운영자는 각 근거를 판단에 사용, 무관, 오탐, 보류 중 하나로 표시한다. 이 표시는 해당 케이스 판단을 돕는 상태이며 기준 DB 편입을 즉시 의미하지 않는다.
- **Outcome:** 케이스 안에서 어떤 근거가 판단에 쓰였는지 남는다.
- **Covered by:** R1, R2, R3
- F2. 케이스 판정 후 주의 후보 생성
- **Trigger:** 운영자가 케이스를 보류 또는 반려로 판정한다.
- **Actors:** A1, A2
- **Steps:** 시스템은 판단에 사용된 근거와 제출 이미지 지문을 묶어 주의 후보를 자동 생성한다. 승인 케이스에서는 자동 후보를 만들지 않는다.
- **Outcome:** 보류와 반려 케이스가 이후 탐지 기준으로 누적된다.
- **Covered by:** R4, R5, R6, R7
- F3. 주의 후보 기반 재검출
- **Trigger:** 새 제출 이미지가 들어오거나 기존 케이스가 재분석된다.
- **Actors:** A2
- **Steps:** 시스템은 새 이미지와 주의 후보의 이미지 지문, 근거 패턴, 관련 키워드를 비교한다. 유사성이 높으면 확정 기준 DB와 거의 같은 강도로 위험도를 올리되, 화면에는 주의 후보 기반 감지로 분리 표시한다.
- **Outcome:** 확정되지 않은 보류/반려 기반 신호도 강하게 검출된다.
- **Covered by:** R8, R9, R10
- F4. 후보 승격과 오탐 제외
- **Trigger:** 운영자가 후보 관리 화면에서 주의 후보를 검토한다.
- **Actors:** A1, A3, A2
- **Steps:** 운영자는 주의 후보를 확정 기준 DB로 승격하거나 오탐 제외 처리한다. 오탐 제외된 후보와 근거 패턴은 이후 우선순위와 점수 반영이 낮아진다.
- **Outcome:** 많이 잡는 전략을 유지하면서 DB 오염을 줄인다.
- **Covered by:** R11, R12, R13
---
## Requirements
**근거 품질 상태**
- R1. 시스템은 근거별 상태로 판단에 사용, 무관, 오탐, 보류를 제공해야 한다.
- R2. 근거별 상태는 기준 DB 편입을 즉시 발생시키지 않고, 먼저 케이스 판단 맥락에만 귀속되어야 한다.
- R3. 무관 또는 오탐으로 표시된 근거는 기본 근거 목록에서 낮은 우선순위로 이동하거나 접힌 상태로 보여야 한다.
**케이스 판정 기반 후보 생성**
- R4. 기준 DB 후보 생성은 케이스 판정 이후에만 일어나야 한다.
- R5. 보류 케이스는 자동으로 주의 후보를 생성해야 한다.
- R6. 반려 케이스는 자동으로 주의 후보를 생성해야 한다.
- R7. 승인 케이스는 자동으로 주의 후보 또는 확정 기준 DB 항목을 생성하지 않아야 한다.
**주의 후보의 점수 반영**
- R8. 주의 후보와 유사한 새 제출은 확정 기준 DB와 거의 같은 강도로 위험도에 반영되어야 한다.
- R9. 주의 후보 기반 감지는 확정 기준 DB 감지와 UI에서 명확히 구분되어야 한다.
- R10. 주의 후보 기반 감지는 자동 반려나 자동 승인으로 이어지지 않고 운영자 검토 우선순위를 높이는 용도로만 사용되어야 한다.
**후보 관리와 오염 방지**
- R11. 운영자는 주의 후보를 확정 기준 DB로 승격할 수 있어야 한다.
- R12. 운영자는 주의 후보 또는 근거 패턴을 오탐 제외 처리할 수 있어야 한다.
- R13. 오탐 제외된 후보나 근거 패턴은 이후 위험도 반영과 표시 우선순위가 낮아져야 한다.
- R14. 확정 기준 DB와 주의 후보는 같은 목록에 섞이더라도 상태, 출처, 판정 케이스가 구분되어야 한다.
**운영 가시성**
- R15. 각 기준 DB 항목과 주의 후보는 어떤 케이스 판정에서 생성되었는지 추적 가능해야 한다.
- R16. 각 기준 DB 항목과 주의 후보는 이후 몇 번 위험 판단에 기여했는지 운영자가 볼 수 있어야 한다.
- R17. 후보 생성, 승격, 오탐 제외, 근거 상태 변경은 감사 로그에 남아야 한다.
---
## Acceptance Examples
- AE1. **Covers R1, R2, R4, R5.** 운영자가 케이스 근거 3개 중 2개를 판단에 사용으로 표시하고 케이스를 보류하면, 시스템은 그 2개 근거와 제출 이미지 지문을 바탕으로 주의 후보를 자동 생성한다.
- AE2. **Covers R1, R2, R6.** 운영자가 근거를 판단에 사용으로 표시했더라도 케이스 판정을 아직 내리지 않았으면 기준 DB 후보는 생성되지 않는다.
- AE3. **Covers R7.** 운영자가 케이스를 승인하면 판단에 사용으로 표시된 근거가 있어도 자동 주의 후보는 생성되지 않는다.
- AE4. **Covers R8, R9, R10.** 새 이미지가 기존 주의 후보와 강하게 유사하면 위험도가 크게 오르고 근거 그룹에 주의 후보 기반 감지로 표시되지만, 케이스 상태는 자동 변경되지 않는다.
- AE5. **Covers R11, R14, R15.** 운영자가 주의 후보를 확정 기준 DB로 승격하면 해당 항목은 확정 상태, 원래 판정 케이스, 샘플 이미지, 별칭/키워드 정보를 함께 가진다.
- AE6. **Covers R12, R13.** 운영자가 특정 주의 후보를 오탐 제외하면 이후 유사 이미지가 들어와도 해당 후보는 강한 위험도 근거로 쓰이지 않고 낮은 우선순위 참고로만 남는다.
---
## Success Criteria
- 운영자는 근거가 많아도 판단에 쓸 근거와 버릴 근거를 빠르게 구분할 수 있다.
- 보류와 반려 케이스가 자동으로 다음 탐지 품질을 높여, 초기 기준 DB가 부족해도 위험 후보를 많이 잡을 수 있다.
- 강직한 검출 전략을 유지하면서도 확정 기준 DB, 주의 후보, 오탐 제외가 분리되어 DB 오염을 추적하고 줄일 수 있다.
- 구현 계획 단계가 후보 생성 시점, 보류 케이스 처리, 주의 후보의 점수 강도, UI 구분 방식을 새로 invent하지 않아도 된다.
---
## Scope Boundaries
- 근거 상태는 케이스 판정을 대체하지 않는다.
- 주의 후보는 자동 생성되지만 확정 기준 DB 승격은 운영자 검토를 거친다.
- 주의 후보가 위험도를 강하게 올리더라도 자동 반려, 자동 보류, 자동 승인 상태 변경은 하지 않는다.
- 얼굴 임베딩, 특정 개인 식별용 생체 템플릿, 얼굴 유사도 DB는 만들지 않는다.
- Google Image Search, Google Lens, Naver 웹 UI 자동화나 스크래핑은 포함하지 않는다.
- 신청자에게 근거 상태, 주의 후보, 위험도 산식, 내부 판단 근거를 노출하지 않는다.
---
## Key Decisions
- 케이스 판정 우선: 근거 상태는 중간 판단 보조이며 DB 후보 생성은 보류/반려 판정 이후에만 발생한다.
- 보류까지 자동 후보화: 파급효과를 줄이기 위해 보류 케이스도 위험 신호로 적극 누적한다.
- 주의 후보 강반영: 주의 후보는 확정 DB와 거의 같은 강도로 위험도에 반영하되 UI에서는 출처를 분리한다.
- 확정과 주의 분리: 많이 잡는 전략을 유지하되, 운영자가 확정 기준과 주의 기준을 구분할 수 있게 한다.
- 오탐은 학습 신호: 오탐 제외는 단순 숨김이 아니라 이후 우선순위와 점수 반영을 낮추는 운영 피드백으로 사용한다.
---
## Dependencies / Assumptions
- 현재 시스템은 이미지 지문과 기준 DB 유사도 분석을 이미 갖고 있으므로 주의 후보도 같은 이미지 수준 지문 기반으로 시작할 수 있다.
- 얼굴 관련 처리는 현재 정책처럼 얼굴 영역 웹 근거와 사람/얼굴 존재 신호에 한정하며, 생체 인식 저장소로 확장하지 않는다.
- 실제 점수 가중치는 구현 계획에서 현재 위험도 산식과 테스트를 확인해 정한다.
---
## Outstanding Questions
### Deferred to Planning
- [Affects R8, R13][Technical] 주의 후보 강반영 점수를 확정 DB와 완전히 같게 둘지, 약간 낮게 둘지 현재 위험도 산식과 함께 결정해야 한다.
- [Affects R3, R9][Technical] UI에서 주의 후보 기반 감지와 확정 DB 감지를 어떤 근거 그룹과 배지로 분리할지 정해야 한다.
- [Affects R12, R13][Technical] 오탐 제외가 URL, 이미지 지문, 제목, 도메인 중 어느 범위까지 전파되는지 정해야 한다.