一份售后手册有三百页，用户只问某个错误码。知识库若把整本手册当成一个检索对象，向量很难准确代表里面几十个主题。若按固定字数切得太碎，错误码在上一块，处理步骤落到下一块，检索拿回来的又可能只剩半个答案。
我对照了 Azure AI Search 的切块说明和 RAG 架构指南。文档切块先解决模型输入上限，也直接影响检索能找到什么。即使原文没有超长，一个页面同时讲安装、保养和故障处理，用一个向量概括整页仍可能太粗。
切多长只能从样本里找
常见做法有固定长度、按句子或标题结构切分、语义切块，以及几种办法混合使用。固定长度最容易实现，可以留少量重叠，让一个段落在边界处不至于突然断开。Azure 文档给过 512 token、25% 重叠的起始建议，另一处示例也提到 200 个词或 600 个字符配 10% 到 15% 重叠。这些数字适合拿来开第一轮实验，不能直接当成所有公司文档的标准。
合同条款、维修手册和聊天记录的结构差得很大。合同适合保留条款编号和上级标题，维修手册要让故障现象与步骤留在一起，聊天记录还要保住说话人和时间顺序。只调块长，常会错过这些原文关系。
按 Markdown 或 HTML 标题切分，能让章节边界更自然。语义切块会尽量把意思连贯的句子放在同一块，也可能跨过原始页码。中间块离开文档开头以后容易失去主题，可以把文档标题或章节名追加到每一块。这样检索命中一段细节时，模型仍知道它属于哪份产品、哪一章。
解析错误会一路带进检索
切块之前还要看解析结果。页眉页脚若每页重复，会占掉块里的位置。表格被抽成一串错序文字，切得再精细也找不回正确行列。图片里的流程图若很关键，需要保留图片引用，或先生成可核对的文字说明。Azure 的架构指南也提醒，转换中间格式可能丢数据，预处理结果最好留一份，方便比较不同切法。
上线前可以挑二十个真实问题，人工标出答案在原文的哪几段。每换一种切块方式，就看前几条检索结果是否包含完整答案、标题和来源位置。还要统计块数与重复量，重叠过多会增加嵌入和存储成本，也可能让相似片段挤满候选结果。
切块策略一旦进入生产，改动会牵动重新解析、重新嵌入和重建索引。先用小样本看清边界，比把全公司文件一次导进去省事。知识库答错时，也应先检查命中的原文块，再决定要不要换模型。