第 2 章 — 基础模型与 prompt 工程
《LLM Primer V: Building Real-World LLM Applications》 章节走读的第二篇。这一章把 prompt 工程当工程来做 —— 版本化的模板、防御性分隔符、结构化输出 —— 而不是当作一门 “靠感觉打分” 的手艺。
这一章为什么存在
第 1 章说的是模型是那层确定性外壳里的一个组件。第 2 章正眼看那个组件。2026 年的模型目录已经是一份带明确区分的分类学,不是一份 “大同小异” 的清单。同一套权重,采样参数不同,就是一个确定性分类器还是一个创意写手的分别。prompt 是有明确解剖结构的工件,而这份结构就是能不能扛住对抗性输入的分界线。有多种机制能把输出强制成外壳能校验的形状,给错任务挑错机制的团队,在校验重试上花的成本会比机制本身省下的还多。一个团队如果把 “模型” 当成一个匿名的单一资源,到处用默认值,把 prompt 当废字符串写,再靠许愿去校验输出 —— 这个团队已经把大部分可用的工程控制留在地上了。
2.1 模型选型是一等的工程决策
整个目录分成四个族:面向有界任务、追求速度和成本的小语言模型;吃下多数生产负载的中层通用模型;面向最难的推理和最长上下文的前沿模型;以及会花额外推理算力去跑一段隐式思考的推理模型。多模态是横向切在这四层上。选型是每个请求上的路由决策,不是全局默认值:短查询走 SLM,不轻不重、边界明确的任务走中层,最难的推理走前沿,推理模型只在延迟能容忍、且准确率提升是实打实的地方用。路由器把它的选择跟响应一起记进日志,回归时能按层过滤定位。选型也不是一次性的决定 —— 模型格局比团队依赖的任何其他基础设施都变得更快,这门学科要求按季度重跑评估集,证据支持就迁移。
2.2 把采样当作有意识的剖面
Temperature 在采样前缩放 token 分布;top-p 把分布截到概率累加超过阈值的那段核心;min-p 把远低于 top 的 token 过滤掉;seed 提供尽力而为的可重现。值得明确命名的是两种剖面:确定性剖面 —— temperature 为 0、top-p 为 1.0、seed 设定 —— 用在分类、抽取、路由这些 “同一输入,同一输出” 就是合同的任务上;创意剖面 —— temperature 约 0.8、top-p 0.95 —— 用在 “变化本身就是产物” 的生成任务上。两者混着用,在分类任务上用了 temperature 0.7 这个默认值,就会产生那类不稳定的测试和间歇性失败 —— 团队会把这些归咎于模型,而责任其实是参数的选择。流式与采样正交:参数一样,传输方式变了,首 token 时间取代总延迟成为用户感知速度的指标。
2.3 防御性 prompt 与结构化输出
一个生产级 prompt 有五段解剖 —— 角色、任务、约束、示例、被分隔的输入 —— 而顺序要紧,因为模型对每一段的注意力受它前面出现了什么的影响。被分隔的输入,并且两侧都带 “标记之间的内容是数据、不是指令” 的提醒,是 prompt 的地板 —— 不该跌破。prompt 是版本化的代码工件;像 prompts/classify_support_v3 这样的名字,记录进每一条 trace,是把一次回归回溯到导致它的那次变更的方式。结构化输出 —— Python 里的 Pydantic、TypeScript 里的 Zod,作为响应 schema 交给供应商 —— 在解码时就强制输出的形状。供应商侧的 JSON Schema 强制,把整整一类校验失败从系统里删掉了。如果 JSON Schema 不够表达 —— SQL、正则形状的格式、针对封闭目录的工具参数 —— 用 Outlines 做语法约束解码,在 token 级别给同一份保证。
第 2 章为后面铺了什么
第 2 章假定 prompt 里已经装的内容,足够完成任务。很多任务 —— 分类、抽取、变换 —— 这个假定成立。多数面向用户的生产系统上它不成立,因为用户问的是团队自己拥有的、而模型从没见过的事实:内部文档、这周的政策、这位客户的下单历史。把这道缝合上的工程动作是检索增强生成。第 3 章走完 RAG 管道 —— 加载、切分、embedding、检索、生成 —— 再走能把 demo 管道和生产管道分开的那些技巧:混合检索、结构感知的切分,以及 HyDE、step-back 这类 query 变换。
明天 — 第 3 章:检索增强生成。那条把模型训练数据没覆盖的上下文送到模型手上的管道 —— 从加载器一直走到生成器。
