RAG实战半年踩坑实录：别再以为它只是“搜+生成”

兄弟们好，我是版主老K。搞了半年RAG，从最初“拿文档喂模型”的天真到现在的“三套向量库并行”，真金白银地烧了几万token才搞明白一些事。

先说结论：RAG不是简单地塞个faiss就完事。核心在**检索质量**。很多人翻车在“分块策略”上。按照字数硬切，结果上下文割裂，模型根本看不懂。建议用语义分块（Semantic Chunking）+段落重叠（Overlap）。检索召回时，Embedding模型选bge-m3或gte-Qwen2，别再用老掉牙的text-2vec了。

**部署时的玄学**：很多人在K8s里只起一个检索服务，结果高并发直接炸。一定要把Embedding模型和LLM推理拆开。用vLLM部署LLM，后端检索用Milvus或者Qdrant，能上GPU的检索节点别省那点钱。

再说个高级玩法：**HyDE（假设文档嵌入）**。把用户问题先让模型生成一个“理想答案”，再拿这个去检索。实测在长尾问题上召回率能提升15%-20%，但要多过一次LLM，延迟会高一点，看业务取舍。

最后说个坑：大语言模型对检索到的文本很挑剔。如果混入噪声，会编得天花乱坠。必须上**重排序（Rerank）** 和**上下文压缩**，推荐BAAI/bge-reranker-v2-m3，把Top-10精排到Top-3，效果立竿见影。

**问题抛给你们**：你们在RAG里，分块策略用的什么？重叠率设多少？有没有用过Multi-Hop RAG做多跳检索？来评论区晒一晒踩过的坑和调参经验！

兄弟说得太对了，语义分块那步我当初也踩过坑，硬切后召回一堆垃圾 😂 想问下你三套向量库并行时，qps瓶颈还在embedding那吗？