大模型检索增强生成（RAG）有哪些好用的技巧？

RAG算是大模型时代的hello world项目了但是开源方案基本都是文章切块向量召回llm生成 3步实际业务落地过程中有哪些好用的技巧呢说实话RAG 这东西我一开始觉得挺简单——文档切片、向量化、检索、生成四步完事。结果真上手才发现能跑通和能用是两码事。我花了几周时间从 FAISS 换到 Chroma从基础检索加到 Reranker 精排中间踩的坑足够写本小册子。今天就把这些实战里摸出来的技巧摊开讲讲都是真金白银换来的经验。一、Chunk 参数别瞎设这是检索质量的根基很多人做 RAG上来就chunk_size1000觉得切大块点上下文更完整。大错特错。向量模型是有上限的。比如bge-small-zh-v1.5最大支持 512 token你切 1000 字符直接超限向量化直接报错。就算不报错大块里混杂的噪声也会让检索精度直线下降。我调试下来的经验值PYTHON text_splitter RecursiveCharacterTextSplitter( chunk_size250, # 中文场景安全值 chunk_overlap40 # 约 15-20% 的重叠 )为什么是 250小于 Embedding 模型上限512 token留足余量大于一般段落长度能保持语义完整中文 1 字符≈1 token好计算overlap 的作用是兜底。理想情况是根本用不到它——如果切出来的 chunk 都没触达 250 上限说明分块策略成功。我用教学文档测试切出来最大片段 236 字符overlap 闲置这才是最佳状态。二、FAISS 适合学习生产环境请用 Chroma刚开始我用 FAISS代码确实爽PYTHON db FAISS.from_documents(splits, embeddings_model) db.save_local(faiss_index)三行代码搞定适合快速验证想法。但问题很快就来了FAISS 是内存索引保存的是静态快照。知识库要更新只能全量重建。文档要增删改做不到。换 Chroma 之后持久化问题解决了PYTHON dbChroma( persist_directory./chroma_db, embedding_functionembeddings_model )但 Chroma 有个巨坑一次插入不能超过 5461 条记录。LangChain 默认会一次性把所有 chunk 丢过去直接报错。我查源码才发现这个限制解决办法是分批插入PYTHON batch_size 5000 for i in range(0, len(splits), batch_size): batch splits[i:i batch_size] db.add_documents(batch) print(f已插入 {min(i batch_size, len(splits))} / {len(splits)} 条)这个细节官方文档没写我卡着调试半天才弄明白。三、基础检索不准上 Reranker 精排这是提升检索质量最立竿见影的技巧。基础 RAG 流程是用户提问→向量化→向量库相似度检索→返回 top_k→给 LLM 生成。问题在于向量相似度≠语义相关性。我用《战争与和平》测试问皮埃尔是共济会成员吗基础检索召回的全是兄弟会相关内容——向量距离近但事实无关。解决方案粗召回 精排序PYTHON # 第一步粗召回扩大候选范围 base_retriever db.as_retriever(search_kwargs{k: 50}) # 第二步Reranker 精排重打分 encoder HuggingFaceCrossEncoder(model_nameBAAI/bge-reranker-base) reranker CrossEncoderReranker(modelencoder, top_n6) # 第三步管道封装 compression_retriever ContextualCompressionRetriever( base_retrieverbase_retriever, base_compressorreranker )这里涉及两个关键参数k 和 top_nk50粗召回数量决定 Reranker 的工作量。CPU 环境下每增加 1 个 k耗时约 0.05stop_n6最终给 LLM 的片段数决定 Token 消耗博弈关系不怕花时间→提升 k如 k100确保不漏检不怕花钱→提升 top_n如 top_n10给 LLM 更多上下文但 top_n 不是越大越好。过大会导致中间迷失效应——噪声太多反而干扰 LLM 提取关键信息。四、把 RAG 封装成 Tool而不是独立系统这是我踩过之后才醒悟的一点。一开始我把 RAG 做成独立问答系统用户提问直接走 RAG 链条。后来发现两个问题没有记忆——用户问他加入什么组织了RAG 不知道他是谁无法自主决策——有些问题根本不需要查知识库但 RAG 每次都检索正确做法把 RAG 封装成 Tool交给 Agent 调度PYTHON # 一次性初始化 RAG 链避免每次调用都重载模型 rag_chain_instance build_rag_chain(llm) tool def search_war_and_peace(query): 查询《战争与和平》小说中的人物、情节、历史事件 print(f\n正在检索《战争与和平》:{query}) return rag_chain_instance.invoke(query) tools [get_weather, search_war_and_peace] agent create_tool_calling_agent(llmllm, toolstools, promptprompt)这样做的好处记忆由 Agent 统一管理RAG 不用自己处理多轮对话Agent 能自主判断什么时候该查知识库、什么时候直接回答Agent 能结合对话历史改写查询比如把他改写成皮埃尔五、Prompt 写松一点别把 LLM 捆太死这个技巧很小但效果很明显。我一开始的 RAG System Prompt 是这样写的“请严格按上下文回答上下文中没有的信息不要编造。”结果 LLM 明明从上下文能推理出答案却因为没明说就不敢回答。改成“请根据上下文回答问题。如果上下文强烈暗示了答案即使未明说也可推理回答。”效果好很多。LLM 需要一点自由度来发挥推理能力太死板的限制会让它变成只会复制粘贴的机器。六、开发阶段开缓存省 Token 也省时间调试 RAG 很烧 Token。每次改个参数、调个 Prompt都要重新跑一遍检索 生成。开发阶段加个缓存PYTHON from langchain.cache import InMemoryCache set_llm_cache(InMemoryCache())命中缓存的请求不花钱调试效率提升明显。但上线前记得关掉——生产环境缓存复用答案没有任何智能。七、Embedding 模型选对事半功倍不同 Embedding 模型在语义表达能力、维度、上下文感知能力上差异很大。短文本、通用场景bge-small-zh-v1.5速度快资源占用低长文档、专业领域bge-large-zh或bge-m3效果更好但下载慢、资源占用高选模型前可以去 MTEB 排行榜看看模型选错了后面怎么调参都救不回来。小结下RAG 这玩意儿看着简单真要做稳了不容易。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】