RAG检索翻车？真正的问题藏在分块边界里

很多团队在做RAG时，习惯把注意力放在嵌入模型、向量数据库和检索算法上，却忽略了一个更基础、也更容易出问题的环节：文档分块。原文作者在长期观察生产系统后指出，RAG返回“技术上正确、上下文上无用”的结果，问题几乎总是出在分块或元数据，而不是嵌入模型。

一、“Agent”被滥用，工程决策跟着走偏

原文开篇就点出一个行业现象：函数调用工具叫Agent，带记忆的聊天机器人叫Agent，带循环的脚本也叫Agent。这种语义稀释不是小事，它会直接导致工程上的误判——简单流水线被过度设计，真正复杂的系统反而缺乏该有的架构。

作者给出的定义标准是：Agent应该拥有目标而非指令，能自主决定下一步、处理失败、判断任务何时完成。如果每一步都需要人来告诉它怎么做，那只是聊天界面；能从工具调用失败中恢复并换一条路，才算入门；能把目标拆解成子任务并分派，才是真正的Agent。

这一定义的价值在于，它帮团队在动手前先判断：我到底需不需要Agent？很多工作流用一个结构良好的提示词就能解决，硬加编排层只会增加维护成本。

二、生产环境里的Agent，其实都很“窄”

原文对真实部署情况的描述相当克制：大多数Agent落地场景都很窄——客服工单分流、文档抽取、特定代码库的代码审查。它们不是通用推理引擎，而是带有智能决策层的目的性流水线。

做出效果的团队，关注点不在追最新模型，而在三件事：工具设计是否干净、失败处理是否到位、可观测性是否能追溯决策路径。反之，效果差的团队往往是把GPT-4换成最新前沿模型，其他什么都不改，然后期待行为发生变化。

这个观察和RAG的问题是相通的：模型只是系统中的一个部件，系统行为由架构决定，而不是由模型版本决定。

可观测性（Observability） 在Agent系统中指能够追踪和还原一次任务执行的完整决策路径，包括每次工具调用的输入输出、模型推理的中间步骤、失败重试的原因等。它不同于传统日志：日志记录“发生了什么”，可观测性则要回答“为什么这样发生”。对Agent而言，由于行为由模型动态决定，缺乏可观测性就意味着无法定位幻觉、死循环或工具误用的根源。常见实践包括为每次运行分配追踪ID、结构化记录每一步的上下文快照、以及将决策路径可视化。没有可观测性的Agent系统在生产环境中几乎无法调试和信任。

三、框架之争是噪音，模式才是资产

LangChain、LangGraph、CrewAI、AutoGen、Semantic Kernel——几乎每个月都有新框架出现，也总有人写文章宣布旧框架已死。原文作者的态度很明确：框架没有模式重要。

他反复验证有效的几个模式包括：

• 先规划再执行：一个推理步骤产出计划，另一个执行步骤按计划走，两者不要混在一起。
• 检索与推理分离：取上下文和使用上下文是两件事，混在一起系统就会混乱。
• 显式交接：Agent之间传递工作时，交接应当是结构化且可记录的，而不是通过提示词传一个字符串。

作者提到自己用三种不同框架重建过同一套架构，结果基本一致。框架是脚手架，架构才是建筑本身。这个判断对正在选型的团队有直接参考价值：与其纠结框架，不如先把模式定下来。

显式交接（Explicit Handoff） 是多Agent协作中的一种设计模式：当一个Agent将任务转交给另一个Agent时，交接内容应当是结构化的数据对象（如包含任务描述、已完成步骤、待办事项、约束条件的JSON），而不是一段自由文本提示词。结构化交接的好处是可验证、可记录、可回放——接收方Agent能明确知道前序状态，系统也能在出问题时追溯是哪一次交接丢失了信息。相比之下，通过提示词传字符串的隐式交接容易在传递过程中丢失关键约束，且难以自动化检查。这一模式与“检索与推理分离”一脉相承，核心都是把隐含假设显式化。

四、RAG的真正病根：分块边界

这是全文最核心的部分。RAG已经是涉及专有数据的生产AI系统的标配，但教程很少讲清楚一个问题：分块边界是错的。

把文档切块并嵌入时，你实际上在对“哪些上下文属于一起”做假设。这些假设经常不成立。一个只有结合上一段才能读懂的段落，被孤立检索出来后，模型就会幻觉出缺失的上下文。

原文给出的改进路径分三层：重叠窗口、语义分块、父文档检索等更好的分块策略能缓解问题；但真正的修复是重新思考存储内容——有时该存的不是原始文本，而是信息的结构化表示；而如果你发现RAG返回的结果“技术上正确但上下文无用”，问题几乎肯定在分块或元数据，不在嵌入模型。

这一判断值得所有RAG团队自查：换嵌入模型之前，先看看分块策略和元数据设计。

语义分块（Semantic Chunking） 是一种基于内容含义而非固定字符数切分文档的策略。常见做法是先对相邻句子或段落计算嵌入向量的相似度，当相似度低于某个阈值时视为主题边界，在此处切分。相比固定长度窗口，语义分块能让每个块内部主题更连贯，减少“半句话被切断”或“跨主题混装”的情况。但它并非银弹：阈值选择依赖经验，计算成本更高，且相似度突变不一定对应真正的语义边界。实践中常与重叠窗口结合使用，并配合元数据标注块的来源章节，以便检索后能回溯补全上下文。

父文档检索（Parent Document Retrieval） 是另一种缓解分块边界问题的方法。其思路是：用较小的子块（如句子级）建立索引以保证检索精度，但返回给模型的是该子块所属的更大父块（如整节或整段）。这样既避免了长块嵌入稀释语义，又保证了生成时拥有完整上下文。实现上通常需要维护子块到父块的映射关系，并在检索后做一次聚合去重。父文档检索特别适合技术文档、法律合同等结构清晰但上下文依赖强的材料。

五、未来的竞争力：可维护、可信赖的系统

原文对未来趋势的判断很朴素：模型会继续变好，上下文窗口会继续扩大，每token成本会继续下降。但这些都不改变根本的工程挑战——构建一个在没人盯着时也能正确行事的系统。

作者认为值得解决的问题是治理、可观测性和可靠的工具调用，而不是追榜单。两三年后真正重要的工程师，是能构建其他工程师可以维护和信任的AI系统的人。这是一种更接近系统设计、而非模型研究的能力。

原文还顺带提到几条行业动态：Anthropic承诺将5%股份投入“公共利益基金”；迪士尼同意雇用Character.AI的大部分员工；Meta删除了引发爬取和AI训练担忧的条款措辞。这些动态本身不改变上述工程判断，但反映了AI行业在治理和人才流动上的持续变化。

对正在做RAG或Agent系统的团队来说，这篇文章的价值不在于给出新工具，而在于把注意力拉回到那些不性感的环节：分块、元数据、失败处理、可观测性。这些才是决定系统能不能被信任的地方。