RAG真正解决的，不是搜索，而是证据。

你大概率已经遇到过下面这些瞬间。▪你把公司文档全喂给 AI它回答得一本正经但偏偏答错最新版流程。▪你明明知道答案就在那份 PDF 里模型就是死活找不到。▪你把上下文窗口拉到很大成本上去了效果却没稳定变好。▪你以为做RAG就是接个向量数据库结果上线后发现真正难的是切分、排序、权限和评测。▪你看别人 demo 一切正常自己一落地就开始出现答非所问、引用错文档、版本串线。如果用一句不完美但够用的话来定义RAG就是让大模型在回答之前先去外部知识库里翻资料再带着资料回来作答。这个知识点最常见的误解是很多人把RAG理解成给模型外挂一个搜索框。其实不是。搜索只是其中一步真正值钱的是你如何把资料切开、存好、找到、重排、塞回 prompt并保证它在生产环境里稳定工作。我更喜欢把RAG想成给一个很聪明但记忆不可靠的实习生配了一套外脑系统。这个实习生脑子很好推理也不错但他不一定记得你公司昨天刚更新的报销制度。你不能只跟他说自己想。你得先告诉他资料放在哪哪些资料可信查到后怎么引用引用冲突时怎么处理最后怎么把答案写成用户能看懂的话。再换一个类比RAG不是给模型加肌肉而是给模型装图书馆、目录卡、分拣台和引用规则。图书馆没有目录藏书再多也没用。定义与本质1.1 一句话本质定义RAGRetrieval-Augmented Generation检索增强生成是一种在推理时临时引入外部知识的系统架构让大模型不只依赖训练时记住的内容而是能基于最新、私有、可追溯的资料回答问题。1.2 它在更大技术体系中的坐标从技术栈看RAG位于模型能力和业务数据之间。▪上游依赖文档解析、清洗、分块、Embedding、索引、权限模型、数据更新机制▪中间核心查询理解、召回、过滤、重排、上下文组装、答案生成▪下游依赖客服问答、企业知识库、代码助手、研究助手、报表分析、Agent 工具调用如果把整个LLM应用栈看成一条流水线RAG干的是把对的资料在对的时机以对的顺序放到模型眼前。1.3 它到底解决什么问题没有RAG之前世界更像这样。▪模型知识停在训练截止日▪模型不知道你的私有文档▪模型会把相似但不正确的内容脑补成答案▪你很难给出引用来源很难审计很难追责有了RAG之后世界变成这样。▪模型可以回答最新知识不必每次更新都微调▪模型可以利用企业内部资料、产品文档、会议纪要、代码库▪模型回答能尽量贴着证据走而不是只靠参数记忆▪系统可以返回引用、版本、来源和权限边界1.4 RAG 不是孤立选项它总在和别的方案比较方案知识更新一次性成本单次调用成本可解释性适合什么问题纯 Prompt手工改提示词低低低简单格式化、固定任务RAG更新文档并重建索引中中高知识密集型问答、企业资料问答微调重新训练或继续训练高中中风格、结构、行为稳定化长上下文直塞直接把大量资料丢进 prompt低高中小规模、一次性、深度整文分析这里面最容易想明白的一点是RAG主要解决知识接入问题微调主要解决行为塑形问题。两者不是敌人很多生产系统是一起用的。1.5 不同流派对 RAG 的理解差异今天业内对RAG至少有三种常见理解。▪狭义RAG只要是检索相关片段再拼到 prompt 里就算RAG▪工程RAG强调完整链路包括索引、重排、权限、评测、监控▪Agentic RAG把检索看成一个动态决策过程模型会主动改写查询、拆子问题、多轮找证据狭义理解适合入门工程理解适合落地Agentic 理解适合复杂任务。很多争论其实不是谁对谁错而是大家讨论的根本不是同一个层级。端到端流程RAG 真正难的地方不在你知道有多少组件而在你明白每一步错了会带来什么连锁反应。2.1 一条完整链路步骤输入输出关键决策点常见误区1. 数据接入PDF、网页、数据库、代码仓库可解析内容用什么解析器保留哪些结构只抽正文丢掉标题、表格、版本等上下文2. 内容清洗原始文本结构化文本去噪程度、保留元数据把页码、标题、来源、更新时间一并清掉3. 分块 Chunking长文档若干 chunk块大小、重叠比例、按结构还是按长度切固定按字符切导致句子和语义断裂4. 向量化Embeddingchunk向量选什么 embedding 模型是否分域拿通用 embedding 硬打专业语料5. 建索引向量和元数据可检索知识库向量库选型、是否加BM25、元数据字段只有向量没有关键词和过滤条件6. 查询预处理用户问题检索查询改写、拆问题、时间过滤、权限过滤把用户原话直接拿去查完全不做理解7. 召回与重排查询 索引Top-K 证据相似度、混合检索、rerank、去重只看相似度分数不看证据是否真的可回答8. 上下文组装检索结果prompt context顺序、压缩、截断、引用格式一股脑塞 20 段关键证据埋在中间9. 生成与校验query context最终答案引用、拒答、置信度、事实校验生成后不做 groundedness 检查10. 反馈与评估用户反馈、日志迭代信号评测集、线上反馈、错误归因只盯最终满意度完全不知道哪一层出了错2.2 一步做错后面会发生什么▪数据接入错了后面检索再聪明也只能在坏资料里选最像的错答案▪分块错了最常见的后果是证据被切碎模型拿到的是半句话和半段上下文▪Embedding选错了召回会看起来相关实际答不对▪没有元数据过滤系统很容易把 2023 版制度答成 2026 版▪没有重排最关键的一段可能排在第 7 个位置然后被大模型忽略▪没有评测闭环你只能知道用户不满意但不知道是切块、检索还是生成的问题2.3 一个极简伪代码def answer(query):query_v2 rewrite(query)candidates hybrid_retrieve(query_v2, top_k20, filters{“tenant”: “A”})ranked rerank(query_v2, candidates)[:5]context pack_context(ranked)response llm.generate(queryquery, contextcontext, require_citationsTrue)return validate(response, ranked)这个伪代码看着简单但里面已经藏了RAG的四个核心动作找什么、从哪找、按什么顺序给、答完怎么兜底。底层原理3.1 先讲直觉不先讲公式RAG的直觉非常朴素。大模型像一个读过很多书的人但不是一个随时都记得精确页码的人。你问他一个问题他可能有印象也可能模模糊糊。RAG做的事就是先帮他从资料堆里翻到几页可能有答案的证据再让他基于这些证据整理成自然语言。所以RAG的关键不是让模型知道更多而是让模型在有限注意力里看到更相关的东西。3.2 为什么不是所有资料都直接塞给模型因为上下文窗口再大也不等于利用率就高。在当前公开实践里有几个很有代表性的信号。▪Anthropic 在介绍Contextual Retrieval时提到如果知识库小于约 200,000 tokens大约 500 页左右材料很多时候可以直接整库放进 prompt再配合 prompt caching速度可提升到原来的 2 倍以上成本最多可下降约 90%▪但一旦知识库变大纯长上下文就会遇到成本高、延迟高、噪音多的问题▪一些 2025-2026 年的工程讨论里RAG相对长上下文在典型问答负载下常被估算为便宜一个数量级个别案例给到 8-82 倍的成本差这就像考试时开卷。你把整本书都摊开不代表你就更容易答对。真正有用的是先翻到可能的章节再定位关键段落。3.3 三个最常见的数学工具3.3.1 向量相似度向量检索最常见的是余弦相似度。cos(q, d) (q · d) / (||q|| * ||d||)▪q是查询向量▪d是文档向量▪分数越接近 1通常表示语义越接近它解决的是用户明明没说文档里的原词但意思很像也能找出来。3.3.2 BM25BM25更像关键词老将擅长精确词匹配。score(D, Q) Σ IDF(q_i) * (f(q_i, D) * (k1 1)) / (f(q_i, D) k1 * (1 - b b * |D| / avgdl))你不用死记公式知道两件事就够了。▪它更擅长错误码、产品名、SKU、专有名词、时间编号这种精确匹配▪它会考虑词频和文档长度不是简单的出现次数统计3.3.3 MMR 重排如果只按相似度取前 5 条常常会取回 5 段非常像的内容信息高度重复。MMR的直觉是既要相关也要多样。MMR argmax [lambda * Sim(query, doc) - (1 - lambda) * max Sim(doc, selected)]它做的事像组会邀请人既要请最懂这个话题的人也别请五个讲同一件事的人。3.4 为什么用 A不用 B比较项AB为什么经常选 A检索方式混合检索纯向量检索混合检索同时照顾语义相似和精确关键词分块方式按结构切块固定长度硬切结构化切块更少断义尤其适合文档、Wiki、手册结果顺序原文顺序重排纯按相似度排序原文顺序更连贯长上下文阅读效果更稳生成方式带引用回答无引用自由回答更易审计也更容易发现错在哪3.5 真懂 RAG 的人最在意的细节细节 1检索正确不等于答案正确你把对的 chunk 取回来只说明召回可能没问题不代表模型会用也不代表它不会混着自己的先验乱答。细节 2召回率和精确率要平衡RAG不是永远追求更准。有时你得先保证把答案所在片段放进来也就是先保召回再靠重排和压缩去降噪。细节 3顺序真的很重要Stanford 在 2025 年一篇对比多阶段RAG的研究里指出简单的 DOSRAG也就是先检索再按原文顺序重排在多个长文问答基准上能稳定匹配甚至超过更复杂的多阶段方法。一个典型数字是在 InfinityBench 的 30K token 预算下DOSRAG达到 93.1%高于 VanillaRAG的 87.8%这个结论特别有意思。它告诉你复杂不一定更强很多时候只是更贵、更慢、更难调。分层次展开RAG不是一个点而是一个从微观到宏观逐层展开的系统。4.1 第一层Chunk 层这里关心的是一小段文本到底怎么切。▪定义把长文拆成适合检索和拼接的最小工作单元▪实例FAQ 常从 200-500 tokens 起步技术文档常从 400-800 tokens 起步重叠通常在 10%-20%▪优势命中更精确成本更低▪局限切太碎会丢上下文切太大又会引入噪音▪适用条件问题答案通常集中在局部片段4.2 第二层Document 层这里关心的是一整篇文档怎样被表示。▪定义不只保存 chunk 文本还保存标题、章节、来源、更新时间、版本、租户、权限▪实例一条 chunk 记录里除了正文还会带doc_id、section_title、updated_at▪优势便于过滤、版本控制和引用回溯▪局限元数据设计差会导致检索虽快但不准▪适用条件多版本、多团队、多租户知识库4.3 第三层Retriever 层这里关心的是怎么找。▪定义从索引里把候选证据召回出来▪实例向量检索、BM25、混合检索、图检索▪优势能针对不同查询类型做差异化策略▪局限错误往往隐蔽看起来像相关实际上答不出▪适用条件知识库规模大于单次上下文窗口4.4 第四层Context 层这里关心的是怎么喂。▪定义把召回结果整理成模型最容易用的上下文▪实例去重、重排、压缩、保留原始顺序、在前后放最关键证据▪优势直接影响最终回答质量▪局限太贪心会塞满噪音太保守又会漏证据▪适用条件大模型上下文敏感且有 lost in the middle 风险4.5 第五层Product 层这里关心的是怎么让用户可用。▪定义RAG不再是检索实验而是一个产品能力▪实例客服机器人返回引用来源代码助手返回文件路径知识库机器人按权限过滤▪优势更可信更可审计▪局限牵扯权限、日志、反馈闭环复杂度上升▪适用条件真的要上线给用户用4.6 层级对比表层级主要对象核心问题做好了的表现做差了的表现Chunk 层单段文本怎么切召回精准信息完整断句、断义、错过答案Document 层文档与元数据怎么组织过滤准确引用清晰版本串线权限混乱Retriever 层召回器怎么找相关内容能被找回找得像但答不对Context 层prompt 上下文怎么喂证据顺序合理模型能用关键证据埋没在中间Product 层用户体验与治理怎么上线可追踪、可回放、可迭代只有 demo没有系统如果你只在某一层努力RAG很容易看起来做了很多最后还是不稳定。真正成熟的系统五层都得看。主流方案与实现对比5.1 架构方案对比方案核心思路适用规模优势劣势什么时候不该选Naive Vector RAG向量召回后直接拼 prompt小到中型知识库快速起步工程量小对精确词、版本、噪音处理差文档版本多、关键词很重要时Hybrid RAG向量 BM25 过滤中到大型知识库兼顾语义和关键词调参更多语料非常单一、问题极简单时Contextual Retrieval给 chunk 补上下文再做检索复杂长文档召回更稳预处理成本高文档简单短小、召回已足够时Agentic RAG多轮拆问题、改写、验证复杂任务、多跳推理复杂问题表现更好延迟和成本明显上升低延迟客服、预算极紧时Long Context Retrieve先检索缩小范围再长上下文深读大文档深分析兼顾召回和整文推理编排复杂高频短问答场景这里面一个特别值得注意的数据是Anthropic 在Contextual Retrieval的介绍里给出过非常醒目的提升。▪只做 contextual embeddings失败检索率可下降约 35%▪contextual embeddings 加 contextualBM25失败检索率可下降约 49%▪再叠加 reranking可下降约 67%这个数字不是说你一上来就必须做Contextual Retrieval而是提醒你很多所谓模型不会答问题其实出在检索前的表示方式。5.2 向量存储与实现工具对比工具/方案部署方式优势劣势适合谁pgvectorPostgreSQL 扩展和现有业务库整合方便权限和事务模型熟大规模纯向量性能不如专业库已有 Postgres 团队Qdrant自建或托管过滤和 payload 设计友好生态成熟需要额外维护中大型业务Pinecone托管上手快运维轻供应商绑定感更强想快速上线的团队Weaviate自建或托管向量 schema 搜索能力完整学习成本稍高做复杂语义搜索的团队Chroma本地或轻量部署简单适合原型生产能力有限Demo、PoC、个人项目5.3 一个很实用的选型判断▪先做原型用Chroma或本地 FAISS 都行目标是跑通链路▪要和现有业务权限、审计、事务深度结合pgvector很顺手▪要做中大型线上服务Qdrant、Pinecone、Weaviate更常见5.4 正向选型与反向排除▪如果你的问题里有大量错误码、型号、合同编号别只上纯向量混合检索几乎是默认项▪如果你的知识库只有几十篇文档而且单次问答低频先别急着建复杂RAG长上下文直塞可能更省事▪如果你的业务强依赖权限边界别用一个只会相似搜索、不会做严肃过滤的轻量方案▪如果你的任务大量涉及多跳推理别指望单轮 top-k 检索就永远够用至少准备 query rewrite 和 subquery 能力5.5 一个最小实现骨架retriever HybridRetriever(dense_indexvector_db,sparse_indexbm25_index,metadata_filters[“tenant”, “version”, “doc_type”],)pipeline (QueryRewriter()retrieverReranker(top_k5)ContextPacker(max_tokens6000)GroundedGenerator(citationsTrue))你会发现真正决定上限的往往不是最后那个GroundedGenerator而是前面几层。局限性与常见陷阱RAG绝对不是装上就灵。6.1 常见坑点总表陷阱典型场景为什么会出现实际后果缓解方案切块太机械50 页 PDF 直接每 500 字切一刀只图简单忽略语义边界答案上下文断裂按标题、段落、表格结构切块缺失元数据多版本制度文档共存只存正文不存版本时间答到旧政策存version、updated_at、source只做向量不做关键词查询含报错码、SKU、专有名词误以为向量万能找到相似概念错过精确答案加BM25或 exact matchTop-K 太贪心一次塞 20 个 chunk想提高召回忽视噪音模型答非所问lost in the middle先召回更多再重排压缩到 3-8 段只看最终答案不测检索团队只盯满意度缺乏阶段化评测出错不知道该修哪分开测 recall、precision、groundedness权限没收紧多租户知识库检索层没做权限过滤串租户泄露资料过滤前置不要只在生成后遮盖6.2 五个最容易被低估的问题问题 1检索像不等于可回答很多 chunk 和问题语义接近但没有回答所需的关键事实。这会让系统看起来很聪明实际上只是在拿边缘信息糊用户。缓解方式给检索结果做 answerability 判断至少做 rerank不要只盯 cosine score。问题 2重叠不是越多越好很多人听说 overlap 能保上下文于是一路加到 30%、40%。结果索引体积暴涨重复召回严重最后 prompt 里充满长得差不多的段落。工程上更常见的起点是 10%-20%不够再调。问题 3版本漂移比幻觉更要命幻觉是胡编版本漂移更阴。它答的每句话都像真的甚至引用也是真的只不过引用的是旧版本。这种错比胡说更难被发现。问题 4RAG 不是数据库RAG很适合问文本证据型问题但不适合所有精确计算型问题。比如精确库存、实时报表、余额这类问题很多时候更应该走 SQL、API 或工具调用而不是让RAG硬答。问题 5复杂方案不一定更好Stanford 那篇 DOSRAG研究给人的提醒特别强很多时候保留原文顺序、用更强 embedding、控制好上下文预算比引入多层摘要树和多轮 agent 更划算。所以别迷信花活先把强基线打稳。优化策略与最佳实践下面这些策略基本都是真正能拉开线上效果差距的点。7.1 优化策略表策略核心思路具体做法预期效果适用条件成本级别结构化切块先尊重文档结构再考虑 token按标题、段落、表格、代码块切召回更完整断义更少文档有明显结构 低成本混合检索语义和关键词一起查向量 BM25 metadata filter精确词召回明显变好错误码、型号、版本多 中等成本Rerank 压缩先多找再精选再压缩Top20 召回重排到 Top5再做压缩降噪减少 lost in the middle中大型知识库 中等成本Contextual Retrieval给 chunk 补局部背景为每个 chunk 生成上下文摘要并联合检索复杂长文档召回更稳语义依赖强chunk 易失真 高成本高回报Query Rewrite / HyDE先把问题改写成更好检索的形态扩缩写、补实体、生成假想答案向量模糊问题更好找用户问题口语化、歧义多 中等成本评测闭环不只看最终回答建 gold set线上回放分阶段打分能定位问题层需要长期迭代 中等成本7.2 哪些优化最先做如果你资源有限优先级我会这么排。结构化切块 元数据混合检索Rerank评测闭环Query rewriteContextual Retrieval或Agentic RAG这个顺序的逻辑很简单。先修地基再修路再谈自动驾驶。7.3 几个很值钱的经验▪技术文档里标题和小节名经常比正文还重要别在清洗阶段扔掉▪FAQ、政策制度、帮助中心这类内容parent-child 或 Small2Big 往往很有效小块召回大块补全▪对代码和配置文件问答纯 semantic search 往往不够lexical 检索非常重要▪对多轮对话类RAG先处理会话摘要不然旧上下文会慢慢腐烂7.4 一个很多团队都会踩的错觉很多团队会觉得Embedding模型升级一版效果就该明显提升。实际常常不是这样。RAG的瓶颈可能根本不在 embedding而在切块、过滤、顺序、权限、评测。就像厨房里做菜不好吃你换一把更贵的刀不一定先解决问题。工程落地与生产实践RAG一旦进入生产问题会从模型效果迅速转向延迟、成本、权限、更新和可观测性。8.1 性能与延迟简单RAG的体验目标通常不是绝对最强而是足够快。▪问答型应用首 token 常希望控制在 2-5 秒内▪如果加入 query rewrite、rerank、多轮搜索延迟很容易上升数百毫秒到数秒▪高频场景下比模型参数更重要的常常是缓存命中率和检索层效率很现实的一点是用户能容忍一个偶尔答得一般但 2 秒出结果的系统不一定能容忍一个 15 秒后才给高质量答案的客服机器人。8.2 成本控制RAG的成本大头通常分成三类。▪离线成本Embedding和建索引▪在线成本查询 embedding、检索、rerank、LLM生成▪隐性成本重建索引、日志、评测和人工标注一个很实用的成本判断是。▪文档小更新少查询低频可以考虑长上下文直塞▪文档大查询高频更新频繁RAG更容易摊薄成本8.3 更新与迭代策略Microsoft 的生产RAG指南里把更新策略讲得很明确真实系统不能只做全量重建。▪增量更新适合每天都有少量新增▪触发式更新适合文档修改后立即生效▪选择性重建适合局部变更▪版本快照适合需要回溯和审计如果你问我一句最朴素的建议就是别把索引当一次性产物要把它当持续演进的数据资产。8.4 监控与兜底监控项说明常见阈值或观察方式兜底思路检索命中率gold evidence 是否进入 Top-K看 Top3、Top5、Top10调 chunk、query rewrite、混合检索引用覆盖率最终回答是否给出来源按回答类型分桶看无法引用时主动拒答Groundedness回答是否真的基于证据LLM-as-judge 人工抽检低分触发重答或退回搜索延迟检索和生成各层耗时P50、P95、P99缓存、降级、少一步 rerank权限过滤命中是否发生越权候选被召回审计日志过滤前置严格 tenant isolation用户反馈点踩、追问、复制率线上埋点回放失败请求补评测集8.5 安全与权限这块真的不能偷懒。▪权限过滤要前置到检索阶段不要等答案生成后再挡▪多租户环境必须把 tenant id 当成第一层过滤条件▪文档中涉及敏感字段时建议在入库前做脱敏或分级▪记录引用来源时也要确保来源本身对当前用户可见8.6 高可用与扩展性大多数RAG系统真正的压力点不是大模型而是索引服务和更新链路。▪热点知识库可以做分片和缓存▪查询高峰时要有降级策略比如关闭昂贵 rerank只保留混合召回▪更新链路和在线检索最好解耦避免重建索引拖慢在线查询一句话总结生产实践RAG不只是让模型答对还要让它持续、稳定、合规地答对。进阶形态与相关延伸RAG这两年最有意思的变化不是它消失了而是它分化了。9.1 常见进阶版本▪Multimodal RAG不只检索文字也检索图片、图表、版面和表格▪Graph RAG把实体关系和图结构引入检索▪Agentic RAG让模型主动规划检索策略和多轮求证▪Contextual Retrieval给 chunk 添加局部上下文再检索▪Hybrid Memory用RAG先缩小范围再用长上下文做深读9.2 对比表版本解决什么痛点优势劣势什么时候值得上基础RAG私有知识接入简单、稳定、成熟对复杂多跳问题有限FAQ、帮助中心、制度问答Multimodal RAG图表/版面/截图无法纯文本理解能处理图文混合资料成本高解析复杂财报、论文、技术手册、UI 文档Graph RAG实体关系复杂对关系推理更强图构建昂贵法务、风控、知识图谱类场景Agentic RAG多跳问题、模糊问题复杂问题更强延迟和成本高研究助手、复杂分析Hybrid Memory大库 长文深读平衡范围和深度编排复杂代码库、报告深分析9.3 基础版什么时候就够了下面这些场景基础RAG往往已经很能打。▪帮助中心▪内部制度查询▪售后知识库▪产品文档问答▪中小规模企业内部助手9.4 什么时候该上进阶版▪文档里大量答案藏在表格、图片和版面关系里上Multimodal RAG▪问题需要跨实体、跨文档、跨层级关系推理上Graph RAG▪用户问题非常模糊还经常要分解、追问、验证上Agentic RAG▪需要读整段长文逻辑又不能每次把全库塞进上下文上Hybrid Memory9.5 什么情况下属于过度设计▪你还没做基本评测就先上多 agent 检索▪你 FAQ 只有 200 篇却上图检索、树摘要、知识图谱三件套▪你的主要问题是版本没过滤却试图靠更复杂的 embedding 去解决这类过度设计本质都一样问题还没定位方案已经失控了。核心 Takeaways 与深度追问10.1 如果只记住三句话RAG不是搜索外挂而是一整套把证据送到模型眼前的系统工程。生产RAG的瓶颈通常不在模型本身而在切块、过滤、重排、权限和评测。更复杂的RAG不一定更强先把强基线打稳很多时候已经能赢过花哨架构。10.2 深度追问概念理解类为什么RAG不能彻底消灭幻觉RAG只是提高证据供给质量不保证模型一定正确使用证据也不保证检索永远无误。为什么很多RAG系统答错不是因为模型笨常见根因在检索层尤其是切块、版本过滤和上下文组织。为什么长上下文没有杀死RAG长上下文解决的是装得下不是一定用得好。成本、延迟、噪音和注意力稀释仍然存在。技术选型类什么时候优先用RAG什么时候优先微调知识更新和可追溯需求强时优先RAG风格和行为稳定化时优先微调。什么时候必须做混合检索用户问题里常出现错误码、产品号、专有名词、版本号时混合检索几乎是默认项。pgvector、Qdrant、Pinecone怎么选看团队基础设施、权限要求、规模和运维能力不存在统一最优。工程实践类chunk size 到底怎么定没有银弹通常从 300-800 tokens 起步结合文档类型、问题粒度和评测结果迭代。Top-K 是不是越大越好不是。一般是先多召回再重排压缩。直接给太多 chunk 容易噪音淹没证据。RAG该怎么评测分阶段评测至少拆成 retrieval、rerank、grounded generation 三层不要只看最终答案满意度。边界场景类RAG能回答实时数据库问题吗不推荐只靠RAG。精确实时值更适合走 API、SQL 或工具调用。RAG能处理图片和表格吗纯文本RAG很有限需要 OCR、版面理解或Multimodal RAG。Agent 一定要配RAG吗不一定。小范围任务、明确上下文、低频一次性分析时长上下文也可能够用。但一旦涉及大知识库、私有资料、重复查询RAG的价值会快速变大。如果把这部分再压缩成一句特别接地气的话就是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%免费】