RAG

先说一个反直觉的数字:80% 喊着「我们要微调」的需求,换个更好的检索就解决了。 这是 2026 年做过几轮项目后,业内基本形成的共识。但凡你想让一个通用大模型「答对你自己的事」——公司的产品文档、内部规章、某个客户的历史订单——你大概率会在三条路里纠结:RAG(检索增强)、微调、长上下文(直接把材料塞进 prompt)。 这三条路经常被拿来对比,但很多对比都在装中立,列个表说「各有优劣,看场景」。这篇不装。它们不是平级的选项,它们解决的根本不是同一个问题。选错那条,代价不是「效果差一点」,而是要么每个月烧掉本不该烧的钱,要么半年后你的数据全过期、整个系统没人敢碰。 它们到底各自在解决什么 把这件事想清楚,后面就不纠结了。 RAG:模型不知道答案,你临时把答案找出来递给它。模型本身不变,变的是每次喂给它的上下文。 微调:你改的是模型本身的权重。让它换一种说话方式、固定输出某种格式、养成某种行为习惯。 长上下文:你不做检索、不做训练,直接把所有相关材料一次性塞进 prompt,让模型自己在里面找。 注意区别:RAG 和长上下文都是在「给模型补知识」,区别只是补的方式——一个精挑细选地补,一个一股脑全塞。而微调压根不是在补知识,它在补能力和行为。这是最常见的认知错位:有人想让模型「记住公司有 300 条规章」,跑去微调,结果训完发现模型还是答不准,因为微调不是用来塞事实的。 一句话记牢:知识用 RAG,行为用微调,长上下文是知识量小到不值得搭管道时的偷懒办法。 RAG:知识会变、要溯源,就选它 RAG 是 2026 年绝大多数团队的默认起点,理由很硬:它便宜、上线快,而且能干那件最常见的事——让模型回答关于你自家数据的问题。 它的真正杀手锏是另外两个: 知识能随时更新。 产品改了价、规章出了新版,你只要更新向量库里那几条,模型下一秒就用新的了。不用重训、不用重新部署。对任何一个数据会变的业务,这一条几乎是决定性的。 答案能溯源。 模型说「退款政策是 7 天」,你能指着它后面挂的那条文档说「依据在这」。金融、医疗、法律这类场景,「答得对」还不够,你得能证明它为什么这么答。微调和长上下文都给不了这种可追溯性——微调把知识熬进了权重里,你根本说不清它从哪学的。 但 RAG 不是免费午餐,2026 年的现实是:当 RAG 出错,73% 的锅在检索,不在生成。 模型没胡说,是你压根没把对的文档捞给它。所以现代 RAG 早就不是「embedding + 余弦相似度」那么简单了,一条能上生产的管道长这样: flowchart LR A[文档] --> B[语义切块] B --> C[向量库] D[用户提问] --> E[混合检索向量 + BM25] C --> E E --> F[Rerank取 Top 5-10] F --> G[LLM 生成] 几个关键点,踩过坑的都懂: 切块是默默崩掉 RAG 的地方。 切得太碎,一个 chunk 答不全一个问题;切得太大,塞进去全是噪音。语义切块(按 embedding 相似度找话题边界)比固定字数切块靠谱得多。 混合检索基本是标配了。 纯语义检索会漏掉「精确匹配」——比如某个型号编号、某个专有名词。把向量检索和 BM25(关键词)拼起来,准确率明显更稳。 Rerank 是那勺秘制酱。 先用混合检索捞 100 条候选,再用一个 cross-encoder 重排序模型(Cohere Rerank、BGE-Reranker 这类)精筛出 5-10 条真正喂给大模型。这一步加上,系统会从「有时有用」变成「能上生产」。 代价是:你得维护一整套数据管道——切块、embedding、向量库、rerank,每一环都能出问题。RAG 上线快,但养着它不轻松。 ...

