前言在前面的学习中我们已经完成了第一个基础版 RAG 系统。Day7 我们实现了文档读取Embedding向量生成向量数据库存储相似度搜索基础RAG问答流程一个完整的 RAG 流程如下用户问题 ↓ 问题Embedding ↓ 向量数据库搜索 ↓ 找到相关知识 ↓ 拼接Prompt ↓ LLM生成答案但是实际项目中的 RAG 远比这个复杂。因为真实企业知识库通常包含几百份PDF技术文档安全规范产品说明内部知识库如果直接把整篇文章进行Embedding会出现很多问题搜索精度下降无关内容大量进入PromptToken浪费LLM回答质量降低因此 Day8 我们开始优化 RAG 的核心环节文档切分 Chunk。一、为什么 Day7 的 RAG 不够好Day7 中我们直接把完整文本生成Embedding。例如企业安全规范 管理员账号必须开启双因素认证。 普通用户密码需要90天修改一次。 发现漏洞后需要7天内完成修复。 服务器日志必须保存180天。 高危漏洞需要立即处理。整个文本作为一个向量。这样做的问题假设用户问密码多久修改向量搜索找到的是企业安全规范全文但是用户真正需要的是普通用户密码需要90天修改一次也就是说搜索粒度太大。二、什么是ChunkChunk就是将一篇长文本切分成多个小文本块。例如原始文档企业安全规范 管理员账号必须开启双因素认证。 普通用户密码需要90天修改一次。 发现漏洞后需要7天内完成修复。切分之后Chunk1:管理员账号必须开启双因素认证。Chunk2:普通用户密码需要90天修改一次。Chunk3:发现漏洞后需要7天内完成修复。每个Chunk都会文本 ↓ Embedding ↓ 向量数据库最终数据库保存向量1 - 管理员账号规则 向量2 - 密码修改规则 向量3 - 漏洞修复规则查询时用户 密码多久修改 搜索 Chunk2这样准确率明显提高。三、Chunk设计的重要性Chunk并不是简单切字符串。一个好的Chunk需要考虑1. Chunk大小如果太大例如5000字一个Chunk问题包含大量无关信息搜索困难Prompt变长如果太小例如一句话一个Chunk问题上下文丢失例如Chunk1: 漏洞处理要求 Chunk2: 发现漏洞后需要7天内修复。单独搜索Chunk2可能不知道它属于什么规则。因此实际项目一般300~1000字符作为一个Chunk大小。2. Chunk overlap重叠什么是Overlap例如文本A B C D E F切分没有重叠Chunk1: A B C Chunk2: D E F问题C和D之间的信息断裂。加入重叠Chunk1: A B C Chunk2: C D E Chunk3: E F这样上下文不会突然丢失。四、Day8项目结构设计重新整理RAG项目day8 │ ├── knowledge │ | │ security.txt │ ├── db │ ├── rag_build.py │ └── rag_chat.py两个核心文件rag_build.py负责知识库构建流程读取文档 ↓ 文本切分 ↓ 生成Embedding ↓ 保存Chromarag_chat.py负责用户查询流程用户问题 ↓ Embedding ↓ 向量搜索 ↓ 拼接Prompt ↓ 交给LLM五、实现文本切分程序核心代码def split_text(text, chunk_size100): chunks[] start0 while start len(text): endstartchunk_size chunktext[start:end] chunks.append(chunk) startend return chunks例如输入企业安全规范......输出Chunk0 Chunk1 Chunk2六、改进后的RAG流程现在完整流程文档 | | Chunk切分 | -------------------- | | | Chunk1 Chunk2 Chunk3 | Embedding | Chroma向量数据库 | 用户问题 | 相似度搜索 | 相关Chunk | Prompt | LLM回答这就是企业RAG的基础架构。七、运行效果构建知识库 RAG知识库构建开始 文本读取成功 Chunk数量: 6 Embedding模型加载完成 Collection创建成功 知识库构建完成 数据数量: 6查询请输入问题: 密码多久修改搜索结果普通用户密码需要90天修改一次。说明RAG已经可以根据问题找到对应知识片段。八、Day8学习总结今天完成了RAG从能运行到更接近真实项目主要学习1. 为什么需要Chunk因为整篇文档Embedding ↓ 搜索范围太大 切成Chunk ↓ 提高检索精度2. Chunk设计原则不是越小越好。需要平衡准确率 上下文完整性 Token成本3. RAG核心不是LLM很多人认为RAG效果不好是模型问题。实际上很多时候问题来自数据处理 ↓ Chunk设计 ↓ Embedding ↓ 检索策略知识库质量决定RAG上限。总结Day7解决了RAG是什么以及如何运行。Day8解决了如何让RAG真正可用。真正的RAG系统不是文本 ↓ Embedding ↓ 搜索而是数据处理 ↓ 合理Chunk ↓ 高质量Embedding ↓ 精准检索 ↓ LLM生成这也是从Demo级RAG走向企业级RAG的关键一步。
Day8：从0实现AI Agent知识库：RAG优化之文本切分Chunk设计详解
发布时间：2026/7/29 1:29:01
前言在前面的学习中我们已经完成了第一个基础版 RAG 系统。Day7 我们实现了文档读取Embedding向量生成向量数据库存储相似度搜索基础RAG问答流程一个完整的 RAG 流程如下用户问题 ↓ 问题Embedding ↓ 向量数据库搜索 ↓ 找到相关知识 ↓ 拼接Prompt ↓ LLM生成答案但是实际项目中的 RAG 远比这个复杂。因为真实企业知识库通常包含几百份PDF技术文档安全规范产品说明内部知识库如果直接把整篇文章进行Embedding会出现很多问题搜索精度下降无关内容大量进入PromptToken浪费LLM回答质量降低因此 Day8 我们开始优化 RAG 的核心环节文档切分 Chunk。一、为什么 Day7 的 RAG 不够好Day7 中我们直接把完整文本生成Embedding。例如企业安全规范 管理员账号必须开启双因素认证。 普通用户密码需要90天修改一次。 发现漏洞后需要7天内完成修复。 服务器日志必须保存180天。 高危漏洞需要立即处理。整个文本作为一个向量。这样做的问题假设用户问密码多久修改向量搜索找到的是企业安全规范全文但是用户真正需要的是普通用户密码需要90天修改一次也就是说搜索粒度太大。二、什么是ChunkChunk就是将一篇长文本切分成多个小文本块。例如原始文档企业安全规范 管理员账号必须开启双因素认证。 普通用户密码需要90天修改一次。 发现漏洞后需要7天内完成修复。切分之后Chunk1:管理员账号必须开启双因素认证。Chunk2:普通用户密码需要90天修改一次。Chunk3:发现漏洞后需要7天内完成修复。每个Chunk都会文本 ↓ Embedding ↓ 向量数据库最终数据库保存向量1 - 管理员账号规则 向量2 - 密码修改规则 向量3 - 漏洞修复规则查询时用户 密码多久修改 搜索 Chunk2这样准确率明显提高。三、Chunk设计的重要性Chunk并不是简单切字符串。一个好的Chunk需要考虑1. Chunk大小如果太大例如5000字一个Chunk问题包含大量无关信息搜索困难Prompt变长如果太小例如一句话一个Chunk问题上下文丢失例如Chunk1: 漏洞处理要求 Chunk2: 发现漏洞后需要7天内修复。单独搜索Chunk2可能不知道它属于什么规则。因此实际项目一般300~1000字符作为一个Chunk大小。2. Chunk overlap重叠什么是Overlap例如文本A B C D E F切分没有重叠Chunk1: A B C Chunk2: D E F问题C和D之间的信息断裂。加入重叠Chunk1: A B C Chunk2: C D E Chunk3: E F这样上下文不会突然丢失。四、Day8项目结构设计重新整理RAG项目day8 │ ├── knowledge │ | │ security.txt │ ├── db │ ├── rag_build.py │ └── rag_chat.py两个核心文件rag_build.py负责知识库构建流程读取文档 ↓ 文本切分 ↓ 生成Embedding ↓ 保存Chromarag_chat.py负责用户查询流程用户问题 ↓ Embedding ↓ 向量搜索 ↓ 拼接Prompt ↓ 交给LLM五、实现文本切分程序核心代码def split_text(text, chunk_size100): chunks[] start0 while start len(text): endstartchunk_size chunktext[start:end] chunks.append(chunk) startend return chunks例如输入企业安全规范......输出Chunk0 Chunk1 Chunk2六、改进后的RAG流程现在完整流程文档 | | Chunk切分 | -------------------- | | | Chunk1 Chunk2 Chunk3 | Embedding | Chroma向量数据库 | 用户问题 | 相似度搜索 | 相关Chunk | Prompt | LLM回答这就是企业RAG的基础架构。七、运行效果构建知识库 RAG知识库构建开始 文本读取成功 Chunk数量: 6 Embedding模型加载完成 Collection创建成功 知识库构建完成 数据数量: 6查询请输入问题: 密码多久修改搜索结果普通用户密码需要90天修改一次。说明RAG已经可以根据问题找到对应知识片段。八、Day8学习总结今天完成了RAG从能运行到更接近真实项目主要学习1. 为什么需要Chunk因为整篇文档Embedding ↓ 搜索范围太大 切成Chunk ↓ 提高检索精度2. Chunk设计原则不是越小越好。需要平衡准确率 上下文完整性 Token成本3. RAG核心不是LLM很多人认为RAG效果不好是模型问题。实际上很多时候问题来自数据处理 ↓ Chunk设计 ↓ Embedding ↓ 检索策略知识库质量决定RAG上限。总结Day7解决了RAG是什么以及如何运行。Day8解决了如何让RAG真正可用。真正的RAG系统不是文本 ↓ Embedding ↓ 搜索而是数据处理 ↓ 合理Chunk ↓ 高质量Embedding ↓ 精准检索 ↓ LLM生成这也是从Demo级RAG走向企业级RAG的关键一步。
