构建生产级AI系统你必须掌握的6个AI概念

我曾亲眼见证一笔200美元的账单在一夜之间出现在AWS账户上。

不是系统崩溃了。

而是一个智能体在没有任何停止条件的情况下循环运行了六个小时，每次迭代都调用OpenAI API。

每个监控仪表盘都显示系统健康。

直到早晨收到账单，才有人注意到。

这就是你在不了解AI系统实际工作原理的情况下构建它们时会发生的事情。

大多数人在反向学习AI工程。

安装一个库。跟着教程走。调用一个API。让某些东西跑起来。感觉自己有进展。

然后某些东西以一种毫无道理的方式出错了。

他们就随机改改数字，直到问题不再出现。

那不是工程。那是带着键盘的希望。

以下是解决这个问题的6个概念。

一句话概括一切

每一个AI系统，无论多复杂，都只是：

记忆（RAG）+ 思考（LLM + Tokens）+ 行动（Agents）+ 测量（Evals）

…通过上下文工程组装在一起。

这就是整个领域。

下面的内容只是把每个部分真正意味着什么拆解开来。

1. 令牌与上下文窗口

LLM不读单词。它们读取称为令牌的块。

“engineering” → 1个令牌

“unbelievable” → 2个令牌 空格和标点符号也算。

每个模型都有一个上下文窗口——它一次能容纳的令牌数量的硬性限制。

→ Claude: 200,000 个令牌

→ GPT-5: 400,000 个令牌

把它想象成会议室里的一个白板。

模型只处理当前在板上的内容。

当白板满了，旧的笔记就会被擦除以腾出空间。

模型并没有失去思考能力。

它失去了对早期信息的访问。

为什么这会破坏生产系统：

→ 令牌要花钱——每次API调用都按输入和输出令牌计费

→ 长的聊天记录会迅速填满窗口

→ 当上下文填满时，早期的指令会被静默丢弃

→ 什么进入上下文是一个工程决策，而不是默认设置

证明这一点的失败案例：

一个团队构建了一个客户支持智能体，在每个请求中都包含了完整的12个月聊天记录作为上下文。

在5次交互的测试中工作得很漂亮。

在生产中，50次交互后，智能体开始忽略自己的系统提示。

指令还在那里。

但它们被埋在了80,000个令牌的对话历史之下。

模型实际上已经停止关注它们了。

解决方法不是换一个更好的模型。

而是对较旧的历史进行总结，以保持窗口的聚焦。

令人不安的真相：

大多数“提示工程失败“实际上都是伪装成令牌和上下文窗口失败的。

工程师责怪提示，但真正的问题是关键指令位于一个500行上下文的第3行，而模型已经不再对其加权。

2. 嵌入与向量搜索

嵌入将含义转化为数字，这样“相似性“就可以通过数学计算。

它们解决的问题：

你有50,000份文档。用户问了一个问题。你需要找到最相关的3份——而不需要每次都阅读全部50,000份。

关键词搜索在这里失效了。

如果文档说“automobile“，而用户问的是“cars“，关键词搜索就会错过它。

不是因为答案不在那里。而是因为词语不匹配。

嵌入用不同的方式解决了这个问题。

一个嵌入模型将文本转换为一个向量——一个代表数学空间中含义的数字列表。

语义相似的文本 → 数字上相似的向量。

“car“和“automobile” → 靠得很近

“car“和“photosynthesis” → 离得很远

向量搜索实际如何工作：

• 每份文档都被转换为一个向量并存储

• 用户的问题也被转换为一个向量

• 系统找到与问题向量最接近的存储向量

• 那些就是最相关的文档

这不是近似魔法。这是几何学。

相似性是一个你可以计算的真实数学属性。

这在生产中出现的地方：

→ 任何文档系统中的语义搜索

→ 查找相似的产品、文章、用户画像

→ RAG中的检索步骤（下一个概念）

→ AI智能体中的记忆

3. RAG（检索增强生成）

不是在你的数据上训练模型，而是在查询时检索相关数据，并将其作为上下文提供给模型。

RAG解决的问题：

LLM知道很多。但它们不知道你的数据。

你公司的内部文档。你的产品数据库。你的客户支持历史。

这些都不在训练集中。

