"Pippa는 네 여행 인생에서 관련된 조각만 뽑아야지, 매 턴 전부를 삼키면 안 돼."
덤핑의 함정
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)이 아니라 산문에 사는 것들.
왜 나누는 게 중요해
레인을 나눠두는 게 둘 다 정직하게 지켜. 구조화된 질문은 날짜를 지어낼 수도 있는 paraphrase가 아니라 DB의 정확한 답을 받을 자격이 있어. 산문 질문은 기억인 척하는 열 값이 아니라 아빠가 진짜 쓴 글에서 뽑은 구절을 받을 자격이 있고. 뭉개면 둘 다의 최악을 얻어. 정밀한 질문엔 fuzzy한 답, 산문엔 provenance 유실. 그리고 prose 레인이 절대 안 넘는 단단한 경계가 있어. 개인 memory vault는 절대 여행 코퍼스에 안 먹여. 재사용은 형제의 검색을 그 tool 표면으로 쓰는 거지, 전부를 미분화된 index 하나로 빨아들이는 게 아냐.