你有没有遇到过这样的情况——
买了AI工具，问它"上个月提了多少货"，它答非所问。问它"某个客户的欠款情况"，它说"我无法访问您的业务数据"。
这不是AI不够聪明，而是AI不认识你的业务数据。
AI大模型训练时用的是互联网公开数据，而你的业务数据（客户、订单、库存、供应商……）是私有信息，AI从来没"见过"。它不知道你系统里"提货"对应哪个表，不知道"金额"是哪个字段，更不知道业务上有什么过滤规则。
那怎么办？传统做法是写代码把每个问题对应到数据库查询——但业务规则那么多、问法那么灵活，写死代码根本维护不过来。
这就是RAG要解决的问题。
一、什么是RAG？
RAG（Retrieval-Augmented Generation，检索增强生成）——一个很技术的名字，但道理很简单：
给AI配一本"业务字典"。
- 字典里写着你系统的数据结构：有什么用、有哪些字段、什么业务规则
- 用户提问时，AI先查字典，再去回答
- 字典更新了，AI自然就知道了
一个比喻
| 场景 | 纯AI | 纯手写代码 | RAG（字典方案） |
|---|---|---|---|
| 问"7月提货数据" | AI猜 | 程序员写好SQL | AI查字典→自动生成 |
| 改了业务规则 | AI不知道 | 改代码、重部署 | 改字典，立即生效 |
| 新增了一个模块 | AI不知道 | 重新写代码 | 字典加一页即可 |
RAG的优势一句话总结：知识（业务逻辑）和代码（技术流程）分离。 知识变了只改文档，流程变了只改代码，互不影响。
RAG 在问数智能体中的位置
从上一篇文章我们知道，问数智能体的核心流程是：
用户提问 → 理解意图 → 检索知识（RAG） → 生成查询参数 → 查数据 → 返回结果
RAG 就在"检索知识"这一步。它的作用是把用户的问题和你的业务数据"搭上线"——没有 RAG，AI 不认识你的数据；有了 RAG，AI 就"懂"了。
二、"业务字典"长什么样？
我们以 EDOAPP 供应链系统为例。系统中有一个"提货单"模块（edoapp.order），在 RAG 的知识库里，它是这样描述的：
模型： edoapp.order（销售提货单——提货主表）
用途： 供应链系统中的销售提货主单据，对应业务中的"出库""提货"操作。
关键字段：
- fnumber：销售提货单编号（唯一标识）
- fdate：提货日期
- fcustomer_id：提货客户
- forder_ytqty：实提件数
- state：单据状态（draft草稿/submit提交/done审核/check确认/received收货/cancel作废……）
业务规则：
- 查询时默认过滤掉草稿/提交/作废状态的单据
- 需要查看明细时，通过 fordermx_ids 关联明细表
这份文档不会写进 AI 的 Prompt 里（那样太长），而是存进一个向量数据库。用户问问题时，系统自动检索出跟问题最相关的几份文档，然后送给 AI 参考。
注意：知识文档用 YAML 格式编写，内容就是业务人员能看懂的描述，不需要写代码。改业务规则时，业务人员直接改文档就行。
知识库的组成
| 文档类型 | 数量 | 示例 |
|---|---|---|
| 模型定义 | 每个业务模块一个文件 | edoapp_order.yaml、edoapp_contract.yaml…… |
| 关联路径 | 一个文件 | 描述表与表之间的关系 |
| 业务规则 | 一个文件 | 全局通用的过滤条件 |
初期只需要覆盖 5-8 个核心模块，后续按需扩充。
三、如何保证AI不乱说？
这是所有技术决策者最关心的问题——RAG 检索错了怎么办？AI 会不会胡说？
我们设计了三重保障：
第一重：Top-K 检索 + AI 判官
用户提问后，系统会从知识库中检索出最相关的 5 条知识，全部送给 AI。
但 AI 不会全信——它会自己判断哪几条与当前问题相关，不相关的一律忽略。
5 条保证不遗漏，AI 自己判断保证不误用。
第二重：自动重试
如果 AI 生成的查询执行后返回空结果或字段错误，系统会自动触发重试机制：
首次查询失败 → 扩大检索范围（从5条扩大到10条）→ AI 基于更丰富的上下文重新生成 → 再次查询 → 仍失败 → 返回友好提示，标记为异常
第三重：人工复盘
所有异常查询都会自动记录日志，内容包括：用户问了什么、检索到了哪些知识、AI 生成了什么查询参数、哪里出错了。
定期（上线初期每天看，稳定后每周看）检查这些日志，发现问题是知识缺失还是 AI 理解错了，针对性修复。
这也是"智能体越用越聪明"的基础——没有复盘就没有优化。
四、与纯编码方案的对比
| 对比维度 | 纯编码方案 | RAG 方案 |
|---|---|---|
| 改业务规则 | 改代码 → 测试 → 重部署 → 重启服务 | 改一个 YAML 文档，立即生效 |
| 增加新模块 | 重新写一套查询逻辑 | 加一个 YAML 文档即可 |
| 灵活问法 | 用户必须用系统预设的关键词 | "提货""出库""发货"都能理解 |
| 维护成本 | 代码量随时间线性增长 | 知识文档随使用自然积累 |
| 冷启动 | 一次性全部写完才能用 | 先写核心模块，后续按需补充 |
| AI 幻觉 | 硬编码不会出错（但只能处理预设场景） | 有检索到的知识作为依据，降低猜错概率 |
结论： 对于数据量大、规则频繁变动、问法灵活的"问数"场景，RAG 是更合适的方案。前期多花一天写知识文档，后期少花无数天改代码。
写在最后
RAG 不是什么高深的技术，它的本质就是给 AI 配一本业务字典，让它能读懂你的数据。
对于企业级 AI 应用来说，这是最关键的一步——不是让 AI 更聪明，而是让 AI 更"懂你"。
下一篇文章，我们会聊聊这套系统如何越用越聪明——智能体的自学习与持续优化机制。
我是唐朝，做了23年企业信息化，财小智/EDOAPP创始人。如果你对AI技术在业务数据查询中的应用感兴趣，欢迎评论区交流。