1. 从“零散笔记”到“RAG 落地手册”我在 all-in-rag 里记下的那些事先说说这标题是怎么来的。算起来我接触 RAG检索增强生成差不多一年半了从最早拿开源框架跑 demo到后来给团队搭了一套能接生产流量的问答系统中间踩过的坑、翻过的车、想明白的道理全都零零碎碎记在一个叫 all-in-rag 的笔记库里。这个笔记库不是什么成型产品也没有漂亮文档就是我自己持续往里丢东西的地方——今天记录一个检索参数调优的细节明天贴一段线上故障排查的日志后天又补一条对某个新框架的试用感受。时间久了我发现自己翻这些笔记的频率比翻任何官方文档都高。所以这篇文章说白了就是把 all-in-rag 里那些散装经验重新串一遍按“为什么要 RAG、检索怎么做、生成怎么配、系统怎么调、坑怎么避”这条主线整理成一份能直接上手参考的东西。适合谁看两类人一类是刚接触 RAG、正准备搭第一个原型的技术同学你可以把它当路线图知道每一步该关注什么另一类是已经跑通 demo、但总觉得效果不够稳的开发者我记录的很多线上问题复盘和参数踩坑可能正好对应你现在的困惑。我不打算写成一堂理论课更想用记笔记的口吻聊聊我在 all-in-rag 里沉淀下来、并且反复验证过的东西。需要先说明一点这篇文章里提到的所有项目、数据、场景都来自我平时工作里的模拟项目和实验室验证不涉及任何具体业务细节。我会尽量把每个结论背后“为什么这么选”讲清楚而不是直接甩给你一堆配置项。毕竟RAG 这东西参数照抄永远调不出好效果理解它每一步在干什么才是真正能复用的能力。2. 为什么我最终选择了“all-in-rag”这条路2.1 从纯大模型到 RAG一次被现实教育的选型最早的时候我以为只要把大模型的上下文窗口拉长就能解决知识更新和私有数据的问题。于是我用了一个支持超长上下文的模型把几十页产品手册直接塞进 prompt跑出来的效果简直灾难——模型确实“读”到了所有文字但回答的时候它分不清哪些信息是当前问题真正需要的经常抓着一句无关紧要的背景介绍展开长篇大论真正关键的参数反而被漏掉。后来我才想明白一个类比大模型就像一个知识渊博但有点“泛读”的顾问你把整本书丢给他他记住的是整体印象而不是你问他某个具体条款时应该精准定位到的那一页。RAG 的思路完全不同它先把“查资料”和“写答案”拆成两个步骤。查询阶段系统像一个图书管理员根据你的问题去索引里精确找到最相关的几段内容生成阶段再把这几段内容连同问题一起交给大模型让它在限定素材的基础上组织回答。这样做的直接好处是模型不需要记住所有资料它只需要理解当前检索到的这几段文字。幻觉率明显下降答案的可解释性也大幅提升——用户追问“你这个结论是从哪来的”我可以直接给出检索到的原文片段。我之所以把所有相关实践都归到一个叫“all-in-rag”的笔记库就是因为这个方向值得系统性地投入。它不是某个框架的附属功能也不是临时的应急方案而是从数据预处理、向量检索、重排序、prompt 编排到大模型调用、评估反馈的一整条链路。每个环节都有独立的优化空间把它们拆开研究才会真正理解 RAG 的上限在哪里。2.2 RAG 系统的整体链路笔记库里的架构图我在 all-in-rag 里画过一张很朴素的链路图没有用任何 fancy 的工具就是文字加缩进数据接入 → 文档解析 → 分块Chunking→ 向量化Embedding→ 写入向量库 用户查询 → 查询改写 → 向量检索 → 重排序Rerank→ 组装 Prompt → 大模型生成 → 答案引用这张图看起来简单但每个环节都有一堆“魔鬼细节”。我给自己定的笔记规则是任何一个环节出了问题都要回到这张图先定位是“资料没存好”还是“查不出来”还是“生成不对”而不是一上来就调大模型参数。后面几个章节我就按这条链路的顺序把每个环节里记过的实践经验和踩坑记录展开讲。3. 数据接入与预处理RAG 效果的上限其实在这里3.1 文档解析被大多数人低估的第一道坎我见过不少团队兴致勃勃地搭好了检索和生成结果测试时发现答案质量很差查了一圈问题出在最开始——PDF 解析出来全是乱码和错位文本。这个环节太容易被忽视了因为 demo 阶段大家用的都是排版干净的 Markdown 或 TXT一旦换到真实场景里的扫描件、双栏排版 PDF、带页眉页脚的 Word解析质量立刻天差地别。我在 all-in-rag 里记过一条原则解析阶段的目标不是“把文字提取出来”而是“把文档的语义结构保留下来”。举个具体例子一份技术规格书表格里有“工作电压5V”这样的关键信息如果解析时表格结构丢失文本变成一行行散乱的字段后续分块和向量化都会出问题——检索时可能只匹配到“工作电压”这个词却不知道它对应的值是 5V。我实际用的方案是分层处理对 PDF先用开源解析库提取文本和坐标信息再用规则把页眉页脚、页码过滤掉对 Word 和 HTML优先保留标题层级和表格结构遇到扫描件先走 OCR但 OCR 之后一定要做一轮基于关键词的校对因为常见的识别错误比如把“100Ω”识别成“100Q”会直接影响检索命中。这些处理逻辑我都写成了可复用的脚本放在笔记库的preprocess/目录下每次接入新类型文档第一件事就是跑一遍解析质量抽检抽检不合格就直接打回不进入下一步。3.2 分块策略决定检索精度的“切菜刀法”分块是 RAG 里最像“手艺人”的环节。块切大了语义完整但检索粒度太粗一个问题可能命中一大段无关内容稀释掉关键信息块切小了定位精准但语义容易不完整经常出现“答案在上一块结尾”的尴尬。我在 all-in-rag 里做过一组对比实验固定其他条件不变只变换分块大小结果如下分块方式平均命中准确率典型问题固定 512 字符无重叠62%关键信息被切开跨块信息丢失固定 512 字符重叠 64 字符71%重叠区带来少量冗余但整体可用按标题层级动态分块83%语义完整性最好但实现复杂度高按段落 超出阈值再切79%常规场景性价比最高所以我最后的生产配置并不是最复杂的动态分块而是“按段落优先段落过长时按句子边界二次切割每个块控制在 300 到 500 字之间”。这个策略代码好写、效果稳定尤其适合技术文档和问答库这类段落边界清晰的场景。另外必须记录一个新手常踩的坑不要把所有文件都用一个固定分块参数。我在笔记里加了一条规则——先对文档类型做分类FAQ 类用较小的块一个问题配一个答案长文技术手册用较大的块保持章节完整表格类数据则单独走“表格结构保留”的分支。分块策略跟着内容形态走而不是一个参数打天下这是我从大量实验里得出的最深教训。3.3 向量化选型Embedding 模型不是越贵越好Embedding 模型的选择对检索效果的影响是决定性的但“选哪个”并没有标准答案。我在 all-in-rag 里比较过通用中英文模型、开源领域微调模型、商用 API 模型最后得出的结论是先看检索任务的语言和领域再看可部署性和成本。我的选择逻辑是这样的如果知识库以中文技术文档为主我会优先用一个在中文语料上表现好的开源 Embedding 模型因为它对中文长文本的语义理解更稳而且可以本地部署数据不用出内网。如果知识库涉及大量英文论文或跨语言查询通用多语言模型会更合适——虽然单条成本高一些但跨语言检索的准确率提升是实打实的。这里有一个非常容易忽略的细节Embedding 模型是有“输入长度上限”的。我之前踩过一次坑用某个模型时忘记看最大输入长度结果分块超过 512 token 的文本被静默截断检索效果莫名其妙变差。排查了很久才发现是截断导致向量只编码了前半段语义。所以参数配置表里一定得记一条分块最大长度不能只按字数算还要换算成 token 数确保不超过 Embedding 模型的输入上限。4. 检索链路从向量到混合检索再到重排序4.1 向量检索的相似度算法与召回率平衡向量检索的核心是“给你一个问题从向量库里找出最相似的 Top-K 个文本块”。相似度算法最常见的是余弦相似度和内积我在实践中绝大多数场景用余弦相似度因为它对向量模长不敏感更适合 Embedding 模型生成的归一化向量。但只做向量检索召回率一定会遇到瓶颈。我印象最深的一次用户问“设备在低温环境下是否可以正常工作”知识库里相关段落写的是“工作温度范围-20℃ 至 60℃”向量检索确实能召回这段话但排名并不靠前因为问题里的“低温”和文档里的“-20℃”在语义空间里距离较远。如果只取 Top-3这段话很可能被挤出结果集生成阶段就拿不到关键信息。面对这种情况我把检索策略升级成了混合检索向量检索负责语义召回关键词检索BM25负责精确匹配。两者各自召回一批候选再合并去重送进重排序阶段。实测下来混合检索能把“精确术语型”问题的召回率提升 15 到 20 个百分点。这也解释了为什么很多生产级 RAG 系统都不再是“纯向量”架构——纯向量适合语义泛化查询但在专有名词、型号、代码片段这些场景里精确匹配依然不可替代。4.2 重排序Rerank为什么是检索质量的胜负手很多入门资料会把 RAG 简化为“向量检索 大模型生成”但实际上线之后你会发现向量检索出来的 Top-K 里真正与问题强相关的可能只有两三条剩下都是“看着像、实际不相关”的干扰项。如果把这些干扰项直接塞给大模型它很容易被带偏——它不知道哪些内容是可信的只会把所有上下文都当作参考依据。所以我从第一版原型开始就给链路加上了重排序环节。重排序模型的输入是“问题 候选文本”输出是相关度打分本质上是用一个更精细的模型对粗排结果做一次精排。它和向量检索的差异在于向量检索是在一个巨大的库里快速筛出几百条候选重排序是在这几百条里挑出最精准的十条。我在 all-in-rag 里记录了重排序的配置经验候选集数量一般取 50 到 100重排序之后保留 Top-5 给生成阶段。这个数字不是拍脑袋定的——候选太少漏掉相关段落候选太多重排序模型的计算成本成倍上升而且长尾的低相关文本可能引入噪声。我还特地对重排序模型做了领域微调实验用几百条模拟问答对让模型学会“技术文档里什么算相关”。微调之后的效果提升非常明显尤其在“问题包含型号但文档用全称”这类语义匹配场景里重排序模型的判断比通用模型准得多。4.3 查询改写用户不会用检索的语言提问这是我在 all-in-rag 里后补的一个环节最初版链路里压根没有它。后来发现用户实际提问的方式和知识库的表述习惯经常对不上。比如知识库里写的是“如何重置设备”用户却问“我搞坏了设置怎么恢复出厂”这两句话在语义上相关但向量检索的效果取决于 Embedding 模型对口语化表达的泛化能力不一定稳定。查询改写就是解决这个问题的在大模型生成答案之前先用一个轻量模型对用户原始问题进行扩展和改写。改写方向包括把口语转书面语、补充同义词、拆解复合问题、识别并规范化专有名词。我实际使用的一个策略是同时生成原始问题和改写后的多个查询变体分别检索再合并结果这样既不丢失原始查询的原意又能通过改写扩大召回覆盖面。当然查询改写不是无脑加。它增加了一次额外的大模型调用延迟和成本都要考虑。我在生产环境里的做法是加了一个开关对短查询比如少于 10 个字不做改写对长查询或检索结果置信度偏低的查询才触发改写。这样既保证了大部分查询的低延迟又能在疑难问题上提升召回质量。5. 生成阶段Prompt 编排与上下文管理5.1 给大模型的 Prompt不是把检索结果拼进去就行很多人以为生成阶段就是把“问题 检索到的段落”拼接起来发给大模型我在实践中发现这个做法效果很差原因在于大模型分不清哪些段落是可信依据哪些只是沾边的背景信息。它可能引用一段过时文档里的说法完全忽略新文档里的更新条款。我在 all-in-rag 里沉淀的 Prompt 模板核心是明确划分“角色、任务、依据、约束”四个部分。角色设定让模型知道自己是知识库助手不是通用聊天机器人任务说明让它明确要基于提供的上下文回答而不是自由发挥依据部分是检索到的段落每段前面带上序号和来源标识约束部分则明确如果上下文里找不到答案直接说不知道不要编造。这个 Prompt 模板看起来简单但里面的细节都是踩坑踩出来的。比如“依据部分”我一开始把整段文本原样塞进去结果大模型经常被长段落里的冗余信息带偏。后来我改成“每个依据先提炼成一句话摘要再附上原始段落”模型生成的答案明显更聚焦。再比如“来源标识”我在生成结果里要求模型在关键结论后面用方括号标注来源编号这样前端展示引用来源时可以直接对应到检索到的原文位置可解释性大大增强。5.2 控制注入上下文的长度与布局大模型对上下文不同位置的内容敏感程度不一样这一点被很多人忽略了。我在实验中发现把关键依据放在靠近问题的地方而不是放在一大段上下文的最前面模型对它的关注度明显更高。这和人类阅读的注意力模式类似——你给一个人一大段背景资料再在末尾抛出一个问题他往往需要回头去翻资料如果把最相关的几条依据压缩精简后紧贴着问题放回答质量会更稳定。所以我的 Prompt 布局是开头放系统指令紧接着放“当前问题”然后是“重排序后最相关的 Top-3 到 Top-5 条依据”最后才是完整检索上下文。依据部分每条不超过 150 字超长内容先做摘要压缩。这样既保证了模型有足够素材又不会让干扰信息稀释重点。另外上下文长度还直接影响生成延迟。我把注入的总 token 数控制在一个合理范围内根据模型上下文窗口而定一般保留 30% 余量给生成部分超过阈值的检索结果直接丢弃而不是全部塞进 Prompt。这个策略极大地稳定了生成延迟避免了“检索结果多的时候响应突然变慢”的线上抖动问题。5.3 生成参数的调优记录温度、Top-P、重复惩罚大模型的生成参数我在 all-in-rag 里专门建了一个记录页因为在不同的 RAG 场景下参数的最优值真不一样。我的默认配置是温度 0.2、Top-P 0.9用于知识问答。这个配置的意图很明确知识问答要求确定性宁可答案平淡也不要为了“多样”而引入幻觉。温度调高到 0.7 以上时我观察到回答的措辞更丰富但事实性错误率同步上升在需要严谨的技术问题上完全不可接受。重复惩罚我也踩过坑。早期为了让回答更简洁我把重复惩罚调得比较高结果遇到长答案时模型会出现“说到一半突然结束”的情况因为它在生成过程中不断回避重复表达最后把自己逼进了死胡同。后来我把重复惩罚降到一个温和值只在回答确实有明显重复时才起到抑制作用长答案的完整性立刻恢复了。需要特别提醒的是生成参数应该放在所有检索和重排序优化做完之后再调。如果你检索出来的内容本身就不准生成端无论怎么调温度都是治标不治本。正确的调优顺序永远是先让检索准起来再谈生成风格。6. 评估与迭代没有评测体系的 RAG 都是“感觉流”6.1 离线评估集让每一次改动都有据可依RAG 系统最大的问题是“感觉好像变好了”但说不清哪里变好了。我在 early 阶段也犯过这个错误——手工测试几个问题觉得回答还不错就上线结果用户的反馈完全不一样。后来我花了一整周时间从知识库里挑出 100 个代表性的模拟问题组成一个离线评估集。这 100 个问题不是随便选的我按几个维度做了分类短查询和长查询、术语密集型问题、口语化改写问题、跨段落信息组合问题、知识库里没有答案的负例问题。每个问题都标注了期望命中的文档和期望答案的要点。有了这个评估集每次改动后我都能跑一遍完整的离线评测用召回率、命中位置、答案相关度等指标量化对比前后差异。这个评估集至今还在持续更新我每次从线上日志里发现一个“用户问了但回答不好”的新类型问题就会把它补进去。渐渐地评估集越来越能代表真实用户分布评测结果也越来越能预判线上效果。我认为这是所有做 RAG 的人都应该尽早投入的一件事——它可能不产生直观的功能但它让后续所有优化都有方向、有标准。6.2 线上效果追踪与用户反馈闭环离线评估能解决“改动有没有变好”的问题但解决不了“用户实际用起来怎么样”的问题。我在生产环境里给每次问答都加上结构化日志记录用户原始问题、查询改写结果、检索引中了哪些文档、重排序得分、生成答案、用户的点赞/点踩反馈。这些日志让我能在线上复现任何一个坏案例。分析线上日志时我发现了一个很有代表性的问题大量用户问的是“多跳问题”比如“A 型号和 B 型号在户外场景下哪个更合适”。这类问题需要同时命中两个型号各自的技术参数再在生成阶段做对比。如果知识库里两个型号的参数分散在不同文档里单路检索很容易只召回其中一个文档的片段。解决这个问题我用了两种方式一是查询改写阶段主动识别“对比类问题”将其拆解为两个独立查询分别检索二是在重排序阶段加入“对比相关性”的判断逻辑。这些改动如果没有线上日志支撑几乎不可能定位到问题根因。所以我给所有 RAG 项目的一条建议是从第一天就埋日志日志字段宁可多不可少。有了完整的链路日志排查问题就是从“猜”变成“看现场”效率完全不是一个量级。7. 常见问题与排查技巧实录7.1 检索召回不到相关文档怎么查这是 RAG 上线后最常遇到的问题。我在 all-in-rag 里的排查顺序是固定的先看检索到的原始结果里目标文档到底有没有出现。如果没出现说明是“召回漏了”原因通常集中在三个方面Embedding 模型对当前查询的语义理解不足、分块方式导致目标文本的向量被稀释、关键词检索的词典里缺少专有名词。如果目标文档出现了但排名靠后说明是“排序问题”需要检查重排序模型的判断逻辑或者调节候选集大小。排查时我强烈建议把每一步的中间结果可视化出来。我写了一个很简单的调试脚本输入一条查询输出每个阶段的 Top-N 文档及打分。看到打分变化就能判断是哪个环节把相关文档排下去了。这个排查方式比直接改参数试错高效得多。7.2 生成答案有幻觉是检索的问题还是模型的问题幻觉是 RAG 绕不开的话题。我的经验是大部分幻觉的根源不是大模型“太能编”而是检索内容里混入了不相关或错误的段落。你给一个诚实的人一份错误资料他也会基于资料说出错误结论这是可以理解的。所以排查幻觉我第一步做的永远是“看生成答案引用的那几条依据到底靠不靠谱”。如果依据本身是对的但模型还是编了不在依据里的内容那才是 Prompt 约束或模型能力的问题。这时候我会做两件事一是强化 Prompt 里的“不基于依据不回答”约束并明确惩罚性指令二是尝试把生成温度进一步降低。如果依据本身就错了那就回到检索链路去解决而不是在生成端打补丁。7.3 一个可复用的 RAG 调试速查表我把日常排查看成一张速查表放在 all-in-rag 的开头位置每次遇到问题先查表再动手改。现象优先排查方向常用手段检索返回结果与问题无关Embedding 模型、分块策略更换/微调 Embedding 模型、调整分块大小相关文档命中但排名靠后重排序逻辑、候选集大小调大候选集、优化重排序模型答案存在信息缺失检索 Top-K 数量、上下文布局扩大 Top-K、把关键依据前置答案存在幻觉依据准确性、Prompt 约束、温度检查依据来源、强化约束、降低温度跨文档问题回答不完整查询改写、多路检索拆分多跳问题、多路并行检索生成结果长度不稳定生成参数、重复惩罚调节重复惩罚、设置长度上限这张表不能直接解决所有问题但它把排查思路固化成了一种肌肉记忆让我面对新问题时不会乱了阵脚。8. 后续想在这条路上继续做的事all-in-rag 这个笔记库到现在还在更新最近我在探索两个方向。一个是评估自动化把离线评估集和线上日志打通做成一个半自动的回归测试系统每次改动一键跑完直接输出效果对比报告。另一个是查询理解的深化比如识别用户提问背后的意图类型是“事实查询”“对比查询”还是“操作指导查询”不同意图走不同的检索和 Prompt 策略。说到底RAG 不是一个“调好参数就一劳永逸”的系统它更像一个需要持续喂养和维护的知识服务。我所有经验的核心只有一句话理解每个环节在做什么用数据而不是感觉来驱动决策。这条经验大概就是 all-in-rag 这个笔记库存在的最大意义。
1. 从“零散笔记”到“RAG 落地手册”我在 all-in-rag 里记下的那些事先说说这标题是怎么来的。算起来我接触 RAG检索增强生成差不多一年半了从最早拿开源框架跑 demo到后来给团队搭了一套能接生产流量的问答系统中间踩过的坑、翻过的车、想明白的道理全都零零碎碎记在一个叫 all-in-rag 的笔记库里。这个笔记库不是什么成型产品也没有漂亮文档就是我自己持续往里丢东西的地方——今天记录一个检索参数调优的细节明天贴一段线上故障排查的日志后天又补一条对某个新框架的试用感受。时间久了我发现自己翻这些笔记的频率比翻任何官方文档都高。所以这篇文章说白了就是把 all-in-rag 里那些散装经验重新串一遍按“为什么要 RAG、检索怎么做、生成怎么配、系统怎么调、坑怎么避”这条主线整理成一份能直接上手参考的东西。适合谁看两类人一类是刚接触 RAG、正准备搭第一个原型的技术同学你可以把它当路线图知道每一步该关注什么另一类是已经跑通 demo、但总觉得效果不够稳的开发者我记录的很多线上问题复盘和参数踩坑可能正好对应你现在的困惑。我不打算写成一堂理论课更想用记笔记的口吻聊聊我在 all-in-rag 里沉淀下来、并且反复验证过的东西。需要先说明一点这篇文章里提到的所有项目、数据、场景都来自我平时工作里的模拟项目和实验室验证不涉及任何具体业务细节。我会尽量把每个结论背后“为什么这么选”讲清楚而不是直接甩给你一堆配置项。毕竟RAG 这东西参数照抄永远调不出好效果理解它每一步在干什么才是真正能复用的能力。2. 为什么我最终选择了“all-in-rag”这条路2.1 从纯大模型到 RAG一次被现实教育的选型最早的时候我以为只要把大模型的上下文窗口拉长就能解决知识更新和私有数据的问题。于是我用了一个支持超长上下文的模型把几十页产品手册直接塞进 prompt跑出来的效果简直灾难——模型确实“读”到了所有文字但回答的时候它分不清哪些信息是当前问题真正需要的经常抓着一句无关紧要的背景介绍展开长篇大论真正关键的参数反而被漏掉。后来我才想明白一个类比大模型就像一个知识渊博但有点“泛读”的顾问你把整本书丢给他他记住的是整体印象而不是你问他某个具体条款时应该精准定位到的那一页。RAG 的思路完全不同它先把“查资料”和“写答案”拆成两个步骤。查询阶段系统像一个图书管理员根据你的问题去索引里精确找到最相关的几段内容生成阶段再把这几段内容连同问题一起交给大模型让它在限定素材的基础上组织回答。这样做的直接好处是模型不需要记住所有资料它只需要理解当前检索到的这几段文字。幻觉率明显下降答案的可解释性也大幅提升——用户追问“你这个结论是从哪来的”我可以直接给出检索到的原文片段。我之所以把所有相关实践都归到一个叫“all-in-rag”的笔记库就是因为这个方向值得系统性地投入。它不是某个框架的附属功能也不是临时的应急方案而是从数据预处理、向量检索、重排序、prompt 编排到大模型调用、评估反馈的一整条链路。每个环节都有独立的优化空间把它们拆开研究才会真正理解 RAG 的上限在哪里。2.2 RAG 系统的整体链路笔记库里的架构图我在 all-in-rag 里画过一张很朴素的链路图没有用任何 fancy 的工具就是文字加缩进数据接入 → 文档解析 → 分块Chunking→ 向量化Embedding→ 写入向量库 用户查询 → 查询改写 → 向量检索 → 重排序Rerank→ 组装 Prompt → 大模型生成 → 答案引用这张图看起来简单但每个环节都有一堆“魔鬼细节”。我给自己定的笔记规则是任何一个环节出了问题都要回到这张图先定位是“资料没存好”还是“查不出来”还是“生成不对”而不是一上来就调大模型参数。后面几个章节我就按这条链路的顺序把每个环节里记过的实践经验和踩坑记录展开讲。3. 数据接入与预处理RAG 效果的上限其实在这里3.1 文档解析被大多数人低估的第一道坎我见过不少团队兴致勃勃地搭好了检索和生成结果测试时发现答案质量很差查了一圈问题出在最开始——PDF 解析出来全是乱码和错位文本。这个环节太容易被忽视了因为 demo 阶段大家用的都是排版干净的 Markdown 或 TXT一旦换到真实场景里的扫描件、双栏排版 PDF、带页眉页脚的 Word解析质量立刻天差地别。我在 all-in-rag 里记过一条原则解析阶段的目标不是“把文字提取出来”而是“把文档的语义结构保留下来”。举个具体例子一份技术规格书表格里有“工作电压5V”这样的关键信息如果解析时表格结构丢失文本变成一行行散乱的字段后续分块和向量化都会出问题——检索时可能只匹配到“工作电压”这个词却不知道它对应的值是 5V。我实际用的方案是分层处理对 PDF先用开源解析库提取文本和坐标信息再用规则把页眉页脚、页码过滤掉对 Word 和 HTML优先保留标题层级和表格结构遇到扫描件先走 OCR但 OCR 之后一定要做一轮基于关键词的校对因为常见的识别错误比如把“100Ω”识别成“100Q”会直接影响检索命中。这些处理逻辑我都写成了可复用的脚本放在笔记库的preprocess/目录下每次接入新类型文档第一件事就是跑一遍解析质量抽检抽检不合格就直接打回不进入下一步。3.2 分块策略决定检索精度的“切菜刀法”分块是 RAG 里最像“手艺人”的环节。块切大了语义完整但检索粒度太粗一个问题可能命中一大段无关内容稀释掉关键信息块切小了定位精准但语义容易不完整经常出现“答案在上一块结尾”的尴尬。我在 all-in-rag 里做过一组对比实验固定其他条件不变只变换分块大小结果如下分块方式平均命中准确率典型问题固定 512 字符无重叠62%关键信息被切开跨块信息丢失固定 512 字符重叠 64 字符71%重叠区带来少量冗余但整体可用按标题层级动态分块83%语义完整性最好但实现复杂度高按段落 超出阈值再切79%常规场景性价比最高所以我最后的生产配置并不是最复杂的动态分块而是“按段落优先段落过长时按句子边界二次切割每个块控制在 300 到 500 字之间”。这个策略代码好写、效果稳定尤其适合技术文档和问答库这类段落边界清晰的场景。另外必须记录一个新手常踩的坑不要把所有文件都用一个固定分块参数。我在笔记里加了一条规则——先对文档类型做分类FAQ 类用较小的块一个问题配一个答案长文技术手册用较大的块保持章节完整表格类数据则单独走“表格结构保留”的分支。分块策略跟着内容形态走而不是一个参数打天下这是我从大量实验里得出的最深教训。3.3 向量化选型Embedding 模型不是越贵越好Embedding 模型的选择对检索效果的影响是决定性的但“选哪个”并没有标准答案。我在 all-in-rag 里比较过通用中英文模型、开源领域微调模型、商用 API 模型最后得出的结论是先看检索任务的语言和领域再看可部署性和成本。我的选择逻辑是这样的如果知识库以中文技术文档为主我会优先用一个在中文语料上表现好的开源 Embedding 模型因为它对中文长文本的语义理解更稳而且可以本地部署数据不用出内网。如果知识库涉及大量英文论文或跨语言查询通用多语言模型会更合适——虽然单条成本高一些但跨语言检索的准确率提升是实打实的。这里有一个非常容易忽略的细节Embedding 模型是有“输入长度上限”的。我之前踩过一次坑用某个模型时忘记看最大输入长度结果分块超过 512 token 的文本被静默截断检索效果莫名其妙变差。排查了很久才发现是截断导致向量只编码了前半段语义。所以参数配置表里一定得记一条分块最大长度不能只按字数算还要换算成 token 数确保不超过 Embedding 模型的输入上限。4. 检索链路从向量到混合检索再到重排序4.1 向量检索的相似度算法与召回率平衡向量检索的核心是“给你一个问题从向量库里找出最相似的 Top-K 个文本块”。相似度算法最常见的是余弦相似度和内积我在实践中绝大多数场景用余弦相似度因为它对向量模长不敏感更适合 Embedding 模型生成的归一化向量。但只做向量检索召回率一定会遇到瓶颈。我印象最深的一次用户问“设备在低温环境下是否可以正常工作”知识库里相关段落写的是“工作温度范围-20℃ 至 60℃”向量检索确实能召回这段话但排名并不靠前因为问题里的“低温”和文档里的“-20℃”在语义空间里距离较远。如果只取 Top-3这段话很可能被挤出结果集生成阶段就拿不到关键信息。面对这种情况我把检索策略升级成了混合检索向量检索负责语义召回关键词检索BM25负责精确匹配。两者各自召回一批候选再合并去重送进重排序阶段。实测下来混合检索能把“精确术语型”问题的召回率提升 15 到 20 个百分点。这也解释了为什么很多生产级 RAG 系统都不再是“纯向量”架构——纯向量适合语义泛化查询但在专有名词、型号、代码片段这些场景里精确匹配依然不可替代。4.2 重排序Rerank为什么是检索质量的胜负手很多入门资料会把 RAG 简化为“向量检索 大模型生成”但实际上线之后你会发现向量检索出来的 Top-K 里真正与问题强相关的可能只有两三条剩下都是“看着像、实际不相关”的干扰项。如果把这些干扰项直接塞给大模型它很容易被带偏——它不知道哪些内容是可信的只会把所有上下文都当作参考依据。所以我从第一版原型开始就给链路加上了重排序环节。重排序模型的输入是“问题 候选文本”输出是相关度打分本质上是用一个更精细的模型对粗排结果做一次精排。它和向量检索的差异在于向量检索是在一个巨大的库里快速筛出几百条候选重排序是在这几百条里挑出最精准的十条。我在 all-in-rag 里记录了重排序的配置经验候选集数量一般取 50 到 100重排序之后保留 Top-5 给生成阶段。这个数字不是拍脑袋定的——候选太少漏掉相关段落候选太多重排序模型的计算成本成倍上升而且长尾的低相关文本可能引入噪声。我还特地对重排序模型做了领域微调实验用几百条模拟问答对让模型学会“技术文档里什么算相关”。微调之后的效果提升非常明显尤其在“问题包含型号但文档用全称”这类语义匹配场景里重排序模型的判断比通用模型准得多。4.3 查询改写用户不会用检索的语言提问这是我在 all-in-rag 里后补的一个环节最初版链路里压根没有它。后来发现用户实际提问的方式和知识库的表述习惯经常对不上。比如知识库里写的是“如何重置设备”用户却问“我搞坏了设置怎么恢复出厂”这两句话在语义上相关但向量检索的效果取决于 Embedding 模型对口语化表达的泛化能力不一定稳定。查询改写就是解决这个问题的在大模型生成答案之前先用一个轻量模型对用户原始问题进行扩展和改写。改写方向包括把口语转书面语、补充同义词、拆解复合问题、识别并规范化专有名词。我实际使用的一个策略是同时生成原始问题和改写后的多个查询变体分别检索再合并结果这样既不丢失原始查询的原意又能通过改写扩大召回覆盖面。当然查询改写不是无脑加。它增加了一次额外的大模型调用延迟和成本都要考虑。我在生产环境里的做法是加了一个开关对短查询比如少于 10 个字不做改写对长查询或检索结果置信度偏低的查询才触发改写。这样既保证了大部分查询的低延迟又能在疑难问题上提升召回质量。5. 生成阶段Prompt 编排与上下文管理5.1 给大模型的 Prompt不是把检索结果拼进去就行很多人以为生成阶段就是把“问题 检索到的段落”拼接起来发给大模型我在实践中发现这个做法效果很差原因在于大模型分不清哪些段落是可信依据哪些只是沾边的背景信息。它可能引用一段过时文档里的说法完全忽略新文档里的更新条款。我在 all-in-rag 里沉淀的 Prompt 模板核心是明确划分“角色、任务、依据、约束”四个部分。角色设定让模型知道自己是知识库助手不是通用聊天机器人任务说明让它明确要基于提供的上下文回答而不是自由发挥依据部分是检索到的段落每段前面带上序号和来源标识约束部分则明确如果上下文里找不到答案直接说不知道不要编造。这个 Prompt 模板看起来简单但里面的细节都是踩坑踩出来的。比如“依据部分”我一开始把整段文本原样塞进去结果大模型经常被长段落里的冗余信息带偏。后来我改成“每个依据先提炼成一句话摘要再附上原始段落”模型生成的答案明显更聚焦。再比如“来源标识”我在生成结果里要求模型在关键结论后面用方括号标注来源编号这样前端展示引用来源时可以直接对应到检索到的原文位置可解释性大大增强。5.2 控制注入上下文的长度与布局大模型对上下文不同位置的内容敏感程度不一样这一点被很多人忽略了。我在实验中发现把关键依据放在靠近问题的地方而不是放在一大段上下文的最前面模型对它的关注度明显更高。这和人类阅读的注意力模式类似——你给一个人一大段背景资料再在末尾抛出一个问题他往往需要回头去翻资料如果把最相关的几条依据压缩精简后紧贴着问题放回答质量会更稳定。所以我的 Prompt 布局是开头放系统指令紧接着放“当前问题”然后是“重排序后最相关的 Top-3 到 Top-5 条依据”最后才是完整检索上下文。依据部分每条不超过 150 字超长内容先做摘要压缩。这样既保证了模型有足够素材又不会让干扰信息稀释重点。另外上下文长度还直接影响生成延迟。我把注入的总 token 数控制在一个合理范围内根据模型上下文窗口而定一般保留 30% 余量给生成部分超过阈值的检索结果直接丢弃而不是全部塞进 Prompt。这个策略极大地稳定了生成延迟避免了“检索结果多的时候响应突然变慢”的线上抖动问题。5.3 生成参数的调优记录温度、Top-P、重复惩罚大模型的生成参数我在 all-in-rag 里专门建了一个记录页因为在不同的 RAG 场景下参数的最优值真不一样。我的默认配置是温度 0.2、Top-P 0.9用于知识问答。这个配置的意图很明确知识问答要求确定性宁可答案平淡也不要为了“多样”而引入幻觉。温度调高到 0.7 以上时我观察到回答的措辞更丰富但事实性错误率同步上升在需要严谨的技术问题上完全不可接受。重复惩罚我也踩过坑。早期为了让回答更简洁我把重复惩罚调得比较高结果遇到长答案时模型会出现“说到一半突然结束”的情况因为它在生成过程中不断回避重复表达最后把自己逼进了死胡同。后来我把重复惩罚降到一个温和值只在回答确实有明显重复时才起到抑制作用长答案的完整性立刻恢复了。需要特别提醒的是生成参数应该放在所有检索和重排序优化做完之后再调。如果你检索出来的内容本身就不准生成端无论怎么调温度都是治标不治本。正确的调优顺序永远是先让检索准起来再谈生成风格。6. 评估与迭代没有评测体系的 RAG 都是“感觉流”6.1 离线评估集让每一次改动都有据可依RAG 系统最大的问题是“感觉好像变好了”但说不清哪里变好了。我在 early 阶段也犯过这个错误——手工测试几个问题觉得回答还不错就上线结果用户的反馈完全不一样。后来我花了一整周时间从知识库里挑出 100 个代表性的模拟问题组成一个离线评估集。这 100 个问题不是随便选的我按几个维度做了分类短查询和长查询、术语密集型问题、口语化改写问题、跨段落信息组合问题、知识库里没有答案的负例问题。每个问题都标注了期望命中的文档和期望答案的要点。有了这个评估集每次改动后我都能跑一遍完整的离线评测用召回率、命中位置、答案相关度等指标量化对比前后差异。这个评估集至今还在持续更新我每次从线上日志里发现一个“用户问了但回答不好”的新类型问题就会把它补进去。渐渐地评估集越来越能代表真实用户分布评测结果也越来越能预判线上效果。我认为这是所有做 RAG 的人都应该尽早投入的一件事——它可能不产生直观的功能但它让后续所有优化都有方向、有标准。6.2 线上效果追踪与用户反馈闭环离线评估能解决“改动有没有变好”的问题但解决不了“用户实际用起来怎么样”的问题。我在生产环境里给每次问答都加上结构化日志记录用户原始问题、查询改写结果、检索引中了哪些文档、重排序得分、生成答案、用户的点赞/点踩反馈。这些日志让我能在线上复现任何一个坏案例。分析线上日志时我发现了一个很有代表性的问题大量用户问的是“多跳问题”比如“A 型号和 B 型号在户外场景下哪个更合适”。这类问题需要同时命中两个型号各自的技术参数再在生成阶段做对比。如果知识库里两个型号的参数分散在不同文档里单路检索很容易只召回其中一个文档的片段。解决这个问题我用了两种方式一是查询改写阶段主动识别“对比类问题”将其拆解为两个独立查询分别检索二是在重排序阶段加入“对比相关性”的判断逻辑。这些改动如果没有线上日志支撑几乎不可能定位到问题根因。所以我给所有 RAG 项目的一条建议是从第一天就埋日志日志字段宁可多不可少。有了完整的链路日志排查问题就是从“猜”变成“看现场”效率完全不是一个量级。7. 常见问题与排查技巧实录7.1 检索召回不到相关文档怎么查这是 RAG 上线后最常遇到的问题。我在 all-in-rag 里的排查顺序是固定的先看检索到的原始结果里目标文档到底有没有出现。如果没出现说明是“召回漏了”原因通常集中在三个方面Embedding 模型对当前查询的语义理解不足、分块方式导致目标文本的向量被稀释、关键词检索的词典里缺少专有名词。如果目标文档出现了但排名靠后说明是“排序问题”需要检查重排序模型的判断逻辑或者调节候选集大小。排查时我强烈建议把每一步的中间结果可视化出来。我写了一个很简单的调试脚本输入一条查询输出每个阶段的 Top-N 文档及打分。看到打分变化就能判断是哪个环节把相关文档排下去了。这个排查方式比直接改参数试错高效得多。7.2 生成答案有幻觉是检索的问题还是模型的问题幻觉是 RAG 绕不开的话题。我的经验是大部分幻觉的根源不是大模型“太能编”而是检索内容里混入了不相关或错误的段落。你给一个诚实的人一份错误资料他也会基于资料说出错误结论这是可以理解的。所以排查幻觉我第一步做的永远是“看生成答案引用的那几条依据到底靠不靠谱”。如果依据本身是对的但模型还是编了不在依据里的内容那才是 Prompt 约束或模型能力的问题。这时候我会做两件事一是强化 Prompt 里的“不基于依据不回答”约束并明确惩罚性指令二是尝试把生成温度进一步降低。如果依据本身就错了那就回到检索链路去解决而不是在生成端打补丁。7.3 一个可复用的 RAG 调试速查表我把日常排查看成一张速查表放在 all-in-rag 的开头位置每次遇到问题先查表再动手改。现象优先排查方向常用手段检索返回结果与问题无关Embedding 模型、分块策略更换/微调 Embedding 模型、调整分块大小相关文档命中但排名靠后重排序逻辑、候选集大小调大候选集、优化重排序模型答案存在信息缺失检索 Top-K 数量、上下文布局扩大 Top-K、把关键依据前置答案存在幻觉依据准确性、Prompt 约束、温度检查依据来源、强化约束、降低温度跨文档问题回答不完整查询改写、多路检索拆分多跳问题、多路并行检索生成结果长度不稳定生成参数、重复惩罚调节重复惩罚、设置长度上限这张表不能直接解决所有问题但它把排查思路固化成了一种肌肉记忆让我面对新问题时不会乱了阵脚。8. 后续想在这条路上继续做的事all-in-rag 这个笔记库到现在还在更新最近我在探索两个方向。一个是评估自动化把离线评估集和线上日志打通做成一个半自动的回归测试系统每次改动一键跑完直接输出效果对比报告。另一个是查询理解的深化比如识别用户提问背后的意图类型是“事实查询”“对比查询”还是“操作指导查询”不同意图走不同的检索和 Prompt 策略。说到底RAG 不是一个“调好参数就一劳永逸”的系统它更像一个需要持续喂养和维护的知识服务。我所有经验的核心只有一句话理解每个环节在做什么用数据而不是感觉来驱动决策。这条经验大概就是 all-in-rag 这个笔记库存在的最大意义。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
