第 1 章 — AI 工程这门学科

《LLM Primer V: Building Real-World LLM Applications》 章节走读的第一篇。这一章要说的是,你的 demo 跑得好、生产系统跑不好,原因不是模型问题 —— 是工程问题,而这份工程有自己的名字。

这一章为什么存在

每一个交付了 LLM 功能的团队都会撞上同一道缝。demo 在自己挑的那二十个输入上跑得很好;生产系统在它没见过的两万个输入上跑得很糟。模型没变差。团队走出了那个 “一次成型的合理输出就算成功” 的区域,进入了负载、漂移、对抗性输入,以及那些抱怨指标毫不留情的付费用户所在的区域。第 1 章给这个区域起了名字,也给了它一门学科。AI 工程不是训练模型的科学,也不是写巧妙 prompt 的技艺 —— 它是围绕一个概率式核心构建确定性系统行为的工程。整本书后面各章走的是这门学科所在的一个个面;这一章立的是那个框架。

1.1 demo 与生产之间的可靠性鸿沟

demo 和生产系统在架构图上看长得一模一样。它们的差别在于负载、在于输入分布的长尾、在于延迟预算、在于成本压力、在于故障模式。最主要的差别是统计上的:demo 跑几十个精挑细选的输入,而生产系统面对着数以百万计的长尾请求 —— 那些措辞古怪、夹杂另一种语言、缺上下文、或者故意来找茬的 query。可靠性是关于尾部的问题,不是关于均值的。叠在这之上,模型本身还是非确定性的 —— 采样、供应商侧的负载均衡、悄悄发布的模型更新,一层层叠起来 —— 而且失败很安静。一个错的回答能干净地被 parse、能通过团队写的每一个类型检查,还能一路走到用户面前,却触发不了任何告警。经典的可观测性数的是 HTTP 200,看不到这类失败模式。团队要迈出的第一步,是承认可重复性、正确性、成本,是要靠工程去构造出来的属性,而不是能从经典栈里继承下来的假设。

1.2 包在概率核心外面的那层确定性外壳

架构上的应对是让模型保持概率式,再用经典软件把它包起来。外壳负责输入的形状、输出的形状、校验、重试、回退、缓存、可观测性、成本核算。从外面看,它是一个确定性的函数 —— 一个请求进来,一份经过校验的响应出去。从里面看,它包着一个概率式的组件,并且是带超时、带 schema、带 “模型返回垃圾时该怎么办” 的恢复方案去调用它的。这个外壳分四带:输入校验、prompt 准备、按合同执行、恢复与发出。响应必须走完这四带,才算是外壳正式的输出。反复出现的诱惑是把逻辑塞回模型里 —— “让模型自己检查自己的答案吧” —— 而每一步这样的迁移,都是在离可测性更远一步。这门学科要求把概率核心保持得小、定义清楚、装得住,把系统尽可能多的行为留在团队能版本化、能推理的确定性代码里。

1.3 五根柱子:可靠性、质量、性能、成本、演进

第 1 章走的是每一个生产系统里都会重复出现的五种工程姿态。可靠性来自冗余:带指数退避的重试、从便宜的主链走到更强的次链再走到规则默认值的回退链、跨多个供应商的抽象层、以及不让某个吃力的供应商把整个系统拖下水的熔断器。质量来自校验,分两层:schema 校验抓形状错误,内容校验 —— groundedness 检查、置信度地板、护栏检查 —— 抓那些能过 schema 但语义错的答案。性能来自缓存,三层:精确匹配、语义、prompt 前缀。成本控制来自度量与归因,来自把流量路由到 “刚好够用” 的最小模型,来自按用户、按请求设定的预算 —— 避免一个 agent 循环无声地花掉一千美元 —— 也来自 prompt 上的克制。演进来自五条反馈闭环 —— 日志、评估、追踪、人工反馈、灰度发布 —— 被接成一个回路:一条生产 trace 变成一条评估用例,一次评估的回归拦下一次上线,系统按月改进。

第 1 章为后面铺了什么

整本书后面就是这层外壳,一层一层展开。第 2 章走进模型调用本身 —— 模型分级、采样参数、防御性 prompt、结构化输出。第 3 章向外扩到检索,好让模型手里有对的上下文可推理。第 4 章把这层外壳变成一个能调用工具的 agent。第 5、6 章加上评估和可观测性两条轨道。第 7、8 章以安全和部署经济学收尾。第 1 章立下的这个框架,是让后面每一章读得懂的东西:每一项技术要么是在把外壳收紧,要么是在让里面的那个概率核心更容易被包起来。

明天 — 第 2 章:基础模型与 prompt 工程。外壳里最里面的一层 —— 模型选型、采样、prompt、结构化输出 —— 都作为工程可操作的面来处理,而不是当艺术看。