给你的知识库问一个问题:“我们去年 Q3 的退款政策,跟今年比有什么变化?” 朴素 RAG 会怎么做?它把这一整句话拿去向量库里查一次,取回 5 个最相似的片段,塞进 prompt,让大模型生成。结果大概率是:它检索到了"今年的退款政策",但没检索到"去年 Q3 的",因为这句话作为一个整体,语义上离"今年的政策文档"更近。于是模型用今年的政策,回答了一个关于"变化"的问题——而且它不会告诉你它只看到了一半。 这就是朴素 RAG 的根本毛病。它把检索当成一个一次性的、无脑的前置步骤:查一次,查到什么算什么,然后生成。它不会判断"我查到的东西够不够",不会发现"这个问题其实要查两次",更不会在检索失败时重来。它失败的时候不会报错,会编。 2026 年,生产环境里真正能扛住复杂问题的,已经不是这条流水线了。这篇讲清楚它怎么一步步长成 Agentic RAG,以及——这是重点——多出来的延迟和成本,什么时候值,什么时候是浪费。 朴素 RAG 到底卡在哪 先把它失败的几类问题说具体,不然后面所有"改进"都是空的。 多跳问题。“写《三体》的作者还写过哪些小说?"——这要先查”《三体》的作者是谁"(刘慈欣),再用这个答案去查"刘慈欣的其他作品"。一次检索拿不到第二跳需要的关键词,因为第二跳的查询词(“刘慈欣”)根本不在原始问题里。 **模糊 / 措辞错位。**用户问"那个会自动重试的配置项叫什么",知识库里写的是"retry_policy 重试策略"。用户的口语和文档的术语对不上,向量相似度也救不回来。 问题里藏着多个子问题。“对比一下 A 方案和 B 方案的成本和上线周期”——这是四个检索意图揉在一句话里,一次检索只会取回一堆"半相关"的片段,哪个都不深。 需要计算或外部数据。“我们这个季度的获客成本环比涨了多少”——答案不在任何一个文档片段里,它需要先取两个数,再算个除法。文本检索给不了。 这些问题的共同点是:正确答案不是"检索一次就能拿到的那 5 个片段"。要么得检索多次,要么得换个查法,要么检索根本不是最后一步。朴素 RAG 的架构里没有"再来一次"这个动作,所以它只能在第一次的结果上硬生成。 演进的主线:从「流水线」到「控制循环」 把朴素 RAG 和 Agentic RAG 摆在一起看,差别不是"加了几个模块",是控制权交给了谁。 朴素 RAG 是一条固定流水线:检索 → 生成,顺序写死,模型只负责最后那步生成,没有决策权。 Agentic RAG 是一个控制循环:大模型坐在中间当指挥,它拿到问题后自己决定下一步干什么——要不要检索、检索什么、查到的东西够不够、要不要换个查询词再来一次、还是已经可以回答了。检索从"前置步骤"变成了模型手里的一个工具,跟计算器、SQL 查询、API 调用平级。 flowchart TB subgraph naive[朴素 RAG:固定流水线] direction LR Q1[问题] --> R1[检索一次] --> G1[生成] --> A1[答案] end subgraph agentic[Agentic RAG:控制循环] direction LR Q2[问题] --> AG{Agent决策} AG -->|要查| R2[检索/改写/计算] R2 --> EV[评估结果够不够?] EV -->|不够| AG EV -->|够了| G2[生成] --> A2[答案] end style AG fill:#fde7c2,stroke:#e8b23c style EV fill:#fde7c2,stroke:#e8b23c 橙色的两块——决策和评估——是朴素 RAG 里完全没有的。整个演进,本质上就是把这两个能力一点点加进来。下面拆成四个阶段讲。 ...

