找回密码
立即注册
搜索
热搜: Java Python Linux Go
发回帖 发新帖

3801

积分

0

好友

560

主题
发表于 昨天 04:19 | 查看: 18| 回复: 0

一、 Data Agent的现状与挑战

Datus AI 是一个开源的数据工程智能体(Data Engineering Agent)项目,开源约两个月,已在 LinkedIn、Expedia、Coinbase 等海外企业开展测试,国内也有多个大型客户上线相关业务。

Data Agent失败原因分析

Data Engineering Agent 在生产环境的大规模落地面临多重现实挑战。传统上依赖 RAG(检索增强生成)与固定工作流的方法,虽然在特定场景下有效,但其泛化能力有限,难以应对复杂多变的业务需求。真实的数据仓库环境中,存在着大量“隐藏”在工程师和分析师头脑中的领域知识,这些隐性知识如果无法被有效提取和形式化,那么问题的准确定义和结果的可靠评估都无从谈起。此外,建立一个能够持续从人工纠正和多轮交互中学习进化的反馈与在线学习闭环,是稳定交付价值的核心难点。

针对这些痛点,Datus 项目的目标并非构建另一个通用对话式 Data Agent 或 Chat BI 工具,而是将创新核心聚焦于可迭代的上下文工程(Context Engineering)。其开源产品形态类似于“面向数据工程师的 Copilot”,旨在构建一个专为数据服务、可持续增强的 Data Context 体系,为智能体在实际工作流中的可靠运行与持续优化提供坚实支撑。

从SQL Writer到Context Engineer

在 AI 时代,数据工程的工作范畴已显著扩展。它不再仅仅是构建数据仓库、进行表转换并最终交付静态仪表盘。如今,数据工程师的工作需要同时支撑多种新型需求:既要为人类用户提供自然语言查询接口,也需要为其他智能体提供 API 服务,还要将已有的指标与语义层与各类 BI 工具对齐。

行业正在推动语义层的标准化建设,以解决各公司或业务领域“黑话”向标准化 SQL 转换的难题。因此,数据工程师的核心任务正从单纯的 SQL 编写者,转变为为 AI 系统构建高质量、可演化的数据上下文的关键角色。

这里的核心挑战在于,如何从历史 SQL、交互反馈等环节中持续提取有价值的元数据与语义信息,来构建并迭代这一上下文。当前的工作流需要同时服务于人类和后续的智能体,因而融合了更多“人在回路”(Human-in-the-loop)的交互式体验,其形态更像为数据工程量身打造的 Copilot 工具。

二、 Datus 系统设计架构

Datus系统架构图

Datus 系统的整体架构分为多个层次:

  • 适配器层 (Adapter Layer)
    系统底层是适配器层,支持接入多种大语言模型(LLMs)、数据仓库、元数据目录服务、语义层及 BI 工具。例如,已实现与 Snowflake、StarRocks、Trino、Redshift 等数据源的连接,部分由开源社区贡献。该层也支持与 Polaris 等元数据目录,以及类似 Metric Flow 的开源语义层集成,并可对接企业内部自定义的指标平台。

  • 核心上下文引擎 (Core Context Engine)
    架构的核心是上下文引擎,它负责整合元数据、指标定义、历史 SQL、文档及成功案例,构建统一的数据上下文。该引擎通过一套标准化的工具接口(Tools Spec)向上层提供能力。

  • 设计哲学:智能体原生循环 (Agentic Loop)
    在实现路径上,系统选择了更偏向智能体(Agentic)的交互范式,而非固定的预定义工作流。核心决策逻辑是:随着底层大语言模型能力的持续进化,智能体多轮规划与决策的方式更能充分“复用”模型能力提升带来的红利,具备更强的适应性与成长性。尽管单次执行耗时可能略高于预定义工作流,但对数据工程任务而言,能否最终可靠地解决问题是更关键的效率指标。

  • 工具与集成形态
    系统以 Datus CLI 命令行工具为主要载体,为数据工程师提供类似 Copilot 的编码辅助体验。同时,它支持创建面向特定业务场景的子智能体(Sub-Agent)。这些子智能体可作为聊天机器人嵌入到 Superset 等 BI 工具的侧边栏中,供数据分析师交互使用,并在此过程中收集反馈。

  • 核心资产与反馈闭环
    系统的核心资产是持续演化的数据上下文。其结构体现为两棵树:目录树 与 主题树。整个系统的目标是不断积累高质量的上下文,并通过集成丰富的子智能体与反馈闭环,实现上下文质量的持续迭代与提升,从而支撑实际的数据工程工作。固定的工作流在特定场景仍有其价值,系统会在未来版本中予以辅助支持。

上下文工程是核心

