在 RAG 系统中，“知识”并非只有非结构化的长文本文档。企业环境中大量高价值信息以结构化或半结构化形式存在——数据库中的客户记录、产品目录表格、实时汇率接口等。这些数据同样需要纳入检索增强的范围，让大模型不仅能“读文章”，也能“查表”和“调用数据”。
1. 什么是结构化数据
结构化数据是指具有明确字段定义、格式规整、易于程序查询和处理的信息。典型形式包括：
- 关系型数据库：MySQL、PostgreSQL 中的用户表、订单表、库存表等，每个字段有固定类型和含义。
- 表格/CSV：产品参数对比表、价目表、财务数据报表，以行和列清晰组织。
- API 接口返回的数据：JSON/XML 格式的结构化响应，例如天气查询接口、股票价格接口、客户余额接口。
与非结构化文本相比，结构化数据的取用逻辑截然不同：用户期望的不是“找出相关段落”，而是得到精确的数字、列表或状态值。
2. 结构化数据在 RAG 中的角色
RAG 的经典检索路径是“向量相似度搜索”，这适合语义模糊的文本，但对结构化查询（如“北京地区所有金牌会员的消费总额”）却捉襟见肘。为此，RAG 系统通常通过以下方式接入结构化数据：
- Text-to-SQL：将用户的自然语言问题转换成 SQL 查询，直接运行在数据库上，把查询结果（表或数值）作为上下文提供给生成模型。例如问“上月销量最高的三款产品是什么？”，系统生成并执行 SQL 后，得到产品列表，再由模型组织成易读的回答。
- API 工具调用：为模型配备“调用函数”的能力，当识别到需要查天气、查股价、查订单状态时，主动调用对应的 API 获取实时结构化数据，然后融入最终回答。
- 表格直接嵌入：对于变动不频繁的结构化信息（如产品规格表），可将表格内容转为可读文本切片存入向量库，通过语义匹配召回，或者在检索阶段通过关键字/字段匹配直接抽取。
3. 实用的接入模式
实际场景中，结构化数据的接入往往采用“混合架构”：
模式一：检索+计算分离
- 向量库负责非结构化文档的语义检索。
- 独立的结构化查询引擎（SQL 数据库、API 网关）负责精确查询。
- 问题路由（简单分类器或 LLM 判断）决定走哪条通路，或同时执行，结果合并。
模式二：LLM 即席生成查询
由 LLM 根据用户问题和预定义的库表结构、API 文档，自动生成 SQL 语句或 API 调用代码，执行后获取结果。这种模式对库表结构的描述质量依赖较高，需要将字段含义和表关系以文本形式提前提供给模型（例如在 System Prompt 中描述数据库 Schema）。
4. 一个真实的组合案例
某电商客服 RAG 系统支持如下查询：
- 用户：“我的订单 8821 发货了吗？”
- 系统识别为结构化查询，调用订单查询 API，得到状态：“已发货，顺丰快递 12345”。
- 生成回答：“您的订单 8821 已发货，顺丰运单号 12345，预计 5 月 20 日送达。”
- 用户：“这款手机和那款比，哪个电池容量大？”
- 检索向量库找到产品参数表格的文本描述，提取电池容量字段，对比后生成：“型号 A 电池容量 5000mAh，型号 B 为 4500mAh，A 的电池更大。”
这里的关键在于：系统根据问题类型动态决定是“查接口”还是“搜文档”，并将分散的信息整合在一个自然的回答中。
5. 注意事项与维护要点
- 库表结构的文档化：要提供清晰的 Schema 描述，包括每个字段的业务含义、可能的枚举值。模型需要“看懂”数据库才能生成正确的查询。
- 安全第一：严禁让模型直接执行任何修改性 SQL（DELETE、UPDATE等），只允许只读查询，并且最好通过参数化查询或中间件限制访问范围。
- 数值的时效标记：如果数据来自实时 API，回答中最好注明“当前查询时间为 15:30”，避免用户误以为固定不变。
- 降级与兜底：当 API 超时或数据库连接失败时，应有固定的回复（如“暂时无法查询，请稍后再试”），而不是任由模型猜测结果。
将结构化数据融入 RAG，本质上是扩展了系统的“知识”范畴——从静态的文档记忆，变成能够动态抽取、计算和比对实时业务数据的能力。这带来的不仅是回答准确度的提升，更是业务场景的极大丰富。