三年前做一个带检索的 AI 功能,默认动作是去注册一个 Pinecone,或者在 k8s 上拉起一套 Milvus。“做向量检索就得有向量数据库”,这是当时的常识。 2026 年我不会这么干了。我现在的默认动作是反问一句:你的业务数据是不是已经在 Postgres 里了? 如果是,那大概率你不需要再多一个数据库——装个 pgvector 扩展就够了。 这不是图省事。这两年向量检索这个领域发生了一件挺反常识的事:专用向量数据库的护城河,被"在已有数据库里加一个向量列"这件事填掉了一大半。 这篇就讲清楚这件事是怎么发生的,以及——什么场景下你还是真的需要一个专用的。 向量检索这两年变了什么 先说结论:向量检索从"一项需要专门系统的黑科技",退化成了"一种索引类型"。 2022、2023 年的时候,向量检索确实特殊。HNSW 索引怎么建、近似最近邻(ANN)怎么调参、召回率和延迟怎么权衡,这些都是新东西,通用数据库根本不支持。你想做语义检索,除了上专用向量库没有别的选择。专用向量库的价值,很大程度上来自于"别人还做不了"。 到 2026 年,情况倒过来了。HNSW 这种图索引已经是成熟、公开、被反复实现的算法,不再是谁家的秘密。pgvector 作为 Postgres 扩展,把 HNSW 和 IVFFlat 索引、多种距离度量、半精度存储这些都做齐了;0.8 版本之后还补上了"迭代索引扫描"(iterative index scan),专门解决带过滤的向量查询里那个老大难问题——后面会细讲。 换句话说,“做向量检索"这件事本身,已经不构成开一个新数据库的理由了。 它现在更像是"我需要一个 JSON 字段"或者"我需要全文检索”——你的现有数据库基本都能干,只是早几年还不行。 专用向量库不是没价值了,而是价值的位置变了:它不再赢在"能不能做",而是赢在"做到什么规模、做得多快、过滤多复杂"。这是一个量变到质变的边界问题,而不是一个有无问题。 pgvector 为什么吃掉了大半场景 把向量检索塞进 Postgres,带来的好处不是"少装一个软件"这么肤浅。真正值钱的是下面三件事。 第一,数据不用搬,事务是一致的。 绝大多数 AI 功能不是孤立的——一段文档的 embedding,总是挂在某个用户、某个项目、某个权限边界下面。如果向量在专用库、业务数据在 Postgres,你就得自己维护两套数据的同步:文档删了,向量要跟着删;权限变了,检索结果要跟着变。这套同步逻辑写起来不难,但它是一类永远会出 bug 的胶水代码——双写失败、顺序错乱、补偿任务追不上。向量和业务数据待在同一个 Postgres 事务里,这一整类问题直接不存在。 第二,过滤就是普通的 SQL WHERE。 “找语义相近的文档,但限定这个用户、这个时间段、状态是已发布”——这种带元数据过滤的检索是 RAG 里的常态,几乎没有哪个真实业务是纯粹的全库 ANN。在 pgvector 里,这就是一条 SQL,WHERE 子句和向量排序写在一起,还能直接 JOIN 业务表。在专用向量库里,过滤得靠它自己那套 payload/metadata 过滤机制,表达能力通常比 SQL 弱,跨"表"的关联更是做不了。 ...

RAG是什么 一句话：先查资料，再回答问题。 大模型直接回答问题容易编造内容。RAG让它先从你的知识库里找到相关内容，再基于这些内容回答。 1 用户问题 → 搜索知识库 → 找到相关文档 → 喂给LLM → 生成答案 最简实现 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 from langchain.vectorstores import Chroma from langchain.embeddings import OpenAIEmbeddings from langchain.chat_models import ChatOpenAI # 1. 把文档切块并存入向量数据库 docs = load_and_split_documents("./docs") vectorstore = Chroma.from_documents(docs, OpenAIEmbeddings()) # 2. 检索相关内容 retriever = vectorstore.as_retriever(k=3) relevant_docs = retriever.get_relevant_documents("什么是RAG？") # 3. 生成答案 llm = ChatOpenAI() answer = llm.invoke(f""" 根据以下内容回答问题： {relevant_docs} 问题：什么是RAG？ """) 就这么简单。30行代码就能跑起来。 ...