第一次正经做 RAGRetrieval-Augmented Generation检索增强生成相关的项目是被一个内部知识库问答需求逼上山的。某公司想把几百份产品文档、售后工单和技术规范整理成一个问答机器人把客服那边重复到快麻木的这个报错怎么处理那个字段怎么配问题分流掉。刚开始我想偷懒直接拿通用大模型 API 硬上结果非常惨——模型能把不存在的产品型号编得有模有样甚至给出一段看起来完全合理、但实际不存在的配置命令。后来老老实实把 RAG 链路搭起来才明白一句话RAG 不是把文档塞给模型而是把文档切成可检索的知识片段在回答前先通过检索把最相关的证据找出来再让模型基于证据生成。这篇内容适合两类人一类是刚接触 RAG、想系统理解整套链路离线索引、在线检索、生成拼接、评估闭环的开发者另一类是已经跑通了一个 Demo但发现检索不准、答案有幻觉、上线后效果不稳定的同学。下面我不按教科书顺序讲而是按照真正动手搭建时会遇到的顺序来展开每一步都带上我实测过的参数、踩过的坑和取舍逻辑。1. 为什么偏偏是检索增强大模型知识的边界与 RAG 的破局方式1.1 大模型的知识截止点与私有知识盲区任何一个预训练模型知识上限都固定在其训练数据采集的时间点。训练完成后模型对新产生的政策文档、内部系统变更、某私有平台特有的报错信息一无所知。更麻烦的是越是垂直行业的私有知识越不可能出现在公开语料里。我在那个客服项目里遇到过最典型的情况售后工单里有一种特殊的错误码只在某个内部版本里出现过。模型没有见过这个错误码被问到时就开始合理推测一本正经地编造了一个不存在的故障原因。这不是模型笨而是它的知识库里根本没有这个信息。预训练模型本质上是在做按概率接话没有证据约束时概率上最顺的话就会被生成出来。1.2 幻觉的本质生成过程缺少证据约束很多人觉得幻觉是模型质量不行换个更大的模型就能解决。实际上大模型在编造细节这件事上模型越大编得越流畅越难被察觉。原因在于生成流程是自回归的每一步都在最大化下一个 token 的概率并没有一个机制去校验我当前说出来的内容是否真的有出处。RAG 的破局方式不在生成端硬堵而在生成之前先把答案空间收敛。通过检索把原本无边无际的概率分布约束到与用户问题强相关的几个文档片段上。模型看到的上下文里已经包含了正确信息它再做摘要和重组编造的空间被大幅压缩。我曾经做过一个对比实验同一批问题无检索直接答幻觉率大概是三成接上 RAG 之后在没有针对性调 Prompt 的情况下幻觉率就能降到一成以内。这个差距就是证据在场与证据缺失的差距。1.3 微调与 RAG 的取舍不是二选一而是分工做这个项目时有人问我为什么不直接微调一个模型我把理由整理一下。微调的本质是把知识烘焙进权重里但存在三个硬伤更新成本高文档每天在变每变一次就重新训练一次工程上不可接受。知识容量有限一次微调能稳定注入的知识量级有限塞几百份超长文档进去很容易学到后面忘前面。可解释性差微调后的回答很难追溯用户问你这个结论哪来的你没法给出文档出处。RAG 的优势在于知识外置、按需取用。文档更新只需要重新索引回答时可以明确标注依据哪份文档的哪一节。我后来甚至见过一些项目把两者结合起来RAG 负责提供事实和依据微调负责适配问答风格和输出格式。这是后话但对大多数团队来说第一优先永远是 RAG微调只有在你确实需要改变模型的表达习惯时才值得做。2. 离线索引层的工程化从原始文档到可检索的向量片段RAG 链路里最先要解决的是离线索引问题。你得把一堆乱七八糟的原始文档变成计算机可检索的结构化片段。这一步做不好后面检索再花哨也没用。我见过太多团队把大量精力花在调模型上最后发现根因是文档解析阶段就把信息弄丢了。2.1 文档解析最常见的失败点不在切分而在读不完整原始文档格式五花八门PDF、Word、Markdown、扫描件、PPT。解析阶段核心目标只有一个——把人类可读的内容完整、准确保留成纯文本。最容易踩的坑有三个PDF 的表格和多栏排版普通解析库遇到两栏论文或复杂表格经常把内容按从左到右的物理顺序提取导致表格跨栏错乱、语义断裂。我试过一份产品参数表解析出来之后 A 列和 B 列的内容混在一起检索时每次命中都是错的。页眉页脚污染每个 PDF 都有页眉、页码、公司 Logo 说明文字不清理掉就会混进正文里被当成正经内容编码进向量库检索时噪声极大。扫描件必须接 OCR光学字符识别而且 OCR 识别错误没法完全避免尤其是中文标点和类似字形的字符后面需要在清洗阶段处理。实操建议PDF 优先用基于版面分析的解析工具而不要用简单的文本抽取库。表格解析要单独验证——拿三份真实表格文档肉眼核对解析结果确认单元格内容没有串列。清洗阶段统一去掉页码、页眉、页脚、连续换行和多余空白。对 OCR 文档我建议在清洗后做一次简单的错别字高频词替换比如数字 0 被识别成字母 O 这类。2.2 分块策略块大小直接决定检索精度分块是 RAG 的命门之一。块太大单个片段包含的信息多但噪音也多检索回来命中不够精准而且很费 token块太小单个片段语义不完整检索回来内容碎片化模型无法理解。我一开始用定长字符切分每 512 个字符一块无重叠。实测效果很差一段话可能被从中间切开后半段内容没了上下文有的块正好横跨两个章节语义混杂。后来改成按语义边界递归切分按文档结构层级标题、段落、句子逐级往下切优先保完整语义单元块目标大小设为 400 字符左右然后允许上下浮动。一个具体案例某产品文档里有一段描述当温度超过 85 度时系统自动降频定长切分可能把这句话拦腰截断当温度超过在上一块85 度时自动降频在下一块。按语义切分则会把整句保留在同一块内检索时命中率和上下文完整性明显提升。除了切分方式重叠窗口也很重要。我会在相邻块之间保留 30 到 60 个字符的重叠防止恰好落在边界的语义内容被整体丢弃。伪代码大概是def recursive_chunk(text, max_chunk_size400, overlap50): # 先按标题结构拆再按段落拆最后按句子拆 units split_by_heading_or_paragraph(text) chunks [] buffer for unit in units: if len(buffer) len(unit) max_chunk_size: # 先加入带重叠的块 chunks.append(buffer) buffer take_tail(buffer, overlap) unit else: buffer unit if buffer.strip(): chunks.append(buffer) return chunks分块参数没有绝对标准取决于你文档的类型和检索的粒度。原则是如果答案通常是一句话就能说清楚的块可以略小如果答案是某个流程或方案段块要保证该流程完整。上线前拿真实问题做几轮抽样观察命中的块是否包含答案核心再反推调块大小。2.3 Embedding 选型与向量检索基础分块完成后每个片段要喂给 Embedding 模型变成一个向量。选 Embedding 模型的几个关键考量中文效果有些通用 Embedding 模型在英文上很好中文却一般。要专门看中文语义相似度 benchmarks或者自己构建一个领域小测试集来比。维度与成本向量维度高信息粒度更细但存储和计算成本更高。实际项目里常用维度几百到上千。输入上限Embedding 模型通常有 token 上限分块不能超过这个限制否则会被截断信息缺失。Embedding 出来后需要存进向量数据库。单机跑测试用简单的numpy暴力相似度就能做但数据量一上来必须上向量库。核心索引算法无非两类HNSW分层可导航小世界图和 IVF倒排索引系。HNSW 检索快、召回好但内存占用偏高IVF 更省资源但召回略弱需要合理设定聚类数。实操中有一个被忽略的点相似度度量方式。常见的余弦相似度和内积在向量归一化后是等价的但如果你选的内积模型没有对向量做归一化结果就会偏。我建议统一在归一化之后用余弦相似度并在索引建立时和写入时保持一致避免离线评测和线上效果对不上。另一个点Metadata 过滤。向量检索前先用文档类型、部门、时间范围等元数据做过滤再在剩余集合里做距离计算能大幅减少无关命中和计算开销。比如客服项目里用户问的是售后问题就先过滤掉研发规范类文档这才不会被不相关但有语义重叠的内容干扰。3. 检索层的调优空间混合召回、重排序与查询改写索引建好之后真正的差距开始在检索策略上拉开。一个朴素实现是query 转向量在向量库里找 topK 个相似片段拼进 Prompt。实测很快会发现纯向量检索常常语义沾边但关键词不中尤其面对产品型号、错误码、专有名词时。3.1 混合检索稀疏召回与稠密召回的互补稠密向量检索擅长捕捉语义但有个明显弱点它会把ABC-1000这种型号名和一个语义相近、但完全不是这个型号的句子关联起来因为它理解的是整体语义而不是字面精确匹配。此时需要引入稀疏检索——BM25 这类传统关键词匹配。BM25 对精确词和短语的匹配召回非常强两者互补。工程上常用的融合方式是 RRFReciprocal Rank Fusion倒数排名融合思路很简单对同一个 query分别用稀疏和稠密各取一批结果然后按排名倒数计算融合分把双方的 top 结果按排名交叉合并。def merge_with_rrf(sparse_hits, dense_hits, k60): scores {} for rank, hit in enumerate(sparse_hits): scores[hit.id] scores.get(hit.id, 0) 1 / (k rank) for rank, hit in enumerate(dense_hits): scores[hit.id] scores.get(hit.id, 0) 1 / (k rank) return sorted(scores.items(), keylambda x: x[1], reverseTrue)这个做法的好处是不需要调权重的比例RRF 是归一化的排名指标天然适用两个尺度完全不同的检索器。实测混合检索相比纯向量命中率能提高 10 到 20 个百分点主要增益就来自精确匹配场景。3.2 重排序召回多、精排准两阶段各司其职召回阶段讲究高召回、不可漏检。但召回结果里会有不少看着相关、实则不相关的片段。比如用户问重启后配置丢失怎么办召回结果里可能有一条只是顺带提到重启这个词但核心在讲日志。此时需要重排序模型Reranker做精排。Reranker 用的是交叉编码器结构query 和候选片段一起送入模型直接计算相关程度分数。相比双塔式的 Embedding它的计算量更大但精度更高。工程实现上就是两阶段先召回 30 到 50 个候选再用 Reranker 取 top5 到 top10。实操中效果最明显的调整是把召回 10 个直接喂给模型改成召回 50 个、重排后取 top5。这在一次内部评测中把最终回答的正确率提高了约 8%。原因很朴素候选池更大Reranker 有更多好内容可选而如果候选池只有 10 个即使 Reranker 排得准选择空间也摆在那里。3.3 查询改写与多路召回有个容易被忽略的事实用户的提问方式往往不适合直接检索。典型问题包括指代不明、问题过短、口语化表达。比如用户问那个重启的的问题解决了吗这个 query 里适合检索的主题词只有重启。这时候让大模型把用户问题改写成适合检索的形式或者生成多个子查询多路召回后再合并效果会有明显提升。我实际用过一个简单的流程先判断 query 里是否包含足够多的专有名词如果太少就让一个轻量模型做改写或扩写生成 2 到 3 个检索 query分别检索再进行 RRF 融合。还有一个相关技巧叫 HyDE假设性文档嵌入——先让模型生成一个假设答案再用这个假设答案去检索。这样做在某些场景下有效但要注意如果 LLM 生成的假设答案是错的会把检索带偏不是银弹需要对照测试。综合下来一个可靠检索层配置是第一层BM25 与向量检索并行候选 50 条。第二层RRF 融合保留 top30。第三层Reranker 精排取 top5 到 top8。进入生成前按 rerank 分数降序排列片段。4. 生成层的约束机制Prompt 组装、引用溯源与拒答兜底检索做好了不等于模型会老实回答问题。生成层是 RAG 链路的最后一公里这里的问题通常出在上下文组得对不对和模型是否受到了足够的约束。4.1 Prompt 组装别把所有片段都塞进去一个常见错误是不管三七二十一把召回的所有片段全扔进 Prompt。要知道上下文窗口是有限的预算片段越多无关内容越多模型越容易分心还白白拉高成本。Prompt 组装有几个实操要点只保留高相关片段控制总 token我一般把检索片段的总 token 控制在上下文窗口的 40% 到 50% 左右剩下留给系统提示词、历史对话和模型输出。片段顺序按相关度降序虽然模型是全局注意力但离用户问题越近的地方往往利用率越高。把最强相关的片段放最前面或最后面都比揉在中间好。曾做过对比把最相关片段放在开头回答正确率比随机顺序高出一截。明确标注每个片段的来源文档让模型知道这段来自《XX 操作手册》第 3 章帮助它做交叉参考。系统提示词里说明游戏规则不是直接给规则而是明确你只能依据给出的资料回答资料不足时直接说不知道不要编造。4.2 引用溯源与可解释性客户场景里有个特殊需求模型不能只给一个答案必须说明依据。于是我在每个片段里都保留了文档 ID、标题和原文摘要并在 Prompt 中要求模型在回答中的关键结论后面标注引用编号例如[1]对应第一个检索片段。实施后效果很好一方面模型的回答有据可循幻觉率下降了另一方面用户看到引用后对答案的信任度明显提高。要让引用真实必须明确告诉模型不要编造引用编号只能引用上下文里真实存在的编号。即使模型回答不了问题也不许强行挂一个不存在的引用。4.3 拒答与兜底策略宁可说不知道不要瞎说在内部客服场景里瞎说比说不知道的危害大得多。但模型被问到一个检索不到答案的问题时天生倾向于强行回答。怎么让它学会拒答一个有效手段是相关度阈值。检索片段平均分数低于阈值时直接返回预设的兜底话术比如我暂时没有在该知识库中找到相关答案建议转人工处理。另一个手段是 Prompt 中给模型承认无知的合法性明确写出如果提供的资料中找不到答案请直接回答资料库中没有相关信息不要推测或编造。阈值怎么定不要靠拍脑袋。我在上线前专门构建了一个应拒答问题集和应回答问题集然后扫描不同阈值下两者的通过率找出平衡点。目测经验值归一化分数在 0.55 到 0.65 附近浮动具体取决于你的检索器分布。注意一点这个分布可能会随着文档更新而漂移所以阈值也要定期重校。5. 评估一个 RAG 系统指标设计、失败模式与回归集很多项目前面做了半天却说不清我的 RAG 到底比裸模型强在哪。RAG 评估难就难在它不是一个模型而是一条链路。检索错了生成再好也无用检索对了生成也可能答非所问。所以评估必须拆开来看。5.1 评估链路分段检索质量与生成质量分开测我实践的方案是定一套双层评估指标检索质量看最终采用的重排结果里是否包含能正确回答用户问题的片段以及这些好片段的排名是否靠前。常用指标是 nDCG归一化折损累积增益和 Recallk。生成质量看模型在给定检索片段后是否忠实于片段内容作答没有编造。常用维度是忠实度faithfulness和答案相关性answer relevance。忠实度是幻觉问题的直接度量。实际操作中我会随机抽 50 到 100 条测试 query人工判断生成回答的每一句是否都能从前面对应的检索片段中找到支持。有一条找不到支持就算一次幻觉。测试集不需要很大但必须覆盖不同难度常见问题、模糊问题、跨文档问题、应拒答问题。5.2 失败模式定位问题到底出在哪个环节当系统回答错误时不要急着调参数。先做定位。我通常按下面顺序排查检索环节把最终进入 Prompt 的片段打印出来。如果片段本身就不对是召回没召到还是重排把对的排下去了分别看召回 top50 和重排 top5 的差异。召回没召到问题在分块或 Embedding重排排错了问题在 Reranker。生成环节如果片段正确但答案错了是 Prompt 约束不够还是模型没读懂片段把片段直接扔给模型让它做摘要如果摘要都做不好说明模型对长上下文的利用能力弱可能需要调 Prompt 或减少片段数量。片段冗余如果多个高度相似片段同时进入 Prompt模型容易被带偏需要做片段去重或 MMR最大边际相关性控制多样性。5.3 持续回归把评估做成自动化而不是一次性任务RAG 系统是不断演进的文档会更新用户的提问模式会变化Embedding 或 Reranker 可能被替换。没有回归测试任何一次调整都可能是开盲盒。我在项目中落地了一个轻量回归机制固定一套覆盖各项能力的测试集每次改动换模型、调参数、改分块策略后跑一遍记录检索指标和生成质量指标对比历史结果。这套测试集不需要很大80 到 150 条即可关键是覆盖完整。跑一次可能需要几分钟但换来的是每次改动的效果可感知。用 LLM 自动打分做初筛人工抽检校准性价比很高。6. 生产环境里的 RAG延迟、更新与成本的取舍最后聊上线。实验室里跑通和线上稳定运行之间差了一整层工程思维。6.1 延迟拆解检索作答各占多少RAG 查询的延迟主要由三块构成检索耗时、重排耗时、生成耗时。实际观察到的典型数值以中等规模知识库、通用 GPU/CPU 服务为例环节常见耗时优化空间向量检索HNSW百万级索引20 到 80ms加缓存、换更稳定的索引参数Rerankercross-encoder50 到 150ms减小候选集、用小模型LLM 生成1 到 5 秒控制输出长度、更换更快的服务生成是大头。如果用户体验要求秒级返回可以从这几点挤时间输出长度上限控制答案不是越长越好检索候选缓存高频 query 直接缓存最终 top 片段结果连检索带重排都省了异步预取当检测到用户正在输入时先做一次粗查询但这需要小心处理权限与历史上下文。6.2 索引更新全量重建还是增量追加知识库不是静止的。每周都有新文档、旧文档废除。处理更新有两种思路增量更新新文档切块、Embedding、写入向量库废弃文档按 ID 删除。适合变化频繁的场景。定时全量重建每天凌晨重建一遍索引。适合文档量不大、变化集中的场景实现简单不容易出错。实操建议即便采用增量更新也要定期比如每周做一次全量重建用来清理那些由于文档修订产生的残留脏数据。删除逻辑要谨慎如果一个文档被更新而不是新增老版本的向量块和陈旧的元数据都要同步处理否则会出现新旧版本并存、检索结果自相矛盾的诡异情况。6.3 成本控制token 消耗与重排开销RAG 的成本常常被低估。它不只是 Embedding 那一次费用还包括每次查询时把检索片段喂进大模型的生成成本。为了把成本压到可控认真做重排把候选从 50 条压缩到 top5表面上多花了一次 Reranker 调用实际省掉了大量喂给 LLM 的无效 token。这是一个很容易忽略的杠杆。控制检索片段总长我的经验是按每个片段 200 到 300 token的量级控制每次只取 4 到 6 段总 token 控制在 1500 以内配合系统提示词和对话历史既能保证答案质量又不至于烧钱。缓存高频问答把用户问过且质量高的回答缓存起来命中缓存就不走完整链路。客服场景的重复性问题比例不低缓存收益明显。对简单问题降级如果 query 明显是文档里某句话就能回答可以直接走检索片段摘要强制模型输出短答案节省大量生成时长和费用。我做这个客服问答项目时最深的感触是RAG 不是装好开源组件就能跑出效果的它是一条完整的数据链路。从一个粗糙的向量检索 Prompt起步到把分块策略、混合召回、重排、引用溯源、拒答阈值、自动化评估全部串起来最终上线后的大多数回答质量才真正让人放心。最后分享一个调试技巧给系统加一个调试模式把每次查询的实际检索片段、重排分数、最终 Prompt 都打印出来。这比任何指标都直观能快速定位是没找到、找错了、还是答错了。我也是被连续几轮诡异的回答折磨之后才意识到光看最终输出根本无从下手把链路摊开之后很多问题都变得一目了然。
第一次正经做 RAGRetrieval-Augmented Generation检索增强生成相关的项目是被一个内部知识库问答需求逼上山的。某公司想把几百份产品文档、售后工单和技术规范整理成一个问答机器人把客服那边重复到快麻木的这个报错怎么处理那个字段怎么配问题分流掉。刚开始我想偷懒直接拿通用大模型 API 硬上结果非常惨——模型能把不存在的产品型号编得有模有样甚至给出一段看起来完全合理、但实际不存在的配置命令。后来老老实实把 RAG 链路搭起来才明白一句话RAG 不是把文档塞给模型而是把文档切成可检索的知识片段在回答前先通过检索把最相关的证据找出来再让模型基于证据生成。这篇内容适合两类人一类是刚接触 RAG、想系统理解整套链路离线索引、在线检索、生成拼接、评估闭环的开发者另一类是已经跑通了一个 Demo但发现检索不准、答案有幻觉、上线后效果不稳定的同学。下面我不按教科书顺序讲而是按照真正动手搭建时会遇到的顺序来展开每一步都带上我实测过的参数、踩过的坑和取舍逻辑。1. 为什么偏偏是检索增强大模型知识的边界与 RAG 的破局方式1.1 大模型的知识截止点与私有知识盲区任何一个预训练模型知识上限都固定在其训练数据采集的时间点。训练完成后模型对新产生的政策文档、内部系统变更、某私有平台特有的报错信息一无所知。更麻烦的是越是垂直行业的私有知识越不可能出现在公开语料里。我在那个客服项目里遇到过最典型的情况售后工单里有一种特殊的错误码只在某个内部版本里出现过。模型没有见过这个错误码被问到时就开始合理推测一本正经地编造了一个不存在的故障原因。这不是模型笨而是它的知识库里根本没有这个信息。预训练模型本质上是在做按概率接话没有证据约束时概率上最顺的话就会被生成出来。1.2 幻觉的本质生成过程缺少证据约束很多人觉得幻觉是模型质量不行换个更大的模型就能解决。实际上大模型在编造细节这件事上模型越大编得越流畅越难被察觉。原因在于生成流程是自回归的每一步都在最大化下一个 token 的概率并没有一个机制去校验我当前说出来的内容是否真的有出处。RAG 的破局方式不在生成端硬堵而在生成之前先把答案空间收敛。通过检索把原本无边无际的概率分布约束到与用户问题强相关的几个文档片段上。模型看到的上下文里已经包含了正确信息它再做摘要和重组编造的空间被大幅压缩。我曾经做过一个对比实验同一批问题无检索直接答幻觉率大概是三成接上 RAG 之后在没有针对性调 Prompt 的情况下幻觉率就能降到一成以内。这个差距就是证据在场与证据缺失的差距。1.3 微调与 RAG 的取舍不是二选一而是分工做这个项目时有人问我为什么不直接微调一个模型我把理由整理一下。微调的本质是把知识烘焙进权重里但存在三个硬伤更新成本高文档每天在变每变一次就重新训练一次工程上不可接受。知识容量有限一次微调能稳定注入的知识量级有限塞几百份超长文档进去很容易学到后面忘前面。可解释性差微调后的回答很难追溯用户问你这个结论哪来的你没法给出文档出处。RAG 的优势在于知识外置、按需取用。文档更新只需要重新索引回答时可以明确标注依据哪份文档的哪一节。我后来甚至见过一些项目把两者结合起来RAG 负责提供事实和依据微调负责适配问答风格和输出格式。这是后话但对大多数团队来说第一优先永远是 RAG微调只有在你确实需要改变模型的表达习惯时才值得做。2. 离线索引层的工程化从原始文档到可检索的向量片段RAG 链路里最先要解决的是离线索引问题。你得把一堆乱七八糟的原始文档变成计算机可检索的结构化片段。这一步做不好后面检索再花哨也没用。我见过太多团队把大量精力花在调模型上最后发现根因是文档解析阶段就把信息弄丢了。2.1 文档解析最常见的失败点不在切分而在读不完整原始文档格式五花八门PDF、Word、Markdown、扫描件、PPT。解析阶段核心目标只有一个——把人类可读的内容完整、准确保留成纯文本。最容易踩的坑有三个PDF 的表格和多栏排版普通解析库遇到两栏论文或复杂表格经常把内容按从左到右的物理顺序提取导致表格跨栏错乱、语义断裂。我试过一份产品参数表解析出来之后 A 列和 B 列的内容混在一起检索时每次命中都是错的。页眉页脚污染每个 PDF 都有页眉、页码、公司 Logo 说明文字不清理掉就会混进正文里被当成正经内容编码进向量库检索时噪声极大。扫描件必须接 OCR光学字符识别而且 OCR 识别错误没法完全避免尤其是中文标点和类似字形的字符后面需要在清洗阶段处理。实操建议PDF 优先用基于版面分析的解析工具而不要用简单的文本抽取库。表格解析要单独验证——拿三份真实表格文档肉眼核对解析结果确认单元格内容没有串列。清洗阶段统一去掉页码、页眉、页脚、连续换行和多余空白。对 OCR 文档我建议在清洗后做一次简单的错别字高频词替换比如数字 0 被识别成字母 O 这类。2.2 分块策略块大小直接决定检索精度分块是 RAG 的命门之一。块太大单个片段包含的信息多但噪音也多检索回来命中不够精准而且很费 token块太小单个片段语义不完整检索回来内容碎片化模型无法理解。我一开始用定长字符切分每 512 个字符一块无重叠。实测效果很差一段话可能被从中间切开后半段内容没了上下文有的块正好横跨两个章节语义混杂。后来改成按语义边界递归切分按文档结构层级标题、段落、句子逐级往下切优先保完整语义单元块目标大小设为 400 字符左右然后允许上下浮动。一个具体案例某产品文档里有一段描述当温度超过 85 度时系统自动降频定长切分可能把这句话拦腰截断当温度超过在上一块85 度时自动降频在下一块。按语义切分则会把整句保留在同一块内检索时命中率和上下文完整性明显提升。除了切分方式重叠窗口也很重要。我会在相邻块之间保留 30 到 60 个字符的重叠防止恰好落在边界的语义内容被整体丢弃。伪代码大概是def recursive_chunk(text, max_chunk_size400, overlap50): # 先按标题结构拆再按段落拆最后按句子拆 units split_by_heading_or_paragraph(text) chunks [] buffer for unit in units: if len(buffer) len(unit) max_chunk_size: # 先加入带重叠的块 chunks.append(buffer) buffer take_tail(buffer, overlap) unit else: buffer unit if buffer.strip(): chunks.append(buffer) return chunks分块参数没有绝对标准取决于你文档的类型和检索的粒度。原则是如果答案通常是一句话就能说清楚的块可以略小如果答案是某个流程或方案段块要保证该流程完整。上线前拿真实问题做几轮抽样观察命中的块是否包含答案核心再反推调块大小。2.3 Embedding 选型与向量检索基础分块完成后每个片段要喂给 Embedding 模型变成一个向量。选 Embedding 模型的几个关键考量中文效果有些通用 Embedding 模型在英文上很好中文却一般。要专门看中文语义相似度 benchmarks或者自己构建一个领域小测试集来比。维度与成本向量维度高信息粒度更细但存储和计算成本更高。实际项目里常用维度几百到上千。输入上限Embedding 模型通常有 token 上限分块不能超过这个限制否则会被截断信息缺失。Embedding 出来后需要存进向量数据库。单机跑测试用简单的numpy暴力相似度就能做但数据量一上来必须上向量库。核心索引算法无非两类HNSW分层可导航小世界图和 IVF倒排索引系。HNSW 检索快、召回好但内存占用偏高IVF 更省资源但召回略弱需要合理设定聚类数。实操中有一个被忽略的点相似度度量方式。常见的余弦相似度和内积在向量归一化后是等价的但如果你选的内积模型没有对向量做归一化结果就会偏。我建议统一在归一化之后用余弦相似度并在索引建立时和写入时保持一致避免离线评测和线上效果对不上。另一个点Metadata 过滤。向量检索前先用文档类型、部门、时间范围等元数据做过滤再在剩余集合里做距离计算能大幅减少无关命中和计算开销。比如客服项目里用户问的是售后问题就先过滤掉研发规范类文档这才不会被不相关但有语义重叠的内容干扰。3. 检索层的调优空间混合召回、重排序与查询改写索引建好之后真正的差距开始在检索策略上拉开。一个朴素实现是query 转向量在向量库里找 topK 个相似片段拼进 Prompt。实测很快会发现纯向量检索常常语义沾边但关键词不中尤其面对产品型号、错误码、专有名词时。3.1 混合检索稀疏召回与稠密召回的互补稠密向量检索擅长捕捉语义但有个明显弱点它会把ABC-1000这种型号名和一个语义相近、但完全不是这个型号的句子关联起来因为它理解的是整体语义而不是字面精确匹配。此时需要引入稀疏检索——BM25 这类传统关键词匹配。BM25 对精确词和短语的匹配召回非常强两者互补。工程上常用的融合方式是 RRFReciprocal Rank Fusion倒数排名融合思路很简单对同一个 query分别用稀疏和稠密各取一批结果然后按排名倒数计算融合分把双方的 top 结果按排名交叉合并。def merge_with_rrf(sparse_hits, dense_hits, k60): scores {} for rank, hit in enumerate(sparse_hits): scores[hit.id] scores.get(hit.id, 0) 1 / (k rank) for rank, hit in enumerate(dense_hits): scores[hit.id] scores.get(hit.id, 0) 1 / (k rank) return sorted(scores.items(), keylambda x: x[1], reverseTrue)这个做法的好处是不需要调权重的比例RRF 是归一化的排名指标天然适用两个尺度完全不同的检索器。实测混合检索相比纯向量命中率能提高 10 到 20 个百分点主要增益就来自精确匹配场景。3.2 重排序召回多、精排准两阶段各司其职召回阶段讲究高召回、不可漏检。但召回结果里会有不少看着相关、实则不相关的片段。比如用户问重启后配置丢失怎么办召回结果里可能有一条只是顺带提到重启这个词但核心在讲日志。此时需要重排序模型Reranker做精排。Reranker 用的是交叉编码器结构query 和候选片段一起送入模型直接计算相关程度分数。相比双塔式的 Embedding它的计算量更大但精度更高。工程实现上就是两阶段先召回 30 到 50 个候选再用 Reranker 取 top5 到 top10。实操中效果最明显的调整是把召回 10 个直接喂给模型改成召回 50 个、重排后取 top5。这在一次内部评测中把最终回答的正确率提高了约 8%。原因很朴素候选池更大Reranker 有更多好内容可选而如果候选池只有 10 个即使 Reranker 排得准选择空间也摆在那里。3.3 查询改写与多路召回有个容易被忽略的事实用户的提问方式往往不适合直接检索。典型问题包括指代不明、问题过短、口语化表达。比如用户问那个重启的的问题解决了吗这个 query 里适合检索的主题词只有重启。这时候让大模型把用户问题改写成适合检索的形式或者生成多个子查询多路召回后再合并效果会有明显提升。我实际用过一个简单的流程先判断 query 里是否包含足够多的专有名词如果太少就让一个轻量模型做改写或扩写生成 2 到 3 个检索 query分别检索再进行 RRF 融合。还有一个相关技巧叫 HyDE假设性文档嵌入——先让模型生成一个假设答案再用这个假设答案去检索。这样做在某些场景下有效但要注意如果 LLM 生成的假设答案是错的会把检索带偏不是银弹需要对照测试。综合下来一个可靠检索层配置是第一层BM25 与向量检索并行候选 50 条。第二层RRF 融合保留 top30。第三层Reranker 精排取 top5 到 top8。进入生成前按 rerank 分数降序排列片段。4. 生成层的约束机制Prompt 组装、引用溯源与拒答兜底检索做好了不等于模型会老实回答问题。生成层是 RAG 链路的最后一公里这里的问题通常出在上下文组得对不对和模型是否受到了足够的约束。4.1 Prompt 组装别把所有片段都塞进去一个常见错误是不管三七二十一把召回的所有片段全扔进 Prompt。要知道上下文窗口是有限的预算片段越多无关内容越多模型越容易分心还白白拉高成本。Prompt 组装有几个实操要点只保留高相关片段控制总 token我一般把检索片段的总 token 控制在上下文窗口的 40% 到 50% 左右剩下留给系统提示词、历史对话和模型输出。片段顺序按相关度降序虽然模型是全局注意力但离用户问题越近的地方往往利用率越高。把最强相关的片段放最前面或最后面都比揉在中间好。曾做过对比把最相关片段放在开头回答正确率比随机顺序高出一截。明确标注每个片段的来源文档让模型知道这段来自《XX 操作手册》第 3 章帮助它做交叉参考。系统提示词里说明游戏规则不是直接给规则而是明确你只能依据给出的资料回答资料不足时直接说不知道不要编造。4.2 引用溯源与可解释性客户场景里有个特殊需求模型不能只给一个答案必须说明依据。于是我在每个片段里都保留了文档 ID、标题和原文摘要并在 Prompt 中要求模型在回答中的关键结论后面标注引用编号例如[1]对应第一个检索片段。实施后效果很好一方面模型的回答有据可循幻觉率下降了另一方面用户看到引用后对答案的信任度明显提高。要让引用真实必须明确告诉模型不要编造引用编号只能引用上下文里真实存在的编号。即使模型回答不了问题也不许强行挂一个不存在的引用。4.3 拒答与兜底策略宁可说不知道不要瞎说在内部客服场景里瞎说比说不知道的危害大得多。但模型被问到一个检索不到答案的问题时天生倾向于强行回答。怎么让它学会拒答一个有效手段是相关度阈值。检索片段平均分数低于阈值时直接返回预设的兜底话术比如我暂时没有在该知识库中找到相关答案建议转人工处理。另一个手段是 Prompt 中给模型承认无知的合法性明确写出如果提供的资料中找不到答案请直接回答资料库中没有相关信息不要推测或编造。阈值怎么定不要靠拍脑袋。我在上线前专门构建了一个应拒答问题集和应回答问题集然后扫描不同阈值下两者的通过率找出平衡点。目测经验值归一化分数在 0.55 到 0.65 附近浮动具体取决于你的检索器分布。注意一点这个分布可能会随着文档更新而漂移所以阈值也要定期重校。5. 评估一个 RAG 系统指标设计、失败模式与回归集很多项目前面做了半天却说不清我的 RAG 到底比裸模型强在哪。RAG 评估难就难在它不是一个模型而是一条链路。检索错了生成再好也无用检索对了生成也可能答非所问。所以评估必须拆开来看。5.1 评估链路分段检索质量与生成质量分开测我实践的方案是定一套双层评估指标检索质量看最终采用的重排结果里是否包含能正确回答用户问题的片段以及这些好片段的排名是否靠前。常用指标是 nDCG归一化折损累积增益和 Recallk。生成质量看模型在给定检索片段后是否忠实于片段内容作答没有编造。常用维度是忠实度faithfulness和答案相关性answer relevance。忠实度是幻觉问题的直接度量。实际操作中我会随机抽 50 到 100 条测试 query人工判断生成回答的每一句是否都能从前面对应的检索片段中找到支持。有一条找不到支持就算一次幻觉。测试集不需要很大但必须覆盖不同难度常见问题、模糊问题、跨文档问题、应拒答问题。5.2 失败模式定位问题到底出在哪个环节当系统回答错误时不要急着调参数。先做定位。我通常按下面顺序排查检索环节把最终进入 Prompt 的片段打印出来。如果片段本身就不对是召回没召到还是重排把对的排下去了分别看召回 top50 和重排 top5 的差异。召回没召到问题在分块或 Embedding重排排错了问题在 Reranker。生成环节如果片段正确但答案错了是 Prompt 约束不够还是模型没读懂片段把片段直接扔给模型让它做摘要如果摘要都做不好说明模型对长上下文的利用能力弱可能需要调 Prompt 或减少片段数量。片段冗余如果多个高度相似片段同时进入 Prompt模型容易被带偏需要做片段去重或 MMR最大边际相关性控制多样性。5.3 持续回归把评估做成自动化而不是一次性任务RAG 系统是不断演进的文档会更新用户的提问模式会变化Embedding 或 Reranker 可能被替换。没有回归测试任何一次调整都可能是开盲盒。我在项目中落地了一个轻量回归机制固定一套覆盖各项能力的测试集每次改动换模型、调参数、改分块策略后跑一遍记录检索指标和生成质量指标对比历史结果。这套测试集不需要很大80 到 150 条即可关键是覆盖完整。跑一次可能需要几分钟但换来的是每次改动的效果可感知。用 LLM 自动打分做初筛人工抽检校准性价比很高。6. 生产环境里的 RAG延迟、更新与成本的取舍最后聊上线。实验室里跑通和线上稳定运行之间差了一整层工程思维。6.1 延迟拆解检索作答各占多少RAG 查询的延迟主要由三块构成检索耗时、重排耗时、生成耗时。实际观察到的典型数值以中等规模知识库、通用 GPU/CPU 服务为例环节常见耗时优化空间向量检索HNSW百万级索引20 到 80ms加缓存、换更稳定的索引参数Rerankercross-encoder50 到 150ms减小候选集、用小模型LLM 生成1 到 5 秒控制输出长度、更换更快的服务生成是大头。如果用户体验要求秒级返回可以从这几点挤时间输出长度上限控制答案不是越长越好检索候选缓存高频 query 直接缓存最终 top 片段结果连检索带重排都省了异步预取当检测到用户正在输入时先做一次粗查询但这需要小心处理权限与历史上下文。6.2 索引更新全量重建还是增量追加知识库不是静止的。每周都有新文档、旧文档废除。处理更新有两种思路增量更新新文档切块、Embedding、写入向量库废弃文档按 ID 删除。适合变化频繁的场景。定时全量重建每天凌晨重建一遍索引。适合文档量不大、变化集中的场景实现简单不容易出错。实操建议即便采用增量更新也要定期比如每周做一次全量重建用来清理那些由于文档修订产生的残留脏数据。删除逻辑要谨慎如果一个文档被更新而不是新增老版本的向量块和陈旧的元数据都要同步处理否则会出现新旧版本并存、检索结果自相矛盾的诡异情况。6.3 成本控制token 消耗与重排开销RAG 的成本常常被低估。它不只是 Embedding 那一次费用还包括每次查询时把检索片段喂进大模型的生成成本。为了把成本压到可控认真做重排把候选从 50 条压缩到 top5表面上多花了一次 Reranker 调用实际省掉了大量喂给 LLM 的无效 token。这是一个很容易忽略的杠杆。控制检索片段总长我的经验是按每个片段 200 到 300 token的量级控制每次只取 4 到 6 段总 token 控制在 1500 以内配合系统提示词和对话历史既能保证答案质量又不至于烧钱。缓存高频问答把用户问过且质量高的回答缓存起来命中缓存就不走完整链路。客服场景的重复性问题比例不低缓存收益明显。对简单问题降级如果 query 明显是文档里某句话就能回答可以直接走检索片段摘要强制模型输出短答案节省大量生成时长和费用。我做这个客服问答项目时最深的感触是RAG 不是装好开源组件就能跑出效果的它是一条完整的数据链路。从一个粗糙的向量检索 Prompt起步到把分块策略、混合召回、重排、引用溯源、拒答阈值、自动化评估全部串起来最终上线后的大多数回答质量才真正让人放心。最后分享一个调试技巧给系统加一个调试模式把每次查询的实际检索片段、重排分数、最终 Prompt 都打印出来。这比任何指标都直观能快速定位是没找到、找错了、还是答错了。我也是被连续几轮诡异的回答折磨之后才意识到光看最终输出根本无从下手把链路摊开之后很多问题都变得一目了然。
