← 返回文章列表

数据库里的结构化数据,怎么建立 RAG 知识库?两条路线与选型判断

方案认知(待实测回填,2026-08-28)。

📖 摘要:前面聊过文档怎么清洗进知识库,但有朋友问:数据存在数据库里(订单表、客户表、规格表),怎么建 RAG?这篇文章讲清楚一个关键认知——数据库数据建 RAG 的难点不在清洗,在「语义化」:结构化记录(字段名+值)直接向量化是语义哑的。给出两条路线(数据转文档 / 查询即上下文)、Dify 落地四路径、和一张选型判断表。方案来自工程实践推断,标注待实测回填。

导读

一、业务场景:文档清洗完,该轮到数据库了

我们之前聊过 RAG 建库前怎么清洗文档(PDF/Word/Markdown → 清洗管线 → 知识库),这套流程解决的是「文档形态」的问题。但知识型业务里还有一大块数据不在文档里——在数据库里:

这些数据有字段、有结构、还能精确查询——但想让它变成「能回答自然语言问题的知识库」,直接灌进去是不行的。

二、场景痛点:结构化数据直接向量化,语义是哑的

把数据库表直接导成文档进知识库,会撞上两个硬问题:

  1. 语义鸿沟。向量检索按语义匹配。但结构化记录长这样:
{customer_id: 10023, status: active, region: 华东}

用户问「我们有多少华东区在跟进中的客户?」——这条记录的向量里没有「跟进中」「华东区」这种自然语言表达,status=active 和「跟进中」在向量空间里离得很远,检索召不回。字段名+值不是语言,是编码。

  1. 动态性。文档入库是一次性快照;数据库每时每刻在变。今天入库的订单表,明天就有新订单——快照知识库回答的永远是「建库那天」的数据。

所以数据库建 RAG 的正确问题不是「怎么清洗」,而是两个前置问题:要不要入库?入库前怎么转成语言?

三、解决方案:两条路线

路线 A:数据转文档(入库型)

把数据库记录转写成自然语言段落,然后走文档建库管线(转换 → 清洗 → 门禁 → 分段 → 建库)。

graph TD A["数据库表"] --> B["SQL 导出 CSV/JSON"] B --> C{"转写方式"} C --> D["模板转写:字段拼句子"] C --> E["LLM 转写:改写成自然语言段落"] D --> F["清洗管线 + 质量门禁"] E --> F F --> G["知识库建库"]

转写示例(模板转写):

原记录:{id: WZ-1000, temp_range: -10~60℃, protocol: [Modbus, MQTT]}

转写后:「WZ-1000 工业网关支持 Modbus 和 MQTT 协议接入,

设备工作温度范围 -10℃ 到 60℃。」

转写后它就是一篇文章,复用现有清洗质量门禁——但数据库场景门禁重点不同:

门禁项 文档场景 数据库场景重点
自包含 单段可答 一条记录转一段,段内完整(问温度范围命中即答全)
脱敏 正文敏感词 字段级剥离:用户 ID/手机号/身份证,转写前决定哪些字段入库
去重 重复段落 多表 join 导出易重复

路线 B:查询即上下文(直查型)

不建向量库。工作流里用 HTTP 节点调数据库 API → 查到的记录直接拼进 prompt 作上下文。

适合动态、精确的数据:订单状态、库存余量、用户信息。「这个订单什么状态」本质是一条 SQL——确定性查询,向量检索既答不准(语义哑)又答不快(要索引)。直接查库,把结果喂给 LLM,又快又准。

四、Dify 落地路径

路径 机制 适合 限制
导出 → 转写 → 上传建库 SQL 导出 → 转写 → 清洗 → 文档上传 静态字典/规格/FAQ 快照时效;大批量需分批
工作流 HTTP 直查数据库 HTTP 节点调后端 API → 结果拼上下文 实时精确查询 需要可查询 API;结果要转自然语言
外部知识库 API(企业版) external-knowledge-api:外部检索服务返回结果给 Dify 已有检索服务、要保留结构化查询 企业版特性;需自建检索服务
混合 精确字段直查 + 语义描述走向量库,工作流分流 大而全的系统 设计成本高

五、选型判断

