我的数据空间

主题

智能问答 ​

场景　平台用得越深,问题越杂:新人问「离线作业怎么建」,老手问「Spark OOM 从哪查起」,业务同学问「营收到底是怎么算的」——总不能每个问题都翻手册、追着数据团队问。AI 助手「工小数」常驻在平台右下角,基于平台知识库、语义模型与真实运行数据作答,而不是拿通用大模型的印象糊弄。

能干什么

你想做的事在工小数里长这样
操作/排障疑问,不想翻手册直接问,回答基于平台文档,底部列来源,点开可看原文
想确认回答不是模型现编的展开「思考过程」,每一步检索了什么、拿到什么一目了然
问指标口径、表结构、表关联直接读语义模型与元数据作答,口径与实际查数用的同一套
想查个数,但只会说大白话转为生成 SQL,指标过滤自动折进去,拿到「数据查询」页就能跑
问得含糊、或一个词对应多个口径不瞎猜,先反问并给出可点候选,点一下继续
作业跑挂了想知道为什么对话里带上实例号,自动转深度诊断,给出根因与修复建议
回答有误想纠正点「纠错」提交,沉淀为经验,同类问题以后答得更准
想把自己团队的文档喂给它管理员可上传业务文档进知识库,传完即可被检索到

亮点 ​

  • 答案带出处,检索不到就明说——基于知识库作答并列出来源;知识库没有的内容会明确拒答并建议怎么补充提问,不拿通用知识冒充平台事实
  • 一个入口收编多种能力——文档问答、口径解读、SQL 生成、失败诊断由模型按问题自主选用,你不用先想「该去哪问」
  • 口径问答与查数同源——「营收怎么算」的解释和「帮我查营收」生成的 SQL 用同一套语义模型,不会各说一套
  • 不确定就反问,反问可点选——歧义时给出候选按钮,点一下带着你的选择继续,不打字也能把问题问准

示例一:问一个排障问题 ​

问「Spark 任务 OOM 怎么排查?」,回答不是泛泛的调参清单,而是按平台的实际动线组织:先用哪个入口拿证据、怎么判断 OOM 发生在哪一层、去哪里调资源配置:

工小数回答「Spark 任务 OOM 怎么排查」:给出结构化排查指南,第一步指向平台的智能诊断入口(运维监控选中失败实例点智能诊断),第二步区分 Driver OOM 与 Executor OOM 的典型场景,第三步指到数据开发的作业配置里调 executor/driver 内存与实例并行度

回答底部是完整的可信度配套:五篇来源文档(含引擎调优资料)、三个「继续」追问建议、以及一句诚实的边界声明——知识库里没有的调参细节,它直说「不做臆测」:

回答收尾:说明段写明"以上基于平台使用文档与引擎资料整理;知识库未收录更细的 Spark 调参组合,不做臆测",下方列出 AI助手.md、数据开发.md、资源管理与平台运营.md、运维与告警.md、spark sql-performance-tuning.md 五个来源 chip,以及"帮我诊断一个失败实例""数据倾斜怎么定位和优化"等继续建议

展开「思考过程」能看到它一共检索了多轮:同一个问题被改写成「内存参数调优」「作业资源申请」「executor GC 诊断」等多个角度分别查,某一轮没查到也如实记录——检索了什么、拿到什么全程可审计:

思考过程展开:连续多个 search_docs 调用,查询词各不相同(Spark 任务 OOM 内存溢出排查/Spark 内存参数 executor memory overhead 调优/离线作业 Spark 参数配置 资源申请),其中一轮如实显示"未检索到相关文档片段",另一轮返回数据开发.md 的资源申请章节

示例二:问指标口径 ​

业务上最常见的扯皮是「你说的营收和我说的营收不是一个数」。工小数直接读空间里的语义模型回答口径问题——下面这个空间里恰好有两个「营收」:财务口径只计已完成订单,经营口径下单即计。它把两个口径连同差异一次讲清,而不是随便挑一个:

问「营收是怎么算的」,工小数列出两个口径:财务口径(语义模型:财务营收核算)营收=SUM(t.amount) 过滤 t.status='已完成',只计已确认收货的订单;经营口径(语义模型:销售大盘)营收=SUM(t.amount) 过滤 t.status<>'已退款',下单即计;最后总结差异主要在"在途订单"是否计入

