AI 图表推荐：先判断分析任务，再决定可视化形式

AI 图表推荐先判断分析任务再决定可视化形式一、图表推荐不是把字段丢给模型选样式智能可视化工具常提供“自动推荐图表”。用户选择字段后系统自动生成折线图、柱状图、饼图或散点图。这个功能看起来简单但如果只根据字段类型判断很容易推荐错误图表。时间字段加数值字段不一定总是折线图分类字段加占比也不一定适合饼图。图表选择首先取决于分析任务。是看趋势、比较、构成、分布、相关性还是异常点。字段类型只是输入条件不是最终答案。AI 图表推荐应先识别用户要回答的问题再选择图表。为什么仅凭字段类型推荐图表一定会翻车给你两列数据date日期、revenue金额。按字段类型匹配系统大概率推折线图——但用户可能想看的是各周收入分布该用直方图也可能是收入和营销费用的相关性该用散点图。同一组字段对应至少 5 种不同的分析意图每种意图的正确答案都不一样。更坑的是很多数据工具把推荐等同于猜你喜欢——用户选了俩字段它随机甩一张图出来用户也不知道对不对就凑合用了。图表推荐的第一原则在不知道分析意图时宁可推荐表格也不推荐错误的图表。二、把分析意图映射到图表候选推荐链路可以分为意图识别、字段校验、图表候选和可读性检查。模型可以参与意图识别但图表规则最好结构化维护。flowchart TD A[用户问题] -- B[分析意图识别] C[字段元数据] -- D[字段适配检查] B -- E[图表候选] D -- E E -- F[可读性评分] F -- G[推荐图表] G -- H[生成解释]可读性评分很重要。分类项太多时不适合饼图时间点太少时折线图价值有限数值跨度过大时需要对数坐标或分面。为什么可读性评分这个环节被 90% 的 BI 工具忽略饼图有个硬伤人眼对角度差异的辨识精度远低于长度差异。6 个分类在饼图里还能勉强区分12 个分类时那些占比 5% 的扇区挤成一团标签互相重叠用户盯着图看了 10 秒只能读出有大的有小的——这种图没有任何信息量不如一个表格。很多 BI 工具为了好看强行画饼图用户为了做了分析默认接受双方默契地生产了一堆无效可视化。可读性评分要做的事当分类数 6 时自动降级为柱状图当时间点 3 时折线图降级为数值卡片当数值跨度超过 1000 倍时强制切换到对数刻度并标注。这是规则不是 AI 的判断——规则错了能修AI 的觉得没法追责。三、用规则层兜住基础推荐下面示例展示一个非常简化的推荐器。真实系统可以更复杂但规则层应该可测试。def recommend_chart(intent: str, field_count: dict, cardinality: int) - str: if intent trend and field_count.get(time, 0) 1: return line if intent compare and cardinality 20: return bar if intent composition and cardinality 6: return stacked_bar if intent distribution: return histogram if intent correlation and field_count.get(number, 0) 2: return scatter return table默认返回表格并不是退步。表格在很多场景里比错误图表更诚实。可视化的目标是让比较更清楚不是每次都画出图。四、推荐结果要说明为什么也要允许用户改AI 推荐图表时应说明推荐依据。例如“选择柱状图因为当前任务是比较不同渠道的转化率分类数量为 8”。这个解释能帮助用户判断是否接受。还要避免自动聚合带来的口径问题。用户选择订单金额系统不能悄悄决定求和还是平均。聚合方式必须可见并能回到指标定义。图表推荐如果绕过指标口径就会让看板变得不可信。为什么自动聚合是 BI 工具里最大的信任杀手一个真实案例运营拖了order_amount订单金额字段系统默认按 SUM 聚合柱状图显示营销渠道 A 的订单金额是 500 万渠道 B 是 300 万。运营得出结论A 渠道更好加大投入。但渠道 A 的客单价是 10000 元B2B 大单渠道 B 的客单价是 200 元B2C 零售——按订单数看 B 渠道是 A 的 5 倍。系统用 SUM 画图运营没注意到聚合方式是 SUM一个亿级预算决策就这样被一个默认聚合带偏了。图表推荐系统必须显式展示聚合方式且不能由 AI 决定——SUM/AVG/COUNT 的选择是业务判断不是技术判断。最后推荐系统要收集用户修改。用户把饼图改成条形图把折线图改成面积图这些都是反馈。但反馈要结合场景不要全局学习成固定偏好。推荐结果还要考虑数据量。明细点太多时散点图需要采样或密度图分类项太多时柱状图需要 TopN 和“其他”合并时间跨度太长时要自动切换到周或月粒度。图表推荐不是单点选择而是图表、聚合粒度和数据抽样一起决定。 踩坑提醒不要把用户修改图表的行为 100% 学成固定偏好用户上次把饼图改成柱状图不代表他永远喜欢柱状图——可能上次只是因为分类太多饼图看不清。直接拿修改历史做训练数据会导致推荐越来越窄。正确的做法是记录修改的上下文修改时数据的分类数、时间范围、指标类型只在相似场景下提升对应图表的推荐权重场景不同时权重清零。否则推荐系统会退化成每次只推那几种图的笨蛋。散点图的数据量超过 10000 点时必须自动采样或切密度图不能靠前端硬扛ECharts 的散点图在 10000 点以上开始明显卡顿100000 点时浏览器直接弹页面无响应。很多 BI 工具把数据全丢给前端让浏览器渲染几万个 SVG circle 元素每个 circle 都是一个 DOM 节点——这不是图表这是内存炸弹。规则点数 5000 自动切 Hexbin 密度图 10000 用 LTTB 采样降到 3000 点 100000 只展示聚合统计值。推荐系统的图表规则必须可测试不能全交给 LLM 黑盒决策如果你的推荐逻辑是把字段和用户意图发给 GPT让它选图表那测试时今天的推荐和昨天的推荐可能不一样模型更新、temperature、上下文窗口。一个财务月报今天推荐饼图明天推荐柱状图业务方直接怀疑数据有问题。规则层字段类型→图表映射用确定性代码实现 单元测试覆盖LLM 只负责用户意图识别和推荐解释生成这两个模糊任务。规则打底、AI 润色不要反过来。AI 图表推荐要先识别分析任务再结合字段类型、基数和可读性规则选择图表。模型可以帮助理解问题和生成解释但图表规则需要可测试、可回溯。推荐结果要说明依据并允许用户修改。好图表不是更花而是让问题更容易被回答。五、总结本文介绍的方案在实际项目中需要经过充分验证后再全量推广。建议先在灰度环境中观察关键指标的变化确认无异常后再逐步放量。技术在不断演进保持学习和实践的心态才能在架构设计上走得更远。如果在实际落地过程中遇到问题欢迎在评论区交流讨论。