实地笔记：Agentic RAG 如何处理企业数据

一位客户发送了一张支持工单。 他们询问过去某个项目中特定服务器的保修详情。 他们还需要合同条款和当前的售后联系人。

回答这个问题很难。它需要来自四个不同地方的数据：

  • CRM，用于获取客户历史记录。
  • ERP，用于获取合同条款。
  • 资产管理系统，用于获取序列号。
  • HR 系统，用于获取员工详情。

这些系统使用不同的数据库和不同的权限。 标准的 RAG 在这里会失效。它只进行一次搜索，如果找不到内容就会放弃。

Agentic RAG 通过将检索转化为一个计划来解决这个问题。 它不仅仅是搜索。它会思考、行动并检查自己的工作。

以下是其工作流程：

  1. 编排器 (The Orchestrator) 系统将问题分解为子任务。它会识别应使用哪些数据源，以及哪些任务依赖于其他任务。

  2. 查询重写器 (The Query Rewriter) 每个系统使用的“语言”都不同。有的需要 SQL，有的需要关键词搜索。重写器会将用户的问题翻译成适合每个工具的正确格式。

  3. 并行检索 (Parallel Retrieval) 系统同时查询多个数据源。它必须遵守安全规则：AI 只能访问特定用户有权查看的数据。

  4. 充分性检查器 (The Sufficiency Checker) 这是最重要的部分。系统会询问：“这些信息足以回答问题吗？” 如果缺少某些信息（例如某个特定的 PDF 附件），系统不会停止。它会创建一个新计划来寻找该特定文件。它会不断循环，直到掌握完整的信息。

  5. 综合 (Synthesis) 最终的 Agent 会收集所有片段，并构建一个带有来源的单一、准确的答案。

Agentic RAG 并非万能灵药。它比传统的 RAG 更慢，成本也更高。

对于单个数据库中的简单问题，请使用传统的 RAG。 对于跨多个系统的复杂、多步骤问题，请使用 Agentic RAG。

目标是从简单的“查询-响应”模型转向有状态的工作流： 计划。执行。评估。迭代。

来源：https://dev.to/luhuidev/field-notes-how-agentic-rag-handles-the-real-mess-of-enterprise-data-a68

可选学习社区：https://t.me/GyaanSetuAi