2.2.2 文档、网页、数据库、代码库有什么区别？

它们都能成为 RAG 的知识来源，但差别非常大。

如果不区分这些差异，就容易出现一种问题：把不同类型的数据都当成“普通文本”，结果导致接入、检索和回答方式都不合适。

文档：重点是内容完整，但结构质量不稳定

文档类数据通常包括 PDF、Word、PPT、Markdown、手册和规范。

它的特点是：

• 内容比较完整
• 常常适合说明型问答
• 容易包含长段落和跨页内容

难点在于：

• 格式差异大
• 结构提取不稳定
• 常有页眉页脚、目录和模板噪声

所以文档类数据的重点，通常不是“能不能抽出文字”，而是：

• 能不能稳定识别标题和段落边界
• 能不能把模板噪声和正文分开
• 能不能保留版本、来源、页码、章节这些上下文

如果这些问题没处理好，后面的切块和检索质量通常都会受影响。

网页：重点是层级清晰，但模板噪声明显

网页类数据常见于帮助中心、文档站、知识库页面和 Wiki。

它的优点是：

• HTML 结构通常更明确
• 标题层级比较清楚
• 更新频率较高

但问题也很明显：

• 正文和导航、侧栏、推荐区混在一起
• 同一模板页面噪声大量重复
• 页面跳转关系复杂

网页类数据因此更需要注意两件事：

• 先抽“主内容”，不要把模板区和正文等价对待
• 保留页面层级和链接关系，因为很多网页知识不是靠单页完整表达，而是靠一组页面共同组成

数据库：重点是字段明确，但语义不在长文本里

数据库或业务系统数据通常是结构化记录。

它的特点是：

• 字段清楚
• 可过滤性强
• 实时性通常更好

但它和文档不一样，很多语义不在“段落”里，而在：

• 字段名
• 表关系
• 条件约束
• 时间维度

所以数据库常常更适合：

• 查询
• 聚合
• 条件筛选

而不是简单做文档检索。

如果把数据库记录直接拼成自然语言文档再做语义检索，常见问题是：

• 实时性丢了
• 条件约束丢了
• 数值精度和统计口径也容易丢

所以数据库类数据更像“应该被调用的事实系统”，而不是“应该被背下来的一堆文本”。

代码库：重点是上下文依赖强

代码库里的知识通常包括：

• 源代码
• README
• 注释
• 配置文件
• 目录结构
• 提交记录

它和普通文档最大的区别是：局部文字往往不能脱离上下文独立理解。

比如一个函数片段是否重要，往往取决于：

• 它所在文件
• 调用关系
• 模块职责
• 配置环境

所以代码类数据通常更依赖结构信息，而不是单纯文本相似度。

这也是为什么代码问答经常不能只靠“把源码切块喂进去”。很多真实问题都需要同时知道：

• 代码本身写了什么
• 它被谁调用
• 它依赖什么配置
• 它属于哪个模块边界

也就是说，代码库里的上下文关系，本身就是知识的一部分。

它们在 RAG 里的典型区别

如果用更工程化的话说，这几类数据的核心区别主要体现在四个维度：

1. 结构清晰度

• 网页、数据库通常更结构化
• PDF、扫描件通常更不稳定

2. 更新方式

• 网页和数据库更容易频繁更新
• 静态文档更新通常更批量、更离散

3. 检索粒度

• 文档和网页更适合段落或章节级
• 数据库更适合记录级
• 代码库更适合文件、函数、模块级

4. 最终回答方式

• 文档更适合解释型回答
• 数据库更适合精确查询结果
• 代码库更适合带定位和上下文的回答

如果再往前走一步，可以把这几类数据分别对应到不同的系统动作：

• 文档：更偏“检索段落 -> 拼上下文 -> 解释答案”
• 网页：更偏“抽主内容 -> 保留层级 -> 引用页面回答”
• 数据库：更偏“识别意图 -> 转查询条件 -> 返回结果再解释”
• 代码库：更偏“检索位置 -> 补调用关系 -> 给出带定位的说明”

这一步很关键，因为它决定了你后面到底是在优化 chunk，还是在优化查询路由和工具调用。

如果你想再收成一个更简单的判断，可以这样记：

• 文档和网页，重点是“怎样把文本和结构保留下来”
• 数据库，重点是“怎样把查询能力保留下来”
• 代码库，重点是“怎样把上下文关系保留下来”

