看到标题里的 “Complete Guide part1” 时我第一反应不是“这门课讲什么”而是“为什么现在 AI、LLM、GenAI 和 RAG 这四个词能凑到同一门课里并且还要分成 part1、part2 来讲”。如果你已经在用 LangChain、Dify 或手写过 RAG 流程大概率也遇到过类似困惑教程里每一步都跑通了合在一起就是不稳定检索结果看着相关模型回答却完全跑偏明明加了知识库模型还是答非所问。这不是某个工具的问题而是 RAG 从一开始就不是“一个库”“一个脚本”能解决的它是一套完整系统。而这套系统最难的恰恰不是生成是检索、组装、评估和迭代。这篇不是课程导读也不是功能介绍。我想从 RAG 工程化的角度拆一拆为什么这类内容值得系统学一遍、真正的学习分水岭在哪里以及从 demo 到可用之间你到底缺了哪些环节。1. 为什么 RAG 不是“一个库”而是一套需要调优的系统1.1 先分清RAG 真正解决的不是检索而是可控生成很多人理解 RAG第一反应是“给 LLM 加一个知识库”让模型回答私有数据、最新数据。这个理解没有错但它把 RAG 的价值说小了。RAG 真正解决的是“生成的可控性”问题。大模型在训练时被“固化”了一部分知识这些知识有截止时间、有覆盖范围、也有胡说八道的可能。RAG 的思路是不在模型内部硬塞知识而是在回答的当下先从外部检索到相关内容再把检索结果拼进提示词让模型基于给定材料作答。这意味着两件事模型可以不用“记住”你的私有知识它只需要“读懂”你给它的片段。回答的依据是可替换、可追溯、可更新的而不是埋在权重里不可解释。所以如果你只是把 PDF 切开、塞进向量库、然后等模型回答那你只做了 RAG 的表层。真正的 RAG 工程是把“检索-组装-生成-检验”这整条链路变成一套可以被度量、被调整、被迭代的系统。这门课程把 RAG 放在“AI LLM Engineering Mastery”的框架里而不是单独讲一个“文档问答工具”背后其实就是这个逻辑。1.2 为什么很多人停留在“demo 能跑”阶段我见过不少开发者环境装好、代码跑通、示例问答能返回结果然后就没有然后了。原因不是懒而是 demo 和真实系统之间隔着四道墙数据墙示例文档是干净的真实文档是扫描件、多栏排版、表格、图片混合体。检索墙示例 query 是和文档强相关的真实 query 是口语化、模糊、带错别字的。判断墙示例只看最终回答真实系统要判断“到底有没有答对”“依据是否充分”。迭代墙示例改一次就完了真实系统每天都要面对新文档、新问题、新失败案例。课程能讲完的永远是通用方法和典型链路。真正拉开差距的是你有没有能力把上面四道墙逐个拆掉。而拆掉的前提是你完整理解 RAG 内部每一层在干什么。2. 把 RAG 拆成七层你才知道问题出在哪如果一个 RAG 系统表现不好最忌讳的是整条链路一起调整。正确做法是先定位问题出在输入解析、分块策略、embedding、检索、重排、上下文组装还是生成环节为了做定位我建议把 RAG 拆成七个层面来理解。2.1 从文档解析到分块输入质量决定结果上限绝大多数 RAG 失效问题不在模型而在“喂进去的东西”。文档解析不是“把 PDF 变成文本”这么简单。PDF 里的多栏排版、页眉页脚、表格、图片说明、脚注都会污染切分结果。你切出来的文本块可能包含半个句子、两个不相关内容、或者把一个完整概念从中间切断。这些噪声对向量检索的影响是致命的因为 embedding 模型关注的是语义不是版面。分块策略同样关键。分块太小语义不完整分块太大向量表示被平均化检索精度下降。这里没有标准答案但有几个通用判断顺序先保证块内语义完整再考虑长度。优先按标题、段落、表格边界来切而不是固定字符数。相邻块之间要保留重叠防止概念被切开。如果是代码、表格、合同条款这类结构化内容要用对应解析器不能一刀切。更实际的做法是先准备 20 到 50 条真实问答再用这些问答去检验切分结果。如果答案信息分散在多个块里就说明切分粒度或重叠策略需要调整。这一步不做好后面所有环节都在补救。2.2 向量化与检索相似度不是唯一标准embedding 模型决定了文本在向量空间里的“位置”。同一个 query用不同的 embedding 模型检索结果差异可能非常大。选型时不能只看公开榜单分数还要看你的文本领域和语言。比如你的知识库是中文技术文档、法律合同、还是英文论文适合的模型不一样。不同模型的上下文长度、维度、对长文本的压缩方式也不同。这里给一个选型检查顺序先拿 10 条你领域内的 query 做测试。对比召回结果里有多少条是真正有用的。判断模型对同义词、口语化表达、缩写是否敏感。如果检索质量不行优先换 embedding 模型而不是调相似度阈值。检索阶段同样不能只看向量相似度。精确匹配、BM25 关键词检索、混合检索hybrid search在很多时候比纯向量检索更可靠尤其是当 query 包含型号、编号、人名、日期这些“必须精确命中”的信息时。常见的做法是向量检索负责语义召回关键词检索负责精确召回然后用重排模型reranker把两组结果合并排序。重排环节非常容易被忽视。向量检索返回 Top K 后K 个结果里可能只有 2 个真正相关。重排模型的职责就是把这 2 个往前放。很多场景里加一个 reranker 比换 embedding 模型带来的提升更明显。2.3 上下文组装和生成prompt 工程在这条链路里的真实位置检索完之后怎么把检索结果拼进 prompt直接决定生成质量。常见错误有两种把全部检索结果一股脑塞进 prompt导致模型被无关内容干扰。没有告诉模型“只用给定材料回答材料里没有就直说”。更合理的组装方式是把检索结果按相关度排序只保留最相关的几段并明确标注每段内容的来源。Prompt 里要写清楚三件事系统角色、可用材料、回答规则。回答规则至少包括“仅基于材料回答”“材料不足时明确说不知道”“不要编造来源”。这里还想纠正一个观念prompt 工程不是独立的魔法它是 RAG 链路里的一个环节。只有当检索结果足够好时prompt 才能发挥真正作用。检索返回一堆噪声写再多提示词也救不回来。反过来检索结果很好但 prompt 没有约束模型只基于材料作答模型还是会自由发挥。两个环节要一起调。3. 用指标而不是体感来判断 RAG 好不好3.1 检索质量指标召回率、精确率、MRR、NDCG判断 RAG 好坏不能靠“感觉还挺相关”。你需要一套指标尤其是当你已经积累了几百条测试问题时。先明确两个基本概念精确率PrecisionK你检索返回的 K 条结果里有多少条是真正相关的。召回率RecallK所有相关文档里你找回来了多少条。K 越大召回通常越高但精确率会下降。除了这两个还有两个更常用、但在实际项目里经常被误读的指标MRRMean Reciprocal Rank看第一条正确答案排在第几位。如果第一条正确结果在第二位那这条 query 的 reciprocal rank 就是 1/2。把所有 query 取平均得到 MRR。判断“正确答案是否能被排到最前面”时MRR 很直接。NDCGNormalized Discounted Cumulative Gain不只是看“相关与否”还看“相关程度”。它会按位置的先后对收益打折排得越靠后增益越小。适合排序结果本身有级别差异的场景。把这四个指标放一起你不光能看出“检索得准不准”还能看出“正确结果排得靠不靠前”。这比肉眼翻看十来条结果要可靠得多。3.2 生成质量评估忠实度、相关性、完整性检索指标只解决一半问题。另一半是“生成质量”。RAG 的生成评估通常要分开看三个维度忠实度Faithfulness模型的回答是否严格基于检索到的材料有没有自己的“想象力”。这是 RAG 最重要的指标它直接决定你是否能信任回答。答案相关性Answer Relevance回答是否在回应 query而不是答非所问或绕圈子。完整性Completeness针对一个需要多步骤回答的问题答案是否覆盖了所有必要部分。评估方式有两种。一种是用 LLM 作为裁判把“材料 答案 评估标准”发给一个强模型让它打分并输出理由。另一种是人工抽检尤其在小样本阶段人工抽检能发现很多自动评估看不到的语义问题。实际项目里通常混合使用自动评估跑全量人工抽检跑关键案例。3.3 一套可复用的评估迭代框架这里沉淀一个比较通用的 RAG 评估流程适合从零开始的项目准备 30-100 条测试问题覆盖高频问题、复杂问题、边界问题、应该回答“不知道”的问题。对每个测试问题标注标准答案以及“回答依据应在哪些文档内”。先跑一遍当前链路记录检索结果和生成结果。计算检索指标RecallK、MRR、NDCG和生成指标忠实度、相关性、完整性。找出失败案例按“检索失败”和“生成失败”分类。检索失败调整分块、embedding、检索方式、重排。生成失败调整上下文组装、prompt 约束、候选文档数量。每改一步只跑一次全量评估对比前后指标不要把多个改动混在一起。这个框架看起来不复杂但它是 RAG 从“能跑”走向“可用”的分水岭。没有评估你就不知道改动是在变好还是变坏。4. 从课程到项目为什么建议先跑通最小闭环再上框架4.1 “先手写一遍 RAG 链路”到底在练什么现在有 LangChain、LlamaIndex、Dify、向量数据库自带 SDK 这些高层封装很多人会问还有必要手写 RAG 吗我的判断是如果你只是想快速做个 demo用框架没问题但如果你要做真实的 RAG 项目最好先手写一遍最小链路哪怕很简陋。手写一遍的价值不是“不用框架”而是让你理解每一层发生了什么文档加载之后文本在哪里被切分、以什么结构存储向量化之后元数据、来源、分块 ID 是怎么和向量关联的检索时query 是怎么被向量化的Top K 被取出来后发生了什么组装 prompt 时候选文本的截断、排序、来源标注是怎么处理的这些问题在用框架时很容易被屏蔽掉。框架帮你把链路串起来了但一旦出问题你往往不知道去哪一层排查。我建议的最小闭环是这样的准备一个 PDF 或 Markdown 文件。写脚本切分文本保存成带 ID 的文档块。调用 embedding 模型把每个块向量化存进向量数据库。用一个 query 做向量检索打印出 Top 5 结果。把检索结果拼进一个写好的 prompt调用 LLM 生成回答。打印完整 prompt看模型到底“看到”了什么。这一步跑通后再引入框架你会发现框架里每个参数、每个组件都在解决你手写时遇到过的真实问题。这时候学 LangChain、Dify 就不是“记 API”而是理解设计思路。4.2 LangChain、Dify、LlamaIndex 这些框架的边界框架也不是没有价值。它们真正解决的是“常见模式的复用”LangChain 提供了大量 loader、splitter、retriever、memory 的标准化接口适合拼装自定义链路。LlamaIndex 在文档解析和索引结构上做得更细适合做以文档为中心的知识库。Dify 把 RAG 应用做成了可视化编排适合快速验证流程也适合给业务人员配置。但框架也有明显的边界框架的价值在于“默认路径帮你走通”但不保证每个默认值都适合你的场景。框架升级快API 变动频繁跟着教程敲代码容易陷入“版本对不上”的坑。框架隐藏了成本结构。一次检索调用多少次 embedding、多少个候选块进 prompt、有没有重复计算都需要你额外关注。所以我会把框架当成“高级工具箱”而不是“学习入口”。先用最小闭环建立心智模型再根据项目复杂度选择合适的框架是更稳的路径。4.3 长期工程化还需要补什么从“一个能跑的知识库问答”到“一个可用的系统”中间还缺几块拼图日志链路每条 query 的检索结果、最终 prompt、模型输出都要记录。没有日志你就无法复现失败案例也无法改进。缓存与成本控制相同或相似 query 的检索结果可以缓存候选文档数量要控制embedding 调用要避免重复计算。降级策略向量数据库挂了怎么办模型服务超时怎么办有没有关键词检索兜底权限与数据隔离多用户场景下A 用户的知识库不能泄露给 B 用户。这个在架构设计阶段就要考虑。版本管理文档更新后向量库怎么同步旧的向量怎么清理embedding 模型升级后是否要全部重新向量化评测沉淀把测试集、评估脚本、业务指标固化下来纳入开发和发布流程。这些内容通常不会出现在“入门教程”里但恰恰是判断一个 RAG 项目是否成熟的关键。5. 一个针对 RAG 的排查链路5.1 检索不到先查输入、切分、embedding、索引、query如果用户问的问题明明在知识库里但检索不到相关内容按这个顺序排查查输入文档PDF 是不是扫描件有没有 OCR文本是不是被破坏查切分目标内容是不是被切碎了或者跟不相关的内容混在同一个块里查 embedding 结果把目标文档块和 query 分别向量化算一下相似度看是不是真的低。查索引和元数据过滤是不是有权限过滤、时间过滤误伤了目标内容查 query 本身用户问的是“怎么退款”但文档里写的是“退货政策”语义术语不同需要同义词扩展或混合检索。5.2 检索到了但答错先查上下文组装和 prompt如果 Top 5 检索结果里有正确答案但最终回答还是错的问题通常出在生成阶段先打印完整 prompt确认模型到底看到了哪些内容。检查候选文本是否被截断截断后关键信息是否丢失。检查 prompt 里的排序正确答案是否被排到后面被无关内容挤占。检查模型角色设定和回答规则有没有约束“只能基于材料回答”。如果都正常换更强的模型试一次。部分问题对推理能力要求高小模型确实答不对。5.3 回答慢或成本高先查候选数量、缓存、并发RAG 系统的“慢”通常来自三个地方检索慢向量库数据量大、索引类型不合适、没有用 ANN 索引。生成慢候选块太多prompt 太长模型输出 token 数太多。调用链慢每次请求重复做 embedding、重复查库缺少缓存。建议先加缓存再看 Top K 数和 max_tokens最后才考虑换模型或换索引。5.4 一张排查表格现象优先排查可能原因明明有答案检索不到输入文档、切分、embedding、query文档解析损坏、切分不合理、术语不一致检索结果有正确答案但回答错误prompt、上下文组装、模型能力候选排序差、关键信息被截断、模型推理弱回答答非所问query 改写、重排检索噪声太大正确答案没被重排到前面回答速度慢缓存、Top K、向量索引、max_tokens候选块过多、prompt 过长、无缓存回答不忠实编造信息prompt 约束、忠实度评估模型没被限制在材料范围内排查的基本原则是一次只改一个变量改完跑一组测试集用指标判断是否变好。6. 学习顺序才是这类课程真正值钱的地方6.1 不要按章节顺序学要按问题顺序学很多课程和项目把内容拆成“基础概念-环境搭建-代码实现-项目实战”。这种顺序适合系统的知识索引但不适合构建解决真实问题的能力。因为真实世界里你不会先学完所有概念再动手。你通常是先遇到一个问题然后被迫去理解相关概念。以 RAG 为例我更推荐按问题顺序学先用 30 分钟跑通一个最小 RAG demo建立感性认知。故意制造几个失败案例改小分块、去掉重排、把 prompt 约束删掉观察效果变化。带着失败经验去学理论为什么切分影响检索为什么需要混合检索再补评估指标用数据验证之前的直觉。最后再学框架用框架复现手动链路。这样的学习路径比从头到尾看一遍课程更牢靠。因为每一步都是在解决一个你已经遇到的真实问题而不是记忆一个未来可能用到的 API。6.2 “part1”背后的内容边界意识回到课程标题里的 “part1”。它其实揭示了一个行业事实GenAI 和 LLM 工程化的内容量已经大到不可能一个课程、一个章节全部讲完。基础层面有 tokenizer、模型架构、推理优化、上下文管理应用层面有 prompt 工程、RAG、Agent、工具调用、记忆管理工程层面有评估、可观测性、成本控制、数据管道再往上还有多模态、微调、蒸馏、部署、运维。如果你把“学会 RAG”当成目标那是一个有限目标按上面的路径走两三个月就能入门。如果你把“精通 LLM 工程”当成目标那就要接受这是一个持续迭代的过程。每次学习新模块都应该带着前面沉淀下来的问题意识和排查方法而不是从零开始背概念。6.3 我的最终建议把 RAG 当成一个“系统调试”问题而不是“模型调用”问题回到开头的问题为什么 RAG 教程总让人觉得“会了但没用”因为真正决定系统质量的不是你会不会调用模型而是你有没有能力把输入、切分、向量、检索、重排、组装、生成、评估这八个环节拆开、调优、再组装起来。我给想系统学习 AI 和 LLM 工程的读者的建议是选一门覆盖完整链路的课程或项目但不要跟着敲完就算完。准备一套自己的小规模数据集用真实文档做 RAG。手写一遍最小链路建立每个环节的心智模型。用评估指标驱动改进不要靠体感迭代。再引入框架把精力放在业务逻辑和系统健壮性上。这样学下来的结果不是“会用 RAG”而是“能判断、能定位、能改进一个 RAG 系统”。后者才是这类课程把它叫做 Engineering Mastery 的原因。RAG 本身还在快速演进。Agentic RAG、Graph RAG、自适应检索、多轮记忆融合这些方向都会持续改变它的实现形态。但只要你有“链路拆解 指标迭代 系统排查”这套底层能力无论 RAG 怎么变你都能快速接住。下次再看到一个“3 小时搞懂 RAG”的视频不用点进去。省下那三个小时去搭一套自己的 RAG 系统然后逼自己回答一个问题如果检索结果不好我下一步动哪一层
RAG系统调优实战：从检索到生成的全链路优化指南
看到标题里的 “Complete Guide part1” 时我第一反应不是“这门课讲什么”而是“为什么现在 AI、LLM、GenAI 和 RAG 这四个词能凑到同一门课里并且还要分成 part1、part2 来讲”。如果你已经在用 LangChain、Dify 或手写过 RAG 流程大概率也遇到过类似困惑教程里每一步都跑通了合在一起就是不稳定检索结果看着相关模型回答却完全跑偏明明加了知识库模型还是答非所问。这不是某个工具的问题而是 RAG 从一开始就不是“一个库”“一个脚本”能解决的它是一套完整系统。而这套系统最难的恰恰不是生成是检索、组装、评估和迭代。这篇不是课程导读也不是功能介绍。我想从 RAG 工程化的角度拆一拆为什么这类内容值得系统学一遍、真正的学习分水岭在哪里以及从 demo 到可用之间你到底缺了哪些环节。1. 为什么 RAG 不是“一个库”而是一套需要调优的系统1.1 先分清RAG 真正解决的不是检索而是可控生成很多人理解 RAG第一反应是“给 LLM 加一个知识库”让模型回答私有数据、最新数据。这个理解没有错但它把 RAG 的价值说小了。RAG 真正解决的是“生成的可控性”问题。大模型在训练时被“固化”了一部分知识这些知识有截止时间、有覆盖范围、也有胡说八道的可能。RAG 的思路是不在模型内部硬塞知识而是在回答的当下先从外部检索到相关内容再把检索结果拼进提示词让模型基于给定材料作答。这意味着两件事模型可以不用“记住”你的私有知识它只需要“读懂”你给它的片段。回答的依据是可替换、可追溯、可更新的而不是埋在权重里不可解释。所以如果你只是把 PDF 切开、塞进向量库、然后等模型回答那你只做了 RAG 的表层。真正的 RAG 工程是把“检索-组装-生成-检验”这整条链路变成一套可以被度量、被调整、被迭代的系统。这门课程把 RAG 放在“AI LLM Engineering Mastery”的框架里而不是单独讲一个“文档问答工具”背后其实就是这个逻辑。1.2 为什么很多人停留在“demo 能跑”阶段我见过不少开发者环境装好、代码跑通、示例问答能返回结果然后就没有然后了。原因不是懒而是 demo 和真实系统之间隔着四道墙数据墙示例文档是干净的真实文档是扫描件、多栏排版、表格、图片混合体。检索墙示例 query 是和文档强相关的真实 query 是口语化、模糊、带错别字的。判断墙示例只看最终回答真实系统要判断“到底有没有答对”“依据是否充分”。迭代墙示例改一次就完了真实系统每天都要面对新文档、新问题、新失败案例。课程能讲完的永远是通用方法和典型链路。真正拉开差距的是你有没有能力把上面四道墙逐个拆掉。而拆掉的前提是你完整理解 RAG 内部每一层在干什么。2. 把 RAG 拆成七层你才知道问题出在哪如果一个 RAG 系统表现不好最忌讳的是整条链路一起调整。正确做法是先定位问题出在输入解析、分块策略、embedding、检索、重排、上下文组装还是生成环节为了做定位我建议把 RAG 拆成七个层面来理解。2.1 从文档解析到分块输入质量决定结果上限绝大多数 RAG 失效问题不在模型而在“喂进去的东西”。文档解析不是“把 PDF 变成文本”这么简单。PDF 里的多栏排版、页眉页脚、表格、图片说明、脚注都会污染切分结果。你切出来的文本块可能包含半个句子、两个不相关内容、或者把一个完整概念从中间切断。这些噪声对向量检索的影响是致命的因为 embedding 模型关注的是语义不是版面。分块策略同样关键。分块太小语义不完整分块太大向量表示被平均化检索精度下降。这里没有标准答案但有几个通用判断顺序先保证块内语义完整再考虑长度。优先按标题、段落、表格边界来切而不是固定字符数。相邻块之间要保留重叠防止概念被切开。如果是代码、表格、合同条款这类结构化内容要用对应解析器不能一刀切。更实际的做法是先准备 20 到 50 条真实问答再用这些问答去检验切分结果。如果答案信息分散在多个块里就说明切分粒度或重叠策略需要调整。这一步不做好后面所有环节都在补救。2.2 向量化与检索相似度不是唯一标准embedding 模型决定了文本在向量空间里的“位置”。同一个 query用不同的 embedding 模型检索结果差异可能非常大。选型时不能只看公开榜单分数还要看你的文本领域和语言。比如你的知识库是中文技术文档、法律合同、还是英文论文适合的模型不一样。不同模型的上下文长度、维度、对长文本的压缩方式也不同。这里给一个选型检查顺序先拿 10 条你领域内的 query 做测试。对比召回结果里有多少条是真正有用的。判断模型对同义词、口语化表达、缩写是否敏感。如果检索质量不行优先换 embedding 模型而不是调相似度阈值。检索阶段同样不能只看向量相似度。精确匹配、BM25 关键词检索、混合检索hybrid search在很多时候比纯向量检索更可靠尤其是当 query 包含型号、编号、人名、日期这些“必须精确命中”的信息时。常见的做法是向量检索负责语义召回关键词检索负责精确召回然后用重排模型reranker把两组结果合并排序。重排环节非常容易被忽视。向量检索返回 Top K 后K 个结果里可能只有 2 个真正相关。重排模型的职责就是把这 2 个往前放。很多场景里加一个 reranker 比换 embedding 模型带来的提升更明显。2.3 上下文组装和生成prompt 工程在这条链路里的真实位置检索完之后怎么把检索结果拼进 prompt直接决定生成质量。常见错误有两种把全部检索结果一股脑塞进 prompt导致模型被无关内容干扰。没有告诉模型“只用给定材料回答材料里没有就直说”。更合理的组装方式是把检索结果按相关度排序只保留最相关的几段并明确标注每段内容的来源。Prompt 里要写清楚三件事系统角色、可用材料、回答规则。回答规则至少包括“仅基于材料回答”“材料不足时明确说不知道”“不要编造来源”。这里还想纠正一个观念prompt 工程不是独立的魔法它是 RAG 链路里的一个环节。只有当检索结果足够好时prompt 才能发挥真正作用。检索返回一堆噪声写再多提示词也救不回来。反过来检索结果很好但 prompt 没有约束模型只基于材料作答模型还是会自由发挥。两个环节要一起调。3. 用指标而不是体感来判断 RAG 好不好3.1 检索质量指标召回率、精确率、MRR、NDCG判断 RAG 好坏不能靠“感觉还挺相关”。你需要一套指标尤其是当你已经积累了几百条测试问题时。先明确两个基本概念精确率PrecisionK你检索返回的 K 条结果里有多少条是真正相关的。召回率RecallK所有相关文档里你找回来了多少条。K 越大召回通常越高但精确率会下降。除了这两个还有两个更常用、但在实际项目里经常被误读的指标MRRMean Reciprocal Rank看第一条正确答案排在第几位。如果第一条正确结果在第二位那这条 query 的 reciprocal rank 就是 1/2。把所有 query 取平均得到 MRR。判断“正确答案是否能被排到最前面”时MRR 很直接。NDCGNormalized Discounted Cumulative Gain不只是看“相关与否”还看“相关程度”。它会按位置的先后对收益打折排得越靠后增益越小。适合排序结果本身有级别差异的场景。把这四个指标放一起你不光能看出“检索得准不准”还能看出“正确结果排得靠不靠前”。这比肉眼翻看十来条结果要可靠得多。3.2 生成质量评估忠实度、相关性、完整性检索指标只解决一半问题。另一半是“生成质量”。RAG 的生成评估通常要分开看三个维度忠实度Faithfulness模型的回答是否严格基于检索到的材料有没有自己的“想象力”。这是 RAG 最重要的指标它直接决定你是否能信任回答。答案相关性Answer Relevance回答是否在回应 query而不是答非所问或绕圈子。完整性Completeness针对一个需要多步骤回答的问题答案是否覆盖了所有必要部分。评估方式有两种。一种是用 LLM 作为裁判把“材料 答案 评估标准”发给一个强模型让它打分并输出理由。另一种是人工抽检尤其在小样本阶段人工抽检能发现很多自动评估看不到的语义问题。实际项目里通常混合使用自动评估跑全量人工抽检跑关键案例。3.3 一套可复用的评估迭代框架这里沉淀一个比较通用的 RAG 评估流程适合从零开始的项目准备 30-100 条测试问题覆盖高频问题、复杂问题、边界问题、应该回答“不知道”的问题。对每个测试问题标注标准答案以及“回答依据应在哪些文档内”。先跑一遍当前链路记录检索结果和生成结果。计算检索指标RecallK、MRR、NDCG和生成指标忠实度、相关性、完整性。找出失败案例按“检索失败”和“生成失败”分类。检索失败调整分块、embedding、检索方式、重排。生成失败调整上下文组装、prompt 约束、候选文档数量。每改一步只跑一次全量评估对比前后指标不要把多个改动混在一起。这个框架看起来不复杂但它是 RAG 从“能跑”走向“可用”的分水岭。没有评估你就不知道改动是在变好还是变坏。4. 从课程到项目为什么建议先跑通最小闭环再上框架4.1 “先手写一遍 RAG 链路”到底在练什么现在有 LangChain、LlamaIndex、Dify、向量数据库自带 SDK 这些高层封装很多人会问还有必要手写 RAG 吗我的判断是如果你只是想快速做个 demo用框架没问题但如果你要做真实的 RAG 项目最好先手写一遍最小链路哪怕很简陋。手写一遍的价值不是“不用框架”而是让你理解每一层发生了什么文档加载之后文本在哪里被切分、以什么结构存储向量化之后元数据、来源、分块 ID 是怎么和向量关联的检索时query 是怎么被向量化的Top K 被取出来后发生了什么组装 prompt 时候选文本的截断、排序、来源标注是怎么处理的这些问题在用框架时很容易被屏蔽掉。框架帮你把链路串起来了但一旦出问题你往往不知道去哪一层排查。我建议的最小闭环是这样的准备一个 PDF 或 Markdown 文件。写脚本切分文本保存成带 ID 的文档块。调用 embedding 模型把每个块向量化存进向量数据库。用一个 query 做向量检索打印出 Top 5 结果。把检索结果拼进一个写好的 prompt调用 LLM 生成回答。打印完整 prompt看模型到底“看到”了什么。这一步跑通后再引入框架你会发现框架里每个参数、每个组件都在解决你手写时遇到过的真实问题。这时候学 LangChain、Dify 就不是“记 API”而是理解设计思路。4.2 LangChain、Dify、LlamaIndex 这些框架的边界框架也不是没有价值。它们真正解决的是“常见模式的复用”LangChain 提供了大量 loader、splitter、retriever、memory 的标准化接口适合拼装自定义链路。LlamaIndex 在文档解析和索引结构上做得更细适合做以文档为中心的知识库。Dify 把 RAG 应用做成了可视化编排适合快速验证流程也适合给业务人员配置。但框架也有明显的边界框架的价值在于“默认路径帮你走通”但不保证每个默认值都适合你的场景。框架升级快API 变动频繁跟着教程敲代码容易陷入“版本对不上”的坑。框架隐藏了成本结构。一次检索调用多少次 embedding、多少个候选块进 prompt、有没有重复计算都需要你额外关注。所以我会把框架当成“高级工具箱”而不是“学习入口”。先用最小闭环建立心智模型再根据项目复杂度选择合适的框架是更稳的路径。4.3 长期工程化还需要补什么从“一个能跑的知识库问答”到“一个可用的系统”中间还缺几块拼图日志链路每条 query 的检索结果、最终 prompt、模型输出都要记录。没有日志你就无法复现失败案例也无法改进。缓存与成本控制相同或相似 query 的检索结果可以缓存候选文档数量要控制embedding 调用要避免重复计算。降级策略向量数据库挂了怎么办模型服务超时怎么办有没有关键词检索兜底权限与数据隔离多用户场景下A 用户的知识库不能泄露给 B 用户。这个在架构设计阶段就要考虑。版本管理文档更新后向量库怎么同步旧的向量怎么清理embedding 模型升级后是否要全部重新向量化评测沉淀把测试集、评估脚本、业务指标固化下来纳入开发和发布流程。这些内容通常不会出现在“入门教程”里但恰恰是判断一个 RAG 项目是否成熟的关键。5. 一个针对 RAG 的排查链路5.1 检索不到先查输入、切分、embedding、索引、query如果用户问的问题明明在知识库里但检索不到相关内容按这个顺序排查查输入文档PDF 是不是扫描件有没有 OCR文本是不是被破坏查切分目标内容是不是被切碎了或者跟不相关的内容混在同一个块里查 embedding 结果把目标文档块和 query 分别向量化算一下相似度看是不是真的低。查索引和元数据过滤是不是有权限过滤、时间过滤误伤了目标内容查 query 本身用户问的是“怎么退款”但文档里写的是“退货政策”语义术语不同需要同义词扩展或混合检索。5.2 检索到了但答错先查上下文组装和 prompt如果 Top 5 检索结果里有正确答案但最终回答还是错的问题通常出在生成阶段先打印完整 prompt确认模型到底看到了哪些内容。检查候选文本是否被截断截断后关键信息是否丢失。检查 prompt 里的排序正确答案是否被排到后面被无关内容挤占。检查模型角色设定和回答规则有没有约束“只能基于材料回答”。如果都正常换更强的模型试一次。部分问题对推理能力要求高小模型确实答不对。5.3 回答慢或成本高先查候选数量、缓存、并发RAG 系统的“慢”通常来自三个地方检索慢向量库数据量大、索引类型不合适、没有用 ANN 索引。生成慢候选块太多prompt 太长模型输出 token 数太多。调用链慢每次请求重复做 embedding、重复查库缺少缓存。建议先加缓存再看 Top K 数和 max_tokens最后才考虑换模型或换索引。5.4 一张排查表格现象优先排查可能原因明明有答案检索不到输入文档、切分、embedding、query文档解析损坏、切分不合理、术语不一致检索结果有正确答案但回答错误prompt、上下文组装、模型能力候选排序差、关键信息被截断、模型推理弱回答答非所问query 改写、重排检索噪声太大正确答案没被重排到前面回答速度慢缓存、Top K、向量索引、max_tokens候选块过多、prompt 过长、无缓存回答不忠实编造信息prompt 约束、忠实度评估模型没被限制在材料范围内排查的基本原则是一次只改一个变量改完跑一组测试集用指标判断是否变好。6. 学习顺序才是这类课程真正值钱的地方6.1 不要按章节顺序学要按问题顺序学很多课程和项目把内容拆成“基础概念-环境搭建-代码实现-项目实战”。这种顺序适合系统的知识索引但不适合构建解决真实问题的能力。因为真实世界里你不会先学完所有概念再动手。你通常是先遇到一个问题然后被迫去理解相关概念。以 RAG 为例我更推荐按问题顺序学先用 30 分钟跑通一个最小 RAG demo建立感性认知。故意制造几个失败案例改小分块、去掉重排、把 prompt 约束删掉观察效果变化。带着失败经验去学理论为什么切分影响检索为什么需要混合检索再补评估指标用数据验证之前的直觉。最后再学框架用框架复现手动链路。这样的学习路径比从头到尾看一遍课程更牢靠。因为每一步都是在解决一个你已经遇到的真实问题而不是记忆一个未来可能用到的 API。6.2 “part1”背后的内容边界意识回到课程标题里的 “part1”。它其实揭示了一个行业事实GenAI 和 LLM 工程化的内容量已经大到不可能一个课程、一个章节全部讲完。基础层面有 tokenizer、模型架构、推理优化、上下文管理应用层面有 prompt 工程、RAG、Agent、工具调用、记忆管理工程层面有评估、可观测性、成本控制、数据管道再往上还有多模态、微调、蒸馏、部署、运维。如果你把“学会 RAG”当成目标那是一个有限目标按上面的路径走两三个月就能入门。如果你把“精通 LLM 工程”当成目标那就要接受这是一个持续迭代的过程。每次学习新模块都应该带着前面沉淀下来的问题意识和排查方法而不是从零开始背概念。6.3 我的最终建议把 RAG 当成一个“系统调试”问题而不是“模型调用”问题回到开头的问题为什么 RAG 教程总让人觉得“会了但没用”因为真正决定系统质量的不是你会不会调用模型而是你有没有能力把输入、切分、向量、检索、重排、组装、生成、评估这八个环节拆开、调优、再组装起来。我给想系统学习 AI 和 LLM 工程的读者的建议是选一门覆盖完整链路的课程或项目但不要跟着敲完就算完。准备一套自己的小规模数据集用真实文档做 RAG。手写一遍最小链路建立每个环节的心智模型。用评估指标驱动改进不要靠体感迭代。再引入框架把精力放在业务逻辑和系统健壮性上。这样学下来的结果不是“会用 RAG”而是“能判断、能定位、能改进一个 RAG 系统”。后者才是这类课程把它叫做 Engineering Mastery 的原因。RAG 本身还在快速演进。Agentic RAG、Graph RAG、自适应检索、多轮记忆融合这些方向都会持续改变它的实现形态。但只要你有“链路拆解 指标迭代 系统排查”这套底层能力无论 RAG 怎么变你都能快速接住。下次再看到一个“3 小时搞懂 RAG”的视频不用点进去。省下那三个小时去搭一套自己的 RAG 系统然后逼自己回答一个问题如果检索结果不好我下一步动哪一层