我要投稿

一场由AI拯救的数据重构之战

发布日期：2025-09-29 08:37:33 浏览次数： 1525

作者：阿里云开发者

微信搜一搜，关注“阿里云开发者”

一、引言：数据研发的烦恼

又是一个美好的周一上午，我们的校招新人小D同学来到了工位，刚打开电脑就收到了一条上周遗留的工单消息来催赶紧解决，原来是有业务方看不懂宽表上的字段逻辑，并且发现在不同地方出现数据不一致，想弄清楚下这个差异是怎么造成的。小D心想：应该是前人在哪个环节用了不同表，查下代码就知道了，so easy~ 于是乎他查到这两个不一样的地方分别用的是哪个数据表，然后逐一打开代码想细看下这两个字段的代码逻辑，结果....WTF...这代码怎么一个比一个复杂！！！

小D开始后悔打开这个工单，但是没办法，他已经把工单状态改成处理中了，秉着认真负责的态度，他硬啃代码，查表字段逻辑、查上游依赖，一层层溯源了解这几个字段的加工逻辑，最后终于理清楚，发现一个上午过去了，其他活也没干。下午好不容易和业务解释清楚这个逻辑之后，业务说这个逻辑不对，得改，小D一脸懵逼...

因为宽表上的数据都是明细类数据，如果要改逻辑的话，必然会影响到下游数据使用方，这就需要去盘清楚影响面有多大，听起来像是个大工程。

小D赶紧跑去和师兄反馈：“师兄这个字段逻辑要改的话好像影响了很多下游，这要预计花多少时间我盘不过来啊！！！”

师兄毕竟是见识过大风大浪的人，微微一笑：“慌什么，年轻人得跟上时代了，这不是有AI吗，让它帮你。”

二、AI提效生产力

2.1 AI帮我们解决什么问题

进入正题，在应对新的数据需求时，我们通常遵循需求评估-模型设计-SQL开发-测试发布-数据质量运维的多阶段协作流程。值得注意的是，这些环节并非线性推进，而是与日常研发工作深度融合。就像小D，在运维过程中发现问题，需及时启动影响范围评估及迭代修复等保障机制，确保线上数据的准确性，也因此带来了连锁反应导致大量额外工作。正是这样的复杂情况下，我们意识到AI技术的价值：通过自动化工具与智能决策辅助，帮助我们从低效重复的ROI泥潭中突围，实现从“研发提效”到“技能跃迁、能力提升”的跨越，推动我们自身与业务价值的双重增长。

现有大模型已经做到了文本/代码生成、多模态处理、复杂逻辑推理及知识增强等能力，同时也存在黑箱机制、鲁棒性不足等问题。基于现有大模型的优势，我们带入到数据研发的各个环节大致盘点了下它能怎么帮助我们研发提效：

2.2 我们还需要解决哪些问题

在集团内部，尽管数据百晓生已通过自动化技术实现数据表的检索与答疑，并且利用LLM构建AI数据助手实现了“找数-取数-用数”的全链路覆盖；D2 Copilot亦支持SQL/Python代码生成与改写等功能，但若想进一步利用大模型实现需求评估、模型评审、CodeReview、代码规范改写及问题排查等场景，仍需攻克以下核心问题：

1.数据链路影响范围的精准定位

当前大模型及数据百晓生无法完整返回数据链路全景，仍需依赖DFD（数据流图）等工具辅助，才能准确评估需求变更或问题排查对上下游链路的潜在影响。

2.多业务域模型规范的差异化适配

各业务域模型评审标准差异显著（如HR、数据办公等），需维护并注入各领域专属规范文档作为Agent的“指导手册”，避免统一规则导致的适配偏差。

3.代码规范标准与基模能力的匹配难题

基于通用预训练模型的代码生成能力（如基模）难以贴合团队私有数仓的代码规范（如命名、注释、性能优化），需灌入私有模型知识库实现定制化适配。

4.元数据驱动的代码改写挑战

面对SELECT * INTO TABLE等模糊操作，需结合元数据知识自动补全字段内容，才能生成符合代码标准的规范语句（如SELECT work_no, order_num FROM ...）。

