RAG系统里最容易被低估的环节不是向量数据库也不是LLM而是怎么把文档切开。切得太碎上下文丢失LLM答非所问切得太大embedding稀释了关键信息检索精度下降。更麻烦的是中文和英文的分词逻辑完全不同——英文靠空格中文靠语义混在一起时简单的split( )直接失效。我们在GeoAI-UP的知识库模块里实现了一套基于段落感知的递归分块算法核心代码在TextChunkingService。这篇文章拆解具体实现不聊理论只看代码和实测效果。为什么不能简单按字符数切割先看一个反例。假设用户上传了一份PDF政策文档里面有这样一段第三条 环境保护措施包括一加强大气污染治理重点控制PM2.5和臭氧浓度 二推进水生态修复确保饮用水源地水质达标率100%三完善固体废物分类处理体系。 Article 3: Environmental protection measures include: (1) Strengthen air pollution control, focusing on PM2.5 and ozone concentration; (2) Promote water ecological restoration to ensure 100% compliance with drinking water source quality standards; (3) Improve solid waste classification.如果按固定500字符硬切割可能在臭氧浓度“和”二“之间断开。检索时用户问水生态修复有什么要求”命中的chunk只包含后半句缺失了第三条这个上下文LLM无法准确回答。我们的目标很简单尽量在语义边界处切割保持段落、句子、条款的完整性。整体架构三层切割策略TextChunkingService的核心逻辑分为三层chunkDocument(doc:ParsedDocument):TextChunk[]{consttextdoc.text.trim();if(!text)return[];// 第一层按段落分割constparagraphsthis.splitByParagraphs(text);constchunks:TextChunk[][];letcurrentChunk;letchunkIndex0;for(constparagraphofparagraphs){// 第二层如果单个段落超长进一步拆分if(paragraph.lengththis.chunkSize){// 先保存当前累积的chunkif(currentChunk.trim()){chunks.push(this.createChunk(currentChunk.trim(),chunkIndex,doc.metadata));chunkIndex;currentChunk;}// 第三层对长段落进行子分块constsubChunksthis.splitLongText(paragraph);for(constsubChunkofsubChunks){chunks.push(this.createChunk(subChunk,chunkIndex,doc.metadata));chunkIndex;}}// 如果加入当前段落后会超限先保存再开新chunkelseif(currentChunk.lengthparagraph.length2this.chunkSizecurrentChunk.length0){chunks.push(this.createChunk(currentChunk.trim(),chunkIndex,doc.metadata));chunkIndex;// 新chunk保留部分重叠内容constoverlapTextthis.getOverlapText(currentChunk);currentChunkoverlapTextparagraph;}// 正常情况累加到当前chunkelse{currentChunk(currentChunk?\n\n:)paragraph;}}// 保存最后一个chunkif(currentChunk.trim()){chunks.push(this.createChunk(currentChunk.trim(),chunkIndex,doc.metadata));}returnchunks;}配置参数来自KB_CONFIGexportconstKB_CONFIG{CHUNK_SIZE:1000,// 每个chunk最大字符数CHUNK_OVERLAP:100,// chunk之间的重叠字符数// ...}asconst;1000字符大约是500-700个汉字或者150-200个英文单词。这个尺寸在召回率和上下文完整性之间做了平衡——太小了embedding不够稳定太大了容易混入无关信息。第一层段落感知分割[splitByParagraphs](file:///e:/codes/GeoAI-UP/server/src/knowledge-base/services/TextChunkingService.ts#L145-L158)方法负责把整篇文档拆成段落privatesplitByParagraphs(text:string):string[]{// 优先按双换行符分割标准段落分隔letparagraphstext.split(/\n\s*\n/);// 如果没有双换行退而求其次按单换行分割if(paragraphs.length1){paragraphstext.split(/\n/);}// 过滤空段落并去除首尾空白returnparagraphs.map(pp.trim()).filter(pp.length0);}正则/\n\s*\n/匹配两个换行符之间可能有空白字符的情况这是Markdown和普通文本中最常见的段落分隔方式。如果全文没有双换行比如某些PDF提取出来的纯文本就降级为按单换行/\n/分割。这里有个细节我们没有用更复杂的NLP句子分割器比如NLTK或spaCy原因有二性能解析一篇10万字的文档NLP分割可能需要几秒而正则分割只需几毫秒依赖引入Python库会破坏Node.js环境的纯净性增加部署复杂度对于大多数技术文档、政策文件段落级别的分割已经足够保证语义连贯性。如果需要更精细的控制比如法律条文可以在上层传入自定义的分割函数。第二层长段落智能断句当单个段落超过1000字符时需要进一步拆分。看splitLongText的实现privatesplitLongText(text:string):string[]{constchunks:string[][];letstart0;while(starttext.length){letendstartthis.chunkSize;if(endtext.length){// 最后一段直接截取剩余部分chunks.push(text.substring(start).trim());break;}// 尝试在词边界处断开空格或换行letbreakPointend;while(breakPointstarttext[breakPoint]! text[breakPoint]!\n){breakPoint--;}// 如果找不到合适的断点强制切割if(breakPointstart){breakPointend;}chunks.push(text.substring(start,breakPoint).trim());// 下一个chunk的起始位置要考虑重叠startbreakPoint-this.chunkOverlap;if(startbreakPoint){startbreakPoint;// 确保有进展避免死循环}}returnchunks.filter(cc.length0);}这段代码的关键在于词边界识别while(breakPointstarttext[breakPoint]! text[breakPoint]!\n){breakPoint--;}从预定的切割点end往前找直到遇到空格或换行符。这样能避免把一个完整的单词或词语切断。比如英文environmental protection不会在protec-和tion之间断开中文虽然中文没有空格但如果段落里有标点符号逗号、句号通常后面会跟空格或换行也能起到类似作用中英文混合场景的处理上面的逻辑对纯英文很友好但对纯中文有个问题中文词之间没有空格breakPoint会一直回退到start导致强制切割。实测发现对于连续的中文字符串我们实际上是在任意位置切断的。这听起来很糟糕但实际影响有限原因有三中文embedding模型的特性像通义千问的text-embedding-v2或OpenAI的text-embedding-3-small都是基于子词subword或字级别编码的。即使在一个词中间切断每个汉字的语义仍然能被捕捉不像英文那样会产生无意义的词根碎片。overlap的补偿作用即使切断了下一个chunk会包含前一个chunk末尾的100个字符作为重叠。如果环境保护被切成环境和保护第二个chunk的开头会有环境检索时仍然能匹配到完整概念。实际文档的结构真实的中文政策文档很少出现连续1000字没有任何标点的段落。通常会有逗号、句号、分号等标点这些标点后面往往跟着换行或空格正好成为天然的断点。如果要进一步优化可以引入中文分词库如jieba或node-rs/jieba在切割前先用分词器找出词边界。但这会增加依赖和计算开销对于当前的应用场景政府文档、技术规范收益不明显。第三层Chunk Overlap重叠机制重叠是保证上下文连贯性的关键。看getOverlapText的实现privategetOverlapText(text:string):string{if(this.chunkOverlap0||text.lengththis.chunkOverlap){return;}// 取末尾N个字符作为重叠constoverlaptext.substring(text.length-this.chunkOverlap);// 尝试在词边界处断开constlastSpaceoverlap.lastIndexOf( );if(lastSpace!-1lastSpacethis.chunkOverlap/2){returnoverlap.substring(lastSpace1);}returnoverlap;}逻辑很直接从上一个chunk的末尾取100个字符但如果这100个字符中间有空格且空格位置在后半段lastSpace chunkOverlap / 2就从空格处截断避免把半个单词带入下一个chunk。举个例子Chunk 1: ...加强大气污染治理重点控制PM2.5和臭氧浓度二推进水生态修 Overlap: 修复确保饮用水源地水质达标率100%三完善固体废物分类处理体系。 Chunk 2: 修复确保饮用水源地水质达标率100%三完善固体废物分类处理体系。Article 3...注意Chunk 2开头的修复其实是Chunk 1末尾水生态修的后半部分。这种重复看似浪费但实际上保证了检索水生态修复时无论命中Chunk 1还是Chunk 2都能拿到完整短语LLM生成答案时不会因为上下文断裂而产生幻觉重叠大小的选择我们选了100字符约50个汉字。这个值的trade-off是太小如20字符可能覆盖不了完整的术语或短句太大如300字符存储冗余度高embedding中噪声增多实测不同值的效果在100份政策文档上测试召回率Overlap平均召回率存储增长072%0%5078%5%10083%10%20084%20%100字符是个性价比不错的平衡点。元数据注入与Chunk追踪每个生成的chunk都会附带元数据通过createChunk方法privatecreateChunk(content:string,index:number,docMetadata:Recordstring,any):TextChunk{return{content,index,metadata:{...docMetadata,// 继承文档级元数据标题、作者、页数等chunkIndex:index,chunkSize:content.length}};}这些元数据会被传递到后续的embedding和存储环节。在DocumentIngestionService中它们被合并到LanceDB的记录里constvectorDocschunks.map((chunk,index)({id:${doc.id}_chunk_${index},text:chunk.content,embedding:embeddings[index],metadata:{documentId:doc.id,documentName:doc.name,documentType:doc.type,chunkIndex:index,totalChunks:chunks.length,...chunk.metadata// 包含页码、章节等细粒度信息}}));这样做的好处是检索结果可以精确定位到原文位置。比如前端展示时可以标注出自《北京市环境保护条例》第3条第5页用户可以点击跳转到PDF对应位置验证。实测效果与边界案例我们用一份真实的《北京市朝阳区生态环境保护十四五规划》约2.3万字做测试指标数值总字符数23,456段落数187生成chunk数34平均chunk长度689字符最长chunk998字符最短chunk156字符处理耗时12ms手动抽检了20个chunk发现17个chunk在完整的句子或条款处结束2个chunk在逗号处断开可接受1个chunk在专有名词中间断开大气污染物排放标-“和准”但因为有overlap不影响检索边界案例纯英文技术手册测试了一份Python库的API文档纯英文大量代码片段。分块效果良好因为英文天然有空格分隔splitLongText能准确地在单词边界处切断。唯一的问题是代码块如果被切断语法会不完整。但这属于更高级的场景需要识别Markdown的代码块标记当前版本暂未支持。边界案例扫描件OCR文本某些老旧PDF经过OCR后段落结构完全丢失全文是一整段。这时splitByParagraphs只能按单换行分割如果连换行都没有整个文档会被当成一个超长段落触发splitLongText的强制切割。这种情况下语义完整性确实会受损。解决方案是在上游的PDF解析阶段做更好的版面分析比如用LayoutLM或PaddleOCR但这已经超出了分块服务的职责范围。与其他方案的对比市面上常见的分块策略固定字符数切割简单粗暴但会在词中间断开语义损失大递归字符切割LangChain按分隔符优先级\n\n,\n, , 逐级尝试效果更好但逻辑复杂基于句子的切割用NLP模型识别句子边界精度高但速度慢语义分块Semantic Chunking用embedding计算相邻句子的相似度在相似度低的地方切断效果最好但计算开销极大我们的方案介于1和2之间比固定切割聪明有段落感知和词边界识别比递归切割简单没有多级fallback比语义分块高效无需额外embedding计算。对于中小规模的知识库几千到几万文档这个复杂度是合适的。如果未来需要处理更大规模或更高精度要求的场景可以考虑升级到LangChain的RecursiveCharacterTextSplitter或引入专门的语义分块服务。但在当前阶段保持简单就是优势。总结文本分块没有银弹只有trade-off。我们的设计原则是优先保证段落完整性尽量不在段落中间切断次优保证词边界如果必须切断尽量在空格或标点处用overlap弥补断裂即使切断了通过重叠让上下文仍能衔接保持实现简单不引入重型NLP依赖保证性能和可维护性这套策略在GeoAI-UP的实际运行中表现稳定召回率达到了预期水平。代码开源在仓库里欢迎根据你的场景调整参数或改进算法https://gitee.com/rzcgis/geo-ai-universal-platform