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 图表推荐要先识别分析任务，再结合字段类型、基数和可读性规则选择图表。模型可以帮助理解问题和生成解释，但图表规则需要可测试、可回溯。推荐结果要说明依据，并允许用户修改。好图表不是更花，而是让问题更容易被回答。
五、总结
本文介绍的方案在实际项目中需要经过充分验证后再全量推广。建议先在灰度环境中观察关键指标的变化，确认无异常后再逐步放量。技术在不断演进，保持学习和实践的心态，才能在架构设计上走得更远。如果在实际落地过程中遇到问题，欢迎在评论区交流讨论。