"자기가 어느 텍스트를 요약했는지 모르는 요약은 언제 틀렸는지도 몰라."
파생된 것들의 문제
transcript 는 자식을 낳아: 요약, 제목, 검색 index, 어쩌면 미래의 embedding. 각각은 텍스트의 특정 버전에서 파생돼. 조용한 위험이 여기 있어: 텍스트는 바뀔 수 있는데(네가 교정했어) 파생된 자식은 자동으로 몰라. 어제의 요약이 아직 거기 앉아, 네가 이후에 고친 줄을 인용하며, 새것과 똑같이 권위 있어 보여. 시스템은 current 요약이랑 stale 요약을 어떻게 구별해?
약한 답은 타임스탬프야 — '요약이 release 보다 오래됐으니 stale 일지도.' 근데 시계는 거짓말하고, job 은 순서 어긋나게 돌고, '더 오래됨' 이 '다른 버전에서 파생됨' 을 증명하진 않아. Recall 은 대신 정확한 걸 써: content hash.
모든 자식을 부모의 hash 에 묶어
모든 release 는 content hash — 자기 정확한 텍스트에서 계산된 지문 — 를 지녀. Recall 이 요약을 생성할 때, 그 요약에 자기가 요약한 release 의 content hash 를 찍어. 요약은 자기가 어느 영상에서 왔는지만 아는 게 아냐; 텍스트의 어느 정확한 버전에서 왔는지 알아. 그 도장이 트릭 전부야.
이제 staleness 감지가 사소하고 결정적이야. 영상의 current release 를 잡아, content hash 를 읽어. 요약에 찍힌 hash 를 읽어. 같으면, 요약이 현재 텍스트를 반영해. 다르면, 요약이 만들어진 뒤 텍스트가 움직인 거야 — 요약은 증명 가능하게 stale 이고, Recall 이 재생성용으로 표시할 수 있어. 타임스탬프 없음, 추측 없음, '아마' 없음. 두 hash 는 같거나 아니거나야.
이게 분기가 타협 불가였던 이유야
지난 레슨을 돌아보면 딱 와: 교정은 정확히 content hash 가 바뀌도록 새 버전으로 분기해야 했어. 교정이 텍스트를 제자리에서 덮어썼으면, hash 가 그대로 남거나(또는 비교할 옛 버전 없이 바뀌거나) 했을 거고, 요약은 자기 소스가 움직인 걸 알 방법이 없었을 거야. 불변 run, 버전 있는 release, content-hash 도장은 하나의 목적을 가진 하나의 시스템이야: 모든 파생 산물이 자기 소스가 바뀐 걸 감지할 수 있게 만들기. 그게 lineage 에 적용한 content-addressing 이야 — 버전 관리 시스템이 파일이 hash 로 바뀐 걸 아는 그 아이디어를, 요약을 정직하게 유지하는 문제에 겨눈 거야.