한 질문, 두 검색 lane

lexical은 이름을 붙잡아

FTS5는 정확한 단어, path fragment, 고유명, quoted phrase에 강해. 특정 failure code나 product 이름을 기억할 때 vector가 의미상 가까운 일반 문장을 먼저 올리는 것보다 exact match가 훨씬 낫지.

또 결과가 왜 나왔는지 설명하기 쉽다. 어떤 token과 field가 matched인지 보여줄 수 있고, index rebuild도 text에서 deterministic하게 수행돼. 하지만 표현이 완전히 달라지면 같은 의미를 놓쳐.

semantic은 다른 말을 이어

vector lane은 표현이 달라도 의미가 가까운 memory를 찾는다. '매번 읽는 비용'을 검색했을 때 'session boot token weight' note를 올릴 수 있어. duplicate candidate와 Related panel에 특히 유용해.

대신 model과 chunking과 pooling이 결과에 숨어 있어. score가 높다는 이유만으로 같은 기억이라고 결론 내릴 수 없고, 고유명이나 짧은 code token은 lexical보다 약할 수 있어.

lane을 먼저 분리해 보여

hybrid result만 주면 어느 lane이 무엇을 찾았는지 잃어. debug할 때 FTS가 깨졌는지 embedding이 stale한지 모르고, 사용자는 semantic guess를 exact match로 오해해.

UI는 All, Text, Meaning 같은 lane을 노출하고 fused card에도 lexical rank와 vector rank를 붙일 수 있어. 동일 item은 합치되 evidence는 지우지 않는 거야.

권한 filter는 fusion 전후 모두 방어해

가장 안전한 구현은 candidate fetch부터 actor scope를 좁히고, fusion 뒤 반환 직전 다시 policy를 확인해. vector store가 모든 vault를 index하더라도 super fragment가 unauthorized context로 나가면 안 돼.

filter 때문에 결과가 적어졌다는 사실은 보여줄 수 있지만 protected title이나 snippet을 leak하면 안 돼. retrieval quality와 authorization correctness를 같은 metric으로 평가하지도 마.

lexical과 semantic은 경쟁 모델이 아니라 서로 다른 blind spot을 가진 두 관측 lane이야. 순서는 합쳐도 lane provenance와 permission 경계는 지우지 마.

Code

SQLite FTS5의 exact-term lane·sql

CREATE VIRTUAL TABLE notes USING fts5(path, body);
INSERT INTO notes(path, body) VALUES
  ('memory/weight.md', 'session boot token weight'),
  ('memory/restore.md', 'forward write recovery');
SELECT path, bm25(notes) AS rank
FROM notes
WHERE notes MATCH '"session boot"'
ORDER BY rank;

lexical은 이름을 붙잡아

semantic은 다른 말을 이어

lane을 먼저 분리해 보여

권한 filter는 fusion 전후 모두 방어해

Code

External links

Exercise

Progress

댓글 0