只要把重点抓错，后面的处理链路通常就会一路跑偏。

一类很常见的误判：把所有数据都按“段落文本”处理

这是很多早期 RAG 系统最容易犯的错。

表面上看，所有数据最后都能变成字符串；但真正的问题是：

• 文档的语义单位常常是段落
• 网页的语义单位常常是页面结构
• 数据库的语义单位常常是记录和字段
• 代码库的语义单位常常是函数、文件和模块关系

如果你把它们都压扁成“普通段落”，系统就会在关键地方失真。

比如：

• 表格中的列名丢了，数值就失去意义
• 代码的调用关系丢了，函数片段就很难解释
• 网页层级丢了，正文就可能缺前提
• 文档页码和章节丢了，引用就难以追溯

所以真正要区分的，不只是“数据来源长什么样”，而是“它本来的语义单位是什么”。

更贴近落地的处理分流

如果你在设计接入方案，可以先按下面这种方式分流：

文档和网页

优先考虑：

• 主内容抽取
• 标题层级恢复
• 噪声清理
• 段落或章节级切块

这类数据的重点通常是提高可读性和引用稳定性。

数据库和业务系统

优先考虑：

• 字段语义映射
• 查询意图识别
• 条件过滤和聚合能力
• 返回结果的解释层

这类数据的重点通常不是 embedding，而是把“用户想问什么”稳定翻译成查询动作。

代码库

优先考虑：

• 文件、函数、类、模块这些边界
• README、设计文档、配置文件和代码之间的关联
• 调用关系和依赖关系
• 结果返回时的路径与定位信息

这类数据的重点通常是“结构上下文”，而不是单独一句代码解释得多漂亮。

如果你现在正在做接入设计，可以先把这三类数据分给三种不同问题：

• 文档和网页：怎样切得更合理、引用更稳定
• 数据库和业务系统：怎样查得更准、条件更可控
• 代码库：怎样把定位、调用关系和上下文一起带出来

这样你会更容易避免“所有问题都往 embedding 上压”的惯性。

怎么判断当前问题更像哪一类

可以先看用户问题本身：

• 如果问题是“某个概念、规则、流程是什么”，通常更像文档或网页问题
• 如果问题是“当前状态、数量、命中条件是什么”，通常更像数据库问题
• 如果问题是“某段代码为什么这样写、在哪调用、会影响哪里”，通常更像代码库问题

这个判断很重要，因为它直接决定你是该去检索文本，还是去查字段、查关系、查依赖。

接入时最值得先问的 4 个问题

如果你拿到一类新数据，还不确定该怎么接，可以先问：

1. 它的核心语义主要藏在段落里，还是藏在字段和关系里？
2. 用户更可能拿它来“问解释”，还是“查事实”？
3. 如果把它压成普通文本，会不会丢掉最关键的信息？
4. 它更适合进入主知识库，还是更适合作为查询系统或工具能力存在？

这 4 个问题的作用是：先决定它应该走哪条链路，再决定后面用什么解析、索引和回答方式。

一个更现实的经验

很多系统不是只接一种数据，而是同时接文档、网页、数据库和代码库。

真正决定系统成熟度的，不是“接得全不全”，而是它有没有能力做到：

• 文档问题走文档链路
• 实时状态问题走查询链路
• 代码问题走结构化代码检索链路

如果所有问题最后都被塞进同一个“向量检索 + 拼 prompt”流程，系统很快就会暴露边界。

很多团队真正的问题，不是“不知道有哪些数据”，而是知道有很多数据以后，仍然下意识只想用一种处理方式把它们全部吞进去。这通常才是效果不稳的起点。

不要把“接入方式”误解成“处理方式”

虽然这些数据都可以通过连接器、抓取器或同步任务进入系统，但进入后不应该走完全一样的处理链路。

更准确的做法是：

• 先区分数据类型
• 再决定解析方式
• 再决定切块方式
• 最后决定检索和回答方式

必要时，甚至要先做“要不要走 RAG”这一步判断。因为有些数据库型问题，最合理的路径根本不是检索增强，而是直接查系统事实。

一句话总结

文档、网页、数据库、代码库都能成为 RAG 的知识来源，但它们解决的问题不同、语义载体不同、结构差异也很大。真正成熟的系统，不是“统一塞进去”，而是“按数据类型分别处理”。