从脑补到实战：我的智能图表推荐器追问机制实现与翻车反思

大模型应用开发不是简单的调用api

我在刚开始写这个项目的时候觉得”我都用 AI 了为什么还要写这么多逻辑”，不是简单的给ai套个壳子就能有不错的效果了吗，后来发现事情没有我想的那么简单

这本质上是调用功能和构建产品的区别

调用功能：

# 调一下 df.chat()，它只能算个 Demo
result = df.chat("帮我分析这个数据")

构建产品：

  • 处理脏数据
  • 提供图表推荐
  • 设计追问机制
  • 管理 Session

这些才是让 OpsMind 能在真实办公场景下不”翻车”的核心竞争力。

大模型应用的本质

大模型应用不是简单的”调 API”，而是构建一个完整的产品系统。LLM 只是其中一个组件，真正的价值在于如何将其与业务逻辑、数据处理、用户体验有机结合。

1. 缘起：图表推荐，只给类型是不够的

最近在折腾智能图表推荐系统。做过数据可视化的同学都知道，系统告诉你”这组数据适合散点图”只完成了 30% 的工作。剩下的 70% 痛点在于：

  • 到底哪一列该放 X 轴？
  • 哪一列是 Y 轴？
  • 是否需要图例（Legend）分组？

为了解决这个映射问题，我闭关写了一套混合模式的追问机制。当时我觉得方案已经非常闭环了：能推断的直接出图，不确定的再来问用户。

2. 方案设计：既要智能，又要掌控感

我设计的核心是混合模式（Hybrid Mode）。

快速通道

利用 LLM 强大的语义理解能力，直接分析用户的 Query 和数据特征（Data Features），给出置信度高的列映射。

透明展示

系统不搞”黑盒”，推断结果会清晰地展示给用户。

追问流程

如果 LLM 只有 50% 的把握，或者发现数据中存在多个可能的数值列，系统会触发 ClarificationQuestion。

为了支撑这个机制，我重构了底层数据结构，定义了 ChartColumnMapping（列映射）和 ChartInference（推断结果）等数据类，并为 15 种常用图表配置了严格的属性要求（CHART_REQUIREMENTS）。

# 核心数据类：让推断结果结构化
@dataclass
class ChartInference:
    chart_type: str                   # 图表类型
    column_mapping: ChartColumnMapping # 具体的列映射方案
    confidence: float                 # 置信度 (0-1)
    needs_clarification: bool = False # 是否需要反向追问用户

3. 翻车现场：当”脏数据”遇到”理想逻辑”

代码写完，本地测试集跑了一遍，全绿通过。我志得意满，觉得这套 450 行代码的逻辑已经无懈可击了。

正好有个朋友在做业务分析，我拉他来当首位”受害者”。结果他顺手甩给我一张真实业务场景的表格——我当场就傻眼了。

真实场景的不实用

那是一张完全没有经过清洗的数据：

表头命名随心所欲：有的叫 col_1，有的叫 tmp_data_v2。

数据类型混乱：本该是数值的列里混着”暂无”、”N/A”甚至是注释。

冗余信息爆炸：一张表几十列，LLM 在分析语义时被大量的无关干扰项带跑了。

理想逻辑的溃败

我预设的”根据列名和特征自动推断”在这些脏数据面前溃不成军。LLM 给出的映射结果置信度极低，甚至直接把日期列映射到了 Y 轴。

而我设计的追问机制，因为原始数据太乱，生成的选项（Options）里塞满了垃圾信息，用户看着几十个乱七八糟的列名，根本选不出来。

那一刻我意识到：做的项目要贴合真实场景从用户角度出发，光是跑自己的东西那只能叫工具

4. 核心实现回顾（虽然翻车，但逻辑依然是骨干）

虽然在脏数据上吃到了教训，但这套追问机制的骨架依然是必要的。我主要实现了以下几个核心方法：

infer_column_mapping()：这是大脑

负责调用 LLM 把用户那句”看看去年的销售趋势”翻译成 x_axis='date', y_axis='sales'。

check_clarification_needed()：这是守门员

当置信度低于 0.7，或者候选列太多时，它会强行切断自动流程，进入追问模式。

generate_clarification_questions()：这是外交官

它会根据图表需求（比如柱状图需要一个分类轴和一个数值轴）生成交互问题。

# 追问流程的示例
if results[0]["inference"]["needs_clarification"]:
    # 自动生成针对性的问题，比如"哪一列代表你想分析的分类？"
    clarification = recommender.generate_clarification_questions("bar", df, inference)
    # 展示给用户进行手动修正

5. 痛定思痛：下一步计划

这次”翻车”让我清醒了。对于非专业用户来说，他们可能连自己的数据里有哪些异常值都不知道，指望他们能通过简单的追问完成复杂的映射是不现实的。

下一步改进计划

我打算在推荐器之前增加一个”预处理与诊断层”：

  1. 自动检测脏数据：在推断前先给数据”把脉”，识别格式错误和缺失值。

  2. 智能列清洗建议：不仅仅是问用户选哪一列，还要提示用户”这一列有非数值字符，是否需要我帮你剔除？”

  3. 语义降噪：先利用 LLM 对所有列名进行一次语义降维，过滤掉无关的冗余列。

总结

好的工具不应该只是”聪明”地处理正确的信息，更要”强壮”地面对混乱的现实。

开发任务还在继续，预处理功能，安排！

最后的思考

从”调包侠”到”架构师”的转变，本质上是从”使用工具”到”创造价值”的进化。

  • 调包侠关注的是：这个 API 能做什么？
  • 架构师思考的是：这个产品如何解决真实问题？

大模型应用开发不是简单的 API 调用，而是需要你理解业务场景、设计合理架构、处理边界情况、提供良好体验的完整工程实践。

这才是真正的 AI 应用开发。