面试官Chunking 的时候语义被切断是个很常见的问题你有没有遇到过怎么处理的‍♂️我遇到过加个 overlap 重叠就好了前后重叠个 100 token基本不会出问题。面试官overlap 只是兜底方案它能保证跨边界的文字不丢失但解决不了「一个完整语义被拆散」的问题。比如「企业用户享有优先客服通道响应时间不超过 2 小时并可申请专属技术顾问服务」这句话被切成两段两段单独看相关度都不高overlap 帮得了吗‍♂️我呃……那就把 chunk 设大一点每个 chunk 包含更多内容就不会断了。面试官chunk 越大语义越杂检索精度越差。你这是用一个问题去换另一个问题。句子窗口检索呢父子切割呢Contextual Retrieval 呢一个都没听说过好吧语义截断这个问题远比加个 overlap 复杂下面我来把各种方案讲透。 简要回答我的思路是从两个方向来规避这个问题。第一个方向是切的时候就不要在语义中间截断用重叠切割和语义边界切割来保证每个 chunk 内容是完整的也就是按句子、段落这些自然的边界来切。第二个方向是切完之后用检索策略把上下文补回来核心方案是句子窗口检索命中一个句子就把周围几句一起返回给 LLM另外还有父子切割小块检索命中、大块内容输出。还有一个我觉得比较有价值的方案是 Anthropic 提出的 Contextual Retrieval在做 Embedding 之前先让大模型看着整篇文档为每个 chunk 生成一段背景说明把这段背景和 chunk 拼在一起再向量化从根本上解决孤立 chunk 没头没尾的问题。 详细解析语义被切割是什么问题?先把问题说清楚。假设文档里有这样一段内容...前三条款适用于个人用户。第四条企业用户享有优先客服通道响应时间不超过 2 小时并可申请专属技术顾问服务。此条款自 2024 年起生效。...如果 chunk 的边界恰好切在「响应时间不超过 2 小时」这里那「企业用户享有优先客服通道」和「并可申请专属技术顾问服务」就被分到了两个 chunk。你可能会想两个 chunk 里都有部分答案搜到其中一个不就行了问题是两个 chunk 单独来看相关度都不高极可能都不会被召回答案就断了。这就是语义截断的核心问题不是信息丢了而是信息被拆散之后每一半都不够强检索时全军覆没。方案一重叠切割Overlap最基础的方案让相邻 chunk 之间有一段内容重叠这样就算边界切在语义中间跨边界的内容也一定会完整地出现在其中一个 chunk 里。重叠量通常设为 chunk_size 的 10%20%比如 chunk_size800overlap150。你可能会问为什么不直接设大一点比如重叠 40%这是实践经验摸出来的平衡点太小了比如 5%重叠区域覆盖不了完整的跨边界语义保护效果弱太大了比如 40%重复内容太多存储和检索成本上升而且大量重复内容还会干扰 LLM 的阅读和理解。重叠切割是所有方案的基础几乎每个 RAG 系统都应该开启但它只是兜底不能彻底解决语义截断问题。很多人以为加了 overlap 就万事大吉了其实它只能保证跨边界的文字不丢失解决不了「一个完整语义被拆散」的根本问题。方案二按语义边界切割重叠切割既然只是兜底那能不能在切的时候就更聪明一点直接避免在语义中间截断这就是语义边界切割的思路——找到文本中自然的语义边界再切。为什么要识别句子边界因为句子是语言表达意思的最小完整单位一个完整的句子包含了主语、谓语、宾语能独立表达一个意思。把句子从中间截断前半截和后半截单独来看都是残缺的向量化后的语义也是扭曲的。实际操作时可以用 NLP 工具比如spacy或nltk识别句子结束位置然后以句子为单位填充 chunk把句子一条条往当前 chunk 里加加满了就封存这个 chunk 开启新的不会在句子中间截断。对于段落分明的文档还可以在句子边界的基础上优先在段落边界处切效果更好。方案三句子窗口检索Sentence Window Retrieval前面两种方案都是在「怎么切」上做文章到了这一步思路就变了——切归切检索的时候再把上下文补回来。这个方案的思路和前两个完全不同它不是在「切」上做文章而是在「检索后如何返回上下文」上做文章。类比一下就像你在图书馆里用关键词找到了某本书里的一句话但你实际阅读的是这句话所在的整个段落而不是只拿走那一行文字。具体做法是存储时把文档切成单个句子每个句子单独做向量用于精准检索检索命中一个句子后并不只返回这一个句子而是把这个句子前后各 N 个句子一起返回形成一个上下文窗口交给 LLM 阅读。这样的好处是两全其美检索粒度细单句定位准确相关性高但给 LLM 的内容是完整的上下文窗口不会因为检索粒度太细而导致 LLM 拿到的信息不完整。缺点是存储量较大每个句子都需要单独向量化库里的记录数等于文档的句子总数。方案四父子切割Parent-Child Chunking理解了句子窗口检索的「检索命中后动态扩展上下文」思路父子切割就很好懂了它是一种更结构化的实现方式。父子切割的思路是「用小 chunk 检索用大 chunk 生成」存储时同一段内容存两份一份是细粒度的小 chunk比如 200 token一份是包含这个小 chunk 上下文的大 chunk比如 1000 token两者通过 ID 关联。检索时用小 chunk语义聚焦召回精度高命中后把对应的大 chunk 返回给 LLM上下文更完整生成质量更好。和上面句子窗口检索对比句子窗口是检索命中后动态扩展上下文父子切割是提前把父子关系存好。两者思路相近父子切割更灵活父 chunk 大小可以精确控制句子窗口实现更简单不需要维护父子 ID 关系。方案五命题化切割Propositions-based Chunking前面几种方案都是在「怎么切」或「切完怎么补上下文」上想办法那有没有一种方案能从根本上让每个 chunk 天然就是完整独立的命题化切割就是冲着这个目标来的。这是质量最高但成本也最高的方案思路不按文本位置切割而是用 LLM 把文档分解成一条条独立的「命题」Proposition。每个命题是一个完整、自包含的陈述句包含了表达这个事实所需的全部上下文单独拿出来就能看懂不依赖上下文只包含一个核心事实。举个例子来感受一下。原文是「企业用户享有优先客服通道响应时间不超过 2 小时并可申请专属技术顾问服务。」分解成命题后变成三条独立陈述「企业用户享有优先客服通道。」「企业用户的客服响应时间不超过 2 小时。」「企业用户可以申请专属技术顾问服务。」这三条单独拿出来都能看懂不需要任何上下文辅助向量化后的语义密度极高。命题化切割的优势是每个 chunk 的语义密度最高、最独立检索精度非常好。缺点是需要额外的 LLM 调用来生成命题成本比较高适合对质量要求极高的场景。方案六Contextual RetrievalAnthropic命题化切割是用 LLM 重新组织 chunk 内容而 Contextual Retrieval 则换了一个角度不改变 chunk 本身而是在向量化之前把缺失的上下文补进去。这是 Anthropic 在 2024 年提出的方案思路和前面几种完全不同它不是在「怎么切」或「检索后怎么扩展」上做文章而是在向量化之前就把缺失的上下文补进去。先说一下这个方案要解决的根本问题chunk 被单独拿出来后就失去了语境。一个 chunk 在向量化时Embedding 模型只能看到这段文字本身根本不知道它来自哪篇文档、讲的是什么主题。比如「此条款自 2024 年 1 月 1 日起生效」这段文字单独向量化后完全丢失了「这是企业版客服条款」这一关键信息检索时自然容易被无关内容干扰。你可能会觉得奇怪向量不是能捕捉语义吗为什么会丢信息原因很简单向量只能捕捉它「看到」的文字里的语义它看不到的那部分背景信息自然没法编码进向量里。向量里没有主题信息是孤立 chunk 召回质量低的根本原因。核心做法分两步生成 Context让 LLM 看着整篇原始文档为每一个切出来的 chunk 生成一段简短的背景说明通常 12 句话说清楚这个 chunk 在整篇文档里处于什么位置、讲的是什么拼接再向量化把生成的 Context 前置拼到 chunk 前面然后把这个「Context chunk」整体去做 Embedding 和 BM25 索引具体来说这一步会用 LLM 传入完整文档和当前 chunk让模型生成「这段内容是关于什么的」的背景说明再把背景说明和原始 chunk 拼在一起整体向量化入库。举个例子来感受一下效果。假设原始 chunk 是此条款自 2024 年 1 月 1 日起生效适用于所有企业版订阅用户。没有上下文时这个 chunk 孤立地看完全不知道「此条款」指的是什么向量检索时很容易被其他内容干扰。Contextual Retrieval 生成的 Context 可能是这段内容说明了企业用户专属客服和技术顾问服务条款的生效日期和适用范围。拼在一起向量化的就是这段内容说明了企业用户专属客服和技术顾问服务条款的生效日期和适用范围。此条款自 2024 年 1 月 1 日起生效适用于所有企业版订阅用户。现在这个 chunk 的向量里就包含了「企业用户」「客服条款」「生效日期」这些关键语义检索时被正确召回的概率大幅提升。成本控制用 Prompt Caching 大幅降低 LLM 调用费用你可能会担心每个 chunk 都要调一次 LLM这成本得多高确实这是 Contextual Retrieval 最大的顾虑但 Anthropic 的 Prompt Caching 特性可以把这个成本降低 80%-90%每次调用时full_document完整文档在所有 chunk 的请求里是相同的前缀。开启 Prompt Caching 后第一次调用会把文档内容缓存到 KV Cache后续同一篇文档的所有 chunk 请求都复用这份缓存只有 chunk 部分需要重新计算。一篇有 100 个 chunk 的文档实际只需要完整处理 1 次文档剩余 99 次只处理各自的 chunk成本直接打一折。整体工程上只需要在调用时把文档内容标记为可缓存前缀框架就会自动复用。根据 Anthropic 的测评数据Contextual Retrieval 结合 BM25 混合检索能将检索失败率Top-20 召回未命中目标 chunk 的比例降低约 49%是目前业界实测效果最显著的 chunk 质量提升方案之一。把几种方案的核心思路对比一下实际选型时按场景组合使用方案核心思路适合场景代价重叠切割相邻 chunk 有内容重叠所有场景基础兜底存储轻微增加语义边界切割在句子/段落边界处切段落结构清晰的文档需要 NLP 工具句子窗口检索精细检索 扩展返回窗口追求高召回精度存储量大父子切割小块检索、大块返回通用场景效果均衡存储翻倍、索引复杂命题化切割LLM 拆解为独立命题高质量要求、重要知识库LLM 调用成本高Contextual Retrieval向量化前为每个 chunk 补全背景上下文文档语境强、chunk 孤立感严重的场景LLM 调用成本Prompt Caching 可大幅降低 面试总结回到开头那段面试语义截断问题的回答不能只停留在「加个 overlap」。面试官想听的是你对问题本质的理解和多种方案的掌握。先说清问题chunk 被单独拿出来后失去语境语义被拆散导致检索召回不到。然后分两个方向讲方案一是「切的时候别截断」包括重叠切割、语义边界切割二是「切完之后补上下文」包括句子窗口检索、父子切割、命题化切割、Contextual Retrieval。实际工程中通常是组合使用重叠切割做兜底语义边界切割保证切割质量对高质量要求的场景再加父子切割或 Contextual Retrieval。能把这个组合思路讲出来面试官就满意了。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】