从RAG到数据资产：如何打造可落地的企业级 Agent 知识底座？

本文为社区作者个人技术实践与思考分享，仅供参考，不构成官方意见。

过去几年，RAG 几乎成为了 AI 应用在企业内落地的核心路径之一。

在面向产品手册、规章制度、FAQ 和项目资料的问答场景中，这套架构依然有效。但随着 Agent 开始参与数据分析、故障排查、业务决策和跨系统操作，企业需要处理的已经不只是“从一批文档中找到相关段落”。

用户可能会询问一项指标的实时数值，也可能要求系统解释指标口径、追溯数据来源、判断数据质量，再调用业务系统完成后续操作。一次请求涉及的上下文，可能同时分布在数据库、数据仓库、文件系统、数据开发任务和业务应用中。

这时，传统的“切块、向量化、召回、生成”仍然可以承担一部分知识检索，但很难独立完成整个任务企业知识应用的核心问题，也因此从文档检索逐渐延伸到了数据发现、理解、治理和调用。

当 Agent 进入真实业务，RAG 为什么不够用了？

传统 RAG 通常将文档切分为若干文本块，通过向量检索召回语义相似的内容，再交给大模型组织答案。这套方法的效果高度依赖文档解析、切分策略、召回质量和上下文组织。

问题在于，企业数据并不天然适合被处理成一组彼此独立的文本块。

一份制度文件中的定义、适用范围、例外条件和执行要求，可能分布在不同章节；一张数据表的真实含义，则依赖字段说明、统计口径、上下游血缘和使用场景。内容一旦被切分成相对独立的文本块，原有的章节关系和业务关系就可能难以完整保留。

其次，语义相似并不等同于业务相关。

名称相近的两张数据表，可能分别承载原始明细与加工后的汇总结果；包含相同指标名称的两份材料，也可能对应不同时间、版本或计算口径。仅根据向量距离召回内容，无法充分判断哪一项数据更权威、更新、更适合当前问题。

更现实的问题是，企业中的很多答案并不存在于文档里。

客户所处的当前阶段需要查询 CRM，最新库存需要访问业务数据库，实时经营指标需要查询数据仓库，审批条件则应当交给规则引擎判断。将这些内容定期导出成文件再建立索引，往往会产生新的数据副本，也可能引入更新延迟和口径偏差。

复杂问题会进一步放大这些矛盾。

越来越多的行业实践正在将检索从一次固定召回，扩展为由模型根据任务拆解问题、访问多个知识源并持续判断证据是否充分的过程。例如，微软的 Agentic Retrieval 会将复杂问题拆解为多个子查询，并行访问一个或多个知识源，再将内容、引用和检索记录统一返回；它所构建的知识层也强调知识的复用与权限感知。

但检索策略的升级，只解决了“如何找到信息”的一部分问题，在业务落地的过程中，难免还要回答这些问题：

• 哪些数据可以被检索；
• 数据的业务含义和责任主体是什么；
• 当前内容是否完整、准确和有效；
• 不同资产之间存在怎样的关系；
• 用户或 Agent 是否具备访问权限；
• 数据变化后，相关索引和应用如何及时更新。

这些问题都指向同一个基础条件：企业需要先将分散的数据转化为可管理、可理解和可使用的数据资产。

不同的数据，需要更定制化的访问方式

面对这些问题，行业内并没有出现一种可以简单替代 RAG 的单一方案。更实际的做法，是根据数据形态和任务目标组合不同的访问方式。

检索开始具备任务规划能力

面对多条件、多文档和多跳问题，AgenticRAG 应运而生。

AgenticRAG 研究为模型提供搜索、定位、打开文档和摘要等工具，使模型能够根据已有证据决定是否继续检索，而不是只使用第一次召回的固定候选集。实验中，性能提升的主要来源也不是更换嵌入模型，而是从单次检索转向可迭代的工具调用。不再完全依赖用户原始问题与文本块之间的一次相似度计算。

结构化数据开始直接查询

实时指标、客户状态、订单明细和设备数据，本身已经以结构化形式保存在数据库或数据仓库中。将它们批量转成文本并建立向量索引，不但增加数据副本，也容易产生更新延迟和口径偏差。

以 Amazon Bedrock Knowledge Bases 为例，他们已经尝试将结构化数据源纳入知识库架构。系统可以根据数据库结构，将自然语言转换为 SQL，直接查询原始数据，而不需要先将表数据转换为向量。生成的 SQL 还可以独立插入后续工作流。

数据关系开始进入检索过程

向量检索擅长查找语义相似内容，却不擅长稳定表达实体之间的确定关系。

对于跨实体和跨系统关系明确的问题，知识图谱、数据血缘和语义关系可以提供更稳定的查询路径。它们不只回答哪些内容“看起来相似”，还可以表达客户与合同、指标与数据表、数据表与加工任务之间的确定关系。

企业级 Agent 需要一套可治理的数据访问体系

当数据访问方式逐渐多样化，一个更基础的问题开始显现：无论上层使用 RAG、SQL、图查询还是业务 API，Agent 都必须先知道企业拥有哪些数据，以及这些数据意味着什么。

一张表只有名称和字段，并不足以帮助模型判断其业务用途；一份文件只有正文，也不足以说明它是否为当前生效版本；一项指标如果缺少口径、负责人和加工链路，即使能够被准确检索，也可能被错误使用。

因此，企业级 Agent 所需要的数据基础，至少应当具备几个条件。

首先，数据能够被统一发现。数据库、数据仓库、文件系统和多模态内容虽然保存方式不同，但应具备统一的资产目录和查询入口。

