从智能问数，看AI应用到底在做什么

在上一篇我们聊了《AI 应用开发工程师的学习路线》，更多是在说你要学些什么：Python、RAG、Agent、LangChain/LangGraph、工程化等等。但很多人学着学着会冒出一个灵魂疑问：

“AI 应用到底在做什么？不就是把原来调业务接口，换成调大模型接口吗？”

要回答这个问题，用“智能问数”这个AI应用经典项目来拆解是很合适的。因为它涵盖了 AI 应用常做的事情：意图识别、上下文补全、从业务知识里检索表结构/指标定义、让模型写 SQL、做安全校验、执行数据库、再把结果说成人话，还能多轮追问。同时它也好对比：传统 BI、报表、手写 SQL 是怎么干的，AI 是怎么干的，通过对比可以看出AI对业务的赋能。

智能问数的定位：RAG 在结构化数据场景的实践

AI 应用常见 4 类：

Workflow：一条清晰业务链路，模型只是其中一步。
RAG：给模型补数据、补上下文，降低幻觉。
Agent：让模型会“自己决定下一步干嘛”，工具编排更多。
Fine Tuning：让模型更懂你的域。

“智能问数”就是典型的 RAG + 结构化数据实践。社区里像 SqlBot 这一类开源项目，都是同一思路：用户一句自然语言，系统生成一条能跑的 SQL，跑完以后再让模型基于查询结果做解释、做总结、甚至做趋势描述。为什么要 RAG？因为大模型天生只是“根据上下文预测 token 的机器”，它没见过你公司的表、字段、指标定义，更不知道你们 BI 那套“退款订单数”的口径。那就只能在推理时，把这些“本地知识”先检索出来塞给它，让它“好像知道了”——这就是 RAG 的核心：先检索，再生成。

RAG，即检索增强生成。因为大模型本质是根据上下文预测token（后面会专门出文章分析），所以输出本身具备不确定性，会存在幻觉问题。幻觉问题的主要原因是：训练知识不足，某些特定领域在互联网上没有公开资料。而RAG就是缓解大模型幻觉问题的解决方案。它的核心思想是：把特定领域的知识作为一个本地知识库，在把用户问题输入给大模型之前，先通过在本地知识库检索到相关知识片段，把这些片段作为参考资料一起给到大模型。大模型就可以在得到足够上下文的情况下，输出比较准确的结果。了解完RAG的基本概念，我们再来看一下智能问数这个RAG的经典实践是怎么做的。

传统问数项目是怎么做的？

传统问数的流程一般是：

业务人员想问：“上周各航司的退款订单数和退款金额，按金额倒序。”
他得知道去哪张表，或者去问数仓/BI。
他得知道字段名叫什么、怎么 join、时间怎么写。
写 SQL，或者在 BI 工具里点指标、选维度。
执行，导出，看结果。

这套流程的前提是：人知道库里有什么，人能把“我想问的业务问题”翻译成“我知道要查哪张表、哪个字段、哪个时间范围”。

基于AI的智能问数项目是怎么做的？

AI 版多了几层“把人话变成机器能查的东西”的步骤，可以拆成下面几步：

意图识别 把用户的自然语言解析成一个结构化的查询意图，比如任务类型、指标、维度、时间范围、排序方式等。这样后面才能拼 SQL。
知识检索（RAG） 去“本地的业务知识里”查：有哪些表、表的说明、字段的含义、指标的定义、允许的取值……把和当前问题最相关的几段拉出来。这一步就是在解决“模型其实不知道你有哪张表”这个问题。
生成 SQL（大模型生成） 把“用户意图 + 检索到的表结构/字段说明 + 数据库类型 + 示例”一起喂给模型，让模型生成一条候选 SQL。
校验和安全控制 模型写的 SQL 不一定合法，也不一定安全，所以要再过一层规则：

不允许 drop、update、delete；
字段名必须在白名单里；
没写时间范围就补默认时间；
解析 SQL 看看能不能执行。

执行与结果格式化 真正去数据库查询，拿到 rows 之后，再把结果整理成表格、维度统计、甚至直接生成一段自然语言说明：“上周退款金额最高的是 XX 航司，共 2330 元…”。
多轮追问 用户接着问：“那只看国内航司呢？” 系统要能记住上一轮的查询意图，只做增量约束，而不是让用户重说一遍。这就是 AI 应用里很典型的“上下文贯通”。到这一步你就能看清楚：智能问数不是“我问你答”这么轻飘，它是一条“理解 → 检索 → 生成 → 校验 → 调用外部工具 → 再解释 → 支持追问”的完整流水线。