1. RAG落地时最常踩的五个坑，以及我这些年攒下的应对方案

RAG这个词这两年火得不行，但真正在生产环境里跑过的人都知道，Demo和上线之间隔着一道巨大的鸿沟。我最早接触RAG是在一个内部知识问答项目上，当时用LangChain搭了个原型，向量库一接、文档一灌，感觉效果还行。结果一上真实数据，问题全暴露了：检索回来的内容答非所问、模型开始胡编乱造、用户问一个跨文档的问题直接歇菜。后来陆续做了六七个RAG项目，从最简单的本地知识库到带图谱的混合检索，踩过的坑基本能凑齐一本错题集。这篇文章就把我遇到的最频繁、最要命的五个问题拆开讲，每个问题都会说清楚它为什么发生、怎么排查、怎么解决，以及我在实操中总结的那些文档里不会写的细节。不管你是刚用LangChain4j Easy RAG跑通第一个Demo，还是在优化一个已经上线的RAG知识库，这些内容应该都能帮你少走点弯路。

2. 检索命中率低——RAG的第一道生死线

2.1 为什么你的检索总是“差一点”

检索命中率（Hit Rate）是RAG系统的命门。我见过太多项目，模型本身能力不差，但检索回来的内容跟用户问题只有半毛钱关系，最后生成的答案自然惨不忍睹。这个问题的根源通常不在模型，而在检索链路的设计。

最常见的情况是：用户问“年假怎么申请”，你的向量库返回了一堆关于“请假流程”“考勤制度”“休假类型”的文档片段，看起来相关，但真正能回答“怎么申请”的那段操作步骤就是没被排到前面。这不是向量模型不行，而是单一向量检索的天然缺陷——它擅长捕捉语义相似度，但对精确匹配、关键词匹配、结构化关系的处理很弱。

我做过一个对比测试：同一个知识库，纯向量检索的Hit Rate大概在62%左右，加上BM25混合检索后直接拉到81%。这个提升幅度在真实业务里意味着什么？意味着用户每问五个问题，能多得到一个靠谱答案。

2.2 混合检索：向量加关键词才是正解

混合检索的核心思路很简单：向量检索负责语义匹配，BM25负责关键词精确匹配，两路结果融合后重排序。LangChain和LangChain4j都支持这种模式，但配置细节很关键。

以LangChain4j为例，你需要同时配置EmbeddingStoreContentRetriever和BM25ContentRetriever，然后用ReRankingContentAggregator做融合。这里有个坑：两路检索的TopK不要设成一样的。我的经验是向量检索取Top 20，BM25取Top 10，融合后取Top 5给模型。为什么？因为向量检索的召回率更高但精度低，需要更大的候选池；BM25精度高但召回有限，取太多反而引入噪声。

// LangChain4j混合检索配置示例 EmbeddingStoreContentRetriever vectorRetriever = EmbeddingStoreContentRetriever.builder() .embeddingStore(embeddingStore) .embeddingModel(embeddingModel) .maxResults(20) .minScore(0.6) .build(); BM25ContentRetriever bm25Retriever = new BM25ContentRetriever.Builder() .maxResults(10) .build(); ReRankingContentAggregator aggregator = ReRankingContentAggregator.builder() .scoringModel(scoringModel) .build();

重排序模型的选择也很讲究。如果预算有限，可以用Cohere Rerank或者BGE-Reranker这类开源方案；如果追求极致效果，交叉编码器（Cross-Encoder）是更好的选择，但延迟会高一些。我一般会在检索层做一次粗排，然后在生成前做一次精排，这样平衡效果和速度。

2.3 分块策略：别让一刀切毁掉你的知识库

分块（Chunking）是另一个被严重低估的环节。很多人直接用RecursiveCharacterTextSplitter设个chunk_size=1000、overlap=200就完事了，结果检索出来的片段要么缺头少尾，要么把两个不相关的段落拼在一起。

