덤핑이 아니라 검색

"Pippa 는 네 여행 인생의 관련 조각을 query 해야지, 매 턴 전부를 삼키면 안 돼."

덤핑의 함정

Waystone 의 전제 전부가 기억이 복리로 쌓인다는 거야 — 그래서 몇 년 지나면 그게 많아. Pippa 한테 그 기억을 주는 순진한 방법은 매 턴 지난 여행 전부와 로그 전부를 prompt 에 쑤셔넣는 거야. 그게 context 덤핑이고, 두 번 실패해: model 을 무관함에 익사시키고, 처음 몇 개 journey 넘어가면 확장이 안 돼. 옳은 수는 context 검색이야 — 활성 journey·목적지·계절·여행자·질문·링크된 장소·과거 결과로 고른 관련 조각을 query. 목표는 한 번에 전부 아는 게 아니라, 이번 턴이 필요한 걸 딱 뽑는 거야.

두 레인, 두 소유자

여행 기억이 두 다른 형태라서 검색은 두 다른 레인으로 돌아:

• structured 레인. 결정적·집계 질문 — 엄마가 어떤 곳을 즐겼나, 어떤 계획이 날씨에 죽었나, 피로 대 호텔 이동 — 은 canonical Waystone state 를 자기 tool 표면으로 query 해서 답해. 이 레인은 정확하고, 여행 도메인 store 를 절대 안 떠나. 구조화된 fact 를 fuzzy-search 하지 않아. query 해.
• prose 레인. 조립된 일일 entry, 결정 rationale, 링크된 글 로그가 안정되면, 이것들을 코퍼스로 capture 해서 consultation 이 실제로 쓰인 것 을 durable chunk 단위 provenance 로 인용할 수 있게 해. 이 레인은 의미와 표현을 위한 거야 — 열(column)이 아니라 산문에 사는 것들.

왜 분리가 중요한가

레인을 분리해 두는 게 각각을 정직하게 지켜. 구조화된 질문은 날짜를 hallucinate 할 수도 있는 paraphrase 가 아니라 DB 의 정확한 답을 받을 자격이 있어. 산문 질문은 기억인 척하는 열 값이 아니라 아빠가 실제로 쓴 것에서 인용된 구절을 받을 자격이 있어. 뭉개면 둘 다의 최악을 얻어: 정밀한 질문에 fuzzy 한 답, 산문의 provenance 유실. 그리고 prose 레인이 절대 안 넘는 하드 경계가 있어 — 개인 memory vault 는 절대 여행 코퍼스에 안 먹여. 재사용은 형제의 검색을 그 tool 표면으로 소비하는 거지, 전부를 하나의 미분화된 index 로 빨아들이는 게 아냐.