数据库里的结构化数据怎么建立 RAG 知识库两条路线与选型判断知识库/RAG · 独立篇 | 方案认知待实测回填2026-08-28 摘要前面聊过文档怎么清洗进知识库但有朋友问数据存在数据库里订单表、客户表、规格表怎么建 RAG这篇文章讲清楚一个关键认知——数据库数据建 RAG 的难点不在清洗在「语义化」结构化记录字段名值直接向量化是语义哑的。给出两条路线数据转文档 / 查询即上下文、Dify 落地四路径、和一张选型判断表。导读目标读者做 RAG 知识库、要接业务系统数据库数据的开发者内容边界本文是路径与选型认知基于文档建库的既有工程实践推导完整落地待实测回填不是已验证的完整教程——文中标注「实测」的才是实测过的部分你会得到为什么结构化数据不能直接向量化、两条路线怎么选、Dify 里四条落地路径、一张选型表一、业务场景文档清洗完该轮到数据库了我们之前聊过 RAG 建库前怎么清洗文档PDF/Word/Markdown → 清洗管线 → 知识库这套流程解决的是「文档形态」的问题。但知识型业务里还有一大块数据不在文档里——在数据库里产品规格表型号、参数、支持协议FAQ 台账问题、答案、分类设备清单设备 ID、厂商、状态、位置规章制度表条款编号、正文、生效日期这些数据有字段、有结构、还能精确查询——但想让它变成「能回答自然语言问题的知识库」直接灌进去是不行的。二、场景痛点结构化数据直接向量化语义是哑的把数据库表直接导成文档进知识库会撞上两个硬问题语义鸿沟。向量检索按语义匹配。但结构化记录长这样{customer_id: 10023, status: active, region: 华东}用户问「我们有多少华东区在跟进中的客户」——这条记录的向量里没有「跟进中」「华东区」这种自然语言表达statusactive和「跟进中」在向量空间里离得很远检索召不回。字段名值不是语言是编码。动态性。文档入库是一次性快照数据库每时每刻在变。今天入库的订单表明天就有新订单——快照知识库回答的永远是「建库那天」的数据。所以数据库建 RAG 的正确问题不是「怎么清洗」而是两个前置问题要不要入库入库前怎么转成语言三、解决方案两条路线路线 A数据转文档入库型把数据库记录转写成自然语言段落然后走文档建库管线转换 → 清洗 → 门禁 → 分段 → 建库。数据库表SQL 导出 CSV/JSON转写方式模板转写字段拼句子LLM 转写改写成自然语言段落清洗管线 质量门禁知识库建库转写示例模板转写原记录{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」的边界澄清本文讨论的「数据库数据」 结构化表数据不是BI/报表分析对话式 BI 是查库出报表语义检索不是核心本文路径与既有清洗管线衔接转写后的文档复用 doc-cleaner 清洗 质量门禁评分/四层验证/污染注入回归——那部分是实测过的见《知识库数据清洗后怎么知道洗得干不干净》结构化数据到底要不要入库与知识承载设计的原则一致判定性/精确查询 → 直查硬路径参考性/语义查询 → 入库RAG七、待实测以下为方案推断落地后回填实测数据模板转写 vs LLM 转写的检索效果对比转写句式对召回分数的影响LLM 转写的 token 成本与质量抽检标准快照重建策略多频繁重建、增量 vs 全量的工程参数混合分流直查 向量的真实设计样例八、启示数据库建 RAG本质是把「编码」翻译成「语言」——字段名和值在向量空间里是哑的只有转写成自然语言后才进入 RAG 的适用域。而判断要不要做这一步翻译标准很简单数据静态 → 值得翻译入库数据动态 → 别翻译了直接查直查。一句话文档是「清洗后入库」数据库是「转写后入库或直查」。 你接过数据库数据建知识库的需求吗走的哪条路线评论区聊聊。本文为路径与选型认知分享方案基于既有文档建库工程实践推导完整数据库接入流程标注「待实测回填」。AI 参与创作声明本文由 AI 辅助写作内容基于作者真实工程实践与推断。