总之，从数据链路分析到业务规范适配，从基模优化到元数据融合，都通过工具链增强、领域知识沉淀及私有模型迭代，系统性突破大模型在研发提效与技能跃迁中的落地瓶颈，这也将是我们在此次实践中主要攻克的内容。

2.3 为我所用的AI能力

“工欲善其事，必先利其器”，要构建一个好用、高效的研发类Agent来帮我们干活，首先需要了解构建Agent的基础组件是什么。参照于openAI构建Agent的做法，一个Agent最核心的构成包含以下三个基本组件：

模型 (Model)：大型语言模型 (LLM)，理解成Agent的“大脑”，负责思考和做决定。
工具 (Tools)：Agent可以用来采取行动的外部函数或API，理解成Agent的“手脚”，让它能够与外部世界互动和执行任务。
指令 (Instructions)：定义Agent行为方式的明确指导方针和护栏，理解成Agent的“行为手册”或“操作指南”。

说明：本场景面调研时使用的为内部AI工具。

2.4 我们的目标与设计思路

在以上这些丰富的能力加持下，我们希望构建一个面向数据研发全链路的智能Agent，通过AI能力去帮助【评估设计】->【模型评审】->【数据研发】->【数据运维】四大核心环节实现提效，把数据研发同学最耗时、执行效率低或者效果较差的五个场景作为先行切入点：

结合前期我们所调研的情况，以及项目开始前的各产品的迭代进度，我们最终选择用AI Studio平台，并利用已有的一些工具，如图治MCP、D2 API等来构建我们的专属研发增强Agent 【数研小助手】：

三、实践检验

让我们回到小D的场景，由于老板看不惯这个代码太久了，代码逻辑不清晰，日常运维耗时耗力，早就想把它们重构掉。于是顺势而为，因为这个数据不一致，小D承接了一个大工程——代码重构！！！！

3.1【数据设计】评估报告

小D要在重构代码的同时修正代码逻辑，他需要评估一下对下游的影响面是什么，大概需要投入多少人日。他点开了需求文档，发现天啊，居然有这么多的表需要修改，这个表下游挂了7级基线，可不能随便改，那个表存在跨多个域的依赖，也得小心，还有直接用于产品线上的，以及等等等等的需要注意的点，哇哦，小D已经晕了，他急需一个工具能帮他”把这些需求的影响点都给他快速的列出来。

于是，我们就希望能有一个「需求评估」Agent/来帮助小D对需求列表里的每个小需求做影响评估、风险评估等等，能快速的理清里面的方方面面。

3.1.1 场景盘点

首先，我们确定了需求评估的四大场景，从这几方面去做探索。

3.1.2 解决思路和方案

按照设想，我们首先需要从需求文档中提取到要做评估的内容(表)，当然也可以接受用户直给的提问。接下来，「影响评估」帮助同学做表血缘信息、质量信息、生产信息、应用信息一体化的盘点&评估；然后交由「风险评估」帮助判断下其中是否里面存在一些隐含的风险需要注意；最后「工时评估」像是个简易版的数字人告诉同学，你做完这个需求大概需要多少工期，最近还有哪些事排着呢。

这一套下来，希望能切实的帮助同学达成快速评估的效果。

具体开始实施的时候，先明确了最终的样式，然后再梳理了一个个可扩展的场景，再把它们打造成一个个可拼接的拼图。同时，「需求评估」agent我们赋予了他解决特定任务“评估”的职能，是具有高度确定性，因此Workflow的模式成为了较优的agent搭建选择。

在每一个细分的评估场景下，「影响评估」「风险评估」「工时评估」，让他们在具有独立性的同时，保持了可协同，可扩展的能力。

基于上面的思考，总结了关于Agent构建的路径图。

具体来说，三步走策略。一、先基于我们的目标，通过prompt工程做一个初版agent,看它的输出形态是否满足我们的要求；二、对我们的原型agent做子agent拆解，使每个agent保持独立性，具体可扩展，可复用以及易维护的能力，没有问题再做整体workflow的构造；三、模型调优，这一步实际是贯穿在我们整个构建过程中的，评测集必不可少，优化手段也非常多（prompt调优、参数调优、数据增强等等手段），具体落到每个场景下做针对性调优。

