【字节跳动】长文档做向量化之前为什么必须先切片？不切片整篇 encode 会怎样？

考察点

这道题出自字节跳动 LLM 应用算法岗三面，第二问「不切片整篇 encode 会怎样」是典型的反假设问法，面试官想确认你理解切片背后的约束到底是什么，而不是只会背「chunk size 512」。回答要覆盖三层：embedding 模型的硬限制、语义表示的物理本质、检索粒度的工程需求。追问一般往切片策略怎么选、chunk 大小怎么定、以及长上下文模型流行之后切片是否还有必要这几个方向走。

参考答案

硬限制：embedding 模型吃不下一整篇

主流 embedding 模型（BGE、E5、OpenAI 的 text-embedding 系列）的输入上限大多是 512 到 8192 个 token，常见配置就卡在 512。一篇几十页的文档几万 token，直接喂进去会被截断——后半部分内容在向量里完全不存在。而且大部分 embedding 模型训练时用的就是句子和段落级别的语料，超过训练长度分布的输入，位置编码外推失效，向量质量本身就没有保障。所以切片首先是「模型能吃多少」的硬约束，不是可选优化。

语义稀释：一个向量装不下一本书

就算模型支持长输入，整篇 encode 还有一个更本质的问题：单个向量能表达的信息量是有限的。embedding 模型对长文本的编码近似于「全文语义的加权平均」，文档越长、主题越多，平均出来的向量就越平庸——一篇同时讲安装、配置、排错、API 参考的运维手册，整篇向量会落在四个主题的语义重心之间，和哪个都不足够接近。用户问「端口被占用怎么排查」，这篇手册的整篇向量和这条 query 的相似度，很可能低于一篇只讲排错的短文档，真正含答案的文档反而被埋掉。

检索的本质是在向量空间里做最近邻搜索，粒度决定了匹配精度。切片就是把匹配单元从「文档」细化到「语义段落」，让每个 chunk 只承载一个相对集中的话题，query 才能精准命中。

检索粒度与上下文的平衡

切片还有个收益经常被忽略：减少喂给 LLM 的无关上下文。整篇检索意味着命中一篇就要把几万 token 塞进 prompt，成本爆炸不说，无关内容还会稀释模型的注意力、引入干扰信息导致幻觉。切片后只取 top-K 个 chunk，通常几百到几千 token，信噪比高一个量级。

但切片不是越碎越好，这是核心 trade-off：

• chunk 太大：语义稀释，还浪费上下文窗口；
• chunk 太小：语义不完整，一句话脱离上下文可能指代不明（「该参数默认关闭」——哪个参数？），检索命中了模型也读不懂。

工程上常见的落点是 256 到 512 token 配 10% 左右的重叠（overlap），重叠用来缓解答案恰好被切在边界的问题。

常用切片策略

按实施成本从低到高：

我处理结构化文档时的习惯是：按标题层级切，每个 chunk 的 metadata 里存完整章节路径，且把「文档标题 > 一级标题 > 二级标题」拼在 chunk 正文前面一起向量化——这解决了小 chunk 脱离上下文指代不明的问题，成本低收益大。

收尾一句：长上下文模型不消灭切片

面试官可能会反问「现在模型上下文都 128K 了，还要切片吗」。要。原因没变：embedding 的语义稀释问题与上下文窗口无关，检索粒度需求也没变——塞进 128K 上下文让模型自己找答案，成本高、速度慢，而且「大海捞针」测试表明模型对中段信息的利用仍然不稳定。切片是检索精度的前提，这一点不因上下文变长而改变。

可能的追问

• chunk size 怎么定？ 答：没有通用最优值，在自家评测集上扫 128/256/512/1024 几档对比 Recall@K；一般 256-512 token 起步，技术文档偏小、叙事文档偏大。
• 表格和代码块怎么切？ 答：不当普通文本切。表格尽量整表保留转 markdown，超大表按行组切并重复表头；代码块按函数/类边界切，切断了语义就废了。
• 怎么评估切片策略的好坏？ 答：构造答案位置已知的评测集，对比不同策略下答案所在 chunk 的召回率；同时看端到端答案正确率，召回好但答案错说明 chunk 上下文不足。
• 父子切分（parent-child）了解吗？ 答：小 chunk 做检索保证命中精度，命中后取它所属的父 chunk（或相邻窗口）喂给 LLM 补全上下文——检索粒度和阅读上下文解耦，是兼顾两者的常用方案。