这些口径不是从文档里猜的,而是读的语义建模里的结构化定义;没建语义模型的表,问表结构时也会直连元数据返回字段、类型与注释。只会看到你所在空间、且有读权限的模型与表——权限校验在工具内部完成,不依赖模型「自觉」。

示例三:问数遇到歧义,反问可点选 ​

接着问「帮我查 7 月各支付渠道的营收」——两个模型都有「营收」,它不替你拍板,而是弹出两个可点候选:

工小数反问"目前有两个语义模型都含营收指标,需要你先确认查询口径",下方给出两个可点按钮:财务营收核算(财务口径/营收核算)、销售大盘(大盘/销售总览),回答徽标显示"澄清"

点「销售大盘」,它带着你的选择重新作答:生成的 SQL 里指标的口径过滤被自动折了进去,时间范围按「7 月」换算成具体日期,并说明这条 SQL 为只读、执行时仍按表权限鉴权:

点选"销售大盘"后,工小数生成 SQL:SELECT t.pay_channel, SUM(t.amount) FILTER (WHERE t.status <> '已退款') AS 营收 FROM iceberg_lake.qa_demo.fact_order t WHERE t.order_date >= '2026-07-01' AND t.order_date < '2026-08-01' GROUP BY t.pay_channel,并附说明:时间范围 2026-07 全月、口径为排除已退款订单、SQL 只读需在数据查询页执行(执行时按表级权限鉴权)

「解释口径」与「按口径查数」走的是同一套选模型逻辑,所以示例二里讲的口径和这里生成的 SQL 必然一致。问得足够具体(点名模型/指标/时间)就不会反问;这条生成链路的完整介绍见 AI 敢用 · NL2SQL 语义层。

示例四:失败实例在对话里直接诊断 ​

对话里带上失败实例号,工小数自动转入深度诊断——和运维监控里的「智能诊断」按钮是同一套能力,只是入口换成了对话。下面这个 Spark SQL 作业死在运行期:SQL 能过语法与权限预检,真正执行到 executor 上才因数据校验不通过炸掉。诊断不但给出根因,还采到了不满足条件的具体反例值,连「这个任务在自读自写同一张表,源数据本身就是脏的」这种上下文都指了出来:

问「实例 #991465 为什么失败了」,工小数给出诊断:结论为数据质量校验失败(assert_true 硬校验不通过)而非 SQL 语法或资源问题;根因指出 SQL 用 assert_true(o.amount > 1000000) 做硬校验,但实际采样到 amount=117.62 的不满足行,Spark 对表达式求值不为 true 时抛 RuntimeException;附关键错误堆栈;还注意到该任务自读自写同一张表;修复建议三条:核对阈值是否合理(并提示 cast 为 decimal(7,0) 的精度问题)、清洗源数据、把硬校验改成 WHERE 过滤或旁路告警

展开「思考过程」能看到诊断的完整取证链就在对话里:错误日志关键段(含异常链)、运行信息(申请了多少资源、跑了多久、谁触发的)、作业配置与 SQL 源码——结论里的每一句都能对回证据:

思考过程展开:诊断·get_error_log 显示 exitCode=1、日志关键段与完整异常链(RuntimeException: (amount#1 > cast(...)) is not true);诊断·get_run_info 显示申请资源 CPU=0.5核 内存=512MB、起止时间、触发者;诊断·get_job_config 显示作业未覆盖平台默认配置,并附出错的 INSERT INTO ... assert_true SQL 源码

诊断能力本身的设计(证据采集器、agentic 取证循环、规则兜底)与更多引擎案例见智能诊断。

为多人同时使用做的兜底 ​

  • 按空间隔离:对话历史、纠错记忆、可检索的文档与模型都以工作空间为边界,别的空间看不到
  • 有身份、有额度:每个问题都在提问者的权限下执行,工具内重新鉴权;单用户与全平台各有并发/成本闸,防止一个重度用户拖垮大家
  • 降级不摆烂:模型暂时不可用时自动降级为纯知识库检索/规则诊断,仍给出最相关的资料与来源,而不是白屏等待

前端呈现 ​

登录后任意页面右下角的悬浮按钮唤起,面板贴右侧纵向拉满、可拖宽。回答流式逐字输出,跑偏可随时中断;支持多轮追问(「那它的分区键呢」这类指代会自动补全),超长会话早期内容自动压缩保留。顶部「历史」可回看、重命名、删除过往会话。

回到核心能力总览 →