科技Bestblogs·阿里技术··AI 生成
高德 Data Agent 实践：从业务问题到可信数据（上篇）
高德数据团队拆解了 Data Agent 的真实工程难点：不是写 SQL，而是口径对齐与幻觉抑制。文章把业务问题到结论拆成六步，提出「补知识、补能力、卡校验、留兜底」四大支柱，并用「美食行业最近表现如何」全程走了一遍落地路径。最硬的一条是可靠性沿链路连乘——每步 99% 准确，50 步后只剩约 60%，这解释了为何单点优化救不了数据分析 Agent。适合正在做或评估企业级数据 Agent 的工程与数据产品读者。原文 ↗原文 ↗
核心观点
- ▍数据分析的本质是「降维→升维」的双向翻译：把业务问题翻译成可执行查询，再把结果回译为带结论的业务语言，两段翻译的准确性共同决定决策可信度。
- ▍Data Agent 的可靠性沿链路连乘，单步高准确率在长链路下会迅速衰减，因此必须把「补知识、补能力、卡校验、留兜底」作为四根并列支柱来设计系统，而非指望模型单点变强。
- 01文章给出连乘的量化结果：每步 99% 准确时，10 步后整体约 90.44%，50 步后跌至约 60%——这在需要精确结论的数据分析场景里属于灾难性衰减。
- 02流程被明确拆为六步：需求厘清、数据口径确定、查询执行、结果体检、解读判断、反馈闭环，每一步都对应不同的失败模式与工程对策。
- 03「美食行业最近表现如何」被作为贯穿案例，展示 Agent 如何先澄清时间范围与指标口径，再取数、校验、输出结论，而非直接生成 SQL。
- 04作者指出真正的坑不是写 SQL，而是「口径」和「幻觉」：AI 容易对不存在的数据编造答案，必须建立「有没有」校验与门禁规则，让 Agent 在拿不到数据时肯承认没有。
- 05仅有指标字典和元数据字典不够，Agent 需要的是能在运行时「查得到」的知识能力，即把静态文档转化为可调用的上下文与工具。
反方 / 局限
- — 四大支柱的具体实现深度不均：补知识与卡校验有较细的工程方案，而「留兜底」和「反馈闭环」在两段式摘要中着墨较少，其可观测性与成本代价未被展开。
- — 连乘模型隐含假设各步骤错误相互独立且准确率均匀，实际链路中错误可能相关（同一口径错误反复出现），或某几步准确率显著低于其他步，此时衰减曲线与对策优先级会不同。
概念锚点
前置背景
平行视角
未来推演
延伸追问