企业官网建设流程全解析

在RAG中，“语义被切割”通常是指：一个完整事实、条件或逻辑关系被拆到不同Chunk里，导致检索只找回其中一半。

例如原文：

员工可以申请远程办公，但必须满足以下条件： 1. 入职满一年； 2. 最近一次绩效为B及以上； 3. 每周最多远程办公两天。

如果切成：

Chunk 1：员工可以申请远程办公。 Chunk 2：入职满一年，绩效为B及以上，每周最多两天。

模型只检索到Chunk 1时，就可能错误回答“所有员工都能申请”。
解决这个问题不能只靠调大Chunk，而要结合结构化切分、重叠、父子检索和上下文扩展。

一、 不要按固定字符数硬切

最容易破坏语义的方式是：

每500个字符切一次

它可能在句子、列表、表格甚至条件表达中间切开。

更好的方式是按照以下优先级递归切分：

标题 ↓ 章节 ↓ 段落 ↓ 完整句子 ↓ 逗号或其他标点 ↓ 最后才按Token长度截断

例如：

separators = [ "\n# ", # 一级标题 "\n## ", # 二级标题 "\n\n", # 段落 "\n", # 换行 "。", # 句子 "；", "，" ]

核心原则是：优先保证语义完整，再满足长度限制。

长度最好按Token计算，而不是按字符数，因为模型的上下文限制是以Token计算的。

二、 使用Chunk Overlap重叠窗口

相邻Chunk之间保留一部分重复内容。

例如：

原文：A B C D E F G H Chunk 1：A B C D E Chunk 2：D E F G H

其中D E就是重叠部分。

常见起点可以设置为：

Chunk大小：300～800 tokens Overlap：Chunk大小的10%～20%

例如：

chunk_size = 500 tokens chunk_overlap = 80 tokens

重叠适合解决：

一个句子刚好横跨边界

代词指向上一段

条件和结论距离较近

上下段存在承接关系

但Overlap不能解决所有问题。它设置得太大会导致：

数据重复

检索结果高度相似

上下文浪费

向量库体积增大

因此不要仅靠无限增加Overlap。

三、使用语义切分

语义切分不是按照长度切，而是检测相邻句子的语义变化。

例如：

句子1：员工每月可以申请一次交通补贴。 句子2：补贴上限为500元。 句子3：申请必须在每月25日前提交。 句子4：公司的招聘流程包括初试和复试。

句子1～3都在讲交通补贴，应放在同一个Chunk；句子4开始讲招聘，应从这里切开。

基本过程是：

文档拆成句子 ↓ 计算相邻句子的Embedding相似度 ↓ 相似度明显下降的位置视为主题边界 ↓ 合并同一主题的连续句子

语义切分比较适合：

长篇报告

会议纪要

新闻和研究材料

没有清晰标题结构的文本

但它的计算成本更高，而且相似度阈值需要根据业务数据调试。

四、 检索后自动扩展相邻Chunk

检索到某个Chunk以后，把它前后的Chunk一起取回来。

例如检索到：

Chunk 8：远程办公的申请条件

系统同时返回：

Chunk 7：远程办公适用范围 Chunk 8：远程办公申请条件 Chunk 9：远程办公审批流程

伪代码：

retrieved = search(query) for chunk in retrieved: context += get_chunk(chunk.index - 1) context += chunk context += get_chunk(chunk.index + 1)

为了实现这一点，每个Chunk需要保存：

{ "document_id": "employee_handbook", "section_id": "remote_work", "chunk_index": 8, "previous_chunk_id": 7, "next_chunk_id": 9 }

相邻扩展特别适合说明书、法规和连续叙述文档。

但最好限制在同一个章节内，避免把下一章的无关内容也带进来。

五、使用父子Chunk

这是实际RAG系统中非常有效的方法，也叫“小块检索，大块返回”。

处理文档时，建立两种Chunk：

父Chunk：800～2000 tokens，保持完整章节语义 子Chunk：100～400 tokens，用于精确检索

例如：

父Chunk：完整的“员工远程办公制度” ├─ 子Chunk 1：申请资格 ├─ 子Chunk 2：申请流程 ├─ 子Chunk 3：办公天数限制 └─ 子Chunk 4：违规处理

查询时：

用户问题 ↓ 检索到“申请资格”子Chunk ↓ 根据parent_id找到完整父Chunk ↓ 把父Chunk交给大模型

这样同时兼顾：

小Chunk检索精确

大Chunk上下文完整

如果直接使用大Chunk做向量检索，其中会包含多个主题，向量容易被无关内容稀释；如果只使用小Chunk生成答案，语义又可能不完整。父子Chunk正好解决这一矛盾。

六、 给每个Chunk补充上下文

有些Chunk单独拿出来后，完全看不出它属于哪个主题。

例如原始Chunk只有：

需要在三个工作日内完成审批。

单独向量化时，很难知道这是报销审批、请假审批还是采购审批。

可以给它添加标题和章节路径：

文档：《员工费用管理制度》 章节：差旅报销 > 审批流程 正文： 差旅报销需要在三个工作日内完成审批。

Embedding时使用带上下文的内容，但展示答案时可以只展示正文。

建议保留的元数据包括：

文档标题 章节标题 父级标题 文档类型 产品型号 发布时间 适用部门 版本号

这种方法通常称为上下文增强或Contextual Chunking。

七、合并检索到的连续Chunk

假设检索结果中出现：

Chunk 5 Chunk 6 Chunk 7 Chunk 12

由于5、6、7是连续的，可以先合并为一个完整上下文：

合并结果A：Chunk 5～7 结果B：Chunk 12

合并时还可以消除Overlap产生的重复文本，避免模型看到同一句话多次

八、使用多粒度索引

同一份文档可以建立多种粒度的索引：

文档摘要索引：判断应该查哪份文档 章节索引：判断应该查哪个章节 段落索引：查找精确事实 句子索引：查找编号、定义和具体数据

查询流程可以是：

先定位文档 ↓ 再定位章节 ↓ 最后检索具体段落

这比在所有零散Chunk中一次性搜索更容易保持文档结构

九、推荐的实用组合

对于普通企业制度、产品手册和技术文档，可以从下面的配置开始：

1. 先按标题和章节解析文档 2. 在章节内按段落和句子递归切分 3. 子Chunk控制在300～500 tokens 4. Overlap设置为50～100 tokens 5. 保存标题、章节路径和版本信息 6. 建立父子Chunk关系 7. 使用子Chunk检索 8. 返回父Chunk或相邻Chunk 9. 对结果进行Rerank 10. 合并连续Chunk并删除重复内容

简化架构如下：

文档 ↓ 按章节切分 父Chunk ↓ 按段落和句子切分 子Chunk ↓ 向量化和建立索引 用户问题 ↓ 检索子Chunk ↓ Rerank ↓ 获取父Chunk和相邻Chunk ↓ 合并、去重 ↓ 交给大模型回答

最关键的原则

不要试图找到一个适合所有文档的固定Chunk大小。真正有效的方案是：

结构决定边界，小块负责检索，大块负责理解，标题补充上下文，相邻片段负责恢复连续语义。

最终还要准备一批真实问题进行评估，重点检查：正确片段是否被召回、条件和结论是否同时出现、表格和列表是否完整，以及最终引用是否真正支持答案