langchain:推荐切片策略

RAG 切片策略,直接关系到最终检索结果的优劣。面试官真正想考察的,是你是否理解不同文档类型需要不同的切分策略,而不仅仅是会用 RecursiveCharacterTextSplitter 这一个工具。

💡 为什么不能"一刀切"式地按固定长度切分?

固定长度切分(如每500字符切一刀)虽然实现简单,但它会粗暴地切断语义单元。例如,一个完整的函数、一段法律条款或一个有上下文的问答对,都可能被切碎,导致检索到的信息支离破碎,无法支撑最终的回答。这在面对技术文档、法律合同等结构化文档时尤为致命。

📝 不同文档类型的推荐切片策略

文档类型 推荐策略 核心逻辑与理由 关键参数/工具
技术文档 (Markdown) 按标题层级切分 根据 #、##、### 等标题切分,确保每个 Chunk 包含完整的章节语义。 MarkdownHeaderTextSplitter
客服问答 (Q&A) 按问答对切分 完整保留问题和答案,使检索时用户输入与库中问题更易匹配。 自定义解析逻辑或 RecursiveCharacterTextSplitter 配合特定分隔符
法律合同/长段落 按段落切分 + 重叠 按自然段落切分,并设置 10%-20% 的重叠,防止关键信息被切到边界外。 RecursiveCharacterTextSplitter
代码 按函数/类切分 保持逻辑单元的完整性,避免将函数或类拆散。 PythonCodeTextSplitter或 AST 感知工具
表格数据 按行切分,表头作为前缀 将每一行作为一个独立 Chunk,但必须在每个 Chunk 前强制加入表头信息,告诉模型每一列的含义。 自定义处理逻辑

💻 核心代码示例

1. 通用首选:RecursiveCharacterTextSplitter

这是 LangChain 官方推荐的通用分割器。它会按优先级递归尝试使用不同的分隔符(\n\n, \n, 。, ,, 等)进行切分,在保留语义和控制长度之间取得平衡。

python 复制代码
from langchain_text_splitters import RecursiveCharacterTextSplitter

# 初始化分割器
text_splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,          # 每个块的目标大小(字符数)
    chunk_overlap=50,        # 块与块之间的重叠字符数,建议为 chunk_size 的 10%-20%
    length_function=len,     # 计算文本长度的函数
    separators=["\n\n", "\n", "。", "!", "?", ";", ",", " ", ""]  # 自定义分隔符优先级
)

# 假设 documents 是已经加载的文档列表
chunks = text_splitter.split_documents(documents)
2. 结构化文档:MarkdownHeaderTextSplitter

专门用于处理 Markdown 格式的文档,能够根据标题层级进行精确分割,并保留标题作为元数据。

python 复制代码
from langchain_text_splitters import MarkdownHeaderTextSplitter

# 定义想要切分的标题层级
headers_to_split_on = [
    ("#", "Header 1"),
    ("##", "Header 2"),
    ("###", "Header 3"),
]

markdown_splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers_to_split_on)

# 假设 markdown_text 是你的 Markdown 文档字符串
chunks = markdown_splitter.split_text(markdown_text)

🎯 面试回答话术

面试官:"你不可能所有文档都按固定长度切吧?上下文语义不就变了吗?"

你可以这样回答:

"是的,您说得非常对。在实践中,'一刀切'的固定长度分割是RAG系统的一个典型误区 。我理解,切片策略必须根据文档类型进行适配。

例如,对于技术文档 ,更好的做法是按Markdown的标题层级(#、##) 来切分,确保每个Chunk对应一个完整的章节语义。对于代码 ,应该使用 PythonCodeTextSplitter 或基于AST(抽象语法树)的工具,按函数或类来切分 ,绝不能破坏代码的逻辑单元。处理表格数据 时,关键在于为每一行数据都附加上表头信息 ,否则模型无法理解数字的含义。而对于长段落 ,则可以采用重叠窗口(Overlap) 策略,通常设置10%-20%的重叠,防止关键信息被切到Chunk的边缘。

目前我主要在Dify这类低代码平台上做配置型使用,切片策略相对固定,但我很清楚在这些平台背后,生产级的RAG系统需要根据文档结构进行精细化的策略设计。如果我有机会参与企业级RAG项目,这块会是我重点设计和优化的方向之一。"

这样回答,既承认了当前经验的局限性,又展示了你知道"什么才是更好的做法",同时通过具体的策略和工具名称,证明了你的理解深度。

相关推荐
续写烂尾5 小时前
贴片 SD NAND、eMMC、TF 卡规格怎么定?硬件工程师选型清单
运维·服务器·网络
科技小E5 小时前
监控设备品牌杂乱无法互通?EasyGBS打通孤岛,统一汇聚视频
服务器·网络·音视频
Data analyse4566 小时前
rnweb 回放数据量太大怎么办?分片存储与断点续传的实现思路
前端·网络·算法·数据分析
xiaogai_gai6 小时前
金蝶收料通知单查询策略实战教程:从源系统拉取到中间层落地的完整路径
java·前端·数据库
weixin199701080166 小时前
《抖音商品API:/product/detail 与 /product/list 的字段边界与图片合规踩坑》(附 Python 源码)
服务器·网络·windows
云飞云共享云桌面7 小时前
设计师共享单台图形服务器,解决 SolidWorks大装配卡顿难题
运维·服务器·3d·自动化·电脑·制造
环境栈笔记7 小时前
指纹浏览器 WebRTC 怎么设置?从 ICE 候选、代理出口到功能验证
前端·人工智能·后端·自动化
无足鸟ICT7 小时前
【RHCA+】RPM包命名规则
linux·运维·服务器
赵大仁7 小时前
官网性能优化实战:LCP 3.2s → 2.1s、CLS 0.107 → 0,以及被我推翻的 6 个判断
前端·性能优化·cls·lcp·core web vitals
xiancai_xianyu7 小时前
Text2SQL落地生产库前,SQL要过哪三道闸
前端·数据库·sql·sql注入·text2sql·ai agent开发·企业级ai框架