3.1.3 挑战及策略

挑战一：运行效果不稳定

由于大模型的特性，幻觉问题很难避免，这时候prompt的好坏就起到了决定性的作用；但是往往由于场景的复杂性，我们的prompt越写越长，越来越不容易调试。

因此在这个过程中，也是做了以下几点，来使效果更稳定。

anget合理规划

对于一些标准化、重复执行的场景，抽离出来单独做一个子agent，如负责「内容总结」的场景是在每个评估场景下都要做的，那就可以抽离出来，间接减少了prompt的内容输入。

提示词调优

结构化提示词模板：这个目前网上是有很多的结构化模板建议，这里我就不做具体的举例，大致可分为「角色」-「要求」-「格式」-「约束」-「示例」。

AI自我理解：大模型自己是最了解自己的，所以在写完提示词后，交给大模型帮你调优。

挑战二：编排复杂度高

在追求尽善尽美的道路上“义无反顾”，带来的是agent内部构造的极速膨胀，怎么把握好「质量」和「数量」之间的平衡，在评估这个场景下同样是个绕不开的话题。

这个平衡是动态的，它取决于我们对agent的期望，基准效果，维护成本等多方面来综合考量的。因此：

做好Agent规划层的权衡

现在的规划层基本都是基于Multi-Agent（多智能体）架构（简易版）来实现的，那么怎么做好稳定可控，我们会在初期就定好大的框架，框定一个范围，避免agent过快的进入“熵增”的泥潭；

3.1.4 效果展示

用户输入：帮我做一下表1,2,3的评估，我要对他们进行变更。

评估建议如下：

3.2 【数据评审】模型评审

小D现在已经知道大概要改哪些点了，既然要重构，那他就需要重新设计这块数据的模型，但是作为新手的他发现了解这块业务的同学已经离开了，团队内的模型规范他还不是很清晰，模型设计评审文档也不知道该怎么写...... 小D想，要是有一个工具能够教我怎么设计模型和写模型文档就太完美了！

基于这种场景/诉求，我们希望借助AI能力，构建一个“模型评审Agent”，支持数据同学在设计过程中实现“边设计、边评审”的目标，减少沟通和设计成本，提升整体研发效能。

3.2.1 场景盘点

在第一期，我们收集了周围数据同学在日常模型设计中存在的高频问题，抽练了一些核心痛点作为初步的试点方向。

3.2.2. 解决思路和方案

基于上述9个问题CASE，我们选出了6个P0的方向，并将这些问题凝练成了两种通用的场景：设计咨询和文档评审。见名知意，前者为数据研发同学提供设计咨询的入口，实时回答模型规范等基础问题（再也不用担心设计出来的表不符合团队规范啦！！）；后者会替代人工对已经完成的模型设计文档进行评审，给出修改意见和可能存在的风险。设计咨询和文档评审两种场景分工明确，工作于并行的形式，真正的为数据同学实现“边设计、边评审”的目标。

从上述的设计图中可以看出，我们的模型评审方案分成了经典的三层架构，自顶向下分别由用户交互层、模型评审Agent层、底层能力层组成。三者的定位如下所述：

用户交互层：面向用户的服务层，承担意图识别、场景分发（调用设计咨询或文档评审子Agent）、建议汇总、多轮回话交互的作用。
模型评审Agent层：模型评审方案的核心层，由设计咨询和文档评审两个子Agent构成，用于为用户交互层提供清晰明确的模型和设计文档建议。该层的各子Agent各司其职，互不干扰，工作于并行的模式。这样设计的目的有两点：1.方便新场景的支持，每个子模块均可自由插拔，可以无痛实现功能扩展。2.功能解耦，每个子模块仅负责预设好的场景，功能不会重合，减少大模型出现幻觉的可能。
底层能力层：前置工具和文档的准备层，由各位开发同学共同维护，用于存放构建Agent所必须的知识库和工具。