Datus 系统通过两棵树形结构构建其核心数据上下文:

  • 目录树 (Catalog Tree)
    目录树是底层数据目录(数据库、模式、表、视图、物化视图等)的结构化映射。在此基础上,系统通过 AI 或人机协同的方式,为这些数据对象生成语义模型,明确其维度、指标定义及常用注释。

  • 主题树 (Subject Tree)
    主题树按业务域进行组织(如一级/二级主题),其叶节点承载具体的指标、可参考的 SQL 模板以及相关的知识文档。指标可定义为 YAML 并通过稳定 API 暴露,直接提供查询结果或可复用的 SQL;参考 SQL 则为特定 ETL 场景提供范例。

  • 构建方式与优势
    与传统 RAG 或手工维护 Schema 的方式不同,该系统从历史 SQL、仪表盘等来源自动提取信息来构建并迭代上下文。最终,它提供一套标准化的工具集,专门服务于大语言模型,以支撑上层的数据工程智能体。这一过程涉及到对大数据技术栈的深度理解和应用。

三、 交互式上下文工程实践

交互式上下文工程

Datus 系统通过以下流程构建和利用数据上下文:

系统在初始化知识库时,支持多种灵活的方式。核心方法是通过内置的 Agent 自动读取历史 SQL,从中提取表结构、数据样本及参考 SQL,并将其存储于一个基于向量数据库(支持混合检索)的知识库中。同时,系统会自动将这些信息组织成结构化的上下文树,并添加标签与摘要,便于大语言模型在特定场景下进行精准检索。

此外,如果历史 SQL 包含完整的注释或问题描述,系统可以进一步从中抽取指标定义,并将其存储为 YAML 文件或向量索引。用户也可以通过命令行工具或交互界面,手动编辑或生成单个指标,以人机协同的方式持续优化数据上下文。

完成构建后,这些结构化的上下文即可提供给大语言模型,用于可靠地执行数据查询与转换任务。

内置评估框架证明准确性

Datus 项目内置了一套针对自然语言转 SQL(NL2SQL)的基准测试与评估框架。测试数据表明,在完全无上下文的情况下,大语言模型自由生成的 SQL 经过多轮尝试,平均准确率仅约为 50%。而在通过系统自动初始化并引入历史 SQL 与指标作为上下文后,准确率可显著提升至 80% 以上。

为进一步提升效果,框架支持并行测试与运行时一致性检查策略(类似于测试时增强技术)。通过让模型对同一问题生成多个候选答案并进行比对,可以在消耗额外计算资源的代价下,换取更高的最终准确率。这套评估框架为衡量和优化数据工程智能体的核心能力提供了基础工具。

基于评估的反馈循环

该系统致力于通过自动化的反馈循环提升准确性,减少对人工调优的依赖。其核心逻辑是基于评估结果对问题进行自动分类:部分问题始终正确,部分始终错误,部分结果则在波动。针对始终错误的案例,通常归因于上下文信息不足或语义模糊。

系统采用基于评估的反馈机制:让大语言模型对同一问题多次生成回答,并引导其自我比较正确结果与错误结果之间的差异,从中抽取出新的知识片段(例如特定的 JOIN 逻辑、空值处理规则或业务约束)。这些知识通过智能体循环被提炼后,可自动补充至上下文知识库中。

实际测试显示,在无外部知识的基准下,44 个测试案例的准确率为 26%;提供经过精准匹配的知识时,准确率可超过 90%;而通过更贴近真实场景的上下文检索方式,准确率虽略有下降,但仍处于可用水平,且抽取的知识本身具备清晰的业务语义逻辑。

对于大概率能做对的问题,可通过运行时一致性校验(Runtime Consistency)来进一步提升准确率;对于正确率波动的案例,本质上是强化学习(如从“尝试一次”逼近“尝试多次”)可以优化的范畴;而对于始终无法做对的难题,仅靠强化学习难以解决,其根本仍依赖于上下文的补充与完善。这些技术探索与人工智能领域的前沿方向紧密相关。

从Dashboard到Agent的用例

该系统支持从用户现有的 BI 报表(如 Superset Dashboard)中自动抽取知识,以丰富上下文。仪表盘中蕴含着业务分析师已梳理清晰的宝贵业务逻辑,例如核心指标的定义、表关联经验、关键筛选条件及下钻路径。这些逻辑与经过生产验证的 SQL,是构建高质量上下文的重要来源。

最新版本的系统能够自动解析 Dashboard 链接,识别其中的数据表、图表构成,并提取每个图表背后的 SQL 语句。更进一步,系统可以从这些 SQL 中自动抽取出公共的指标与维度定义,将其转化为结构化的知识,汇入统一的上下文引擎,供智能体在生成查询时参考使用。这降低了对大语言模型凭空编写准确 SQL 的依赖,提升了输出的可靠性与业务贴合度。

