生产环境RAG的分块策略：固定大小法、语义分块法及父子结构分块法。
对RAG分块技术的实用介绍，涵盖从固定大小与递归分割到父子结构、命题划分、后期分块、RAPTOR方法、表格应用、代码处理以及基准测试等内容。
来源: Chunking Strategies for Production RAG: From Fixed-Size to Context-Aware and Multimodal Retrieval
假设一家保险公司的理赔处理员询问内部助理：40,000欧元的水损理赔需要什么审批手续？在付款之前需要检查哪些内容？该助理可以参考现行的理赔手册。相关文件已成功导入，OCR识别功能正常运行，预处理步骤去除了冗余信息，嵌入模型找到了正确的手册，而重排算法则将其置于页面顶部附近。
但得到的答案仍然不完整。
经验丰富的理算员对此不会感到意外。该规则并非仅写在一段文字中。有一段说明性文字指出，涉及疑似先前损坏的索赔在付款前需要进行独立检查。其下方是一张权限表。下一页则有一张流程图，显示必须先完成欺诈筛查和所有权核实。文档系统中还包含了手册的标识符、版本以及适用地区。
对处理人员而言，这些并非四个独立的事实，而是一条以四种不同形式表达的业务规则：段落规定了条件，表格列出了有权批准的人，流程图说明了检查顺序，而元数据则说明了当前有效的版本。
将标准分割器设置为500个标记时，段落可能被归为一块，表格的上半部分为另一块，相关的表格行则为第三块，而图表中提取的文本则属于第四块。每块数据都是有效的，每次嵌入调用都能成功，控制面板也会保持绿色状态。然而实际的知识结构已被彻底打乱。在查询时，系统必须将声明类型与金额区间关联起来，再将其映射到相应的审批人，找出检查要求并获取相关核查项，而所有这些信息都来自那些单独来看无法理解的碎片。语言模型只能收到零散的信息，因此输出的答案也不完整。
这就是为什么RAG调试容易产生误导。团队们会更换嵌入模型、调整top-k值、购买更强大的重排器或重新编写提示词。有时这些方法确实有效，但更多时候只是弥补了分割过程中造成的问题。较差的RAG质量往往其实是披着大语言模型外衣的分块问题罢了。
关于分块的大多数讨论都集中在一个数字上：256个标记、512或1,000个，以及重叠比例。这些都是合理的实现层面的问题，但架构层面的问题则不同：
哪些内容必须保持在一起，才能在单独检索时依然具有相同含义？
接下来的内容将从最简单的策略讲到2024年和2025年出现的各种技术，指出每种方法的适用场景，并最终给出一种能够处理复杂企业文档的生产级设计方案。
分块在处理流程中的位置
分块并非一个独立的文本处理步骤。它是理解结构清晰的文档与构建可搜索知识之间的界限。上游的所有环节决定了哪些内容可以被分割，而下游的所有环节则取决于这些分割后的部分是否保留了足够的含义、结构及来源信息，从而能够被准确找到。
想象一下完整的路径：PDF、表格、图片、JSON、数据库、API以及代码等来源内容会被导入、解析、清洗并标准化。只有之后，分块层才会决定每种内容类型应如何转化为检索单元。叙述性文本可采用结构化或语义化分割方式；复杂的规则表述则适合用于命题级表示；表格需要依据其结构定义边界；JSON应遵循业务对象的结构；图片则需要与原始内容相对应的视觉描述。
因此，实际生产系统很少为所有内容固定统一的分块大小。同一个语料库可以同时存储文档级、章节级、段落级、命题级和词元级的表示形式。父子检索对会使用较小的分块以确保精确度，同时使用较大的父分块来提供上下文信息；而后期分块、基于上下文的检索以及RAPTOR技术则能够重构那些因简单切割而被丢弃的信息。
即使存在向量，分块过程也并未结束。分块元数据、文档版本、父子链接、访问控制以及来源引用都必须在索引构建、检索、重排序、上下文整合和生成等环节中得以保留。评估则用于形成闭环：检索失败、上下文重复、引用错误以及查询模式的变化都应反馈到分块决策中。实际的分块工作并非单纯地切割文档，而是设计出所有其他功能所依赖的检索单元。
核心权衡
以一段简短的策略摘录为例：
High-risk corporate customers must complete Enhanced Due Diligence.
Facilities above EUR 10 million require Group Credit Committee approval.
Fully cash-collateralised facilities may follow the exception defined in Section 7.4.3.
将所有内容保持在一起虽能保留上下文，但生成的向量较为宽泛且模糊。过度拆分则可实现精准检索，但审批规则可能会偏离其适用的客户群体，而异常情况也可能与它所修改的规则脱节。
这正是其中的矛盾所在：较小的片段能提高精确度，较大的片段则有助于保留上下文，而实际系统需要在这两者之间找到恰当的平衡。每种分块技术都是应对这一权衡的不同途径，且都无法避免对文档内容及用户实际提问的了解。
简单基准方法
固定长度分块
固定长度分块是将文本切割成固定长度的片段，通常以词元为单位，并可选择是否让片段有重叠。这种方法简单、确定性强且成本较低。
通常来说，统计令牌比统计字符更有效，因为嵌入模型处理的是令牌。500个德语或汉语字符所包含的有意义单元远少于相同数量的英语字符。该方法将文本编码为令牌，以固定间隔依次处理这些令牌，并对每个窗口进行解码。由于存在重叠，每个窗口的起始位置都位于前一个窗口结束之前。
- 适用场景：结构均匀的散文、基准测试、操作简洁性至关重要的情况，以及需要先拥有可用处理流程的早期原型。
- 不适用场景：含义取决于结构的情形。某个条件可能在第499个令牌处结束，而其异常情况却在第501个令牌处开始，这样的边界划分完全无法体现业务逻辑。
重叠的作用
重叠机制是防止边界错误的一种保障。没有它，一个句子可能会被分割成两个部分，而这两部分都无法独立存在；有了它，每个部分都会包含一部分相邻内容，从而使两者都仍可被理解。
其代价是实实在在的：需要更多的向量、更高的嵌入计算成本，以及被几乎相同的段落填满的存储空间和结果列表。20%这一比例只是一种惯例而非固定法则，应将其视为用于评估检索性能的参数。
固定大小的分块法之所以能被采用，并非因为它是最优的，而是因为它能提供稳定的基准。如果更复杂的方法在您的数据集上无法显著优于它，那么额外的复杂性就毫无意义。
递归分割
企业文档已在标题、章节、段落、句子和列表中设置了有效的分隔标记。递归分割功能会优先使用这些内置分隔，只有在无法使用时才会采用任意切割点。例如，LangChain的递归字符分割器会首先尝试双换行符——这通常用于标记段落。如果内容仍然过长，它会依次尝试单换行符、句子标点符号、空格，最后才是单个字符。大小限制就是触发这些回退机制的阈值。
分隔符的顺序比具体大小数值更为重要。对于结构清晰的政策文件、操作流程、手册和技术文档而言，这种顺序往往能作为很好的默认设置。
一个制作注意事项：如果数据抽取过程已经提取出了层次结构，就不要将其丢弃后再让分割工具重新发现它。在“借阅”章节下标为7.4的小节已经说明了哪些文本属于同一组。请将这种结构保留在元数据中，并用它来约束分割过程。简单来说，不要在分块时破坏结构，然后在检索时试图重新构建它。
递归分割假设结构大致遵循语义逻辑，但实际情况并非总是如此。一个段落可能包含三条互不相关的规则，而五个段落也可能描述同一个流程。这时就需要基于语义的方法了。
句子与段落单元
spaCy和NLTK等工具提供了经过训练的句子检测器，能够解决简单的分句方式在处理缩写、小数、标题和省略号时出现的错误。段落分割则更为简单且通常更有效，因为段落是作者刻意划分的群体。对于结构清晰的文档，以段落为分割点，并将长度在最小阈值内的相邻短段落合并，是介于固定长度分割与语义分割方法之间的一种合理折中方案。
其缺点在于段落长度不固定。有些段落包含50个标记，而有些则包含800个，这会给批量处理带来困难，增加嵌入过程中的延迟，同时也使得索引大小更难预测。是否这种更好的分割方式值得采用，取决于具体的语料库。
滑动窗口作为召回工具
滑动窗口是一种固定大小的分块方式，其中重叠被视作一种检索机制，而不仅仅是边界保护手段。其原理在于：查询向量与最能直接回答它的段落最为匹配。如果该段落跨越了某个分段的边界，那么这两个分块都可能无法获得高分数。通过设置较大的重叠比例，所有长度合理的段落都至少会完整出现在一个分块中。
更大的重叠比例虽然能提升召回率，但也会带来冗余问题。当重叠比例超过30%到40%时，top-k列表中会出现大量近乎重复的条目，这些条目会消耗上下文资源却无法增加有效信息；而10%到25%的比例则最适合大多数语料库。评估重叠比例时，应结合召回率@k一起测量重复检索率，因为即便将召回率@5提高的同时使重复条目数量翻倍，也未必能提升查询结果的质量。
考虑语义的策略
语义分块
语义分块用一个问题替代了词元计数规则：主题是否发生了足够大的变化，足以构成一个新单元？想象这样一个段落，其前两句讲述检查要求，第三句转向支付限额，第四句则提及欺诈规则。固定的分割器无法识别这些内容转变，而经过良好调优的语义分块器则可以。
常见的处理方法分为三个阶段。首先使用语言模型将文本分割成句子；接着用句向量转换器处理每个句子或相邻句子的小窗口；最后计算相邻嵌入向量的余弦距离，当距离超过某个百分位数阈值时设置分界点，该阈值通常取该文档中距离值的85%至95%之间。
该阈值是至关重要的设定。如果设置得过于激进，相关内容会被拆分成细小且无意义的片段；而如果设置得过于宽松，不同的主题又会保持合并状态，从而重新出现你原本想要消除的噪声。
此外，这种方法的成本也更高，因为必须在确定边界之前完成完整的嵌入处理。对于简短、结构清晰的文档，这种成本带来的收益微乎其微；但对于篇幅长且格式不统一的文本，准确识别主题变化能显著提升检索效果。需要明确的一点是：该方法假设主题会在句子之间逐步且可检测地发生变化。在那些内容密集的法律或规章文本里，一个句子可能同时包含三种条件与两种例外情况，此时基于句子层面的距离计算会产生大量噪声信号。
父子分块
这是生产环境中的RAG技术中影响力最大的模式之一，因为它解决了单一单元处理方式所忽视的矛盾：最适合用于检索的单元并不一定是最适合用于生成的单元。
以一段包含2,000个标记、涉及限制条件、异常处理、控制措施及升级流程的文本为例，将其整体嵌入可以保留上下文，但生成的向量较为模糊。若将其分割成200个标记的片段，则能提升检索精度，但匹配到的片段可能缺乏模型进行有效推理所需的信息。
通过父子分块的方式可以分离这两项任务。父块是指较大的、结构连贯的文本片段，如整个从句、流程或小节；子块则是从父块中提取出的较小且目标明确的片段，如单个条件、阈值或异常情况。只有子块会被嵌入并用于搜索。当某个子块匹配到后，其父块的标识符会用来获取完整的源文本，模型实际读取的也是这部分内容。
LlamaIndex和LangChain通过分层节点、从小到大的检索以及父文档检索提供了相应的实现方式。每个子节点会在元数据中存储父节点ID，检索完成后会先将这些匹配项扩展到其父节点，然后再进行上下文整合。
命题分块
以贷款政策中的这样一句为例：风险较高的企业借款人需要更严格的尽职调查以及年度审查，一旦其风险敞口超过设定限额，就必须由相关委员会批准。这句话包含了三个明确的事实。用于查询此类客户审查频率的系统无需逐一核对审批标准即可找到对应信息。
命题分块将文本拆分为独立的、自包含的陈述句，每个句子都可以单独提取。提取通常在索引时由语言模型完成，该模型会使用结构严谨的提示词来保留所有的条件、阈值、限定词和例外情况，在文本允许的情况下处理代词，并不会推断出未明确提及的内容。对于上述句子，输出可能是三句独立的陈述：此类客户需要经过尽职调查、需进行年度审核，且当风险敞口超过阈值时还需获得委员会批准。
每个命题都有其独立的嵌入向量，因此向量空间就变成了由独立事实构成的空间而非段落集合，这提升了针对具体事实查询的精确度。在此过程中存在两个生成约束：
- 命题并非真理的来源。它只是模型生成的表征。在需要规范的工作中，应先使用命题进行检索，然后再回到权威文本以获取依据、进行推理并引用来源。命题只是索引条目，而非断言。
- 成本会急剧上升。一份包含10,000个标记的文档可能会产生数百个命题，每个命题都需要一次嵌入计算，因此索引规模会迅速扩大。
恢复丢失的上下文
延迟分块
传统的分块方法会先对文本进行分割，再分别对每个部分进行嵌入处理。而Jina AI在2024年提出的延迟分块方法则改变了这一顺序。
延迟分块方法首先将整篇文档输入长上下文嵌入模型，以获得具有上下文信息的词元级表示。之后再设定分块边界，将每个窗口内的词元向量进行聚合。其与直接使用更大分块的差异在于检索单元仍保持较小规模。虽然文本的焦点依然清晰，但其向量能够反映其出现的上下文环境。代词、缩写、前指以及先前定义的术语都已在嵌入阶段得到处理，无需在生成时再由模型处理。
基础设施成本确实存在。你需要一个能够输出词元级结果的长上下文嵌入模型、额外的索引内存以及精心设计的池化代码。它也无法解决糟糕的分段问题：在预处理阶段出错的序列化表格或图表依然会丢失。它只能解决嵌入过程中的上下文丢失问题，无法处理更上游的问题。对于那些存在密集跨句依赖的语料库，比如法规、合同和手册，嵌入质量的提升会非常显著。
上下文检索
Anthropic在2024年发布的上下文检索方法以不同的方式解决了同样的隔离问题。它并未改变嵌入架构，而是在索引时丰富每个数据块的检索文本。
仅包含限制条件的孤立句子可能无法与提及客户等级、管辖区域及审批权限的查询相匹配，因为这些术语存在于文档的其他部分。因此，在进行索引之前，会为每个文本片段生成简短的、针对该文档的上下文说明，例如注明该段落出自哪个政策版本的哪一部分以及其定义的内容。这样的说明会被置于开头，随后再将所有内容整合在一起。
在Anthropic的测试中，将上下文嵌入与上下文BM25结合使用可将前20名的检索失败率降低49%，而加入重排机制后这一比例可进一步降至67%。这些数据来自Anthropic自身的语料库，并非绝对结果。实际效果取决于您的文档、查询、嵌入模型以及检索设置。关键点不在于这些数字，而在于当重要含义位于片段边界之外时，为孤立文本片段添加特定于文档的上下文能够显著提升检索效果。
它对那些含义模糊的片段帮助最大：比如散落的表格行、图片说明、对已定义术语的提及，以及那些范围源自上级章节却不再属于该章节的片段。它也与父子级检索方式能很好地结合使用。需遵循一条原则：生成的上下文仅作为检索辅助，而非原始信息来源。若给每个片段都加上相同的通用描述，向量就会过于相似，从而影响检索效果。良好的上下文化只需补充该片段在不依赖周边内容的情况下所需理解的信息即可。
RAPTOR：多级抽象层次
RAPTOR是“面向树形结构检索的递归抽象处理” 的缩写，它针对单层检索所存在的局限：细粒度的信息片段虽能很好地回答具体的事实性问题，但对于需要跨多个部分进行综合分析的问题则力不从心。比如，询问谁负责批准某一项具体主张，与要求获取该类主张相关的整个组织管控框架相比，前者只需从表格中找到一个权威答案，而后者则需要从审查规则、授权机制、补救或恢复政策、审核流程以及升级路径等各方面寻找证据，很可能涉及多个部门和文件。
RAPTOR构建了一种层次结构。源文本块构成最底层，通过嵌入相似度将相关文本块聚类，随后语言模型会对每个聚类进行总结。这些总结结果再被进一步聚类并总结，如此反复，直到少数高层级总结能够代表整个文档或语料库。在查询时，具体的问题可以匹配到最底层的文本块，而宽泛的问题则可匹配到高层级总结，因此无需改变系统架构即可同时处理这两种查询类型。
在内容生成过程中，最需要关注的问题是来源可靠性。摘要本质上是解读，而解读可能会扭曲阈值、边缘情况以及例外情形——这些正是受监管工作中最为重要的细节。应先使用上层节点找到语料库中的相关部分，然后在生成内容前回溯到原始文本。摘要有助于定位证据，而模型进行推理的依据则是原始文本。RAPTOR在处理长篇政策文件、监管框架以及大型手册时能够体现其价值，因为用户在同一应用中会提出既详细又需要综合分析的问题；而对于短篇内容或同类查询，其复杂性往往难以带来相应收益。
结构化与非文本内容
表格：结构即意义
返回到权限表。该表包含明确的关系：索赔类型为水损，金额在25,000欧元以上，审批人为区域索赔经理。若将这些信息合并成一段文字，就能为每个数值赋予意义的列关系就会消失，因此表格需要专门的处理方式。
对于小型表格，保持其完整性通常是最佳选择，尤其是在需要比较行数据或满足全部条件范围时。可以通过将每行转换为标注-值对的形式来保留列与行之间的关联，从而为每一列指定名称。而对于大型表格，按行划分能更精确地处理数据，但每行都必须包含表头，因为仅有三个没有标注的纯数值本身毫无意义。
在序列化背后还隐藏着一个更重要的决策。如果用户提出的是确定性问题，比如列出超过特定金额的所有审批人，那么向量检索可能完全不是合适的选择。通过 SQL 或数据框查询表格，在进行精确过滤时会比任何嵌入方法都更有效。原则是：不要仅仅为了让所有内容看起来像文本就破坏其明确的结构。
JSON与结构化记录
同样的逻辑也适用于JSON。包含segment、rating、region、amount、approver以及review标志的记录已经明确了哪些字段属于同一组，因此对序列化后的JSON使用分词工具会忽略这一结构。小型记录应保持完整，通过可读的检索界面显示每个字段及其标签。对于大型数据集，则需找出诸如客户、账户、交易、审核事件或案件决策等自然业务实体，然后围绕这些实体进行分块处理。
在单个记录内部，需将语义字段与可过滤字段区分开来。自然语言查询会涉及的字段应纳入嵌入向量中，而region、version、业务单元和生效日期之类的字段作为索引的元数据过滤器通常比作为向量的一部分更有效。针对分类限制进行元数据预过滤既更快也更精确，同时还能让嵌入向量更聚焦于实际含义。
代码：语法是分界标准
代码在另一个领域也存在同样的问题。那种在第500个标记处分割Python文件的通用分割器，可能会将函数与其返回语句分开，或将类与其方法分开。在代码搜索中，分界应遵循语法结构：函数、方法、类和模块。Python的ast模块能够将源代码解析为树结构，并将每个函数、异步函数和类作为独立单元提取出来，这样分割结果就能遵循语言的语义规则，而非仅通过字符数来粗略划分。对于多种语言的代码库，tree-sitter提供了统一的解析接口，可处理正则表达式无法处理的边缘情况。父子节点关系能够自然体现：可以先精确获取某个方法，当模型需要更广泛的上下文时再扩展到其所属的类或文件。
图表与图片
不要将OCR识别出的文本视为图像的完整表现形式。流程图是通过箭头、顺序、分支、分组以及空间布局来传递含义的，而这些都是OCR无法捕捉的。应使用具备视觉理解能力的模型来描述图像所传达的信息，而不仅仅是其中的文字内容。同时存储指向原始图像的指针。生成的描述即为索引条目，而原始图像则是系统作为证据展示的内容。在受监管的系统中，引用应指向原始图像本身，而非其描述。
按内容类型路由
真实的文档是混合结构的。一份手册可能同时包含叙述性规则、权威来源表、流程图、JSON元数据以及嵌入的引用。没有理由对这四种内容都使用相同的拆分工具，因为它们的含义表达方式各不相同：段落通过语言的连贯性来体现意义，表格通过行与列的交叉点来表达信息，流程图通过位置、方向和分组关系来呈现内容，而JSON则依靠明确的键值对来传递信息。
实际解决方案是一种分块路由器，即一种能够识别每个提取出的数据块的内容类型并将其发送给相应处理策略的调度器。该路由器无需过于复杂，其价值在于将内容类型路由作为一种明确的设计选择，而非使用通用分割工具所带来的偶然结果。对于需求说明书而言，叙述内容会通过结构化或语义化分割处理，权威信息表则采用基于表格结构的序列化方式，流程图会转交给视觉模型进行描述，而元数据JSON则会通过基于对象的特征进行分离。
每个生成的数据块都应包含相同的核心元数据，如文档ID、版本号、父节点ID、章节信息及区域标识。这些共享的元数据有助于后续处理环节识别出表格行、段落和图表描述属于同一章节中的相关内容。
何时更大单元更优
上述进展大多朝着更细的粒度方向发展，这可能会给人一种“越小越好”的错误印象。LongRAG的相关研究则探索了相反的方向，测试在某些实验中规模高达约4,000个标记的更大检索单元是否能在处理复杂的多跳问题时优于细粒度检索。研究结果并非表明大块数据始终更优，而是指出检索的粒度应与查询的粒度相匹配。
关于某种账户类型需要多久审核一次的问题，其答案的规模与问题本身相当。而要获取某种声明类型的完整控制框架，则需要来自多个领域的证据；细粒度检索可能会迫使系统从许多孤立的信息片段中拼凑出宽泛的答案，因此即便每个片段都是正确的，也可能会出现整合错误。
选择与衡量
如何挑选策略
并没有一种分块策略在所有情况下都是最优的。选择哪种策略取决于文档结构、实际查询类型、延迟容忍度、索引成本承受能力以及后续生成设计。查询类型与文档类型同样重要。同一套规则可能适用于针对最低审核频率的简单查询，也可能适用于需要解释整个框架的复杂请求，这两种场景对检索精度的要求各不相同。如果你的评估数据仅涵盖某一种类型，那么最优策略在实际使用中可能会表现不佳。
大致指导原则：
- 文本格式统一、处于早期原型阶段：采用固定大小的分块方式，并设置适度的重叠比例。
- 结构清晰的手册和流程文档：采用递归或基于结构的分块方式，将层次关系保存在元数据中。
- 格式不统一的长篇叙述：如果额外的处理成本能带来可测量的收益，可采用语义分块方式。
以基准测试代替猜测
仅查看少量片段并认为其合理有助于调试，但这并非真正的评估。关键在于某种策略能否帮助检索系统找到用户实际发送的查询所需的证据。
构建涵盖不同需求的评估集：与单行数据相关的简单事实查询、需要叙述性内容及流程描述的多证据问题、关于异常情况的条件性问题，以及跨多个部分的综合问题。将每个查询与应被检索到的数据单元的ID关联起来。
仅靠检索指标是不够的。需记录索引规模与固定大小基准值的对比情况、每份文档的嵌入成本、索引与检索的延迟时间、每个查询对应的上下文标记数量、重复率、答案的正确性以及引用内容的正确性。如果索引规模扩大四倍且结果全是近似重复内容，那么Recall@5指标的三个额外分数就毫无价值。
在典型的政策文本语料库中，合理的模式是：在索引成本相同的情况下，递归分割的性能略优于固定长度分割；语义分块虽需稍高的额外成本，但性能提升也较为明显；父子结构能进一步提升召回率，同时索引开销也会显著增加；而命题与父节点结合的方式虽然成本和复杂度都更高，但能达到最高的召回率。上下文检索可能在索引增长较少的情况下实现类似的召回率，这为其在索引阶段采用该模型提供了依据；RAPTOR在处理细节性事实时可能略逊于父子结构，但在综合分析方面更具优势。这仅用于说明各种方法之间的权衡关系，并非实际测量结果。最佳操作点取决于对准确率的要求、延迟限制、索引预算，以及每项改进所带来的复杂度是否值得。
不要仅优化检索功能
假设高度重叠能够提升5分时的召回率，但前五条结果中会有四条几乎完全相同的段落来自同一条款，从而导致其他相关内容被排除在上下文范围之外。虽然有一个指标有所改善，但系统的整体表现反而变差了。需要评估从信息检索、重排序、上下文整合到内容生成的整个流程，在每个阶段都要检查所需证据是否保留完好、重复内容是否占用了有用空间、答案是否正确且有依据、以及引用来源和版本是否准确。
在受监管的系统中，引用准确性绝非可有可无的细节。一个答案可能在事实层面是正确的，但其依据的政策版本却是错误的。这依然属于合规失误，除非对引用的来源进行明确验证，否则这种问题将一直无法被发现。
生产环境架构
思维模式上的核心变化在于，成熟的企业级处理流程几乎从不需要一个通用的分块工具。它需要的是一个路由层，能够将每个内容块发送到合适的处理策略，同时在所有生成的分块中保留共享的元数据，并提供指向权威来源的明确链接。
对于索赔手册而言，一种合理的架构是：叙述性内容进行结构或语义分割；冗长的规则条款转化为保留父节点的命题；小型表格整体序列化处理；大型表格则拆分为包含表头的行块；图表则用视觉模型描述来呈现；JSON记录则通过对象分隔。无论类型如何，每个数据块都包含相同的标识符：文档ID、版本号、父节点ID、章节信息、区域标识以及对原始文档的引用。这种共同的溯源机制与数据块本身同样重要，因为它能够将同一版本中某个章节的表格行、规则条款和流程描述作为证据相互关联起来。
回到水损索赔部分
问题从来不是500个还是800个标记才是合适规模。文档中包含了各种类型的证据：段落表明需要进行独立检查，表格说明了谁负责审批金额范围，图表列出了付款前的核查步骤，元数据则指明了适用的版本和地区。
一个设计良好的分块层能够保持每个部分的原始结构，同时记录它们属于同一部分这一事实。这样一来，在检索时就有不同的选择：涉及审批的问题可获取表格行，涉及检查的问题可获取相关条款，涉及流程的问题可获取图表描述，而复杂问题则可以调取多个相关的子部分，并将其展开为共同的父节点。这正是文本分割与检索单元设计之间的区别所在。
排序规则并非固定为先语义、再命题，最新出现的想法会胜出。正确的做法是：学习源内容，了解查询需求，保留现有结构，选择合适的检索粒度，补充缺失的上下文，保留来源信息，衡量检索结果与答案的质量，仅在确实有必要时增加复杂性。
索引前的最后检查清单
在数据块进入嵌入处理流程之前，每个数据块都需满足以下三个条件：
- 可检索性。具体程度要足以匹配重要的查询，但又不能过于宽泛以至于随意匹配所有内容。
- 可解释性。需包含足够的上下文以便独立理解其含义，或具备通过父节点查询来恢复该上下文的可靠方法。
一旦缺少其中任何一项，分块层就会将其问题传递给检索、重排序、上下文构建和生成环节。向量存储会毫无异议地为有缺陷的单元建立索引，嵌入 API 也会直接返回向量，模型则可能在其基础上给出看似可靠的答案，但这些都无法表明该表示是正确的。在问题演变成嵌入之前修复有缺陷的单元成本最低。
在产品上线前，还需规划日志记录、敏感信息与配置管理、确定性标识符、模型及提示词的版本控制、分块来源追踪、访问控制、评估数据集、索引生命周期管理，以及检索质量、延迟和成本的监控。