"흔들리는 부분을, 그 실패가 어깨 으쓱이지 크래시가 아닌 곳에 둬. 나머지 전부가 그 한 배치에서 따라와."
다들 모델을 어디 두는가
기본 RAG 모양은 언어 모델을 검색 흐름 안에 둬. 질문하면, 시스템이 chunk 몇 개를 검색하고, 프롬프트에 쑤셔 넣고, 모델이 답을 써. 모델이 하중을 받아: 그게 없으면 결과 자체가 없어. 검색과 생성이 한 파이프라인으로 융합되고, 그 파이프라인은 그 안에서 가장 안 믿을, 가장 느린, 가장 재현 안 되는 것 — 모델 — 만큼만 믿을 만하고, 빠르고, 재현 가능해.
Lantern 은 어디 두는가
Lantern 은 선을 한 단계 위에 그어. 엔진의 일은 찾기에서 끝나: 인용 가능한 조각을, 순위 매겨, provenance 와 함께 돌려줘. 그 자체로 완전하고 쓸모 있는 결과야 — 조각을 읽고, 인용하고, UI 에 보여줄 수 있어. 판단 — 그 조각을 답으로 바꾸고, 뜻을 정하고, 산문을 쓰는 것 — 은 API 위에서, 별도 뇌에서, 별도 단계로 일어나. 모델은 여전히 그림 안에 있어. 그냥 경로 안에 없을 뿐이야.
모델이 약한 고리인 이유
세 속성이 언어 모델을 기반으로 의존하기에 틀린 것으로 만들어:
- 비싸. 모든 호출이 돈이나 GPU 시간을 써. 키 누를 때마다 돌리는 검색은 그걸 감당 못 해.
- 비결정론적이야. 같은 쿼리가 다른 출력을 낼 수 있어. 매번 다른 답을 주는 기반은 기반이 아냐.
- 가끔 안 돼. 서버가 꺼지고, rate limit 에 걸리고, 네트워크가 끊겨. 찾기가 모델에 의존하면, 모델이 꺼졌을 때 찾기도 꺼져.
그중 어느 것도 엔지니어링으로 없앨 결함이 아냐 — 그것의 본성이야. 그러니 그에 맞게 배치해.
보상은 믿을 수 있는 기반이야
찾기가 인덱스와 쿼리의 순수 함수가 되면, 하류 전부가 더 튼튼해져. 검색이 싸니까 키 누를 때마다 돌아. 아무것도 주사위를 안 굴리니까 결과가 재현돼. 모델 서버가 리부팅 중인 새벽 3시에도 코퍼스를 쿼리할 수 있어. 그 전부를 모델이 어디 앉는가 에 대한 단 하나의 결정으로 산 거야 — 엔진 안이 아니라, 위에.