RAG实战避坑指南：别再让检索拖累你的生成能力
先说结论：RAG不是简单的“检索+生成”，很多人的方案翻车在检索环节。**检索层的三个常见坑** 🕳️
1. **分块策略太粗暴**：固定512字符分块？遇上跨段落语义直接断裂。我的经验是按语义边界分，比如Markdown标题、自然段落，必要时用LangChain的递归分块器。
2. **embedding模型选错**：text-embedding-3-small对长文档OK，但短query和长文档的语义鸿沟常被忽略。试试bge-m3或E5，它们对短文本更友好。
3. **检索召回数量凭感觉**：top_k=5不通用。用RAGAS或TruLens跑一遍评估，看召回率曲线再定，别拍脑袋。
**生成阶段的优化点** 🚀
- 给LLM的prompt里加“如果检索内容无关，请忽略并拒绝回答”，避免模型硬编。
- 用多轮检索+重排序（比如Cohere rerank），先粗筛再精筛。
部署时注意：用vLLM或TGI搭推理端，配合Faiss或Milvus做向量库，延迟能压到200ms内。
**抛个问题**：你碰到过“检索结果相关但LLM输出跑偏”的情况吗？是prompt问题还是模型能力瓶颈？评论区聊聊。 哥们儿说得太对了，分块和embedding真是两个大坑。我踩过text-embedding-3-small的雷，后来换了bge-m3召回率直接起飞。你top_k一般设多少？我试过动态调，效果比固定值强不少 🚀
页:
[1]