3.2.2.1 通用大模型选型

俗话说：“工欲善其事，必先利其器”。大语言模型是构建Agent的基础，针对于不同的场景，大模型的选型非常重要。为了选出适用我们场景的基础模型，我们分别测试了市面上通用的大模型，并从稳定性、性价比、输出效果几个维度进行了综合考虑。Tips:测试结果仅是从我们的场景上出发，并不代表大模型在其他通用场景上的性能。

基于以上测试结果，针对于本场景，最终决定选择Qwen系列的Qwen3-32B作为基准模型。

3.2.2.2 Prompt构建

选好了合适的通用大模型，配套合适的提示词也至关重要。为了实现设计评审和文档评审子Agent，我们按照：角色 - 技能 - 限制 -示例的结构设计了详细的prompt。

3.2.2.3 知识库构建

知识库是Agent构建的核心支撑，为其提供领域知识、业务规则和上下文信息，显著提升其理解、推理和决策能力。它可以为大模型提供某一特定业务场景的先验知识，使Agent能按照规则准确回答专业问题，尤其在垂直场景中不可或缺。在模型评审的场景中，我们主要构建了三类知识库：

3.2.3. 效果展示

评测方向	评测问题	效果截图	是否符合预期
表命名咨询	我要在cdm层创建一张IT域服务营收的dwd表，该怎么命名		是
表命名规范判断	dwd_is_hr_regist_application_df这张表命名规范吗？		是
生命周期咨询	dwd_is_hr_regist_application_df这个表生命周期设置为3650天合理吗		是
字段命名咨询	work_no这个字段命名合理吗		是

3.3 【数据研发】Code Review

经历千辛万苦，小D的数据模型评审得到了团队内同学的一致通过，终于可以进入开发阶段，围绕他新设计的表，他志得意满地开发完了，结果在Code Review的时候，发现只有师兄可以帮忙CR，有时等师兄在开会，或者周末又不好意思打扰他。于是小D想，要是有个24小时在线，且能快速给我CR建议的Agent工具就好了。

既然团队有数据模型规范，还有统一的代码风格，我们就可以依托AI来实现代码的Code Review，减少人工CR，提高CR的效率及准确性。

3.3.1. 场景盘点

首先，我们还是先盘点Code Review场景里可能会遇到的问题，并展开这部分可能的问题方向。

3.3.2. 解决思路和方案

结合上述的5个细化后的方向，我们分模块进行解决思路的剖析及方案设计。

1）首先是代码规范检查，目标很明确，确保SQL代码符合团队规范（语法、命名、注释、格式等），这里我们只需要依托强大的基座模型 + 私有知识库即可实现，多次调整Prompt后即可实现标准化的输出。私有知识库部分是完全可以依托【模型评审】场景的积累，快速复用的。

2）代码影响评估方向，目标是分析SQL潜在的问题，包括如数据倾斜、数据膨胀等在内的性能风险，这里我们需要依靠工具服务去完成一些关键信息的提取，如表数据量、字段探测后的枚举值等，Workflow模式不太适用，而建议使用ReAct模式，同时可以在Prompt里可以构造一些few-shot来帮助提高鲁棒性。

3）在代码版本演变方向，目标是解释追踪SQL代码的版本差异，总结变更内容，这其实是我们在接收前人代码的时候，可能会关心的事情，尤其是多次版本迭代后，可能有太多的Monkey patch式的代码妨碍我们阅读。这个方向上，目前强大的基模都可以满足代码解释，所以这个场景不需要做太多Prompt的约束，只需调整输出的形式，找到方便我们快速阅读理解的Output形式就可以。

4）代码优化建议方向其实同方向3一样，基模已经很强大，结合RAG和Output形式的调整，即可做的较为优秀。从下图的case可以看出，在使用Qwen3-32B的基模情况下，即便未做太多Prompt的约束就能输出一份很完整的SQL优化建议报告，虽然有些优化点存在幻想，不过稍微做一些Prompt的调整即可输出更好的结果。

