AI 问数能分析 JSON 和半结构化数据吗？先处理路径与数组

很多企业数据并不是干净的行和列。

订单的商品明细可能放在 JSON 数组里，设备上报数据可能嵌套多层属性，用户事件日志里同一个字段甚至可能在不同记录中出现不同类型。

AI 可以生成查询 JSON 的语句，但如果没有稳定的结构定义，很难保证每次都取到相同含义的数据。

JSON 不是“不用建模”

半结构化数据的优势是灵活，但灵活不代表没有结构。在提供给 AI 之前，至少要明确：

• •哪个路径代表业务字段；
• •字段是文本、数值、布尔值还是时间；
• •空值、缺失路径和空字符串是否同义；
• •数组是一个整体，还是需要展开为多行；
• •结构版本变化后如何兼容历史数据。

Snowflake 的半结构化数据文档将 JSON、Avro、ORC、Parquet 等数据作为 VARIANT 处理，但查询时仍需要使用路径和类型转换。这正说明了：存储灵活，分析口径仍需明确。

数组展开会改变粒度

一张订单表每行是一笔订单，其中 items 数组有多个商品。

如果展开数组，每行就会变成一个订单商品。此时直接求和订单金额，可能按商品数量重复计算。

因此需要将：

• •订单粒度指标；
• •订单商品粒度指标；
• •用户、订单、商品之间的关系；

分别建模，不能让 AI 在每次问题中临时决定。

先稳定高价值字段

不必把每个 JSON 属性都拆成一列。

更实用的方法是：

1. •找出高频业务问题；
2. •确定所需的路径和展开规则；
3. •将稳定字段物化或封装成标准视图；
4. •保留原始 JSON 供追溯和新场景探索；
5. •监控结构变化和类型异常。

Databricks Auto Loader 支持在增量接入中推断和演进 Schema，但生产环境仍需要对结构变化设置处理规则。

BuildTable 和 AskTable 的分工

BuildTable 可以先将嵌套路径、数组粒度、数据类型和业务含义整理成稳定的结果表或语义模型。AskTable 再基于这些模型回答问题，避免在每次对话中反复解析复杂 JSON。

结论

AI 问数可以分析 JSON，但不应直接把一个庞大、经常变化的对象丢给 AI。

先稳定路径、类型、粒度和语义，再保留原始数据的可追溯性，才能同时兼顾灵活性和答案稳定性。

参考来源

• •Snowflake：Semi-structured data concepts
• •Databricks：What is Auto Loader?