智能体知识库实战：RAG流水线从切块到检索的工程指南

1. 为什么智能体需要「超体」知识库

1.1 从「一本正经胡说八道」说起

但凡折腾过智能体（Agent）的人，大概率都经历过这个场景：你问它一个公司内部流程问题，它张口就来，语气笃定、格式工整、逻辑自洽，结果一查——全是编的。这不是模型坏，这是大语言模型的本质决定的。它的知识来自训练语料，本质是「概率上最像答案的文本」，而不是「事实数据库」。当问题超出训练分布，它不会说「我不知道」，而是会顺着语言惯性把话说圆。

这就是为什么RAG（检索增强生成）成了智能体落地绕不开的一环。RAG 的核心思路很朴素：别让模型凭记忆答题，先让它去「查资料」，把相关资料塞进上下文，再让它基于资料回答。资料是事实，模型只负责组织和表达，这样输出的可信度就上了一个台阶。

我把它类比成考试：闭卷考试靠脑子记，容易记错；开卷考试允许翻书，答案就稳得多。RAG 就是给智能体配了一本随时能翻的「参考书」，而这本参考书，就是我们说的知识库。

1.2 「超体」这个定位到底指什么

标题里的「超体」，我理解成两层意思。第一层是外挂大脑：智能体本身的参数是固定的，但知识库可以随时增删改，相当于给智能体接了一个可热更新的记忆体，今天加一份产品手册，明天它就会答了，不用重新训练模型。第二层是事实锚点：知识库不只是存文本，它还要承担「事实来源」的角色，回答必须能追溯到具体文档片段，做到可解释、可审计。

这两层决定了知识库不是简单的「把文档丢进去」，而是一整套工程：文档怎么切、怎么向量化、怎么检索、怎么重排、怎么拼进提示词、怎么防止幻觉。任何一个环节偷懒，最后都会体现在「答非所问」上。

1.3 适合谁来读这篇

如果你正在做智能体开发，不管是客服、销售、考公答疑还是内部知识助手，只要涉及「让智能体基于事实说话」，这篇都适用。小白可以照着流程走一遍，理解每个环节在干嘛；有经验的可以重点看参数取舍、踩坑记录和排查表。我不打算讲空泛的概念，而是把一条能跑通的 RAG 流水线拆开，告诉你每一步为什么这么做、参数怎么定、哪里最容易翻车。

2. 知识库的整体设计与方案选型

2.1 先想清楚：知识库要解决哪类问题

动手之前必须先分类，因为不同知识形态对应的方案完全不同。热词里反复出现「kg知识库、rag知识库和结构知识库区分以及应用场景」，这其实点到了要害。我一般把知识分成三类：

• 非结构化文本：产品手册、公众号文章、会议纪要、FAQ。这类最适合经典 RAG，切块加向量检索。
• 结构化数据：表格、数据库、订单记录。这类更适合走 Text2SQL 或 API 查询，硬塞进向量库反而检索不准。
• 图谱化知识：实体关系密集的场景，比如「A 的上级是谁、A 属于哪个部门」。这类用知识图谱（KG）或 Ontology RAG 效果更好，因为关系推理是向量检索的弱项。

我的经验是：先判断你的问题是不是「找一段话」，是就用 RAG；如果是「算一个关系」，就考虑 KG 或结构化查询。很多项目失败，是因为拿向量检索去干关系推理的活。

2.2 为什么选 RAG 而不是微调

经常有人问：既然模型答不准，为什么不直接微调？我的回答是看知识更新频率。微调适合「风格和能力的固化」，比如让模型学会某种话术；但知识是高频变化的，今天的产品价格明天就变了，微调一次成本高、周期长，还容易灾难性遗忘。RAG 的优势在于知识外置、即改即生效，改一个文档，下次检索就是新的。所以知识型需求，RAG 是默认选项，微调是补充。

2.3 流水线的整体骨架

一条完整的 RAG 流水线，我习惯拆成两段：离线索引和在线检索生成。

离线索引负责把原始文档变成可检索的向量：加载 → 清洗 → 切块 → 向量化 → 入库。在线部分负责把用户问题变成答案：问题改写 → 向量化 → 检索 → 重排 → 拼提示词 → 生成 → 引用标注。

这个骨架看着简单，但每一环都有讲究。下面我按实操顺序，把关键环节一个个拆开讲。

3. 核心细节解析与实操要点

3.1 文档切块：RAG 里最容易被低估的一步

切块（Chunking）决定了检索的最小单位。切太大，一块里混了好几个主题，检索出来噪声多；切太小，语义不完整，模型拿到半句话也答不好。我的默认策略是按语义结构切，而不是按固定字数硬切。

具体做法：优先按标题层级切，Markdown 的##、###天然就是语义边界；没有结构的纯文本，再按段落切，段落还太长就按句子切。块大小我一般控制在300 到 800 字之间，并保留10% 到 20% 的重叠（overlap），防止一句话被切断导致语义丢失。