5）关于代码CR的后续动作，这其实是CR这个场景的关键，在完成代码规范检查、代码影响评估、优化建议等相关动作后，需要给出最终的结论是通过or不通过，同时调用D2对应的服务完成CR动作。

3.3.3. 挑战及策略

挑战一：大模型很较真

明明可能不是大问题，调教后的大模型CR还是很较真，不给过就是不给过。依据我们测试的7个可过可不过的评测case，大模型的结论都是不给过，同时还能给出充分的理由及优化建议。如果遇到紧急的问题需要修复，尤其是半夜，如果我们核心中间层出现问题（核心中间层配置了必须CR才能发布），需要紧急修复代码，AI CR非得较真的话，可能真的会急死人。

这里得思考一个问题，适当让大模型松一松手。我们需要梳理日常Coding过程中，可能存在的容忍度较高的问题，让大模型学会通融，而对于红线及容忍度低的问题才绝不放行。对于容忍度较高的问题，比如某些代码样式之类的问题，其实只要团队内能达成一致即可，私有知识库本身也是需要持续完善的。

挑战二：避免陷入“CR->修复”的死循环

没有毫无缺点的代码，只要代码一长就一定会有问题，所以在CR场景的建设上一定要避免陷入“CR->修复”的死循环。

1）一次CR就是一次CR。如果CR不停地翻旧账，改了旧账又翻另外的旧账，就会陷入死循环。

2）CR要把话一次说完，避免挤牙膏式的CR，每次就只说一两个问题。

3.3.4. 效果展示

目前在CR松紧度上，效果还需要再做调整，比如下图case中的原因3，虽然数据规模规范中有“按需取数”的条款，但实际我们常见的代码开发中，是容忍度较高的一个问题，同时D2本身也做了仅读取有权限字段的优化。

3.4 【数据研发】OneStyle

小D的模型重构完了，他通知下游同学修改下依赖，下游同学打开自己负责的任务一看...这是什么历史代码连基本对齐都没有，根本看不懂，想一键格式化，结果发现d2上的格式化真的就只是一键对齐，好像帮我改了又好像没啥效果...... 许多规范性的代码问题根本无法解决：比如代码无注释、超长加工逻辑、多层WITH嵌套等等，严重影响到工作中的协作开发效率......

面对这种场景，我们希望one style可以统一代码的写作风格，使代码变得逻辑性强、易于排查、可读性高。

3.4.1. 场景盘点

在第一期，我们调研了周围的一些数据同学在日常研发上存在的一些问题，抽炼了一些核心场景作为尝试的方向。

3.4.2. 解决思路和方案

在以上的细分场景上，我们又构想了两种使用场景，一种是在日常开发工作中供数据同学使用，另一种是通过API进行批量历史任务的改写，前者可以帮助数据同学在日常开发中快速达到书写规范，提升开发效率，而且可以避免被后人暗戳戳吐槽（bushi），后者可以帮助团队对历史的节点代码进行批量改写，帮助自动化地统一代码风格，在很大程度上可以减缓接手新代码的痛苦。

从具体的使用场景出发，我们拆解了可能会遇到的各种问题，以及在处理这些问题可能要使用的工具和知识，基于这种自上而下的拆解，我们首先完成了底层能力的建设。在Agent的建设上，我们并没有采取一个大而全的Agent的方案，而是将第一部分提炼的问题场景结合使用场景按照“高内聚低耦合”的原则进行了功能的划分，建设了各个垂直功能的Agent，这样做的优势在于：

可扩展性强：现有方案支持我们在保证不影响原有Agent功能的情况下，对Agent能力进行扩建，支持了未来对于其他问题场景的覆盖能力。
效果更好：多Agent分离的形式，可以让每个Agent专注于本身的角色和工作，相比于单Agent模式，可以更有效地减少模型的幻觉和规则遗忘的情况。
支持多种使用场景：不同场景的特性决定了对于Agent能力的要求也不同，在日常工作使用场景时，需要兼顾准确率和效率，而在批量改写代码时，则更关注的是准确率，对于响应时间并不太关注。在我们的方案设计中，核心在于对“积木式”Agent的构建，使得在上层应用时，既能支持单一需求的快速响应，也能支持严谨场景的反复验证。

