"자기가 어느 텍스트를 요약했는지 모르는 요약은 언제 틀렸는지도 몰라."
파생된 것들의 문제
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 로 파일이 바뀐 걸 알아채는 그 아이디어를, 요약을 정직하게 유지하는 문제에 겨눈 거야.