布吉岛 Agent

Appearance

2.2.1 RAG 可以接哪些数据源？ ​

先给结论：只要某类信息能被系统读取、解析、标记和更新，它就有机会成为 RAG 的数据源。

所以 RAG 不是只接“文档”，而是可以接入多种知识来源。

常见的数据源类型 ​

1. 文档类 ​

这是最常见的一类，比如：

  • PDF
  • Word
  • PPT
  • Markdown
  • 纯文本
  • FAQ 文档
  • 产品手册

这类数据通常适合做知识问答，但问题在于格式不统一、结构质量差异很大。

2. 网页类 ​

比如：

  • 帮助中心
  • 博客文章
  • 企业 Wiki
  • 产品文档站
  • 内部门户页面

网页数据的优势是更新方便、结构相对清晰，但也经常混有导航、侧边栏、推荐区和模板噪声。

3. 数据库与业务系统 ​

比如：

  • MySQL / PostgreSQL
  • CRM
  • ERP
  • 工单系统
  • 订单系统
  • 报表系统

这类数据的价值在于结构化强、字段明确、实时性更好，但通常不能直接按“文档问答”的方式处理。

4. 代码与技术资产 ​

比如：

  • Git 仓库
  • API 文档
  • 配置文件
  • 设计文档
  • README
  • Issue 和 PR 讨论

这类数据对开发助手、内部技术问答和代码检索很重要，但它的上下文关系通常更复杂。

5. 表格与报表 ​

比如：

  • Excel
  • CSV
  • BI 报表
  • 指标表
  • 财务表

这类数据的难点在于语义不只在单元格文本里，还在表头、行列关系和统计口径里。

6. 多模态数据 ​

比如：

  • 图片
  • 扫描件
  • 图表
  • 截图
  • 含文字的图片 PDF

这类数据往往需要 OCR、版面分析或额外结构恢复，处理难度明显更高。

不同数据源进 RAG 后的角色并不一样 ​

即使都接入 RAG，它们也不一定扮演同一种角色。

有些数据适合做：

  • 背景知识补充
  • 说明型问答
  • 流程型问答

有些数据更适合做：

  • 精确查询
  • 条件过滤
  • 实时状态读取

所以“能不能接入”只是第一层问题，更重要的是：

这类数据进入系统后，应该走什么样的处理和检索路径。

同一种“可读数据”，进入系统后的处理方式可能完全不同 ​

很多团队一开始会把“能读出来文本”理解成“可以统一塞进向量库”。这通常会出问题，因为不同数据源真正适合的处理方式并不一样。

更实用一点的理解方式是：

  • 文档、手册、FAQ 更适合走“解析 -> 切块 -> 检索增强回答”
  • 表格、工单、订单、客户资料更适合走“字段查询 -> 条件过滤 -> 工具调用”
  • 图片 PDF、扫描件、复杂网页更适合先做“结构恢复”，再决定后面是走问答还是走查询

也就是说，数据源类型决定的不只是“接什么”，还决定“后面该怎么处理”。

各类数据源更适合承担什么角色 ​

如果你想更快做判断，可以先看下面这个对应关系。

文档类和网页类 ​

这两类通常最适合承担：

  • 概念解释
  • 规则说明
  • 流程指导
  • 产品知识回答

因为它们本来就是“以段落为单位传递信息”的，和 RAG 常见的检索增强问答比较匹配。

数据库和业务系统 ​

这类数据更适合承担：

  • 查状态
  • 查字段
  • 查条件命中结果
  • 生成结构化摘要

比如“订单现在是什么状态”“这个客户近 30 天有没有退款”“本月待处理工单有多少”。这类问题如果硬拆成文档问答，往往不稳定，也不够实时。

代码与技术资产 ​

这类数据既可能被当作文档，也可能被当成结构关系图。

比如：

  • README、设计文档、接口说明更像知识文档
  • 源码、配置、调用关系更像结构化技术资产

所以代码类数据做 RAG 时，通常要同时考虑“文本可读性”和“上下游关系”。单纯把所有代码切块后做语义检索，往往只能回答非常浅的问题。

