数据库文档分块

定义

数据库文档分块 是指针对数据库说明材料设计 chunk 切分边界的方法。这里的“数据库文档”主要不是泛泛的技术文档，而是包含表说明、业务说明、字段说明、关联关系、样例数据、常见查询场景等内容的结构化解读材料。

它要解决的核心矛盾是：

• 切分过粗：单个 chunk token 过多，会占用大模型有限的上下文窗口
• 切分过细：内容完整性与上下文关联丢失，导致本应一起被理解的信息被拆散

因此，这个概念的关键不在“尽量切大”或“尽量切小”，而在于围绕完整知识单元切分，让每个 chunk 既不冗余到挤占上下文，也不碎片化到失去语义。

在本文档中的语境

在本文语境里，数据库文档分块 服务于 RAG，尤其适用于 AI 问数、AI2SQL、N2SQL 一类场景。此类场景对“召回是否完整”极为敏感，因为用户提问常常不是只问一个字段名，而是同时依赖：

• 表的用途与业务定位
• 字段的业务含义
• 主键、外键与引用关系
• 层级结构或编码规则
• 示例数据与实际取值方式

如果这些信息在分块时被拆开，即使检索命中了表名，也可能只召回字段列表，却召不回字段含义；或者只召回字段定义，却丢失该表在业务模型中的关系说明。最终结果就是召回看似“相关”，但无法支撑模型一次性给出准确答案。

所以本文强调，精准召回的基础不是简单提高向量检索能力，而是先保证知识库中存在可被完整召回的 chunk。

核心原则

平衡 chunk 大小与语义完整性

数据库文档分块首先要处理块大小与完整性之间的张力。

• chunk 太大：会把大量次要内容、示例和无关说明一起塞进检索结果，挤占上下文窗口
• chunk 太小：会让字段、规则、关系、业务解释分别散落在多个块中，检索时难以一次召回全貌

因此，合理做法不是机械按固定字数切，而是先识别文档中的语义边界，再控制每个边界内部的规模。

围绕完整知识单元切分

所谓完整知识单元，是指一个 chunk 内应尽量容纳一次回答某类问题所需的最小完整信息集合。

例如在数据库说明文档里，一个知识单元可以是：

• 某张表的“表说明”整体
• 某组字段及其统一语境下的字段解释
• 某张表的“关联关系”整体
• 某一业务规则及其约束条件
• 某组样例数据及其解读

这意味着分块边界应优先服从知识单元边界，而不是服从字数平均、段落平均或页面平均。

避免字段与关系信息被割裂

数据库文档最容易在分块后出问题的地方，就是字段说明与关系说明被拆开。

例如：

• 字段定义中写了 accountcode 是会计科目唯一编码
• 关联关系中又写了其他表通常存该科目代码，需要回连本表获取名称

如果这两部分被切到不同 chunk，检索时只命中其一，模型就只能看到“它是什么”或“它怎么被引用”，无法同时理解。对于 SQL 生成、字段映射、表关联判断，这种信息断裂会直接降低答案质量。

典型适用文档

数据库文档分块 特别适用于以下文档：

• 数据表结构解读文档
• 数据库字段字典与字段释义文档
• 表关联关系说明文档
• 含业务背景的表设计说明文档
• 面向 AI2SQL / N2SQL 的知识库说明材料

这些文档的共同特点是：同一主题下往往同时包含结构信息与业务信息，不能像普通文章那样只按自然段粗略切分。

实现机制

本文上下文中的数据库文档分块，通常不是孤立完成，而是和 数据库文档标注 摘要、结构化文档标注、文档边界标记 一起使用。它们的关系可以概括为：

• 标注负责把语义结构显式写出来
• 分块负责沿着这些结构边界生成更适合检索的 chunk

原文给出了三类常见做法，这些做法本质上都是为了给分块提供稳定边界。

1. 依标题层级分块

使用 Markdown 标题层级构建文档骨架，再据此切分。典型结构是：

• 一级标题：文档主题或表名
• 二级标题：主要分类，如表说明、字段说明、业务用途、关联关系
• 三级标题：次级分类，如字段定义、业务规则等

原文强调：

• 一级标题只用于文档主题
• 二级标题用于主要分类
• 三级标题用于次要分类
• 标题要简洁明了，3 到 7 个字为佳

这种方法的意义在于，分块器可以把“一个标题节点及其从属内容”视为自然知识单元，而不是把整篇文档打散。

2. 依信息块标记分块

对于字段表、样例数据、业务说明等边界很重要的区域，可以额外加入开始与结束标记，例如用 HTML 注释包裹一个信息块。

这种方式的关键点包括：

• 标记不影响文档可读性
• 标记名称要简洁明了，便于系统识别
• 开始与结束标记必须成对出现

这类标记特别适合告诉切分逻辑：某个块必须完整保留，不要把中间内容再截断。

3. 依语义分隔符分块

还可以使用文档中不会自然出现的特殊分隔符来标识一个完整区块，例如字段区块、规则区块等。

其实施要求主要有两点：

• 选择不会在正文自然出现的分隔符
• 保持分隔符风格统一一致

这类做法的目标同样不是美化文档，而是把语义边界明确化，从而让 chunk 切分更稳定。

实际结构示例

原文用 account_acc 作为完整示例，展示了一份数据库说明文档如何先被结构化，再据此进行更合理的分块。

该示例中，一张表的内容被拆成多个明确模块：

• 表说明：说明该表用于存储企业财务会计科目信息，是财务系统核算体系的核心基础数据表，并为资产清算、预算管理等模块提供科目引用支持
• 业务用途：包括会计科目管理、业务数据关联、报表生成等用途
• 表数据样例解读：通过样例行展示 id、entid、accountcode、accountname、shortname、parentcode 等字段如何取值
• 字段说明：解释主键、企业号、核算科目编码等字段
• 关联关系：说明该表在业务模型中的主表地位，以及 accountcode 常被其他表用于关联获取会计科目名称

这里可以看到，好的数据库文档分块不是把整张表说明切成平均几段，而是把“表说明”“业务用途”“字段说明”“关联关系”等视为不同的知识单元。