开源的边界与价值

Datus AI 项目的核心开源价值在于构建标准化的工具生态与可共享的智能体经验

当前市场缺少专为数据工程师设计的 AI 编码工具,这构成了一个明确的机会。更深层的开源动机在于,统一与规范化大语言模型所需调用的工具接口至关重要。如果连接数据库、查询元数据与指标的工具定义杂乱不一,将严重阻碍模型的理解、泛化与后续的训练优化。

数据领域缺乏像 GitHub 那样丰富、复杂的公开任务库来驱动智能体能力的持续进化。因此,开源项目可通过定义一组通用、规范的 “Tools Spec”,为整个领域的工程化与模型训练奠定基础。在此之上,社区可以共享和复用针对不同场景的子智能体与技能(Skill)模板,使各数据团队的经验得以沉淀和流通。

项目团队计划围绕此开源核心,提供 CLI 及 IDE 扩展等工具,并在国内专注于开源生态建设。

上下文树的搜索与列表工具

Datus AI 开源项目的核心价值之一,在于为数据工程领域提供了一套标准化的工具接口格式,专门服务于大语言模型。该设计借鉴了 Copilot 等代码助手的交互模式,主要提供 list(列表)和 search(搜索)两类标准化工具,使模型能以类似操作文件系统的方式,自然地探索和调用数据资产。

项目将分散的数据指标、参考 SQL、表结构等信息,统一组织成树形结构进行管理,这种形式对大语言模型而言更易于理解和导航。在工具调用层面,系统内置了自适应的上下文压缩机制,会根据返回结果的大小进行动态压缩,并为每个结果提供简版摘要与完整内容,以优化令牌(Token)使用效率。

此外,系统支持基于内置向量索引的检索接口,可实现文本与元数据的混合搜索。整个上下文体系可由 AI 自动生成,也支持人工交互式编辑。这套标准化的“Tools spec”旨在提升大语言模型与数据基础设施交互的规范性、效率与泛化能力。

子代理系统架构

Sub-Agent 系统的实现逻辑

该系统的底层由多个 Sub-Agent(子代理)构成。每个 Sub-Agent 的核心可视为 Tools(工具)、MCP 协议 与 Skills(技能)三者的统一。对大语言模型而言,它们都是可调用的工具。具体来说:

  • Skills 本质上是一种特殊封装的工具,它提供了一种更优的上下文加载与结构化描述手段,使模型能通过多轮工具调用来探索和执行复杂任务。
  • MCP 则是一层底层协议标准。

关键设计:Scope Context(作用域上下文)
系统虽然维护着全局的目录树和主题树,但具体业务场景通常只需其中一部分表、指标和知识。因此,通过定义 Scope Context,即从全局树中选择相关的子树或节点,并结合业务规则与系统提示词,即可快速构建出面向不同场景的专用 Sub-Agent。这种 Scope Context 机制是实现灵活、高效子智能体的核心,也为后续的强化学习(RL)等优化提供了明确的环境边界。

子代理配置示例

该系统通过可灵活配置的 Sub-Agent(子代理)来实现不同场景的精准支持。每个子代理在底层体现为一组特定的工具集,并可通过命令行交互式创建与管理。

在实际配置中,系统根据任务场景动态提供不同的工具组合:例如,在指标生成场景中,会提供指标读写、JSON 验证及指标查询等工具;在数据查询场景中,则提供指标搜索等工具;在 ETL 开发场景中,会配置参考 SQL 查询工具。工具集既可通过 MCP 协议接入,也可使用原生实现,未来还将支持更结构化的 Skills 封装。

此外,每个子代理可定义其搜索范围(Scope)、业务规则及外部知识源。这些上下文元素支持动态调整,允许根据需求由模型或人工进行更新,从而实现上下文的持续迭代与场景适配。

分层子代理系统

当各个子代理通过反馈循环迭代达到稳定水平后,系统通过分层编排架构对其进行组织与调度。

顶层设计了一个路由代理(Router Agent),负责将任务按类型分发至相应的子代理。整体架构分为两层:第一层为按通用能力划分的模板,如 SQL 生成、指标构建或元数据操作;第二层则在模板基础上注入特定的领域上下文,形成更具业务语义的专属子代理(如营销分析、供应链 Copilot)。两层结构均可被灵活编排。

此外,系统支持计划模式,即由大语言模型先生成任务执行计划,再按计划调用不同的子代理协同完成。该机制提供了另一种上下文隔离与任务组织的可行方案。

基于探索的语义模型构建