两个选项：在你的数据上训练一个模型（昂贵、缓慢、立即过时），或者在模型需要的时候精确地给它你的数据。

RAG是第二个选项，系统性地执行。

三步流程：

→ 检索：

问题变成向量 → 向量数据库找到最相似的存储文档 → 检索前3-5个块

→ 增强：

检索到的文档被添加到模型的上下文中 → 提示变成“使用这个上下文，回答这个问题“

→ 生成：

模型基于你的实际数据回答——而不是幻觉

RAG在哪里崩溃：

→ 检索不好 = 答案不好。模型只能处理它收到的内容

→ 糟糕的分块将答案与其上下文分开

→ 如果检索没有找到有用的内容，模型仍然可能产生幻觉

一个真实的RAG失败案例：

一个团队为一个500页的技术手册构建了一个内部知识助手。

演示中完美运行。在生产中，答案含糊不清，有时是错误的。

问题：块大小。

他们按照原始字符数将手册分成1,000字的块。

表格在行中间被切开。逐步说明在步骤中间被切开。

检索找到了正确的大致区域——但错过了实际的答案。

将块大小减半并增加重叠，一夜之间修复了80%的问题。

硬核观点：

当你的检索很差时，RAG被高估了。

LLM不能修复糟糕的检索。它只能在周围产生幻觉。

如果你看到了错误的答案，停止调整你的提示。

开始测量你的检索精度。

答案就在那里。

4. 智能体循环

智能体通过反复选择行动、执行它、观察结果，并决定下一步做什么来工作——直到任务完成。

一个常规的LLM调用是无状态的。你问，它回答，结束。

智能体是有状态的。它行动、观察、决定、重复。

用大白话描述这个循环：

• 接收一个目标

• 决定下一个行动

• 执行它——搜索、编码、读取文件

• 观察结果

• 根据所学内容决定下一个行动

• 重复直到目标完成

• 返回最终答案

工具是赋予智能体力量的东西。

没有工具，LLM只能响应文本。

有了工具，它可以搜索网络、读取文件、编写代码、调用API、触发你定义的任何操作。

初学者总是搞错的三件事：

→ 没有停止条件的智能体会永远运行。你必须定义何时停止——步骤限制、时间限制或目标条件

→ 更多的工具 ≠ 更好的性能。太多工具会让模型混淆该用哪个

→ 工具错误需要显式处理。一个静默失败会让智能体自信地产生垃圾

那个200美元的夜间失败，详细说明：

智能体没有最大步骤计数。它的目标：研究一个主题并生成摘要。

它其中一个网络搜索工具返回了空结果。

智能体不知道如何停止。

它不停地搜索、重试、生成中间摘要——每一个都触发了另一次搜索。

六个小时后：847次LLM调用。消耗了210万个令牌。一个看起来连贯但完全是循环的摘要。一张200美元的账单。

修复方法是三行代码：一个最大步骤计数器，一个针对空结果的显式处理器，一个信心低时的升级路径。

同样的智能体现在平均在12次调用内完成。

你需要听到的观点：

大多数智能体失败不是因为模型差——而是因为工程师把循环当作是自我管理的。

它不是。

护栏、停止条件、错误处理器——从一开始就构建进来，而不是在第一次事故后才添加。

5. 评估（Evals）

评估是你用来知道你的AI系统是否真正在工作——以及一个改动是让它变好还是变坏的方法。

这是大多数教程跳过的一个概念，因为它不吸引人。

这也是区分构建演示的工程师和构建生产系统的工程师的东西。

没有评估的问题：

你改了你的提示。更新了你的检索逻辑。切换到了一个更新的模型。

它变好了吗？

你不知道。你可以手动检查几个例子——但那是一种感觉，不是证据。

评估实际的样子：

→ 一个黄金数据集：25-50个真实输入，带有已知的正确输出，覆盖主要用例加上5个已知的棘手边界情况

→ 尽可能使用二元指标：

— RAG系统检索到了正确的文档吗？是/否

— 智能体是否无错误完成？是/否

— 响应是否包含所需信息？是/否

→ 随时间跟踪的聚合分数：

— 检索准确率：89% → 做了改动 → 84%。发现回归。

— 任务完成率：76% → 新智能体版本 → 81%。确认改进。

评估循环：

