IBM DataStage：自然语言怎样变成可校验、可编辑的数据流程

DataStage Assistant 最有价值的工程决定，是没有把“生成一条数据流程”交给一次自由生成。它先选择产品支持的算子，再为每个实例填写属性；表达式交给专门的生成与验证路径，产品用法则通过文档检索回答。模型、程序和原有画布各自接住一部分工作。

这解决的是一个具体困难：知道“按客户编号关联客户和销售数据”，不等于知道在工具里选什么组件、填哪些配置。论文公开了上下文、三类提示词、验证和部署，也暴露了重复组件串值、复杂表达式薄弱等问题。沿着这些细节，可以判断自己的配置软件需要准备什么，而不只得到一句“接入大模型”。

用户要的是产品对象，不是一段答案

DataStage 用于提取、转换和加载数据，简称 ETL。它已有图形画布，用户仍需认识数据连接器、转换算子及其属性。论文界面例子是按客户编号关联客户和销售数据，生成后继续由用户完成必要的列映射、键选择等配置。算子是画布中的处理组件；输出最终必须落成产品可以继续编辑的流程。

助手提供三项能力：生成流程、生成 Transformer 表达式、查产品文档。这里的 Transformer 是 DataStage 里处理逐行转换的组件，不是模型架构名称。三项能力可在同一产品里接续使用，但没有一条“每次都先生成流程、再生成表达式、最后查文档”的固定链。论文图1、用户交互章节

在模型调用之前，把产品说明整理成两用知识

论文的前置工作是分析产品文档，将支持的 stage 及属性整理为上下文库。stage 可以是数据源连接器，也可以是转换组件。实验整理了142个 stage，其中90个是连接器；每个组件有1至111项属性，平均27.6项。每项属性保存描述、类型、默认值和生效条件。

这份知识有两个使用者。模型需要它理解组件与配置含义，验证程序需要它检查输出。若只把名称教给模型，程序仍可能无法判断一份配置是否合法；若只做类型校验，模型又可能选对类型、选错业务对象。

知识按当前决定装配：选算子时使用名称、简短定义和示例；填属性时换成已选算子的参数规则；写表达式时提供函数和语言规则。没有把所有产品说明一股脑放入同一个提示词。论文 Architecture、Experiments

三类动态提示词分别在约束什么

算子选择：先确定允许进入哪片配置空间

公开的算子提示词包含任务指令、算子名称与定义、单算子和多算子示例，以及当前用户要求。模型输出一个或多个算子。程序随后核对名称是否属于上下文库。

作者还加入一个专门表示没有合适匹配的选项 unknown；无有效匹配时，会要求用户补充信息。它避免将目录外需求强行归到“最接近”的组件；具体追问模板未全部公开。

第一步的重要性在于：选错算子会打开错误的属性空间。后面的参数即使完全符合那个算子的规则，也可能完成了另一项工作。因此算子准确率和属性准确率需要分开观察。

属性生成：一个算子内部联合考虑，不同实例隔开

属性提示词接收已选算子、参数定义、同类任务示例和用户要求，输出该算子的属性值。作者比较过逐个属性预测与一次预测全部属性，后者表现更好；论文给出的解释是属性间有关联，放在一起能保留条件关系。

但算子之间又需要收窄上下文。同类算子重复出现时，模型可能把一个实例对应的要求填给另一个。作者先将用户输入拆成对应各算子的片段，再分别送去生成属性，报告准确性改善约10%，没有明确相对增幅还是百分点。

这两项选择并不矛盾：同一对象内部的依赖要一起看，不同对象的要求要避免混在一起。论文没有给出一套公开的实例编号协议，也没有展示某两个 Filter 的完整错误轨迹；可确定的是重复算子带来的归属问题及输入切分的处理办法。论文 Operator Prediction、Property Prediction

表达式生成：给函数签名，而不是让模型自由写语言

表达式提示词单独提供 DataStage 语言语法、允许函数列表、函数说明和输入输出、少量示例，以及本次要求和输入列。候选结果使用产品自己的表达式语言，输出由代码标记包围；程序继续检查函数、参数数量和类型。

这与用文档搜索回答“怎样使用组件”不同。前者要形成能解析的配置产物，后者要形成有依据的解释。将两者统称为检索增强生成，会掩盖不同的错误出口。

公开提示词既要求只返回代码，又要求无法生成时通知用户；论文未给出完整的失败返回协议。迁移时应在宿主接口中明确失败怎样表达，不能让程序把一句解释当成表达式。论文 Transformer Expression Generator，公开提示词位于PDF第5页

