"chunk에 이름을 붙이지 마. 그 chunk가 자기 내용으로 이름을 만들게 해."
id는 배정하지 않고 계산해
Lantern은 문서 내용의 해시와 chunk의 시작·끝 문자 위치, chunking profile id를 이어 붙여 SHA-256을 계산하고 앞의 16진수 32자를 chunk id로 사용해. 데이터베이스가 삽입 순서에 따라 붙인 표가 아니라, 내용과 그 내용을 자른 규칙에서 나온 지문이야.
공식에 들어가는 값마다 맡은 일이 있어
doc_sha256은 파일명이 아니라 바이트로 어느 문서인지 정해. 이름을 바꿔도 내용이 같으면 같은 문서고, 한 글자라도 고치면 다른 문서야.char_start와char_end는 디코드된 문서에서 어느 범위를 가리키는지 고정해.profile_id는 어떤 chunking 규칙으로 자른 결과인지 기록해. 같은 범위라도 다른 규칙으로 얻었다면 다른 chunk야.
삽입 시각이나 테이블 위치는 공식에 들어가지 않아. 저장한 장소와 시간을 빼야 어느 기계에서 다시 계산해도 같은 답을 얻을 수 있어.
한 공식에서 세 가지 성질이 따라와
같은 문서와 같은 범위, 같은 profile을 다시 수집하면 id도 같으니 재구축과 기계 이전을 견뎌. 동일한 내용은 같은 id로 모여 자연스럽게 중복이 줄고, 누구든 같은 값으로 id를 다시 계산해 기록이 맞는지 검증할 수 있어. Git이 blob과 commit을 내용으로 식별하고 컨테이너가 이미지 layer를 부르는 방식과 같은 생각이야.
해시를 32자로 줄이는 선택도 장단점을 따져 내린 결정이야. SHA-256 전체는 16진수 64자지만 절반만 남겨도 128비트 공간이야. 실제 개인 코퍼스에서 서로 다른 두 chunk가 같은 id를 얻을 가능성은 사실상 무시할 수 있을 만큼 작아. 이론적 여유 일부를 다루기 쉬운 주소와 바꾼 거지.
id만으로는 출처가 완성되지 않아
검색 결과에는 chunk id와 함께 코퍼스 id, 문서 경로, 문서 해시, 문자 위치, chunk 해시, profile이 따라다녀. id는 오래 가는 손잡이고 나머지 출처 정보는 원문을 다시 찾고 같은 범위를 잘라 검증하는 방법이야. 이 묶음이 있어야 몇 년 뒤 처음 검색할 때 존재하지도 않던 기계에서 해당 구절을 자신 있게 되살릴 수 있어.