注意：重叠不是越多越好。重叠太多会让同一段内容被检索多次，浪费上下文窗口，还容易让模型重复回答。我实测 15% 左右比较平衡。

热词里有人问「有没有本地的 rag 文本拆解工具」，其实很多框架自带切块器，但通用切块器不懂你的文档结构。我的建议是：结构规整的文档自己写切块逻辑，结构混乱的才用通用工具兜底。

3.2 向量化：选对模型比调参更重要

向量化就是把文本变成一串数字（向量），语义相近的文本向量距离也近。这里的关键是选对嵌入模型（Embedding Model）。热词里出现了「siglip2 向量化」，这是多模态方向的模型，能同时处理图文，如果你的知识库里有图片，这类模型就派上用场了。

选型上我分两种情况：

• 纯文本：选中文语义强的嵌入模型，维度一般 768 或 1024。维度越高表达力越强，但存储和检索成本也越高。
• 含图片：用多模态嵌入模型，把图片和文本映射到同一向量空间，这样「以文搜图」和「以图搜文」都能做。

提示：嵌入模型一旦选定，索引和查询必须用同一个模型。换模型等于整个库要重建，这个坑我踩过，重建一次几小时起步，务必提前定好。

3.3 向量库选型：本地还是托管

向量库负责存向量并做相似度检索。选型看三点：数据量、是否要本地、运维成本。

我的建议：验证阶段用本地轻量库快速跑通，生产再换专业库。别一上来就上重型方案，容易在环境配置上耗掉热情。

3.4 检索策略：单一向量检索不够用

纯向量检索有个硬伤：它对关键词精确匹配不敏感。比如用户问「XX-2024 型号的参数」，向量检索可能召回一堆「XX 系列」的泛泛内容，就是找不到那个精确型号。解决办法是混合检索（Hybrid Search）：向量检索负责语义，关键词检索（如 BM25）负责精确匹配，两路结果融合。

融合后再做一步重排（Rerank）：用一个专门的重排模型，把候选片段按与问题的相关度重新排序，取 Top-K 送进生成。这一步能显著提升准确率，代价是多一次模型调用。我的经验是：召回阶段宁多勿少（比如召回 20 条），重排阶段再精选（留 3 到 5 条），这样既不漏又不吵。

4. 实操过程与核心环节实现

4.1 环境与依赖准备

先说明，这里给的是通用流程，具体库名你可以按自己技术栈替换。核心依赖就几类：文档加载、文本切分、嵌入模型、向量库、生成模型。

# 以 Python 生态为例，安装核心依赖 pip install langchain langchain-community pip install sentence-transformers pip install chromadb pip install rank-bm25

装完之后先别急着写业务，跑一个最小验证：拿一段文本，向量化，存进去，再查出来，确认整条链路通了。这一步能帮你提前发现模型下载、版本冲突这类环境问题。

4.2 离线索引：把文档变成可检索的库

索引流程我拆成五步，每步都有明确的输入输出。

第一步，加载文档。支持 PDF、Markdown、Word、网页等。公众号文章这类，热词里有人问「如何把微信公众号看到文章保存到知识库」，实操上就是先把正文导出成 Markdown 或纯文本，再走统一加载流程。关键是去掉导航、广告、页脚这些噪声，噪声进库会污染检索。

第二步，清洗。统一编码、去多余空行、修正乱码。这一步看着琐碎，但直接影响切块质量。

第三步，切块。按前面说的语义优先策略切，给每块打上元数据（来源、标题、页码），元数据后面做引用标注和过滤要用。

第四步，向量化。批量调用嵌入模型，注意控制批大小，太大容易内存溢出，太小速度慢。我一般批大小设 32 到 64。

第五步，入库。把向量、原文、元数据一起写进向量库。

# 索引流程示意（伪代码，按自己技术栈替换） from langchain.text_splitter import MarkdownHeaderTextSplitter from sentence_transformers import SentenceTransformer import chromadb # 1. 按标题切块 splitter = MarkdownHeaderTextSplitter( headers_to_split_on=[("#", "h1"), ("##", "h2"), ("###", "h3")] ) chunks = splitter.split_text(raw_markdown) # 2. 向量化 model = SentenceTransformer("your-embedding-model") texts = [c.page_content for c in chunks] vectors = model.encode(texts, batch_size=32, normalize_embeddings=True) # 3. 入库 client = chromadb.PersistentClient(path="./kb") collection = client.get_or_create_collection("knowledge") collection.add( ids=[f"doc_{i}" for i in range(len(texts))], embeddings=vectors.tolist(), documents=texts, metadatas=[c.metadata for c in chunks], )

注意：normalize_embeddings=True很关键。归一化后，余弦相似度和点积等价，检索更稳定。忘了归一化，相似度排序可能莫名其妙。

4.3 在线检索：从问题到候选片段

在线部分第一步是问题改写。用户的问题往往口语化、指代不清，比如「它多少钱」。直接拿去检索，向量里没有「它」的上下文，召回质量差。做法是用模型把问题补全成独立完整的查询，比如「XX 产品的价格是多少」。这一步对多轮对话尤其重要。

