重塑AI构建方式的7个理念

梯形图转SCL | AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

五年前，构建 AI 应用通常意味着选择一个模型、微调它，然后围绕它构建 API。

模型就是产品。其他一切都是管道。

这种架构已经改变了。

今天的生产 AI 系统可能包括检索管道、记忆层、工具使用循环、编排、语义缓存、评估工具、知识图谱和多个专门模型——所有这些以五年前几乎没有名称的方式连接在一起。

那么这些层都是从哪里来的？

我一直在追溯它们的来源，一个模式不断出现：

一篇研究论文、工程博客文章或开源发布将一个模糊的想法赋予名称、演示它，并创建一个词汇表供他人构建。

这通常是一个想法从有趣的技术转变为行业模式的时刻。

我有意宽松地使用"开始"。这些想法中的一些起源于学术研究。其他则来自工程团队或从业者实验。让我感兴趣的是它们公开后发生了什么——一个想法如何获得词汇表、变得可复制、通过开源传播、进入框架，并最终成为架构。

路径通常看起来像这样：

研究 → 论文 / 博客 → 开源 → 从业者实验 → 框架与工具 → 生产架构 → "AI 趋势"

以下是一些走过这条道路并改变了我们构建 AI 系统方式的想法。

1. RAG：当模型不再需要知道一切

问题

LLM 在参数中存储大量知识，但这些知识难以更新、检查或可靠地锚定。对于知识密集型任务，模型可能产生听起来令人信服但缺乏支持证据的答案。

显而易见的回应是使模型更大并在更多数据上训练它。RAG 挑战了这一假设。

想法

将推理与知识分离。

不要期望模型包含其所需的一切，而是在推理时从外部知识源检索相关信息，并基于检索到的上下文调节生成。

换句话说：查询 → 检索 → 生成

Meta AI 和伦敦大学学院的 Patrick Lewis 及其同事在其 2020 年 NeurIPS 论文《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》中形式化了这种方法。该论文引入了 RAG 模型，将预训练模型的参数记忆与通过检索访问的非参数外部记忆相结合。

传播方式

重要的贡献不仅仅是技术，而是抽象。

一旦工程师有了这个模式的名称，整个生态系统就围绕它形成了：嵌入模型、向量数据库、文档分块、检索管道、重排序、混合搜索、引用和锚定、框架中的检索器抽象。

RAG 最终变得如此普遍，以至于它不再听起来像一种架构，而开始听起来像一个复选框。

当研究想法成为基础设施时，就会发生这种情况。

2. 思维链：当提示成为系统的一部分

问题

早期的大型语言模型在多步推理任务上出人意料地脆弱。要求模型解决数学问题或逻辑谜题时，它可能在没有产生可靠中间推理链的情况下直接跳到答案。

想法

只要求答案，而是给模型包含中间推理步骤的示例。模型从提示本身学习推理过程的结构。

Google 的 Jason Wei 及其同事在其 2022 年论文《Chain-of-Thought Prompting Elicits Reasoning in Large Language Models》中引入了现代思维链提示公式。他们表明，提供推理示例可以显著提高算术、常识和符号推理任务的性能。

没有新的模型架构。没有微调。只是不同的交互结构方式。这是工程师思考 LLM 方式的深刻转变。

传播方式

思维链成为了更广泛的提示和推理技术家族的概念祖先：自一致性、基于树的推理、工具增强推理、结构化提示和代理推理模式。

更深层的教训比思维链本身更大：与模型的接口是系统的一部分。

我在生产中直接见过这一点。当我专门为特定目标模型调整自定义指令——改变结构、框架和指令呈现方式，而不是底层模型——在我的一个实验中，评估分数提高了大约 70%。模型没有改变，接口改变了。

提示不仅仅是模型周围的文本。它可以是架构的一部分。

3. ReAct：当模型学会行动

问题

仅靠推理是不够的。模型可以决定它需要信息，但如果它无法检索该信息、查询数据库、调用 API 或执行代码，它的推理就仍然被困在对话中。

