为什么要分块
将长文本分解成适当大小的片段，以便于嵌入、索引和存储，并提高检索的精确度。
- 模型限制：大模型对上下文长度有固定限制，嵌入模型可能只能处理8000个token，过长的上下文无法嵌入
- 检索精度：将大型数据集切割成更小、更有意义的信息片段，有利于提高检索精度
- 语义保持：过大的文本块会增加噪音，不利于模型保持语义相关性
- 生成效率：适当大小的文本块能提高模型理解和响应的效率
如何确定大模型所能接受的最长上下文
- 模型文档：查看模型官方文档中的上下文长度限制说明
- 开源模型：在Hugging Face模型卡中查找”max_position_embeddings”参数
- 配置文件：检查模型的config.json/tokenizer_config.json文件中的max_position_embeddings/model_max_length字段
分块大小对检索精度的影响 – 理解嵌入过程
文本嵌入生成过程
- 信息压缩：Transformer会将所有token向量压缩成单一768维向量，存在信息损失
- 块大小影响：
- 过大：向量表示过于笼统，关键细节被模糊化
- 过小：可能丢失上下文关联信息
- 嵌入过程：
- 输入文本加CLS标签并分词
- 每个token生成对应向量表示
- 通过Pooling(均值/最大值/CLS)压缩为单一向量
- 最佳实践：不应简单使用模型支持的最大token数作为分块标准
分块大小对生成质量的影响 - lost in the middle
通过应用合理的分块策略，将知识库中的内容切分为主题明确的小块，如“高血压：常用药物”“高血压：用药禁忌”“高血压：生活方式建议”。
每块保持在500个字符左右，可以使检索过程更精准地捕捉每个主题的核心信息，并仅将该信息传递给生成模型，从而生成精准的回答，例如“常用的降压药包括药物A和药物B，需要在医生指导下服用”。
- Lost in Middle问题：过长的上下文会导致生成模型丢失关键细节
分块与主题稀释
假设山西文旅建立了一个包含各地景点和活动的知识库。如果一个文本块包含了关于“五台山、云冈石窟、太原游乐场”的描述，当用户询问“适合带小朋友玩的景点”时，这个综合信息块可能不会得到很高的检索评分。
然而，如果每个景点的信息被独立为块，例如“五台山：佛教名山”“云冈石窟：唐代造像巅峰”“太原游乐场：暑期攻略”，那么RAG系统就能更准确定位到相关信息，避免了无关内容对相似度检索过程的稀释。
- 主题明确性：
- 差示例：”山西旅游”包含所有景点信息
- 好示例：分为”五台山佛教文化”、”云冈石窟艺术”、”太原亲子游乐”等主题块
- 检索评分：主题明确的块能获得更高的相似度评分(从0.2提升到0.7-0.8)
- 推荐大小：500-1000个字符的主题明确块效果最佳
用ChunkViz工具可视化分块
GitHub地址：https://github.com/gkamradt/ChunkViz
在线访问地址：https://chunkviz.up.railway.app/
工程介绍中有详细的安装说明
- 功能：可视化不同分块策略的效果
- 参数调节：可调整块大小、重叠量等参数
- 支持策略：字符分块、递归字符分块等
- 统计信息：显示总字符数、块数量、平均块大小等
- 实现原理：基于LangChain的分块工具进行可视化展示