数据特征 建议
静态 + 语义问答需求(规格/FAQ/台账) 路线 A:导出 → 转写 → 建库(走清洗门禁)
动态 + 精确查询需求(订单/库存/状态) 路线 B:工作流直查,不建向量
静态 + 量大 + 低更新频率 路线 A 分批入库 + 定期重建(快照策略)
需要结构化过滤(按厂商/型号/状态筛) 入库 + Dify 元数据字段打标

六、与「文档建 RAG」的边界澄清

七、待实测

以下为方案推断,落地后回填实测数据:

八、启示

数据库建 RAG,本质是把「编码」翻译成「语言」——字段名和值在向量空间里是哑的,只有转写成自然语言后才进入 RAG 的适用域。而判断要不要做这一步翻译,标准很简单:数据静态 → 值得翻译(入库);数据动态 → 别翻译了,直接查(直查)。

一句话:文档是「清洗后入库」,数据库是「转写后入库或直查」

相关文章:把企业手册变成会答话的机器人:企业知识库问答怎么做(文档型知识问答的对照)|RAG 知识库建库前,数据到底该怎么清洗?一条可复用的清洗管线实测(清洗管线)|RAG 知识库交付实战(下):18 条用例与成本测算(用例与成本测算)

本文为路径与选型认知分享,方案基于既有文档建库工程实践推导,完整数据库接入流程标注「待实测回填」。文中数据均来自我们自己的实测记录(文档清洗/质量门禁部分),理论与推断部分以「待实测」标注边界。

这些 AI 应用能力,如何交付到真实业务场景?看看方案与服务 →
本系列 · Dify 实战
  1. Dify Agent 应用实战:Beta 版「真 Agent」的能力边界实测
  2. Dify workflow 与 Hermes Agent skill 的确定性对比
  3. Dify 意图分类节点总翻车?从 33% 失败率到兜底不崩——可靠性与韧性的三层加固
  4. Dify 标注回复实战:让智能客服记住人工答案的纠错闭环
  5. Dify 知识库元数据过滤实战:检索噪声 75% 降到 0 的确定性闸门
  6. RAG 建库,如何自动设置分段模式
  7. RAG知识库,如何进行持续更新运维
  8. RAG知识库的元数据过滤能力边界
  9. 数据库里的结构化数据,怎么建立 RAG 知识库?两条路线与选型判断
  10. 流程卡在「等人审批」?把审批链接送到企业微信和邮箱
  11. Dify 1.17 升级实测(一):从工作流平台到 Agent 平台,升级前必须知道的 5 件事
  12. Dify 应用上架门户:分享页每次回答都挂着内部流程节点?一个字段关掉
  13. RAG 知识库交付实战(上):4277 页手册喂给 AI——从凌晨故障到三模块方案
  14. RAG 知识库建库前,数据到底该怎么清洗?一条可复用的清洗管线实测
  15. 我们的门户机器人,为什么用 Dify 答、不把 skill 搬上云端 Hermes?
  16. 知识库从需求到交付:清洗、入库、维护全流程,照着走、每一步都能验证
  17. Dify 1.17 升级实测(二):Agent V2 节点与技能包实测——配置在数据库,不在 DSL
  18. RAG 知识库交付实战(中):三大深坑与修复实录——流程图截断/限流风暴/并联污染
  19. DeepSeek 思考模式什么情况下可以关?一次空输出事故的排查实录
  20. Dify 1.17 升级实测(三):循环内人工审批与图片直传实测——两个高频场景的新解法
  21. Dify 定时触发(trigger-schedule)实测:工作流到点自动跑,和三个必须知道的坑
  22. Dify 知识库三种分段模式实测:通用、父子、Q&A 到底怎么选?
  23. Dify 知识库接入 Notion/网页:先搞清三件事,再谈清洗
  24. RAG 知识库交付实战(下):18 条用例与成本测算
  25. 知识库数据清洗后,怎么知道洗得干不干净?一套三层质量门禁实测
  26. Dify 实战:供应商报价单格式五花八门,AI 怎么知道哪列是单价?

联系我

邮箱contact@fishsun.cn

点击邮箱直接写信 · 扫码加微信沟通

微信

微信二维码

扫码加微信 · 备注「门户」更快通过