模型是一个神谕。你问，它答。世界中什么也不会发生。

想法

交替推理和行动。

而不是：思考 → 答案

你得到：推理 → 行动 → 观察 → 推理 → 行动 → …

行动可能是工具调用、数据库查询、API 请求或与外部环境的交互。

Shunyu Yao 及其同事在 2022 年论文《ReAct: Synergizing Reasoning and Acting in Language Models》中引入了这种模式。他们的工作将推理跟踪与特定任务的行动相结合，使模型在解决问题时能够与外部源和环境交互。

传播方式

ReAct 为行业提供了一个可重用的心理模型来构建代理。它成为了后续工具使用和代理架构的基础。

我每天都使用 ReAct 风格的循环。关于它们最引人注目的一点是，从一个惊人简单的控制循环中可以涌现出多少能力。你给模型推理、工具、观察和另一次推理的机会。这个循环改变了系统能够完成的任务。

在 ReAct 之前，没有广泛采用的词汇来描述这种特定的推理和行动循环。ReAct 给了从业者一个可复制和构建的具体模式。之后，有了一个有效的模式和描述它的词汇。

4. GraphRAG：当检索成为知识问题

问题

传统 RAG 擅长查找——找到提到 X 的文档。但有些问题不是查找问题，而是综合问题。

"这个整个集合的主要主题是什么？"或"这些组织、人物和事件如何连接？"需要理解整个语料库的关系，而不是检索几个语义相似的块。

想法

在回答之前构建结构。

GraphRAG 使用 LLM 从源材料中提取实体和关系，构建基于图的表示，并使用该结构支持检索和摘要。Microsoft 的 GraphRAG 工作专门针对需要更广泛"全局"理解语料库的问题。

Microsoft Research 于 2024 年 2 月通过 Jonathan Larson 和 Steven Truitt 的文章公开发布了 GraphRAG。开源版本于 2024 年 7 月发布，Darren Edge、Ha Trinh、Steven Truitt 和 Jonathan Larson 被列为发布者。

传播方式

GraphRAG 是一个有趣的例子，因为包装几乎与研究一样重要。这个想法带着一个可识别的名称、解释、工作代码、示例和 Azure 部署路径一起到来。这极大地降低了实验成本。

一旦工程师开始实验基于图的检索，对话就扩展到了语义图、本体驱动系统、知识图谱、社区检测和其他形式的结构化检索。

更广泛的教训：当你的检索问题实际上是关系问题时，仅靠嵌入可能不够。

5. MCP：当工具需要通用语言

问题

代理需要工具。但在标准化协议之前，将 AI 系统连接到外部工具通常意味着构建自定义集成。一个模型，一个工具，另一个模型，另一个集成。生态系统很快变成了 M × N 集成问题。

想法

创建一个通用协议来向 AI 应用暴露工具和上下文。

Anthropic 于 2024 年 11 月 25 日公开介绍了模型上下文协议（MCP），将其描述为一个开放标准，用于将 AI 助手连接到外部系统、数据源和工具。这个比喻深入人心：MCP 就像 AI 工具的 USB-C。构建一次接口，跨兼容系统连接。

传播方式

MCP 的轨迹特别有趣，因为采用超越了其原始生态系统。OpenAI 于 2025 年 5 月在其 Responses API 中添加了 MCP 支持，其 Agents SDK 现在直接支持 MCP 服务器。Google 后来也宣布了对 Google 服务的官方 MCP 支持。

这就是协议成为基础设施的方式。

我直接使用 MCP 服务器——加固企业 MCP 基础设施、添加速率限制、结构化错误处理和每工具跟踪。从协议公告开始的事情变成了模型与其运行所需系统之间的连接组织的一部分。

6. 语义缓存：当令牌成为基础设施问题

问题

LLM 调用昂贵且通常缓慢。生产流量有一个令人沮丧的特性：人们提出不同的问题，但意思几乎相同。精确字符串缓存没有帮助。系统需要识别语义等价性。