我的做法是按文档类型动态调整分块策略。技术文档按标题层级切，每个小节作为一个独立块；FAQ类文档按问答对切，保证一问一答完整；长篇文章用滑动窗口加语义边界检测，在句子相似度骤降的地方断开。LangChain4j里可以自定义DocumentSplitter，实现基于Markdown标题的分割逻辑。

还有一个细节：chunk_size不是越大越好。我试过512、768、1024、1536几个档位，在中文技术文档场景下，768左右的效果最稳。太小了语义不完整，太大了噪声多且检索精度下降。overlap建议设在chunk_size的15%到20%之间，保证跨块语义的连续性。

实操心得：分块完成后，随机抽20个块人工检查，看看有没有把完整语义切碎的情况。这一步花十分钟，能省掉后面几天的调优时间。

3. 模型胡编乱造——幻觉问题的系统性解法

3.1 幻觉从哪来：检索和生成之间的断层

RAG的幻觉问题跟纯LLM的幻觉不太一样。纯LLM是“不知道也硬编”，RAG的幻觉往往是“检索到了但没用对”。我遇到过几种典型情况：检索回来的文档明明写了A方案，模型生成时却说了B方案；或者检索结果里有多个矛盾的信息，模型自己“脑补”了一个折中答案；还有更隐蔽的，模型把检索到的内容和自己训练时的知识混在一起，生成了一个看起来合理但实际错误的结果。

这个问题的本质是检索结果和生成指令之间的对齐没做好。很多人的Prompt就是简单一句“根据以下内容回答问题”，模型没有明确的约束，自然容易放飞。

3.2 约束性Prompt的设计要点

我现在的Prompt模板里一定会包含这几个要素：明确的角色定义、严格的回答边界、引用要求、以及“不知道”的兜底策略。具体来说：

你是一个严格基于给定资料回答问题的助手。请遵守以下规则： 1. 只使用【参考资料】中的信息回答问题，不要引入任何外部知识。 2. 如果参考资料中没有足够信息，直接回答“根据现有资料无法回答该问题”，不要尝试推测。 3. 每个关键结论后面用[1][2]标注对应的资料编号。 4. 如果不同资料之间存在矛盾，指出矛盾并分别陈述。

这个模板看起来简单，但效果立竿见影。我实测下来，加了引用要求和兜底策略后，幻觉率从23%降到了7%左右。关键就在于让模型有“不知道”的选项，而不是逼着它必须给出答案。

3.3 检索结果的相关性过滤

另一个减少幻觉的手段是在检索后加一层相关性过滤。不是所有检索回来的内容都值得塞给模型，低相关度的片段反而是幻觉的温床。我一般会设一个相似度阈值，低于阈值的直接丢弃；如果过滤后剩余内容太少，就触发兜底回复而不是硬答。

LangChain4j里可以用ContentRetriever的minScore参数做初步过滤，再配合重排序模型的分数做二次筛选。重排序分数低于0.5的基本可以扔掉，0.5到0.7之间的看情况保留，0.7以上的优先使用。

注意：阈值不要设得太高，否则容易把一些表述不同但实际相关的内容误杀。建议先用一批标注数据跑一下，找到召回率和精确率的最佳平衡点。

4. 多跳问题与知识割裂——当答案散落在多个文档里

4.1 单次检索的天花板

用户问“我们公司的年假政策在项目冲刺期间有什么特殊规定”，这个问题的答案可能分散在三个文档里：员工手册里的年假基本规则、项目管理规范里的冲刺期考勤要求、以及某个补充通知里的特殊条款。单次检索只能返回一个维度的内容，模型拿不到完整信息，自然答不全。

这就是多跳问题（Multi-hop QA），也是RAG从“能用”到“好用”必须跨过的门槛。传统的RAG流程是“检索一次、生成一次”，面对这种问题直接歇菜。

4.2 迭代检索与查询分解

解决多跳问题的思路有两种：一种是查询分解，把复杂问题拆成多个子问题分别检索；另一种是迭代检索，根据第一轮检索结果动态生成下一轮查询。

