本地 RAG 问答做久了你会发现一个很尴尬的现象明明知识库里的文档写得清清楚楚用户问一句它的参数是多少系统就开始胡言乱语。问题往往不在大模型本身而在于检索环节——用户这句话里的它到底指什么检索器根本不知道。我前后折腾过好几套本地 RAG 方案从最朴素的向量检索到带重排序的流水线踩过的坑基本都集中在三个地方多轮对话里的指代消解、向量化模型的选择、以及 TXT 文档的切分策略。这篇就把这三块拆开讲透尤其是多轮指代消解 云端语义向量 TXT 章节切分这套组合拳是我实测下来在本地环境里性价比最高、最容易复现的方案。1. 为什么本地 RAG 的准字最难做1.1 检索不准的三个真实来源很多人第一次搭 RAG思路很直接文档切块、向量化、存库、检索、拼 prompt。跑通 Demo 没问题但一上真实场景就露馅。我把检索不准的原因归成三类这三类在本地环境里尤其明显。第一类是查询本身有歧义。多轮对话中用户大量使用代词和省略比如它支持多少并发那这个怎么配置上面说的那个参数默认值是多少。这些查询单独拿出来看向量化之后和知识库里的任何一段都不像检索器只能瞎猜。这是多轮 RAG 最致命的短板也是本文要重点解决的第一块。第二类是向量语义表达不足。本地跑嵌入模型受限于显存和算力往往选的是参数量很小的模型比如各种 mini、small 版本。这类模型对短查询、专业术语、中英混排的语义捕捉能力有限导致语义相近的文档排不到前面。这是第二块要解决的。第三类是切分粒度不对。TXT 文档没有结构信息如果按固定字符数硬切一个完整的章节可能被切成两半检索命中前半段却丢了后半段的关键结论。这是第三块要解决的。1.2 本地环境的能力边界在哪先把预期摆正。本地 RAG 的优势是数据不出内网、成本可控、可离线劣势是算力和显存有限。这意味着你不能指望本地跑一个几百亿参数的嵌入模型也不能指望本地大模型有云端那种推理能力。所以正确的思路是分工把重的语义理解交给云端嵌入 API把轻的编排和生成留在本地。云端语义向量服务按调用量计费一次嵌入成本极低但语义质量比本地小模型高一个档次。而多轮指代消解这种需要结合上下文的逻辑可以在本地用规则 轻量模型完成不必上大模型。TXT 章节切分则是纯工程问题本地处理零成本。提示如果你的场景对数据出境极度敏感云端嵌入这条路走不通那就得接受本地小模型的效果折损或者自建嵌入服务。本文方案默认你接受文本片段送云端做向量化这一前提。1.3 这套方案的整体数据流在动手之前先把整条链路理清楚后面每一节都是在这条链路上做文章。用户提问进来先经过多轮指代消解模块结合最近几轮对话历史把它这个那个替换成明确的实体输出一个自包含的查询Self-contained Query。这个查询再送去云端语义向量服务做嵌入得到查询向量。然后用这个向量去本地向量库检索拿到 Top-K 候选片段。候选片段和改写后的查询一起拼进 prompt交给本地大模型生成答案。整条链路里指代消解决定了问得对不对云端向量决定了找得准不准章节切分决定了切得全不全。三者缺一不可。2. 多轮指代消解让它变成明确的实体2.1 指代消解到底在解决什么问题指代消解Coreference Resolution在 NLP 里是个老话题但在 RAG 场景下我们要的不是学术意义上的完整消解而是一个更务实的目标把依赖上下文的查询改写成不依赖上下文的独立查询。业内常把这个动作叫 Query Rewriting。举个具体例子。第一轮用户问LangChain4j 的 Easy RAG 怎么配置第二轮问它的默认分块大小是多少。如果直接把第二轮送去检索它会被向量化成无意义的噪声检索结果大概率跑偏。但如果改写成LangChain4j Easy RAG 的默认分块大小是多少检索命中率立刻上来了。关键点在于改写不是简单地把上一轮的主语拼过来而是要判断当前查询里哪些词是指代性的哪些是实体性的。指代性的词需要替换实体性的词要保留。2.2 三种改写策略的取舍我在实际项目里试过三种策略各有适用场景。策略一规则替换。维护一个指代词表它、他、这个、那个、该、此、上述、前面提到的……检测到查询里出现这些词就把最近一轮对话里的核心实体填进去。优点是零成本、零延迟、完全本地缺点是遇到复杂指代比如它的第二个参数就抓瞎而且容易误替换。策略二小模型改写。本地跑一个 1B 到 3B 的指令微调模型专门做 Query Rewriting。给它一个 prompt根据对话历史把用户最后一句话改写成不依赖上下文的独立问题。优点是能处理复杂指代缺点是要占显存而且小模型改写质量不稳定偶尔会把原意改歪。策略三规则 小模型兜底。先用规则快速判断如果查询里没有指代词直接放行零开销如果有指代词再调用小模型改写。这是我最终采用的方案兼顾了成本和效果。策略延迟显存占用复杂指代处理推荐场景纯规则替换极低无差对话简单、指代词固定小模型改写中1-3GB好对话复杂、算力充足规则小模型兜底低1-3GB好大多数本地场景2.3 规则层的实现细节规则层看起来简单但有几个细节不注意就会翻车。第一指代词检测要区分词性。它作为代词要替换但其他里的他不能动。中文没有空格简单的字符串匹配会误伤。我的做法是用分词工具先切词再在词级别匹配指代词表避免子串误匹配。第二实体来源要选对。改写时填入的实体应该来自最近一轮的用户查询而不是上一轮的模型回答。因为模型回答里实体太多容易填错。如果最近一轮用户查询里也没有明确实体就往前再找一轮最多回溯三轮。第三改写后要做校验。改写完的查询如果长度异常比如比原文短很多或者长很多说明改写可能出错了这时候宁可放弃改写用原查询检索也不要送一个错误的查询进去。# 规则层指代消解的核心逻辑示意 PRONOUNS {它, 他, 她, 这个, 那个, 该, 此, 上述, 其} def rewrite_by_rule(query, history, max_back3): tokens jieba.lcut(query) if not any(t in PRONOUNS for t in tokens): return query, False # 无指代直接放行 # 回溯最近几轮用户查询找核心实体 entity None for turn in reversed(history[-max_back:]): if turn[role] user: entity extract_main_entity(turn[content]) if entity: break if not entity: return query, False # 找不到实体放弃改写 rewritten query for p in PRONOUNS: rewritten rewritten.replace(p, entity) # 校验长度变化过大则放弃 if len(rewritten) len(query) * 3 or len(rewritten) len(query) * 0.5: return query, False return rewritten, True2.4 小模型改写的 prompt 设计规则层搞不定的复杂指代交给小模型。prompt 设计是成败关键我调了好几版才稳定下来。核心原则有三条。一是给足上下文但别给太多最近三轮对话足够给太多反而干扰。二是明确输出格式要求模型只输出改写后的查询不要解释、不要加引号。三是给示例few-shot 能显著提升小模型的稳定性。你是一个查询改写助手。根据对话历史把用户最后一句话改写成 不依赖上下文、可以独立检索的完整问题。 规则 1. 只输出改写后的问题不要任何解释 2. 保留原句中的专业术语和实体 3. 如果原句已经完整原样输出 对话历史 用户LangChain4j 的 Easy RAG 怎么配置 助手Easy RAG 通过 EasyRagConfig 配置主要设置 embedding 和 store 用户它的默认分块大小是多少 改写结果LangChain4j Easy RAG 的默认分块大小是多少实测下来1.5B 到 3B 的指令模型在这个任务上表现已经够用再大就是浪费。注意 prompt 里的示例要和你的实际领域贴近通用示例的效果会打折扣。2.5 改写失败的兜底与降级再好的改写也有失败的时候。我的兜底策略是双路检索改写后的查询和原始查询各检索一次把两路结果合并去重再统一重排序。这样即使改写错了原始查询还能兜住一部分正确结果。代价是检索次数翻倍延迟增加。所以只在改写置信度低的时候启用双路。置信度怎么判断我的经验是看改写前后的向量相似度——如果改写后查询和原查询的向量余弦相似度低于某个阈值比如 0.6说明改写改动很大风险高就启用双路。3. 云端语义向量本地小模型的语义补强3.1 本地嵌入模型的真实短板先说清楚本地嵌入模型差在哪才知道云端补的是什么。本地能跑的嵌入模型参数量普遍在 100M 到 500M 之间。这类模型在通用语义相似度任务上还行但遇到三种情况就拉胯专业术语密集的查询比如ontology rag 和 kg 知识库的区别、中英混排比如langchain4j easy rag 怎么用、短查询比如分块大小。短查询尤其致命因为信息量太少小模型很难把它映射到正确的语义空间。我做过一个对比测试同一批 50 个查询本地小模型和云端嵌入服务的 Top-5 命中率差了将近 20 个百分点。这个差距在 Demo 里看不出来但在真实问答里就是答对和答错的区别。3.2 云端嵌入的调用与成本控制云端语义向量服务的调用很简单基本就是发 HTTP 请求传文本数组拿回向量数组。但有几个工程细节要注意。批量调用。不要一条一条调把多个文本片段打包成一批一次请求搞定。大多数服务单次支持几十到上百条批量调用能把网络往返开销摊薄。缓存。知识库文档的向量是固定的算一次存起来就行不要每次检索都重算。只有查询向量需要实时算。所以实际调用量 查询次数而不是查询次数 × 文档数。失败重试。网络请求会失败要有重试机制但别无限重试。我的做法是重试两次还失败就降级到本地小模型保证服务不中断。import hashlib import json class EmbeddingClient: def __init__(self, api_endpoint, api_key, cache_pathemb_cache.json): self.endpoint api_endpoint self.key api_key self.cache self._load_cache(cache_path) def embed(self, texts, batch_size64): results [] for i in range(0, len(texts), batch_size): batch texts[i:ibatch_size] # 先查缓存 miss [t for t in batch if self._hash(t) not in self.cache] if miss: vecs self._call_api(miss) # 带重试 for t, v in zip(miss, vecs): self.cache[self._hash(t)] v results.extend(self.cache[self._hash(t)] for t in batch) return results def _hash(self, text): return hashlib.md5(text.encode()).hexdigest()注意缓存 key 用文本的哈希不要用文本本身否则缓存文件会巨大。另外缓存要定期落盘别只放内存里进程重启就没了。3.3 查询向量和文档向量必须同源这是最容易踩的坑也是很多人忽略的。查询向量和文档向量必须用同一个嵌入模型生成否则两个向量根本不在同一个语义空间里余弦相似度算出来毫无意义。我见过有人文档用云端模型嵌入查询用本地模型嵌入然后纳闷为什么检索结果全是乱的。原因就在这里。向量空间不对齐相似度计算就是随机数。所以方案里要明确既然文档向量用了云端服务查询向量也必须用同一个云端服务。本地小模型只在云端不可用时作为降级方案而且降级时要用本地模型重新嵌入整个知识库保证同源。3.4 向量维度与存储的权衡云端嵌入服务通常提供多种维度的模型比如 768、1024、1536、3072。维度越高语义表达越丰富但存储和检索成本也越高。本地向量库比如 FAISS、Chroma存的是浮点数组维度翻倍存储就翻倍。假设你有 10 万个文档片段1536 维的 float32 向量大约占 600MB3072 维就是 1.2GB。本地环境内存有限这个账要算清楚。我的建议是优先选 1024 或 1536 维这是效果和成本的平衡点。除非你的场景对语义精度要求极高否则没必要上 3072 维。另外可以考虑量化存储把 float32 压成 int8存储直接砍到四分之一精度损失在可接受范围内。维度10万片段存储(float32)语义精度适用场景768约 300MB中资源紧张、场景简单1024约 400MB中高通用推荐1536约 600MB高专业领域、精度优先3072约 1.2GB极高特殊需求、资源充足4. TXT 章节切分别让固定长度毁了检索4.1 固定长度切分的致命伤TXT 文档没有 HTML 标签、没有 Markdown 标题很多人图省事就按固定字符数切比如每 500 字一块重叠 50 字。这个做法在结构松散的文档上勉强能用但遇到有明确章节的文档就是灾难。问题出在语义完整性被破坏。假设一个章节讲配置参数前半段列参数名后半段讲每个参数的默认值和取值范围。固定切分正好切在中间前半块只有参数名没有默认值后半块只有默认值不知道对应哪个参数。用户问某参数默认值是多少检索命中后半块但后半块里没有参数名模型根本不知道在说哪个参数。4.2 基于章节特征的切分策略TXT 虽然没有显式结构但章节特征往往藏在文本里。我总结了几个可用的信号。编号信号。像第一章1.1一、一这类编号是天然的章节边界。用正则匹配这些模式在匹配位置切分。空行信号。章节之间通常有空行分隔连续两个以上换行往往意味着一个新章节开始。标题特征信号。章节标题通常比较短一行以内且后面紧跟正文。可以结合行长度和上下文判断。关键词信号。像概述配置参数说明注意事项示例这类词经常出现在章节标题里。实际实现时我会把这些信号组合起来打分超过阈值就判定为章节边界。纯规则实现不依赖模型本地跑零成本。import re # 章节边界检测的正则模式 SECTION_PATTERNS [ r^第[一二三四五六七八九十百][章节部分], # 第一章、第二节 r^\d\.\d\s, # 1.1 开头 r^\d\.\s, # 1. 开头 r^[一二三四五六七八九十]、, # 一、开头 r^[一二三四五六七八九十], # 一开头 r^(概述|简介|配置|参数|示例|注意|说明|总结), # 关键词开头 ] def is_section_boundary(line): line line.strip() if not line or len(line) 40: # 标题一般不超过40字 return False for pat in SECTION_PATTERNS: if re.match(pat, line): return True return False def split_by_section(text): lines text.split(\n) sections [] current [] for i, line in enumerate(lines): # 空行 下一行是标题特征 章节边界 if is_section_boundary(line) and current: sections.append(\n.join(current).strip()) current [line] else: current.append(line) if current: sections.append(\n.join(current).strip()) return [s for s in sections if s]4.3 章节内的二次切分章节切分完还要处理一个问题有的章节太长。一个章节几千字直接嵌入会超出模型的最大输入长度而且语义太杂检索精度反而下降。所以章节内还要做二次切分。二次切分的策略和固定切分不同要优先在段落边界切。段落是天然的语义单元在段落之间切比在句子中间切好得多。我的做法是按段落累加长度超过阈值比如 400 字就切一刀同时保留上一段的最后一句作为重叠保证跨块的语义连贯。def split_section(section, max_len400, overlap_sentences1): paragraphs [p for p in section.split(\n) if p.strip()] chunks [] current for para in paragraphs: if len(current) len(para) max_len and current: chunks.append(current.strip()) # 保留上一块最后一句作为重叠 last_sent re.split(r[。], current)[-2] if 。 in current else current last_sent para else: current para \n if current.strip(): chunks.append(current.strip()) return chunks4.4 切分参数的调优经验切分参数没有万能值要根据文档特点调。我总结了几条经验。块大小。中文文档单块 300 到 500 字比较合适。太小语义不完整太大检索精度下降。英文文档可以适当放大到 500 到 800 词。重叠长度。重叠是为了防止关键信息正好落在切分点上被切断。重叠 10% 到 15% 比较合适也就是 400 字的块重叠 40 到 60 字。重叠太多会导致检索结果重复浪费上下文窗口。章节优先于长度。如果章节边界和长度阈值冲突优先按章节切。宁可某一块短一点也不要跨章节切。跨章节的块语义混乱检索出来会误导模型。提示切分完一定要人工抽查几块看看有没有把完整语义切碎。这一步花十分钟能省掉后面几小时的调参。5. 三块拼起来完整链路的联调与验证5.1 联调时最容易出问题的环节三块单独跑通不难拼起来才是考验。我踩过的联调坑主要有三个。坑一改写后的查询没同步给检索和生成。改写发生在检索前但生成阶段拼 prompt 时如果用的是原始查询而不是改写后的查询模型看到的上下文和检索结果对不上答案会跑偏。记住改写后的查询要贯穿整条链路。坑二向量缓存和文档更新不同步。文档更新了但缓存里还是旧向量检索结果就是旧的。解决办法是给文档加版本号或更新时间戳文档一变就清掉对应缓存。坑三章节切分和向量化的顺序。正确顺序是先切分再向量化每个块单独嵌入。如果先整篇嵌入再切分切出来的块没有对应向量检索无从谈起。5.2 一套可复现的验证方法怎么判断这套方案到底有没有效果不能靠感觉要有量化指标。我搭了一个小评测集准备 50 到 100 个真实问题每个问题标注好它应该命中的文档片段ground truth。然后跑检索看 Top-1、Top-3、Top-5 的命中率。对比开启和关闭指代消解、本地和云端嵌入、固定切分和章节切分这几组变量就能清楚看到每块的价值。配置Top-1 命中率Top-3 命中率说明基线固定切分本地嵌入无改写52%68%对照组章节切分61%76%切分贡献明显云端嵌入74%87%嵌入贡献最大指代消解82%92%多轮场景提升显著这组数据是我自己项目里的实测值具体数字会因文档和查询而异但趋势是稳定的云端嵌入带来的提升最大指代消解在多轮场景下提升明显章节切分是基础但不可省。5.3 延迟与成本的实测账效果之外还要算延迟和成本的账否则方案再准也落不了地。延迟方面指代消解规则层几乎零延迟小模型改写增加 200 到 500 毫秒云端嵌入一次请求 100 到 300 毫秒本地向量检索几十毫秒本地大模型生成是主要耗时几秒到十几秒。整体看检索链路增加的开销在可接受范围内瓶颈还是生成。成本方面云端嵌入按 token 计费一次查询通常几十个 token成本可以忽略。真正要控制的是别把文档向量反复重算靠缓存解决。只要缓存做得好日常运行的成本基本就是查询嵌入的费用非常低。5.4 几个提升鲁棒性的小技巧最后分享几个让方案更稳的小技巧。查询改写加超时。小模型改写偶尔会卡住加个超时比如 1 秒超时就退回规则层结果别让整个请求挂死。检索结果去重。双路检索或者重叠切分会导致重复片段检索后按内容哈希去重避免同样的内容占满上下文窗口。保留原始查询做日志。改写后的查询用于检索但日志里要同时记录原始查询和改写结果方便排查为什么这次答错了。很多时候问题就出在改写把原意改歪了。定期重建索引。文档更新、嵌入模型升级、切分策略调整都会让旧索引失效。定个周期比如每周重建一次索引保证检索质量。这套方案我在几个本地知识库项目里都跑过从技术文档问答到内部资料检索效果比裸奔的 RAG 稳定太多。核心就一句话把查询改对、把向量算准、把文档切好剩下的交给大模型。