布吉岛 Agent

Appearance

12.5.1 结构化数据和非结构化数据怎么一起做 RAG？ ​

先给结论：结构化数据要靠“查询”，非结构化数据要靠“检索”。它们能一起做 RAG，但必须明确分工，再把结果融合。

结构化数据（数据库、指标、表格）天然适合 SQL/过滤，非结构化数据（文档、手册、邮件）适合向量/关键词检索。把二者混在同一检索器里，反而会失真。

一个可落地的混合结构 ​

最稳的结构是“双通道检索 + 结果融合”：

  1. 结构化通道：SQL/过滤检索
  2. 非结构化通道：向量/关键词检索
  3. 融合排序：按任务权重合并结果

可视化理解就是：结构化数据走“查询”，文本走“检索”，最后合并。

典型实现方式 ​

1. SQL + 文本检索并行 ​

  • SQL 查指标、字段、事实
  • 文本检索查解释、背景、条款
  • 最后合并成“事实 + 解释”

示意伪代码：

python
def hybrid_rag(query):
    sql_result = run_sql(query)        # 结构化事实
    text_docs = retrieve_text(query)   # 非结构化解释
    return merge(sql_result, text_docs)

2. 结构化过滤 + 向量检索 ​

如果结构化信息能转成过滤条件（如业务线、时间、地区），可以用：

  • 结构化过滤缩小范围
  • 向量检索在范围内找证据

示意：

python
def filtered_retrieval(query, filters):
    return vector_retriever(query, filters=filters)

3. RRF / 规则融合 ​

当两路结果需要统一排序时，可以用简单融合策略，例如：

  • 结构化结果优先
  • 文本结果补上下文
  • RRF 或加权融合

什么时候这种方式最值得用 ​

只要问题同时包含“事实 + 解释”，你就应该考虑混合：

  • “某指标的值是多少，并解释原因”
  • “某条规则如何计算，并给出来源”
  • “某用户是否满足条件，并给出依据”

常见误区 ​

误区一：把结构化数据向量化 ​

结构化数据的价值在于“可查询”，向量化会丢掉可控性。对结构化数据，优先 SQL 或过滤。

误区二：只用 SQL 就够了 ​

SQL 能给你事实，但给不了解释。没有文本检索，答案会变成“数字 + 空白解释”。

误区三：把所有结果混成一堆 ​

混合的关键是“融合有逻辑”。你必须说明结构化结果优先级、权重或最终展示方式。

自检清单 ​

  • 结构化与非结构化是否明确分工？
  • 是否有融合策略，而不是简单拼接？
  • 结果能否形成“事实 + 解释”的完整闭环？

一句话总结 ​

结构化数据靠查询，非结构化数据靠检索。RAG 要做的不是“混在一起”，而是“分工检索 + 结果融合”。