大模型再厉害,也有一个硬伤:它的知识停留在训练截止的那一刻,而且可能「记错」。想让它回答你公司的内部文档、最新的产品政策,怎么办?答案是 RAG(检索增强生成)。它是目前企业落地大模型最主流、性价比最高的方案。
一、RAG 是什么
RAG 的全称是 Retrieval-Augmented Generation,核心思想一句话:先检索,再生成。模型在回答之前,先从你的知识库里「查资料」,把相关的片段拼进提示词里,再基于这些资料作答。
这样既利用了 LLM 的语言能力,又让答案基于真实、最新的资料,幻觉大幅减少。你可以把 LLM 想象成一个会说话的助手,而 RAG 是递给它的「参考资料文件夹」。
二、核心流程四步走
一个典型的 RAG 系统分四个环节:
- 文档切分(Chunking): 把长文档切成一段段固定长度的小块,并保留上下文,便于后续检索。
- 向量化(Embedding): 用嵌入模型把每个小块转成向量,存入向量数据库(如 Milvus、FAISS、Pinecone)。
- 检索(Retrieval): 用户提问时,把问题也转成向量,在库里找出语义最相近的若干片段。常用方法有向量检索、关键词检索,以及两者的混合检索。
- 生成(Generation): 把检索到的片段和原始问题拼进提示词,交给 LLM 生成最终答案。
三、落地时最容易踩的坑
RAG 看似简单,真正做好却有不少门道:
- 切分策略: 切太碎会丢上下文,切太大会夹带噪音。要根据文档类型调整。
- 检索质量决定上限: 检索不到,LLM 再强也无米下锅。混合检索 + 重排序(Rerank)能显著提升命中率。
- 引用溯源: 让模型在回答里标注「依据来自哪段文档」,用户能核验,信任度大增。
- 查询改写: 用户问题太口语化时,先让模型改写成一个适合检索的查询,效果更好。
四、RAG 之外的补充手段
如果文档经常变、问题很专,还可以配合函数调用:让模型决定要不要实时查数据库、调接口。更进一步,当某类问题需要模型「深度思考」而非查资料时,微调或长上下文可能是更合适的选择。RAG、微调、长上下文,三者不是互斥,而是按场景组合使用。
对个人开发者来说,用开源向量库加几百行代码就能搭一个能用的 RAG 原型。建议从一个小数据集开始,先把检索质量调好,再逐步扩展。
