在之前的向量检索、幻觉抑制两篇内容里我们讲完了检索调优和生成校验的方法后台收到很多读者反馈按照教程把检索参数、Prompt约束、幻觉校验都加上了但是效果还是不好要么召回的内容半截要么大模型张冠李戴要么还是有很多幻觉。排查到最后几乎80%的问题从知识库分块这一步就已经埋下了。你有没有遇到过这种情况检索回来的内容看起来相似度很高但是点进去看是半截代码、半张表格或者脱离了上下文根本看不懂明明知识库更新了最新的内容大模型还是用旧内容回答甚至有时候分块把一句话从中间切断检索回来的内容意思完全反过来很多人遇到这些问题第一反应是换大模型、调检索阈值折腾半天没效果其实根本原因是分块没做对。先搞懂为什么分块是GEO效果的隐形天花板很多人对分块的认知就是“把长文档切成短块”觉得是个没技术含量的预处理步骤实际上分块是连接知识库和检索、生成环节的核心节点——分块的质量直接决定了向量的质量、检索的准确率以及大模型最终会不会采信你给的内容。分块在GEO技术流程里的位置分块做不好后面的检索模型再强、Prompt写得再好也没用向量是基于分块后的文本生成的分块语义不完整向量就不准检索自然召不对分块粒度不对给大模型的内容要么太长有噪声要么太短没上下文大模型自然会生成错误内容。 我们见过太多团队花了几个月时间调检索、调大模型最后回头把分块改对效果直接提升30%以上之前做的很多调优工作其实都是在给分块的问题补窟窿。GEO分块和通用RAG分块的核心差异网上绝大多数分块教程都是通用RAG场景的直接照搬到GEO场景里效果会很差核心是两者的目标不一样通用RAG分块只需要考虑检索能不能找到相关内容但是GEO分块还要考虑两个额外的维度一是大模型对内容的采信度二是生成内容的引用粒度是否合适。 简单来说通用RAG分块只要“找得到”就行GEO分块不仅要“找得到”还要“看得懂、用得上、引对源”这也是为什么很多人照着网上的分块教程做效果还是不好的核心原因。分块不好会带来哪些具体问题根据我们的统计分块配置错误会直接导致三个核心问题第一是召回准确率下降15%-30%很多相关内容因为分块切断语义根本召不回来第二是幻觉率上升10%-20%分块带来的语义缺失、上下文丢失是很多幻觉的根源第三是token浪费30%以上不合理的重叠和过大的分块会让每次检索塞给大模型很多无用内容增加成本和延迟。我们提出的GEO分块三原则在20不同类型技术知识库的调优过程中我们总结了一套专门针对GEO场景的分块原则我们把它叫做GEO分块三原则所有分块策略和参数选择都围绕这三个原则展开按照这个原则配置分块不需要反复试错就能拿到不错的基线效果。第一原则语义完整性优先分块的第一要务是保证每个块里的内容是语义完整的不能把一个完整的知识点、一段完整的代码、一个完整的表格从中间切断。很多人盲目追求小分块把完整的语义拆得七零八落就算检索回来了大模型看到半截内容也根本没法正确理解反而更容易产生幻觉。 我们认为GEO场景下的分块优先级语义完整性永远是第一位的为了检索方便牺牲语义是本末倒置。第二原则引用粒度适配GEO场景下大模型生成内容需要标注引用来源分块的粒度要和引用粒度匹配分块太大一个块里包含五六个不同的知识点大模型引用的时候没法精准对应到具体来源分块太小一个知识点拆成三四个块大模型要同时引用多个块很容易把内容混在一起。 对于技术类GEO场景来说一个分块对应一个独立的小知识点是最合适的大模型引用的时候可以精准对应也不会出现一个块里内容太多混进噪声的问题。第三原则检索友好在满足前两个原则的基础上再考虑检索的需求分块大小要适配嵌入模型的最优输入长度块和块之间保留合适的重叠避免上下文衔接的内容被切断同时要保留足够的元数据比如章节标题、文档版本、更新时间帮助检索和生成环节判断内容的权重和时效性。这里先给大家说一个反常识的结论网上几乎所有教程都在说分块越小越好推荐128token、256token的小分块但是我们在20技术类知识库的实测结果显示512token分块20%重叠的配置比网上流行的128token小分块召回准确率高23%幻觉率低18%。原因很简单128token的分块根本装不下一个完整的技术知识点很多时候一个参数说明、一段代码示例都不止128token强行切成小块会严重破坏语义完整性反而让大模型更难采信。五种主流分块策略实测对比目前行业里主流的分块方法一共有五种我们在同样的测试集10万篇技术类文档1000条标注查询上做了对比测试所有数据都是相同测试环境下的实测结果大家可以根据自己的文档类型选择。分块策略核心逻辑召回准确率幻觉率处理速度适用文档类型固定大小分块按固定token数硬切割不考虑语义62.7%16.3%极快纯文本、格式简单的FAQ递归字符分块按换行、标点、字符优先级递归切割尽量不切断句子74.2%11.8%快普通技术文档、长文语义分块计算句子间语义相似度在语义切换处切割81.5%8.7%中等主题切换多的杂合类文档结构化分块识别文档里的标题、列表、代码块、表格按结构切割87.3%5.2%较慢API文档、规范类文档、带代码的技术文档标题层级分块按Markdown/文档的标题层级切割每个标题下的内容作为一个块84.6%6.1%快层级清晰的官方文档、教程类文档数据来源2026年我们在技术类GEO知识库上的实测结果测试集包含1000条人工标注的查询-相关文档对默认分块大小512token重叠率20%不同分块策略的适用场景说明没有绝对最优的分块策略只有最适合文档类型的策略纯文本短内容用固定大小分块性价比最高普通技术文档用递归字符分块就足够如果文档里有大量代码、表格、API定义一定要用结构化分块效果提升最明显如果文档本身标题层级非常清晰用标题层级分块是最简单效果也不错的选择。 根据我们的观察80%的GEO系统效果差第一个要排查的就是分块配置而不是大模型或者Prompt。很多人上来就用最简单的固定大小硬切割也不管文档里有没有代码和表格效果差是必然的。分块核心参数怎么调分场景最优配置表很多人调分块参数只会瞎试一会儿改大一会儿改小实际上不同类型的文档有非常明确的最优参数区间直接对照这个表配置就可以不需要自己反复试错。文档类型最优分块大小token最优重叠率推荐分块策略注意事项短FAQ/问答对128-25610%固定大小分块一个问答对作为一个块不要拆分普通技术博客/长文384-51215%-20%递归字符分块保留章节标题作为元数据API/接口文档256-51210%结构化分块单个接口定义作为一个块不要拆分参数和返回值代码类文档/教程512-76820%结构化分块代码块必须完整保留不能从中间切断规范/标准类长文档512-102420%标题层级分块按小节切割保留完整层级元数据表格/结构化数据单表/单块0%结构化分块表格必须完整保留不能拆分行/列这里多提一句重叠率不是越高越好很多人把重叠率设到30%以上不仅会浪费大量token还会让相邻分块出现大量重复内容大模型看到重复内容反而会提升幻觉出现的概率20%是绝大多数场景的最优值不要设太高。 关于多语言混合语料的分块最优参数目前行业里还没有统一的结论我们也还在不同语种的语料上持续测试目前给出的参数主要是中文技术文档场景下的经验值英文、中英混合的场景可能需要适当调小分块大小。可直接复用的通用分块核心代码给大家一个不依赖特定框架的通用分块实现包含了重叠处理、元数据保留、代码块/表格识别功能直接替换文件路径就可以用适合绝大多数技术类文档场景import re from typing import List, Dict class GEODocumentChunker: def __init__(self, chunk_size: int 512, chunk_overlap: float 0.2): self.chunk_size chunk_size self.chunk_overlap int(chunk_size * chunk_overlap) # 代码块、表格正则匹配 self.code_block_pattern re.compile(r[\s\S]*?) self.table_pattern re.compile(r\|.*\|\n(\|.*\|[-:].*\|\n)?(\|.*\|\n)) def _extract_structured_blocks(self, text: str) - List[Dict]: 提取结构化块代码块、表格、普通文本 blocks [] last_pos 0 # 先提取所有代码块和表格 structured_matches list(re.finditer(f{self.code_block_pattern.pattern}|{self.table_pattern.pattern}, text)) for match in structured_matches: start, end match.span() # 前面的普通文本 if start last_pos: blocks.append({type: text, content: text[last_pos:start]}) # 结构化内容单独作为一个块 blocks.append({type: structured, content: match.group()}) last_pos end # 剩下的普通文本 if last_pos len(text): blocks.append({type: text, content: text[last_pos:]}) return blocks def _split_text_recursive(self, text: str) - List[str]: 递归分割普通文本按换行、句号、空格优先级切割 separators [\n## , \n### , \n\n, \n, 。, , , , , ] def _split(text: str, sep_idx: int) - List[str]: if len(text) self.chunk_size or sep_idx len(separators): return [text] parts text.split(separators[sep_idx]) chunks [] current_chunk for part in parts: if len(current_chunk) len(part) len(separators[sep_idx]) self.chunk_size: current_chunk part separators[sep_idx] else: if current_chunk: chunks.extend(_split(current_chunk, sep_idx 1)) current_chunk part separators[sep_idx] if current_chunk: chunks.extend(_split(current_chunk, sep_idx 1)) return chunks return _split(text, 0) def split_document(self, content: str, metadata: Dict None) - List[Dict]: 分块主函数返回带元数据的分块结果 if not metadata: metadata {} chunks [] blocks self._extract_structured_blocks(content) current_text for block in blocks: if block[type] structured: # 结构化块先把之前的普通文本分块再把结构化块单独加进去 if current_text.strip(): for text_chunk in self._split_text_recursive(current_text): chunks.append({ content: text_chunk.strip(), metadata: {**metadata, type: text} }) current_text # 结构化块不管多长都单独作为一个块不拆分 chunks.append({ content: block[content].strip(), metadata: {**metadata, type: structured} }) else: current_text block[content] # 处理最后剩下的普通文本 if current_text.strip(): for text_chunk in self._split_text_recursive(current_text): chunks.append({ content: text_chunk.strip(), metadata: {**metadata, type: text} }) # 处理块之间的重叠 for i in range(1, len(chunks)): prev_content chunks[i-1][content] overlap_content prev_content[-self.chunk_overlap:] if len(prev_content) self.chunk_overlap else prev_content chunks[i][content] overlap_content chunks[i][content] return chunks使用的时候直接初始化Chunker传入文档内容和元数据就可以得到分块结果代码块和表格会被完整保留不会被切断普通文本会按语义递归分割自动处理重叠。90%的人分块都会踩的三个坑我们调过的很多GEO知识库分块出问题基本都是踩了这三个非常基础的坑都是做工程化的时候很容易忽略的点。坑一硬切割切断结构化内容这是最常见也最影响效果的坑很多人用最简单的固定大小分块根本不识别文档里的代码块、表格、列表经常出现代码被从中间切断、表格拆成两半、列表项被拆分的情况。这种半截内容就算被检索回来大模型也根本没法正确理解甚至会把半截代码当成正确内容输出造成严重错误。 我们见过最夸张的情况一个API文档的分块把参数说明从中间切断前半部分说参数是必填后半部分说选填最后大模型输出的内容完全相反。坑二分块不带上下文元数据很多人分块的时候只存文本内容不把章节标题、文档版本、更新时间这些元数据存在分块里导致同一个术语在不同章节、不同版本里的意思不一样检索回来的内容张冠李戴。 比如技术文档里“配置参数”这一章讲的是系统配置“接口参数”这一章讲的是接口参数分块不带章节标题的话检索“参数怎么配置”的时候很可能把接口参数的内容召回来大模型根本分不清是哪个参数。坑三为了提升召回率盲目调小分块、加重叠很多人看网上的教程说分块越小召回率越高就把分块设成128token甚至更小重叠率设到30%以上最后不仅召回率没提升幻觉率反而高了很多。小分块会把完整的知识点拆得七零八落语义不完整过高的重叠率会让相邻分块重复内容太多不仅浪费token还会让大模型看到重复内容更容易产生幻觉。顺便说一句很多人分块完不做质量校验直接就生成向量入库等上线了才发现问题这时候再重新分块重新生成向量成本非常高。分块完一定要随机抽10%的块做人工校验看看有没有切断语义、有没有结构化内容被拆分没问题再入库。分块效果怎么验证简单可落地的检查方法分块做完不是就完事了还要做效果验证不需要复杂的测试做三个简单的检查就可以覆盖90%的问题结构化检查随机抽20个包含代码、表格的分块确认没有被从中间切断内容完整语义检查随机抽50个分块不看上下文单独读这个块的内容能不能看懂说的是什么有没有没头没尾的内容检索验证拿20个常见查询做检索看召回的分块是不是包含完整的答案有没有半截内容、无关内容 如果这三个检查都过了分块的基线效果就不会差后续再根据实际查询情况微调参数就可以。分块技术的未来发展方向观察关于分块技术的发展我们也在持续跟进目前能看到三个比较明确的方向 第一个方向是动态分块不再用固定的分块大小而是根据文档内容、查询类型动态调整分块粒度查询宽泛的时候用大分块查询具体的时候用小分块兼顾语义完整性和检索精度。 第二个方向是分块和嵌入模型结合现在已经有嵌入模型支持长文档输入不需要提前分块模型自动在内部做语义分割未来可能不再需要人工设计分块策略。 第三个方向是多粒度分块一个文档同时存多个粒度的分块大的章节块、小的知识点块检索的时候同时检索多个粒度的内容根据查询类型选择合适粒度的内容送给大模型。 我们判断未来1-2年静态固定分块会逐渐被动态语义分块取代但是在目前的技术阶段我们说的三原则和五种分块策略还是性价比最高的技术实现方案。最后说几个实操中的注意点最后再和大家强调几个实操中容易被忽略的点不要盲目追求最复杂的分块策略普通技术文档用递归分块就足够结构化文档再加结构化识别不是越复杂的策略效果越好分块参数一定要在自己的文档上做小范围测试别人的最优参数不一定适合你的文档类型我们给的参数表是基线在此基础上微调就可以知识库更新的时候一定要注意新旧版本分块的隔离不要让新旧版本的分块同时存在否则大模型很容易混新旧内容产生幻觉不要在分块里加太多无关的元数据元数据只保留必要的标题、版本、时间就可以太多无关内容会干扰向量的语义表达。参考资料《检索增强生成RAG技术原理与实战》机械工业出版社2025《大模型知识库构建技术规范》中国人工智能产业发展联盟2026Chunking Strategies for Retrieval-Augmented Generation: A BenchmarkarXiv预印本2025《生成式引擎优化GEO技术白皮书》中国信通院2026标签#GEO #生成式引擎优化 #RAG分块 #知识库构建 #大模型