为提升语义模型的实用性,当前工作聚焦于优化 SQL 建模。针对大规模数据表(常含数百列)自动注释易遗漏关键信息或混淆相似字段的问题,系统通过分析用户 SQL 查询的历史热点,识别高频访问列,并依据其数据分布(如基数高低)差异化生成重点注释,从而构建更精准、实用的数据上下文,以更好地引导大语言模型进行理解与推理。

四、 用户案例与未来规划

用户案例1:构建数据代理

当前构建 Data Agent 的核心路径是:整合数据库、语义层及 BI 工具等多源数据,通过专用组件自动抽取关键信息(如从 BI 报表或历史 SQL 中提取),并调度一系列子代理进行协同处理。最终,系统能交付不同功能的智能体,支持多轮交互对话与报告生成等任务,同时通过交互反馈持续迭代和优化上下文质量。

用户案例2:构建湖仓管道

Datus 可作为统一的客户端工具,接入并协调 PostgreSQL、StarRocks、Polaris 等不同数据库与组件。这些组件以 Docker 或独立服务的形式部署,通过 Datus 进行统一调度与管理,从而构建并执行从数据抽取到数据服务(如生成 ETL 任务或查询 SQL)的复杂数据处理流水线。

用户案例3:DBT替代方案

Datus 项目正规划与 DBT 工作流深度集成,旨在通过一系列数据工程子代理实现以下能力:自动建表、对 SQL 脚本进行版本管理、为 SQL 自动嵌入质量检测规则,并与外部任务调度工具(如 Airflow)无缝对接。

用户案例4:迁移场景

在数据迁移(如 Trino 到 StarRocks)与元数据/权限迁移等场景中,该系统通过提供标准化的工具接口,支持用户通过修改系统提示词或编辑技能工具的方式,自定义和实现相应的迁移逻辑。

Datus 0.3 版本未来规划

Datus 项目在 0.3 版本的规划中,旨在打通湖仓一体(Lakehouse)生态中的各类组件,系统化集成元数据、查询历史、任务调度与指标等多种数据源,以构建更为完整、高质量的统一数据上下文。

强化学习的经验教训

在强化学习的应用上,项目团队持积极而务实的态度。核心决策在于坚持智能体(Agent)原生框架而非工作流(Workflow),因为前者能直接受益于底层大语言模型能力的持续进化,而后者难以利用此“模型红利”。

团队认为,若认可多轮智能体交互能产生更高智能,则强化学习的核心目标应是在一组标准化的工具集下,让智能体学会更高效地完成任务(即让“一次通过”的性能逼近“多次尝试”)。当前,强化学习的基础设施已日趋成熟。

具体到数据工程领域,其任务(如 NL2SQL)具有天然明确的奖励信号(SQL 执行结果正确与否),这为强化学习提供了清晰的环境。真正的挑战在于,如何在用户的真实业务场景中,利用其专有数据和环境进行轻量级的强化学习微调,并确保其产生实际效果。

五、 Datus 的设计理念

Datus Agent的设计理念

Datus 项目在整体设计上遵循三个核心理念:

  • Context over Control(上下文优先于控制):项目采用智能体原生(Agentic)思路,而非追求短期高准确率的固定工作流。其核心在于构建高质量、可迭代的数据上下文(Context),从而持续受益于底层大语言模型能力进化所带来的红利。

  • Simple and Reliable(简单可依赖):系统本身不内置复杂工作流,而是通过提供强大、可靠的验证工具来保障结果质量。例如,在生成指标、SQL 或配置文件时,均会调用相应的验证工具进行格式与逻辑校验,确保输出正确,从而构建可信的智能体交互循环。

  • Embrace Changes(拥抱变化):框架设计强调对模型迭代的适应性。通过提供标准化的强化学习环境与奖励函数,项目为未来可能的模型微调与进化预留了空间。团队认为,在 NL2SQL 等数据工程任务上,大部分性能提升源于上下文工程与智能体框架的优化,而非单纯依赖模型升级。

Datus 是一个开源项目,旨在构建服务于数据工程师的 AI 编程助手。我们欢迎所有对数据工程和人工智能结合的开发者关注项目、参与 云栈社区 的交流与贡献。




上一篇:LiveAutoRecord:免费开源的Windows多平台直播自动录制软件
下一篇:从备胎到传奇:8086处理器逆袭史话
您需要登录后才可以回帖 登录 | 立即注册

手机版|小黑屋|网站地图|云栈社区 ( 苏ICP备2022046150号-2 )

GMT+8, 2026-4-7 19:48 , Processed in 1.049970 second(s), 41 queries , Gzip On.

Powered by Discuz! X3.5

© 2025-2026 云栈社区.

快速回复 返回顶部 返回列表