做了三个RAG项目，前两个差点让我放弃这个方向。第三个终于做成了，是一个企业内部知识库问答系统。把踩过的坑整理出来。
RAG原理很简单：文档切片→向量化存储→用户提问时检索→喂给LLM生成回答。但"原理简单"和"做得好用"之间隔着十万八千里。
坑1：文档切片策略。 直接用LangChain的RecursiveCharacterTextSplitter按500字切，结果答案被切断了，AI找到的片段不完整。正确做法是按语义切，不同文档用不同策略，chunk之间加20%重叠。
坑2：Embedding模型选择。 用了免费小模型，中文检索命中率很低。换成BGE系列后效果好了很多。
坑3：检索数量。 top 3漏信息，top 10又跑偏。正确做法是先检索top 10，再用Reranker重排序取top 3-5。
坑4：答非所问。 用户问"退款政策"，文档里写的是"退货退款须知"，AI搜不到就开始编。需要加置信度阈值+Prompt明确说"不知道就说不知道"。
坑5：性能。 文档过万条后检索变慢。需要用合适的向量数据库+混合检索。
想问问大家：
- RAG项目中Reranker到底有多大提升？
- 有没有比LangChain更好的RAG框架？
- 你们的向量数据库用的是什么？
RAG做了半年多，楼主踩的坑我基本全踩过一遍
说说我的补充。
关于Reranker的提升：非常大，是质变级别的。
我做过A/B测试：
- 纯向量检索 top5：回答准确率约65%
- 向量检索 top10 + BGE-Reranker：回答准确率提升到约82%
提升了将近20个百分点。Reranker的原理是用交叉编码器（Cross-Encoder）对query和每个document做精细匹配，比纯向量的双塔模型准确得多。代价是速度稍慢，但对于实时问答场景完全可以接受。
推荐的Reranker：BGE-Reranker-v2-m3，中英文都很好，而且模型不大，CPU推理都够快。
另外楼主提到的"答非所问"，我有个更好的方案——Query改写。用一个小的LLM把用户的口语化问题改写成更标准的搜索query。比如把"退款怎么搞"改写成"退款退货政策流程"。这一步的效果甚至比Reranker还明显。
3 个赞
回答第二个问题：LlamaIndex确实比LangChain更适合RAG。
我两个都用过，体感对比：
| 维度 |
LangChain |
LlamaIndex |
| 定位 |
通用AI应用框架 |
RAG专用框架 |
| RAG功能 |
有但不够深 |
非常深入 |
| 文档切片 |
基础 |
高级（支持语义切片、表格处理等） |
| 检索方式 |
主要向量 |
支持混合检索、递归检索等 |
| 学习曲线 |
较陡 |
中等 |
LlamaIndex的核心优势是索引策略很丰富。它有Tree Index、Keyword Index、Vector Index等多种索引类型，可以根据文档特点选择最合适的。
比如FAQ类文档用Keyword Index效果就很好，因为FAQ的关键词匹配比语义匹配更准确。技术文档用Tree Index可以保留章节结构。
如果你只做RAG，建议直接用LlamaIndex。如果你的项目不只是RAG（比如还要做Agent），LangChain的生态更全。
楼主第三个问题，向量数据库我用的Qdrant，性能和功能都不错，支持过滤查询，比Chroma强不少。
1 个赞
分享一个进阶经验：多级索引架构。
简单的RAG就是"一把检索"，但做到生产级别你会发现单级检索不够用。我的架构是三级：
第一级：分类路由
先用一个小模型判断用户问题属于哪个类别（产品相关？技术相关？政策相关？），然后路由到对应的知识子库。这样每个子库的文档量小了，检索精度自然高了。
第二级：混合检索
在子库内同时做向量检索和BM25关键词检索，用RRF（Reciprocal Rank Fusion）融合排名。混合检索比纯向量检索的召回率高出15-20%。
第三级：Reranker精排
楼上已经说了，不赘述。
这套架构在我们10万+文档的企业知识库上跑了3个月，用户满意度从最初的62%提升到了89%。
还有一个小trick：给每个chunk加元信息。比如"来源文档"、“章节标题”、“更新日期”。检索时可以按元信息过滤，回答时可以附上来源链接，增加可信度。
2 个赞
向量数据库方面补充一下。
我测试过几个主流方案：
Chroma：开发体验最好，适合原型验证和小规模（<10万条）。但它是内存型的，数据量大了性能下降明显。
Milvus：性能最强，支持分布式。但运维复杂度高，单独搞一套Milvus集群对小团队来说太重了。
Qdrant：我现在的主力。性能接近Milvus，但部署简单得多。支持丰富的过滤条件，API设计也很友好。单机能跑千万级向量。
Weaviate：功能全面，内置了混合搜索，但Go写的，出问题调试不太方便。
建议：
- 个人项目/原型验证 → Chroma
- 中小规模生产（<1000万条） → Qdrant
- 大规模生产（亿级） → Milvus
另外一个容易踩的坑：向量维度要和Embedding模型匹配。BGE-M3的维度是1024，建索引时维度配错了数据存进去检索结果会很诡异，不报错但结果不对。
1 个赞