1. RAG落地时最容易踩的五个坑我一个个帮你填平RAG这个词这两年火得不行但真正在生产环境里跑过一轮的人都知道Demo十分钟上线三个月。我前后经手过六七个RAG项目从最朴素的向量检索到后面折腾GraphRAG、Agentic RAG踩过的坑基本能凑齐一套“事故合集”。这篇文章不聊虚的就盯着五个最常翻车的地方——检索命中率低、文本切分稀碎、知识割裂、多模态内容存不进去、评测全靠感觉——把每个问题的成因、排查思路和具体解法拆开讲清楚。如果你正在用LangChain4j搭Easy RAG或者拿Ollama在本地跑简易知识库又或者刚接触RAG知识库想搞明白“为什么我的问答总是答非所问”那这篇内容基本能覆盖你80%的困惑。我会尽量把每个环节的参数选择、代码片段、实测数据都摆出来让你看完能直接抄作业。2. 检索命中率上不去先别急着换模型2.1 命中率低的三种典型表现很多人一发现RAG答不准第一反应是“模型不行换个更大的”。但根据我的经验检索环节的问题占了七成以上。具体表现通常有三种第一种是“答非所问”用户问A系统召回的是B相关的内容生成出来的答案自然跑偏。第二种是“漏召回”知识库里明明有正确答案但检索阶段就是没把它捞出来。第三种是“排序错位”正确内容确实召回了但排在第五位而大模型只看了前三条等于白搭。这三种表现对应的根因完全不同。第一种往往是Embedding模型和领域不匹配第二种多半是切分粒度或索引策略有问题第三种则需要引入重排序Rerank机制。不区分清楚就盲目调参基本等于瞎猫碰死耗子。2.2 混合检索向量加关键词效果立竿见影纯向量检索有个天然短板它对精确匹配不敏感。比如用户问“LangChain4j的Easy RAG怎么配置”向量检索可能召回一堆讲RAG原理的泛泛内容反而把真正讲LangChain4j配置的那段漏掉了。这时候混合检索Hybrid Search就是最直接的解法。混合检索的核心思路是向量检索负责语义相似度BM25或TF-IDF负责关键词精确匹配两路结果加权融合。在LangChain4j里你可以用EmbeddingStoreContentRetriever配合自定义的ContentRetriever来实现也可以直接上Elasticsearch或Milvus这类支持混合检索的向量库。权重的设置很关键。我的经验值是向量检索占0.7、关键词检索占0.3但这个比例要根据你的查询类型动态调整。如果用户查询里包含大量专有名词、产品型号、代码类名关键词权重可以提到0.5甚至0.6。实测下来混合检索相比纯向量检索Hit Rate命中率能提升15到25个百分点这个提升幅度比换一个更大的Embedding模型明显得多。2.3 Rerank不是可选项是必选项很多人觉得Rerank是“锦上添花”我不同意。在召回阶段多捞一些比如Top 20然后用Rerank模型精排取Top 3这个策略在实际项目里几乎是标配。原理很简单向量检索用的是双塔模型查询和文档分别编码后再算相似度速度快但精度有限。Rerank用的是交叉编码器Cross-Encoder把查询和文档拼在一起过模型精度高但速度慢。所以合理的做法是“粗排靠向量精排靠Rerank”。常用的Rerank模型有BGE-Reranker、Cohere Rerank等。本地部署的话BGE-Reranker-v2-m3是个不错的选择中文效果稳显存占用也可控。在LangChain4j里可以通过自定义ScoringModel接入。我实测过一个法律问答场景加Rerank之前Top 3命中率是62%加了之后直接拉到89%效果非常直观。注意Rerank会增加延迟一般每次查询多200到500毫秒。如果对响应时间极其敏感可以考虑只对Top 10做Rerank或者用更轻量的Rerank模型。2.4 Embedding模型选型别只看排行榜Embedding模型的选择直接决定检索质量的上限。但我要提醒一句排行榜上的高分模型不一定适合你的场景。MTEB排行榜主要看通用语义相似度但你的知识库可能是法律文书、医疗病历或者工业设备手册领域差异很大。我的建议是先用通用模型比如BGE-M3、text-embedding-3-small跑一轮基线然后拿一批真实查询做人工评估。如果发现某些领域的查询效果明显差再考虑用领域数据微调Embedding模型。微调的成本没有想象中高几百条标注数据就能带来可观的提升。另外Embedding模型的维度不是越高越好。1024维和768维在大多数场景下差距不大但存储和检索成本差了不少。如果知识库规模在百万级以下768维完全够用。3. 文本切分做不好后面全白搭3.1 切分粒度太大太小都是坑文本切分Chunking是RAG流程里最容易被忽视、但影响最大的环节之一。切得太大一个Chunk里混了好几个主题检索时语义被稀释切得太小上下文丢失大模型拿到半截话也生成不出好答案。我见过最常见的错误是固定长度切分比如每500个字符一刀切。这种做法在技术文档上尤其致命——它会把一个完整的代码示例从中间截断或者把一段逻辑连贯的说明拆成两半。用户问“这个函数怎么用”检索到的Chunk只有函数签名没有参数说明生成出来的答案自然残缺不全。合理的做法是按语义边界切分。具体来说优先按段落切段落太长再按句子切句子还太长才考虑按字符切。LangChain4j提供了DocumentSplitters.recursive()方法可以设置多个分隔符的优先级比如先按\n\n切再按\n切最后按句号切。这个递归策略比固定长度切分效果好很多。3.2 重叠窗口给上下文留条后路即使按语义切分Chunk之间也可能丢失关联信息。比如一个概念在Chunk A的末尾提出在Chunk B的开头展开如果两段完全割裂检索到Chunk B时就会缺少背景。重叠窗口Overlap就是解决这个问题的。通常设置10%到20%的重叠比例比如Chunk大小是500字符重叠50到100字符。这样相邻Chunk之间有一段共享内容保证语义连续性。但重叠也不是越多越好。重叠太多会导致检索结果冗余多个Chunk内容高度相似浪费上下文窗口。我一般建议重叠比例不超过20%具体根据文档类型调整。技术文档可以低一些10%叙述性内容可以高一些15%到20%。3.3 元数据被低估的检索利器很多人切分完文本就直接存向量库了完全忽略了元数据的价值。元数据包括文档来源、章节标题、页码、创建时间、文档类型等等。这些信息在检索时可以发挥巨大作用。举个例子用户问“2024年更新的API文档里怎么配置超时”如果你的元数据里有“更新时间”和“文档类型”字段就可以在检索时加过滤条件只搜2024年更新的API文档。这比纯语义检索精准得多。在LangChain4j里可以通过Document对象的metadata字段存储这些信息检索时用MetadataFilter做过滤。我强烈建议在切分阶段就把元数据打好后面检索和排序都会轻松很多。3.4 表格和代码块的特殊处理表格和代码块是切分的“硬骨头”。表格如果按行切分表头信息就丢了代码块如果按字符切分缩进和逻辑结构全乱了。我的处理方式是表格整体作为一个Chunk不切分。如果表格特别大可以按行组切分但每个Chunk都要带上表头。代码块同理尽量保持完整如果实在太长按函数或类切分每个Chunk带上必要的导入语句和上下文注释。在LangChain4j里可以通过自定义DocumentSplitter来实现这些特殊逻辑。虽然多写点代码但效果提升很明显。4. 知识割裂RAG最隐蔽的瓶颈4.1 什么是知识割裂为什么它这么致命知识割裂Knowledge Fragmentation是RAG里最隐蔽的问题。它不像检索命中率低那样有明显的症状而是表现为“答案看起来对但总觉得少了点什么”或者“多个Chunk拼出来的答案自相矛盾”。根源在于向量检索是独立的每个Chunk单独被检索Chunk之间的关联关系完全丢失。比如你的知识库里有三份文档分别讲了某个产品的安装、配置和故障排查。用户问“安装后配置报错怎么办”理想情况是把三份文档的相关内容都召回并综合。但实际检索时可能只召回了配置文档的片段安装和故障排查的内容因为语义相似度不够高而被漏掉。4.2 GraphRAG用知识图谱补全关联解决知识割裂的一个思路是GraphRAG。它的核心思想是在切分和向量化之外额外构建一个知识图谱把实体和实体之间的关系抽出来。检索时不仅查向量还查图谱把关联实体一起召回。举个例子文档里提到“模块A依赖模块B”GraphRAG会建立一条“A依赖B”的边。用户问“模块A怎么配置”系统不仅召回A的配置说明还会通过图谱找到B的配置说明一起返回。这样答案就完整了。GraphRAG的实现成本比朴素RAG高不少需要实体抽取、关系抽取、图谱构建等步骤。但如果你的知识库实体关系复杂比如技术文档、医疗知识、法律条文这个投入是值得的。微软开源的GraphRAG项目可以参考不过本地化部署需要一定的工程能力。4.3 父子索引小Chunk检索大Chunk生成另一个解决知识割裂的实用技巧是父子索引Parent-Child Indexing。思路是用小的Chunk做检索精度高但返回给大模型的是包含该小Chunk的更大段落上下文完整。具体操作先把文档按大段切分比如每2000字符然后每个大段再细分成小Chunk比如每300字符。小Chunk存向量库用于检索但每个小Chunk都关联到它所属的大段ID。检索到小Chunk后根据ID找到对应的大段把大段内容送给大模型。这样既保证了检索精度又保证了生成时的上下文完整性。LangChain4j里可以通过Document的父子关系或者自定义检索器来实现。实测下来这个策略对“需要综合多段信息才能回答”的问题效果提升明显。4.4 滑动窗口检索让上下文动起来还有一种思路是滑动窗口检索。不是固定返回Top K个Chunk而是以检索到的Chunk为中心向前后各扩展一定范围把相邻Chunk也一起返回。比如检索到Chunk 5系统自动把Chunk 4和Chunk 6也带上。这样即使Chunk 5本身信息不完整加上前后文也能拼出完整语义。这个策略实现简单效果也不错特别适合叙述性强的文档。但要注意窗口大小。窗口太大噪声就多窗口太小又起不到补全作用。我一般建议前后各扩展1到2个Chunk具体根据Chunk大小和文档密度调整。5. 多模态内容存不进去RAG知识库的盲区5.1 图片、表格、PDF扫描件怎么处理“RAG知识库能存储图片吗”这是被问得最多的问题之一。答案是能但不是直接存。向量库存的是向量图片本身存不进去。你需要先把图片转成可检索的表示。常见做法有三种。第一种是图片描述生成用多模态模型比如GPT-4V、Qwen-VL给图片生成文字描述把描述文本向量化后存入知识库。检索时匹配描述返回原图。第二种是OCR提取文字如果图片主要是文字内容比如扫描件、截图直接用OCR提取文字按文本流程处理。第三种是多模态Embedding用CLIP这类模型把图片和文本映射到同一向量空间支持跨模态检索。我的建议是如果图片包含大量文字信息优先OCR如果图片是图表、流程图、照片用图片描述生成如果预算充足且场景复杂上多模态Embedding。三种方式可以组合使用。5.2 PDF解析别小看这个环节PDF是知识库最常见的文档格式但PDF解析的坑特别多。扫描版PDF和文字版PDF的处理方式完全不同。文字版PDF可以直接提取文本但扫描版PDF必须先OCR。即使是文字版PDF也可能遇到多栏排版、表格跨页、页眉页脚干扰等问题。我常用的工具组合是PyMuPDF做基础文本提取pdfplumber处理表格PaddleOCR处理扫描件。LangChain4j本身不提供PDF解析需要自己集成这些工具。解析完之后一定要做清洗。去掉页眉页脚、合并断行、修复乱码。这些看似琐碎的工作对检索质量影响很大。我见过一个项目因为PDF页眉没去掉每个Chunk里都混着“XX公司内部资料 第X页”检索时这些噪声严重干扰了语义匹配。5.3 本地RAG知识库的存储选型如果你在用Ollama搭简易本地RAG知识库存储选型是个绕不开的问题。向量库方面轻量级场景可以用Chroma或FAISS部署简单、零依赖。中等规模可以用Milvus或Qdrant支持混合检索和元数据过滤。大规模生产环境可以考虑Elasticsearch或Pgvector。我的经验是别一上来就追求“大而全”。很多项目其实几万条数据Chroma完全够用部署还省心。等到数据量真的上来了再迁移也不迟。迁移成本主要在重新向量化如果Embedding模型没换其实还好。6. 评测全靠感觉RAG项目永远调不好6.1 没有评测集调参就是玄学RAG项目最怕的就是“感觉效果不好但不知道哪里不好”。没有评测集你改一个参数效果是变好了还是变差了完全靠感觉。今天觉得Rerank有用明天又觉得没用来回折腾。建评测集是RAG项目的第一优先级比选模型、调参数都重要。评测集不需要很大100到200条真实查询就够了。每条查询标注好标准答案和相关的文档片段。有了这个你才能量化地评估每次改动的效果。评测指标主要看三个Hit Rate相关文档是否被召回、MRR相关文档的排名是否靠前、Answer Quality生成答案是否准确完整。前两个是检索指标第三个是端到端指标。6.2 自动化评测RAGAS和LangSmith手动评测太累可以用自动化工具。RAGAS是个专门为RAG设计的评测框架支持Faithfulness答案是否忠于检索内容、Answer Relevancy答案是否切题、Context Precision检索内容是否精准等指标。它用大模型做裁判虽然不完全准确但趋势判断够用。LangSmith是LangChain生态的评测和追踪工具可以记录每次查询的检索结果、生成结果和延迟方便做对比分析。如果你用LangChain4j虽然没有官方集成但可以通过日志导出自己分析。我的做法是每次改动后跑一遍评测集看三个指标的变化。如果Hit Rate没降但Answer Quality降了说明问题在生成环节如果Hit Rate降了说明检索环节有问题。这样排查起来就有方向了。6.3 常见问题速查表问题表现可能原因排查方向解决方案答非所问Embedding模型不匹配检查检索Top 5内容换领域模型或微调漏召回切分粒度太大检查Chunk大小和重叠调小Chunk增加重叠排序错位缺少Rerank检查Top 3命中率加Rerank模型答案不完整知识割裂检查是否只召回单片段父子索引或GraphRAG图片搜不到未做多模态处理检查图片是否入库OCR或图片描述生成调参无方向缺少评测集是否有标注数据建100条评测集6.4 避坑心得别追求一步到位最后分享几条我踩坑踩出来的经验。第一别一上来就上最复杂的方案。朴素RAG先跑通再逐步加混合检索、Rerank、GraphRAG。每加一个组件都要用评测集验证是否真的有提升。第二Embedding模型和Rerank模型要配套。有些Rerank模型对特定Embedding模型的输出更友好混搭可能效果打折。第三知识库更新频率高的话要考虑增量索引。全量重建索引成本很高Milvus和Qdrant都支持增量插入但要注意去重和版本管理。还有一个容易被忽视的点用户查询的改写。用户问“这个怎么弄”直接拿去做向量检索效果很差。可以先让大模型把查询改写成更完整的表述再去检索。这个步骤叫Query Rewriting对短查询和模糊查询效果提升明显。LangChain4j里可以通过自定义QueryTransformer来实现。RAG这个领域变化很快新工具新方法层出不穷。但核心问题就那么几个检索准不准、切分合不合理、知识连不连得起来、多模态支不支持、评测有没有数。把这五个问题解决了RAG项目基本就能从“能用”变成“好用”。我在实际项目里的体会是花在评测和调优上的时间远比花在选模型上的时间值得。 RAG落地避坑指南：检索命中率、文本切分与知识割裂的实战解法
1. RAG落地时最容易踩的五个坑我一个个帮你填平RAG这个词这两年火得不行但真正在生产环境里跑过一轮的人都知道Demo十分钟上线三个月。我前后经手过六七个RAG项目从最朴素的向量检索到后面折腾GraphRAG、Agentic RAG踩过的坑基本能凑齐一套“事故合集”。这篇文章不聊虚的就盯着五个最常翻车的地方——检索命中率低、文本切分稀碎、知识割裂、多模态内容存不进去、评测全靠感觉——把每个问题的成因、排查思路和具体解法拆开讲清楚。如果你正在用LangChain4j搭Easy RAG或者拿Ollama在本地跑简易知识库又或者刚接触RAG知识库想搞明白“为什么我的问答总是答非所问”那这篇内容基本能覆盖你80%的困惑。我会尽量把每个环节的参数选择、代码片段、实测数据都摆出来让你看完能直接抄作业。2. 检索命中率上不去先别急着换模型2.1 命中率低的三种典型表现很多人一发现RAG答不准第一反应是“模型不行换个更大的”。但根据我的经验检索环节的问题占了七成以上。具体表现通常有三种第一种是“答非所问”用户问A系统召回的是B相关的内容生成出来的答案自然跑偏。第二种是“漏召回”知识库里明明有正确答案但检索阶段就是没把它捞出来。第三种是“排序错位”正确内容确实召回了但排在第五位而大模型只看了前三条等于白搭。这三种表现对应的根因完全不同。第一种往往是Embedding模型和领域不匹配第二种多半是切分粒度或索引策略有问题第三种则需要引入重排序Rerank机制。不区分清楚就盲目调参基本等于瞎猫碰死耗子。2.2 混合检索向量加关键词效果立竿见影纯向量检索有个天然短板它对精确匹配不敏感。比如用户问“LangChain4j的Easy RAG怎么配置”向量检索可能召回一堆讲RAG原理的泛泛内容反而把真正讲LangChain4j配置的那段漏掉了。这时候混合检索Hybrid Search就是最直接的解法。混合检索的核心思路是向量检索负责语义相似度BM25或TF-IDF负责关键词精确匹配两路结果加权融合。在LangChain4j里你可以用EmbeddingStoreContentRetriever配合自定义的ContentRetriever来实现也可以直接上Elasticsearch或Milvus这类支持混合检索的向量库。权重的设置很关键。我的经验值是向量检索占0.7、关键词检索占0.3但这个比例要根据你的查询类型动态调整。如果用户查询里包含大量专有名词、产品型号、代码类名关键词权重可以提到0.5甚至0.6。实测下来混合检索相比纯向量检索Hit Rate命中率能提升15到25个百分点这个提升幅度比换一个更大的Embedding模型明显得多。2.3 Rerank不是可选项是必选项很多人觉得Rerank是“锦上添花”我不同意。在召回阶段多捞一些比如Top 20然后用Rerank模型精排取Top 3这个策略在实际项目里几乎是标配。原理很简单向量检索用的是双塔模型查询和文档分别编码后再算相似度速度快但精度有限。Rerank用的是交叉编码器Cross-Encoder把查询和文档拼在一起过模型精度高但速度慢。所以合理的做法是“粗排靠向量精排靠Rerank”。常用的Rerank模型有BGE-Reranker、Cohere Rerank等。本地部署的话BGE-Reranker-v2-m3是个不错的选择中文效果稳显存占用也可控。在LangChain4j里可以通过自定义ScoringModel接入。我实测过一个法律问答场景加Rerank之前Top 3命中率是62%加了之后直接拉到89%效果非常直观。注意Rerank会增加延迟一般每次查询多200到500毫秒。如果对响应时间极其敏感可以考虑只对Top 10做Rerank或者用更轻量的Rerank模型。2.4 Embedding模型选型别只看排行榜Embedding模型的选择直接决定检索质量的上限。但我要提醒一句排行榜上的高分模型不一定适合你的场景。MTEB排行榜主要看通用语义相似度但你的知识库可能是法律文书、医疗病历或者工业设备手册领域差异很大。我的建议是先用通用模型比如BGE-M3、text-embedding-3-small跑一轮基线然后拿一批真实查询做人工评估。如果发现某些领域的查询效果明显差再考虑用领域数据微调Embedding模型。微调的成本没有想象中高几百条标注数据就能带来可观的提升。另外Embedding模型的维度不是越高越好。1024维和768维在大多数场景下差距不大但存储和检索成本差了不少。如果知识库规模在百万级以下768维完全够用。3. 文本切分做不好后面全白搭3.1 切分粒度太大太小都是坑文本切分Chunking是RAG流程里最容易被忽视、但影响最大的环节之一。切得太大一个Chunk里混了好几个主题检索时语义被稀释切得太小上下文丢失大模型拿到半截话也生成不出好答案。我见过最常见的错误是固定长度切分比如每500个字符一刀切。这种做法在技术文档上尤其致命——它会把一个完整的代码示例从中间截断或者把一段逻辑连贯的说明拆成两半。用户问“这个函数怎么用”检索到的Chunk只有函数签名没有参数说明生成出来的答案自然残缺不全。合理的做法是按语义边界切分。具体来说优先按段落切段落太长再按句子切句子还太长才考虑按字符切。LangChain4j提供了DocumentSplitters.recursive()方法可以设置多个分隔符的优先级比如先按\n\n切再按\n切最后按句号切。这个递归策略比固定长度切分效果好很多。3.2 重叠窗口给上下文留条后路即使按语义切分Chunk之间也可能丢失关联信息。比如一个概念在Chunk A的末尾提出在Chunk B的开头展开如果两段完全割裂检索到Chunk B时就会缺少背景。重叠窗口Overlap就是解决这个问题的。通常设置10%到20%的重叠比例比如Chunk大小是500字符重叠50到100字符。这样相邻Chunk之间有一段共享内容保证语义连续性。但重叠也不是越多越好。重叠太多会导致检索结果冗余多个Chunk内容高度相似浪费上下文窗口。我一般建议重叠比例不超过20%具体根据文档类型调整。技术文档可以低一些10%叙述性内容可以高一些15%到20%。3.3 元数据被低估的检索利器很多人切分完文本就直接存向量库了完全忽略了元数据的价值。元数据包括文档来源、章节标题、页码、创建时间、文档类型等等。这些信息在检索时可以发挥巨大作用。举个例子用户问“2024年更新的API文档里怎么配置超时”如果你的元数据里有“更新时间”和“文档类型”字段就可以在检索时加过滤条件只搜2024年更新的API文档。这比纯语义检索精准得多。在LangChain4j里可以通过Document对象的metadata字段存储这些信息检索时用MetadataFilter做过滤。我强烈建议在切分阶段就把元数据打好后面检索和排序都会轻松很多。3.4 表格和代码块的特殊处理表格和代码块是切分的“硬骨头”。表格如果按行切分表头信息就丢了代码块如果按字符切分缩进和逻辑结构全乱了。我的处理方式是表格整体作为一个Chunk不切分。如果表格特别大可以按行组切分但每个Chunk都要带上表头。代码块同理尽量保持完整如果实在太长按函数或类切分每个Chunk带上必要的导入语句和上下文注释。在LangChain4j里可以通过自定义DocumentSplitter来实现这些特殊逻辑。虽然多写点代码但效果提升很明显。4. 知识割裂RAG最隐蔽的瓶颈4.1 什么是知识割裂为什么它这么致命知识割裂Knowledge Fragmentation是RAG里最隐蔽的问题。它不像检索命中率低那样有明显的症状而是表现为“答案看起来对但总觉得少了点什么”或者“多个Chunk拼出来的答案自相矛盾”。根源在于向量检索是独立的每个Chunk单独被检索Chunk之间的关联关系完全丢失。比如你的知识库里有三份文档分别讲了某个产品的安装、配置和故障排查。用户问“安装后配置报错怎么办”理想情况是把三份文档的相关内容都召回并综合。但实际检索时可能只召回了配置文档的片段安装和故障排查的内容因为语义相似度不够高而被漏掉。4.2 GraphRAG用知识图谱补全关联解决知识割裂的一个思路是GraphRAG。它的核心思想是在切分和向量化之外额外构建一个知识图谱把实体和实体之间的关系抽出来。检索时不仅查向量还查图谱把关联实体一起召回。举个例子文档里提到“模块A依赖模块B”GraphRAG会建立一条“A依赖B”的边。用户问“模块A怎么配置”系统不仅召回A的配置说明还会通过图谱找到B的配置说明一起返回。这样答案就完整了。GraphRAG的实现成本比朴素RAG高不少需要实体抽取、关系抽取、图谱构建等步骤。但如果你的知识库实体关系复杂比如技术文档、医疗知识、法律条文这个投入是值得的。微软开源的GraphRAG项目可以参考不过本地化部署需要一定的工程能力。4.3 父子索引小Chunk检索大Chunk生成另一个解决知识割裂的实用技巧是父子索引Parent-Child Indexing。思路是用小的Chunk做检索精度高但返回给大模型的是包含该小Chunk的更大段落上下文完整。具体操作先把文档按大段切分比如每2000字符然后每个大段再细分成小Chunk比如每300字符。小Chunk存向量库用于检索但每个小Chunk都关联到它所属的大段ID。检索到小Chunk后根据ID找到对应的大段把大段内容送给大模型。这样既保证了检索精度又保证了生成时的上下文完整性。LangChain4j里可以通过Document的父子关系或者自定义检索器来实现。实测下来这个策略对“需要综合多段信息才能回答”的问题效果提升明显。4.4 滑动窗口检索让上下文动起来还有一种思路是滑动窗口检索。不是固定返回Top K个Chunk而是以检索到的Chunk为中心向前后各扩展一定范围把相邻Chunk也一起返回。比如检索到Chunk 5系统自动把Chunk 4和Chunk 6也带上。这样即使Chunk 5本身信息不完整加上前后文也能拼出完整语义。这个策略实现简单效果也不错特别适合叙述性强的文档。但要注意窗口大小。窗口太大噪声就多窗口太小又起不到补全作用。我一般建议前后各扩展1到2个Chunk具体根据Chunk大小和文档密度调整。5. 多模态内容存不进去RAG知识库的盲区5.1 图片、表格、PDF扫描件怎么处理“RAG知识库能存储图片吗”这是被问得最多的问题之一。答案是能但不是直接存。向量库存的是向量图片本身存不进去。你需要先把图片转成可检索的表示。常见做法有三种。第一种是图片描述生成用多模态模型比如GPT-4V、Qwen-VL给图片生成文字描述把描述文本向量化后存入知识库。检索时匹配描述返回原图。第二种是OCR提取文字如果图片主要是文字内容比如扫描件、截图直接用OCR提取文字按文本流程处理。第三种是多模态Embedding用CLIP这类模型把图片和文本映射到同一向量空间支持跨模态检索。我的建议是如果图片包含大量文字信息优先OCR如果图片是图表、流程图、照片用图片描述生成如果预算充足且场景复杂上多模态Embedding。三种方式可以组合使用。5.2 PDF解析别小看这个环节PDF是知识库最常见的文档格式但PDF解析的坑特别多。扫描版PDF和文字版PDF的处理方式完全不同。文字版PDF可以直接提取文本但扫描版PDF必须先OCR。即使是文字版PDF也可能遇到多栏排版、表格跨页、页眉页脚干扰等问题。我常用的工具组合是PyMuPDF做基础文本提取pdfplumber处理表格PaddleOCR处理扫描件。LangChain4j本身不提供PDF解析需要自己集成这些工具。解析完之后一定要做清洗。去掉页眉页脚、合并断行、修复乱码。这些看似琐碎的工作对检索质量影响很大。我见过一个项目因为PDF页眉没去掉每个Chunk里都混着“XX公司内部资料 第X页”检索时这些噪声严重干扰了语义匹配。5.3 本地RAG知识库的存储选型如果你在用Ollama搭简易本地RAG知识库存储选型是个绕不开的问题。向量库方面轻量级场景可以用Chroma或FAISS部署简单、零依赖。中等规模可以用Milvus或Qdrant支持混合检索和元数据过滤。大规模生产环境可以考虑Elasticsearch或Pgvector。我的经验是别一上来就追求“大而全”。很多项目其实几万条数据Chroma完全够用部署还省心。等到数据量真的上来了再迁移也不迟。迁移成本主要在重新向量化如果Embedding模型没换其实还好。6. 评测全靠感觉RAG项目永远调不好6.1 没有评测集调参就是玄学RAG项目最怕的就是“感觉效果不好但不知道哪里不好”。没有评测集你改一个参数效果是变好了还是变差了完全靠感觉。今天觉得Rerank有用明天又觉得没用来回折腾。建评测集是RAG项目的第一优先级比选模型、调参数都重要。评测集不需要很大100到200条真实查询就够了。每条查询标注好标准答案和相关的文档片段。有了这个你才能量化地评估每次改动的效果。评测指标主要看三个Hit Rate相关文档是否被召回、MRR相关文档的排名是否靠前、Answer Quality生成答案是否准确完整。前两个是检索指标第三个是端到端指标。6.2 自动化评测RAGAS和LangSmith手动评测太累可以用自动化工具。RAGAS是个专门为RAG设计的评测框架支持Faithfulness答案是否忠于检索内容、Answer Relevancy答案是否切题、Context Precision检索内容是否精准等指标。它用大模型做裁判虽然不完全准确但趋势判断够用。LangSmith是LangChain生态的评测和追踪工具可以记录每次查询的检索结果、生成结果和延迟方便做对比分析。如果你用LangChain4j虽然没有官方集成但可以通过日志导出自己分析。我的做法是每次改动后跑一遍评测集看三个指标的变化。如果Hit Rate没降但Answer Quality降了说明问题在生成环节如果Hit Rate降了说明检索环节有问题。这样排查起来就有方向了。6.3 常见问题速查表问题表现可能原因排查方向解决方案答非所问Embedding模型不匹配检查检索Top 5内容换领域模型或微调漏召回切分粒度太大检查Chunk大小和重叠调小Chunk增加重叠排序错位缺少Rerank检查Top 3命中率加Rerank模型答案不完整知识割裂检查是否只召回单片段父子索引或GraphRAG图片搜不到未做多模态处理检查图片是否入库OCR或图片描述生成调参无方向缺少评测集是否有标注数据建100条评测集6.4 避坑心得别追求一步到位最后分享几条我踩坑踩出来的经验。第一别一上来就上最复杂的方案。朴素RAG先跑通再逐步加混合检索、Rerank、GraphRAG。每加一个组件都要用评测集验证是否真的有提升。第二Embedding模型和Rerank模型要配套。有些Rerank模型对特定Embedding模型的输出更友好混搭可能效果打折。第三知识库更新频率高的话要考虑增量索引。全量重建索引成本很高Milvus和Qdrant都支持增量插入但要注意去重和版本管理。还有一个容易被忽视的点用户查询的改写。用户问“这个怎么弄”直接拿去做向量检索效果很差。可以先让大模型把查询改写成更完整的表述再去检索。这个步骤叫Query Rewriting对短查询和模糊查询效果提升明显。LangChain4j里可以通过自定义QueryTransformer来实现。RAG这个领域变化很快新工具新方法层出不穷。但核心问题就那么几个检索准不准、切分合不合理、知识连不连得起来、多模态支不支持、评测有没有数。把这五个问题解决了RAG项目基本就能从“能用”变成“好用”。我在实际项目里的体会是花在评测和调优上的时间远比花在选模型上的时间值得。