部署 → 用评估测量 → 发现失败 → 将失败添加到黄金数据集 → 修复 → 再次运行评估 → 比较分数 → 仅当数字提高时才发布

坦诚的事实：

“有用性：3.7/5” 告诉不了你可操作的信息。

“正确检索到文档：84%的时间” 精确地告诉你问题在哪里，以及一个修复改进了多少。

一个没有评估的AI系统不是一个产品。

它是一个你不能自信更改的演示。

6. 上下文工程

决定到底什么信息进入模型的上下文窗口、如何结构化、以及什么被排除在外的学科。

以下是让人不舒服的观点：

上下文工程比提示工程更重要。

一个平庸的提示在精心策划的上下文中，表现优于一个被噪音淹没的出色提示——每一次都是。

大多数团队把80%的优化工作花在提示上，而几乎没有花在上下文上。

结果反映了这一点。

幼稚的方法会失败：

包含一切。所有的历史。所有检索到的文档。每个工具描述。系统提示。用户消息。全部。

这失败有一个一致的原因：模型对什么最重要感到困惑。

有一个被记录的现象叫做“迷失在中间“——埋藏在长上下文深处的信息不太可能被使用。

上下文工程实际涉及什么：

→ 选择：这个特定决策需要哪些文档、事实或历史？

→ 压缩：对话中较旧的部分是否可以总结以节省令牌？

→ 排序：关键指令应该放在开头和结尾——而不是中间

→ 修剪：哪些可以移除而不影响输出质量？

→ 结构：标题、分隔符、带标签的部分会影响模型使用信息的可靠性

一个实际例子：

一个智能体已经运行了45分钟。它积累了80,000个令牌的对话历史。它的窗口是128,000个令牌。

你不希望丢失最初的目标和约束，即使历史填满了窗口。

上下文工程：压缩较旧的工具输出，总结早期的推理，在整个会话中保持任务定义的突出。

提示工程是编写好的指令。

上下文工程是构建这些指令实际被遵循的环境。

这6个概念如何形成一个系统

记忆 → RAG + 嵌入 (系统知道什么)

思考 → LLM + 令牌 + 上下文窗口 (它如何用所知内容推理)

行动 → 智能体循环 + 工具 (它能在世界上做什么)

测量 → 评估 (你如何知道它在工作)

粘合剂 → 上下文工程 (决定什么在上面所有部分之间流动)

一个简单的聊天机器人只是思考。

一个客户支持智能体是记忆 + 思考 + 行动。

一个可靠的生产系统增加了测量。

复杂在于这些部分连接得有多好。

任何一个请求的流程：

用户问题

→ 上下文工程决定包含什么

→ 嵌入检索相关的记忆（RAG）

→ 令牌决定窗口能容纳多少

→ LLM对组装好的上下文进行推理

→ 智能体循环决定是否需要更多信息

→ 评估测量输出是否实际正确

从哪里开始

你不需要同时精通所有六个。

→ 从令牌和上下文窗口开始——它们影响你构建的一切 → 在需要语义搜索或记忆时添加嵌入

→ 在需要将模型锚定在自己的数据上时学习RAG

→ 在需要自动化时学习智能体循环

→ 在将任何东西部署到生产之前添加评估

→ 当其他一切都变得直觉化时应用上下文工程

这个顺序不是随意定的。

每个概念都让下一个概念变得可学习。

诚实的最终观点

大多数在生产中与AI挣扎的团队，并不是在和错误的模型或错误的库作斗争。

他们挣扎是因为跳过了这六个概念中的一个。

智能体永远循环，因为没人考虑停止条件。

RAG答案错误，因为没人测量检索。

提示在长时间会话中停止工作，因为没人理解上下文窗口是如何填满的。

这些不是复杂的问题。

它们是基础问题，只是用技术词汇包装起来了。

工具每六个月换一次。

这六个概念是工具如何工作的原理。

学会这些概念，你将再也不会被一个新工具搞糊涂。

更重要的是——你将再也不会花200美元看着一个智能体整夜循环，想知道哪里出了问题。

如果这对你有用：

→ 转发，分享给你认识的所有AI工程师

→ 关注 @sairahul1 获取更多这样的系统和剖析

→ 收藏此内容——下次生产中出现问题时你会参考它

我写关于AI、构建产品以及在你睡觉时也能工作的系统的内容。