写分块的时候我脑子里冒出来的第一个画面就是刚工作那会儿带我的前辈拿着一篇质量堪忧的RAG项目代码问我“你看这个检索结果为什么老是把毫不相关的段落拽出来”我盯着屏幕看了半天最后发现问题出在最不起眼的文本分块上——几千字的文档直接被硬生生切成每段200字句子被劈成了两半语义全乱了。那一刻我才意识到大模型应用里真正决定效果上限的往往不是模型选得多强而是数据进模型之前你有没有把它收拾利索。今天这篇分享专门写给刚开始接触大模型的小白程序员。我会把手把手拆解一个最常见也最容易被忽略的环节——文本分块。它是什么、为什么重要、有哪些主流做法、代码怎么写、参数怎么调以及哪些坑我替你踩过了争取一篇讲透让你看完整个人都通透了。1. 项目概述小白入门大模型为什么第一课是文本分块1.1 文本分块到底处在什么环节先花一分钟搞清位置。现在主流的大模型应用尤其是文档问答、知识库助理、企业私有数据检索这类场景背后大多跑的是RAG检索增强生成。它的流程可以用四步概括加载文档、文本分块、向量化存储、检索生成。第二步就是文本分块也叫Chunking。它做的是把长文档拆成一截一截可以单独喂给模型、单独做相似度检索的片段。这些片段通常被称为“Chunk”。很多教程讲RAG的时候把大量篇幅给了Embedding模型和向量数据库讲分块两三句就带过了。但实战过的人都知道分块策略选得好不好直接决定检索能不能召回正确信息进而决定大模型最终回答得靠不靠谱。分块是整条链路上最不起眼、但性价比最高的优化点。1.2 分块质量差会引发什么连锁反应如果你把分块做得很随意后面会遇到一串连锁问题。第一检索召回错误。查询词被分到某个语义不完整的块里向量相似度计算时匹配到一堆无关内容。第二上下文被切断。一个完整的事件、逻辑叙述被拦腰截断大模型只拿到半截信息回答自然残缺。第三幻觉变严重。模型在上下文不足时会“脑补”结果就是一本正经地胡说八道。第四效率与成本双输。块切得太碎向量数量的存储和检索开销成倍上涨块切得太大超出模型上下文窗口或检索精度下降。这些问题很少单独出现通常是一起爆发的。你在调Prompt、换Embedding模型上折腾半天不如先回头看看分块的代码是怎么写的。1.3 这篇分享能帮你解决什么这个标题叫“收藏小白程序员轻松入门大模型”我理解“轻松”的意思不是不学原理而是少走弯路。读完这篇文章你会获得几件实实在在的东西搞懂分块背后的四个底层概念知道自己在调参时到底在调什么。掌握五种主流分块策略的适用场景和优缺点不再凭感觉选方案。拿到可以直接运行和改写的Python代码把分块器封装成自己的工具。学会chunk size和overlap的搭配艺术不再盲猜参数。收获一份常见问题速查表遇到坑的时候能快速定位。接下来我按实战的顺序一章一章写。2. 动手前必须理解的四个底层概念不先搞懂底层原理后面调起参来就跟瞎猜一样。这一节我把四个关键概念讲明白每个都用大白话加类比的方式。2.1 Token与上下文窗口为什么不能粗暴地“整篇灌入”小白最容易有的一个疑问是既然大模型这么强为什么不把整篇文档直接塞进去让它回答答案很简单——大模型对输入长度有限制这个限制叫上下文窗口。上下文窗口的单位是Token。Token可以粗略理解为模型处理文本的最小单元一段中文可能一个词拆成一两个Token一个英文单词可能拆成几个Token。不同模型的窗口大小不同有的支持几万Token有的才几千。你可以把模型想象成一个只能记住有限字数的“阅读者”。你把一部几十万字的“文档”整篇扔给它它根本读不过来只能截取前面一部分后面的内容全被忽略。文本分块本质上是在这条长度约束下把信息组织成“一碟一碟刚好能端上桌的小菜”。这里面有个非常关键的工程经验上下文窗口不是用来塞原始文档的而是用来放“检索到的相关内容用户问题Prompt指令”的。RAG的真正价值就是只用几分之一的窗口大小把最相关的信息精准地送到模型面前。2.2 Embedding与相似度检索分块质量为什么能影响召回大模型要回答你的问题得先从一个庞大的知识库里捞出来相关内容这个捞的过程靠的不是传统的关键词匹配而是Embedding。Embedding做的事情是把一段文本转换成一串高维向量一堆数字。语义相近的文本在向量空间里的距离也相近。当用户提问时系统把问题也转成向量然后在向量数据库里找出和它最接近的若干条记录。这时候分块的角色就凸显出来了。假设知识库里有这样一句话“隔壁老王养了一只三岁的橘猫它最喜欢吃小鱼干。”如果你把这句话和另一句完全无关的“橘猫是中华田园猫的一种毛色”切成前后相邻的两块当用户问“橘猫喜欢吃什么”时前一块很容易被选中因为它包含答案但如果你的分块算法把第一句的尾部切掉只剩“隔壁老王养了一只三岁的橘猫”向量里就丢失了“吃小鱼干”这个关键信息召回就会失败。分块粒度越合理每块内部的语义一致性越高Embedding越能准确表达“这块在讲什么”检索质量自然越高。2.3 信息密度与语义完整性分块的黄金平衡点分块的艺术是在两个互相矛盾的目标之间找平衡。目标A语义完整。每块内容是完整、自洽、有明确主题的模型拿到这一块就能理解上下文。 目标B内容精炼。每块只包含最核心的信息不要掺入太多不相关的内容否则检索时会引入噪声。这两个目标天然冲突。块越大语义越完整但噪声越多块越小内容越精炼但语义越容易被切断。高手和菜鸟的分水岭就在这个平衡点的把握上。我习惯用一个生活类比分块好比切西瓜。你要让每个人拿到一块能直接吃的瓜瓤既不能切太大块让人无从下口也不能切成碎末让人用勺子都舀不起来。理想的Chunk就是“一勺子刚好能送进嘴里”的大小。2.4 分块与检索里的“照妖镜”还有一个容易被忽视的点分块策略不是通用最优解而是跟你的业务数据类型强相关的。给你一份合同、一份技术文档、一段聊天记录和一个网页源码各自的最优分块方式完全不同。所以不要在网上复制一段分块代码改两个参数就跑项目。你需要理解每种方法的适用边界再针对自己的数据做测试。这一章的概念都打好基础后我们进入正题看看主流的几种分块策略。3. 主流分块策略逐一拆解这一章我把五种出现频率最高的分块方法讲清楚。每种方法我都会给出实现思路、适用场景和优缺点方便你对照自己的项目选型。分块策略实现思路适用场景优点缺点固定长度分块按字符或Token数硬切简单原型快速验证实现容易、速度极快容易切断语义滑动窗口分块相邻块保留重叠区间通用文档、长文本缓解信息断层存储冗余、成本略高递归字符分块按多级分隔符逐层切分绝大多数文本平衡语义与长度需要调分隔符优先级结构感知分块按Markdown、HTML、代码结构切技术文档、网页、代码库语义边界清晰依赖格式完整性语义分块用Embedding判断句子边界内容逻辑松散、话题多变语义一致性最强计算成本高、依赖模型质量3.1 固定长度分块最直白也最容易翻车固定长度分块是最朴素的方式设定一个chunk_size然后从头到尾按字数或Token数平均切分。实现起来不超过十行代码。它最大的优势是快、可预测、方便控制成本。你要精确知道每块多大这个方法是唯一能做到的。但它的问题同样明显完全不考虑语义。句子可能会被从中间切断一个完整的事件会被劈开段落之间可能出现莫名其妙的边界。举个例子如果chunk_size设成200字一段210字的核心介绍就会被硬生生切掉最后10个字而这10个字可能刚好是结论。我的建议是固定长度分块只适合做基线测试。项目起步时用它快速跑通流程拿到一组效果数据作为基线再换更精细的方法对比。不要一上来就在生产环境用这种方式。3.2 滑动窗口分块给分块加一段“重叠区”滑动窗口分块是固定长度分块的改良版。它的核心思想是相邻的块之间保留一段重叠区域overlap后一块会从前面块的尾部开始一部分内容。为什么需要重叠因为语义完整单元往往恰好跨越切分边界。比如一个方法论包含三步第1步写在上一块末尾第2、3步写在本块开头。如果完全没有重叠检索时这一块就只能看到半个方法。加了重叠之后跨越边界的语义单元至少会在某一两个块里完整出现大大降低信息丢失的概率。代价也明显同一个内容会被多次向量化存储成本和检索时返回的重复内容会增加。一般建议overlap设置在chunk_size的10%到20%之间具体怎么搭配我在第五章细讲。3.3 递归字符分块实用主义者的首选递归字符分块是目前工程中使用最广泛的方案很多框架内置的分割器就是这种思路。它比固定长度聪明又比语义分块便宜属于平衡性最优的选择之一。它的原理可以这样理解准备一组分隔符按优先级从高到低排列比如先是段落符“\n\n”然后是换行符“\n”再是句号、感叹号、问号等。切分时先从最高级别的分隔符下手如果切出来的块还是太大就继续用下一级分隔符对超长块进行递归切分直到所有块满足长度要求。这样做的好处是大部分情况下分块边界都落在自然的语义边界上同时又能保证每个块不超过硬性长度限制。对普通技术文章、新闻、报告这类有明确段落结构的文本效果非常稳。实现起来也不复杂后面代码实战部分我会给一个简化版示例。值得注意的是分隔符的优先级排序对结果影响很大要结合你的文本习惯调整顺序。3.4 结构感知分块遇到Markdown、代码、表格怎么办如果你处理的是Markdown文档、技术博客、网页HTML、源代码那么结构感知分块往往比通用方法表现更好。这类文本自带层级。Markdown里有标题层级、列表、代码块HTML里有标签嵌套源代码里有函数、类、模块。结构感知分块利用这些天然边界把内容按章节、函数、列表项等结构单元切分。举个例子一份README文档你希望每个功能模块的说明能独立成为一个Chunk。如果用递归字符分块很容易把一个模块的长段落和另一个模块混在一起。而结构感知分块会先识别出二级标题把每个标题下的内容当作潜在的分块单元再对超长单元做二次切分。这样做最大的好处是检索的单元与语义的单元高度一致。用户问“这个函数怎么调用”如果知识库里整个函数文档是一个块检索命中率和答案准确率都会显著提升。代价是实现复杂而且依赖文本格式的规范性。如果原始数据格式乱七八糟结构感知分块容易识别失败需要写不少容错逻辑。对代码类文本可以考虑直接按函数或类切对网页可以按DOM层级切对PDF这类无固定结构的内容就不太适合。3.5 语义分块让模型判断哪里该“断开”语义分块是近一年热度上升最快的方案。它的思路是先按句子把文本切碎用Embedding模型计算每个句子的向量表示然后计算相邻句子之间的相似度。相似度高的说明它们属于同一话题就归到一个块相似度突然变低说明话题发生了切换就在这里切一刀。用生活场景类比你在读一篇讲“程序员如何做饭”的文章前半段聊工具准备后半段聊火候控制。句子与句子之间如果话题连续相似度会比较高当聊到火候时跟前面聊工具的内容相似度明显下降模型就在这里断开。语义分块的优点是语义边界捕捉能力强特别适合内容逻辑不那么严谨、话题频繁切换的文本比如网页、聊天记录、知识问答集合。缺点是计算成本高每个句子都要过一遍Embedding模型再加上切分阈值的设定也需要针对数据调门槛比前几种方法高不少。另外提醒一句语义分块的结果有一定不确定性不同Embedding模型对相似度的判断不一样同一份文本在不同模型下可能得到不同的切分结果。建议把它理解为一种“以语义一致性为导向”的分块思路而不是一个黑盒神器。4. 手把手代码实战实现你自己的分块器理论说完了进入最核心的实操环节。我尽量用最少的依赖把每种分块方法的代码写出来并附上运行思路。4.1 准备环境与测试语料建议在Python 3.9环境里操作。起步只需要安装几个库pip install numpy openai # openai用于Embedding可替换为其他兼容库如果不想注册大模型接口也可以先用本地方案比如基于一些开源的Embedding模型代码逻辑是一样的。我这边的示例统一用OpenAI格式的接口方便你迁移。准备一段测试语料我随手写一份模拟项目说明test_text 项目背景 本系统旨在解决企业内部知识分散、检索效率低的问题。系统采用RAG架构 通过向量化检索增强大模型生成能力。整体分为数据接入、文本分块、向量化 存储、检索与生成四个模块。 需求分析 核心需求包括三个。第一支持多格式文档的解析与清洗。第二支持灵活的 分块策略配置满足不同业务场景的适配需求。第三提供可量化的检索质量 评估接口。 技术选型 分块模块考虑采用递归字符分块策略结合结构感知分层。Embedding部分 采用开源向量模型向量数据库选用轻量级方案便于后期扩展。 实施计划 第一阶段完成数据接入与分块原型。第二阶段完成向量化与检索联调。 第三阶段完成评估体系与上线部署。 这份语料包含标题、段落和完整的逻辑结构适合用来对比不同分块方法的效果。4.2 实现固定长度分块与滑动窗口固定长度分块的代码非常简单加上overlap支持后就变成了滑动窗口分块。我直接给出一个带overlap的实现把overlap设为0就是纯固定长度。def chunk_by_length(text, chunk_size100, overlap20): 按字符数分块overlap 控制相邻块重叠长度。 chunks [] start 0 text_len len(text) while start text_len: end min(start chunk_size, text_len) chunk text[start:end].strip() if chunk: chunks.append(chunk) if end text_len: break start max(start chunk_size - overlap, end - overlap) # 防止死循环当 overlap 大于 chunk_size 时要保证 start 前进 if start end: start end return chunks chunks chunk_by_length(test_text, chunk_size50, overlap10) for i, c in enumerate(chunks): print(f--- chunk {i} ---) print(c)这里有一个非常重要的细节防止死循环。如果你设置的overlap大于等于chunk_sizestart会倒退导致循环永远走不完。所以代码里加了start end的保护判断。这是很多人第一次写分块代码时踩的坑。实际运行后你会发现这种切法把“项目背景”和“本系统旨在”硬生生拆开了。这就是固定长度方法的直观问题。4.3 实现递归字符分块递归分块的代码稍微复杂但核心逻辑就三层第一层设置分隔符优先级列表。第二层从最高级分隔符开始切文本。第三层切出来的块如果还超过了chunk_size就换下一级分隔符递归处理。我写一个简化版保留主要思路def recursive_chunk(text, max_size100, separatorsNone): if separators is None: separators [\n\n, \n, 。, , , , , , ] final_chunks [] def split_and_slice(segment, current_idx): # 如果已经比 max_size 小直接作为结果 if len(segment) max_size or current_idx len(separators): if segment.strip(): final_chunks.append(segment.strip()) return sep separators[current_idx] parts segment.split(sep) # 临时组装小于等于 max_size 的块 temp for part in parts: if temp and len(temp) len(sep) len(part) max_size: if temp.strip(): final_chunks.append(temp.strip()) temp part else: if temp: temp sep temp part if temp.strip(): final_chunks.append(temp.strip()) split_and_slice(text, 0) return final_chunks上面的代码已经能工作但对超长块还没有真正“递归”下去。让我补一个更完整的版本def recursive_chunk_v2(text, max_size100, separatorsNone): if separators is None: separators [\n\n, \n, 。, , , , , , ] final_chunks [] def _split(segment, sep_index): if not segment.strip(): return # 如果段长小于 max_size直接返回 if len(segment) max_size: final_chunks.append(segment.strip()) return # 分隔符用完只能硬切 if sep_index len(separators): for i in range(0, len(segment), max_size): piece segment[i:i max_size] if piece.strip(): final_chunks.append(piece.strip()) return sep separators[sep_index] parts segment.split(sep) current for part in parts: candidate part if not current else current sep part if len(candidate) max_size: current candidate else: if current: _split(current, sep_index 1) current part if current: _split(current, sep_index 1) _split(text, 0) return final_chunks递归分块之所以推荐是因为它优先保留段落的完整性。只有当一个段落自身超过max_size时才继续启用下一级分隔符切分很好地平衡了长度限制和语义边界。4.4 实现语义分块语义分块需要调用Embedding接口。我这里以OpenAI库为例但核心思路可以平移到任何Embedding服务。它的完整实现分四步按句子切分、计算每句的向量、计算相邻相似度、按阈值切块。import numpy as np def split_sentences(text): import re # 简易中英文句子切分生产环境建议用专业依赖库 parts re.split(r(?[。!?;]), text) return [p.strip() for p in parts if p.strip()] def get_embeddings(sentences): # 以 OpenAI 接口为例 from openai import OpenAI client OpenAI() resp client.embeddings.create( modeltext-embedding-3-small, inputsentences ) vectors [item.embedding for item in resp.data] return np.array(vectors) def cosine_sim(vec1, vec2): return np.dot(vec1, vec2) / (np.linalg.norm(vec1) * np.linalg.norm(vec2) 1e-10) def semantic_chunk(text, threshold0.75): sentences split_sentences(text) if len(sentences) 1: return [text] embeddings get_embeddings(sentences) chunks [] current_chunk sentences[0] for i in range(1, len(sentences)): sim cosine_sim(embeddings[i - 1], embeddings[i]) if sim threshold: # 相似度低话题切换切一刀 chunks.append(current_chunk) current_chunk sentences[i] else: current_chunk sentences[i] if current_chunk: chunks.append(current_chunk) return chunks语义分块代码不难难点在threshold阈值的设定。阈值越高切分越“敏感”块数越多阈值越低块越趋向于合并。我建议第一次先用0.7到0.8区间跑一遍再根据份数是否符合预期反向调整。一个实践中的优化点是如果句子比较短可以先做句子合并把连续短句合并成一个稍长的句子再做Embedding否则短句的向量波动大相似度噪声也大。4.5 把分块策略封装成一个小工具写到这里你会发现每种策略的接口参数不一样但核心是统一的输入文本输出chunk列表。我习惯把不同策略封装成一个统一的类方便后续切换。class TextChunker: def __init__(self, strategyrecursive, **kwargs): self.strategy strategy self.params kwargs def chunk(self, text): if self.strategy length: return chunk_by_length(text, **self.params) elif self.strategy recursive: return recursive_chunk_v2(text, **self.params) elif self.strategy semantic: return semantic_chunk(text, **self.params) else: raise ValueError(fUnknown strategy: {self.strategy})这样一个封装之后你在项目里想对比不同分块策略只需要改一行配置。这也是我推荐给所有新人的做法——任何算法都先做成可插拔的模块千万别写死在业务代码里。5. 参数调优chunk size 与 overlap 怎么搭配代码能跑只是开始真正的调优功夫在下参数上。这一章是这篇分享里含金量最高的部分之一。5.1 经验值参考表分块没有绝对的“最优参数”只有“最适合当前场景的参数”。下面这张表是我在多个项目里实践下来的经验范围可以作为你的起点值。文档类型chunk_size字符overlap字符推荐理由新闻/资讯200-30020-30段落短粒度太大会有噪声技术文章400-80040-80段落完整性强适合适中粒度学术论文500-100050-100逻辑严密块内需要包含上下文合同/法律文书300-60030-60条款独立性强需按条款语义切分代码文档按函数/类切0-10结构边界比长度更重要聊天记录100-20010-20话题频繁切换小步快跑要注意的是这里的单位是“字符数”不是Token数。如果硬要按Token算中文大体上一个字接近1到1.5个Token英文一个单词约1到2个Token。实际工程中我习惯直接看Token但初学阶段用字符更直观。5.2 不同文档类型下的最优配置思路如果你是做通用知识库优先选递归字符分块chunk_size从400到600起步overlap设为chunk_size的10%到20%先把流程跑通再根据实际评测结果调整。如果你是做代码知识库结构感知分块明显更合适。以函数和类为基本单元一个函数就作为一个Chunk。函数太长时再按逻辑块切并且把函数名和注释作为每块的起始信息能大幅提高检索时的定位精度。如果你是做多轮对话记录这类文本逻辑跳跃建议用语义分块。很多做客服日志分析的项目用固定长度分块切完后跨话题的信息混在各块里检索效果惨不忍睹。换成语义分块后明显改善。5.3 如何判断分块质量好不好很多新人问我怎么知道当前参数好不好答案不要靠感觉要靠评测。我的做法是三步走。先做召回测试。准备10到20个真问题每个问题对应知识库中的标准答案片段。对每个问题跑一遍检索看排在前几名的块里是否包含标准答案片段。统计命中率这是最核心的指标。再做引用测试。看大模型生成答案时引用了哪些块引用块是否与问题相关、是否包含足够信息。如果模型引用了正确的块但答非所问说明块没问题问题出在Prompt或生成策略上。最后做人工抽检。把分块结果随机打印出来人眼看一遍判断每个块是否语义完整、边界是否自然。人工抽检虽然朴素却是最快发现参数问题的办法。比如一条本来完整的操作流程被切断肉眼一眼就能看出来根本不用跑完整评测。参数调优的完整循环是设一组参数跑评测看短板调参数再跑评测。一次调一个参数别同时改两个否则出了问题都不知道是哪个参数导致的。这块我吃过几次亏强烈建议你养成“单变量”的好习惯。6. 常见问题与排查技巧实录这一章把我自己和身边朋友在实践中遇到的典型问题整理成速查表方便你直接对号入座。问题现象可能原因排查方法解决方案检索回来自一大段无关内容chunk_size过大块内混入太多噪声检查单块长度和内容主题调小chunk_size或改用递归分块答案缺少关键细节关键信息正好被切到相邻块中查看被切开位置附近内容增大overlap或改用结构感知分块多条相似内容重复返回overlap过大冗余内容多查看返回块的重叠率降低overlap到10%以内不同话题的内容混在一个块固定长度分块切断句子打印分块结果人工检查使用递归分块或语义分块代码文档检索效果差函数被切散查看代码块的边界按函数/类为单位切分Embedding也解决了问题分块本身语义不一致检查文本清洗与预处理先做清洗后再分块6.1 切换Embedding模型后原来的参数全要重调这个问题容易被忽略。你有天看到一个新的Embedding模型说效果更好于是替换上线结果发现检索反而变差了。原因很常见新模型的向量分布和旧模型不同它对文本语义的压缩方式不一样原来分好的块在新模型下语义一致性也变了。换了Embedding模型分块参数必须重新评测一遍。这是一个许多人不知道的隐藏依赖。6.2 中文分块的专用细节中文分块和英文有几个不同点需要注意。中文没有空格词边界句子切分依赖标点常见分隔符优先级要针对中文文本调整句号、感叹号等优先级可能需要更高中文里“的、了、在”这类的高频词在向量计算时可能引入噪声可以在Embedding前做轻量清洗但不要过度停用词否则会损失语义。还有一个细节中文的长段落很常见一个段落可能达到上千字。如果直接用段落作为Chunk容易超出上下文限制。建议先将超长段落按句子切分再按语义或长度合并成子块。6.3 分块结果出现的“边界污染”所谓边界污染指某个块的尾部内容和下一个块的开头内容属于同一个完整语义单元但被分隔符或长度限制强行拆开。对策除了加大overlap外还有一个技巧对可能被污染的边界做后处理。比如有人会把每个Chunk的最后一句与下一块的第一句做相似度计算相似度过高则自动合并或调整边界。这种方法成本低实际效果很好。我曾经在一个文档问答项目里通过“边界句子相似度合并”这个小优化召回命中率提升了约7个百分点。别小看这种细节优化积累起来就是明显的体验差距。6.4 小白最容易忽略的数据清洗最后一定要提醒分块前先做数据清洗。乱码字符、多余换行、表格符号、URL、无意义的重复文本都会干扰分块边界的判断和Embedding的质量。我自己处理PDF转出来的文本时常会遇到一堆莫名其妙的空格和换行直接拿去分块效果快到你自己都不敢相信。清洗步骤不复杂通常是去乱码、压缩多余空白、规范化标点、去除页眉页脚。这步做好了分块效果才有保障很多人抱怨分块差实际是没做数据清洗。7. 写在最后我的一点实在体会写这篇分享是因为我见过太多新手在文本分块这个问题上绕远路。有人一上来就研究语义分块发现API调用费高得吓人转头又换回固定长度结果效果更差折腾半天毫无进展。我个人在实际操作中的体会是分块这件事没有银弹但它足够重要值得你花一整天去认真打磨。最稳的路线是先做好数据清洗用递归分块跑通流程再针对业务数据做参数评测和优化最后逐步尝试更精细的策略。不要一上来就追求花哨的方法先让链路跑通再让效果变好。最后再分享一个小技巧每次调整分块策略时把“分块结果示例评测指标”截图存档。这个习惯帮我积累了不同数据集的调优经验再遇到类似项目时直接翻存档就能找到合适的起跑参数效率提升非常明显。文本分块入门不难精通靠积累。希望这篇分享能成为你大模型应用之路上一块踏实的垫脚石。 文本分块实战：小白程序员的大模型RAG入门指南
写分块的时候我脑子里冒出来的第一个画面就是刚工作那会儿带我的前辈拿着一篇质量堪忧的RAG项目代码问我“你看这个检索结果为什么老是把毫不相关的段落拽出来”我盯着屏幕看了半天最后发现问题出在最不起眼的文本分块上——几千字的文档直接被硬生生切成每段200字句子被劈成了两半语义全乱了。那一刻我才意识到大模型应用里真正决定效果上限的往往不是模型选得多强而是数据进模型之前你有没有把它收拾利索。今天这篇分享专门写给刚开始接触大模型的小白程序员。我会把手把手拆解一个最常见也最容易被忽略的环节——文本分块。它是什么、为什么重要、有哪些主流做法、代码怎么写、参数怎么调以及哪些坑我替你踩过了争取一篇讲透让你看完整个人都通透了。1. 项目概述小白入门大模型为什么第一课是文本分块1.1 文本分块到底处在什么环节先花一分钟搞清位置。现在主流的大模型应用尤其是文档问答、知识库助理、企业私有数据检索这类场景背后大多跑的是RAG检索增强生成。它的流程可以用四步概括加载文档、文本分块、向量化存储、检索生成。第二步就是文本分块也叫Chunking。它做的是把长文档拆成一截一截可以单独喂给模型、单独做相似度检索的片段。这些片段通常被称为“Chunk”。很多教程讲RAG的时候把大量篇幅给了Embedding模型和向量数据库讲分块两三句就带过了。但实战过的人都知道分块策略选得好不好直接决定检索能不能召回正确信息进而决定大模型最终回答得靠不靠谱。分块是整条链路上最不起眼、但性价比最高的优化点。1.2 分块质量差会引发什么连锁反应如果你把分块做得很随意后面会遇到一串连锁问题。第一检索召回错误。查询词被分到某个语义不完整的块里向量相似度计算时匹配到一堆无关内容。第二上下文被切断。一个完整的事件、逻辑叙述被拦腰截断大模型只拿到半截信息回答自然残缺。第三幻觉变严重。模型在上下文不足时会“脑补”结果就是一本正经地胡说八道。第四效率与成本双输。块切得太碎向量数量的存储和检索开销成倍上涨块切得太大超出模型上下文窗口或检索精度下降。这些问题很少单独出现通常是一起爆发的。你在调Prompt、换Embedding模型上折腾半天不如先回头看看分块的代码是怎么写的。1.3 这篇分享能帮你解决什么这个标题叫“收藏小白程序员轻松入门大模型”我理解“轻松”的意思不是不学原理而是少走弯路。读完这篇文章你会获得几件实实在在的东西搞懂分块背后的四个底层概念知道自己在调参时到底在调什么。掌握五种主流分块策略的适用场景和优缺点不再凭感觉选方案。拿到可以直接运行和改写的Python代码把分块器封装成自己的工具。学会chunk size和overlap的搭配艺术不再盲猜参数。收获一份常见问题速查表遇到坑的时候能快速定位。接下来我按实战的顺序一章一章写。2. 动手前必须理解的四个底层概念不先搞懂底层原理后面调起参来就跟瞎猜一样。这一节我把四个关键概念讲明白每个都用大白话加类比的方式。2.1 Token与上下文窗口为什么不能粗暴地“整篇灌入”小白最容易有的一个疑问是既然大模型这么强为什么不把整篇文档直接塞进去让它回答答案很简单——大模型对输入长度有限制这个限制叫上下文窗口。上下文窗口的单位是Token。Token可以粗略理解为模型处理文本的最小单元一段中文可能一个词拆成一两个Token一个英文单词可能拆成几个Token。不同模型的窗口大小不同有的支持几万Token有的才几千。你可以把模型想象成一个只能记住有限字数的“阅读者”。你把一部几十万字的“文档”整篇扔给它它根本读不过来只能截取前面一部分后面的内容全被忽略。文本分块本质上是在这条长度约束下把信息组织成“一碟一碟刚好能端上桌的小菜”。这里面有个非常关键的工程经验上下文窗口不是用来塞原始文档的而是用来放“检索到的相关内容用户问题Prompt指令”的。RAG的真正价值就是只用几分之一的窗口大小把最相关的信息精准地送到模型面前。2.2 Embedding与相似度检索分块质量为什么能影响召回大模型要回答你的问题得先从一个庞大的知识库里捞出来相关内容这个捞的过程靠的不是传统的关键词匹配而是Embedding。Embedding做的事情是把一段文本转换成一串高维向量一堆数字。语义相近的文本在向量空间里的距离也相近。当用户提问时系统把问题也转成向量然后在向量数据库里找出和它最接近的若干条记录。这时候分块的角色就凸显出来了。假设知识库里有这样一句话“隔壁老王养了一只三岁的橘猫它最喜欢吃小鱼干。”如果你把这句话和另一句完全无关的“橘猫是中华田园猫的一种毛色”切成前后相邻的两块当用户问“橘猫喜欢吃什么”时前一块很容易被选中因为它包含答案但如果你的分块算法把第一句的尾部切掉只剩“隔壁老王养了一只三岁的橘猫”向量里就丢失了“吃小鱼干”这个关键信息召回就会失败。分块粒度越合理每块内部的语义一致性越高Embedding越能准确表达“这块在讲什么”检索质量自然越高。2.3 信息密度与语义完整性分块的黄金平衡点分块的艺术是在两个互相矛盾的目标之间找平衡。目标A语义完整。每块内容是完整、自洽、有明确主题的模型拿到这一块就能理解上下文。 目标B内容精炼。每块只包含最核心的信息不要掺入太多不相关的内容否则检索时会引入噪声。这两个目标天然冲突。块越大语义越完整但噪声越多块越小内容越精炼但语义越容易被切断。高手和菜鸟的分水岭就在这个平衡点的把握上。我习惯用一个生活类比分块好比切西瓜。你要让每个人拿到一块能直接吃的瓜瓤既不能切太大块让人无从下口也不能切成碎末让人用勺子都舀不起来。理想的Chunk就是“一勺子刚好能送进嘴里”的大小。2.4 分块与检索里的“照妖镜”还有一个容易被忽视的点分块策略不是通用最优解而是跟你的业务数据类型强相关的。给你一份合同、一份技术文档、一段聊天记录和一个网页源码各自的最优分块方式完全不同。所以不要在网上复制一段分块代码改两个参数就跑项目。你需要理解每种方法的适用边界再针对自己的数据做测试。这一章的概念都打好基础后我们进入正题看看主流的几种分块策略。3. 主流分块策略逐一拆解这一章我把五种出现频率最高的分块方法讲清楚。每种方法我都会给出实现思路、适用场景和优缺点方便你对照自己的项目选型。分块策略实现思路适用场景优点缺点固定长度分块按字符或Token数硬切简单原型快速验证实现容易、速度极快容易切断语义滑动窗口分块相邻块保留重叠区间通用文档、长文本缓解信息断层存储冗余、成本略高递归字符分块按多级分隔符逐层切分绝大多数文本平衡语义与长度需要调分隔符优先级结构感知分块按Markdown、HTML、代码结构切技术文档、网页、代码库语义边界清晰依赖格式完整性语义分块用Embedding判断句子边界内容逻辑松散、话题多变语义一致性最强计算成本高、依赖模型质量3.1 固定长度分块最直白也最容易翻车固定长度分块是最朴素的方式设定一个chunk_size然后从头到尾按字数或Token数平均切分。实现起来不超过十行代码。它最大的优势是快、可预测、方便控制成本。你要精确知道每块多大这个方法是唯一能做到的。但它的问题同样明显完全不考虑语义。句子可能会被从中间切断一个完整的事件会被劈开段落之间可能出现莫名其妙的边界。举个例子如果chunk_size设成200字一段210字的核心介绍就会被硬生生切掉最后10个字而这10个字可能刚好是结论。我的建议是固定长度分块只适合做基线测试。项目起步时用它快速跑通流程拿到一组效果数据作为基线再换更精细的方法对比。不要一上来就在生产环境用这种方式。3.2 滑动窗口分块给分块加一段“重叠区”滑动窗口分块是固定长度分块的改良版。它的核心思想是相邻的块之间保留一段重叠区域overlap后一块会从前面块的尾部开始一部分内容。为什么需要重叠因为语义完整单元往往恰好跨越切分边界。比如一个方法论包含三步第1步写在上一块末尾第2、3步写在本块开头。如果完全没有重叠检索时这一块就只能看到半个方法。加了重叠之后跨越边界的语义单元至少会在某一两个块里完整出现大大降低信息丢失的概率。代价也明显同一个内容会被多次向量化存储成本和检索时返回的重复内容会增加。一般建议overlap设置在chunk_size的10%到20%之间具体怎么搭配我在第五章细讲。3.3 递归字符分块实用主义者的首选递归字符分块是目前工程中使用最广泛的方案很多框架内置的分割器就是这种思路。它比固定长度聪明又比语义分块便宜属于平衡性最优的选择之一。它的原理可以这样理解准备一组分隔符按优先级从高到低排列比如先是段落符“\n\n”然后是换行符“\n”再是句号、感叹号、问号等。切分时先从最高级别的分隔符下手如果切出来的块还是太大就继续用下一级分隔符对超长块进行递归切分直到所有块满足长度要求。这样做的好处是大部分情况下分块边界都落在自然的语义边界上同时又能保证每个块不超过硬性长度限制。对普通技术文章、新闻、报告这类有明确段落结构的文本效果非常稳。实现起来也不复杂后面代码实战部分我会给一个简化版示例。值得注意的是分隔符的优先级排序对结果影响很大要结合你的文本习惯调整顺序。3.4 结构感知分块遇到Markdown、代码、表格怎么办如果你处理的是Markdown文档、技术博客、网页HTML、源代码那么结构感知分块往往比通用方法表现更好。这类文本自带层级。Markdown里有标题层级、列表、代码块HTML里有标签嵌套源代码里有函数、类、模块。结构感知分块利用这些天然边界把内容按章节、函数、列表项等结构单元切分。举个例子一份README文档你希望每个功能模块的说明能独立成为一个Chunk。如果用递归字符分块很容易把一个模块的长段落和另一个模块混在一起。而结构感知分块会先识别出二级标题把每个标题下的内容当作潜在的分块单元再对超长单元做二次切分。这样做最大的好处是检索的单元与语义的单元高度一致。用户问“这个函数怎么调用”如果知识库里整个函数文档是一个块检索命中率和答案准确率都会显著提升。代价是实现复杂而且依赖文本格式的规范性。如果原始数据格式乱七八糟结构感知分块容易识别失败需要写不少容错逻辑。对代码类文本可以考虑直接按函数或类切对网页可以按DOM层级切对PDF这类无固定结构的内容就不太适合。3.5 语义分块让模型判断哪里该“断开”语义分块是近一年热度上升最快的方案。它的思路是先按句子把文本切碎用Embedding模型计算每个句子的向量表示然后计算相邻句子之间的相似度。相似度高的说明它们属于同一话题就归到一个块相似度突然变低说明话题发生了切换就在这里切一刀。用生活场景类比你在读一篇讲“程序员如何做饭”的文章前半段聊工具准备后半段聊火候控制。句子与句子之间如果话题连续相似度会比较高当聊到火候时跟前面聊工具的内容相似度明显下降模型就在这里断开。语义分块的优点是语义边界捕捉能力强特别适合内容逻辑不那么严谨、话题频繁切换的文本比如网页、聊天记录、知识问答集合。缺点是计算成本高每个句子都要过一遍Embedding模型再加上切分阈值的设定也需要针对数据调门槛比前几种方法高不少。另外提醒一句语义分块的结果有一定不确定性不同Embedding模型对相似度的判断不一样同一份文本在不同模型下可能得到不同的切分结果。建议把它理解为一种“以语义一致性为导向”的分块思路而不是一个黑盒神器。4. 手把手代码实战实现你自己的分块器理论说完了进入最核心的实操环节。我尽量用最少的依赖把每种分块方法的代码写出来并附上运行思路。4.1 准备环境与测试语料建议在Python 3.9环境里操作。起步只需要安装几个库pip install numpy openai # openai用于Embedding可替换为其他兼容库如果不想注册大模型接口也可以先用本地方案比如基于一些开源的Embedding模型代码逻辑是一样的。我这边的示例统一用OpenAI格式的接口方便你迁移。准备一段测试语料我随手写一份模拟项目说明test_text 项目背景 本系统旨在解决企业内部知识分散、检索效率低的问题。系统采用RAG架构 通过向量化检索增强大模型生成能力。整体分为数据接入、文本分块、向量化 存储、检索与生成四个模块。 需求分析 核心需求包括三个。第一支持多格式文档的解析与清洗。第二支持灵活的 分块策略配置满足不同业务场景的适配需求。第三提供可量化的检索质量 评估接口。 技术选型 分块模块考虑采用递归字符分块策略结合结构感知分层。Embedding部分 采用开源向量模型向量数据库选用轻量级方案便于后期扩展。 实施计划 第一阶段完成数据接入与分块原型。第二阶段完成向量化与检索联调。 第三阶段完成评估体系与上线部署。 这份语料包含标题、段落和完整的逻辑结构适合用来对比不同分块方法的效果。4.2 实现固定长度分块与滑动窗口固定长度分块的代码非常简单加上overlap支持后就变成了滑动窗口分块。我直接给出一个带overlap的实现把overlap设为0就是纯固定长度。def chunk_by_length(text, chunk_size100, overlap20): 按字符数分块overlap 控制相邻块重叠长度。 chunks [] start 0 text_len len(text) while start text_len: end min(start chunk_size, text_len) chunk text[start:end].strip() if chunk: chunks.append(chunk) if end text_len: break start max(start chunk_size - overlap, end - overlap) # 防止死循环当 overlap 大于 chunk_size 时要保证 start 前进 if start end: start end return chunks chunks chunk_by_length(test_text, chunk_size50, overlap10) for i, c in enumerate(chunks): print(f--- chunk {i} ---) print(c)这里有一个非常重要的细节防止死循环。如果你设置的overlap大于等于chunk_sizestart会倒退导致循环永远走不完。所以代码里加了start end的保护判断。这是很多人第一次写分块代码时踩的坑。实际运行后你会发现这种切法把“项目背景”和“本系统旨在”硬生生拆开了。这就是固定长度方法的直观问题。4.3 实现递归字符分块递归分块的代码稍微复杂但核心逻辑就三层第一层设置分隔符优先级列表。第二层从最高级分隔符开始切文本。第三层切出来的块如果还超过了chunk_size就换下一级分隔符递归处理。我写一个简化版保留主要思路def recursive_chunk(text, max_size100, separatorsNone): if separators is None: separators [\n\n, \n, 。, , , , , , ] final_chunks [] def split_and_slice(segment, current_idx): # 如果已经比 max_size 小直接作为结果 if len(segment) max_size or current_idx len(separators): if segment.strip(): final_chunks.append(segment.strip()) return sep separators[current_idx] parts segment.split(sep) # 临时组装小于等于 max_size 的块 temp for part in parts: if temp and len(temp) len(sep) len(part) max_size: if temp.strip(): final_chunks.append(temp.strip()) temp part else: if temp: temp sep temp part if temp.strip(): final_chunks.append(temp.strip()) split_and_slice(text, 0) return final_chunks上面的代码已经能工作但对超长块还没有真正“递归”下去。让我补一个更完整的版本def recursive_chunk_v2(text, max_size100, separatorsNone): if separators is None: separators [\n\n, \n, 。, , , , , , ] final_chunks [] def _split(segment, sep_index): if not segment.strip(): return # 如果段长小于 max_size直接返回 if len(segment) max_size: final_chunks.append(segment.strip()) return # 分隔符用完只能硬切 if sep_index len(separators): for i in range(0, len(segment), max_size): piece segment[i:i max_size] if piece.strip(): final_chunks.append(piece.strip()) return sep separators[sep_index] parts segment.split(sep) current for part in parts: candidate part if not current else current sep part if len(candidate) max_size: current candidate else: if current: _split(current, sep_index 1) current part if current: _split(current, sep_index 1) _split(text, 0) return final_chunks递归分块之所以推荐是因为它优先保留段落的完整性。只有当一个段落自身超过max_size时才继续启用下一级分隔符切分很好地平衡了长度限制和语义边界。4.4 实现语义分块语义分块需要调用Embedding接口。我这里以OpenAI库为例但核心思路可以平移到任何Embedding服务。它的完整实现分四步按句子切分、计算每句的向量、计算相邻相似度、按阈值切块。import numpy as np def split_sentences(text): import re # 简易中英文句子切分生产环境建议用专业依赖库 parts re.split(r(?[。!?;]), text) return [p.strip() for p in parts if p.strip()] def get_embeddings(sentences): # 以 OpenAI 接口为例 from openai import OpenAI client OpenAI() resp client.embeddings.create( modeltext-embedding-3-small, inputsentences ) vectors [item.embedding for item in resp.data] return np.array(vectors) def cosine_sim(vec1, vec2): return np.dot(vec1, vec2) / (np.linalg.norm(vec1) * np.linalg.norm(vec2) 1e-10) def semantic_chunk(text, threshold0.75): sentences split_sentences(text) if len(sentences) 1: return [text] embeddings get_embeddings(sentences) chunks [] current_chunk sentences[0] for i in range(1, len(sentences)): sim cosine_sim(embeddings[i - 1], embeddings[i]) if sim threshold: # 相似度低话题切换切一刀 chunks.append(current_chunk) current_chunk sentences[i] else: current_chunk sentences[i] if current_chunk: chunks.append(current_chunk) return chunks语义分块代码不难难点在threshold阈值的设定。阈值越高切分越“敏感”块数越多阈值越低块越趋向于合并。我建议第一次先用0.7到0.8区间跑一遍再根据份数是否符合预期反向调整。一个实践中的优化点是如果句子比较短可以先做句子合并把连续短句合并成一个稍长的句子再做Embedding否则短句的向量波动大相似度噪声也大。4.5 把分块策略封装成一个小工具写到这里你会发现每种策略的接口参数不一样但核心是统一的输入文本输出chunk列表。我习惯把不同策略封装成一个统一的类方便后续切换。class TextChunker: def __init__(self, strategyrecursive, **kwargs): self.strategy strategy self.params kwargs def chunk(self, text): if self.strategy length: return chunk_by_length(text, **self.params) elif self.strategy recursive: return recursive_chunk_v2(text, **self.params) elif self.strategy semantic: return semantic_chunk(text, **self.params) else: raise ValueError(fUnknown strategy: {self.strategy})这样一个封装之后你在项目里想对比不同分块策略只需要改一行配置。这也是我推荐给所有新人的做法——任何算法都先做成可插拔的模块千万别写死在业务代码里。5. 参数调优chunk size 与 overlap 怎么搭配代码能跑只是开始真正的调优功夫在下参数上。这一章是这篇分享里含金量最高的部分之一。5.1 经验值参考表分块没有绝对的“最优参数”只有“最适合当前场景的参数”。下面这张表是我在多个项目里实践下来的经验范围可以作为你的起点值。文档类型chunk_size字符overlap字符推荐理由新闻/资讯200-30020-30段落短粒度太大会有噪声技术文章400-80040-80段落完整性强适合适中粒度学术论文500-100050-100逻辑严密块内需要包含上下文合同/法律文书300-60030-60条款独立性强需按条款语义切分代码文档按函数/类切0-10结构边界比长度更重要聊天记录100-20010-20话题频繁切换小步快跑要注意的是这里的单位是“字符数”不是Token数。如果硬要按Token算中文大体上一个字接近1到1.5个Token英文一个单词约1到2个Token。实际工程中我习惯直接看Token但初学阶段用字符更直观。5.2 不同文档类型下的最优配置思路如果你是做通用知识库优先选递归字符分块chunk_size从400到600起步overlap设为chunk_size的10%到20%先把流程跑通再根据实际评测结果调整。如果你是做代码知识库结构感知分块明显更合适。以函数和类为基本单元一个函数就作为一个Chunk。函数太长时再按逻辑块切并且把函数名和注释作为每块的起始信息能大幅提高检索时的定位精度。如果你是做多轮对话记录这类文本逻辑跳跃建议用语义分块。很多做客服日志分析的项目用固定长度分块切完后跨话题的信息混在各块里检索效果惨不忍睹。换成语义分块后明显改善。5.3 如何判断分块质量好不好很多新人问我怎么知道当前参数好不好答案不要靠感觉要靠评测。我的做法是三步走。先做召回测试。准备10到20个真问题每个问题对应知识库中的标准答案片段。对每个问题跑一遍检索看排在前几名的块里是否包含标准答案片段。统计命中率这是最核心的指标。再做引用测试。看大模型生成答案时引用了哪些块引用块是否与问题相关、是否包含足够信息。如果模型引用了正确的块但答非所问说明块没问题问题出在Prompt或生成策略上。最后做人工抽检。把分块结果随机打印出来人眼看一遍判断每个块是否语义完整、边界是否自然。人工抽检虽然朴素却是最快发现参数问题的办法。比如一条本来完整的操作流程被切断肉眼一眼就能看出来根本不用跑完整评测。参数调优的完整循环是设一组参数跑评测看短板调参数再跑评测。一次调一个参数别同时改两个否则出了问题都不知道是哪个参数导致的。这块我吃过几次亏强烈建议你养成“单变量”的好习惯。6. 常见问题与排查技巧实录这一章把我自己和身边朋友在实践中遇到的典型问题整理成速查表方便你直接对号入座。问题现象可能原因排查方法解决方案检索回来自一大段无关内容chunk_size过大块内混入太多噪声检查单块长度和内容主题调小chunk_size或改用递归分块答案缺少关键细节关键信息正好被切到相邻块中查看被切开位置附近内容增大overlap或改用结构感知分块多条相似内容重复返回overlap过大冗余内容多查看返回块的重叠率降低overlap到10%以内不同话题的内容混在一个块固定长度分块切断句子打印分块结果人工检查使用递归分块或语义分块代码文档检索效果差函数被切散查看代码块的边界按函数/类为单位切分Embedding也解决了问题分块本身语义不一致检查文本清洗与预处理先做清洗后再分块6.1 切换Embedding模型后原来的参数全要重调这个问题容易被忽略。你有天看到一个新的Embedding模型说效果更好于是替换上线结果发现检索反而变差了。原因很常见新模型的向量分布和旧模型不同它对文本语义的压缩方式不一样原来分好的块在新模型下语义一致性也变了。换了Embedding模型分块参数必须重新评测一遍。这是一个许多人不知道的隐藏依赖。6.2 中文分块的专用细节中文分块和英文有几个不同点需要注意。中文没有空格词边界句子切分依赖标点常见分隔符优先级要针对中文文本调整句号、感叹号等优先级可能需要更高中文里“的、了、在”这类的高频词在向量计算时可能引入噪声可以在Embedding前做轻量清洗但不要过度停用词否则会损失语义。还有一个细节中文的长段落很常见一个段落可能达到上千字。如果直接用段落作为Chunk容易超出上下文限制。建议先将超长段落按句子切分再按语义或长度合并成子块。6.3 分块结果出现的“边界污染”所谓边界污染指某个块的尾部内容和下一个块的开头内容属于同一个完整语义单元但被分隔符或长度限制强行拆开。对策除了加大overlap外还有一个技巧对可能被污染的边界做后处理。比如有人会把每个Chunk的最后一句与下一块的第一句做相似度计算相似度过高则自动合并或调整边界。这种方法成本低实际效果很好。我曾经在一个文档问答项目里通过“边界句子相似度合并”这个小优化召回命中率提升了约7个百分点。别小看这种细节优化积累起来就是明显的体验差距。6.4 小白最容易忽略的数据清洗最后一定要提醒分块前先做数据清洗。乱码字符、多余换行、表格符号、URL、无意义的重复文本都会干扰分块边界的判断和Embedding的质量。我自己处理PDF转出来的文本时常会遇到一堆莫名其妙的空格和换行直接拿去分块效果快到你自己都不敢相信。清洗步骤不复杂通常是去乱码、压缩多余空白、规范化标点、去除页眉页脚。这步做好了分块效果才有保障很多人抱怨分块差实际是没做数据清洗。7. 写在最后我的一点实在体会写这篇分享是因为我见过太多新手在文本分块这个问题上绕远路。有人一上来就研究语义分块发现API调用费高得吓人转头又换回固定长度结果效果更差折腾半天毫无进展。我个人在实际操作中的体会是分块这件事没有银弹但它足够重要值得你花一整天去认真打磨。最稳的路线是先做好数据清洗用递归分块跑通流程再针对业务数据做参数评测和优化最后逐步尝试更精细的策略。不要一上来就追求花哨的方法先让链路跑通再让效果变好。最后再分享一个小技巧每次调整分块策略时把“分块结果示例评测指标”截图存档。这个习惯帮我积累了不同数据集的调优经验再遇到类似项目时直接翻存档就能找到合适的起跑参数效率提升非常明显。文本分块入门不难精通靠积累。希望这篇分享能成为你大模型应用之路上一块踏实的垫脚石。