두 개의 판단

"같은 문장이 나한텐 완벽히 쓸모 있고 그걸 인용하는 기계한텐 적극적으로 위험할 수 있어."

transcript 하나, 아주 다른 두 운명

진짜 결함이 든 transcript 하나를 잡아 — model 이 조용한 구간에 상투구를 hallucinate 했고, 이름을 한 번 잘못 들었어. 이제 그 동일한 텍스트가 다른 두 소비자를 만나는 걸 봐:

Recall 검색. 어떤 구절을 검색하고, hit 을 받고, 그 타임스탬프의 영상으로 클릭해 들어가. hallucinate 된 줄? 네가 검색할 만한 것과 하나도 안 맞으니, 볼 일이 없어. 잘못 들은 이름? 영상을 열고, 진짜 단어를 듣고, 넘어가. 결함이 무해해, 소스가 클릭 하나 거리고 사람이 사용 지점에서 검증하니까.
지식 corpus. 같은 텍스트가 검색돼 하류에서 사실로 인용돼. 아무도 영상을 안 열어. 잘못 들은 이름이 이제 아빠가 한 적 없는 것에 대한 자신만만하고 출처 있어 보이는 주장이야. 결함이 위험해, 검증 loop 이 없으니까 — 텍스트가 곧 증거야.

같은 바이트. 반대 평결. 이건 해결할 모순이 아냐; 문제의 실제 구조야.

적합성은 데이터의 속성이 아냐

이 퀘스트 전체에서 가져갈 만한 아이디어가 여기 있어: '이 데이터 좋아?' 는 잘 형성된 질문이 아냐. 적합성은 데이터만의 속성이 아냐 — (데이터, 소비자, 검증 loop) 삼중항의 속성이야. 셋 중 하나만 바꿔도 바이트는 그대로인 채 답이 바뀌어. 잡음 있는 transcript 는 소스를 확인하는 소비자한텐 적합하고 blind 로 인용하는 소비자한텐 부적합해. 그러니 데이터에 찍힌 단일 '품질: 좋음' 플래그는 범주 오류야: 누가 묻고 뭘로 확인할지 안 대면 답할 수 없는 질문에 답하니까.

그래서 Recall 은 임계값 하나를 튜닝하는 대신 두 판단을 구조적으로 분리해. 검색 판단은 관대해도 돼 — 사람이 loop 을 닫으니까. corpus 판단은 엄격해야 해 — 하류에서 아무것도 loop 을 안 닫으니까. 구조 품질 점수(트랙 3) 는 둘 다에 정보를 주고 둘 다를 결정 안 해, 정확히 그게 텍스트의 속성이고 결정은 사용의 속성이라서.

검증 loop 을 찾고, 그다음 기준을 정해

이게 주는 실전 수는 데이터가 네 손을 떠나는 모든 경계에서 물을 질문이야: 누가, 어디서 검증해? 사람이 사용 순간에 소스를 보면, 잡음을 견딜 수 있어 — loop 이 잡으니까. 데이터가 그걸 확정된 사실로 다루는 뭔가에 소비될 거면, loop 이 사라졌고 네 기준이 보상하려 올라가야 해. 기준은 데이터가 얼마나 깨끗해 보이냐로 정해지지 않아; 그 하류에 검증이 얼마나 존재하냐로 정해져. Recall 의 격리 전체가 그냥 이 원리를 기계화한 거야: 검색은 자기 loop 을 유지하고 관대하게 남고; corpus 엔 loop 이 없으니, 승인이 기본값 아니오고 사람만이 아니라고 말할 수 있어.

Code

release 하나, 소비자 둘, 다른 기준 둘·python

# 같은 release 객체를, 두 번, 다르게 판단.

def usable_for_search(release) -> bool:
    # 사람이 loop 을 닫음: hit -> 영상 열기 -> 검증.
    # 잡음은 견딜 만함; 소스가 클릭 하나 거리.
    return release.has_segments()          # 일부러 관대하게

def eligible_for_corpus(release) -> bool:
    # 하류에 loop 없음: 텍스트가 곧 증거, 사실로 인용됨.
    # 그래서: 기본값 거부, 사람 승인만.
    return (release.status in ('reviewed', 'published')
            and release.corpus_eligibility == 'approved')

# quality_score 는 둘 다에 정보를 주고 둘 다를 결정 안 함 --
# 그건 텍스트의 속성이고; 적합성은 사용의 속성이다.

Exercise

네 일에서 소비자가 둘 이상인 데이터셋이나 출력을 하나 잡아 — 눈으로도 보고 알림도 거는 로그, 훑기도 하고 집계도 하는 스크랩, 유저에게 보이면서 저장도 되는 model 출력. 소비자마다 검증 loop 을 대: 누가, 어느 순간에 확인해? 그다음 소비자별로 별도 기준을 정해. 단일 'validated' 플래그가 지금 아주 다른 loop 을 가진 두 소비자를 섬기는 데가 있는지 적어봐.

Hint

냄새는 문 둘을 지키는 품질 gate 하나야. 소비자별로 물어: 이 record 가 미묘하게 틀리면, 누가 언제 알아채? 답이 '사람이, 즉시, 소스를 앞에 두고' 인 데선 관대해도 돼. '아무도 — 그냥 쓰여' 인 데선, 데이터가 동일해도 그 소비자한텐 자기만의 더 엄격한 기본-거부 gate 가 필요해.