RAG-인-어-박스 말고, 코퍼스 엔진을 짓는 이야기
Lantern 의 탄생 이야기 — 이미지 엔진 Ember 와 음악 엔진 Bonfire 의 검색 형제, 아빠가 직접 만든 코퍼스 엔진. RAG 서비스를 빌리는 대신 내가 쓴 말을 다시 찾아주는 결정론적 엔진을 직접 짓는 이유, 그리고 모든 설계 선택이 '내가 뭘 썼는지 기억하는 방식을 소유한다'는 게 뭔지 가르쳐주는 이야기.
8 tracks · 33 lessons · ~6h · difficulty: intermediate-to-advanced
Lantern 이 뭔지, 이름이 왜 곧 주제인지, 왜 존재하는지
검색 메커니즘보다 먼저, 방향 잡기. Lantern 은 코퍼스 엔진이야 — RAG 챗봇도, 리본 달린 벡터 DB 도, 두 번째 뇌도 아냐. 이 트랙에서 이름을 풀고(랜턴은 들고 다니는 불), 엔진 형제 가족 안에 Lantern 을 놓고, 두-Pippa 탄생 이야기를 들려주고, 엔진 전체가 풀려고 존재하는 단 하나의 문제를 잡아 — 열두 집에 흩어진 10년 치 글.
핵심 베팅 — 선언으로 모으고, 파일은 절대 안 건드려
창립 함정은 모으려고 파일을 옮기는 거였어. 이 트랙은 그 대안을 통째로 지어: 글이 이미 사는 곳을 이름 붙이는 선언적 manifest, 읽되 다시 쓰지 않는 idempotent 순회, 두 코퍼스 클래스(referenced 와 captured), 그리고 유일하게 버릴 수 없는 저장소 — captured 텍스트를 영원히 보존하는 스냅샷 레이어.
경로에 모델 없음 — 찾는 건 지루하게 두고, 판단은 위에서
엔진 전체의 안티-하이프 척추. 다들 검색에 언어 모델을 볼트로 박고 모델의 의견을 '검색' 이라 불러. Lantern 은 거부해: 검색 경로 어디에도 모델 호출 없음, 그래서 뇌가 안 닿아도 검색은 돌아. 이 트랙은 그 규율을 지어 — 왜 모델이 API 위로 가는지, 결정론 보장이 뭘 벌어주는지, 왜 Lantern 이 RAG 챗이 아닌지, 그리고 왜 degraded 검색이 조용히 거짓말하는 대신 자기를 알려야 하는지.
content-addressed chunk id — citation 이 다음 재색인에서 절대 안 죽게
엔진이 첫날부터 지는 단 하나의 앞을 보는 의무. 인덱스를 재구축할 때 깨지는 citation 은 쓸모없어. 이 트랙은 내구성 레이어를 지어: 왜 깨지기 쉬운 citation 이 기본 실패인지, content-addressed chunk id 가 재색인과 기계 이전을 어떻게 견디는지, 왜 chunking profile 이 불변이어야 하는지, 그리고 완전히 버릴 수 있는 인덱스가 어떻게 절대 안 깨지는 citation 을 여전히 쥘 수 있는지.
하이브리드 검색과 키스트로크 자동완성은 물리가 달라
엔진의 검색 심장, 통째로. 시맨틱 검색과 phrase 자동완성은 비슷해 보이고 전혀 안 닮았어 — 다른 latency 예산, 다른 메커니즘, 다른 실패 모드. 이 트랙은 둘 다 지어: 왜 API 가 둘을 합치길 거부하는지, 전문 BM25 순위가 어떻게 작동하는지, dense 벡터와 Reciprocal Rank Fusion 이 어떻게 결합하는지, 왜 rerank 가 기본이 아니라 심화 패스인지, 그리고 자동완성이 네트워크 하나 없이 어떻게 키스트로크 속도를 치는지.
텍스트가 들어오는 법 — chunk 하고, adapt 하고, 봉합선에서 정제해
raw 소스가 검색 가능한 chunk 가 되는 곳. 이 트랙은 수집 레이어를 지어: 검색의 원자로서의 chunk 와 왜 문서 통째가 변형의 최소 단위인지, 파일이 곧 텍스트인 단순한 referenced adapter, PDF 와 HTML 오염 콘텐츠를 깨끗한 prose 로 바꾸는 captured adapter, 그리고 정제가 변환 봉합선에서 일어나지 — 원본을 제자리에서 편집해서가 절대 아니라는 — 힘겹게 얻은 규칙.
고정된 passage, 입장 있는 claim, 결정론적 재검증
앞의 안정적인 chunk id 위에 지어진 제품 천장. 검색은 텍스트를 찾고, 증거는 거기서 뭘 결론 냈는지 기록해. 이 트랙은 그 레이어를 지어: 왜 고정된 passage 가 포인터를 믿는 대신 정확한 텍스트를 복사하는지, claim 과 입장 있는 citation 이 어떻게 판단을 API 위에 두는지, 모순이 어떻게 claim 사이의 타입 링크가 되는지, 그리고 재검증이 어떻게 문자열 동등 비교만으로 정직하게 남는지.
세 표면, 클라이언트보다 엔진 먼저, 그리고 왜 빌리지 않고 짓는가
마무리 규율. 이 가족엔 세 검색 표면이 공존하고 어느 것도 다른 걸 흡수 못 해 — '모든 검색을 통합해' 본능에 저항하는 건 아키텍처 행위야. 이 트랙이 퀘스트를 닫아: 표면을 분리해 두는 경계 표, 클라이언트를 쉽게 만든 엔진-먼저 빌드 순서, 코퍼스 엔진을 빌리지 않고 짓는 정직한 논거, 그리고 내가 쓴 말을 다시 찾는 방식을 소유한다는 게 실제로 뭘 뜻하는지.
아직 댓글이 없어요. 첫 댓글을 남겨보세요.