为什么 AI Analytics Tools 正在解决错误的问题

Source: Dev.to

TLDR: AI 分析行业痴迷于构建更好的查询引擎——使用大模型（LLM）把自然语言转换为 SQL。但这只占真实挑战的 20%。剩下的 80% 呢？捕获并维护散落在人们脑海、未记录的会议以及组织五层结构中零散 wiki 里的海量业务上下文。除非我们解决这个不光鲜的文档问题，AI 驱动的分析将只能停留在令人印象深刻的演示阶段，在生产环境中举步维艰。

每一个“与数据对话”的演示看起来都一样。有人在时尚的界面里输入“显示上个月各地区的销售额”。LLM 生成一条 SQL 查询，结果出现。大家点头称赞。

然后你尝试在公司内部部署它。

突然，原本应该简单的问题变得不可能回答。“我们的高级客户收入是多少？”听起来很直接，直到你意识到有三个不同的团队对“高级”有不同的定义，而“收入”在财务和运营眼中意义完全不同。

演示之所以成功，是因为演示使用的是干净、简单的数据。你的现实要乱得多。

Everyone Is Building 的现状

打开任意 AI 分析产品，你会发现其底层架构大致相同。

• 它们连接到你的数据库并获取模式——表、列、数据类型、外键。
• 使用检索增强生成（RAG）在你提问时查找相关元数据。
• LLM 结合这些上下文生成 SQL。
• 执行查询，格式化结果，或许再生成一些洞察。

对于结构良好的数据库的简单问题，这套流程可以工作。“上周的总订单数”或“按消费额排名前 10 的客户”——没问题。

这就是大家争相完善的 20% 分析工作。

那 80% 没人谈论的部分

真正的工作在你走出数据库模式、进入业务含义的混沌世界时才开始。

第 1 层：无处可寻的业务定义

你的数据库里有一个 customers 表，包含 200 万行。很好。但哪些是“高级客户”？

• 是年消费超过 1 万美元的客户吗？
• 你的忠诚度计划中的 VIP 等级？
• 还是拥有专属客户经理的客户？

不同团队会给出不同答案。

再说“高销量门店”呢？是按收入排名前 10%？按交易笔数？按店面面积？答案可能藏在 18 个月前的策略稿里，也可能只在某位在公司工作了五年的老员工脑中。

“高峰时段”听起来客观，直到你发现零售把它定义为上午 10 点‑下午 2 点和下午 5 点‑8 点，而仓库团队则是上午 7 点‑11 点和下午 3 点‑7 点。

这些信息根本不在数据库里。它们是业务知识，必须以结构化方式记录下来，LLM 才能使用。

第 2 层：指标及其隐藏的复杂性

问五个人“收入”是什么意思，你可能得到五种不同答案。

• 收入是否包括待处理订单？
• 退货怎么办？
• 是在折扣前还是折扣后？
• 计入运费吗？
• 税费算不算？
• 是在下单时、发货时还是付款清算时计入？

每个问题的答案散布在组织的各个角落——往往有多个版本，甚至相互矛盾。

你的分析团队可能用一种方式计算“月度经常性收入”，财务部门为董事会采用另一种计算方式，销售仪表盘则因为排除试用而显示第三种数字。

每个指标都需要唯一的真相来源——不仅是英文定义，还要有实际的业务逻辑：条件、排除项、边缘案例，全部记录并维护。

第 3 层：领域特定的业务规则

再加入各业务单元为解决自身问题而做出的决定。

• 市场部在开展活动时排除最近 30 天内有购买的客户。
• 运营部对超过 5 000 美元的订单进行特殊处理。
• 客服对保修索赔的处理方式不同于普通支持工单。
• 财务部的收入确认规则会因产品类型而异。

这些规则是为了解决当下问题而实施的。制定这些决定的人并未考虑下游分析，也没有为未来的 AI 系统记录下来。然而，每一个决定都会影响数据的含义以及解释方式。

第 4 层：技术实现决策

业务需求交给工程团队后，开发者会自行做出选择。

• 他们构建微服务，每个服务拥有自己的数据。
• 他们选择适合业务场景的数据结构。
• 为了性能、API 合约、部署约束进行优化。

于是出现了诸多问题：

• 客户 ID 是字符串还是整数？
• 地址是以结构化字段存储还是自由文本？
• 时间戳是 UTC 还是本地时间？

不同服务会有不同的实现。这些是务实的工程决策，并非“错误”。但数据因此成为运营的副产品，而非首要关注点，而且大多数决策根本没有在任何数据系统可访问的地方记录。

第 5 层：数据平台转换层

最后，数据团队把一切汇总。它们从数十个来源抽取数据，清洗、标准化、转换。

• 通过连接六个不同的客户表创建 dim_customer。
• 通过合并订单、退货、退款和调整数据构建 fact_orders。
• 使用复杂逻辑计算 customer_lifetime_value 等衍生指标。

每一张表、每一次转换、每一个衍生字段都蕴含决策。这个 ETL 作业里嵌入了哪些业务逻辑？为什么要这样转换数据？有哪些假设？处理了哪些边缘情况？

如果没有文档，这些知识只能存在数据工程师的脑子里，或埋在数百行 SQL 代码中。

文档债务危机

把它们加起来：

• 每个业务领域术语的定义
• 每个指标和 KPI 的精确逻辑
• 各业务单元的规则与排除项
• 每个工程团队的技术决策
• 每条数据管道的转换逻辑

这些就是 LLM 生成正确查询以回答真实业务问题所需的上下文。几乎没有任何一项以机器可理解的方式被记录。这就是那 80%。

为什么如此困难

文档编写是手工工作——不光鲜、耗时且永无止境。业务定义会变；今天的“高级客户”可能在下个季度被重新定义。指标会随业务成长而演进。规则会因监管变化而更新。数据平台会重构表和模式。

一旦写好，静态文档立刻就会过时。你需要一个随业务演进而持续更新的活文档系统。

但这到底归谁负责？业务团队专注业务问题；工程团队忙着交付功能；数据团队被管道维护压得喘不过气。没有人真正拥有……