部分内容可能来自网络或者由AI生成。如有雷同纯属巧合仅供学习参考之用。一、为什么需要 RAG定位与边界一句话结论RAG 不是让模型更聪明而是在回答前把模型不知道、但知识库里有的相关信息补进上下文用非参数化的外部知识弥补参数化知识的三个固有缺口。大语言模型有三个绕不开的痛点一是幻觉模型会一本正经地编造事实二是知识过时训练数据有截止时间无法覆盖最新信息三是缺乏专业/私域知识企业内部文档、实时业务数据从来不在预训练语料里。RAG 的做法是先查资料再答题——像一个带着笔记进考场的考生或给模型配一本随时可查的教科书。与两个易混淆方案划清边界RAG vs 微调微调是让模型广泛学习并内化知识与风格改变的是模型参数RAG 是给模型一本教科书去查具体问题不改参数。RAG 在知识更新时效性、可追溯性、数据安全、成本、可扩展性上占优微调在风格模仿、固定格式输出上占优两者可叠加。RAG vs 长上下文随着 GPT-4-turbo128K、Gemini 1.5 Pro1M、Claude 31M、Kimi约 200 万字等长窗口模型出现直接把全部资料塞进上下文看似可行但成本、延迟、以及迷失在中间Lost in the Middle问题依旧存在。主流判断是二者互补而非替代长上下文缓解了塞不下但精准检索仍是控成本、控噪声的关键 。RAG 的收益有据可查OpenAI 曾公开一个案例在不做微调的前提下通过 RAG 相关优化把准确率从 45% 提升到 98%。小结当问题依赖时效性强、私域、可追溯的知识时优先用 RAG当需要改变模型输出风格/格式时才考虑微调长上下文是 RAG 的补充不是免死金牌。二、RAG 工作流全景一句话结论一条完整 RAG 链路可拆成离线建库和在线问答两段共七个环节每一环都是独立的可优化节点——把 RAG 当黑盒是定位不了问题的。明确反对把 RAG 当黑盒主张深入链路细节锚定两个核心指标召回率把最相关的找回来和精确率不相关的别混进来二者在实践中需要权衡追求两者都高并不现实。各环节职责加载对接多种数据源清洗去除 HTML 标签、URL、邮箱、无意义图片等噪声切分把长文档拆成可检索的 chunk向量化把文本编码为向量索引决定检索速度与召回质量在线侧的检索前处理优化 query 表达检索做多路召回检索后处理做重排与压缩最后增强拼装进 Prompt 交给 LLM 生成并通过评估闭环持续优化。小结优化 RAG 的正确姿势是先定位链路瓶颈召回没找到、还是精排没排上、还是生成没用好再针对性动某一环而不是笼统地换个大模型。三、四大范式演进一句话结论RAG 沿Naive → Advanced → Modular → Graph/Agentic演进本质是从固定串行管道走向模块可插拔、流程可自适应理解原理后应自由组合而非套用某个固定范式。公开综述arXiv:2312.10997Gao et al.即热文1的翻译母本把 RAG 归纳为三大经典范式后续社区补充了 Graph RAG2024 微软开源与 Agentic RAG集大成两代范式核心特征关键手段局限Naive RAG索引→检索→生成的检索-阅读串行管道固定分块 向量相似度 Top-K低精度/低召回、上下文冗余、过度依赖检索 [热1]Advanced RAG在检索前后加优化环节查询改写/扩展/路由、Rerank、Prompt 压缩、混合检索、HyDE仍是相对固定的流程Modular RAG模块可增删替换、可端到端训练搜索/记忆/融合/路由/预测/任务适配六模块编排复杂度高 [热1][用户5]Graph RAG引入知识图谱索引期抽取实体关系图遍历解多跳、全局主题分析建图成本高 [用户2][用户5]Agentic RAG在各环节引入 Agent 自适应决策动态规划、多工具协同、反思闭环延迟与稳定性挑战 [用户2][用户5]三者关系可理解为逐级泛化Naive RAG 是 Advanced RAG 的特例Advanced RAG 是 Modular RAG 的特例。Modular RAG 的六个模块——Search多查询/跨模态/缓存并行、Memory对话历史/User Profile/反馈、Fusion加权 RRF / Learning-to-Rank、Routing关键词/LLM 语义/多级、PredictHyDE 先生成后检索、TaskAdapterZero-shot 提示池 / Few-shot——可以用 langgraph 的 StateGraph 编排成routing → pre_retrieval → retrieval → post_retrieval → generate的节点图。小结范式没有优劣只有匹配度。简单 FAQ 用 Naive/Advanced 足矣跨文档多跳推理考虑 Graph RAG需要动态判断要不要查、查几次、查哪里时才上 Agentic RAG。四、检索前的关键工程分块与索引增强一句话结论分块质量是 RAG 的地基——垃圾进垃圾出固定长度切分最省事也最容易切碎语义语义分块和索引增强能显著改善召回。4.1 分块Chunking策略系统归纳了五类分块策略可按语义保真度与算力成本排序策略做法优点代价Fixed-size 固定大小按固定 token 数 重叠切实现最简单易截断句子、丢失关键上下文Recursive 递归先按段落、再递归细分兼顾结构与粒度需调分隔符Document-structure 按结构按 H1/章节/列表/表格切保留文档层级依赖规整格式Semantic 语义按语义单位、靠余弦相似度阈值合并块内相关性高需额外相似度计算LLM-based让 LLM 智能判断语义块效果上限最高算力成本最高公开最佳实践论文arXiv:2407.01219给出了更具体的经验值最优 chunk 大小约 512 或 256 token重叠 20 token滑动窗口sliding window分块在忠实度/相关性上表现最好faithfulness 97.41 / relevancy 96.85其次是 small2big小块 175 token、大块 512 token。工程实操上给出了可量化的判断方法用 StatisticalChunkermin_split_tokens100, max_split_tokens500做语义分块盯三个指标——Threshold相似度下限例子取 0.31越大块内越相关、Window Size默认 5越大上下文越全但算力越高、Similarity Chunk Ratio示例 0.89 41/46越高说明越是按语义切分而非被强制截断。LLM-based 分块的提示词可以很简洁——让模型只输出句子编号分组角色你是 RAG 语义分块专家。 输入按句子编号后的文本。 要求将语义连贯的句子归为一组只输出句子编号 同一块的编号放同一行、逗号分隔不同块换行。 输出示例 1, 2, 3 4, 5, 6, 7 8, 94.2 索引增强分块之外索引期还能做两类增强语义增强上下文补全把 chunk 连同整篇文档丢给 LLM 生成一段概述append回 chunk 再索引。建议用强 LLM Prompt Cache 降低重复开销。这与 Anthropic 的 Contextual Retrieval 思路一致。反向 HyDE把 chunk 视为答案让 LLM 为它生成若干个可能被问到的问题用作索引检索时用问题匹配问题。优势是可完全离线处理、不影响在线 RT适合问答型知识与关键词扩写场景。综述还补充了滑动窗口、Small2big、摘要嵌入、元数据过滤、图索引等块优化技术以及用实体名替换代词以保留指代语义这类清洗细节。小结分块不要一上来就上 LLM-based。先用递归/语义分块把 Similarity Chunk Ratio 拉到 0.85 以上再视召回缺口决定要不要加语义增强或反向 HyDE。五、嵌入与向量库选型一句话结论Embedding 决定能不能被检索到向量索引决定检索得快不快、贵不贵中文场景务必选中文语料充分的嵌入模型海量向量场景优先考虑 DiskANN 这类低内存索引。5.1 Embedding 模型嵌入模型的三个隐形坑语言覆盖all-MiniLM-L6-v2处理中文很差会返回大量表示不可识别 token的兜底值、词汇表大小all-MiniLM-L6-v2词汇表仅 30522主流模型多在 5 万/10 万以上、语义空间通用模型在垂直领域可能需要 SFT。综述也提醒text-embedding-ada-002在文本少于 5 token 时会出现异常高的余弦相似度更适合 256/512 token 的文本块 [热1]。中文可选项的横向参考蚂蚁企业问答实测的 CMTEB 排名[热5]模型CMTEB 得分备注gte-large-zh66.72实测最高stella-large-zh-v265.13bge-large-zh-v1.564.53社区常用piccolo-large-zh64.11m3e-base57.79蚂蚁问答早期选型text-embedding-ada-00253.02中文偏弱公开最佳实践则推荐 LLM-EmbedderBAAI效果接近 bge-large-en 但体积小约三倍 [公开1]。5.2 向量索引与向量库向量检索的底层是近似最近邻ANN索引 IVF倒排文件索引用 Voronoi 质心把空间分块检索时只扫最近的几个单元省算力但有精度损失。HNSW分层可导航小世界图逐层递进搜索召回与性能都好但占内存大。DiskANN磁盘友好的层次化图仅需约 10% 数据入内存、90% 放磁盘即可达到接近 HNSW 的召回率内存成本仅为 HNSW 的 1/10支持千亿级向量。IVFHNSW 折中单元内用 HNSW平衡内存与精度。主流向量库对比向量库索引全文检索混合检索特点MilvusHNSW/IVF_FLAT/IVF_SQ8/IVF_PQ/DISKANNKnowhere 引擎支持内置功能全、十亿级、云原生公开最佳实践唯一四项全满足者 [公开1]QdrantHNSW支持支持轻量易用COSINE 距离WeaviateHNSW支持内置混合开箱即用混合搜索ChromaHNSW弱弱适合业务初期原型Elasticsearch倒排 向量强支持全文检索基石DashVector / TablestoreProxima / DiskANN 多元索引支持支持RRF 待上线阿里云托管Tablestore 自适应索引免参数选择Tablestore 的路线值得单独提一句它主张用宽表引擎 多元索引同时承接 Agent 的短期记忆Memory与长期知识Knowledge即 RAG 知识库靠 DiskANN 把内存成本压到 HNSW 的 10%、向量以 bytes 格式存储比字符串省最多 4 倍空间并通过自适应查询策略自动选最佳索引免除用户手工调参。这解决了传统方案的痛点MySQL 单表超 5000 万行性能骤降、PG-Vector 在 1 亿向量时混合查询超 1 秒。小结中文场景先在 CMTEB 上选嵌入模型并考虑领域微调原型期用 Chroma/Qdrant生产上规模用 Milvus超大规模、成本敏感场景评估 DiskANN 系如 Tablestore。六、检索与重排混合检索、RRF 与 Rerank一句话结论单一向量检索不够——业界最佳实践是向量稠密检索 BM25 稀疏检索混合召回后用 RRF 融合再叠加 Rerank 精排HyDE 能进一步提召回但要付延迟代价。6.1 混合检索五种核心检索技术各有分工 技术匹配方式角色代表实现全文/BM25词法精确匹配混合检索基石Elasticsearch/Solr向量稠密检索语义匹配核心FAISS/Milvus/Weaviate向量稀疏检索学习的词权重关键词增强SPLADE图检索实体关系遍历多跳知识图谱HyDE生成式查询扩展补召回先生成假设文档再检索稀疏向量为何不能完全替代全文搜索因为预训练模型生成的是固定维度如 3 万或 10 万维稀疏向量专业术语、机器型号这类词可能根本不在模型词表里二者各有千秋。三路混合全文 稠密 稀疏即 BlendedRAG在公开基准上被验证效果最优 。融合多路结果的标准做法是 RRFReciprocal Rank Fusion倒数排名融合它只看排名不看原始分兼顾大众评分又防止冷门优质结果沉底。以k60为例某文档在两路分别排第 1、第 2则得分1/(601) 1/(602) ≈ 0.03252。若用加权融合需先各自归一化再加权给出的经验权重是稀疏 0.2、稠密 0.8# 归一化后加权融合alpha0.2 偏向稠密向量 import numpy as np dense_norm (dense_scores - dense_scores.min()) / (dense_scores.ptp() 1e-8) sparse_norm (sparse_scores - sparse_scores.min()) / (sparse_scores.ptp() 1e-8) alpha 0.2 weighted_scores (1 - alpha) * dense_norm alpha * sparse_norm公开最佳实践的量化结论Hybrid Search HyDE 效果最好TREC DL19 上 nDCG10 达 73.34但延迟高HyDE 用一个假设文档即可加多了只增延迟不提效果混合权重 α0.3 最优综合考虑效率纯 Hybrid Search 是更务实的默认选择 。6.2 重排Rerank向量高分并不等于最相关因此需要用更重的模型做精排。常见做法Cross-Encoder把 query-doc 拼在一起联合编码打分代表模型BAAI/bge-reranker-large、Cohere rerank、jina-reranker精度高但算力大可蒸馏为 TinyBERT 或用 FP16/INT8 量化提速。ColBERT延迟交互Late Interaction MaxSim多向量表示兼顾精度与效率。图重排 G-RAG把文档建成图、用 GNN 重排缓解传统排序的信息整合失效、冗余放大、关系盲区三类问题。公开最佳实践给出选型monoT5220M性价比最佳RankLLaMA7B性能最强TILDEv2110M最快每 query 10-20ms适合固定文档集去掉 Rerank 会明显掉点 [公开1]。综述还提到检索后的 Prompt 压缩Selective Context、LLMLingua、Recomp和重排摆放技巧——把最相关文档放在离 query 最近处Reverse repacking 最优以缓解 Lost-in-the-Middle [热1][公开1]。一个 LlamaIndex 生态的 Rerank 调用示例# LanceDB CrossEncoder 重排 reranker CrossEncoderReranker(modelBAAI/bge-reranker-large) results tbl.search(查询语句).rerank(rerankerreranker).limit(5).to_pandas()小结默认配方 向量 BM25 混合召回RRF 融合 Cross-Encoder 精排。召回还差就加 HyDE 或查询改写延迟敏感就把 Rerank 换成 TILDEv2 或蒸馏/量化版。七、生成侧与前沿查询改写、Agentic RAG 与 RAG 2.0一句话结论检索质量的上限往往由 query 表达决定把 Agent 引入 RAG 各环节能做到按需检索、多步检索、自我反思这是 RAG 从固定管道走向自适应系统的关键。7.1 查询改写与 Advanced RAG 检索法检索前处理的目标是让 query 更好被匹配 查询重写Query2Doc、HyDE、STEP-BACK prompting、查询扩展生成多个子查询覆盖不同角度、查询路由关键词/LLM 语义决定走哪条检索链。用 LlamaIndex 阿里云 DashScopeQWEN_MAX, temperature0embeddingTEXT_EMBEDDING_V2chunk_size256给出了 5 种可运行的 Advanced RAG 检索法混合融合检索LLM 生成多查询 → 向量 BM25 → RRF 取 Top-K。重写查询检索LLM 生成多查询 → 仅向量 → RRF比上者少了关键词路。自动合并检索建父/子节点图同父下叶子命中超阈值则合并上升到父节点。小到大块检索小子块建索引做检索命中后把对应父块内容喂给 LLM。句子窗口检索按句子切更细的子块检索后带上下文窗口还原。7.2 Agentic RAGAgentic RAG 的本质是在 RAG 的每个阶段引入 Agent 做决策 。典型流程用户 query → Agent 重写 → 判断是否需要更多信息 → 检索资源 → LLM 响应 → 检查相关性 → 返回或回到改写重来闭环。架构上分单 Agent查询分析器 策略规划器 工具集 反思模块和多 Agent 分层顶层协调 Agent 领域 Agent 工具 Agent通信有中心化与去中心化两种设计 。代表方法有 Self-RAG用反思 token 决定是否检索、Adaptive RAG、FLARE按低概率词触发检索。用给出了一个生产级案例用 MCP Agent 逐步调用db_tool → knowledge_tool → sls_tool定位异步视频任务失败根因其提到的 MCP-ZeroLLM 先假设工具 → RAG 检索真实工具 → 填参执行在 APIBank 评测集上节约 98% token 而准确率基本不变。7.3 Graph RAG 与 RAG 2.0 前沿Graph RAG2024 微软开源在索引期用 LLM 抽取实体与关系构建知识图谱查询时做图遍历擅长跨文档多跳推理与全局主题分析。轻量实现 LightRAG 提供 naive/local/global/hybrid/mix 五种查询模式 。把 2025 年的技术前沿归纳为 RAG 2.0几个值得关注的方向均为论文级、多为单一来源落地成熟度待验证强化学习驱动DeepRAG用 MDP 建模检索决策、CoRAG链式多步检索微软称在复杂推理上达 93% 效果。图神经网络GFM-RAG8M 参数的图基础模型在 7 个领域数据集 zero-shot 超越 HippoRAG 18.9%。多模态ColPali 把图像视为 1024 个图块、降维至 128 维、用 MaxSim 延迟交互、端到端免 OCR基础模型 PaliGemma 3B。安全TrustRAG 用 K-means 聚类 余弦相似度 ROUGE 做两阶段防御应对针对检索库的对抗攻击。小结先把查询改写和混合检索这些确定有效的 Advanced 手段做扎实Agentic/Graph RAG 在多跳、需自适应决策的场景收益明显RAG 2.0 的 RL/GNN 方向前沿但落地样本还少选用前务必自测。八、RAG 评估体系一句话结论RAG 出问题要能分层归因——先分别评检索器找得准不准和生成器答得对不对再做端到端评估RAG 三元组忠实度、答案相关性、上下文相关性是最常用的抓手。评估分两层组件独立评估检索器看 Hit Rate、MRR1/rank、nDCGK、RecallK、PrecisionK生成器看忠实度/事实一致性Faithfulness/Groundedness、答案相关性、流畅度。端到端评估RAG 三元组 扩展Faithfulness答案是否忠于检索到的上下文、Answer Relevance答案是否切题、Context Relevance/Precision/Recall上下文是否相关且齐全再加 Answer Correctness、Harmfulness/Safety。综述还提出 RGB 四能力抗噪声、拒绝无效回答、信息综合、反事实鲁棒性 [热1]。RAGAS 的三步算法原理答案忠实度LLM 把答案拆成陈述逐条检验是否被上下文支撑、答案相关性让 LLM 根据答案反推问题算与原问题相似度均值、上下文相关性筛出与问题相关的句子占比。主流评估框架对比框架特点适用RAGASfaithfulness/answer_relevance/context_relevance/context_recall提示经 LLM 评估通用首选TruLenscontext_relevance → groundedness → answer_relevance 三段可观测/追踪ARES微调 BERT 做评判比直接 LLM 评估快约 10 倍成本低大批量评测DeepEval12 指标、G-Eval、可 pytest 集成工程化回归还有 LLM-as-a-Judge 作为人工评估的替代需注意其偏差。小结先用 RecallK 确认检索有没有把答案捞回来捞不回来是检索问题再用 Faithfulness 确认生成有没有乱编编了是生成问题。别用一个笼统的准确率掩盖真正的瓶颈。九、落地清单与选型建议一句话结论真实业务里 RAG 的收益大头往往不在换更炫的算法而在数据源接入稳定性、向量模型领域微调、以及消除噪声这些脏活。把全文收敛成一份可执行的检查清单先定位再优化用 RecallK 判断检索层、用 Faithfulness 判断生成层别笼统换模型。分块默认递归/语义分块chunk 约 256-512 token、重叠 20Similarity Chunk Ratio 目标 0.85召回缺口大再加语义增强或反向 HyDE。嵌入中文按 CMTEB 选型gte/bge/stella 系垂直领域优先做微调收益最大注意词表与语言覆盖。向量库原型 Chroma/Qdrant生产 Milvus超大规模/成本敏感评估 DiskANN 系。检索向量 BM25 混合 RRF 融合或加权 α≈0.2-0.3 Cross-Encoder 精排延迟敏感用 monoT5/TILDEv。生成查询改写/扩展 COT最相关文档靠近 query 摆放条件推理类用数据模板而非急着上 RL。进阶多跳/全局分析上 Graph RAG需自适应决策上 Agentic RAG前沿 RAG 2.0 方向先小样本自测再推广 。评估闭环RAGAS/DeepEval 建回归集量化每次改动的收益失败实验也留档 。参考来源Gao et al., Retrieval-Augmented Generation for Large Language Models: A SurveyarXiv:2312.10997即热文1的翻译母本https://arxiv.org/abs/2312.10997Searching for Best Practices in Retrieval-Augmented GenerationarXiv:2407.01219RAG 各环节最佳实践与量化对比https://arxiv.org/html/2407.01219v1RAG 原始论文 Lewis et al., 2020arXiv:2005.11401https://arxiv.org/abs/2005.11401StackAI, RAG Best Practices for Enterprise AI: Chunking, Embeddings, Reranking and Hybrid Search https://www.stackai.com/insights/retrieval-augmented-generation-(rag)-best-practices-for-enterprise-ai-chunking-embeddings-reranking-and-hybrid-search-optimizationFirecrawl, Best Chunking Strategies for RAG (and LLMs) https://www.firecrawl.dev/blog/best-chunking-strategies-rag