其次，数据能够被正确理解。技术结构之外，还需要业务定义、分类标签、责任主体、版本信息、上下游关系和使用情况。

再次，数据具有可以判断的可信状态。完整性、准确性、一致性和时效性等信息，应当成为数据使用时可以参考的属性，而不仅是治理部门的离线报告。

最后，数据访问需要继承企业既有的安全规则。用户和 Agent 能够看到什么内容，应由数据权限、分级分类和脱敏规则共同决定，而不是在每个智能应用中重新建立一套独立控制逻辑。

从近期行业产品的发展方向来看，可以将这一工程思路概括为：

先将分散的数据转化为可发现、可理解、可治理的资产，再由 Agent 根据任务选择合适的访问方式。

这也让元数据管理与企业 Agent 之间建立了更加直接的联系。

袋鼠云如何将数据资产能力带入 Agent 场景

袋鼠云元数据资产平台对结构化数据和非结构化数据进行统一管理，并将元数据管理、数据质量、数据安全和持续治理整合到同一套资产体系中。

它所解决的，正是企业数据进入 Agent 和智能应用之前的资产化问题。

统一盘点分散的数据资产

平台可以接入企业的数据仓库和业务数据库，采集库、表、字段等元数据，并通过数据地图提供统一查询入口。

用户可以在同一位置查看表结构、业务元数据、数据预览、版本变更、任务依赖和血缘关系，降低找库、找表和理解数据的成本。

对于企业 Agent，这些信息能够为数据源选择提供比字段名称更完整的依据。例如，在生成 SQL 前，系统不仅可以获得候选表，还可以参考表的业务说明、加工链路和维护情况。

管理并解析多模态非结构化数据

平台支持文本、图片、音频和视频等多种数据类型，提供文件上传、下载、编目、标签和数据集管理能力。

在检索层面，平台能够综合查询文件名称、目录、标签等元数据，也能查询文件内容和元数据语义；经过内容解析和向量化解析后，还可以提供面向多模态数据的综合查询能力。

这些能力可以为企业文档检索、多模态知识发现和后续 RAG 应用提供经过组织的数据来源，而不是直接面对散落在不同存储中的原始文件。

用元数据补充数据的业务含义

平台通过元模型约定不同资产需要维护的元数据信息，并支持维护技术元数据、业务元数据和管理元数据。

除资产名称和字段结构外，平台还能够关联血缘、质量、版本、任务和使用情况，使数据从一个技术对象转化为具有业务解释的数据资产。

在 Agent 场景中，这些元数据既可以参与搜索和过滤，也可以作为模型理解数据、选择工具和解释结果的上下文。

将质量和安全要求落实到数据层

平台支持事前规则配置、事中质量校验和事后分析报告，对数据的完整性、准确性、规范性、唯一性和一致性进行评估。

在数据安全方面，平台支持数据源、数据库、数据表以及行列级权限分配，同时提供数据脱敏和分级分类能力。

对于需要接入内部核心数据的 Agent，这意味着数据在进入检索、查询和分析链路之前，就已经具备相应的质量状态和安全属性。

让 AI 参与数据理解和治理

平台已经在数据地图、数据质量和任务运维中引入大模型能力。

它能够根据建表语句分析数据表的含义和用途，通过自然语言辅助生成数据质量 SQL，并对元数据同步和质量任务日志进行智能解析。

这些功能直接作用于数据理解和治理流程：一方面降低开发者认识陌生数据的成本，另一方面提高规则配置和故障排查效率，使数据资产能够更快进入后续使用环节。

这些能力共同构成了袋鼠云元数据资产平台在 Agent 场景中的核心价值：

让不同形态的企业数据能够被统一发现，让数据的业务含义和关联关系能够被理解，并让质量与安全要求进入实际的数据调用过程。

从企业实践中，理解元数据资产平台适合解决什么问题

袋鼠云元数据资产平台已经在金融、制造等企业客户内部形成了较为充分的实践。这些项目的建设目标虽然不完全相同，但普遍围绕几个问题展开：数据分散、口径不统一、查找和溯源困难、质量问题定位链路长，以及权限和敏感数据缺乏统一管理。

结合这些实践，可以更具体地理解它在智能应用中的使用方式。

**当企业希望建设数据 Agent 或智能分析助手时，**平台可以帮助 Agent 查找正确的库、表和字段，并利用业务元数据、血缘和质量信息辅助数据源选择与 SQL 生成。

**当企业需要建设内部知识检索和 RAG 应用时，**平台可以统一管理文档、多模态文件、标签、目录和数据集，为上层检索系统提供经过整理和治理的数据来源。

**当企业积累了大量文本、图片、音频和视频，希望为模型开发或多模态应用准备数据时，**平台可以承担资产盘点、文件解析、编目和数据集组织工作。

**对于金融、制造、政企和大型集团等对数据质量、安全与可追溯性要求较高的组织，**平台还可以将质量校验、血缘分析、权限管理和数据脱敏纳入同一条资产管理链路。

这些场景并不要求企业首先建设一个庞大的通用知识库。它们共同关注的是：在数据真正被智能应用使用之前，先把数据的结构、语义、关系和边界整理清楚。

随着 Agent 开始处理更复杂的企业任务，数据接入方式也在发生变化。

文档内容仍然需要检索，实时指标需要查询数据库，确定关系需要通过图结构或血缘表达，业务状态和操作则需要连接具体系统。不同技术解决不同问题，但它们都依赖一套稳定的数据基础。

元数据资产平台的作用，正是将分散的数据转化为能够被发现、理解、验证和安全使用的企业资产。

在这个基础之上，RAG、Text-to-SQL、知识图谱和工具调用才能不只是展示模型能力，而是更可靠地进入真实业务流程。