面试题 · 文档处理
搜索「重排」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在构建基于RAG的系统时，你是如何设计文本分块策略的？请说明分块的粒度选择、重叠处理以及向向量数据库写入数据的具体流程。
核心原则：分块不是先猜一个万能数字，而是先保留文档的标题、段落、表格和代码边界，再用同一批业务问题比较候选方案。块更小可能更容易命中局部事实，但也更容易丢失上下文；块更大能保留论证链，却可能引入更多无关内容。
| 场景 | 候选切法 | 验证重点 |
|---|---|---|
| 通用问答 | 先按段落或句子边界切分 | 关键事实能否完整召回 |
| 代码/API文档 | 函数、类或接口级别 | 定义与用法是否仍在同一语义单元 |
| 论文/报告 | 标题与段落级别 |
按学习路线查看教程、项目和面试题。
| 论点、证据与结论是否被拆散 |
| 对话记录 | 单轮或相关多轮合并 | 指代与话题是否连贯 |
关键判断：同一个chunk能否独立解释被命中的事实，以及加入上下文后是否真的改善最终答案。不能只看块长，还要看Recall@K、证据完整率、答案正确性、延迟和索引膨胀。
原始文档 → 清洗（去噪/格式标准化）→ 结构化解析（提取标题/表格/代码块）
↓
产生多组分块候选 → 在固定问题集上评测 → 生成chunk元数据（来源、位置、类型）
↓
Embedding模型编码 → 按实际显存、限流和失败重试能力确定批量大小 → 写入向量库
↓
按需建立倒排索引，用于混合检索工程注意点：
先说明业务问题和文档结构，再给出候选切法、评测集与指标，最后说清最终选择的收益和代价。没有真实实验时，应明确说这是待验证方案，而不是把经验数字说成结论。
场景切入
我看你做过知识库问答，假设用户上传了一本产品手册，系统要检索相关段落来回答。你会怎么切这些文本？比如一段话跨了两页，或者一个表格横跨几行，切分时怎么保证不丢失关键信息？
层层追问
RAG系统里文本分块你一般怎么处理？……如果chunk太小，语义不完整怎么办？……那再加点重叠是不是能缓解？具体重叠多少合适？……最后这些块怎么批量写到向量库里，流程上有什么坑？
直球架构
设计RAG的文本分块策略，说说你选多大粒度、怎么处理重叠，以及从文档到向量库的完整写入流程。要考虑不同文档类型，比如代码、论文、客服对话，分别怎么切？
这道题问的不是你记住了多少分块参数，而是你能不能把语义完整性、检索精度和工程成本放进同一个验证流程。
我会先看文档结构和问题类型。API文档适合按函数、类或接口边界切，论文和报告优先保留标题与段落层级，对话则要避免把指代关系拆开。企业SOP往往要混合处理：先按章节和段落切，表格、代码块和清单再走各自的解析规则。这里没有一种粒度能通吃所有场景，所以我不会一上来就宣布某个token数最好。
接着我会准备几组候选方案。块较小时，局部事实可能更容易命中，但上下文也更容易断；块较大时，论证链更完整，向量却可能混入无关语义。重叠同样不是固定比例：我会比较零重叠、短窗口和较长窗口，用同一批真实问题回放，观察Recall@K、证据完整率、最终答案正确性、延迟与索引体积。只有答案跨边界的bad case明显改善，而且冗余成本可以接受，才保留重叠。
写入流程上，原始文档先清洗和结构化解析，提取标题、表格、代码块与页码；然后执行候选[[分块]]并生成来源、父级标题、原文位置和版本等元数据；再调用[[Embedding]]模型编码，批量写入[[向量数据库]]。batch size 需要根据文本长度、向量维度、显存、接口限流和失败重试能力压测，不能从别的项目抄一个数字。需要[[混合检索]]时，再同步维护倒排索引。
上线还要处理增量更新与一致性。文档更新后，要能定位受影响的chunk，写入新版本，再安全下线旧版本；否则新旧政策可能同时被召回。元数据里保留原文位置，是为了召回后去重、拼接相邻上下文、[[重排序]]和引用溯源。
最后我会用固定评测集记录每组方案的指标与bad case，再决定上线配置。如果没有做过这些实验，我会明确说这是候选设计和验证计划，不会把一个经验范围包装成自己的项目结果。