很多人对 RAG 的第一印象，仍然停留在一张非常简洁的架构图里：前端负责提问，后端负责调度，向量库负责检索，大模型负责回答。这张图当然没有错。它适合解释 RAG 的基本原理，也足够让人快速理解“检索增强生成”这件事。但问题在于，一旦系统从 Demo 走向真实业务，这张图就开始不够用了。

对于小模型，单机单卡或者单机多卡就能满足推理的部署需求，比如Qwen-32B，模型权重文件大概64G，单个H20的显存有96G，所以单卡就可满足。

某企业法务团队上线了一套合同问答系统。用户问："渠道商季度返点的计算条件是什么？"系统返回了三段参考文档，生成了一段看起来完整的回答。法务审核时发现：引用的是 2024 年旧版渠道政策，而 2026 年新版政策已经在知识库里了——只是被排在第 8 条结果，没有进入最终送给模型的上下文窗口。

Token 是 AI 处理信息的最小原子单元，也是算力消耗、成本计价、产业竞争的核心标尺——算力的核心就是 Token 吞吐量。

这两年，我聊过很多想转 AI 的产品经理。有人做了 5 年传统 PM，突然发现岗位描述里全变成了 Agent、Copilot、RAG、多模态。

2026年2月，OpenAI发了一篇博客，悄悄重新定义了软件工程师的日常工作。标题只有两个词： **"Harness Engineering"** 。

最近刷到一篇来自上交大和中科院团队的综述，发表于2026年4月，题目叫 *Externalization in LLM Agents*，说的是一个很有意思的视角：**大模型Agent的核心进化，不是在把模型做得更大，而是在把认知负担一件一件地"搬出去"。

RAG 系统上线后答案出错，绝大多数团队的第一反应都是换更贵的模型、反复调试 prompt。但有时候，问题其实出在检索层，RAG根本没有召回正确的文档。而这种问题，如果没有量化评估，几乎很难被发现。

上一篇我们聊了 LLM 语义路由，用模型本身做意图分类，告别了关键词硬匹配的三种陷阱。不少同学问：那到底什么时候用关键词、什么时候上 LLM？只用 LLM 不是更香吗？

他们以为向量数据库就是"把向量存进去、搜出来"，选哪个差别不大。但真的上了生产才发现：选错了，要么搜得太慢，要么存得太贵，要么你需要的功能它不支持。