查询分解更适合结构清晰的问题。比如上面那个例子，可以拆成“年假基本规则是什么”“冲刺期考勤有什么要求”“有没有关于年假和冲刺期的补充规定”三个子查询，分别检索后合并结果。LangChain4j里可以用QueryTransformer接口实现自定义的分解逻辑，或者直接用LLM做查询改写。

迭代检索更灵活但实现复杂度高。基本流程是：第一轮检索后，让模型判断“现有信息是否足够回答问题”，如果不够，生成新的查询语句进行第二轮检索，直到信息充足或达到最大轮次。这个方案对Agentic RAG特别适用，因为Agent本身就有规划和反思的能力。

4.3 知识图谱的引入时机

GraphRAG和本体RAG（Ontology RAG）是最近很热的方向，核心思路是用知识图谱补足向量检索在关系推理上的短板。但我得说句实话：不是所有场景都需要上图谱。

如果你的知识库主要是独立的事实性文档，文档之间没有复杂的实体关系，那向量检索加混合排序就够了。只有当你的数据里存在大量“A属于B”“B导致C”“C和D有冲突”这类关系，且用户问题经常涉及跨实体的推理时，图谱才值得投入。

我做过一个对比：在一个规章制度类知识库上，纯向量加混合检索的准确率是78%，引入轻量级知识图谱后提升到86%。提升有，但构建和维护图谱的成本也不低。我的建议是先用混合检索加查询分解把基础打好，确实遇到瓶颈了再考虑图谱方案。

5. 性能瓶颈——当RAG从Demo走向生产

5.1 延迟从哪里来：拆解RAG的耗时分布

Demo阶段大家关注的是“能不能答对”，上线后第一个被投诉的往往是“太慢了”。一个完整的RAG请求，耗时主要分布在四个环节：查询预处理（包括查询改写、意图识别）、向量检索、重排序、LLM生成。我实测过一个中等规模的知识库（约5万文档块），各环节的耗时大致是：

可以看到，重排序和LLM生成是大头。向量检索本身反而很快，因为现在的向量数据库（Milvus、Qdrant、Weaviate等）都做了大量优化。

5.2 缓存策略与异步处理

最有效的优化手段是缓存。我一般会做三层缓存：查询缓存（相同问题直接返回结果）、检索缓存（相同查询跳过检索）、Embedding缓存（相同文本不重复计算向量）。查询缓存的命中率在真实场景下能到30%到40%，这一下就把平均延迟砍掉了三分之一。

异步处理也很关键。重排序和LLM生成可以并行化——把检索到的Top 20先送给LLM做初步判断，同时用重排序模型精排，两者结果都到了再合并。LangChain4j的异步API配合CompletableFuture可以做到这一点。

CompletableFuture<List<Content>> rerankFuture = CompletableFuture.supplyAsync(() -> reranker.rerank(query, candidates)); CompletableFuture<String> draftFuture = CompletableFuture.supplyAsync(() -> llm.generate(quickPrompt(query, candidates))); // 合并结果 CompletableFuture<Void> combined = rerankFuture.thenCombine(draftFuture, (reranked, draft) -> { return llm.refine(draft, reranked); });

5.3 向量索引的选型与调参

向量索引的选择对检索速度影响很大。HNSW适合高召回场景但内存占用高，IVF适合大规模数据但需要调nprobe参数，PQ量化能大幅压缩内存但会损失精度。我的经验是：百万级以下用HNSW，百万到千万级用IVF加PQ，再往上考虑分片。

HNSW的关键参数是M和efConstruction。M控制图的连接度，一般设16到64；efConstruction控制建索引时的搜索深度，设100到200比较稳。查询时的efSearch参数直接影响召回率和延迟的平衡，我一般从64开始调，根据实际效果往上加。

踩坑记录：有一次为了省内存把PQ的压缩率设得太高，结果检索召回率暴跌，模型拿不到正确内容，幻觉率飙升。后来老老实实把压缩率降下来，内存多用了30%，但效果回来了。内存和效果之间，优先保效果。