表格与报表 ​

这类数据最常见的问题是：真正的语义并不只在某个单元格里，而是在：

  • 表头
  • 行列关系
  • 时间维度
  • 统计口径

所以表格型数据更适合先做结构化抽取，再决定哪些部分进入检索，哪些部分改成查询接口。

多模态数据 ​

这类数据最大的问题不是“能不能接”，而是“解析出来的东西是否足够可信”。

比如一份扫描版合同，如果 OCR 把金额、日期、条款编号识别错了，后面 RAG 再聪明也只是在错误基础上继续生成。所以多模态数据往往要先经过更重的预处理和质量校验。

一个更实用的理解方式 ​

可以把 RAG 数据源粗略分成三类：

  • 知识文档型：适合做检索增强问答
  • 结构记录型：适合做查询、过滤和工具调用
  • 复杂载体型：适合先做解析和结构恢复，再进入后续链路

这三类数据可以同时存在于一个系统里，但通常不会用完全一样的方法处理。

如果你要继续往下落，可以再把它们各自对应到更具体的链路：

  • 知识文档型：抽正文 -> 清洗噪声 -> 切块 -> 建索引 -> 检索增强回答
  • 结构记录型：识别关键表和字段 -> 明确查询意图 -> 条件过滤或 API 查询 -> 再把结果交给模型解释
  • 复杂载体型：OCR / 版面分析 / 表格恢复 -> 结构校验 -> 再决定是走文档链路还是查询链路

这一步很重要，因为它直接决定你后面是在优化 chunk、embedding 和 rerank，还是应该去补字段映射、查询接口和数据同步。

接入前最好先问的 5 个问题 ​

一类数据要不要接入 RAG，比较实用的判断问题通常是：

  1. 这类数据的核心价值是“解释说明”，还是“实时查询”？ 如果更偏实时查询，就不要默认走文档型 RAG。

  2. 这类数据更新频率高不高？ 如果变化非常快，而你的索引更新做不到及时同步，接进来也容易答错。

  3. 这类数据有没有稳定结构？ 如果连字段、标题、版面都经常变化，接入成本会比你想象得高很多。

  4. 这类数据对准确率和可追溯性的要求高不高？ 如果用户必须看到精确字段和值，那你更应该考虑查询接口或工具调用，而不是只做语义召回。

  5. 这类数据有没有权限、租户、时效等边界？ 如果有，那接入时就要把这些边界一起建进去，不能只抽正文。

这 5 个问题的价值在于：它们会逼你先判断“这是不是合适的 RAG 数据”，而不是先把一切都扔进索引再说。

哪些情况不适合直接按“文档问答”接入 ​

下面这些情况尤其容易被误判：

  • 本质是查实时状态的数据
  • 本质是按字段筛选的数据
  • 本质是需要精确计算的数据
  • 版面极其复杂、解析质量还不稳定的数据
  • 权限边界很多，但元数据设计还没跟上的数据

这些数据不是不能进入智能系统，而是通常不该直接照搬“文档切块 + 向量检索 + 拼 Prompt”这一套最基础 RAG 流程。

一个更现实的接入思路 ​

对很多团队来说，比较现实的做法不是“一次接所有数据源”，而是分层推进：

  1. 先接最稳定的知识文档。 比如产品手册、FAQ、帮助中心、制度说明。这类数据最容易先做出稳定效果。

  2. 再接结构更复杂但价值高的数据。 比如 Wiki、PDF、表格、代码文档。这一步重点通常在解析和清洗。

  3. 最后再接实时业务系统。 比如订单、CRM、工单、库存。这一步往往不只是“接入知识库”，而是要同时设计查询接口、权限控制和同步机制。

这样推进的好处是：你不会一开始就把最难的数据源和最重的工程问题混在一起。

一句话总结 ​

RAG 可以接很多数据源，但真正关键的从来不是“接了多少种”，而是“每一类数据有没有被按合适方式处理”。对很多系统来说，数据源越多越不是优势，只有在类型判断、处理链路和治理边界都做对时，它才会变成优势。