第2部分 — GenAI 不是魔法：像系统工程师一样理解 LLM

Source: Dev.to

请提供您希望翻译的正文内容，我将按照要求保留源链接并翻译成简体中文。

从软件工程师到生成式 AI 工程师：2026 年实用系列

大型语言模型常被描述为全新的突破——一次飞跃，一个类别的转变。从系统的角度来看，它们更为熟悉：具备明确约束的概率组件、可预测的失效模式以及可衡量的运营成本。以这种视角审视它们，便能消除围绕生成式 AI 的大部分困惑。

Source: …

确定性 vs. 非确定性

传统软件系统是确定性的：给定相同的输入，你会期待得到相同的输出。当这种情况没有发生时，就说明出现了问题。

大型语言模型（LLM）从设计上就打破了这一假设。即使使用相同的提示、模型和数据，输出也可能会有所不同。这不是 bug，而是这些模型生成文本的固有特性。对于工程师而言，正确性不再能用严格相等来定义，而必须用可接受性、范围和约束来描述。

Tokens, Context, and Cost

LLMs 不直接处理原始文本，而是处理 tokens。从系统角度看，tokens 更像是内存而不是字符串：

• 上下文是有限的
• 成本随 token 数量线性增长
• 延迟随上下文增长而增加
• 截断会悄然发生

当上下文成为受限资源时，提示设计从措辞转向资源管理。

幻觉：预期行为，而非错误

幻觉并非随机产生的。大型语言模型（LLM）会根据其训练，生成序列最可能的后续内容。当缺乏信息时，它会用统计上合理的内容填补空白。这是一种针对流畅性而非真实性进行优化的组件的预期行为。

• 让模型“保持准确”并不起作用。
• 置信度并不是正确性的信号。
• 基础和验证必须在模型之外实现。

幻觉并不能通过更好的提示来修复；它们受系统设计的约束。

温度作为系统杠杆

温度常被描述为“创造力旋钮”，但这种说法具有误导性。

• 较低的温度 减少方差。
• 较高的温度 增加方差。

在生产系统中，温度是可靠性控制手段：更高的方差会增加风险，较低的方差则提升可重复性。将温度视为审美选择而非系统杠杆是常见的早期错误。

上下文窗口大小：架构约束

• 模型一次可以推理多少信息。
• 是否需要检索。
• 摘要的频率。
• 状态如何向前传递。

当上下文窗口被超出时，系统会悄悄降级，而不是大声报错。良好的架构是围绕此限制设计的。

Prompt Engineering 的局限性

Prompt engineering 在早期效果很好，因为它成本低且灵活。但它会在以下情况下失效：

• 提示词无限制增长。
• 行为变得脆弱。
• 更改会引入副作用。
• 多个用例相互冲突。

此时，提示词不再是指令，而是配置。像所有配置一样，它们需要版本管理、验证和隔离。

对大型语言模型的实用视角

可以将大型语言模型视为一个 非确定性函数，它：

• 接受有界的上下文。
• 产生概率性的输出。
• 优化的是似然度，而非正确性。
• 成本和延迟与输入规模成正比。

这样来看，LLM 不再显得神秘，而是具有可权衡取舍的组件，能够进行理性分析。

将 LLM 视为系统组件

当 LLM 被视为系统组件时：

• 原始输出不再被信任。
• 验证层变得必要。
• 需要进行重试和回退。
• 关键逻辑转移到模型之外。

这正是生成式 AI 工程再次类似于后端工程的地方。

下一篇文章将探讨为何仅靠提示工程无法扩展，以及为何将提示视为配置而非技能更有用。