版权与内容来源声明
本文为原创整理。文中涉及官方文档、开源仓库、论文与公开报道的内容，均在附表 A 中标注来源；引用官方原文保持原样，不作改写。文中命令、版本号与界面截图以本文成文时的实测/核验结果为准，标注「待验证」的部分请以你本地环境实际输出为判断依据。本文不推荐任何不合规的软件获取方式，也不对任何收益结果作承诺。转载请注明出处。
一、同一个 60 字上限，两种切法给出两种结果
一份 257 个字符的《订单服务说明》，带两级标题、一段代码、几处空行。把每块上限设成 60 字、重叠设成 0，只把分隔符列表换个顺序，块 1 从 49 字变成 38 字，块 2 从 44 字变成 55 字。
差别不是「多几字少几字」，而是「## 一、创建订单」这个小标题，跟不跟着它下面的正文走。
先统一两个词。切分器（text splitter）：把长文档切成小段的那段程序。块（chunk）：切出来的一段文本，后面通常会被算成一个向量、检索时整段塞进上下文。检索命中的单位是块，不是文档——这一点决定了后面所有结论为什么重要。
1.1 两个结果的差别落在一句话上
默认分隔符顺序下，块 1 的 49 字正好停在「## 一、创建订单」这个小标题结束的位置，紧接着那 44 字的正文（「调用方必须传 order_id 与 amount……」）被切进了块 2。
把标题类分隔符提到最前面以后，块 1 只剩 38 字（一级标题加引言段），块 2 是 55 字，开头就是「## 一、创建订单」，后面跟着它的正文。
对检索来说这是两种完全不同的结果。如果查询词更接近标题，命中的是块 1，模型拿到的是「有个叫创建订单的章节」，但拿不到「必须传 order_id 与 amount、单位是分、不接受浮点数」。标题被检索到了，内容没被带出来。
1.2 参数不是「调大调小」，是「先在哪切」
多数人调分块的方式是「效果不好就把 chunk_size 调小一点、overlap 调大一点」。但这份文档在 60 字上限下，五块长度是 49/44/45/51/57，每一块都没超过上限，参数是合规的。坏掉的是边界落在哪。
参数管的是「每块最多多长」，分隔符顺序管的是「刀先落在哪个单位上」——段落、标题、句子、词，还是字符。这两件事不在一个维度上，调前者解决不了后者。
1.3 本文只认三个能当场看的量
块数、每块长度、每块开头的字符。这三个不需要向量库、不需要模型，split_text跑一遍就能看见。
本文会跑四组配置：默认分隔符配 80 字上限（5 块，49/44/45/51/57）；只给中文句号（4 块，最短一块 19 字，最长一块 134 字）；把标题类分隔符提到最前、上限压到 60 字（5 块，38/55/45/51/57）；以及 40 字上限配 40 字重叠（13 块，最短 3 字）。数字后面逐组拆开，先记住一件事：这四组的差别几乎全在边界位置，而不在块长上限。
二、默认值是 4000/200，先把基线校准
2.1 本机读出来的四个默认值
不传任何参数直接构造，把内部属性打印出来，是校准基线的第一步。
fromlangchain_text_splittersimportRecursiveCharacterTextSplitter d=RecursiveCharacterTextSplitter()print("chunk_size =",d._chunk_size,"| chunk_overlap =",d._chunk_overlap)print("默认 separators =",d._separators)实测输出：chunk_size = 4000、chunk_overlap = 200，分隔符是['\n\n', '\n', ' ', '']。环境是 Python 3.13.14、langchain-core 1.6.6，切分器来自langchain_text_splitters这个包（本机也装了，只是没打出它的版本号）。
这里要纠正一个流传很广的说法：4000 才是默认值，不是 1000。旧教程里常见的chunk_size=1000, chunk_overlap=200是示例参数，写给人照着改的，被不少文章当成了默认值。截至 2026-10-19，本机这一版的默认值仍然是 4000/200。
还有一项容易被忽略：length_function默认就是len，也就是按字符数算长度，不是按 token 数。中英文的「字符换 token」比例不一样，所以同一个 4000，在中英文文档里占的上下文并不是一回事。
2.2 四级优先，最后一级是逐字兜底
四个分隔符不是「四个一起用」，而是有严格的先后顺序。
| 层级 | 分隔符 | 它想保住的结构 | 这一级缺失时会怎样 |
|---|---|---|---|
| 1 | \n\n | 段落 | 段落被拆成行，标题与正文可能分开 |
| 2 | \n | 行 | 列表、代码行被拆开 |
| 3 | 空格 | 英文的词 | 英文单词被切成两半 |
| 4 | 空串 | 无结构，逐字切 | 中文长句在任意字之间断开 |
第 4 级的空串不是「没有分隔符」，而是「每个字符之间都算一次分隔」，所以任何文本都能被切到上限以内。代价是它不认任何语义边界。
2.3 官方文档和源码各说了一半
官方文档页（docs.langchain.com的 RecursiveCharacterTextSplitter 指南）写清了三件事：默认分隔符列表是["\n\n", "\n", " ", ""]；切分方式是按字符列表递归尝试；块长由length_function决定。但这一页没有写 4000 和 200 这两个数字。
数字在源码里：langchain_text_splitters/base.py里chunk_size: int = 4000、chunk_overlap: int = 200、length_function: Callable[[str], int] = len；character.py里self._separators = separators or ["\n\n", "\n", " ", ""]。文档管语义、源码管数值，两边合起来才是完整基线。
同一页还有一节专门讲中文、日文、泰文这类没有词边界的语言，明确建议把「。」加进分隔符列表，示例里也确实加了。但它没说这个「。」该排在第几位——而这恰恰是本文实测下来影响最大的地方。
三、默认分隔符在代码和长句上都会「硬切」
3.1 80 字上限：5 块，代码断成 45 和 51
沿用默认的四个分隔符，只把chunk_size压到 80，同一份文档切成 5 块：
| 块 | 长度 | 开头（按实测日志） | 问题 |
|---|---|---|---|
| 1 | 49 | # 订单服务说明到## 一、创建订单 | 小标题落在块尾，正文在下一块 |
| 2 | 44 | 调用方必须传 order_id 与 amount | 与自己的标题分离 |
| 3 | 45 | 以开头围栏起头，接def create_order(...) | 只有开头围栏，没有结尾围栏 |
| 4 | 51 | return {...}加结尾围栏 | 只有结尾围栏，没有开头围栏 |
| 5 | 57 | ## 二、查询订单到文末 | 两个小标题各自带着正文 |
块 3 到def create_order(order_id, amount):这一行的冒号就结束了，函数体整段落到块 4。渲染出来是两段坏代码：前一段有开头围栏没结尾，后一段有结尾没开头。
更值得注意的是块 1 和块 5 的对比：同一套参数，块 5 里两个小标题都跟着正文，块 1 里的小标题却独自留在末尾。原因很朴素——块 1 装到 49 字时只剩 31 字余量，塞不下 44 字的正文；块 5 的两节加起来 57 字，还有余量。标题保不保得住，取决于这一块还剩多少空间，不取决于它是标题。
3.2 中文长句：80 加 31，第二块以「证幂等」开头
换一篇纯中文、没有空行也没有空格的文本：三句客服话术重复三遍，共 111 字。默认分隔符切出来是 80 加 31 两块，第二块开头是「证幂等。重复提交不能产生两笔订单……」
「保证幂等」被从「保」和「证」之间切开。对这种文本，前三级分隔符全都不命中：没有空行、没有换行、中文也没有空格。一路降到第 4 级空串，逐字切到 80 字为止。
3.3 为什么会这样
默认分隔符表是按英文散文设计的：段落、行、词、字符。英文的词之间有空格，第 3 级能兜住大部分情况。中文没有空格，第 3 级形同虚设；一旦文本里没有空行和换行，就只剩逐字兜底。代码则是另一种情形：它的换行和空格都是「合法分隔符」，切分器并不知道围栏里面是不能切的。
四、只给一个分隔符：主语留在上一块
4.1separators=["。"]的 4 块
很多人抄到的配置是「中文就按句号切」，于是只传一个「。」。同一份文档切成 4 块：75 / 19 / 134 / 29。
块 2 只有 19 个字，内容是「。amount 单位为分，不接受浮点数」。它的主语「调用方必须传 order_id 与 amount」留在了块 1 的末尾。读者和模型看到块 2 时，拿到的是半句：谁的 amount、为什么是分，都不在块里。
块 3 更直接：134 字，超过了 80 的上限。
RecursiveCharacterTextSplitter(chunk_size=80,chunk_overlap=0,separators=["。"],).split_text(DOC)后面几段代码都摘自同一个实测脚本，DOC就是这份订单服务说明，不再重复贴原文。
4.2 没有下一级兜底，上限会失效
递归切分的规则是：用一个分隔符切开后，如果某一段还是超限，才拿剩下的分隔符继续切。只给一个「。」，剩下的列表就是空的。
于是 134 字那段（从「。」开始，跨过整段代码，到「允许 3 秒内的延迟」）没有下一级可走，被整段保留。chunk_size是「尽量不超过」，不是硬保证：这段文本不经过合并那一步，直接把原文放进了结果，长度上限当场失效，流程也不会因此中断。
那个 19 字块也不是「切得细」，而是残余：前一块已经 75 字装不下它，它自己又短，只能单独成块。碎片块大多是这样产生的，不是设计出来的。
4.3 中文文档的分隔符顺序怎么排
按「先结构、再句子、最后兜底」排，不要只给一个。
| 顺序 | 放什么 | 理由 | 排错了会怎样 |
|---|---|---|---|
| 1 | \n##（连同\n#） | 让标题和它下面的正文成为一段 | 标题留在上一块末尾，正文进下一块 |
| 2 | \n\n | 段落边界 | 段落被拆散，跨节合并 |
| 3 | 。！？ | 语义完整的最小单位 | 句子被切在半句 |
| 4 | \n | 列表项、表格行、代码行 | 列表项被合并或拆开 |
| 5 | ，、 | 长句的次级断点 | 一个短句被硬切 |
| 6 | "" | 逐字兜底 | 超长片段被整段放行 |
两个细节。第一，这份表里干脆去掉了「空格」这一级：中文里空格极少，留着它，遇到混排英文的文档时就会先在英文词边界切一刀，把中文句子留在半截；如果文档里英文确实很多，可以把空格放到句末标点之后。第二，逗号一定要排在句号后面，否则句子会先被切在逗号处，等于把半句当成一块。
至于为什么不能只给一个分隔符：只给一个，丢的不只是结构层，还把兜底层一起丢了。除句号之外没有任何可退的层级，一段超长的表格或代码就会被整段放行，长度上限形同虚设——4.1 节那 134 字就是这么来的。
需要说明：这张表里第 1、2 级的先后，本文做了对照实测；第 3 到 6 级是按切分机制推出来的排序，没有逐项对比切分结果。把它们当成有依据的建议，不要当成实测结论。
五、把标题排在空行前面，标题就和正文分开了
5.1 顺序对调：49/44 变成 38/55
把上限压到 60 字，跑两组配置，只改分隔符顺序：
第一组["\n\n", "\n", ""]（空行优先），5 块，49 / 44 / 45 / 51 / 57——和 80 字那组完全一样，因为每块本来就没到 60。
第二组["\n## ", "\n\n", "\n", ""]（标题优先），5 块，38 / 55 / 45 / 51 / 57。
块 1 少掉的 11 个字，正是「空行 + ## 一、创建订单」这一段；它整体挪到了块 2 开头，于是 55 字的块 2 = 标题 + 正文。
RecursiveCharacterTextSplitter(chunk_size=60,chunk_overlap=0,separators=["\n## ","\n\n","\n",""],).split_text(DOC)5.2 机制：第一个命中的分隔符决定第一刀
切分器不是「把所有分隔符一起用」，而是按列表顺序找到第一个在文本里出现的分隔符，用它把全文切一遍；切开后哪一段还超限，才拿列表里剩下的分隔符继续切。
所以列表第 1 位决定的是「全局第一刀落在什么单位上」。
- 空行优先：全文先按段落切，标题自己是一段（它前面就是空行）。合并时按顺序往块里塞，塞到装不下就停。标题恰好被塞进块 1 的末尾，正文塞不进去。
- 标题优先：切出来的每一段都是「标题 + 它下面的正文」。合并时要么整段进，要么整段留到下一块，标题和正文不会分家。
一句话：顺序不是偏好问题，它决定合并的最小单位是什么。
5.3 判断切分结果对不对的三条判据
不用先建索引、不用先跑模型，把块打印出来逐条看就够。
| 判据 | 怎么看 | 命中说明什么 | 怎么改 |
|---|---|---|---|
| ① 标题是否与它下面第一段同块 | 搜##，看这个标题的下一行还在不在同一块里 | 标题孤零零在块尾，检索命中标题拿不到内容 | 把\n##提到\n\n前面 |
| ② 有没有以标点开头的块 | 看每块第一个字符是不是。，、！？ | 上一块结尾没有收束，标点被甩到这一块开头 | 把句末标点提前一级，别让标点单独当块首 |
| ③ 有没有小于 50 字的碎片块 | 统计每块长度（80 字上限时看 50 以下） | 多半是残余块或参数配错 | 先查是不是单分隔符造成的残余，再考虑 overlap |
第 ② 条值得多说一句。切分器的keep_separator默认是开着的，分隔符会被保留下来，但落点是下一块的开头。空白类分隔符留下的换行会被顺手去掉，标点不会——所以块首出现一个孤立的「。」，就是「这里被切过」的显式痕迹：上一块以一个没有句号的半句收尾，这一块以一个孤立的句号起头。这是个几乎零成本的检查点。
第 ③ 条的 50 字不是定理。它是按 80 字上限给的：大约是上限的六成。上限换成 4000，就按同比例折算，或者干脆看「最短块是不是只有最长块的零头」。
切分结果自查清单：把本章三条判据做成了一张可逐项勾选的表，附了几组对照配置的块长。放在资料包里，扫码即可获取：
六、overlap 只在被切断的位置生效
6.1 0 / 10 / 30 的实测对照
chunk_size固定 60，只改chunk_overlap：
| overlap | 块数 | 块 2 长度 | 现象 |
|---|---|---|---|
| 0 | 5 | 44 | 标题在块 1 末尾，正文单独成块 |
| 10 | 5 | 44 | 与 0 完全一样，一个字都没多 |
| 30 | 5 | 55 | 标题被带到块 2 开头，与正文同块 |
| 40（上限也是 40） | 13 | 9 | 块数暴涨，出现 3 字碎片 |
forovin(0,10,30):ch=RecursiveCharacterTextSplitter(chunk_size=60,chunk_overlap=ov).split_text(DOC)print(ov,len(ch),[len(c)forcinch])6.2 能带多少，取决于上一块尾部有多长
overlap常被理解成「每块都复制上一块的尾巴」。它不是。它只在一块装满、必须断开的那一刻起作用：从这块末尾往回留最多 overlap 个字，当作下一块的开头。而且它按整段回退，不会把某一段截掉一半——留多少，是一段一段算的。
留得下留不下，取决于断点前那一段有多长。这个例子里，断点前是「空行 + ## 一、创建订单」，正好 11 个字符：
- overlap=10：11 大于 10，一个字都留不下，结果和 0 一模一样。
- overlap=30：11 小于 30，整段标题被留下，块 2 变成 55 字，标题和正文在一起。
所以 overlap 不是「越大越连贯」。切点落在天然分隔符上、前一段又比 overlap 长的时候，它根本没有落点。想让标题跟着正文，改分隔符顺序是直接的；指望 overlap 顺手带过来，得先算准那段有多长。
6.3 overlap 等于 chunk_size：13 块和 3 字碎片
把chunk_size和chunk_overlap都设成 40，块数从 5 涨到 13。
块 10 只有 3 个字符，是一个孤零零的代码结尾围栏。块 3（31 字）和块 4（37 字）都含「order_id 与 amount」，只是切点不同；块 7（29 字）和块 8（39 字）都含return那一行。同一段代码被重复了两遍，还都不是完整的。
原因还是那条：一块本身就只有 40 字，却要求保留 40 字重叠。每装进下一段就必然超限，只能立刻再切一刀，于是刀刃相接、块数翻倍、内容重复。
chunk_overlap大于chunk_size时，构造切分器就会失败（参数校验不通过）；等于的时候不会报错，但结果没有可用性。这条边界不要试探。经验上把 overlap 控制在块长的四分之一到三分之一，剩下的连贯性交给分隔符顺序解决。
七、结构要自己保：先按结构拆，再逐段切
7.1 「保护代码块」的分隔符反而更碎
一个自然的想法是：把代码围栏写进分隔符列表，让切分器认出来。实测相反。
对一段只有两个函数的代码，用默认分隔符加 40 字上限，切 2 块：36 和 33，一块只有开头围栏、一块只有结尾围栏。换成「保护代码块」的配置——把「换行 + 三个反引号 + 换行」和「三个反引号」都写进分隔符列表——变成 3 块：36 / 29 / 3，最后一块只有 3 个字符的结尾围栏。
原因不复杂：这段代码的第一道围栏在开头、最后一道在结尾，中间没有「前后都有换行」的围栏，所以第一项根本不命中；真正命中的是「三个反引号」这一项。它在开头和结尾各出现一次，开头那一刀切出来的前半段是空串、被丢掉，于是「开头围栏 + 两个函数」连成一段（69 字，超过 40，只能退回按换行切），结尾围栏则单独成了 3 字的一块。
**把结构标记写进分隔符列表，等于告诉切分器「这里可以切」。**它会照切，而且默认会把分隔符保留到下一块开头——保留下来的是单侧的三个反引号，配不成对。
7.2 先按结构拆，再对每段做切分
代码块、表格、公式、JSON 这类结构，切分器本身保护不了。可行的做法是两步：先从文档层面把结构整段摘出来，再对剩下的正文做递归切分。
| 结构 | 切分器能自己保护吗 | 建议做法 |
|---|---|---|
| 代码块 | 不能 | 按围栏整段摘出，整段作为一个块；超长再按行切，并补回首尾围栏 |
| 表格 | 不能 | 按「表头 + 若干行」成组切，别让一行被切开 |
| Markdown 标题 | 部分可以 | 用标题类分隔符（顺序要对），或先用标题切分器分层 |
| 公式、JSON | 不能 | 整段保留，超长时按语法结构切 |
| 长度口径 | 默认按字符 | 要按 token 控长，就换length_function，别指望改 chunk_size 等价于改 token |
⚠️代码待验证
importre FENCE=re.compile(r"(`{3}.*?`{3})",re.S)defsplit_sections(text:str):"""先把围栏代码整段摘出，正文再交给切分器。"""parts,last=[],0forminFENCE.finditer(text):head=text[last:m.start()]ifhead.strip():parts.append(("text",head))parts.append(("code",m.group(1)))last=m.end()tail=text[last:]iftail.strip():parts.append(("text",tail))returnparts拆完以后，text段交回切分器，code段整段保留。这段代码本文没有实际跑过，只是结构示范，标记为待验证；真正落地时要拿你自己的文档补一遍边界情况（比如代码块里嵌了反引号、围栏没闭合）。
7.3 诚实边界：这是几何层面的实测
上面所有数字都是几何与结构层面的观察：块数、块长、块首字符、边界落在哪个字上。没有测任何检索效果指标——没算召回，没算命中，也没验证答案对不对。
换一个分隔符顺序，能让标题和正文进同一块，这是能直接看到的事实；但「同一块之后检索是不是更准」，本文没有证据，也不作暗示。
要证明切得好，只能自己标一套检索评测集：从真实提问里取 50 到 100 条，逐条标出答案所在的原文段落，然后用两套切分参数各建一次索引，比较「答案段落有没有出现在前几条结果里」。这一步没有捷径，也没有通用参数可以代替。
顺序上也别弄反：先用三条判据看结构对不对，结构不对就先改分隔符；结构对了，再花时间标评测集看效果。结构层面就能看出的问题，不值得用评测去证明。
结构优先的切分脚本骨架：把「先摘代码块、再切正文」的两步流程写成了可改的骨架，含围栏正则和分段后的处理分支。放在资料包里，扫码即可获取：
附表 A：本文引用事实与出处对照表
| 事实 | 出处（文档名 + 发布方 + 链接） | 本文位置 |
|---|---|---|
环境：Python 3.13.14、langchain-core 1.6.6，切分器来自langchain_text_splitters模块 | 本机实测（work/2026-10-19_切分器实测.py，日志work/2026-10-19_切分器实测.log） | 第 2.1 节 |
默认chunk_size = 4000、chunk_overlap = 200、separators = ['\n\n', '\n', ' ', ''] | 本机实测（同上脚本与日志，直接打印内部属性） | 第 1.3、2.1、2.2 节 |
chunk_size: int = 4000、chunk_overlap: int = 200、length_function: Callable[[str], int] = len | LangChain 源码langchain_text_splitters/base.py，langchain-ai/langchain，https://raw.githubusercontent.com/langchain-ai/langchain/master/libs/text-splitters/langchain_text_splitters/base.py | 第 2.1、2.3 节 |
self._separators = separators or ["\n\n", "\n", " ", ""]；keep_separator默认True | LangChain 源码langchain_text_splitters/character.py，同上仓库，https://raw.githubusercontent.com/langchain-ai/langchain/master/libs/text-splitters/langchain_text_splitters/character.py | 第 2.3、5.3 节 |
默认分隔符列表为["\n\n", "\n", " ", ""]；块长由length_function决定；中文等无词边界语言建议把「。」加入分隔符 | Splitting recursively，LangChain 官方文档，https://docs.langchain.com/oss/python/integrations/splitters/recursive_text_splitter | 第 2.3、4.3 节 |
| 该官方页面未给出 4000 / 200 两个数值（数值只在源码中出现） | 同上页面，2026-10-19 核验 | 第 2.3 节 |
默认分隔符 + 80 字上限：5 块，长度 49/44/45/51/57；代码块被切成 45 与 51，块 3 止于def行的冒号 | 本机实测（work/2026-10-19_切分器实测.py） | 第 3.1 节 |
| 块 1 的 49 字恰好是「一级标题 + 引言 + ## 一、创建订单」，块 2 的 44 字是该标题下的正文（按块长与前缀复算） | 本机实测（同上脚本与日志） | 第 1.1、3.1 节 |
separators=["。"]+ 80 字上限：4 块，75/19/134/29；块 2 为「。amount 单位为分，不接受浮点数」，块 3 长 134 超过上限 | 本机实测（同上脚本与日志） | 第 4.1、4.2 节 |
分隔符顺序对调（["\n\n","\n",""]与["\n## ","\n\n","\n",""]，上限 60）：块 1 由 49 变 38，块 2 由 44 变 55 | 本机实测（同上脚本与日志） | 第 5.1 节 |
chunk_overlap取 0 / 10 / 30：块 2 长度为 44 / 44 / 55；overlap=10 与 0 的块内容一致 | 本机实测（同上脚本与日志） | 第 6.1、6.2 节 |
chunk_size=40, chunk_overlap=40：13 块，块 10 长 3，块 3/4 与块 7/8 内容重叠 | 本机实测（同上脚本与日志） | 第 6.3 节 |
中文无空格长句（111 字）默认切为 80 + 31，第二块以「证幂等」开头；["。","\n",""]切为 73 + 38，第二块以「。」开头 | 本机实测（同上脚本与日志） | 第 3.2、4.1 节 |
| 代码块保护尝试（把「换行 + 三个反引号 + 换行」与「三个反引号」写进分隔符）：3 块 36/29/3，末块仅 3 个字符 | 本机实测（同上脚本与日志） | 第 7.1 节 |
length_function默认为len，按字符计数；用自定义函数包一层len后块数不变（2 块） | 本机实测（同上脚本与日志） | 第 2.1、7.2 节 |
| 核验方式：官方文档与源码于 2026-10-19 由本机直接访问上述 URL 逐字核对；实测数据取自当日脚本运行日志，未做二次加工 | 本机核验方式说明（如实标注，供读者复核） | 全篇 |
附表 B：术语速查表
| 术语 | 一句话解释 | 在本文哪里用到 |
|---|---|---|
| 切分器 | 把长文档切成小段的程序，英文 text splitter | 第 1 章 |
| 块 | 切出来的一段文本，检索与向量化的基本单位 | 第 1 章 |
| chunk_size | 每块的长度上限，默认按字符数计 | 第 1.2、2.1 节 |
| chunk_overlap | 断开时从上一块末尾保留的最大字数 | 第 6 章 |
| 分隔符 | 切分时用来断句的字符串，按列表顺序递归使用 | 第 2.2 节 |
| 递归切分 | 一刀切完还超限，就用下一级分隔符继续切 | 第 4.2 节 |
| keep_separator | 是否保留分隔符，默认保留，落在下一块开头 | 第 5.3 节 |
| 逐字兜底 | 列表最后的空串，让每个字符之间都能切 | 第 2.2、3.2 节 |
| 碎片块 | 远短于上限的小块，多为残余而非设计 | 第 4.2、5.3 节 |
| 代码围栏 | Markdown 里包住代码的三反引号 | 第 3.1、7.1 节 |
| RAG | 检索增强生成：先检索片段，再让模型照着片段回答 | 第 1 章 |
| token | 模型切词后的最小单位，与字符数不是一回事 | 第 2.1 节 |
| 检索评测集 | 带标注答案位置的问题集合，用来比较切分方案 | 第 7.3 节 |
写在最后：这篇用到的资料
写这篇文章时，把相关的官方文档和源码又翻了一遍，顺手也整理了几份配套的东西：
- 大模型学习路线图：从零基础到能自己动手做 Agent，按阶段说明每一步该学什么、哪些可以先跳过
- 《LangChain + LangGraph + MCP 智能体开发实战》视频课：7 个模块，从私有化部署、Embedding+RAG 到 MCP+Agent 全流程
- AI 大模型知识库（在线可查）：Agent Skills 从入门到落地、Claude Skills 完全指南等专题，按目录浏览即可
- 640 套 AI 大模型行业报告 + 经典 PDF 书籍：看行业落地案例和别人怎么做的时候用得上
- 大模型零基础到精通教学视频：跟着敲一遍，比只读文档快得多
资料是我自己整理的，放在下面这个码上，扫码即可获取：
添加时备注「AI」，优先通过。
资料按「先路线、再动手、最后查漏」的顺序整理好了，建议先看学习路线那一份，照着它挑一条适合自己当前基础的路径再往下看。
