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

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

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

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

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

AI 应用常见 4 类：

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

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

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

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

传统问数的流程一般是：

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

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

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

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

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

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

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

可以抽象出的动作

我们可以从智能问数里抽象出四个动作，基本可以套到大多数 AI 应用上：

1. 知识检索 模型不知道你的业务、表、指标，我们要把本地知识库的相关知识作为上下文的一部分传入给大模型。
2. 结构化输出 让模型不是乱说，而是说成固定 JSON / SQL / DSL。 这一步是“让模型说成机器能用的东西”。
3. 工具调用 模型不是终点，它是“写 SQL”或“选工具”的那个人，真正的数据在数据库里。 这一步是“让模型带你去用外部世界”。
4. 安全控制

大模型的输入输出都要进行安全、权限相关的校验。 这四个动作加起来，就是“AI 应用到底在忙什么”的答案。

AI应用与传统 Web 项目的区别

看起来都在写接口、写控制器、写前端，但核心区别有几条：

1. 输入不是确定的

Web 项目里，前端表单帮你把输入约束死了；AI 项目里，用户随口一句话，模糊、歧义、漏信息都得你来兜底。所以你会多出意图识别、澄清、安全校验这类步骤。

2. 业务知识不是写死在代码里的

传统项目里，“退款订单字段叫啥”是在代码里、在表结构里；AI 项目里，为了让模型知道，你得把这些知识“放到一个可检索的地方”，然后在运行时喂给模型。这就是 RAG 的那半边工程量。

3. 模型输出要再加工

Web 里，代码的输出就是最终输出；AI 里，模型的输出往往只是“候选结果”，你要再做校验、再做提示、再做解释，甚至要自动生成“你可以继续问：xxx”这种引导。

4. 观测和评估更重要

因为模型不稳定，所以你要有日志、链路追踪（LangSmith/LangFuse）、prompt 版本、数据集回放，去看哪一步容易出错，哪种问题没法生成合法 SQL，这样才能迭代。 传统 Web 很多时候只看错误日志就够了。

5. 运维对象变了

不只是服务要上线，知识库、prompt、模型版本、工具权限也都是需要运维的对象，这在传统 Web 里是几乎没有的。

可以这么总结：传统 Web 是“我已经知道要做什么，只要把它做对”；AI 应用是“用户说了个大概，我得一步步把这个大概变成可以执行的东西”。