第二步，双路检索。向量路召回语义相近的，关键词路召回精确匹配的。

# 混合检索示意 def hybrid_search(query, top_k=20): # 向量路 q_vec = model.encode([query], normalize_embeddings=True) vec_hits = collection.query(query_embeddings=q_vec.tolist(), n_results=top_k) # 关键词路（BM25） tokenized = query.split() bm25_scores = bm25.get_scores(tokenized) bm25_top = bm25_scores.argsort()[::-1][:top_k] # 融合（简单加权或 RRF） return merge_results(vec_hits, bm25_top)

融合算法我常用RRF（Reciprocal Rank Fusion），它不依赖分数绝对值，只看排名，鲁棒性好。公式是每个结果得分等于1/(k+排名)累加，k 一般取 60。

第三步，重排。把融合后的候选送进重排模型，取 Top 3 到 5。

4.4 生成与引用：让答案可追溯

最后一步是把检索到的片段拼进提示词，让模型基于片段回答。提示词里我会明确三条约束：只依据给定资料回答、资料没有就说不知道、每个结论标注来源编号。

你是知识库助手，请严格依据以下资料回答问题。 规则： 1. 只使用资料中的信息，不得编造。 2. 资料不足以回答时，明确说明「资料中未提及」。 3. 回答末尾标注引用的资料编号，如 [1][2]。 资料： [1] {片段1} [2] {片段2} 问题：{用户问题}

这样出来的答案，用户能点开引用核对，可信度直接拉满。这也是「让智能体基于事实说话」的落地形态。

5. 常见问题与排查技巧实录

5.1 检索不准的排查顺序

检索不准是最常见的问题，我一般按这个顺序排查：

这个表我贴在工位上，出问题先对号入座，能省不少时间。

5.2 知识库里的图片怎么处理

热词里「rag 知识库能存储图片嘛」「知识库图片怎么处理」问得很多。答案是能，但要分两种做法。一种是图片转文字：用 OCR 或视觉模型把图里的文字提取出来，当文本处理，适合截图、扫描件。另一种是多模态向量化：用多模态嵌入模型把图片直接编码成向量，和文本共用一个空间，适合产品图、示意图。我的建议是：以文字为主的图走 OCR，以视觉信息为主的图走多模态，别一刀切。

5.3 知识库「排队中」是怎么回事

热词里出现「dify 知识库排队中」，这通常是索引任务在排队。原因一般是文档量大、嵌入模型调用慢、并发受限。解决办法：分批索引、错峰执行、给嵌入调用加缓存（相同文本不重复向量化）。我处理过一个大库，加了内容哈希缓存后，重复文档直接跳过，索引时间砍了一半。

5.4 平台搭建和代码搭建的智能体差在哪

热词里反复问「平台搭建的智能体与用 python 搭建的智能体有什么不同」。我的体会是：平台版胜在快，拖拽配置就能跑，适合验证和轻量场景；代码版胜在可控，切块策略、检索逻辑、重排、提示词全都能改，适合复杂需求。先用平台验证需求，需求复杂了再迁到代码，这是我推荐的路径，别一上来就硬写代码。

5.5 几个容易忽略的坑

第一个坑是元数据丢失。切块时没保留来源，最后答案没法标注引用，用户不敢信。第二个坑是嵌入模型和查询模型不一致，前面提过，重建库很痛。第三个坑是提示词没约束，模型拿到资料还是自由发挥，等于白检索。第四个坑是不做评估，改了半天不知道有没有变好。我建议建一个小测试集，二三十个问题，每次改动跑一遍，看命中率变化，心里才有数。

6. 知识库的扩展方向

6.1 从 RAG 到 GraphRAG

当你的问题开始涉及「多个实体之间的关系」，纯向量 RAG 就吃力了。这时候可以往GraphRAG或Ontology RAG方向走：先把文档里的实体和关系抽出来建图，检索时既走向量也走图遍历。代价是构建成本高，但关系类问题的准确率提升明显。我的建议是：关系问题占比超过三成，再考虑上图谱，否则性价比不高。

6.2 知识库的持续维护

知识库不是建完就完事。文档会过期、会新增，所以要有一套更新机制：定期增量索引、给文档打时效标签、过期内容降权或下架。我一般给每块加一个updated_at字段，检索时对太旧的内容做降权，避免模型拿几年前的信息回答今天的问题。

6.3 行为审计与可观测

热词里提到「智能体行为审计」，这在企业场景很重要。RAG 的好处是天然可审计：每次回答都能追溯到检索了哪些片段、用了哪个模型、耗时多少。我会把这些日志存下来，出问题时能复盘，也能用来优化检索策略。这比黑盒模型让人放心得多。

最后分享一个我自己的习惯：每次上线新知识库，我都会先拿一批「刁钻问题」去测，专挑那些容易让模型编造的边界问题。能扛住这些问题的库，才算真正能「基于事实说话」。这个过程很枯燥，但每次发现一个幻觉点并修掉它，那种踏实感是实打实的。