多轮检索与单次检索的成本对比，FDE 现场交付需要看什么

先说结论

• 单次检索（single-shot retrieval）在“多部分问题”上容易漏掉需要跨文档拼接的信息，而代理式检索（agentic retrieval）通过多次检索与推理能更好地处理这类问题。
• AWS 的这篇博客不只是讲效果，还明确让读者把同一查询分别跑两条路径，并对比各自的成本，这是 FDE 做交付评估时最该抓的两件事。
• 对 FDE 而言，真正可落地的动作是建立“问题复杂度分级 + 检索路径选择 + 成本基线”的现场流程，而不是盲目上 Agent。

背景

AWS AI 发布了一篇关于使用 LangChain 与 Amazon Bedrock Managed Knowledge Base 构建检索增强生成（RAG）应用的技术文章，核心主题是 Agentic retrieval with LangChain and Amazon Bedrock Knowledge Bases。文章展示了如何在同一查询上分别走“单次检索”和“代理式检索”两条路径，并对比两者的回答质量与成本。

对 FDE 来说，这篇内容最有价值的地方在于它把抽象的“Agent 更聪明”转化成了可复现的工程对比：跑同样的查询、读 trace events、看费用差异。这正好对应企业内 RAG 项目从 PoC 走向交付时最常被问到的三个问题——效果差在哪、为什么贵、值不值得换路径。

为什么对 FDE 重要

FDE 在现场交付时，客户往往只关心最终答案对不对，但真正决定项目成败的是检索路径的选择逻辑。单次检索在简单、单文档、事实明确的问题上表现稳定且成本低；而多部分、跨文档、需要推理拼接的问题，单次检索容易给出片面甚至错误的答案。代理式检索通过多步检索与中间推理弥补了这一缺口，但代价是更高的调用次数与更长的延迟。

这正是 AI Agent 企业部署 中反复强调的原则：Agent 不是默认选项，而是针对特定问题复杂度的工具。FDE 需要把这种判断变成可执行的流程，而不是靠直觉或销售话术。同时，这也与 Context Engineering 的理念一致——检索路径的选择本质上是对上下文构造策略的优化，不同的问题类型需要不同的上下文组织方式。

从职业角度，这类工程判断能力正是 FDE 职业路线 中高级工程师阶段的核心要求：能独立设计交付方案、量化效果与成本、并在客户现场做出有依据的技术取舍。

现场落地建议

不要一开始就全量上 Agent。先按问题复杂度给查询分级，再为不同级别选择检索路径，最后用 trace 与成本数据验证。

• 建立问题分级标准：区分单文档事实型、多文档拼接型、需要推理判断型三类问题，作为检索路径选择的输入。
• 跑对照实验：对典型问题同时执行单次检索与代理式检索，记录回答质量、延迟与成本，形成内部基线。
• 读 trace 而非只看结果：通过 trace events 定位哪一步检索失败或重复，这比单纯调提示词更有效。
• 把成本纳入 SLA：代理式检索的成本可能随问题复杂度非线性增长，需在交付前与客户明确预算边界。

风险与检查清单

• 效果风险：代理式检索在简单问题上未必优于单次检索，需避免过度设计。
• 成本风险：多步检索可能带来数倍于单次检索的调用成本，需在 PoC 阶段就测算。
• 延迟风险：多次检索与推理会显著增加端到端延迟，影响用户体验。
• 可维护性风险：Agent 路径的逻辑更复杂，需保留清晰的 trace 与日志以便现场排查。

常见问题

单次检索和代理式检索的区别是什么？

单次检索只执行一次检索并生成回答，适合简单、单文档问题；代理式检索会多次检索并结合中间推理，更适合多部分、跨文档的问题。AWS 的文章通过同一查询对比两者，说明代理式检索在多部分问题上表现更好。

FDE 在现场该如何选择检索路径？

建议先对查询按复杂度分级，再为不同级别选择路径，并用 trace 与成本数据验证。不要默认全量上 Agent，而应把代理式检索作为解决特定问题复杂度的工具。

代理式检索的成本会不会很高？

会。由于涉及多次检索与推理，成本可能显著高于单次检索。AWS 的文章明确建议对比两条路径的成本，FDE 应在交付前建立成本基线并与客户确认预算边界。

---

来源：AWS AI — Agentic retrieval with LangChain and Amazon Bedrock Knowledge Bases