做 AI+知识库别只套壳大模型，解决知识切片与召回幻觉才是核心

做 AI 知识库，很多人一上来就陷入一个误区：找个开源框架接上大模型 API，把几十份 PDF 和 Word 往里一扔，就以为系统做好了。

结果一测，漏洞百出。问它具体的报销标准，它胡编一个数字；问它设备故障代码，它东拼西凑一堆废话；甚至同一个问题问两次，答案完全相反。很多人遇到这种情况，第一反应是觉得模型太差，急着把小模型换成更贵的大模型。

但是换了模型之后，错误依然存在。

根据我在实际项目里的调试经验，知识库问答出现胡说八道，超过八成的根本原因不在大模型本身的推理能力，而在前面的切片质量太差、召回结果不准。大模型只是根据你喂给它的上下文做总结。你塞给它的是垃圾切片，或者根本没把对的那段话找出来，模型就只能靠已有的预训练概率去猜，这时候必然产生幻觉。

要想把知识库真正做可用，你得把精力从“套壳换模型”转到“搞定切片与召回”上来。

为什么生硬切片一定会导致幻觉

很多人做切片，直接用最简单的固定长度切分，比如每 500 个字符切一刀，重叠 50 个字符。这种做法省事，但也是灾难的根源。

举个实际工作中的例子。一份人事手册写着：“员工因公出差，北京、上海每晚住宿上限 800 元；其他省会城市上限 500 元；其余地级市上限 350 元。未经总监审批超标者，财务一律不予报销。”

如果按照固定字符切分，切分点刚好落在“其他省会城市上限”和“500 元”之间，这两半就会被分到两个不同的切片里。一旦用户问“去南京出差住一晚能报销多少钱”，向量检索单独看这两个切片，语义全是残缺的：前一个切片没有金额，后一个切片不知道主体是哪个城市。大模型拿不到完整因果关系，又必须回答用户的提问，就会自己造一个合理的数字，比如瞎说“600 元”。这就是典型的切片语义割裂引发的上下文断层。

表格和代码更是重灾区。Markdown 里的多列数据表，一旦被横腰切断，表头丢失，下面的每一行数字就会彻底失去对应关系。

不同切片方案在工程落地的表现差异很大，我把主流的四种切片方式整理成了对比表：

切片策略	核心切分依据	适用文档场景	召回准确率	计算与工程成本	核心避坑点
固定字符切分 (Fixed-size)	机械按字符或 Token 长度截断	纯文本、长篇小说、无格式小说	低	极低	禁止用于规章制度、合同与表格，极易切断核心主谓语与数值
结构化标记切分 (Recursive Markdown)	按标题层级（#、##）、段落换行分块	规范的技术文档、操作指引、排版良好的政策文件	中等偏高	低	必须保留父级标题路径，否则深层子段落会丢失主题语境
父子切片 (Parent-Child)	小块做向量检索，大块作为上下文注入模型	长篇制度规范、复杂业务手册、产品说明书	高	中等	小块与大块的包含关系必须在元数据中绑定完整，防止回溯失败
语义切分 (Semantic Chunking)	计算相邻句子向量相似度，突变处作为切分点	叙述性分析报告、行业研报、会议纪要	中等	高（切分阶段需调用大量 Embedding）	相似度阈值极难调优，容易切出过碎或过大的切块

做好知识切片的具体操作步骤

别指望有一套通用的默认参数能搞定所有文档。想要切出高质量的语料，你可以照着下面这三步走：

第一步：先做文档清洗与结构化转换。

不要直接把未经处理的 Word、扫描版 PDF 往向量库送。先用解析工具把文件转为统一的 Markdown 格式。对于复杂表格，转为带明确表头的 HTML `

` 格式或 Markdown 表格，这样切片时才能保证每行数据都有表头约束。

第二步：采用“小切片检索，大上下文理解”的父子切片机制。

先将文档按完整章节切成 800 到 1200 个 Token 的父切片；然后把每个父切片进一步拆分成 150 到 250 个 Token 的子切片（子切片之间保留 10% 的重叠）。在向量数据库里，我们只为子切片建立向量索引。当用户提问时，系统通过子切片做精准匹配；一旦命中，不要把子切片直接送进模型，而是通过元数据索引找到它归属的完整父切片喂给模型。这样既能保证检索的命中精度，又能给模型提供完整的段落上下文。

第三步：强制补充元数据（Metadata）。

切出来的每段文字，都要在头部注入元数据标签。包括：文档所属产品线、生效日期、当前段落完整的标题路径（例如：`[制度库 > 差旅管理 > 住宿标准]`）。把这些元数据拼在切片文本的最前排一起做向量化。这样可以避免同名不同含义的切片互相干扰。

解决召回幻觉：光靠向量检索远远不够

很多开发者以为把切片存进向量数据库，做一次余弦相似度计算，拿前 3 名（Top-3）送给模型就万事大吉。这也是幻觉高发的另一个核心根源。

向量检索擅长处理概念、意图相近的模糊查询，但在处理精确匹配（如型号名、错误代码、专业术语、人名）时表现很差。比如用户查“Error 40430”，向量检索很可能找出一堆“404”或“403”的无关切片。大模型拿到这些错误的切片，只能顺着错误的内容胡说。

要想把召回准确率拉上去，必须使用混合检索加上重排（Rerank）机制。

下面是不同检索技术路线的性能与效果对比：

检索方案	底层匹配原理	精确匹配表现 (代码/型号/姓名)	语义泛化表现	响应延迟	幻觉压制效果
纯向量检索	稠密向量余弦距离计算	差（经常遗漏专有名词）	优	30-80ms	较弱，常常召回“看似相关其实无用”的噪声切片
纯关键词检索 (BM25)	词频与逆文档频率匹配	优	差（无法理解近义词）	10-30ms	容易漏召回，未召回时模型直接缺省回答
混合检索 (Hybrid)	向量匹配 + BM25 结果打分融合 (RRF)	良好	优	50-100ms	较好，兼顾精确匹配和泛化表达
混合检索 + Rerank 交叉重排	粗召回后用 Cross-Encoder 模型打分过滤	优	极优	150-300ms	最好，能把语义最贴合的切片精准排在前三位

搭建低幻觉召回流水线的落地方案

要把召回阶段的噪声降到最低，可以按照下面这个流程搭建召回管线：

第一步：先做用户查询（Query）改写。

用户的问题往往很简短或者带口语，比如“这个怎么修”。系统先调用轻量模型把问题结合前几轮对话，改写为语义完整、带有具体主语和上下文的独立问题。

第二步：执行双路召回。

同时发起向量检索与 BM25 关键词检索。单路各取前 20 条候选切片，通过倒数排名融合（RRF）算法把两路结果合并成一个包含 30 篇左右候选切片的候选池。

第三步：使用重排模型（Reranker）精筛。

把改写后的问题与候选池里的切片逐一配对，送进专业的重排模型（比如 BAAI 的 bge-reranker-v2-m3）。重排模型比单纯的向量点积更加精确，能够细致捕捉两句话之间的逻辑蕴含关系。必须设置严格的分数截断阈值（比如相关性得分低于 0.45 直接丢弃），绝不把低质量文本喂给后续环节。

第四步：在提示词中设置防御规则。

在发给大模型的 Prompt 结尾明确增加约束：“请严格依据上述给出的已知资料回答问题。如果已知资料中没有明确提及答案，请直接告知‘当前知识库中未查到相关信息’，严禁根据个人推测补充内容。”这样大模型一旦面对信息缺失，就会如实交代，而不是编造谎言。