用 LangChain 搭 RAG：分块、检索与拼装的实操要点

很多人第一次搭 RAG 是这样的：代码跑通了，向量库也建好了，一问问题答得驴唇不对马嘴。问题通常不在模型，而在切分粒度、检索条数和拼装顺序这三步。这篇按开发顺序把三步走一遍，每一步给出可调参数、验收方式和常见翻车点，让你在本地就能判断是切错了还是检错了。

很多人第一次搭 RAG 是这样的：代码跑通了，向量库也建好了，一问问题答得驴唇不对马嘴。这时候八成会先去怀疑模型，其实问题通常出在切分粒度、检索条数和拼装顺序这三步上。这三步都是能在本地调的工程旋钮，不需要换模型也能明显改善。

下面按开发顺序走一遍：文档怎么切、检索怎么调、上下文怎么拼，最后给一个答不准时的排查顺序。每一步都给出可调参数、验收方式和常见翻车点，让你能自己判断到底是切错了还是检错了。

分块：切多大、按什么切、怎么验收

按语义边界切通常比按固定字数切更稳。标题、段落、列表项优先作为切点，代码块和表格单独处理，别让一段完整的话被从中间劈开。如果原始文档本身结构混乱，先做一次清洗和标题识别，比后面反复调检索参数划算。

块大小和重叠要一起调，不要只动一个。块越大上下文越完整，但噪声也越多；重叠能救回跨块的句子，代价是存储变大、召回容易重复。先用一个中庸值把流程跑通，再带着问题去小步调。

召回条数不是越多越好。条数上去，噪声也跟着上去，模型反而更容易被带偏。先把条数当成一个旋钮，小步试，配合答案质量一起看，别一上来就拉满。

纯向量检索对关键词、编号、专有名词容易漏，因为语义相近但字面不同的内容会被优先召回。混合检索，也就是向量加关键词一起用，通常更稳，代价是系统复杂度和成本都高一些。判断方法是：如果你的问题里经常出现编号、型号、专有名词，就该考虑混合。

重排是提精度的常见手段，但要算清代价：多一次模型调用，延迟和成本都会涨。如果对响应速度敏感，可以只在答案质量不达标时开启，而不是默认常开。

给模型明确指令：只用给定资料回答，资料里没有就说没有，不要自己编。这是减少幻觉最直接的一步，比换模型便宜得多。指令要写在资料前面，让模型先知道规则再读内容。

拼装总长度要提前算。不同模型的上下文窗口不一样，超了要么报错要么被截断。具体某个模型能吃多长、单价多少，到站内页面核对当时的数字，别凭记忆拍脑袋。成本换算可以用 /tools/token-price-calculator 里的工具过一遍。

答不准时，排查顺序不能乱，否则容易在错误的地方反复调。正确顺序是先看检索，再看拼装，最后才怀疑模型。每一步都要留下可看的中间结果，别只看最终答案。

这个顺序的价值在于省时间。检索错了就去调提示词，等于在错误的方向上使劲。反过来，检索对了模型仍答错，那才轮到拼装和模型本身。

文档切分有没有通用参数？

没有。中文长句多、英文短句多，合同、手册、代码的边界都不一样。可行做法是先按语义结构切，再拿十几条真实问题测一遍，逐步调块大小和重叠，用问答正确率来判断，而不是照搬别人的数值。

检索出来明明是对的，模型还是答错？

大概率是拼装问题。检查三点：正确段落有没有被长度截断、它在提示里的位置是不是太后、指令有没有明确要求只依据资料回答。这三点都排除了再考虑换模型，否则换模型只是掩盖问题。

必须上重排吗？

看场景。资料量小、问题集中，粗召回通常就够；资料量大、问题杂、对准确度敏感，加重排的收益明显。重排会带来延迟和费用，先用小样本对比有重排和无重排的答案质量，划算再加。