6. 知识库更新与维护——RAG系统的长期运营

6.1 增量更新：别每次都全量重建

很多团队一开始图省事，知识库更新就全量重建索引。文档少的时候没问题，文档一多，每次更新要跑几个小时，根本没法接受。增量更新是必须的。

增量更新的核心是文档去重和变更检测。每篇文档入库时记录一个内容哈希，更新时先比对哈希，只有内容变化的文档才重新分块、重新计算向量、更新索引。LangChain4j里可以用Document的metadata字段存哈希值，配合自定义的DocumentLoader实现变更检测。

删除操作也要处理好。向量数据库一般支持按ID删除，但要注意删除后索引的重建开销。HNSW的删除是标记删除，不会立即释放空间，需要定期做compact操作。

6.2 知识库质量监控

上线不是终点，知识库的质量需要持续监控。我一般会跟踪几个指标：检索命中率（人工抽检）、用户反馈率（点赞点踩）、无答案率（模型触发兜底回复的比例）、以及平均响应延迟。这些指标异常时，往往意味着知识库内容过期或者检索链路出了问题。

还有一个容易被忽略的点：知识库的覆盖度。用户问的问题里，有多少是知识库能覆盖的？如果无答案率持续偏高，说明要么知识库内容不够，要么检索策略有问题。我一般会定期分析无答案的问题，看看是缺文档还是检索没召回，然后针对性补充。

6.3 多模态内容的处理

现在很多知识库里不只有文本，还有图片、表格、PDF里的图表。RAG知识库能不能存图片？技术上可以，但处理方式不同。图片一般用多模态Embedding模型（如CLIP）转成向量存储，检索时用文本查图片或者图片查图片。表格的话，我一般会转成Markdown格式再分块，保留结构信息。

但说实话，多模态RAG目前的效果还不太稳定，尤其是涉及图表理解的问题。我的建议是：如果文本能表达清楚，尽量用文本；确实需要图片的，做好图片描述（Caption）再入库，检索时用描述文本匹配，比直接匹配图片向量靠谱得多。

7. 几个我踩过的坑和对应的排查思路

7.1 常见问题速查表

7.2 一个真实的排查案例

有一次线上反馈说“年假问题回答得不对”，我排查了一圈发现：检索回来的文档是对的，但模型生成时把“年假天数”和“调休天数”搞混了。根因是这两个概念在文档里相邻，分块时被切到了同一个块里，模型看到两个数字就自己对应错了。

解决办法很简单：在分块时加了一条规则，遇到“年假”“调休”“病假”这类关键词时，强制在段落边界切分，保证每个假种的信息独立成块。改完之后问题就消失了。这个案例告诉我，分块策略要结合业务语义来设计，不能纯靠通用规则。

7.3 关于Agentic RAG的一点个人看法

Agentic RAG是现在的热门方向，核心思路是让Agent自主规划检索策略、判断信息充足性、决定是否继续检索。我试过几个方案，效果确实比固定流程好，尤其是在复杂问题上。但代价是延迟和成本都上去了，而且Agent的决策过程不好调试。

我的建议是：简单问题走固定流程，复杂问题才触发Agent模式。可以在入口加一个意图分类器，判断问题复杂度，然后路由到不同的处理链路。这样既保证了简单场景的响应速度，又能在复杂场景下拿到更好的效果。

8. 写在最后

RAG这个领域变化很快，每隔几个月就有新方案出来。但核心问题就那么几个：检索准不准、生成稳不稳、速度快不快、维护方不方便。把这四个问题解决好，大部分场景都能覆盖。我自己的经验是，与其追新框架，不如把分块、检索、Prompt这三个基础环节打磨到位，收益远比换一个花哨的架构大。另外，别忽视数据质量——知识库里的内容如果本身就有错、过期、矛盾，再好的RAG系统也救不回来。定期清理和更新知识库，比调参重要得多。