很多团队把智能体接到业务后，第一周顺风顺水，第二周就被“记不住”“答不准”“越接越慢”狠狠教育。症结几乎都落在检索增强与知识沉淀的工程细节上——不是大而全的架构不行，而是需要一套能快速落地、可小步试错的轻方案。作为工程实践者，我更偏向把复杂度压进流程与约定里，让系统自然生长。
是什么：面向自动化场景的轻量检索增强
本文聚焦一种在现有工作流里即可落地的做法：将文本资料做结构化切分、生成向量、写入轻型存储，并在对话或任务执行时按需检索与重排，然后把高质量上下文注入到模型调用中。它不是“大一统知识中台”，而是“小步快跑、可插可拔”的工程拼装：
- 数据源：本地文档、Notion/Confluence、工单系统、Git 仓库 README、API 返回等。
- 切分与压缩：按语义与结构分块，必要时做摘要压缩，控制 token 预算。
- 向量化：选用本地或云端文本嵌入模型，统一向量维度与归一化。
- 存储：用轻量向量库或关系型数据库的向量扩展，优先易运维。
- 检索：相似度 + 关键词混检，必要时用多路召回 + 重排（Rerank）。
- 注入：基于模板的上下文拼装，携带来源与置信度，送入模型推理。
为什么：把复杂问题拆成可控小模块
与“先上大平台、后配业务”相反，轻方案的价值体现在：
- 演进友好：先把 20% 关键路径打通（摄取→检索→注入），再替换局部组件。
- 成本可见：嵌入与检索的开销清清楚楚，方便做配额与缓存。
- 治理可落地：来源、时间戳、命中分数、版本号都进入上下文，利于审计与回溯。
- 对 Agent 友好：智能体工具箱里多一个“可依赖、可解释”的记忆接口。
怎么做：在 n8n 中的工程落地
以下为可直接复刻的流程骨架，覆盖“摄取—向量化—存储—检索—注入—追踪”。
- 数据摄取（Ingest）
- 触发：定时触发器、Webhook、Git Push、表单上架。
- 清洗：统一编码，抽取元数据（来源、作者、更新时间、URL）。
- 分块：按标题层级与段落语义切分，控制每块 300–800 tokens。
- 向量化（Embed）
- 选择嵌入模型：本地（如 BGE、GTE 家族）或云端服务，统一维度。
- 归一化：向量 L2 归一，便于余弦相似度；保留 model_version 元数据。
- 存储（Store）
- 轻型首选：SQLite + 向量扩展、Chroma、Qdrant 单机、Postgres + pgvector。
- 模式（Schema）：chunks(id, doc_id, text, meta, embedding)，meta 存 JSON。
- 检索（Search）
- 召回：余弦相似度 top-k（k=8~20），并行关键词过滤（时间、来源、标签）。
- 重排：按 BM25 分数与向量分数加权；或引入小型重排模型。
- 去冗余：同源相邻块合并，控制总上下文 ≤ 模型窗口的 30–50%。
- 注入（Assemble）
- 模板：系统提示携带规范、置信度阈值、不得臆断规则。
- 引用：附上
[n] 来源/时间/链接/分数，便于前端渲染。
- 追踪（Trace）
- 记录：问题、检索参数、命中文档、分数分布、最终回答、耗时、token。
- 回放：将失败样本回注入摄取/分块/召回环节做 AB 实验。
流程示例：关键节点配置片段
以下片段用于说明思路，直接粘贴到对应节点（如 Code/HTTP Request/SQL）即可改造使用。
// Code 节点：余弦相似度（向量已归一） function cosine(a, b) { let s = 0; for (let i = 0; i < a.length; i++) s += a[i]*b[i]; return s; // 归一后点积即余弦 } // Top-k 合并打分：alpha 控制 BM25 与向量权重 function blendScore(sim, bm25, alpha=0.7){ return alpha*sim + (1-alpha)*bm25; } return { data: { cosine, blendScore } };
-- Postgres + pgvector 建表 CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE IF NOT EXISTS chunks ( id BIGSERIAL PRIMARY KEY, doc_id TEXT, text TEXT, meta JSONB, embedding VECTOR(1024) ); -- 向量检索 + 关键词过滤 SELECT id, doc_id, text, meta, 1 - (embedding <=> $1::vector) AS score FROM chunks WHERE (meta->>'source') = $2 AND to_tsvector('simple', text) @@ plainto_tsquery($3) ORDER BY embedding <=> $1::vector LIMIT 20;
# HTTP Request 节点：Qdrant 相似度查询（示意） POST /collections/knowledge/points/search { "vector": <query_vector>, "limit": 20, "with_payload": true, "filter": { "must": [ { "key": "source", "match": { "value": "handbook" } } ] } }
工程要点：把坑填在流程里
- 分块优先语义边界：表格、列表、代码块需要结构化切分，避免跨段截断。
- 时间敏感：meta 里存
updated_at，检索时加时间窗，回答时声明时效。 - 反幻觉：低分段落不注入；回答模板要求“不知道即说明未知并给出可能路径”。
- 缓存与配额：对热门问法缓存向量与命中列表；对嵌入调用做节流。
- 评测闭环：构造黄金问答集，按命中率/准确率/引用完整性评估，每周回归。
- 多源合并：业务文档与运行态数据（如 API 返回）分层注入，避免互相稀释。
选型速查：存储与检索对比
| 组件 | 部署复杂度 | 性能/扩展 | 特色 | 何时选 |
|---|
| SQLite(+扩展) | 低 | 单机中 | 零运维、便于嵌入 | PoC/边缘场景 |
| Chroma | 低 | 中 | 开箱即用、API 友好 | 团队试点/本地知识 |
| Qdrant | 中 | 中高 | HNSW、过滤强 | 需要过滤与扩展 |
| Postgres+pgvector | 中 | 中高 | SQL 生态、事务一致 | 已有 PG、数据一致性优先 |
与 Agent 协同：把检索变成一个“可靠工具”
在智能体里把检索包装为工具函数，提供明确输入输出契约：
{ "tool": "knowledge.search", "input": { "query": "问题文本", "filters": {"source": "handbook", "time_from": "2025-01-01"}, "top_k": 12 }, "output": { "contexts": [ {"text": "...", "source": "...", "score": 0.81, "updated_at": "2025-06-01"} ], "trace_id": "..." } }
- 给 Agent 清晰的失败语义：当 top-1 分数 < 阈值，要求改写查询或请求人工回补。
- 让 Agent 能做“二跳”检索：先结构化关键信息，再触发第二次召回与重排。
- 把引用渲染交给前端：Agent 只返回结构化上下文与分数，避免串台。
扩展思考：从轻到稳，再到强
- 多模态：为表格/截图加 OCR 与结构化抽取，存文本与关键字段双索引。
- 检索学习：基于用户点选与纠错做离线重排训练；每周小步更新。
- 任务编排：把检索结果作为“证据通道”，与函数调用/工作流节点并行合并。
- 安全与隔离：多租户隔离到库/Schema 级；meta 里打租户与权限标签。
结语
可复用框架：数据分层摄取 → 结构化分块 → 统一嵌入 → 轻存储 → 多路召回+重排 → 模板化注入 → 全链路追踪。当你能稳定跑通这条链，再谈模型升级、工具扩张就水到渠成。
开放问题：如果把“置信度—引用完整性—答案覆盖率”做成一个三维指标，你会如何在不同业务下给它们定权重？欢迎把思路发给我交流。更多实践与模板可关注 Dr.n8n（drn8n.com）与相关生态，我们会持续沉淀可以直接拿来用的工程组合。
