RAG 的下一步不是查得更准，而是先想清楚再查

RAG 技术已经证明了它能帮大模型"查资料"。但如果目标不是回答问题，而是做决策呢？

比如一个制药公司需要决定关停哪座工厂、雇佣多少员工，才能既最小化生产成本又保证准时交付。传统做法是：人类制定分析计划，RAG 负责查数据，人类再做决策。最困难的部分，规划分析路径，始终落在人肩上。

PlanRAG 这篇论文想做的，就是把这个"规划"环节也交给 AI。

它的核心思路很直观：在做检索之前，先让语言模型生成一个分析计划。这个计划描述为了做出决策需要执行哪些数据分析任务，然后检索器根据计划去生成查询、拉取数据。如果第一次计划不够用，还可以重新规划。

听起来像是一个简单的流程调整，但效果很显著。在论文构建的 Decision QA 基准 DQA 上，PlanRAG 相比现有的迭代 RAG 方法，在定位场景中准确率提升了 15.8%，在构建场景中提升了 7.4%。

这个提升的来源，在于一个关键差异：传统 RAG 是"边查边想"，PlanRAG 是"先想再查"。前者在处理复杂决策问题时容易遗漏关键数据，论文数据显示，迭代 RAG 在超过 60% 的定位问题和 95% 的建筑问题中未能从数据库检索到任何结果。而 PlanRAG 通过先规划再检索，将遗漏率从 3.3% 降到了 1.3%。

当然，这还只是研究阶段的工作。论文也承认规划本身在复杂场景中仍然困难，特别是在需要多跳遍历的构建场景中。但方向已经清晰：当 RAG 从"回答问题"进化到"辅助决策"时，检索之前的规划环节可能是下一个真正的瓶颈。

对于正在搭建 RAG 系统的开发者来说，PlanRAG 的价值不在于照搬它的 SQL/Cypher 查询方案，而在于它揭示了一个容易被忽视的事实：检索策略的优劣，不只看你查到了什么，更看你查之前想清楚了什么。

RAG 系统的性能优化是一个系统工程。从文档处理到检索策略到生成融合，每个环节都可能成为瓶颈。文档切分是 RAG 的基础，切得太细检索精度高但上下文不完整，切得太粗上下文完整但检索精度低。实践中常用的策略是语义切分，根据文档的段落和标题结构来切分。检索策略的选择同样关键，纯向量检索无法处理精确匹配需求，全文关键词检索无法理解语义，混合检索可以兼顾两者。RRF 融合算法是目前最实用的混合检索结合方式，它不需要对两种检索的分数做归一化，直接基于排名位置做融合。Embedding 模型的选择直接影响检索质量，bge-m3 和 gte-qwen2 等中文优化模型可以让中文 RAG 系统的检索质量有明显提升。Reranker 可以在检索结果的 TOP-K 中做精排，尽管增加了系统复杂度和延迟，但对于需要高精度的场景来说，带来的提升是值得的。

技术的价值不在于它有多前沿，而在于它能在多大程度上解决实际问题。AI 技术的快速迭代不是用来追赶的潮流，而是用来解决业务痛点的工具箱。在实际应用中，有时候简单的方案反而最有效。一个 RAG 系统用了最复杂的检索策略但文档处理没做好，效果不如一个文档处理完善但检索策略简单的系统。一个 Agent 系统用了最贵的模型但 prompt 设计粗糙，效果不如一个精心设计 prompt 的普通模型。建议在追求技术先进性之前，先把基础工作做扎实。文档清洗、数据标注、评测体系、监控告警，这些看似基础的工作，往往是决定 AI 项目成败的关键。

在软件开发领域，有一条经验法则：任何在开发阶段看起来很聪明但让调试变得困难的做法，最终都不是好主意。这条法则在 AI 应用开发中尤其适用。AI 应用的不确定性比传统软件高得多，这意味着调试和排查问题的难度也大得多。因此 AI 应用的设计应该追求简单、透明、可追踪。简单意味着每个组件的职责清晰，组件之间的依赖关系明确。透明意味着系统的每个决策过程都可以被追溯和理解。可追踪意味着每次模型调用、每步推理过程都被记录在案。只有做到了这三条，你才能在系统出现问题时快速定位根因。

AI 项目的技术栈选择决定了开发效率和后期维护的成本。Python 是目前 AI 开发的主流语言，拥有最丰富的生态。TypeScript 在 AI 应用开发中也越来越流行，特别是在需要前后端一体化的场景中。选择技术栈时的核心原则是优先考虑团队熟悉的技术，减少学习成本。框架选择同理，LangChain 功能丰富但复杂度也高，直接调用 API 可能更可控。建议从最简单的方案开始，随着需求复杂度的增加逐步引入框架。过早的框架选择会让系统复杂度不必要地增加。