前言

在前面的学习中，我们已经完成了第一个基础版 RAG 系统。

Day7 我们实现了：

• 文档读取

• Embedding向量生成

• 向量数据库存储

• 相似度搜索

• 基础RAG问答流程

一个完整的 RAG 流程如下：

用户问题
   ↓
问题Embedding
   ↓
向量数据库搜索
   ↓
找到相关知识
   ↓
拼接Prompt
   ↓
LLM生成答案

但是实际项目中的 RAG 远比这个复杂。

因为真实企业知识库通常包含：

• 几百份PDF

• 技术文档

• 安全规范

• 产品说明

• 内部知识库

如果直接把整篇文章进行Embedding，会出现很多问题：

• 搜索精度下降

• 无关内容大量进入Prompt

• Token浪费

• LLM回答质量降低

因此 Day8 我们开始优化 RAG 的核心环节：

文档切分 Chunk。

---

一、为什么 Day7 的 RAG 不够好？

Day7 中，我们直接把完整文本生成Embedding。

例如：

企业安全规范：

管理员账号必须开启双因素认证。

普通用户密码需要90天修改一次。

发现漏洞后，需要7天内完成修复。

服务器日志必须保存180天。

高危漏洞需要立即处理。

整个文本作为一个向量。

这样做的问题：

假设用户问：

密码多久修改？

向量搜索找到的是：

企业安全规范全文

但是用户真正需要的是：

普通用户密码需要90天修改一次

也就是说：

搜索粒度太大。

---

二、什么是Chunk？

Chunk就是：

将一篇长文本切分成多个小文本块。

例如：

原始文档：

企业安全规范：

管理员账号必须开启双因素认证。

普通用户密码需要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

↓

保存Chroma

---

rag_chat.py

负责：

用户查询

流程：

用户问题

↓

Embedding

↓

向量搜索

↓

拼接Prompt

↓

交给LLM

---

五、实现文本切分程序

核心代码：

def split_text(text, chunk_size=100):

    chunks=[]

    start=0

    while start < len(text):

        end=start+chunk_size

        chunk=text[start:end]

        chunks.append(chunk)

        start=end


    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的关键一步。