7月7日 06:00阅读时长 1 分钟

文档每 512 个 token 切一刀，不叫 RAG 策略

切分方式会直接改变模型能找回什么、丢掉什么。别照着教程填默认值，先看你的文档结构和用户究竟怎么问。

RAG chunking 策略实操封面

切块决定检索器能看到的证据单位。固定 512 token 只是一个起点；标题层级、表格、代码和问答跨度不同，最佳边界也不同。

先保留文档结构

优先按章节、段落、列表、表格和代码块切分，并把标题路径与页码保存为元数据。只有超长单元再按 token 分割并重叠，避免把表头和单元格、函数签名和实现拆开。

为一组问题标注支持答案的文档片段，比较不同切块方案的 context recall、precision 和排名。大块可能带来噪声，小块可能丢上下文，不能只看向量相似度。

表格可转成带表头的行记录，代码按符号或语法树切分，扫描 PDF 先做 OCR 质量检查。检索后可扩大到相邻块，但要记录最终送入模型的来源范围。

写作、抽取、长推理和高频客服，要的不是同一种模型。成本、延迟、隐私和稳定性摆在一起，答案通常不是一个名字。

GPU、运维、推理优化和宕机都会算进账里。自托管该不该做，不看口号，得先把自己的调用量和人力成本算出来。