把本地 RAG 问答做准这事我前后折腾了小半年。最初搭的 demo 看着能聊一到真正的多轮对话就露馅“这本书的作者是谁”“它的第二章讲了什么”——那个“它”字直接让检索结果漂到十万八千里外。更别提那些直接从网上下载的 TXT 电子书按固定窗口切完段落前言不搭后语检索出来就像在图书馆里只看到了撕碎的书页。后来我把方案收敛成三件事多轮指代消解、云端语义向量、TXT 章节切分。每一项单独拎出来都不算新但组合在一起才真正把本地知识库问答从“能答”拉到了“答得准”。这篇文章把我整个改造过程的思路、具体参数、踩过的坑全部记录下来适合正在做本地 RAG 问答、或者已经被“切分不合理、召回不准、多轮识别不了”折磨过的朋友参考。1. 本地 RAG 问答为什么总“答不准”先聊点实际的。RAG 的标准流程大家都很熟文档切块 - 向量化 - 存向量库 - 检索 - 拼 Prompt - 交给 LLM 生成。理论上每个环节都正常结果却经常是一本正经地胡说八道。我复盘了自己的数据和失败案例发现“答不准”基本集中在三个环节。第一个坑在切分。本地知识库里有大量 TXT 格式的电子书和文档传统做法是按固定字符数切块比如每 512 字切一段、重叠 128 字。这样切出来的结果很随机可能把一个小节的标题切到上一块正文内容切到下一块也可能把一个完整的故事段落拦腰截断。检索时拿到的是半截上下文大模型再聪明也补不齐缺失的信息。我之前做一个长篇小说的问答问“主角第一次遇到对手是在什么场景”检索到的几块文本七零八落模型只能靠幻觉硬凑答案自然是不靠谱的。第二个坑在语义向量。本地部署的向量模型大多是中小尺寸的双塔模型参数量有限对中文长文本的语义理解能力很一般。尤其是对比“这本书的写作风格如何”和“这本书的语言特点是什么”这类近义表达时本地小模型算出来的向量余弦相似度经常偏低导致召回不完整。同样一段话用云端的新一代 Embedding 模型和本地小模型分别编码语义相近度排序结果差距很大。这就是我后来宁可把文本送到云端做向量化也不在本地硬扛的原因。第三个坑在多轮指代。本地知识库问答很多时候不是一次性提问而是连续追问。用户先问“张三的日记里写了什么”再问“他对秋天的看法呢”这里的“他”指的是谁如果直接把第二句原文拿去检索向量检索会发现“他对秋天的看法呢”这种碎片化的、缺少主语的句子根本匹配不到有价值的文本。让 LLM 在最终回答时去猜指代是不靠谱的必须在检索之前就把指代消解掉把“他”还原成“张三”把问题改写成一句完整的、可独立检索的查询。我最初也犹豫过要不要直接上 KG知识图谱方案。热搜词里“kg知识库、rag知识库和结构知识库区分以及应用场景”被频繁提起但坦白说知识图谱适合实体关系稠密、需要精确推理的场景比如企业知识资产盘点、人物关系网络分析。而本地 TXT 文档大多是散文、教程、小说、报告这类自然语言文本实体关系松散做 KG 的抽取成本极高而且很多隐含语义是图谱表达不了的。RAG 的优势在于不需要预定义 schema开箱即用维护成本低。把 RAG 做准比在文档类知识库上强行套 KG 更划算。2. 多轮指代消解让“它”找到真正的“书”2.1 先搞清指代消解要做什么指代消解并不是什么新概念NLP 领域研究了很多年但在 RAG 流程里它的目标非常明确在把用户问题送进向量检索之前把它改写成一个摆脱上下文的独立查询。举个例子历史对话是用户推荐几本关于产品经理入门的书助手可以看看《人人都是产品经理》和《俞军产品方法论》用户第二本的作者是谁如果直接把“第二本的作者是谁”拿去检索向量数据库里没有“第二本”这个概念结果必然跑偏。指代消解要做的就是结合对话历史把“第二本”理解成《俞军产品方法论》并生成“《俞军产品方法论》的作者是谁”这个完整查询。这样才能在知识库中精准定位到文档块。2.2 方案选型规则替换 vs LLM 改写我最初用规则方案维护一个“候选实体——提及词”的映射关系比如从上一轮回答里抽取出书名然后建立正则表达式把“它”“这本书”“第二本”替换为具体书名。规则方案在小范围测试里表现还行一旦对话变长、实体变多问题就来了指代依赖多层推理比如“那本书的第二章里提到的那个人的结局是什么”用正则几乎写不出来。后来我切到了 LLM 改写方案。用一个小一点的模型——比如本地跑的 Qwen 或者云端便宜的对话模型——来专门做“Query 改写”而不是让大模型直接在回答阶段处理指代。这样有几个好处改写任务可以随对话实时调用延迟可控用专用 Prompt 约束输出格式稳定性比自由对话高不占用最终回答模型的上下文长度保持最终 Prompt 干净。我实测下来改写模型用 7B 左右的中小模型已经够用因为任务比较单一不需要太强推理。如果你本地部署资源紧张也可以调用云端 API我的经验是这类改写请求单次约消耗 300~500 token成本很低。2.3 具体实现对话历史的压缩与改写直接说我的实现方式。核心思路是不把所有历史对话都丢给改写模型而是只保留最近几轮的“用户问题 助手回答关键信息”防止上下文过长导致模型提取不到关键实体。改写 Prompt 这样设计你是一个信息提取助手。请根据对话历史和当前用户问题生成一个不依赖上下文的独立查询语句。 要求 1. 如果当前问题中没有指代词如“它”“这本”“那位”“前者”“第二章”等直接返回原问题。 2. 如果有指代请结合对话历史中出现的具体实体书名、人名、地名、专业术语等替换成完整表述。 3. 不要补造原对话中没有的信息。 4. 只输出最终查询语句不要任何解释。 对话历史 用户推荐几本产品经理入门的书 助手可以看看《人人都是产品经理》和《俞军产品方法论》 当前问题第二本的作者是谁 改写结果实际输出就是“《俞军产品方法论》的作者是谁”。这一步的关键在于改写模型只负责“信息补全”不负责“回答问题”所以 Prompt 里要明确禁止它输出答案性内容。处理后端我加了三层保险。第一层是“指代探测”先让模型判断当前问题里是否存在指代性表达如果没有直接走原查询省掉一次多余的 LLM 调用。第二层是“改写结果校验”对比改写结果和原问题如果差异过大或者模型信心不足就退回原问题避免改写引入错误实体。第三层是我自己踩坑总结出来的改写时保留原有的时间信息比如“去年提到的那本书”要改写成“《XXX》”但如果对话里根本没有“去年”对应的实体宁可保留原问题也不要瞎猜。2.4 运行期经验与坑多轮指代消解上线后我遇到的第一个坑是历史对话里模型生成的文本太长塞进改写 Prompt 后把关键实体淹没。后来我把助手回答做了一层摘要压缩只保留回答中的图书名、人名、章节名等实体信息。比如助手回答用了 300 字介绍一本书我在日志里只保留“《俞军产品方法论》作者俞军”改写效率反而更高。另一个实战经验指代消解需要控制触发时机。如果不加判断地对每个问题都做改写会遇到两个问题一是每次问答多出 200ms 左右的延迟二是模型可能把本来没有歧义的短问题改歪了。我的做法是对问题先做一次“是否包含指代词”的规则预检命中“它/他/她/这本/那本/前者/后者/这/那”等词的才进入 LLM 改写否则直接跳过。这大概能过滤掉 60% 以上的不需要改写的请求。加这个预检之后整体问答延迟明显回落。最后提醒大家注意指代消解不是万能的。当对话历史里出现两个同类实体比如两本书、几个人名且用户说“第一本的作者是谁”时改写模型可能选错实体。我的应对措施是对改写结果同时保留“改写版”和“原问题版”两个查询分别去做检索把两组结果合并去重后再交给答案模型。这样即使改写漂了原始查询依然有机会召回正确文本。这个策略让召回准确率提升了大概 8% 左右。3. 云端语义向量把“语义”从本地搬到云端3.1 为什么本地小模型不行在做指代消解之前我的向量化方案是本地跑的理由和大多数人一样数据不出本地隐私安全离线可用。但实测效果让我不得不重新审视这个选择。对比测试用的是同一批 2000 个中文问答对用本地模型算出的向量做召回top5 准确率只有 62% 左右。同样的数据用云端新一代 Embedding 模型top5 准确率能到 83% 以上。差距主要体现在语义相关的判断上。举个例子用户问“这本书的叙事结构有什么特点”本地小模型会把“叙事结构”看成独立关键词召回的文本大多是包含“叙事”字眼的句子而云端语义模型能理解“叙事结构”和“情节组织方式”“时间线安排”之间的深层关联召回的文本更贴合用户真实意图。这几年 Embedding 模型的一个重要演进方向就是“语义匹配”代替“字面匹配”本地小模型在参数量上吃亏很多隐含语义是学不出来的。3.2 选型对比与维度参数我试过几类方案简单做个对比方案维度中文语义效果成本适用场景本地 BGE-medium 等小模型512一般0离线、隐私敏感场景本地 BGE-large 微调1024较好需要 GPU 资源有一定硬件投入的团队云端 text-embedding-3 系列可配 1536/3072 等好按 token 计费追求效果、成本可控的场景云端中文专用语义模型多档可配好按 token 计费中文内容为主的项目我的选择是云端 API 的方式。隐私是绕不开的问题——把公司内部文档传到云端 API确实要先做数据脱敏。但我的使用场景是个人知识库和教程类文档不涉及敏感内容而且我用的是国内云厂商提供的合规 API不走任何非常规网络通道所以隐私问题在可控范围内。如果你处理的是高度敏感的数据还是老老实实本地部署大模型同时接受召回效果打折的可能性。参数方面我把 Embedding 维度设置成了 1024而不是模型默认的更大维度。原因是高维度确实能提升语义区分度但会带来两个副作用——向量库占用空间更大检索耗时更长。在我这个规模约 5000 个文档块下1024 维的检索延迟在 30ms 以内而 3072 维会飙到 80ms 以上。关键是1024 维对中文长文本的语义表达已经足够更高的维度对 top5 召回率的提升基本可以忽略。3.3 批量向量化与本地缓存调用云端 API 做向量化最容易踩的坑是“一个一个请求”慢且容易触发限流。我踩过这个坑2000 个文档块逐个请求跑了快两个小时中间还断了几次断点续传全靠自己写。后来我改成批量提交每次把 100 个文本块打包成一个请求整体耗时直接降到 15 分钟左右。批量请求的 Python 示意import json import requests def embed_batch(texts, batch_size100): results [] for i in range(0, len(texts), batch_size): batch texts[i:ibatch_size] resp requests.post( EMBEDDING_ENDPOINT, headers{Authorization: fBearer {API_KEY}}, json{input: batch, dimensions: 1024} ) data resp.json() results.extend([item[embedding] for item in data[data]]) return results这里有个细节批量请求必须保证返回顺序和输入顺序一致。部分 API 的返回顺序不保证我就在每个 item 里带上 index 字段最后按 index 排序这样即使返回乱序也不会把向量对应错。另外强烈建议做一个本地向量缓存层。同一个文本块如果内容没变就不需要重新请求 API。我用最简单的方式实现把文本的 SHA256 哈希作为键向量值持久化到本地 JSON 文件下次构建知识库时直接命中缓存。这个策略在反复调参数、重建索引时省下的钱和时间非常可观——我从两天里重建了七八次索引缓存机制上线后重建时间从 40 分钟降到了 3 分钟因为 95% 的向量都直接命中。3.4 向量检索与排序细节向量入库之后检索环节也需要认真调。很多人只用 Cosine 相似度一个阈值做过滤比如 topK 直接取 5。我的做法是先取 top20 候选再用相似度阈值0.70做一轮粗过滤最后按文本块之间的重叠度做一次去重合并。为什么要去重合并因为同一个章节的前后相邻块内容高度相似经常会同时出现在 top5 里如果不合并最后拼进 Prompt 的几块文本其实是同一段内容的重复信息量不足。合并逻辑很简单如果两块内容的 Jaccard 重叠度超过 40%只保留相似度更高的一块。多路召回也值得做。一种方式是沿用章节切分得到的“章节标题/小节标题”作为关键词做 BM25 召回和向量召回结果做加权融合。在标题词命中明确的场景比如直接问“第三章讲了什么”BM25 的精准度往往超过纯向量召回。我实测下来的权重比例是向量召回 0.7、BM25 召回 0.3融合后 top5 准确率又涨了 5% 左右。这一步不算复杂但对“准”的提升非常关键。4. TXT 章节切分先找目录再切正文4.1 固定窗口切分的罪与罚常见的 TXT 切分方式是按固定长度比如 Python 的text.split()之后每 500 字一个 chunk再接 100 字 overlap。在小规模测试中看不出问题真正把一本几十万字的电子书扔进去问题就暴露了书籍是分章、分节、有结构的固定窗口无视这些结构导致检索时的上下文支离破碎。我举一个亲测的失败案例。知识库里放了一本技术教程用户问“异常处理的 finally 块有什么用”按固定窗口切分后检索命中的是某一章的中间段落上下文里完全没有“异常处理”这个小节标题结果答案模糊不清。改成按章节切分后检索可以精准落到“异常处理”整节模型能看到完整的引言、示例代码和注意事项回答质量提升了一个档次。固定窗口切分的另一个隐形问题是切分边界刚好落在句子中间的几率很高。中文不像英文有天然空格一个 chunk 的开头和结尾经常是半句话。向量检索时半截话的语义表达是不完整的模型拼写答案时也容易把半截话接错。章节切分天然规避了这个问题因为章节边界通常在标题和换行符附近很少截断完整句子。4.2 章节识别不只看“第X章”TXT 文档的格式参差不齐尤其是从网上下载的电子书目录格式五花八门。常见的章节标题格式包括“第一章 XXX”“第1章 XXX”“一、XXX”“1. XXX”以及全角数字的“第一章”。我最初用单一正则第.章去匹配结果漏掉了大量使用“一、二、三”格式的文档。后来我设计了三级回退识别方案。先做格式探测统计整个文档中出现的章节标题模式按出现次数排序选出最主流的 1~2 种格式作为本章文档的章节格式。这是一个无监督的探测过程import re PATTERNS [ re.compile(r^第[一二三四五六七八九十百千万0-9][章回节卷]), re.compile(r^[一二三四五六七八九十]、), re.compile(r^[0-9](\.[0-9])*\s), ]探测结果会告诉你当前文档更倾向哪种格式。然后用识别出的主格式做章节切分用次格式做小节切分。这样两级标题结构就能被完整保留下来。如果某个 TXT 没有任何章节标记这种情况多见于论坛帖子合集、纯散文就退回到固定段落切分但段落切分前我会先做“段落合并”把连续的短行合并成一个语段避免把同一段内容的换行断开。识别细节上有几个坑值得说。第一个是目录区干扰很多 TXT 前面会有几十行目录如果不做预处理切分时会生成大量无实质内容的空章节块。我加了一个简单逻辑如果某一行的内容与文档后文重复出现且连续多行都这样就认为是目录直接跳过。第二个是章节标题本身很短通常不超过 30 字但也有的章节标题特别长比如“第五章 从零开始搭建一个高可用的监控系统——以 Prometheus 为例”。如果按 30 字截断会把标题切成两半所以我设置了“含章节关键词的整行都作为标题保留”的规则不截断。4.3 切分策略与参数调优章节识别完成后我定的切分策略是以章节标题为边界把章节内容作为整体存入一个 chunk。这样做的好处是检索到该 chunk 时上下文包含完整的章节主题答案模型不需要脑补。但整章存储有一个问题——长章节内容可能超过向量模型的输入限制。以云端模型为例单次输入通常限制在 8192 token有些更短的只有 512 token。一个几万字的大章节显然放不进去。我的处理策略是“自适应二次切分”先保存章节标题和摘要然后把超长章节内容按照段落边界切开每个子 chunk 保留章节标题前缀再追加本段内容。这样切出来的每一块文本都带着章节归属信息检索时不会丢失上下文。具体参数我给了三档配置章节长度切分策略参数设置小于 1500 字整章单块无切分完整索引1500~8000 字按自然段切 2~5 块每个子块带章节标题前缀大于 8000 字按段落边界切块每块控制在 1200 字子块之间保留 100 字重叠“子块带章节标题前缀”这一招效果极好。举个例子切出的某一子块正文是“它通过拦截异常确保程序不会因为局部错误而崩溃”如果不带前缀检索系统很难定位它属于哪一章加上前缀“【异常处理】”之后哪怕用户只问“拦截异常有什么作用”这个子块也能在语义上与问题正确关联。做本地知识库问答的强烈建议在切分时保留这种“索引上下文”成本几乎为零收益却非常直观。4.4 切分效果的实测对比章节切分上线后我做了个简单回归。同一本电子书、同一条测试问题集旧方案是所有文本固定 500 字切块新方案是按章节切分。结果如下测试维度固定窗口切分章节切分top5 相关文本命中率61%84%回答准确率人工判定58%79%平均检索延迟42ms38ms索引区块数量1248 块723 块索引区块数量反而变少了因为章节块通常比 500 字窗口更长但是更完整。向量库的查询压力小了延迟还略微下降。这一步做完我才觉得本地 RAG 问答基本摆脱了“答非所问”的阶段。5. 整体流水线从 TXT 到可问答的 RAG5.1 构建阶段完整流程串起来说我的构建流程分四步解析、切分、向量化、入库。解析阶段输入是原始 TXT 文件先做编码识别。这里有个容易忽略的实际问题从网上下载的 TXT 文件编码五花八门有 UTF-8、GBK、GB18030甚至有的部分是 UTF-8 带 BOM。如果读入时编码识别错了后面切分全是乱码。我用chardet做自动检测检测置信度低于 0.8 的用 GBK 和 UTF-8 分别解码一次按“解码后无乱码字符比例更高”来选。这一步虽然工程化但对下游效果影响极大。切分阶段走上一节说的三级章节识别方案。每个生成的 chunk 有四个元数据字段来源文件、章节号、标题、内容哈希。元数据用于后续检索过滤和结果定位非常重要。没有元数据的向量库过滤和去重都无从谈起。向量化阶段调云端 API 批处理配合本地缓存。入库阶段我用的向量数据库是轻量级的 Chroma单机跑基本够用。为什么不用 Milvus 或 Qdrant我的数据量只有几千到几万块Chroma 部署简单、零运维检索速度也已经足够。如果数据量超过十万块再上 Milvus 这类专业向量数据库也不迟。# 构建命令示例 python build_index.py \ --input-dir ./books/ \ --output-dir ./index/ \ --chunk-mode chapter \ --embedding-api text-embedding-3 \ --embedding-dim 10245.2 查询阶段完整流程查询流程多了一层“先改写、再检索、后生成”的逻辑用户输入问题指代探测判断是否存在指代性表达如果需要调用改写模型生成独立的查询语句并行执行向量召回和 BM25 召回按权重融合top20 候选按重叠度去重相似度阈值过滤保留 top5~8 块把查询和相关文本块注入 Prompt交给生成模型返回答案同时带回来源信息生成阶段的 Prompt 我也调过多次最终固定为如下模板你是一个知识库问答助手。请根据下面提供的资料片段回答问题。 规则 1. 资料中如果没有答案直接说“资料中未找到相关内容”不要编造。 2. 回答时尽量引用资料中的原句可以适当概括。 3. 如果资料之间存在矛盾指出矛盾内容不要强行解释。 资料 {chunk1} {chunk2} {chunk3} 问题{question}这里的“资料中未找到相关内容”这句兜底话术很关键。没有它模型会强行从无关资料里编造答案。测试时我把 30 个“知识库外问题”混入测试集开启这个规则后正确的拒答率从 12% 提升到了 83%。宁可答不出也不能让 RAG 变成幻觉生成器。5.3 一套可复用的参数配置把前面所有经验收敛成一张参数配置表方便你直接抄作业配置项推荐值说明章节切分模式三级回退识别先探测再切分子块最大长度1200 字兼顾语义完整与向量模型限制子块重叠100 字防止边界截断向量维度1024平衡效果与检索速度topK 召回20 候选最终 5~8先召回多再过滤相似度阈值0.70低于此值直接丢弃去重重叠度阈值40%去除相邻重复内容向量召回/BM25 融合权重0.7 / 0.3用标题词精准匹配兜底改写触发词表它/他/她/这本/那本/前者/后者/这/那预检后进入 LLM 改写最终答案模型温度0.2减少幻觉、倾向忠实资料这套参数本身不神秘但每项背后都有实测依据。比如 topK 我试过 3、5、10、20最终选 20 是因为取 5 时经常漏召回取 20 再过滤可以明显提升最终质量同时延迟增加有限。6. 常见问题排查与心得6.1 实际场景中的问题速查表现象可能原因排查与解法检索结果完全不相关切分破坏了语义完整性检查章节切分是否生效确认文本块是否还包含完整标题多轮对话答非所问指代消解未生效观察改写日志看“它/这本”是否被替换成具体名称相似问题召回不全本地向量模型能力不足临时切换到云端 API 对比测试效果差距明显就换回答出现大量重复内容topK 中相邻块重叠过多开启重叠度去重逻辑向量库太大检索变慢维度设置过高降维到 1024或换成支持量化压缩的方案API 调用频繁报错并发或批次过大批量限制在 50~100 条做好指数退避重试答案与资料无关却又自信缺少拒答兜底话术在 Prompt 中加“资料中未找到相关内容”规则6.2 三个踩过的深度坑第一个坑是“对 PDF 转 TXT 的文件不做清洗”。很多朋友从网上下载的是 PDF 转换来的 TXT里面残留大量页码、页眉、空格和断行符直接切分后chunk 里全是噪点。一定要加一个预处理步骤用正则去掉页码行、页眉行、连续的空白行把“段落内换行”的硬回车替换成空格。这一步我最初偷懒跳过后来发现检索效果始终不稳定排查了半天才定位到是脏文本问题。第二个坑是“实体同一指代多个写法”。知识库里同一本书目录里叫《深入浅出 C》正文里可能写成“深入浅出C”或者“C 深入浅出”向量检索虽然能处理一部分近义匹配但这种局部敏感的信息仍然会分裂成多个不相关的向量。我的解决办法是在切分阶段做实体归一化把常见变体统一成标准写法。归一化规则用正则维护一个同义词表就行不需要上模型。第三个坑是“改写模型返回了多余内容”。有段时间我直接把 LLM 改写结果拿去检索发现经常查不到原因是模型输出的结果里带着“根据对话历史查询语句应为”这类前缀。后来我强制了输出格式要么直接输出改写后的查询要么输出“ORIGINAL”。解析时只取第一行后面全部丢弃。模型输出规范化这种事看似小实际影响巨大。6.3 一点真实的个人体会整套方案做完我最深的感受是本地 RAG 问答的“准”不是某一个环节的功劳而是切分、向量、改写、融合共同作用的结果。很多人一上来就换更大的模型、调更高的 topK其实经常是本末倒置。数据切分不合理、检索上下文不完整再大的模型也只能靠幻觉硬撑。如果你现在正准备做类似的项目我的建议是按顺序排查先看切分是否保留了标题和章节结构再看向量化效果在同义改写和语义相似测试中是否稳定最后再考虑要不要引入指代消解。这三件事补齐本地 RAG 问答的准确率基本能提升一个档次。最后提醒一句云端语义向量确实强但要不要用、用哪家的 API一定要先结合自己的数据敏感度和合规要求做判断。数据安全这条红线比效果更重要。