大模型应用工程化从 Prompt 设计到生产级稳定性保障很多团队把大模型接进业务系统之后很快就发现一个尴尬的事实Demo 跑得通生产上不稳。同样的 prompt昨天输出正常今天就开始答非所问接口偶尔超时重试一多反而把上游打挂用户多问几轮上下文越长越贵成本报表看得人心惊。这些问题的根源在于——很多人把大模型当成一个更聪明的 API却忘了它本质上是一个概率系统、一个网络服务、一个成本中心。这篇文章不讲炫技只讲一条从 Prompt 到生产环境的完整工程链路覆盖结构化输出、缓存、重试、评测与监控五个关键环节每一步都给出可直接落地的做法。一、Prompt 设计的工程化思维Prompt 看起来是写几句话实际上它决定了你整个系统的行为边界。工程化的第一课是把 Prompt 当作受版本控制的代码来对待它有文件路径、有版本号、有变更记录绝不允许直接散落在业务代码的字符串里。一个生产级的系统 Prompt 通常拆成四层结构角色与目标一句话说清楚模型是谁、要干什么比如你是一个合同审查助手负责识别条款中的法律风险。输入规范说明你会喂给它什么数据数据从哪里来边界是什么。输出规范明确输出的格式、长度、语气尤其是如果信息不足该怎么办。约束与兜底列出不能做的事以及遇到异常输入时的标准回应。其中最容易踩坑的是输出规范。让模型自由发挥就等于把下游解析逻辑的复杂度全部交给了不确定性。正确做法是强制结构化输出让模型返回 JSON再用代码做二次校验。fromopenaiimportOpenAI clientOpenAI()SYSTEM_PROMPT你是一个合同风险审查助手。 请根据用户提供的合同条款输出风险评估结果。 输出必须是一个 JSON 对象包含三个字段 - risk_level: high | medium | low - - risk_points: 字符串数组列出具体风险点 - - suggestion: 字符串给出修改建议 - 如果输入内容不是合同条款将 risk_level 设为 unknown。 - respclient.chat.completions.create(modelgpt-4o-mini,messages[{role:system,content:SYSTEM_PROMPT},{role:user,content:第七条若乙方逾期交货甲方有权每日按合同总额的 0.5% 收取违约金。}],response_format{type:json_object},# 强制 JSON 输出temperature0.2,)importjson resultjson.loads(resp.choices[0].message.content)assertset(result.keys()){risk_level,risk_points,suggestion},输出结构不合法这里有个容易被忽略的点temperature参数。很多人生产环境也保留默认的 0.7~1.0这等于在给一个需要确定性输出的业务场景引入随机性。凡是输出要被程序消费的场景temperature 都应该压到 0.2 以下只有面向用户的创意类对话才值得放开。二、结构化输出与 Schema 校验光让模型输出 JSON还不够JSON 的字段类型、取值范围都可能出错。生产级方案是引入输出 Schema先定义好数据结构让模型按 Schema 填充再用 Pydantic 这类库做严格校验不合格就触发一次带错误信息的重试。frompydanticimportBaseModel,FieldfromtypingimportLiteral,ListclassRiskAssessment(BaseModel):risk_level:Literal[high,medium,low,unknown]risk_points:List[str]Field(min_length1)suggestion:strField(min_length5)# 校验失败时的修复重试defsafe_parse(text:str,schema,max_retries2):forattemptinrange(max_retries1):try:returnschema.model_validate_json(text)exceptExceptionase:ifattemptmax_retries:raise# 把错误信息回传给模型让它自行修复textfix_with_llm(text,str(e)) 这种校验-反馈-重试的闭环是把模型输出从碰运气变成可治理的关键一步。不要怕多一次调用相比下游程序因为解析失败而崩溃一次修复调用的成本可以忽略。## 三、缓存成本与延迟的杀手锏大模型推理的成本和延迟很大一部分可以通过缓存消解。两种缓存必须区分开**语义缓存Semantic Cache**用户问题高度相似时直接返回之前的答案。做法是把用户 query 向量化在向量库里找余弦相似度超过阈值比如0.95的命中。适合客服、文档问答这类重复问题多的场景。**精确缓存Exact Cache**同样的输入直接命中。适合日志分析、数据抽取这类批量任务——同一批数据反复处理时命中率极高。 pythonimporthashlibimportredis rredis.Redis(hostlocalhost,port6379)defcached_completion(messages,ttl3600):keyllm:hashlib.sha256(str(messages).encode()).hexdigest()cachedr.get(key)ifcached:returncached.decode()# 未命中则调用模型respclient.chat.completions.create(modelgpt-4o-mini,messagesmessages)textresp.choices[0].message.content r.set(key,text,exttl)returntext 缓存带来的收益是双重的用户侧延迟从几秒降到几十毫秒成本侧则可能直接砍掉三到五成调用量。唯一要小心的是缓存一致性——知识库内容更新后相关缓存要主动失效否则用户会看到过时答案。## 四、重试与限流把网络问题当一等公民生产环境里模型 API 的失败是常态而不是例外限流429、服务端错误5xx、超时timeout都会出现。但无脑重试是灾难性的——瞬时并发重试会放大流量反而触发更严格的限流。 正确的重试策略是指数退避 抖动 pythonimporttimeimportrandomdefcall_with_retry(fn,max_retries4,base_delay1.0):forattemptinrange(max_retries):try:returnfn()exceptExceptionase:ifattemptmax_retries-1:raisedelaybase_delay*(2**attempt)random.uniform(0,0.5)print(f第{attempt1}次失败{delay:.1f}s 后重试:{e})time.sleep(delay) 除了调用侧重试还要在应用侧加一层信号量或令牌桶做并发控制把瞬时请求数限制在服务商配额之内。记住一个原则**给下游的每一分流量都要是有计划的流量**。## 五、评测没有评测就没有优化绝大多数大模型应用死在感觉还行四个字上。感觉还行意味着你无法回答三个问题这次改动是变好了还是变差了线上表现和上线前一致吗用户投诉的那个case回归了吗 生产级做法是建一条评测流水线1.**黄金数据集**从真实用户问题里挑100~300条人工写好标准答案作为评测基准。2.2.**自动打分**用规则关键实体命中率、格式合规率或 LLM-as-Judge让一个更强的模型按评分标准打分来批量评估。3.3.**回归门禁**每次改动 prompt 或链路参数先跑一遍评测集分数下降超过阈值就禁止上线。 python# LLM-as-Judge 简化示例defjudge(reference,answer,question):promptf请对比参考答案与模型回答按 1-5 分评分。 问题{question}参考答案{reference}模型回答{answer}只输出分数数字。respclient.chat.completions.create(modelgpt-4o,messages[{role:user,content:prompt}])returnint(resp.choices[0].message.content.strip()) 这套流水线跑起来之后prompt 优化就不再是玄学而是有数据支撑的迭代过程。## 六、监控把黑盒变成仪表盘最后一道防线是监控。至少需要采集四类指标-**调用量**按接口、模型、时间切片看趋势是否异常。--**延迟**P50/P95/P99 分位延迟P95 比平均值更能暴露真实体验。--**错误率**按错误码归类429和 5xx 的处理方式完全不同。--**成本**按日、按用户、按功能模块归因成本失控往往比性能失控更致命。 另外强烈建议给所有请求加一个全局 trace_id贯穿用户请求 → 应用逻辑 → 模型调用 → 结果返回全链路。这样线上出问题时你拿到一条 trace_id 就能定位到具体是哪一次调用、哪一段 prompt、哪个环节超时而不是在日志海里捞针。## 七、小结把大模型应用做上生产真正拉开差距的从来不是谁的 prompt 写得妙而是谁把 prompt、输出、缓存、重试、评测、监控这些工程环节串成了体系。这套体系的价值在于**它让不确定性变成了可控的不确定性**——模型依然可能偶尔抽风但你的系统知道它会怎么抽风、如何检测、如何兜底、如何复盘。建议按本文的顺序逐步搭建先固化 prompt 与结构化输出再加缓存和重试最后补上评测与监控。每加一层你的系统就向生产级靠近一步。