想法

基于含义而不是精确文本进行缓存。

如果新请求与之前的请求足够相似，则返回缓存结果而不是再次调用模型。这将优化问题从"我们能缓存这个精确请求吗？"转移到"我们能确定两个请求何时足够相似以重用相同结果吗？"

Fu Bang 和 Di Feng 在 2023 年 NLP-OSS 研讨会上展示了 GPTCache，这是一个专门为 LLM 应用设计的开源语义缓存。这个概念早于 GPTCache，但它帮助将语义缓存转变为一个可识别、可用的工程模式。

传播方式

一旦工程师能够实现它，缓存就成为 LLM 基础设施对话的一部分：用于相似性的嵌入、距离阈值、缓存失效、TTL 策略、语义假阳性、延迟和成本权衡。

我为一个生产 ReAct 代理构建了一个 Redis 支持的语义缓存，将缓存请求的观察延迟从约 200ms 降低到约 40ms——减少了 80%——同时消除了重复或语义等价查询的冗余 LLM 调用。重要的不是 Redis，而是认识到模型不需要回答它实际上已经回答过的问题。

7. 工程环境：当模型成为一个组件

问题

随着代理变得更有能力，另一个瓶颈变得明显：模型不是整个系统。给同一个模型不同的工具、仓库上下文、测试、反馈循环和权限——你会得到截然不同的结果。周围环境开始决定模型能够可靠完成什么。

想法

将工程环境视为工程产品。

工程师的工作从编写每一行代码转向设计代理能够可靠地生成、测试、审查和改进工作的环境。人类引导，代理执行。

OpenAI 于 2026 年 2 月 11 日发布的文章《Harness engineering: leveraging Codex in an agent-first world》描述了一个为期五个月的实验，一个小团队使用 Codex 生成了大约一百万行代码来构建内部产品，人类刻意不自己编写代码。工程师专注于架构、约束、反馈循环、工具和代理周围的环境。

为什么重要

这可能是列表中最重要的想法，因为它改变了工程杠杆所在的位置。

如果模型变得越来越强大，差异化可能不再是你使用哪个模型，而是你围绕它构建的环境——工具、上下文、护栏、测试、可观测性、反馈、权限、评估、恢复。

模型成为更大的工程系统中的一个组件。这就是前沿现在移动的方向。

8、模式告诉了我们什么

纵观所有七个想法，相同的序列不断出现：

一个困难的问题出现。有人开发了一个有用的解决方案。有人给它命名。有人发布它。其他人实现它。社区实验它。框架包装它。公司将其运营化。最终，行业称其为趋势。到那时，它不再感觉像趋势，而是感觉显而易见。

AI 工程中最大的转变并非总是来自更大的模型。许多来自改变模型周围的东西：

RAG 给模型提供了外部知识。思维链改变了我们与其推理交互的方式。ReAct 将推理与行动连接起来。GraphRAG 在检索中引入了结构。MCP 标准化了模型连接工具和数据的方式。语义缓存将模型推理视为基础设施资源。工程环境将模型周围的整个环境重新定义为产品的一部分。

它们共同描述了一个更大的转变：从围绕模型构建应用到围绕智能构建工程系统。

这改变了有趣问题所在的位置。不仅仅是使用哪个模型，而是它应该看到什么上下文、应该检索什么、可以调用什么工具、应该记住什么、多个代理应该如何协调，以及如何使行为足够可靠以用于生产。

现在感觉显而易见的生产 AI 技术栈是逐步组装的——来自论文、博客文章、GitHub 仓库和研究原型，它们起初要小得多。

这意味着下一层可能已经在某处写好了。

重要的想法很少宣布自己。它们只是被引用，然后被实现，然后被包装，然后被采用。最终，每个人都想知道我们曾经如何在没有它们的情况下构建 AI。

关注工程师在行业开始称其为趋势之前悄悄构建的东西。

原文链接: The Ideas That Changed How We Build AI

汇智网翻译整理，转载请标明出处