Suda：RAG教程看了 100 篇，为什么还是做不好？

Suda：RAG教程看了 100 篇，为什么还是做不好？ Suda：RAG教程看了 100 篇，为什么还是做不好？ Modified January 7 Glean定位为企业内部的"工作AI助理"，核心是跨系统的语义搜索+问答。研究它的价值不在于推荐这个产品，而是 理解企业级RAG要额外解决什么问题 ——这些设计思路同样适用于自建系统。 4.1 企业搜索 vs 个人搜索：本质区别 企业搜索和个人搜索的核心差异不在于"有没有"某个能力，而在于 复杂度量级 ： 核心洞察 ： • 个人搜索：单用户 × 少数据源 × 简单个性化 • 企业搜索：多用户 × 多数据源 × 多维度个性化 × 权限治理 混合检索（BM25+向量）已是行业标配，不是企业搜索的差异化能力。Glean的核心价值在于处理 权限、多维度个性化、场景化时效性、术语理解、数据治理 这些企业特有的复杂度。 4.2 统一权限模型 核心问题 ：企业有100+数据源，每个系统权限模型不同，如何统一？ Glean的解决方案 ： 关键实现细节 ： • 不是检索后再查权限（太慢），而是 权限预先索引 • 通过实时同步机制同步权限变更 • 支持权限继承（文件夹权限自动继承到子文件） 4.3 时效性加权 核心问题 ：旧文档被引用多、内容丰富，向量得分往往更高，但用户要的是最新的。 场景化调整 ：不是所有查询都需要最新的 • 搜「公司政策」→ 时效性权重高 • 搜「技术文档」→ 时效性权重中 • 搜「历史记录」→ 时效性权重低 这个思路对任何RAG系统都适用： 时效性不是一个全局参数，而是要根据查询意图动态调整 。 4.4 个性化排序 核心问题 ：同一个问题，销售和工程师需要的结果不同。 Glean的个性化信号 ： 实际效果 ： • 销售搜「Q3报告」→ 优先返回销售数据 • 工程搜「Q3报告」→ 优先返回技术指标 4.5 双层知识图谱 Glean构建两层图谱： 企业图谱（组织级）+ 个人图谱（用户级） 企业图谱 维度 作用 语义系统 理解组织内部术语（Project Titan = 2024旗舰项目） 文档链接 文档间的引用/关联关系 人员网络 组织内人员协作关系网络 概念理解 领域概念的同义词、上下位关系 个人图谱 维度 作用 协作网络 用户常合作的同事 关注领域 用户常访问的文档类型/主题 工作上下文 用户当前参与的项目/任务 双层图谱的价值 ： • 企业图谱解决「术语理解」和「实体消歧」 • 个人图谱解决「个性化排序」 • 两者结合实现：同一个问题，不同人看到与自己最相关的结果 研究Glean不是为了推荐它（大多数团队也用不起），而是想搞清楚： 从个人RAG到企业RAG，中间差了什么？ 答案是：权限、个性化、时效性、术语理解。 这些问题在个人项目里感知不到，但在企业场景里是刚需。如果你在做ToB的RAG产品，这些是绕不过去的。 五、落地建议 5.1 先建评 测 体系，再谈优化 这是我最想强调的一点： 没有评 测 体系的RAG优化是在碰运气 。 很多人的做法是：上线 → 用户反馈不好 → 调参数 → 再上线 → 还是不好 → 继续调…… 问题是：你怎么知道调对了？用户说"不好"，是检索不准？还是回答不对？还是根本没理解问题？ 比跑指标更重要的是：自己看case，做错误分析。 作为AI产品经理，你至少得亲自看过100个case才能建立体感。不是看指标报告，是一个一个看：用户问了什么、检索到了什么、回答了什么、哪里出了问题。 看多了你会发现错误是有规律的： • 某类问题总是检索不到 → 可能是切块策略问题 • 检索到了但回答错 → 可能是上下文太长LLM没注意到 • 某个文档反复出问题 → 可能是解析有问题 错误分析比优化更重要 。知道错在哪，优化方向才清晰。 评测工具方面，LlamaIndex内置了 评测 模块，包含诸如：忠实度（Faithfulness）、相关性（Relevancy）、正确性（Correctness）、语义相似度（Semantic Similarity）等指标。 开源工具还有Ragas（专注RAG 评测 ）、DeepEval（更全面的LLM 评测 框架）、Arize Phoenix（观测平台）等。但工具只是辅助，核心还是你对case的理解。 评测 这块内容很多， 我准备单独写一篇展开 。 5.2 分阶段路线图 第一阶段：MVP（2 4周） 目标：跑通基础RAG，验证可行性 技术栈： • 向量检索：LlamaIndex VectorStoreIndex • 关键词检索：BM25 • 时效性过滤：文件日期 • 简单合并排序 交付物：能用的问答原型 第二阶段：优化（4 8周） 目标：提升准确率，加入高级能力 新增： • 实体识别（评分标准、技术要求） • 简单图谱（文档 评分项 案例） • 点击反馈学习 • 基于用户历史的个性化 关键动作： 建立 评测 体系，数据驱动迭代 第三阶段：进阶（可选） 目标：达到生产级水平 新增： • 完整知识图谱（项目 标段 评分规则 中标方案） • 多跳推理（类似项目的中标策略） • 自动更新图谱 前提：有足够的数据和工程资源 5.3 技术栈推荐 层级 推荐方案 备选 检索框架 LlamaIndex 向量库 Milvus / Qdrant pgvector 文档解析 LlamaParse MinerU 图谱（可选） Neo4j 评测 LlamaIndex内置 Ragas LLM选型不列了。原则很简单： 先用最强的模型（GPT/Claude/Gemini）把效果调到位，再考虑换便宜模型降成本 。别一开始就用小模型省钱，效果差了你都不知道是模型问题还是RAG问题。 5.4 常见坑 坑 说明 避坑方法 一上来就建知识图谱 过度设计，投入产出不划算 MVP先验证基础RAG 只用向量数据库 精度不够，无法精确匹配 混合检索（BM25+向量） 自己造轮子 浪费时间重复发明 用LlamaIndex 不做评测 就上线 不知道效果好不好 先建 评测 体系 忽视解析质量 垃圾进，垃圾出 先看解析，再调检索 5.5 几句大实话 1. 解析是地基 ——效果不好先查解析，别急着换架构 2. 没有银弹 ——不同文档用不同工具，别指望一招鲜吃遍天 3. 先跑起来再说 ——从简单方案开始做起， 完美主义是RAG项目最大的敌人 4. 评测 比优化重要 ——没有 评测 体系，你根本不知道改对了没 写在最后 写完这篇，我最大的感受是： RAG没有银弹 。 市面上太多文章在推销某个框架、某个架构、某个神奇的技术，好像用了就能解决所有问题。但现实是，RAG的效果取决于一系列琐碎的决策：文档怎么解析、怎么切块、用什么向量模型、检索策略怎么配、重排序要不要加……每个环节都可能出问题。 如果非要总结几个最重要的认知： 1. 解析是门槛 ——做不好是0分，做好了是60分及格线 2. 检索是天花板 ——从60到90全靠这里，但调优是玄学 3. 评测是指南针 ——没有 评测 体系，优化就是碰运气 还有很多我没想清楚的问题，比如： • 评测体系怎么建才能真正反映业务效果，而不是自嗨？ • 多模态RAG在实际场景中的ROI到底怎么样？ • Agentic RAG的可控性问题怎么解决？ 如果你也在研究这些，或者有实践经验想分享，欢迎加我微信聊： Suda Lulu 独学无友，则孤陋寡闻。 参考资料 论文 • Retrieval Augmented Generation for Large Language Models: A Survey（RAG综述） • Agentic Retrieval Augmented Generation: A Survey on Agentic RAG（Agentic RAG综述） • LongRAG: Enhancing Retrieval Augmented Generation with Long context LLMs（长上下文RAG） • ColPali: Efficient Document Retrieval with Vision Language Models（多模态RAG） 产品文档 • LlamaIndex: https://docs.llamaindex.ai/ • LlamaCloud: https://cloud.llamaindex.ai/ • RAGFlow: https://ragflow.io/ • Glean: https://developers.glean.com/ Glean定位为企业内部的"工作AI助理"，核心是跨系统的语义搜索+问答。研究它的价值不在于推荐这个产品，而是 理解企业级RAG要额外解决什么问题 ——这些设计思路同样适用于自建系统。 4.1 企业搜索 vs 个人搜索：本质区别 企业搜索和个人搜索的核心差异不在于"有没有"某个能力，而在于 复杂度量级 ： 核心洞察 ： • 个人搜索：单用户 × 少数据源 × 简单个性化 • 企业搜索：多用户 × 多数据源 × 多维度个性化 × 权限治理 混合检索（BM25+向量）已是行业标配，不是企业搜索的差异化能力。Glean的核心价值在于处理 权限、多维度个性化、场景化时效性、术语理解、数据治理 这些企业特有的复杂度。 4.2 统一权限模型 核心问题 ：企业有100+数据源，每个系统权限模型不同，如何统一？ Glean的解决方案 ： 关键实现细节 ： • 不是检索后再查权限（太慢），而是 权限预先索引 • 通过实时同步机制同步权限变更 • 支持权限继承（文件夹权限自动继承到子文件） 4.3 时效性加权 核心问题 ：旧文档被引用多、内容丰富，向量得分往往更高，但用户要的是最新的。 场景化调整 ：不是所有查询都需要最新的 • 搜「公司政策」→ 时效性权重高 • 搜「技术文档」→ 时效性权重中 • 搜「历史记录」→ 时效性权重低 这个思路对任何RAG系统都适用： 时效性不是一个全局参数，而是要根据查询意图动态调整 。 4.4 个性化排序 核心问题 ：同一个问题，销售和工程师需要的结果不同。 Glean的个性化信号 ： 实际效果 ： • 销售搜「Q3报告」→ 优先返回销售数据 • 工程搜「Q3报告」→ 优先返回技术指标 4.5 双层知识图谱 Glean构建两层图谱： 企业图谱（组织级）+ 个人图谱（用户级） 企业图谱 维度 作用 语义系统 理解组织内部术语（Project Titan = 2024旗舰项目） 文档链接 文档间的引用/关联关系 人员网络 组织内人员协作关系网络 概念理解 领域概念的同义词、上下位关系 维度 维度 作用 作用 语义系统 语义系统 理解组织内部术语（Project Titan = 2024旗舰项目） 理解组织内部术语（Project Titan = 2024旗舰项目） 文档链接 文档链接 文档间的引用/关联关系 文档间的引用/关联关系 人员网络 人员网络 组织内人员协作关系网络 组织内人员协作关系网络 概念理解 概念理解 领域概念的同义词、上下位关系 领域概念的同义词、上下位关系 个人图谱 维度 作用 协作网络 用户常合作的同事 关注领域 用户常访问的文档类型/主题 工作上下文 用户当前参与的项目/任务 维度 维度 作用 作用 协作网络 协作网络 用户常合作的同事 用户常合作的同事 关注领域 关注领域 用户常访问的文档类型/主题 用户常访问的文档类型/主题 工作上下文 工作上下文 用户当前参与的项目/任务 用户当前参与的项目/任务 双层图谱的价值 ： • 企业图谱解决「术语理解」和「实体消歧」 • 个人图谱解决「个性化排序」 • 两者结合实现：同一个问题，不同人看到与自己最相关的结果 研究Glean不是为了推荐它（大多数团队也用不起），而是想搞清楚： 从个人RAG到企业RAG，中间差了什么？ 答案是：权限、个性化、时效性、术语理解。 这些问题在个人项目里感知不到，但在企业场景里是刚需。如果你在做ToB的RAG产品，这些是绕不过去的。 五、落地建议 5.1 先建评 测 体系，再谈优化 这是我最想强调的一点： 没有评 测 体系的RAG优化是在碰运气 。 很多人的做法是：上线 → 用户反馈不好 → 调参数 → 再上线 → 还是不好 → 继续调…… 问题是：你怎么知道调对了？用户说"不好"，是检索不准？还是回答不对？还是根本没理解问题？ 比跑指标更重要的是：自己看case，做错误分析。 作为AI产品经理，你至少得亲自看过100个case才能建立体感。不是看指标报告，是一个一个看：用户问了什么、检索到了什么、回答了什么、哪里出了问题。 看多了你会发现错误是有规律的： • 某类问题总是检索不到 → 可能是切块策略问题 • 检索到了但回答错 → 可能是上下文太长LLM没注意到 • 某个文档反复出问题 → 可能是解析有问题 错误分析比优化更重要 。知道错在哪，优化方向才清晰。 评测工具方面，LlamaIndex内置了 评测 模块，包含诸如：忠实度（Faithfulness）、相关性（Relevancy）、正确性（Correctness）、语义相似度（Semantic Similarity）等指标。 开源工具还有Ragas（专注RAG 评测 ）、DeepEval（更全面的LLM 评测 框架）、Arize Phoenix（观测平台）等。但工具只是辅助，核心还是你对case的理解。 评测 这块内容很多， 我准备单独写一篇展开 。 5.2 分阶段路线图 第一阶段：MVP（2 4周） 目标：跑通基础RAG，验证可行性 技术栈： • 向量检索：LlamaIndex VectorStoreIndex • 关键词检索：BM25 • 时效性过滤：文件日期 • 简单合并排序 交付物：能用的问答原型 第二阶段：优化（4 8周） 目标：提升准确率，加入高级能力 新增： • 实体识别（评分标准、技术要求） • 简单图谱（文档 评分项 案例） • 点击反馈学习 • 基于用户历史的个性化 关键动作： 建立 评测 体系，数据驱动迭代 第三阶段：进阶（可选） 目标：达到生产级水平 新增： • 完整知识图谱（项目 标段 评分规则 中标方案） • 多跳推理（类似项目的中标策略） • 自动更新图谱 前提：有足够的数据和工程资源 5.3 技术栈推荐 层级 推荐方案 备选 检索框架 LlamaIndex 向量库 Milvus / Qdrant pgvector 文档解析 LlamaParse MinerU 图谱（可选） Neo4j 评测 LlamaIndex内置 Ragas 层级 层级 推荐方案 推荐方案 备选 备选 检索框架 检索框架 LlamaIndex LlamaIndex 向量库 向量库 Milvus / Qdrant Milvus / Qdrant pgvector pgvector 文档解析 文档解析 LlamaParse LlamaParse MinerU MinerU 图谱（可选） 图谱（可选） Neo4j Neo4j 评测 评测 LlamaIndex内置 LlamaIndex内置 Ragas Ragas LLM选型不列了。原则很简单： 先用最强的模型（GPT/Claude/Gemini）把效果调到位，再考虑换便宜模型降成本 。别一开始就用小模型省钱，效果差了你都不知道是模型问题还是RAG问题。 5.4 常见坑 坑 说明 避坑方法 一上来就建知识图谱 过度设计，投入产出不划算 MVP先验证基础RAG 只用向量数据库 精度不够，无法精确匹配 混合检索（BM25+向量） 自己造轮子 浪费时间重复发明 用LlamaIndex 不做评测 就上线 不知道效果好不好 先建 评测 体系 忽视解析质量 垃圾进，垃圾出 先看解析，再调检索 坑 坑 说明 说明 避坑方法 避坑方法 一上来就建知识图谱 一上来就建知识图谱 过度设计，投入产出不划算 过度设计，投入产出不划算 MVP先验证基础RAG MVP先验证基础RAG 只用向量数据库 只用向量数据库 精度不够，无法精确匹配 精度不够，无法精确匹配 混合检索（BM25+向量） 混合检索（BM25+向量） 自己造轮子 自己造轮子 浪费时间重复发明 浪费时间重复发明 用LlamaIndex 用LlamaIndex 不做评测 就上线 不做评测 就上线 不知道效果好不好 不知道效果好不好 先建 评测 体系 先建 评测 体系 忽视解析质量 忽视解析质量 垃圾进，垃圾出 垃圾进，垃圾出 先看解析，再调检索 先看解析，再调检索 5.5 几句大实话 1. 解析是地基 ——效果不好先查解析，别急着换架构 2. 没有银弹 ——不同文档用不同工具，别指望一招鲜吃遍天 3. 先跑起来再说 ——从简单方案开始做起， 完美主义是RAG项目最大的敌人 4. 评测 比优化重要 ——没有 评测 体系，你根本不知道改对了没 写在最后 写完这篇，我最大的感受是： RAG没有银弹 。 市面上太多文章在推销某个框架、某个架构、某个神奇的技术，好像用了就能解决所有问题。但现实是，RAG的效果取决于一系列琐碎的决策：文档怎么解析、怎么切块、用什么向量模型、检索策略怎么配、重排序要不要加……每个环节都可能出问题。 如果非要总结几个最重要的认知： 1. 解析是门槛 ——做不好是0分，做好了是60分及格线 2. 检索是天花板 ——从60到90全靠这里，但调优是玄学 3. 评测是指南针 ——没有 评测 体系，优化就是碰运气 还有很多我没想清楚的问题，比如： • 评测体系怎么建才能真正反映业务效果，而不是自嗨？ • 多模态RAG在实际场景中的ROI到底怎么样？ • Agentic RAG的可控性问题怎么解决？ 如果你也在研究这些，或者有实践经验想分享，欢迎加我微信聊： Suda Lulu 独学无友，则孤陋寡闻。 参考资料 论文 • Retrieval Augmented Generation for Large Language Models: A Survey（RAG综述） • Agentic Retrieval Augmented Generation: A Survey on Agentic RAG（Agentic RAG综述） • LongRAG: Enhancing Retrieval Augmented Generation with Long context LLMs（长上下文RAG） • ColPali: Efficient Document Retrieval with Vision Language Models（多模态RAG） 产品文档 • LlamaIndex: https://docs.llamaindex.ai/ • LlamaCloud: https://cloud.llamaindex.ai/ • RAGFlow: https://ragflow.io/ • Glean: https://developers.glean.com/ 🔗 Source link: https://mp.weixin.qq.com/s? biz=Mz... https://mp.weixin.qq.com/s? biz=Mz... Original Suda探险家 苏打气泡档案2025年12月6日 19:48 广东 前言 RAG教程满天飞。随便搜一下，"手把手教你搭建RAG"、"10分钟跑通RAG"、"RAG最佳实践"……看起来很简单对吧？ 但真正上手就会发现：教程里的demo跑得飞起，换成自己的文档就拉胯。 为什么？ 因为大多数教程在教你 怎么跑通 ，而不是 怎么做好 。它们会告诉你用什么向量库、怎么调Top k、怎么写Prompt——但这些都是"能跑起来"的60分线，不是"效果好"的90分线。 我研究了一周RAG，发现真正决定效果的是两道坎： • 第一道坎：解析层 ——看得见的坎，你的文档有没有被正确解析 • 第二道坎：检索层 ——看不见的坎，检索策略的调优没有标准答案 解析层是门槛，做不好是0分；检索层是天花板，从60到90全靠这里。 这篇文章不是另一个"跑通RAG"的教程，而是我对这两道坎的理解，以及架构选型、框架对比、企业落地的判断。 有偏差欢迎拍砖。 一、第一道坎：解析层 大多数教程跳过这个环节，直接教你怎么切块、怎么检索。但如果文档解析就是错的，后面全白搭。 1.1 RAG七阶段Pipeline RAG系统可拆解为七个阶段： 阶段 核心任务 标准化程度 启动门槛 落地上限 核心痛点 1. 数据接入 连接数据源 中 中 中 工程繁琐。OA三巨头虽有API但取内容难；老旧私有系统（OA/ERP）基本靠定制或人工导出 2. 解析清洗 非标转结构化 极低 中 极高 决定成败。复杂PDF、表格、公式尚无完美解析方案，数据洗不干净，后续算法再强也是徒劳 3. 分块索引 语义切片 中 低 中 语义断裂。简单按字数切分会导致上下文丢失；引入语义切分成本较高 4. 检索策略 召回+重排序 高 低 极高 易学难精。跑通流程仅需几行代码，但要解决"查得准"（多跳推理/精确匹配）极度依赖调优 5. 上下文构建 提示词组装 中 低 中 窗口博弈。长文本下的"迷失中间"问题，随着长窗口模型普及，难度略有下降 6. 生成回答 LLM生成 极高 极低 低 同质化严重。调用通用大模型API即可，除特定行业微调外，各家能力差异不大 7. 效果评测 体系化验收 低 低 高 重建设轻验收。缺乏体系化的基准测试集，导致优化方向不明，迭代全凭体感 阶段 阶段 核心任务 核心任务 标准化程度 标准化程度 启动门槛 启动门槛 落地上限 落地上限 核心痛点 核心痛点 1. 数据接入 1. 数据接入 连接数据源 连接数据源 中 中 中 中 中 中 工程繁琐。OA三巨头虽有API但取内容难；老旧私有系统（OA/ERP）基本靠定制或人工导出 工程繁琐。OA三巨头虽有API但取内容难；老旧私有系统（OA/ERP）基本靠定制或人工导出 2. 解析清洗 2. 解析清洗 非标转结构化 非标转结构化 极低 极低 中 中 极高 极高 决定成败。复杂PDF、表格、公式尚无完美解析方案，数据洗不干净，后续算法再强也是徒劳 决定成败。复杂PDF、表格、公式尚无完美解析方案，数据洗不干净，后续算法再强也是徒劳 3. 分块索引 3. 分块索引 语义切片 语义切片 中 中 低 低 中 中 语义断裂。简单按字数切分会导致上下文丢失；引入语义切分成本较高 语义断裂。简单按字数切分会导致上下文丢失；引入语义切分成本较高 4. 检索策略 4. 检索策略 召回+重排序 召回+重排序 高 高 低 低 极高 极高 易学难精。跑通流程仅需几行代码，但要解决"查得准"（多跳推理/精确匹配）极度依赖调优 易学难精。跑通流程仅需几行代码，但要解决"查得准"（多跳推理/精确匹配）极度依赖调优 5. 上下文构建 5. 上下文构建 提示词组装 提示词组装 中 中 低 低 中 中 窗口博弈。长文本下的"迷失中间"问题，随着长窗口模型普及，难度略有下降 窗口博弈。长文本下的"迷失中间"问题，随着长窗口模型普及，难度略有下降 6. 生成回答 6. 生成回答 LLM生成 LLM生成 极高 极高 极低 极低 低 低 同质化严重。调用通用大模型API即可，除特定行业微调外，各家能力差异不大 同质化严重。调用通用大模型API即可，除特定行业微调外，各家能力差异不大 7. 效果评测 7. 效果评测 体系化验收 体系化验收 低 低 低 低 高 高 重建设轻验收。缺乏体系化的基准测试集，导致优化方向不明，迭代全凭体感 重建设轻验收。缺乏体系化的基准测试集，导致优化方向不明，迭代全凭体感 从这张表能看出什么？ 两个"极高"落地上限的环节： 解析清洗 和 检索策略 。这就是我说的两道坎。 另外注意 效果评测 ：启动门槛低，但落地上限高（认真做起来不简单）。大多数团队选择跳过，结果就是优化全凭体感，改了也不知道对不对。 1.2 为什么「解析」最难标准化？ 数据现实 ：大量企业数据仍以PDF、扫描件、富文本为主，结构混乱。 行业差异 ：不同领域有不同的复杂文档—— 行业 典型复杂文档 金融 财报、合同条款、嵌套表格 医疗 检验报告、多语言混排 技术 规格书、流程图、公式 行业 行业 典型复杂文档 典型复杂文档 金融 金融 财报、合同条款、嵌套表格 财报、合同条款、嵌套表格 医疗 医疗 检验报告、多语言混排 检验报告、多语言混排 技术 技术 规格书、流程图、公式 规格书、流程图、公式 技术栈复杂 ：解析不是单一技术，而是多层叠加——OCR → 版面分析 → 表格结构识别 → 领域规则 → 质量 评测 。还要处理页眉页脚、脚注、跨页表格、嵌套列表、编号错乱…… 结论 ：这不是按字数机械切分就能解决的问题。 1.3 商业化逻辑：为什么都在解析环节收费 三个字： 难、脏、贵 。 特征 说明 难 技术栈复杂，需OCR+版面+表格+多模态多管线协同 脏 需要大量标注数据、领域经验规则、后处理逻辑 贵 训练/微调多模态模型，构建数据处理流水线成本高 特征 特征 说明 说明 难 难 技术栈复杂，需OCR+版面+表格+多模态多管线协同 技术栈复杂，需OCR+版面+表格+多模态多管线协同 脏 脏 需要大量标注数据、领域经验规则、后处理逻辑 需要大量标注数据、领域经验规则、后处理逻辑 贵 贵 训练/微调多模态模型，构建数据处理流水线成本高 训练/微调多模态模型，构建数据处理流水线成本高 看看头部玩家怎么收费的 ： LlamaIndex推出的LlamaCloud，核心卖点就是LlamaParse——一个文档解析服务。定价模式很直接：按页收费，每页几美分。复杂文档（嵌套表格、扫描件、多语言）价格更高。 为什么客户愿意买单？因为价值主张极其清晰： • "你的PDF解析成一坨屎，我帮你解析成结构化数据" • "跨页表格、嵌套表格、扫描件，我都能处理" • "你自己搞需要养一个团队，用我的服务按页付费" 相比之下，"我们检索更聪明"、"我们重排序多加了一层"这种卖点，客户根本没感知。你说准确率提升5%，客户问：怎么证明？ 而且检索层的技术大多是开源标准方案——向量库有Milvus、Qdrant、pgvector，重排序有开源模型，混合检索也不是秘密。你能做的，别人也能做。没有技术壁垒，就很难收费。 这就是为什么解析层容易商业化，检索层不容易 。 1.4 对下游的影响：Garbage In, Garbage Out 解析质量对RAG效果的影响是 质变级别 的： • 表格解析错误 → 检索召回错误信息 → 生成答案胡说八道 • 跨页内容断裂 → 上下文不完整 → 回答片面或矛盾 • 格式丢失 → 层级关系消失 → 无法做结构化检索 一句话：解析是RAG的「地基」，地基歪了，上面盖什么都白搭。 解析层是RAG的 第一道坎 ——看得见的坎。 文档解析错了，一眼能看出来；解析对了，至少能拿60分。这道坎的特点是：难，但有解。砸钱砸人，总能搞定。 另外别忘了评测。大多数RAG项目死在"不知道哪里出了问题"，根本原因是没有评 测 体系。后面会专门讲这个。 60分到90分，靠的是下一道坎。 二、第二道坎：检索层 2.1 为什么检索层更难？ 解析层是工程问题，检索层是调优问题。 维度 解析层 检索层 难度类型 确定性的难 不确定性的难 特点 脏、累、但 有解 玄学、组合爆炸、 没有标准答案 评 测 容易（对不对一眼看出来） 困难（什么叫"检索好"？） 投入产出 砸钱能解决 砸钱不一定有用 维度 维度 解析层 解析层 检索层 检索层 难度类型 难度类型 确定性的难 确定性的难 不确定性的难 不确定性的难 特点 特点 脏、累、但 有解 脏、累、但 有解 玄学、组合爆炸、 没有标准答案 玄学、组合爆炸、 没有标准答案 评 测 评 测 容易（对不对一眼看出来） 容易（对不对一眼看出来） 困难（什么叫"检索好"？） 困难（什么叫"检索好"？） 投入产出 投入产出 砸钱能解决 砸钱能解决 砸钱不一定有用 砸钱不一定有用 检索层的痛苦在于： • Top k设多少？ 设3可能漏信息，设10可能引入噪音 • Chunk size怎么定？ 256还是512还是1024？没有标准答案 • 要不要Rerank？ 加了延迟上升，不加准确率差 • 混合检索权重怎么配？ BM25和向量各占多少？ 每个参数都能调，但调了也不知道对不对。80%的case好调，剩下20%的边界case能把人逼疯。 举个真实的例子 ： 用户问"Q3销售额是多少"，你的RAG返回了Q2的数据。为什么？ 可能是： • 向量相似度上，"Q3销售额"和"Q2销售额"几乎一样 • 恰好Q2那段内容更长、信息更密集，得分更高 • 或者根本就是解析问题——Q3的表格解析错了 你怎么判断是哪个环节出了问题？只能一层一层排查。而且修了这个case，可能又搞坏了另一个case。 这就是第二道坎： 看不见的坎 。你以为RAG跑通了，但效果就是上不去，又说不清问题在哪。 2.2 检索层的核心优化方向 好消息是，虽然没有银弹，但有一些成熟的优化方向。 2.3 Naive RAG：能用但局限明显 架构 ：文档 → 切块 → 向量化 → 向量库 → Top k检索 → LLM生成 适用场景 ：简单问答、小规模文档（<100篇）、原型验证 优势 ：实现简单，开源方案成熟，成本低 致命局限 ： 问题 说明 检索准确率低 语义漂移，"Q3财报"可能匹配到Q2、Q4 上下文碎片化 切块太小信息不足，太大检索不准 无法处理复杂查询 多跳推理（需要串联多个信息点才能回答）、对比分析搞不定 对文档结构无感知 层级关系、表格结构全丢失 问题 问题 说明 说明 检索准确率低 检索准确率低 语义漂移，"Q3财报"可能匹配到Q2、Q4 语义漂移，"Q3财报"可能匹配到Q2、Q4 上下文碎片化 上下文碎片化 切块太小信息不足，太大检索不准 切块太小信息不足，太大检索不准 无法处理复杂查询 无法处理复杂查询 多跳推理（需要串联多个信息点才能回答）、对比分析搞不定 多跳推理（需要串联多个信息点才能回答）、对比分析搞不定 对文档结构无感知 对文档结构无感知 层级关系、表格结构全丢失 层级关系、表格结构全丢失 2.4 Advanced RAG：三阶段优化 核心思路：在Naive RAG的基础上，针对 检索前、检索中、检索后 三个阶段做优化。 这里只列最常用的技术，实际上每个阶段都有大量变体和组合，论文层出不穷。不用全学，挑适合你场景的用。 检索前优化 技术 原理 解决的问题 查询改写 LLM改写用户问题，使其更适合检索 用户表达不清晰 查询扩展 扩展同义词、相关词 召回不全 查询拆解 把复杂问题拆成子问题，分别检索 复杂问题难以一次命中 HyDE 先让LLM生成假设性答案，用答案去检索 问题和文档的语义空间不匹配 技术 技术 原理 原理 解决的问题 解决的问题 查询改写 查询改写 LLM改写用户问题，使其更适合检索 LLM改写用户问题，使其更适合检索 用户表达不清晰 用户表达不清晰 查询扩展 查询扩展 扩展同义词、相关词 扩展同义词、相关词 召回不全 召回不全 查询拆解 查询拆解 把复杂问题拆成子问题，分别检索 把复杂问题拆成子问题，分别检索 复杂问题难以一次命中 复杂问题难以一次命中 HyDE HyDE 先让LLM生成假设性答案，用答案去检索 先让LLM生成假设性答案，用答案去检索 问题和文档的语义空间不匹配 问题和文档的语义空间不匹配 其他还有：查询路由（根据问题类型选不同检索器）、意图识别、查询分类等。 检索中优化 技术 原理 适用场景 层级检索 先检索文档摘要，再检索具体段落 多文档（100+） 句子窗口 用单句做检索，返回时扩展上下文 需要精确匹配+上下文 混合检索 BM25（关键词）+ 向量（语义）并行 需要精确匹配+语义理解 父子chunk 检索用小chunk，返回用大chunk（父chunk） 精确召回+完整上下文 技术 技术 原理 原理 适用场景 适用场景 层级检索 层级检索 先检索文档摘要，再检索具体段落 先检索文档摘要，再检索具体段落 多文档（100+） 多文档（100+） 句子窗口 句子窗口 用单句做检索，返回时扩展上下文 用单句做检索，返回时扩展上下文 需要精确匹配+上下文 需要精确匹配+上下文 混合检索 混合检索 BM25（关键词）+ 向量（语义）并行 BM25（关键词）+ 向量（语义）并行 需要精确匹配+语义理解 需要精确匹配+语义理解 父子chunk 父子chunk 检索用小chunk，返回用大chunk（父chunk） 检索用小chunk，返回用大chunk（父chunk） 精确召回+完整上下文 精确召回+完整上下文 其他还有：多路召回、向量模型微调、动态chunk策略等。 检索后优化 技术 原理 效果 重排序 用更精细的模型对检索结果重新打分 显著提升准确率 压缩 压缩检索到的上下文，去除冗余 减少token消耗 过滤 基于规则/模型过滤低质量结果 减少噪音 技术 技术 原理 原理 效果 效果 重排序 重排序 用更精细的模型对检索结果重新打分 用更精细的模型对检索结果重新打分 显著提升准确率 显著提升准确率 压缩 压缩 压缩检索到的上下文，去除冗余 压缩检索到的上下文，去除冗余 减少token消耗 减少token消耗 过滤 过滤 基于规则/模型过滤低质量结果 基于规则/模型过滤低质量结果 减少噪音 减少噪音 其他还有：结果融合、多样性优化、上下文重组等。 关键认知 ：这些技术不是越多越好。每加一层都有成本（延迟、复杂度、维护负担）。先把基础的做好（混合检索+重排序），再根据具体问题加对应的优化。 2.5 Modular RAG：从固定流程到可编排模块 核心思路 ：不再是固定的「检索→生成」流程，而是把RAG拆成 可插拔模块 ，自由编排。 关键特征 ： • 模块独立，可单独替换/升级 • 流程可编排（支持条件分支、循环） • 支持并行执行 适用场景 ：多类型查询需要不同处理流程、需要灵活实验不同组合、生产环境需要模块级监控 优势 ：灵活性高、便于A/B测试和迭代、模块级可观测性 劣势 ：架构复杂度上升、需要更多工程投入、调试难度增加 2.6 Graph RAG：知识图谱增强 核心思路 ：用知识图谱补充向量检索的盲区—— 实体关系和多跳推理 。 向量检索的盲点 举个例子：在一个企业知识库里搜「谁负责Project Titan？」 方式 过程 结果 向量检索 语义匹配 → 返回相关段落 方式 方式 过程 过程 结果 结果 向量检索 向量检索 语义匹配 → 返回相关段落 语义匹配 → 返回相关段落 可能返回项目介绍、项目进度，但就是没有负责人 知识图谱 查询 (人) [负责] (Project Titan) 直接返回：张三 为什么向量检索找不到？因为"张三负责Project Titan"这句话可能根本不存在于任何文档中。它是散落在各处的：组织架构图里有张三是PM，项目文档里有Project Titan的描述，但没有一句话把两者直接关联起来。 知识图谱的三大优势 优势 示例 多跳推理 「谁是Project Titan负责人的上级？」→ 张三 → 张三的汇报线 → 李总，一次查询搞定 实体消歧 公司有两个「李明」，根据部门、项目上下文匹配正确的那个 时间推理 「去年这个时候谁负责这个项目？」→ 带时间属性的关系 优势 优势 示例 示例 多跳推理 多跳推理 「谁是Project Titan负责人的上级？」→ 张三 → 张三的汇报线 → 李总，一次查询搞定 「谁是Project Titan负责人的上级？」→ 张三 → 张三的汇报线 → 李总，一次查询搞定 实体消歧 实体消歧 公司有两个「李明」，根据部门、项目上下文匹配正确的那个 公司有两个「李明」，根据部门、项目上下文匹配正确的那个 时间推理 时间推理 「去年这个时候谁负责这个项目？」→ 带时间属性的关系 「去年这个时候谁负责这个项目？」→ 带时间属性的关系 什么时候该用Graph RAG？ 适用场景： • 需要多跳推理（