向量化 · 入库索引 · 召回

路径 A：知识库章节主动 + 顺带

嵌入文本由三段拼成，中间用换行连接后截断：

[title, summary ?? "", contentMd] .map(trim).filter(Boolean) .join("\n") .slice(0, 4000)

路径 B：对话消息后台异步

这条路径在回答的热路径上，所以设计目标是「一秒都不能拖」：

insert into petrichor_assistant_message_embedding (message_id, thread_id, user_id, excerpt_md, embedding, created_at) values ($1, $2, $3, $4, $5::vector, now()) on conflict (message_id) do update set excerpt_md = excluded.excerpt_md, embedding = excluded.embedding

模型配置 ai/embedding.ts · config-logic.ts

索引 DDL full-migration.ts

两个扩展、两个 HNSW、一个 GIN，全部 if not exists：

create extension if not exists pg_trgm; create extension if not exists vector; alter table petrichor_kb_wiki_tree_node add column if not exists embedding vector(1024); create index if not exists idx_petrichor_kb_wiki_tree_node_embedding on petrichor_kb_wiki_tree_node using hnsw (embedding vector_cosine_ops); create index if not exists idx_petrichor_assistant_message_embedding on petrichor_assistant_message_embedding using hnsw (embedding vector_cosine_ops); create index if not exists petrichor_assistant_message_embedding_fts_idx on petrichor_assistant_message_embedding using gin (to_tsvector('simple', coalesce(excerpt_md, '')));

注意 kb_wiki_tree_node.embedding 故意不在 Drizzle schema 里声明： 声明了会让 select() 全列查询在没有该列的 SQLite 本地库上直接报错。这一列只走原生 SQL 读写。

还有一列向量，但已经没人读了

迁移脚本里还有第三处 vector(1024)：petrichor_agent_memory.embedding， 连同它的 HNSW 索引一起保留在 full-migration.ts 里，原本用于旧问答 Agent 长期记忆的语义去重。

但当前代码路径已经不再读写它——站内助手的操作员记忆走的是 assistant_operator_profile（两块 Markdown 短文）与 assistant_message_embedding（情景检索），与这张旧表互不相干。 列与索引留着，代码没有引用：这是事实，不是遗漏说明。

为什么文档分片不做向量

不是做不了，是这条线上向量的性价比不高：

• 文档分片是定位而非理解：用户往往已经知道要查哪份文件，需要的是「第几页、哪一段」，locator 与 page 比语义相似度更有用。
• 分片量级远大于章节（单文档上限 4000 片），全量嵌入的成本与延迟都由用户的 API 额度承担。
• pg_trgm 的 word_similarity(query, text) 对中文子串友好，且 SQLite 分支也能用 LIKE + 词频兜底，零依赖。
• 真需要语义时，用户可以把文档导入知识库——那条线是有向量的。

search_knowledge 的合并 tools/knowledge.ts

指定了知识库（或有 focus 默认库）时，两路都跑，然后按 nodeKey 去重：

1. 先跑推理式导航 retrieveTreeNodesForAgent（LLM 选节点）
2. 再跑向量语义 semanticSearchTreeNodes，用 try/catch 包住并记下 semanticAvailable
3. 把 [...treeHits, ...semanticHits] 灌进 Map，先到者胜——导航结果天然排在前面
4. 截到 limit，返回 mode: "tree+semantic" 或降级后的 "tree"

mode 字段是给模型看的：它能据此知道这次到底有没有语义检索兜底。 不传 knowledgeBaseId 时则走完全不同的 mode: "cross_kb" 分支。

注入提示词 buildInstructionsWithContextExtras

召回片段不是伪装成对话，而是明确标注来源与可信度：

{基础系统提示词} 以下是本对话较早内容的摘要（已折叠细节，仅供连贯理解； 最近几轮原文仍在消息中）： {contextSummaryMd} 以下是与当前问题相关的较早对话片段 （向量召回，供参考，非完整历史）： 1. (相关度 0.62) … 2. (相关度 0.41) …

两段都是可选的：没有摘要就不写摘要段，没有召回就不写召回段。 而工具检索的结果走的是另一条路——它们以工具返回值的形态进入对话，由模型自行决定引用哪些， 最终必须调 show_citations 出引用卡，字段不得改写。

入库前脱敏 sanitizeRecallExcerpt

对话摘录会长期留在向量表里，所以清洗必须发生在入库前，而不是展示时：

另一处脱敏：步骤落档 redactAssistantStepInput

工具调用的入参会原样写进 assistant_step.input 用于回放， 所以落库前会递归遍历对象，把敏感键名的值换成 [redacted]，数组与嵌套对象一并处理。

两处脱敏的目标不同：这一处防的是运维回放时看到密钥， 上一处防的是密钥被向量化后在别的对话里被召回出来——后者更隐蔽，也更重要。