可横向查看，点击打开原尺寸 ↗

据论文流程生成路径重绘；只画已披露的实例切分、属性依赖与用户确认，不补自动修复循环。

验证器检查产品规则，不能替业务确认目标

属性验证不仅看字段有没有值，还看值是哪类对象、枚举是否合法、属性是否满足生效条件。论文图2给出了真实的 Column Generator 约束：只有 Column Method 选择 Explicit，Column to Generate 才适用；前者允许的选择包括 Explicit 与 Schema File。

表达式验证则沿函数结构检查：函数是否在支持库内、传入参数个数是否正确、每个参数类型是否与签名相符。复杂表达式把多个合法函数组合起来，仍可能违反这些关系。

这些检查能拦住产品不认识或无法解析的结果，不能自动证明选中的字段和处理意图正确。画布检查、列映射及实际数据验证仍有各自职责。论文没有充分公开属性或表达式失败后的自动修复、重试预算和完整图连接生成协议，不能把概念上的“返回修正”画成已经证实的循环。

文档问答还有另一种核验对象。系统先将文档转为文本并切块，再用语义检索选取相关内容生成回答；论文描述通过生成答案与检索文本的最长词匹配定位来源文档。这个方法方便打开依据，但存在重合文本本身不证明每项结论都被支持。论文属性验证、表达式验证及 Document Explorer

结果回到画布，数据作业在另一侧运行

论文披露，Canvas 前端通过异步 REST 接口访问容器化 FastAPI 后端，后端运行在 RHEL 和既有 Kubernetes 集群中，与 DataStage 同区域部署。模型推理由 watsonx.ai 承担，Milvus 保存文档及系统知识的向量。

两个容量数字容易混淆：每个 pod 配置8个 Gunicorn/Uvicorn Web worker；模型服务则按每环境每秒8个请求限流。前者是接收和处理服务请求的进程，后者是下游推理配额。增加应用副本不等于模型配额同步增加；论文未给出排队、端到端延迟或真实吞吐曲线，不能据此换算可服务多少用户。

功能在项目级选择启用。论文所述默认模型是 Granite 3.1 8B，也允许使用 watsonx.ai 上其他模型。所有实际流程变更需要用户在界面明确确认；助手不直接接触客户数据源或作业运行环境。用户可以继续补配置，确认后的流程再由 DataStage 原有机制运行。

因此应区分三种结果：模型生成了一份草案，用户将变更应用到画布，数据作业运行并得到正确结果。前两项不是第三项的替代指标。论文 Deployment Environment and Platform

按模块看评测，才能知道错误藏在哪里

作者以产品文档构造并标注测试材料，没有公开足以独立复跑的完整数据和评分代码。各项评测的分母不同：

算子实验提示词放入142个示例，覆盖单、多组件组合。实验统一使用贪心解码；gpt-oss 的模板适配了其响应格式。下面保留两个模型的整行结果，避免把不同模型的最佳数值拼成一套部署表现：

Granite 的表达式总体为404/483正确，但字符串嵌套只有5/11，日期时间嵌套只有5/14。总体成绩没有消除组合结构的弱点；这两类分母也很小，不宜直接当稳定生产失败率。文档问答的相关内容入上下文指标约77%，答案使用 BLEU/ROUGE 等文本重合指标，不能解释为业务问题答对率77%。论文实验、表1与表2

用户研究是另一条证据：若干熟练用户和初学者先不用助手、再用助手完成任务；作者报告前者约节时一半、后者创建流程约节时九成。参与人数、耗时分布和顺序学习效应没有充分展开，因此它支持继续验证效率，不足以承诺本团队同样的收益。论文 User Study

把这套办法用于自己的配置软件

应先取得真实组件目录、属性依赖、函数签名和一批获准使用的任务，再设计提示词。一次最有价值的检查，是让同类组件在同一任务里重复出现，逐项核对要求片段、目标实例、属性值、程序校验及人工修改，随后确认第一次运行和输出数据。

再按失败位置决定修改：组件选错，检查目录和选择示例；属性错配，检查输入切分与实例绑定；组合表达式失败，检查函数关系和相应测试；草案正确而运行失败，回到连接、数据及作业环境。不能把所有问题都归为模型“不够聪明”。

这也是本案的可迁移边界：它适合有稳定领域对象、可维护元数据和可编辑产物的软件。新增组件时，说明、参数规则、示例和验证器须一起维护。只有把这些资产接上已有产品的检查与执行边界，生成才能减少总工作量，而不是把输入工作改成更难的审阅工作。