做过几个 LLM 问答项目后你会发现单靠模型本身的知识去回答垂直领域问题上下文稍微具体一点就答非所问或者一本正经地编。RAG检索增强生成就是当前落地成本最低、见效最快的一剂补药而这篇要聊的是 ACP-LLM 项目里 RAG 部分的第二个阶段。第一篇我们搭完了从文档解析、向量化到检索生成的基础链路这一篇会把决定线上效果好坏的进阶环节逐个拆开不只讲怎么选更要讲清楚为什么选它以及那些文档里根本不会写的坑。1. 进阶 RAG 的整体设计与一条链路上的取舍1.1 基础 RAG 跑通之后下一步瓶颈出在哪先快速对齐一下基础链路的形态。文档进来后做解析、清洗、分块、向量化然后把向量写入向量数据库回答问题时拿到用户 query 向量化在库里做 ANN 近似最近邻检索取回 Top-K 个片段作为上下文连同问题一起交给 LLM 生成答案。这个流程初版不难但一旦放入真实业务场景问题立刻暴露。我在实际项目里遇到最多的三类瓶颈基本代表了 RAG 进阶要解决的核心矛盾。第一类是召回精度。向量检索对这种语义匹配场景很友好但它本质上是将“相关性”压成一个向量距离两个语义相似但表述结构差异很大的句子向量距离未必近。更多时候用户 query 里包含精确关键词、编号、型号这类信息靠纯向量检索往往丢分严重Top-K 里真正可用的片段经常不足一半。第二类是上下文质量。检索回来的片段数量是有限的如果分块大小不合适、块内混入大量噪声或者多轮对话中用户意图本身模糊那么拼给模型的上下文既浪费 token又干扰最终答案。这里的问题通常不是模型能力而是输入的信息密度太低。第三类是生成可靠性。模型拿到相关片段之后仍然可能偷懒不引用原文或者把多个片段的信息串在一起编出新内容。这类问题靠调 prompt 能压一部分但根源在于检索端有没有提供足够忠实、清晰的证据结构。基础 RAG 能回答“能跑吗”但回答不了“跑得好不好”。进阶阶段的核心工作是把这条链路从可用推到好用。1.2 进阶阶段的路线图每一环都在解决一个失真问题在 ACP-LLM 的第二阶段我的设计主线是围绕信息失真去做补偿。数据从原始文档到最终答案中间要经历语义保持、位置保持和相关性保持任何一个环节失真都会直接体现为答案质量下降。所以整体拆成这样几条工作线。文档层做清洗与结构化提取解决原始信息颗粒度不一致的问题分块层做递归与结构化分块解决语义撕裂的问题索引层做向量与关键词的混合检索解决单一检索策略各有盲区的问题生成层做引用回溯与精简上下文解决模型不信不忠实利用证据的问题。这条路线和做索引的思路很像先保证数据被正确写入再保证查询能精准命中最后保证命中的结果能以高质量格式输出。每一条线之间是递进关系前面做不好后面优化的空间非常有限。这篇的实际操作顺序也建议从文档处理开始而不是先想着微调模型或者换更大的模型。2. 文档预处理与分块策略这是最容易被低估的一层2.1 文档清洗和结构化提取的实操要点经常有人把 PDF 扔进解析器拿出来的文本又乱又碎就直接丢进切分器。这样后面的向量化基本是在垃圾堆里找黄金。文档级预处理的核心目标只有一个把“给人看”的排版信息还原成“给模型看”的语义单元。我的标准流程是三步。第一步做解析把 PDF、Word、HTML 各自转成纯文本或 Markdown第二步做规则清洗去除页眉页脚、多余换行、表格错位、OCR 噪声第三步做结构识别尽量把标题层级、段落边界、表格结构标记出来。第三步的产出直接影响分块质量因为后续分块要依据标题和段落边界做切分。清洗这一步有几个容易忽略的细节。PDF 解析出的文本经常会在表格和双栏布局上乱序常见的正则没法处理建议优先看解析器输出的坐标信息按坐标排序后再拼接收益很大。另外段落中如果出现箭头、项目符号等冗余字符要设计黑名单替换避免这些符号混进向量特征里。表格数据是一个特殊项。直接把表格拍平成一行文字会让细胞之间的语义关系丢失。我的做法是保留 Markdown 表格结构并在分块时把表格作为一个整体块处理而不是和上下文混切。这样检索到表格时模型看到的是完整行列关系而不是被切碎的单元格。2.2 固定分块、递归分块与结构化分块怎么选分块大小和重叠率是一个流传很广的经验参数网上说法从 256 到 1024 不等实际上没有一个万能值。分块太小语义上下文不完整分块太大向量平均化之后精度下降且浪费上下文窗口。我用的基准策略是递归字符分块核心是层级回退先用段落标记切分如果块太小向上升级到章节如果块太大向下递归到句子级别。这个策略能让块的大小尽量跟随语义边界而不是被硬切。结构化分块是在递归分块之上叠加元信息。切分时把当前块所属的标题路径、文档名、页码记录下来组成类似这样的块结构{ content: 块正文内容..., metadata: { doc_id: manual_v3_12, chapter: 3.2 故障诊断, section: 3.2.1 电源指示灯异常, page: 8 } }这个 metadata 后面有两个用处。一是检索时可以做过滤用户只查某个章节时直接在库层先过滤再检索二是生成时可以把标题路径回填进 prompt模型能明白这段内容的上下文位置回答会可靠很多。分块重叠率我一般控制在 10% 到 15%。重叠的目的是防止检索时句子被从中间截断但重叠太多会让库里出现大量近似重复的向量既占空间又容易在召回时出现同一段话的多个变形体挤占 Top-K 名额。2.3 分块中的常见错误硬切句子和过度切分犯过最多次的错误是硬按固定字数切分比如 char_split 一下按 500 字符切。这种切法会让句子、表格、列表项被拦腰截断检索时虽然也能命中但召回片段往往缺失结论或前提模型只能靠猜。后期评估时会发现这类块贡献了相当比例的幻觉样本。另一个坑是过度追求块粒度小以为块越小匹配越精确。试过 200 字左右的小块匹配率确实看起来高但生成时模型缺乏上下文来理解指代关系比如块里出现“该方法”却不知道方法主体在上一块。小块方案必须搭配强大的重排序和上下文归并机制否则不如稳妥用 400~600 字的中块。3. 向量化、混合检索与重排序召回质量的关键引擎3.1 Embedding 模型选型按语言和领域综合判断向量化是对语义的一次投影embedding 模型的能力直接决定了后续检索的上限。选模型时我主要看三点语言覆盖度、检索能力、以及句长支持。中文场景下建议优先找在中文语料上有充分训练的开源模型而不是直接用英语模型。通用域模型跑垂直领域文本时也需要验证因为领域术语的语义表示差异很大。选型时必须做一件事自己构建一个几十条的领域测试集把模型逐个跑一遍计算 RecallK。有一个容易被忽略的点是 query 和 document 的表示不对称问题。很多模型在训练时对 query 和 document 采用了不同的编码方式比如一个模型输出维度为 1024但内部对短 query 和长文本各有独立优化。实际使用时要按模型建议的规范拼接输入不要随手把 query 直接塞进文档编码接口。另外embedding 模型不是越新越好而是越匹配越好。评估指标上我会重点看中等召回数量下的命中率比如 Recall10 是否够硬而不是只盯着单一分数。同时要看模型对长文档的编码稳定性有些模型超过 512 token 之后向量质量急剧下降这决定了分块大小上限。3.2 向量索引参数关于 ANN 的误区向量数据库的检索性能靠索引实现常见的是基于图的近似索引。这里的参数选择存在很多想当然。很多教程会告诉你调 M 和 efConstruction但没人解释这两个参数的控制范围。M 控制每个节点的连接数影响索引的稠密程度。M 越大查询精度越高但索引体积和内存占用也越大。efConstruction 是构建图时的动态候选集大小影响索引质量构建完成后不再参与查询。查询时还有一个 ef_search决定检索时的探索范围这才是线上可动态调的精度开关。我的建议是索引构建阶段 M 值可以设大一点确保质量比如 16 到 32efConstruction 设 200 到 400。线上查询把 ef_search 设为一个中间档位如果召回率不够再往上加而不是一开始就把索引建得很粗。做索引耗时是个一次性成本但查询延迟是每个请求都要付出的精度与延迟的平衡点在更新 ef_search 时找。3.3 混合检索让精确匹配和语义检索互补纯向量检索在长尾专有名词上表现不稳定最典型的例子是用户搜索一个设备型号比如“ABC-200 电源故障”向量召回的结果可能全是泛泛的电源知识而真正包含这个型号的文档片段排在后面。这种问题用混合检索几乎是必解向量检索负责语义相关关键词检索负责精确命中。关键词侧我常用 BM25 算法核心思想是词频和稀有度加权对精确匹配非常友好。混合检索要做的是把两个结果列表按同一标准融合。直接用分数加权容易出问题因为向量分数和 BM25 分数分布不一致。我更倾向于先做倒序归一化把位置信息转成分数再按权重融合。权重设定需要动态观察。预设词命中密集的 query 上比如用户粘贴了一段报错日志关键词权重应加大纯语义表述的 query比如“如何判断设备过热风险”向量权重应加大。线上实现可以做一个简单的 query 分析按包含的专有名词数量、引号比例、文本长度来选择权重实测比固定权重稳定很多。3.4 重排序最后一道精排关卡检索阶段为了召回率往往会取回较多片段比如 Top-20。直接把这 20 个片段全部塞给模型非常浪费且有害。重排序环节用更强的模型对 query 和每个片段做精细相关性打分再用分数挑出 Top-5。这个思路和经典搜索里的粗排、精排两段式完全一致。重排序模型普遍对中文有专门优化使用体验上最大的区别在于输入形式。有些重排序模型支持交叉编码器把 query 和文档拼接后打分精度高但计算量随文档数线性增长。好在 Top-20 这个量级完全扛得住。重排之后的效果提升通常非常明显我见过不少项目不加重排时答案质量差得明显加上之后肉眼可见改善。这里有一个细节重排分数的绝对值不能跨请求比较它只用于本请求内部的片段排序。所以不要试图设置一个全局限定阈值去过滤而是宁可保留固定数量比如始终取 Top-5让后续生成策略去兜底。4. 生成侧优化上下文编排、引用溯源和多轮对话4.1 Prompt 模板怎样才让模型愿意用上下文生成阶段最常见的误区是 prompt 里堆满指令什么“你必须严格根据上下文回答”“不要编造”但上下文本身一团乱。模型不是不愿遵循而是不知道该信谁。我的模板设计原则很简单上下文放在前问题放在中约束放最后。上下文用清晰的标记区分每一条来源并带上 metadata 里的标题路径。这样模型能知道每段文字的出处语境。一个可复用的模板结构大致是【背景资料】 来源1标题xxx 章节yyy 内容... 来源2标题xxx 章节yyy 内容... 【用户问题】 问题... 【要求】 1. 优先依据背景资料回答若资料不足请明确说明缺失信息。 2. 引用资料中的关键依据时请标注对应来源编号。 3. 不要将不同来源的信息拼接成不存在的事实。实测里把来源编号和标题路径写清楚之后模型的“幻觉”明显减少而且回答更结构化。这不全靠 prompt 技巧本质上是你给模型提供了足够的证据链。4.2 引用溯源给每个答案装上定位锚点RAG 落地到企业内部用户不只是要一个答案还要能核验。引用溯源的核心是让生成结果和检索片段建立对应关系。实现上可以在 prompt 要求模型在引用依据后输出编号后在解析层把模型输出的编号映射回 metadata 的文档标题和页码。做引用映射的时候要注意一个细节模型生成的编号不一定对应 prompt 里的原始编号偶尔会自己乱写。所以解析之后要做一次校验检查引用的片段编号是否真实存在于本次检索结果中不存在就把引用标记为无效。校验不通过时宁可显示“AI 生成无直接引用”也不要让用户被错误引用误导。4.3 多轮对话query 改写是绕不开的RAG 里的多轮对话不能直接把用户当前这句话拿去检索。用户说“那它的功率呢”如果你不知道“它”指代的是什么检索一定会偏。我的做法是引入 query 改写模块利用 LLM 把整段对话历史中的指代信息改写成完整、独立的检索 query再拿去向量化检索。这里有更省事但不太可靠的做法是直接把最近几轮对话拼接后检索试过之后发现拼接的噪声会把语义带偏。改写显然更干净。改写后的 query 要用好。另一个实用技巧是改写模块返回两种结果一个用于检索的完整 query一个用于生成阶段展示的用户原始 query。生成阶段仍然用用户原话来提问避免模型被改写后的措辞带歪。5. 评测体系与问题排查实录让效果可量化5.1 怎么搭建一套不骗自己的评测集RAG 改进如果没有评测基本属于自嗨。要判断某个环节是否真的有效关键是有一套固定的评测集和标准指标。我建议按场景构建百条级别的评测样本每一条包含标准 query、对应的黄金片段列表、可接受答案要点。离线评测时我会同时看四个维度检索命中率、上下文精确率、生成忠实度、答案有用率。检索命中率反映检索端能不能找回黄金片段上下文精确率看找回的 Top-K 里有多少是真正相关的生成忠实度看答案是否能从上下文中推出答案有用率则让评测者手工判断最终答案能不能直接用。线上效果观测也要做。在日志里记录每次问题的检索 Top-K 来源、最终引用来源、用户反馈每周做一次抽样复核。如果发现线上失效案例大幅增长通常不是模型出问题而是新文档入库后分块不合理或者检索权重需要调整。5.2 高频问题与排查思路速查整理一张速查表很有必要我按实际踩坑频率排过序大致如下现象优先排查方向常见解决方式问题上千条但答案经常错误分块是否撕裂语义边界换成递归结构分块观察命中块边界专有名词、编号检索不到纯向量检索盲区引入 BM25 混合检索召回了相关片段但答案仍花式编造上下文信息密度低或模板未引导引用精简 Top-K加来源编号和引用要求片段内出现截断的解释说明分块固定字数硬切割增加重叠率或按句子边界切分相似问题反复回答不一致缺乏评测基线构建评测集锁定参数版本检索延迟波动大ef_search 参数过大或召回量过大固定召回数量逐步调低 ef_search新文档录入后质量明显下降清洗规则未覆盖新格式检查解析坐标、扩展清洗规则排查思路上有一点值得多讲出现质量问题时不要把锅都推给 embedding 模型。先用一个已知问题样例把检索层的 Top-10 打印出来肉眼判断片段是否相关。如果片段都无关优先查索引和检索策略如果片段相关但答案错误再去查生成 prompt 和模型选择。这个二分定位法效率最高。5.3 环节级别还是微调先提升 RAG 管线总有人问“是不是应该微调一个领域模型”。我的经验是在 RAG 链路还没调稳之前做模型微调属于奢侈行为。微调解决的是输出风格和领域格式问题不能解决知识缺失。先把检索召回和上下文编排做好如果此时答案质量已经达标再考虑用少量高质量问答对做输出格式微调让模型更贴合业务语气。有个数据点值得记录在一次实际对比中仅靠混合检索与重排序把领域问答的忠实度从 68% 提升到了 81%而仅换更大参数量的底座模型提升只有 3%。这说明大部分收益来自信息供给的准确性而非推理能力的增强。经费有限的情况下优先把 RAG 管线里的数据链路做好投入产出比远高于直接升级模型。根据我的实际操作经验RAG 项目里见效最快、最少走弯路的一件事是第一时间建立评测闭环。不要等系统上线后再靠用户反馈来发现问题离线百条评测样本就能拦住大部分明显 bug。做评测时也别追求自动化到极致先从半人工开始边跑边看检索片段和答案可以积累很多一手感觉。等你能准确说出“这种问题大概会挂在分块上”“这种问题多半是检索权重不对”时这套系统的稳定性就真正立住了。