RAG
检索增强生成
在运行时把相关上下文注入 LLM Prompt，这些上下文来自你自己的数据，让模型基于你的知识回答，而不是它训练数据里的知识。
RAG 是让 LLM 能回答它没被训练过的数据相关问题的架构。机制很直接：拿用户的问题，从你的语料里检索出最相关的片段（通过向量检索、关键词检索，或一种混合），把它们塞进 Prompt，让模型回答。它是大多数有用的 AI Agent 底下的那层接地。
RAG 之所以存在：用你的私有数据训练一个模型既贵又慢，而且你的数据一变它就过时。RAG 通过把数据当作运行时上下文来回避这一点。代价是检索质量成了瓶颈：一个拿到坏上下文的模型会自信地产出错误答案。
经典失败，举个实际例子：一家公司在它的帮助文档之上构建了一个客服机器人，Demo 令人印象深刻，然后在生产中它自信地引用了错误的退款政策。本能反应是怪模型并试一个更大的。答案依旧错，因为问题在上游：文档在句子中间被切块，Embedding 分不清「退款」和「退货」，而且没有一个 Reranker 把正确的段落推到顶部。换上更好的切块、混合搜索和一个 Reranker，同一个模型突然就显得聪明了。这个教训可以推广：当 RAG 出错时，几乎每次都先怀疑检索，再怀疑生成。
诚实的取舍以及 RAG 崩溃的地方：它在「能从少数几个段落里回答的查找式问题」上表现出色，而在「答案需要跨许多文档综合、或需要调和语料里的矛盾」时退化。到那个点上，你要的是一个更小的精选语料、一条逐步推理的 Agent 式流水线，或微调，而不是一个更大的检索器。不性感的真相是：80% 的工作是把检索做好（切块、Embedding、Rerank、混合搜索），20% 才是模型。把你的数据源封装成 MCP 服务器会让检索层可移植，但不会让它变好。把 RAG 当作一键式功能来卖的供应商，卖的是容易的那一部分。