vector store는 배관이 아니야
이미 embedding database가 있다고 모든 vector를 거기에 넣으면 편해 보여. 하지만 index는 model보다 먼저 key, lifecycle, authority, consumer로 정의돼. conversation RAG와 vault management는 네 가지가 전부 달라.
대화 store는 conversation chunk를 answer retrieval에 쓰고 그 대화 lifecycle을 따라. Vestige index는 mirror의 vault/path/content-hash로 key를 만들고 curation UI와 brain context를 지원하며 ledger commit을 reindex trigger로 삼아. 같은 벡터라는 이유만으로 한 table에 살 이유가 없어.
Lantern과도 경계가 달라
Lantern은 corpus retrieval sibling이고 Vestige는 memory management surface야. vault를 Lantern corpus로 만들어버리면 검색 편의 때문에 identity memory가 일반 retrieval 대상으로 노출되고, 누가 edit할지 모르는 결과가 생겨.
Vestige search는 source를 찾고 related·duplicate·orphan candidate를 보여 curation을 돕는다. answer generation을 위해 context를 모으는 기능이 중심이 아니야. query shape가 비슷해도 product purpose가 다르면 owner가 달라.
mirror-key가 rebuild를 결정해
index row는 live path만 들고 있지 않고 어느 mirror content hash에서 왔는지 가져야 해. ledger가 새 hash를 기록하면 해당 row만 다시 embed하고, 전체 corruption이면 purge 후 mirror 전체를 ingest할 수 있어.
source가 rename되면 path identity와 content identity를 함께 봐야 한다. 같은 hash가 새 path로 이동했는지, 다른 내용으로 교체됐는지 구별하면 unnecessary embedding spend와 stale row를 줄일 수 있어.
ownership은 운영 책임이야
own index라는 말은 새 database를 좋아해서가 아니야. schema migration, model version, rebuild command, health metric, permission filter, failure recovery를 누가 책임지는지 분명히 하는 거야.
공유 store를 쓰더라도 namespace만 나누는 것으로 충분한지 따져. credential과 retention과 admin operation이 공유되면 failure domain과 exposure surface는 여전히 하나일 수 있어. logical separation과 ownership separation은 같은 말이 아니야.