为什么需要 RAG大语言模型LLM虽然强大但有两个硬伤知识截止日期训练完成后就不再更新不知道最新发生的事情。比如你问 GPT-4 “昨天 OpenAI 发布了什么”它答不上来。幻觉问题不懂的问题也会编造答案看起来有模有样但其实在胡说。这在企业场景下是不可接受的。RAGRetrieval-Augmented Generation检索增强生成就是解决这两个问题的标准方案。RAG 的核心流程一句话概括让模型在回答问题前先去知识库里查一下相关资料再根据查到的资料来回答。整个流程分三步第一步索引Indexing—— 把知识库准备好把文档PDF、Wiki、数据库记录等拆成小块Chunk每一块用 Embedding 模型转成向量一串数字存入向量数据库。比如 “什么是 RAG” 这句话会被向量化成类似 [0.023, -0.154, 0.672, …] 这样一串数字然后存入 Milvus 或 Qdrant 这样的向量数据库。第二步检索Retrieval—— 找到相关内容用户提问时把问题也转成向量去向量数据库里找最相似的 Top-K 个片段。举个例子用户问 “RAG怎么减少幻觉”系统会把问题向量化在知识库里找到最相关的 3 个片段比如讲 RAG 原理、讲幻觉成因、讲知识库质量的片段第三步生成Generation—— 基于资料回答把检索到的片段和用户问题一起拼成 Prompt交给 LLM 生成最终答案。这样 LLM 就有了参考资料不会凭空编造。关键细节Chunk 策略切块是 RAG 效果的基础。常见的切法固定长度256/512 tokens 一段简单但可能切断语义语义切分按段落、句子边界切效果更好递归切分先按段落切太大的再按句子切经验值中文场景下512 tokens 左右 128 tokens 重叠是比较稳妥的配置。Embedding 选型中文场景首选中文 Embedding 模型英文模型的 tokenizer 对中文不友好检索效果会差一截BAAI/bge-large-zh-v1.51024 维中文场景推荐stella-base-zh-v3768 维轻量级M3E-base768 维国产通用混合检索Hybrid Search向量检索擅长语义匹配“苹果→iPhone”但可能忽略精确关键词。实际生产中推荐混合检索向量检索加上关键词检索BM25结果用 RRF 算法合并排序。Re-ranking检索到的 Top-K 结果用 Cross-Encoder 重排序可以大幅提升最终效果。推荐 BAAI 的 bge-reranker-v2-m3免费或 Cohere 的 rerank-multilingual-v3付费。进阶方向Agentic RAG让 Agent 决定什么时候去查知识库、查什么、查多少次Graph RAG用知识图谱代替向量库适合需要多跳推理的场景微软开源的 GraphRAGMulti-modal RAG同时检索文本图片适合文档问答Query 改写把用户问题改写后再检索效果往往比直接搜好常用工具LangChain / LlamaIndexRAG 编排框架Milvus / Qdrant / Chroma向量数据库Unstructured.io文档解析总结RAG 并不神秘本质就是先查资料再回答。做好 RAG 的核心在于三个环节切好块Chunking找得准Retrieval回答好Generation每个环节都有很多优化空间但从最简单的实现开始跑通流程再逐步优化是最高效的学习路径。觉得有用点赞 收藏 关注。