3.4.3. 效果展示

原始代码：

改写后的代码：

原始输出结果

复制到D2编辑器中

3.5 【数据管理】问题排查

小D明明已经通知了下游要改的地方需要在什么时候修改完毕，历史模型会做下线处理，然而过一段时间还是被业务找上门了，说他的数据产出有问题。小D汗颜—_—|||，赶紧帮忙看下到底是啥问题......

日常工作过程中，除了将业务的需求按期高质量交付，我们也需要保障数据和任务的稳定性，而不影响线上数据的产出，当出现问题时，我们希望【问题排查】可以自动帮我们定位到问题点，减少我们耗时费力的排查过程。

3.5.1 场景盘点

线上的数据产品，我们最常被问到的问题就是这个数据的口径是什么，或者这个指标怎么和另一个地方的数据不一致。即使是个深耕业务的研发老手，也会因为接触的任务太多而忘记这个数据的具体口径是什么，然后去深扒指标的代码逻辑，当业务逻辑比较复杂，依赖的链路较深时，花上0.5-1个人日都是有可能的。在我们的场景当中，我们主要围绕我们最常见的几个问题进行重点提效：

3.5.2 解决思路和方案

回想一下，当面临数据异常或者任务出错时，传统排查流程往往需要我们手动梳理任务链路、解析代码逻辑，这种人工排查方式存在效率低、耗时长等问题。为此，我们希望建设【问题排查Agent】，通过以下两大核心模块实现自动化问题定位：

任务诊断：通过识别任务及其上游任务、基线的产出情况，辅助判断数据异常情况是否来源于任务异常，如果真有异常，可以定位到我们具体哪个任务有异常，异常点是什么，最好能直接告诉我们怎么解决。
数据诊断：Agent帮我们完成找代码、理解代码、溯源并整理输出的工作，从代码层面直接告诉我们数据的计算口径是什么（不直接查表，减少数据安全风险），减少我们人工扒代码，花时间查口径、理解数据的人力成本。

整体设计中我们遵循"统一溯源，差异处理"原则，实现从"人工经验排查"到"智能辅助诊断"的范式升级：

通性能力：依托节点或者表的血缘分析引擎实现跨任务/表的数据任务和代码加工逻辑追踪。LLM自主选择调用工具，快速定位问题点。
差异化能力：任务诊断侧重调度监控与运行状态分析；数据诊断聚焦代码逻辑解析与计算规则推导。
技术支撑：任务诊断借助图治MCP智能诊断技术，数据诊断通过D2 API调用节点实时代码进行语义分析。

3.5.3 挑战及策略

挑战一：如何让Agent自己实现溯源排查问题？

传统排查问题时，往往不是直接查看发现问题的节点就能立马定位原因，需要层层溯源定位源头，Agent要做到这一步，就需要知道怎么去找节点的上游。而查找节点上游需要利用到ODPS元数据的血缘信息。除此之外，Agent要排查数据的计算口径，也需要能够查找到节点代码便于理解，因此在项目初期，我们抽出了共性问题——ODPS元数据。将所有需要利用元数据信息的场景封装成一个通用型agent来帮我们实现，支持查找表或节点的基础信息，包括字段、节点id、表/节点/字段的血缘。

基于这个通用型Agent，在【问题排查】场景中，我们只需要调用该Agent来帮我们查出异常字段/表的各上游节点，并根据字段血缘深度，由大模型帮我们梳理出相关字段的加工逻辑，从而辅助我们的口径答疑。

挑战二：怎么知道节点的运行状态？

在实际场景中，我们的任务未挂载到基线上，任务又受上游影响（我们非上游任务负责人）延迟产出而没及时被通知时，需要我们自行进入到运维中心，根据任务血缘不断往上找到问题所在。即使是让Agent来帮我们排查问题，也需要能够获取到任务实例状态，因此我们借助图治的诊断能力来帮我们实现这部分功能，图治近期上线了离线运维的MCP能力，正好支持我们在AI Studio上调用。