上一篇我们谈到了 Embedding(4.1 节),它就像一台超级碎纸机兼塑封机,能把一切生涩的人类文字塑封成规整的浮点数指纹。
但这指纹该怎么用? 想象一下,今天你要让一个不懂劳动法常识的 AI(闭卷考生)替你解答:“新员工试用期怎么离职?” 你手头有一本厚厚的员工手册 PDF。我们要做的,就是把这本 PDF 切碎、归档,等到 AI 被提问时,迅速从档案室里抽出一两张纸塞给它,跟它说:“照着这张纸上的内容回答用户。”
这就是大名鼎鼎的 RAG(检索增强生成) 完整链路图。我们这就来一步步拆解档案室的入库与出库运作。
1. 拆碎长文:Chunking(文档切分)
不要试图把一整本书强压给大模型,首先受到冲击的是它那昂贵且脆弱的上下文窗口限制(Token Limit),其次,一篇长文扔进去就算没 溢出,大模型也往往会得“近视眼”——出现著名的“中间内容丢失(Lost in the Middle)”现象,它记住了书本的开头和结尾,反而忽略了藏在中间段的答案。
这就必须在入库前进行 Chunking(切块):
- 固定大小切分(Fixed Size Chunking):最粗暴但最常用的手段,比如硬性规定每 500 个字符砍一刀,变成一块“Chunk”。为了防止刚好一刀切断了句子的连贯词缀,通常设定 50 个字符的重叠区(Overlap)。
- 递归/语义切分(Recursive / Semantic Chunking):一种更人道的方法。脚本先尝试按段落回车符切分,如果段落太大才按句号切分。尽可能保证每一块 Chunk 拥有逻辑上的闭环关联。
这就好比我们在摘抄经典名句。摘抄卡片不能只是干瘪的十个字,最好连同上下文摘录几百字的段落,这便是 Chunking 诞生的初衷:保留知识密度的最小切片单位。 在高级玩法中,甚至还有 Parent-Child Retrieval(父子块检索),用极小的指纹块负责引出索引(更容易命中),但真要给 AI 查阅时则丢回携带了丰富上下文的前后巨大文段(防止 AI 觉得没头没尾)。
[图片占位:(A clean, minimalist technical diagram on a solid white background. Use simple, crisp vector line art, monochrome or with very subtle minimal color accents. Flat design, no 3D effects, no clutter. Draw a large document icon being sliced evenly into three smaller blocks, representing document chunking.)]