1. 为什么本地 RAG 问答总是“答不准”1.1 从一次翻车现场说起去年年底我帮一个做工业设备售后的小团队搭了套本地知识库问答硬件就是一台 32G 内存的迷你主机模型跑的是 7B 量级的量化版本向量库用的本地文件方案。第一版 demo 演示的时候效果惊艳问“XX 型号的保养周期是多久”答案张口就来。结果上线第三天客服主管直接甩过来一段对话记录用户问“它的滤芯多久换一次”系统答的是另一台设备的参数。再问“那这个呢”系统彻底懵了开始胡言乱语。问题出在哪不是模型不行也不是向量库不行而是检索环节拿到的上下文本身就是错的。用户说的“它”和“这个”在系统眼里就是两个毫无意义的代词拿这种 query 去向量库里搜搜出来的东西自然驴唇不对马嘴。这就是本地 RAG 最容易被忽视、也最致命的瓶颈——多轮对话里的指代消解。很多人搭 RAG 的路径是这样的找一堆文档切一切灌进向量库接个大模型完事。单轮问答确实能跑通但只要用户开始追问、开始用代词、开始省略主语整个系统就崩了。而真实场景里用户几乎不会用完整的主谓宾跟你说话。所以“把本地 RAG 问答做准”这件事核心不在模型多大而在检索前的 query 处理和切分策略这两个容易被跳过的环节。这篇内容适合谁看如果你已经搭过一个能跑但不够准的本地 RAG或者正准备动手搭一套尤其是面向客服、售后、内部文档查询这类多轮追问场景的那接下来的东西应该能帮你少走不少弯路。我会围绕三个抓手展开多轮指代消解怎么做、云端语义向量怎么选怎么用、TXT 章节切分怎么切才不丢信息。1.2 三个抓手的关系先理清楚在动手之前得先明白这三件事不是并列的而是有先后依赖的。多轮指代消解解决的是“用户到底在问什么”。它发生在检索之前把“它的滤芯多久换”还原成“XX 型号设备的滤芯更换周期”。这一步做不好后面全白搭。云端语义向量解决的是“怎么把还原后的 query 和文档匹配上”。本地小模型做 embedding 在中文长文本上经常力不从心云端 API 的语义向量模型在中文语义理解上普遍更稳尤其是处理同义替换、行业术语的时候。TXT 章节切分解决的是“文档怎么进库”。切得太碎上下文断裂检索到的片段答非所问切得太粗一个片段里混了好几个主题向量被平均掉匹配精度下降。TXT 这种没有结构标记的纯文本切分尤其考验策略。三者串起来就是一条链路原始多轮对话 → 指代消解还原 query → 云端向量化 → 与章节切分后的文档块匹配 → 喂给大模型生成答案。任何一个环节掉链子最终答案都会歪。下面我按这条链路的顺序把每个环节的实操细节掰开讲。2. 多轮指代消解让“它”和“这个”说人话2.1 指代消解到底在解决什么问题先明确概念。指代消解Coreference Resolution在 NLP 里是个老课题但在 RAG 场景下我们要的不是学术意义上的完整消解而是够用就行的 query 重写Query Rewriting。目标是把当前这一轮用户输入里省略的、指代的信息从对话历史里补回来形成一个自包含的、可以独立检索的 query。举个实际例子。对话历史是这样的用户XX-200 型号的保养周期是多久系统XX-200 建议每 500 小时保养一次。用户那它的滤芯呢第三轮用户输入“那它的滤芯呢”如果直接拿去检索向量库里全是“滤芯”相关的片段但不知道是哪个型号的滤芯。指代消解要做的就是把“它”还原成“XX-200”把 query 重写成“XX-200 型号的滤芯更换周期是多久”。这样检索出来的片段才精准。这里有个关键判断不是所有代词都需要消解。像“这个多少钱”里的“这个”如果上文刚提过具体产品那必须消解但如果用户是在一个全新话题里说“这个方案不错”那可能只是口语习惯强行消解反而引入噪声。所以指代消解的第一步是判断当前 query 是否依赖上下文。2.2 判断是否需要重写的三个信号我总结下来出现以下三种情况时query 大概率需要重写信号一出现代词或指示词。包括“它、他、这个、那个、该、此、其”等。但要注意有些代词是泛指比如“这个东西怎么用”如果上文没有明确对象消解不了这时候应该触发澄清反问而不是硬猜。信号二句子成分残缺。比如“那滤芯呢”“多久换一次”“还有别的吗”这类 query 单独看语义不完整必须结合上文补全。信号三话题延续但主语省略。中文里特别常见用户说“保养周期呢”其实是在延续上一个型号的话题但主语没了。判断逻辑可以用一个轻量规则引擎先过滤比如检测到代词或句子长度低于阈值就标记为“待重写”。但规则引擎容易误判所以更稳的做法是用一个小模型做分类判断当前 query 是否自包含。这个分类任务很轻7B 以下的模型甚至规则加关键词就能做到八九不离十。2.3 重写策略从简单拼接到模型改写确定需要重写之后具体怎么重写我试过三种方案效果和成本各不一样。方案一历史拼接。最简单粗暴把最近 N 轮对话直接拼在当前 query 前面一起丢给检索。缺点是噪声大历史里的无关信息会干扰向量匹配而且拼接后的文本变长向量语义被稀释。实测下来N 取 2 到 3 轮还行再多就明显掉点。方案二规则模板替换。针对高频代词做映射比如把“它”替换成上一轮的主语实体。这个方案在特定场景下很准但维护成本高遇到复杂指代就歇菜。方案三小模型改写。用一个本地小模型把对话历史和当前 query 一起喂进去让它输出一个自包含的 query。这是目前我觉得最平衡的方案。提示词可以这样设计你是一个查询重写助手。根据以下对话历史将用户的最新问题重写为一个不依赖上下文、可以独立理解的完整问题。只输出重写后的问题不要解释。 对话历史 {history} 用户最新问题{query} 重写后的问题实测下来7B 模型在这个任务上表现已经够用重写准确率能到 85% 以上。关键是提示词里要强调“只输出重写后的问题”否则模型容易画蛇添足加一堆解释。2.4 重写失败的兜底澄清反问再好的重写也有翻车的时候。如果对话历史里根本没有可消解的实体比如用户上来就说“它的参数呢”这时候硬猜就是瞎编。正确的做法是触发澄清反问让系统回复“您指的是哪款设备呢”引导用户补充信息。这个兜底机制很重要因为 RAG 最怕的就是“一本正经地胡说八道”。宁可多问一句也不要给一个错误答案。判断是否触发澄清可以看重写后的 query 里是否还残留无法解析的代词或者重写置信度低于阈值。注意澄清反问会打断对话流畅度所以只在确实无法消解时使用。如果每轮都反问用户体验会很差。我的做法是设置一个计数器连续两轮无法消解才触发反问。3. 云端语义向量本地 embedding 不够用怎么办3.1 本地 embedding 的真实短板很多人搭本地 RAG 时embedding 也用本地模型图的是全离线、零成本。但实际用下来本地小 embedding 模型在中文场景有几个明显短板。第一是长文本语义压缩能力弱。一个 500 字的文档块本地小模型编码出来的向量往往只能抓住前几句的重点后面的信息被稀释掉了。云端大模型在这方面明显更稳。第二是行业术语和同义替换处理差。比如“滤芯”和“滤网”在很多设备手册里是同义词但本地模型可能认为它们向量距离很远。云端模型因为训练语料更丰富对这种语义关联的捕捉更准。第三是多语言混排场景。有些技术文档中英文夹杂本地模型容易在语言切换处丢失语义。当然云端 embedding 不是没有代价。数据要出本地这件事对某些团队是硬伤。所以选不选云端得先看你的数据敏感度。如果文档本身不涉密云端方案在准确率上的提升是实打实的。3.2 云端语义向量的选型考量选云端 embedding 服务我一般看四个维度维度说明我的建议中文语义能力在中文长文本上的检索准确率优先选中文语料训练充分的模型向量维度维度越高表达力越强但存储和计算成本也高1024 到 1536 维是甜点区批量接口是否支持一次请求编码多条文本必须支持否则建库慢到崩溃成本按 token 计费还是按请求计费建库阶段用量大要算清楚维度这块补充一句不是越高越好。我试过 3072 维的模型检索准确率相比 1536 维提升不到 2%但存储翻倍、检索变慢。除非你的文档语义极其细腻否则 1536 维足够。3.3 向量化实操批量编码与缓存建库阶段的向量化是个体力活。假设你有 5000 个文档块每个块平均 300 字那就是 150 万字。如果一条条调 API光网络往返就够你等的。所以必须用批量接口一次塞几十条进去。代码层面大概是这样import requests def batch_embed(texts, batch_size32): all_vectors [] for i in range(0, len(texts), batch_size): batch texts[i:ibatch_size] resp requests.post( EMBEDDING_API_URL, json{input: batch, model: your-model}, headers{Authorization: fBearer {API_KEY}} ) vectors resp.json()[data] all_vectors.extend([v[embedding] for v in vectors]) return all_vectors这里有个坑批量大小不是越大越好。有些服务对单次请求的 token 总量有限制批次太大直接报错。我的经验是 batch_size 取 16 到 32 之间既不太慢也不容易超限。另一个关键点是缓存。文档更新频率通常很低但你可能反复重建索引。所以向量算完要存下来用文档块的哈希值做 key下次重建时先查缓存命中就不重复调 API。这一招能省下大量成本和时间。3.4 向量库的本地存储与检索向量算完了得有地方存。本地 RAG 常用的方案有 FAISS、Chroma、Qdrant 本地模式等。我一般用 FAISS因为它轻、快、纯本地不依赖额外服务。存的时候要注意向量和原文块要一一对应。我习惯用一个 JSON 文件存元数据字段包括块 ID、原文、来源文件、章节路径向量单独存成 FAISS 索引。检索时先拿 FAISS 返回的 ID 去 JSON 里捞原文。检索参数里top_k 不要设太大。很多人怕漏top_k 设成 10结果一堆无关片段挤进上下文反而干扰大模型。我的经验是 top_k 取 3 到 5配合一个相似度阈值低于阈值的直接丢掉。宁可少给不要给错。4. TXT 章节切分纯文本怎么切才不丢信息4.1 为什么 TXT 切分比 PDF 还难PDF 好歹有版面信息标题字号大、加粗能靠这些线索识别章节。TXT 是纯文本所有字都一样大章节边界全靠内容本身判断。这就导致两个极端切太碎一个完整段落被拆成好几块检索到的片段缺头少尾切太粗一个块里混了好几个主题向量被平均匹配精度暴跌。我见过最离谱的切分是按固定字数硬切每 500 字一刀。结果一个设备参数表被从中间切开前半截在块 A后半截在块 B用户问参数检索到块 A答案缺了一半。这种切法在 TXT 场景下必须避免。4.2 基于章节标记的切分策略TXT 虽然没格式但通常有隐式的章节标记。常见的有数字编号第一章、1.1、一、关键词概述、注意事项、技术参数、维护保养分隔线、----、****空行密度章节之间通常有空行我的切分策略是两级切分。第一级按章节标记切把文档切成大块第二级在大块内部按段落切保证每块不超过设定长度。具体实现上先用正则匹配章节标题行import re CHAPTER_PATTERN re.compile( r^(第[一二三四五六七八九十][章节]|[0-9]\.[0-9]*\s| r[一二三四五六七八九十]、|【.*?】) ) def split_by_chapter(text): lines text.split(\n) chapters [] current [] for line in lines: if CHAPTER_PATTERN.match(line.strip()) and current: chapters.append(\n.join(current)) current [line] else: current.append(line) if current: chapters.append(\n.join(current)) return chapters这个正则覆盖了大部分中文技术文档的章节格式。实际用的时候你得先拿几份真实文档跑一遍看看漏了哪些格式再补正则。4.3 块大小与重叠的取舍章节切完之后如果某个章节还是太长就得再切。这时候块大小怎么定我的经验值是300 到 500 字。低于 300 字语义太碎向量表达不完整高于 500 字一个块里可能混了多个子话题检索精度下降。这个区间是多次实测下来的甜点区。重叠overlap也要设。相邻块之间留 50 到 100 字的重叠防止关键信息正好卡在切分边界上。比如一个参数说明跨了两个块有重叠的话至少有一个块包含完整信息。但重叠不是越多越好。重叠太多向量库里全是重复内容检索时返回一堆相似片段浪费上下文窗口。50 到 100 字足够了。4.4 给每个块打上章节路径标签这一步很多人会忽略但对检索准确率提升很明显。每个块除了原文还要记录它的章节路径比如“第三章 维护保养 3.2 滤芯更换”。为什么要这个因为检索时可以用章节路径做过滤或加权。比如用户问“滤芯更换”如果某个块的章节路径里包含“滤芯”那它的相关性天然更高可以给它加个权重。另外喂给大模型时带上章节路径模型更容易理解这段内容的上下文位置生成的答案也更靠谱。实现上就是在切分时维护一个路径栈遇到章节标题就入栈切到具体块时把当前栈拼成路径字符串存进元数据。5. 完整链路串起来从对话到答案5.1 一次完整请求的处理流程把前面三块串起来一次用户请求的处理流程是这样的接收用户输入取出最近 N 轮对话历史。判断是否需要重写检测代词、句子完整性。执行 query 重写用小模型把当前 query 还原成自包含形式。重写失败兜底如果无法消解触发澄清反问。向量化 query调云端 embedding 接口。检索向量库top_k 取 3 到 5带相似度阈值过滤。组装上下文把检索到的块按章节路径排序拼成 prompt。调用大模型生成答案prompt 里带上对话历史和检索片段。返回答案同时把本轮对话存入历史。这个流程里第 3 步和第 5 步是两次模型调用加上第 8 步的生成一次请求至少三次模型交互。延迟会比单轮 RAG 高但准确率的提升值得。如果延迟敏感可以把重写和向量化并行或者用更小的模型做重写。5.2 上下文组装的技巧检索到片段之后怎么拼进 prompt 也有讲究。我一般按这个模板你是一个知识库问答助手。请根据以下参考资料回答用户问题。如果参考资料中没有相关信息请明确说明“资料中未提及”不要编造。 参考资料 [片段1] 章节第三章 维护保养 3.2 滤芯更换 内容... [片段2] 章节第三章 维护保养 3.1 保养周期 内容... 对话历史 用户XX-200 的保养周期是多久 助手建议每 500 小时保养一次。 用户问题那它的滤芯呢 请回答关键点有三个一是明确要求“不知道就说不知道”这是防幻觉的底线二是片段带章节路径帮模型定位三是把对话历史也带上让模型理解当前问题的语境。5.3 效果对比改前改后差多少我拿同一批 50 个多轮追问测试用例跑过对比。改之前也就是不做指代消解、本地 embedding、固定字数切分准确率大概 52%。改之后指代消解加云端向量加章节切分准确率到了 81%。提升最明显的是含代词的追问从 30% 出头涨到接近 80%。这个提升不是靠换大模型来的模型全程没变。纯粹是检索环节的优化。所以如果你现在的 RAG 答不准先别急着换模型把检索链路捋一遍收益可能更大。6. 踩过的坑与排查清单6.1 指代消解把 query 改歪了最常见的问题是重写模型过度发挥。比如用户问“这个多少钱”上文提的是 A 产品但用户其实在问 B 产品。模型硬把“这个”消解成 A检索就错了。排查方法把每轮重写前后的 query 都打日志定期人工抽查。发现改歪的案例补充到提示词的 few-shot 示例里。我一般会放 3 到 5 个正例和反例在提示词里效果比纯指令好很多。另一个技巧是限制重写幅度。如果重写后的 query 和原 query 的编辑距离太大就标记为可疑走澄清反问。这样能拦住大部分过度改写。6.2 云端向量接口超时或限流批量建库时云端接口偶尔会超时或返回 429。这时候不能直接崩要有重试机制。我的做法是指数退避重试第一次等 1 秒第二次 2 秒第三次 4 秒最多重试 3 次。同时把失败的批次记下来最后统一补跑。另外建库最好分批进行别一次性把几千个块全塞进去。每批处理完存一次盘万一中途挂了不用从头再来。6.3 章节切分把表格切碎了TXT 里的表格是切分重灾区。一个参数表如果被从中间切开检索到的片段就是残缺的。我的处理办法是在切分前先识别表格区域连续多行包含制表符或对齐空格的标记为表格块整块不切。如果表格太长超过块大小上限就按行切但每块都带上表头。识别表格可以用简单的启发式连续 3 行以上包含多个连续空格或制表符就认为是表格。6.4 常见问题速查表现象可能原因排查方向追问答非所问指代未消解看重写日志检查代词是否还原答案缺一半切分把内容切断检查块边界加重叠检索结果全是无关片段向量模型不匹配换云端模型或调 top_k 和阈值建库特别慢没批量、没缓存上批量接口和哈希缓存模型编造答案prompt 没约束加“不知道就说不知道”指令同义术语搜不到embedding 语义弱换中文能力强的云端模型6.5 几个我踩过的具体坑坑一对话历史存太多。一开始我把全部历史都存下来喂给重写模型结果模型被早期无关话题干扰。后来改成只取最近 3 轮效果反而更好。历史不是越多越好够用就行。坑二向量维度选太高。试过 3072 维检索没快多少存储和内存占用翻倍。后来退回 1536 维性价比最高。坑三章节正则太严。一开始正则只匹配“第X章”结果文档里用“一、”“1.1”的章节全漏了。后来把常见格式都加上覆盖率才上来。建议拿真实文档跑一遍看漏了什么再补。坑四忘了给块去重。文档里有重复内容切完块之后向量库里一堆重复检索时返回好几个一样的片段浪费上下文。后来在建库时加了去重按内容哈希过滤。7. 后续还能怎么优化这套方案跑通之后还有几个方向可以继续打磨。一是重写模型换更小的。现在用 7B 做重写其实有点浪费。试过 1.5B 的模型在指代消解这个特定任务上配合好的提示词效果差距不大但速度快了一倍多。如果你的硬件紧张可以往这个方向试。二是加一层重排序Rerank。向量检索召回 top_k 之后再用一个重排序模型对候选片段精排。这一步能进一步提升精度尤其是 top_k 设得比较大的时候。重排序模型也有云端和本地可选本地的小模型就够用。三是章节路径做加权检索。现在章节路径只是拼在 prompt 里其实还可以参与检索打分。比如 query 里出现“滤芯”那章节路径含“滤芯”的块加权。这个改动不大但效果立竿见影。四是建一个 badcase 库。每次发现答错的案例把 query、检索到的片段、正确答案都存下来。积累到一定量可以用来微调重写模型或者优化切分规则。这个习惯我从做第一个 RAG 项目就保持到现在回报很大。最后分享一个我自己的体会本地 RAG 做准这件事八成的功夫在检索前和检索中不在生成。很多人把精力花在换更大的生成模型上但检索拿到的上下文是错的再大的模型也救不回来。把指代消解、向量模型、切分策略这三块打磨好哪怕生成模型小一点答案的准确率也能上一个台阶。