文档切片不是切西瓜!面试官问你chunk size设多少,别再说＂512＂

     — 探索 AI 与 AGI 前沿 · 大模型 & AI Agent 实践 —       记录从传统开发到 AI 新时代的技术转型之旅     

面试官：”RAG 里的文档是怎么存的？”答”直接整篇存进去”的，面试官直接反问”那细节信息不全被平均掉了？”

为什么这道题必考？

这是 RAG 面试的基础技术题，考察你对存储层核心概念的理解。

很多同学回答太简单：

• ❌ “直接整篇存进去” —— 忽略了向量模型长度限制和语义稀释问题
• ❌ “切成小块就行” —— 没有说清楚 chunk 的结构和策略
• ❌ “切成 500 token” —— 没有说明粒度选择的权衡

面试官想听的是完整的存储结构理解和多种切割策略的掌握。

Q4：RAG 中的文档是怎么存的？粒度是多大？详细说说文档切割（Chunking）策略？

🎯 面试官想考察什么？

面试官想确认：

1. 为什么必须切 chunk（长度限制 + 语义稀释）
2. chunk 的结构组成（向量 + 原文 + metadata）
3. 粒度选择的权衡（大 vs 小）
4. 多种切割策略的掌握

满分回答框架

第一步：先讲为什么不能直接存

原始文档不能直接存，必须先切成 chunk，原因有两个：一是向量模型有输入长度限制（通常几百到几千 token），长文档塞不进去；二是整篇压成一个向量会「平均掉」细节，检索精度差。

详细说明：

整篇文档 -> 向量模型 -> 一个向量（信息太杂，语义笼统）切成 chunk -> 分别向量化 -> 多个向量（语义聚焦，检索精准）

类比理解：

• 问”退款政策”，整篇向量化相当于问”中国菜整体偏咸”，具体哪道菜咸不知道
• chunk 向量化相当于问”宫保鸡丁的口味特点”，精准定位

第二步：讲清楚 chunk 的结构

向量库里每条 chunk 记录包含三个部分：向量用于相似度检索，原始文本是 LLM 阅读的内容，metadata 用于过滤和溯源。

详细说明：

metadata 包含什么：

• 来源文件名、页码
• 章节标题、作者
• 自定义标签（部门、分类等）

第三步：粒度选择的权衡

Chunk 粒度没有银弹，通常 500～1000 token 是起点，关键是根据文档类型选策略。

详细说明：

实践建议：

• 普通文本：500-1000 token + 重叠 10-20%
• 结构化文档：按标题层级切
• 代码：按函数/类切

第四步：详细讲切割策略

策略一：固定大小 + 重叠（基础兜底）

• 按固定 token 数切割，相邻 chunk 有重叠
• 优点：实现简单，chunk 大小可控
• 缺点：可能在语义中间截断
• 适用：纯文本、无明显结构的文档

策略二：语义边界切割

• 按句子、段落、标题层级等自然边界切
• 优点：语义完整，召回质量好
• 缺点：chunk 大小不均
• 适用：段落分明的文章、Markdown/HTML

策略三：特殊内容专项处理

• 代码：按函数/类切，保持逻辑完整
• 表格：整块保留，转 Markdown 格式
• 需要 AST 解析或特殊处理逻辑

策略四：父子切割（高质量场景）

• 小块（200 token）用于检索，大块（1000 token）用于生成
• 通过 parent_id 关联
• 优点：检索精准 + 上下文完整两全
• 缺点：存储量翻倍，索引构建复杂

策略五：Late Chunking（前沿方案）

• 先整篇编码，再按边界切分做 mean pooling
• 每个 chunk 向量保留全文语境
• 需要模型支持长上下文（如 jina-embeddings-v2 支持 8192 token）

💡 加分回答点

⚠️ 踩坑警示

🔍 面试官可能的追问

1. “Chunk 切多大合适？如果切错了会有什么影响？”

• 提示：太大检索精度差，太小 LLM 看不懂，需要权衡

2. “父子切割具体怎么实现？”

• 提示：小 chunk 存向量，大 chunk 存原文，通过 parent_id 关联

3. “代码文件怎么切？按固定大小切有什么问题？”

• 提示：代码要按函数切，固定大小会切断逻辑

4. “你们项目用的什么策略？效果如何？”

• 提示：讲实际选型理由和评估结果

总结

📌 建议收藏本文，面试前拿出来复习一遍，祝你早日拿到心仪 offer！

有问题欢迎在评论区留言，我会一一回复。

本文是《RAG 面试通关秘籍》系列第 4 篇，持续更新中…

— 本文由 AI大本营自习室 出品，转载请注明出处 —