面经策

在 RAG 中，常见的分块策略有哪些？分别有什么区别？ ​

  • 标签：AI、大模型、RAG

🏛 业务架构师 ​

常见分块策略我按"业务知识形态"来归类，而不是背参数：

  • 固定长度切分：按固定 token 数+重叠滑动窗口。实现最简单、成本最低，适合格式统一的纯文本（日志、评论），但对结构敏感的文档会切断语义。
  • 递归字符切分（LangChain 默认）：优先按段落→句子→字符逐级回退，尽量保住语义完整性，是通用场景的稳妥起点。
  • 结构化/文档感知切分：按 Markdown 标题、HTML 标签、PDF 章节切。企业知识库大量是结构化文档，这种切法天然对齐业务单元（一条制度、一个条款），引用溯源最干净。
  • 语义切分：用 Embedding 判断句间语义突变点再切，效果最好但计算成本高。
  • 父子分块（Small-to-Big）：用小块做精准检索，命中后返回其所属大块给模型——检索准、上下文足，是我做知识库问答的首选。

我的选型逻辑：先看知识形态和引用要求，再谈算法。制度/合同类选结构化切分+父子分块；聊天记录类用固定长度；预算有限就递归切分起步。切分参数没有银弹，靠评测集驱动迭代。

🏗 系统架构师 ​

常见分块策略我按架构权衡排个谱系，从简单到复杂：

  • 固定长度切分：按 token/字符数切。实现零成本，但语义被腰斩，只适合 PoC；
  • 固定长度 + 重叠（Overlap 10~20%）：缓解边界语义断裂，是最常用的默认方案；
  • 递归字符切分（LangChain RecursiveCharacterTextSplitter）：按分隔符优先级（段落→句子→词）递归切，尽量保住自然语义边界，通用性好；
  • 结构/文档感知切分：按 Markdown 标题、HTML 标签、代码函数边界切。语义最完整，是生产首选，代价是解析层要按格式定制；
  • 语义切分：用 Embedding 相邻句子相似度找断点。效果上限高但嵌入成本高、不稳定，用得少；
  • 父子块（Small-to-Big / Parent-Child）：小块做检索（精准），命中后回父块（大段上下文）给 LLM。解耦"检索单元"和"生成单元"，是我最推荐的进阶方案。

选型逻辑：纯文本 QA 用递归+重叠兜底；结构化文档（手册、Wiki）用标题感知 + 父子块；表格走独立通道。chunk_size 常规 256~512 token，没有银弹，用金标集对比 Recall@K 来定。

💻 全栈开发专家 ​

常见分块策略按工程演进排序：

  • 固定长度/递归字符切分：RecursiveCharacterTextSplitter 按 \n\n → \n → 句号 → 空格 优先级递归切，尽量在自然边界断开。默认首选，简单可控。
  • Token 切分：按 token 数精确切，保证每块 token 预算可控，配合 Embedding 上限用。
  • 结构化切分：MarkdownHeaderTextSplitter 按 # 标题层级切、HTML 按标签切，保留「所属章节」作为元数据。技术文档、制度文件首选，检索时还能按章节过滤。
  • 语义切分：SemanticChunker 对相邻句算 Embedding 相似度，在语义突变点断开。块大小不均但语义完整，成本高一点。
  • 父子块（Small-to-Big）：用小块（如 128 token）做检索匹配，命中后返回其父块（如 1024 token）给 LLM。兼顾「检索要准」和「上下文要全」，生产上效果很好，是我最推荐的进阶方案。
  • 表格/代码特殊处理：表格整块不切、行列展开为文本；代码按函数边界切。
python
from langchain.text_splitter import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(chunk_size=512, chunk_overlap=64)

选择心法：先递归字符兜底，再按文档结构升级，最后用评测集验证，不迷信单一策略。