资深工程师如何构建AI系统

大多数人工智能程序在演示中看起来令人印象深刻，但在实际生产环境中却悄无声息地失败，这可以用以下差异来解释：

人工智能并没有让软件工程变得更简单，它只是揭示了谁已经精通此道。

模型本身并不难，这一点你肯定深有体会：人工智能功能在测试环境中运行完美，但在实际流量、混乱数据和不稳定用户操作下却崩溃了。系统则不然。

本文不讨论提示、框架以及追逐最新模型版本。本文重点在于资深工程师如何构建能够经受住真实世界交互考验的人工智能系统。

1、AI系统并非在你想象的地方失效

大多数人工智能故障并非模型本身的问题。

它们通常是：

• 数据故障
• 假设故障
• 集成故障
• 监控故障

简而言之，模型是问题显现的地方。资深工程师很早就意识到这一点。他们不会一开始就说“我们来添加人工智能吧”，而是会先提出一个极其基础的问题：

即使模型完美无瑕，问题又出在哪里呢？因为模型在生产环境中永远不可能完美无缺。

2、资深工程师从约束条件而非功能出发

初级工程师的思维模式：

“这个模型能做什么？”

资深工程师的思维模式：

“这个系统允许出现哪些故障？”

在编写任何一行代码之前，资深工程师会先定义约束条件：

• 延迟预算
• 成本上限
• 准确率阈值
• 容错率
• 监管或隐私边界

这些约束条件会影响后续的一切。

例如：

• 如果延迟必须保持在 300 毫秒以下，那么一半的热门模型都会立即被淘汰。
• 如果不能接受幻觉，那么必须对生成式输出进行门控、验证或约束。
• 如果数据每天都在变化，那么静态微调就是一个陷阱。

约束条件就是架构。

3、将数据视为产品，而非输入

资深工程师必须通过实践才能领悟到这个不为人知的道理：

你的数据管道决定了你的 AI 系统的稳定性。

资深工程师不负责“获取数据”。数据契约由他们掌控。

他们明确规定：

• 数据来源
• 数据更新频率
• 数据出错时的责任人
• “错误数据”的定义

并且他们还实现了自动化执行。

示例：数据验证作为一等公民

from pydantic import BaseModel, ValidationError

class UserEvent(BaseModel):
    user_id: str
    action: str
    timestamp: int

def validate_event(event_dict):
    try:
        return UserEvent(**event_dict)
    except ValidationError as e:
        log_error(e)
        raise

这并非“额外工作”。这是防御性系统设计。

资深工程师假定上游数据最终会出错。

4、模型是可替换的组件，而非神圣不可侵犯的物件

模型能够吸引年轻工程师。但它们终将被资深工程师取代。

在实际系统中：-切换模型 -比较输出 -即时回滚

这需要抽象。

高级模式：模型适配器

class LLMClient:
    def generate(self, prompt: str) -> str:
        raise NotImplementedError

class OpenAIClient(LLMClient):
    def generate(self, prompt):
        return openai_response(prompt)

class LocalModelClient(LLMClient):
    def generate(self, prompt):
        return local_model(prompt)

重要性：

• 您可以在服务中断期间切换提供商
• 您可以进行 A/B 测试
• 您可以优雅地降级

模型不是系统本身，而是一个依赖项。

5、高级模式：针对部分故障进行设计

人工智能系统不会干净利落地失败，而是会降级。

资深工程师会假设：

• API 会超时
• 模型会出现幻觉
• 嵌入代码会漂移
• 外部服务会限速

因此，他们会构建备用路径。

示例：分层 AI 响应

def get_answer(query):
    try:
        return high_quality_model(query)
    except TimeoutError:
        return fast_model(query)
    except Exception:
        return cached_answer(query)

这不是悲观，而是现实。

专业提示：如果你的 AI 系统没有备用方案，那它就不是一个系统，而只是一场赌博。

6、可观测性胜过智能

大多数 AI 团队监控准确率，而资深工程师则监控行为。

他们追踪：

• 提示变化
• 输入分布
• 输出熵
• 延迟百分位数
• 每次请求的成本

因为生产环境中的问题很少会主动暴露出来。

可观测性示例

def monitored_generate(prompt):
    start = time.time()
    response = model.generate(prompt)
    duration = time.time() - start

   log_metrics({
        "latency": duration,
        "prompt_length": len(prompt),
        "response_length": len(response)
    })

   return response

日志不足以满足需求。仪表盘也不足以满足需求。

不妨试试其他方法。资深工程师更倾向于事后分析，而不是早期预警。

7、自动化是实现规模化的唯一途径

手动 AI 系统寿命很短。

资深工程师实现以下自动化：

• 评估
• 回归测试
• 及时发现变更
• 数据漂移检测
• 部署和回滚

自动化评估示例

def evaluate_model(model, test_cases):
    scores = []
    for case in test_cases:
        output = model.generate(case["input"])
        scores.append(compare(output, case["expected"]))
    return sum(scores) / len(scores)

此函数运行于：

• 部署前
• 数据变更后
• 模型更新后

如果您的 AI 系统需要手动“抽查”，那么它已经存在问题。

8、资深工程师认为人类是系统的一部分

AI 系统不会取代人类，它们只是改变了工作流程。

高级工程师设计：

• 人工审核循环
• 覆盖机制
• 审计跟踪

尤其是在高风险领域。

人机协作模式

if confidence < THRESHOLD:
    route_to_human_review(result)
else:
    auto_approve(result)

这并非弱点。这是生产系统经受住严格审查的方式。

9、提示工程是最后的 10%

这可能会让一些人感到不快。

高级工程师的大部分时间并不花在提示工程上。

他们更关注：

• 输入规范化
• 输出验证
• 状态管理
• 缓存
• 成本控制

在糟糕的系统中，再好的提示也无济于事。

“如果提示承担了过多的工作，说明你的架构做得不够。”

10、高级工程师的设计着眼于变化，而非完美

主要区别在于：

初级工程师的目标是创建最优秀的 AI 系统，而资深工程师致力于打造功能最全面的系统。

原因如下：

• 模型不断改进
• 成本不断变化
• 法规不断调整
• 用例不断演进

成功的系统往往是平淡无奇、模块化、可观察且可替换的。

就像其他优秀的软件一样。

11、结束语

由资深工程师构建的 AI 系统通常：

• 从简单的入手
• 尽早发布
• 积极进行评估
• 逐步改进

不盲目追捧。即使出现故障，也不会惊慌失措。无需逞强。它本身就能说明一切。

AI 并没有创造新的工程问题。

它只是加剧了已有的问题。

资深工程师之所以能在 AI 领域取得成功，是因为他们理解的是系统而非仅仅是工具，而这正是他们在其他领域取得成功的原因。

如果你的 AI 项目脆弱、不清晰或难以运行，那么更好的模型并不能解决问题。

原文链接：How Senior Engineers Actually Build AI Systems

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