最近一段时间技术社区里聊得最多的已经不是“大模型又发布了什么新能力”而是另一个更现实的问题如果 AI 的投入一直换不回产出我们的项目还能活多久这个问题的背后就是“AI 泡沫”这四个字。泡沫这个词听起来偏金融、偏宏观和我们平时写的接口、Pipeline、Prompt 离得很远。但如果你真的在一线参与过 AI 应用开发就会明白泡沫一旦开始收缩波及的不仅是估值更是一个个具体项目的预算、排期和技术选型。这篇文章不预测市场不谈股价只切换回工程师视角拆解一件事假设 AI 泡沫彻底破裂我们手上已经开发完成的 AI 应用到底还剩多少价值以及在泡沫还没破裂之前怎么把应用设计成“能活下来”的样子。文章会覆盖伪需求识别、可降级的模型路由、Token 成本控制、模型效果回归评估、常见失败信号排查等内容并提供可以直接运行的 Python 示例工程。适合正在做 AI 应用开发或者正准备把大模型接入业务系统的后端工程师、算法工程师和架构师阅读。1. 从“AI 泡沫”说起工程师真正该担心什么1.1 泡沫的三种层次先说明一下我理解的“AI 泡沫”不是单一事件而是三个层次预期同时被高估。资本层AI 概念项目估值过高一旦融资热度下降“烧钱换增长”的策略就会失效。模型能力层市场对大模型的通用能力期待过高认为“给一段文本模型就能解决所有问题”但现实中模型仍然会幻觉、会不稳定、会受上下文长度限制。应用价值层大量应用只是把大模型包装成聊天窗口没有嵌入真实的工作流用户用完即走留存和付费意愿都很低。对一线开发者来说资本层的泡沫离我们最远模型和应用这两个层次才直接影响我们的日常工作。你在项目里遇到的“模型回答看起来合理但完全不能用”“上线一个月活跃用户个位数”“API 成本比服务器成本还高”基本都是后两个层次的问题。1.2 泡沫破裂不等于 AI 失效泡沫破裂本质上是预期回归到真实能力附近。当年互联网泡沫破裂之后互联网本身并没有消失反而沉淀出了一批有真实商业价值的公司。AI 大概率也会走类似的路径靠概念拿融资、靠 Demo 充日活的项目会减少但真正嵌入业务流程、解决真实问题的 AI 能力仍然会被保留下来。所以对工程师来说与其焦虑不如用“泡沫视角”重新审视自己的项目剥离掉“因为用了大模型所以很酷”的成分之后它是否还有独立存在的价值如果有泡沫破裂后它大概率还能继续跑如果没有现在就值得调整方向。这个审视过程恰恰是区分“AI 项目”和“真需求项目”的分水岭。2. 泡沫期常见的三类“高危 AI 项目”2.1 为了 AI 而 AI 的聊天窗口过去一年里最常见的 AI 项目形态就是把大模型接入对话框前面套一层壳后面挂一段知识库就叫“智能助理”。这类项目最典型的问题是用户并没有明确的任务场景聊天就只是聊天回答完问题之后没有下一步动作也没有和业务系统打通。判断一个项目是否属于这类可以做一个简单测试把“大模型”这个关键词从产品描述里去掉再看用户是否还愿意使用。如果去掉之后产品几乎没有存在意义说明 AI 只是伪装并没有真正解决问题。类似的场景还包括一些 AI 建站、AI 电商营销工具如果核心能力只是“帮你生成一段文案”而没有深入到交易、库存、客服闭环那么在预算收缩期很容易被砍掉。2.2 只换模型不换系统的“伪升级”另一种常见情况是团队把大量精力花在“从模型 A 换到模型 B”上但外围系统完全没有变化知识库仍然是几个 PDF提示词仍然是临时拼出来的效果评估仍然靠开发人员自己肉眼看几遍。模型升级本身不是坏事坏的是把它当成唯一变量。AI 应用的实际效果大致等于模型能力、数据质量、工程链路、评估反馈四个因素的乘积只调整其中一个因素效果提升往往非常有限。泡沫破裂后能沉淀下来的一定是整体工程链路而不是某个模型的名字。今天叫得上号的模型几年后可能就被替换掉了但你的数据管线、评测集、监控系统是可以一直复用的。2.3 忽视数据质量的“智能决策”还有一类项目是直接让大模型承担决策职责比如自动回复客户、自动生成合同、自动审批工单。如果底层知识库没有整理、没有权限边界、没有人工审核机制这类系统的风险非常高。模型输出的内容从表面看流畅自信但一旦关键字段出错用户信任就会迅速崩塌。这类项目在资本热潮期容易被包装成“降本增效”的样板实际上需要非常严格的评测和兜底设计。比较稳妥的做法是让模型先做“辅助决策”输出建议和理由再由人来确认等到准确率评估稳定之后再逐步扩大自动化范围。这也是我为什么强调在任何 AI 项目里“评估”都不是测试阶段的附加项而是上线前的安全闸门。3. 需求四问把概念项目变成可交付项目3.1 需求判断清单在启动任何 AI 功能之前我都会先过一遍需求四问这里也分享给你。业务问题是否真实存在在 AI 介入之前这个问题是不是已经存在并且客户愿意为此付费或高频使用大模型是不是最高性价比的解法有些问题用规则、用数据库、用传统分类模型反而更便宜、更快、更容易控制。失败容忍度是多少如果模型给出错误答案会带来什么后果是“推荐错了换个推荐”还是“合同金额算错要赔钱”模型不可用时怎么办是直接拒绝服务还是降级到关键词匹配、FAQ 搜索、人工客服这四个问题不要求全部满足但至少要想清楚每个答案。尤其是第四问很多项目从来没有设计过降级链路线上一旦模型服务抖动整个功能就瘫痪。这种单点依赖是所有抗风险设计里最需要避免的。3.2 用“失败容忍度”决定技术选型根据失败容忍度的不同可以把 AI 应用大致分成两类。低风险场景包括标题生成、内容润色、闲聊助手、推荐理由生成等。这类场景允许偶尔出错可以直接调用大模型重点放在控制成本和响应速度上。高风险场景包括合同分析、医疗建议、工单自动处理、金额计算等这类场景不能把模型输出直接当最终结论必须叠加规则校验、引用溯源和人工审核。在泡沫破裂后的预算收缩期低风险场景可以先上用比较小的成本验证价值高风险场景需要更保守先做小范围试点用客观数据证明准确率之后再扩大投放范围。这个先易后难、先辅助后自动的路径能让团队在投入产出比还没有被验证的时候少踩很多坑。4. 抗泡沫实战设计一个可降级、可评估的 AI 问答助手下面用一个最小示例来演示怎么把 AI 应用从“单点依赖大模型”改造成“可降级、可评估、可续命”的形态。示例场景是一个企业内部的 FAQ 问答助手。4.1 项目结构示例工程放在resilient_llm_app目录下文件划分如下resilient_llm_app/ ├── model_router.py # 模型路由与降级 ├── simple_cache.py # 简单缓存 ├── cost_tracker.py # Token 成本估算 ├── evaluate.py # 回归评估脚本 └── main.py # 组装入口4.2 模型路由主模型挂了本地模型顶上核心思路是配置多个模型源调用时按顺序尝试。主模型失败后自动降级到备用模型最后还可以降级到本地模型或规则兜底保证服务不中断。# 文件路径resilient_llm_app/model_router.py import logging logger logging.getLogger(__name__) class ModelRouter: 可替换、可降级的模型路由。 def __init__(self, model_configs): model_configs 是模型配置列表示例 [ { name: remote-llm, type: openai_compat, model: gpt-4o-mini, base_url: https://api.example.com/v1, api_key_env: REMOTE_API_KEY }, { name: local-llm, type: openai_compat, model: qwen-plus, base_url: http://127.0.0.1:8000/v1, api_key_env: NOT_REQUIRED } ] self.model_configs model_configs def chat(self, messages, preferNone): candidates self.model_configs if prefer: candidates sorted( candidates, keylambda cfg: cfg[name] ! prefer, ) last_error None for cfg in candidates: try: return self._call(cfg, messages) except Exception as exc: logger.warning(模型 %s 调用失败: %s, cfg[name], exc) last_error exc raise RuntimeError(f所有模型均不可用请检查服务。最后错误: {last_error}) def _call(self, cfg, messages): # 这里以 OpenAI 兼容接口为例实际请按模型服务商 SDK 调整 from openai import OpenAI client OpenAI( base_urlcfg[base_url], api_keycfg.get(api_key_env, EMPTY), ) resp client.chat.completions.create( modelcfg.get(model, gpt-4o-mini), messagesmessages, temperature0.2, ) return resp.choices[0].message.content需要说明的是model_configs列表的顺序就是降级顺序。主模型不可用不代表服务要挂掉本地模型只要部署在一台有显存的机器上就能在远程 API 故障时兜住核心请求。生产环境建议在此基础上再增加超时控制、重试次数限制和健康检查避免某个模型持续超时拖慢整体响应。4.3 缓存层去掉重复的 Token 开销同一个问题被用户反复提问是 AI 应用最常见的成本浪费之一。加一层缓存可以把热点问题的 Token 消耗降到接近零。# 文件路径resilient_llm_app/simple_cache.py import hashlib from collections import OrderedDict class SimpleCache: 一个极简 LRU 缓存生产环境可替换为 Redis。 def __init__(self, max_size256): self._store OrderedDict() self._max_size max_size def _key(self, messages): raw repr(messages) return hashlib.md5(raw.encode(utf-8)).hexdigest() def get(self, messages): key self._key(messages) if key not in self._store: return None self._store.move_to_end(key) return self._store[key] def set(self, messages, answer): key self._key(messages) self._store[key] answer self._store.move_to_end(key) if len(self._store) self._max_size: self._store.popitem(lastFalse)这里把“问题消息列表”序列化后取 MD5 作为缓存 key。实际项目中如果问题文本很长或包含多余空白建议在路由前先做规范化处理例如统一去掉首尾空格、把全角标点转半角这样可以明显提高缓存命中率。多实例部署时不要用进程内缓存建议替换为 Redis并设置合理的过期时间。4.4 成本追踪让每笔调用都算得清很多 AI 项目做到最后才发现成本失控是因为从第一天起就没有把 Token 消耗当作业务成本来记账。我建议在路由层加一个简单的成本追踪器把每次调用的输入长度、输出长度、估算费用全部记录下来。# 文件路径resilient_llm_app/cost_tracker.py # 示例单价美元 / token请根据你的实际模型渠道价格自行调整 PRICE { gpt-4o-mini: {input: 0.15 / 1_000_000, output: 0.60 / 1_000_000}, qwen-plus: {input: 0.8 / 1_000_000, output: 2.0 / 1_000_000}, } def estimate_tokens(text: str) - int: 粗略估算 token 数中文约 1 个字 1 个 token英文约 3~4 个字符 1 个 token。 生产环境建议使用 tiktoken 或模型厂商 SDK 提供的精确计数。 text str(text) chinese_chars sum(1 for ch in text if \u4e00 ch \u9fff) return max(1, chinese_chars (len(text) - chinese_chars) // 3) def log_cost(model: str, input_text: str, output_text: str) - dict: price PRICE.get(model) if not price: return {model: model, cost: 0.0, note: unknown model price} input_tokens estimate_tokens(input_text) output_tokens estimate_tokens(output_text) cost input_tokens * price[input] output_tokens * price[output] return { model: model, input_tokens: input_tokens, output_tokens: output_tokens, cost: round(cost, 6), }在model_router的_call方法里调用log_cost把返回结果写入结构化日志就能按天、按功能统计成本分布。没有这份数据就没有办法判断一个 AI 功能是否值得继续保留。很多团队在复盘时才发现某个功能烧掉了大部分预算原因就是缺少这种最基本的计量能力。4.5 回归评估模型升级前先过测试集“这个模型效果好像好一点”在很多团队是被直接当成结论来用的。更稳妥的做法是准备一份固定的评估集每次换模型、改 Prompt、改知识库之前都跑一遍用通过率来判断效果是提升了还是回退了。# 文件路径resilient_llm_app/evaluate.py EVAL_SET [ { question: 如何重置登录密码, must_contain: [重置, 邮箱], }, { question: 订单超过多久不能申请退款, must_contain: [7天], }, { question: 你们有企业版吗, must_contain: [企业版, 销售], }, ] def run_evaluation(chat_fn): total len(EVAL_SET) passed 0 for item in EVAL_SET: answer chat_fn(item[question]) ok all(keyword in answer for keyword in item[must_contain]) print(f问题{item[question]}) print(f回答{answer}) print(f结果{通过 if ok else 不通过}\n) passed int(ok) rate passed / total print(f评估通过率{passed}/{total} {rate:.2%}) return ratemust_contain是最简单的自动化断言适合初期版本。更完整的效果评估还应该包括回答相关性人工打分、事实错误标注、格式规范校验。这些工作虽然朴素但它是 AI 工程里唯一能让“效果好坏”从主观感受变成可比较指标的手段。只要评估集还在团队就不会在模型升级时彻底失去方向。4.6 组装入口把模块串起来主流程很清晰先查缓存命中就直接返回没有命中就调用模型路由更新缓存再记录成本。# 文件路径resilient_llm_app/main.py from model_router import ModelRouter from simple_cache import SimpleCache from cost_tracker import log_cost # 这里按 4.2 节的说明填写模型配置 router ModelRouter([...]) cache SimpleCache() def chat(question): messages [{role: user, content: question}] cached cache.get(messages) if cached: return cached answer router.chat(messages) cache.set(messages, answer) log_cost(gpt-4o-mini, question, answer) return answer if __name__ __main__: run_evaluation(chat)到这里一个具备基础抗风险能力的 AI 问答服务就完成了。它不会因为某个模型服务商涨价、断连、或者模型策略调整而完全瘫痪这就是“抗泡沫设计”的起点。5. Token 成本控制的工程手段5.1 成本是怎么悄悄失控的一个普通的 RAG 问答请求会把系统 Prompt、多轮历史、检索到的知识库片段、用户问题全部塞给模型。你以为用户只是问了一句“密码怎么改”实际输入可能已经有一两千个 Token。日活一千的场景一个月的模型调用成本就可能达到数千元。问题往往不是模型本身贵而是调用方式太粗放。5.2 从代码层面可做的四件事命中缓存直接返回。重复问题不重复计费这是收益最明显的优化。控制上下文长度。只传最近两轮对话知识库片段做截断系统 Prompt 定期精简。先小模型后大模型。简单意图识别、关键词分类先用小模型或规则处理只有复杂问题才调用大模型。设置调用上限。例如每个用户每分钟最多调用十次防止异常流量打爆成本。结合上一节的代码只需要在chat方法里先查缓存、再更新成本日志就已经完成了最基本的成本控制闭环。在这个闭环跑通之前先不要急着追求复杂的评测平台和指标系统先把“成本可见、可限流、可追溯”这三件事做好。6. 大模型效果“漂移”与幻觉治理6.1 为什么模型升级后效果反而变差模型服务商不会提前通知你行为变化。同一个问题、同一个 Prompt这周和上周的回答可能完全不同。这种“效果漂移”在泡沫破裂后会更加致命因为预算收缩团队没有足够精力持续监控一旦线上回答质量下降用户流失是不可逆的。应对手段不复杂但需要固定下来锁定模型版本。生产环境不要使用自动指向“最新版”的写法而是明确写版本号。即使价格高一点也要保证行为可预期。每次升级先跑评估集。用上一节的evaluate.py跑一遍评估通过率不低于当前版本再考虑切换流量。保留旧模型路由。把旧版本放在model_configs的备用位置万一新版本翻车可以快速回滚。这里要提醒的是如果你使用 Cursor、PyCharm AI 插件这类 AI 编程工具它们同样面临模型版本更新带来的行为变化。把“生成代码”纳入版本管理通过代码评审和自动化测试把关比信任“AI 编程工具输出一定正确”要靠谱得多。AI 编程的价值在于提效而不是替代验证。6.2 幻觉治理的工程边界大模型的“幻觉”很难被完全消除。工程上能做的是让幻觉可以被发现、被追溯。比较实用的组合是给回答加引用来源。如果模型引用了知识库内容把原文片段一并返回用户可以自己核对依据。关键数据做规则校验。金额、日期、订单号这类强格式字段用正则和数据库校验不要轻信模型输出。高风险场景人工兜底。合同、医疗、财务等场景保留人工审核环节模型只负责起草和摘要。说到底不要试图让模型永远正确而是要让系统在模型出错时也能及时发现问题。这比单纯追求“更高准确率”更有工程价值。7. AI 项目下马前的五个信号与排查清单7.1 五个危险信号信号典型表现可能原因解决思路用户留存低上线一个月活跃用户个位数功能没有嵌入真实工作流重新梳理用户任务和业务系统打通评估靠感觉团队说不清效果是变好还是变差缺少评估集和回归机制先建最小评估集再继续迭代成本不可控月底账单远超预算没有缓存、没有限量、上下文过长加缓存、控长度、设置调用上限模型升级就崩同一套 Prompt 换模型后效果大变缺少模型版本锁定和回归流程固定版本升级前跑评估集没有降级方案模型服务抖动时功能完全不可用没有备用模型和兜底逻辑配置多模型路由增加关键词兜底7.2 排查思路如果项目已经出现了多个信号建议按下面的顺序排查不要一上来就换模型。先看业务数据。用户到底在什么场景下使用留存低是入口问题还是回答质量的问题。再看链路数据。打开日志确认每次请求的响应时间、Token 消耗、缓存命中率。最后再动模型。确认数据和链路没有问题后再考虑调整 Prompt 或更换模型。这个顺序的意义在于模型只是 AI 应用链路里的一环。把精力放在数据、链路和评估上效果提升通常比单纯换模型更稳定。反过来如果项目已经连续几个迭代周期拿不出效果数据那就应该果断收缩范围把资源集中到少数有明确指标的功能上。8. 泡沫之后AI 工程师可以沉淀什么8.1 真正能沉淀下来的四类能力如果 AI 泡沫破裂受影响最大的会是三类人只会写 Prompt 的“套壳型”开发者、只会调 API 不愿碰数据的“调用型”开发者以及没有业务判断力的“模型崇拜型”开发者。反过来有四类能力在任何市场周期里都有价值。数据工程能力清洗数据、构造知识库、做数据质量校验。所有 AI 应用的上限都由数据决定。应用工程能力把模型调用嵌入业务流程设计缓存、降级、重试、监控保证系统稳定。评估反馈能力建设评估集、指标看板、线上回归机制让效果可以被度量、被回溯。成本与资源意识用最合适的 从AI泡沫到工程生存：可降级、可评估的LLM应用设计指南
最近一段时间技术社区里聊得最多的已经不是“大模型又发布了什么新能力”而是另一个更现实的问题如果 AI 的投入一直换不回产出我们的项目还能活多久这个问题的背后就是“AI 泡沫”这四个字。泡沫这个词听起来偏金融、偏宏观和我们平时写的接口、Pipeline、Prompt 离得很远。但如果你真的在一线参与过 AI 应用开发就会明白泡沫一旦开始收缩波及的不仅是估值更是一个个具体项目的预算、排期和技术选型。这篇文章不预测市场不谈股价只切换回工程师视角拆解一件事假设 AI 泡沫彻底破裂我们手上已经开发完成的 AI 应用到底还剩多少价值以及在泡沫还没破裂之前怎么把应用设计成“能活下来”的样子。文章会覆盖伪需求识别、可降级的模型路由、Token 成本控制、模型效果回归评估、常见失败信号排查等内容并提供可以直接运行的 Python 示例工程。适合正在做 AI 应用开发或者正准备把大模型接入业务系统的后端工程师、算法工程师和架构师阅读。1. 从“AI 泡沫”说起工程师真正该担心什么1.1 泡沫的三种层次先说明一下我理解的“AI 泡沫”不是单一事件而是三个层次预期同时被高估。资本层AI 概念项目估值过高一旦融资热度下降“烧钱换增长”的策略就会失效。模型能力层市场对大模型的通用能力期待过高认为“给一段文本模型就能解决所有问题”但现实中模型仍然会幻觉、会不稳定、会受上下文长度限制。应用价值层大量应用只是把大模型包装成聊天窗口没有嵌入真实的工作流用户用完即走留存和付费意愿都很低。对一线开发者来说资本层的泡沫离我们最远模型和应用这两个层次才直接影响我们的日常工作。你在项目里遇到的“模型回答看起来合理但完全不能用”“上线一个月活跃用户个位数”“API 成本比服务器成本还高”基本都是后两个层次的问题。1.2 泡沫破裂不等于 AI 失效泡沫破裂本质上是预期回归到真实能力附近。当年互联网泡沫破裂之后互联网本身并没有消失反而沉淀出了一批有真实商业价值的公司。AI 大概率也会走类似的路径靠概念拿融资、靠 Demo 充日活的项目会减少但真正嵌入业务流程、解决真实问题的 AI 能力仍然会被保留下来。所以对工程师来说与其焦虑不如用“泡沫视角”重新审视自己的项目剥离掉“因为用了大模型所以很酷”的成分之后它是否还有独立存在的价值如果有泡沫破裂后它大概率还能继续跑如果没有现在就值得调整方向。这个审视过程恰恰是区分“AI 项目”和“真需求项目”的分水岭。2. 泡沫期常见的三类“高危 AI 项目”2.1 为了 AI 而 AI 的聊天窗口过去一年里最常见的 AI 项目形态就是把大模型接入对话框前面套一层壳后面挂一段知识库就叫“智能助理”。这类项目最典型的问题是用户并没有明确的任务场景聊天就只是聊天回答完问题之后没有下一步动作也没有和业务系统打通。判断一个项目是否属于这类可以做一个简单测试把“大模型”这个关键词从产品描述里去掉再看用户是否还愿意使用。如果去掉之后产品几乎没有存在意义说明 AI 只是伪装并没有真正解决问题。类似的场景还包括一些 AI 建站、AI 电商营销工具如果核心能力只是“帮你生成一段文案”而没有深入到交易、库存、客服闭环那么在预算收缩期很容易被砍掉。2.2 只换模型不换系统的“伪升级”另一种常见情况是团队把大量精力花在“从模型 A 换到模型 B”上但外围系统完全没有变化知识库仍然是几个 PDF提示词仍然是临时拼出来的效果评估仍然靠开发人员自己肉眼看几遍。模型升级本身不是坏事坏的是把它当成唯一变量。AI 应用的实际效果大致等于模型能力、数据质量、工程链路、评估反馈四个因素的乘积只调整其中一个因素效果提升往往非常有限。泡沫破裂后能沉淀下来的一定是整体工程链路而不是某个模型的名字。今天叫得上号的模型几年后可能就被替换掉了但你的数据管线、评测集、监控系统是可以一直复用的。2.3 忽视数据质量的“智能决策”还有一类项目是直接让大模型承担决策职责比如自动回复客户、自动生成合同、自动审批工单。如果底层知识库没有整理、没有权限边界、没有人工审核机制这类系统的风险非常高。模型输出的内容从表面看流畅自信但一旦关键字段出错用户信任就会迅速崩塌。这类项目在资本热潮期容易被包装成“降本增效”的样板实际上需要非常严格的评测和兜底设计。比较稳妥的做法是让模型先做“辅助决策”输出建议和理由再由人来确认等到准确率评估稳定之后再逐步扩大自动化范围。这也是我为什么强调在任何 AI 项目里“评估”都不是测试阶段的附加项而是上线前的安全闸门。3. 需求四问把概念项目变成可交付项目3.1 需求判断清单在启动任何 AI 功能之前我都会先过一遍需求四问这里也分享给你。业务问题是否真实存在在 AI 介入之前这个问题是不是已经存在并且客户愿意为此付费或高频使用大模型是不是最高性价比的解法有些问题用规则、用数据库、用传统分类模型反而更便宜、更快、更容易控制。失败容忍度是多少如果模型给出错误答案会带来什么后果是“推荐错了换个推荐”还是“合同金额算错要赔钱”模型不可用时怎么办是直接拒绝服务还是降级到关键词匹配、FAQ 搜索、人工客服这四个问题不要求全部满足但至少要想清楚每个答案。尤其是第四问很多项目从来没有设计过降级链路线上一旦模型服务抖动整个功能就瘫痪。这种单点依赖是所有抗风险设计里最需要避免的。3.2 用“失败容忍度”决定技术选型根据失败容忍度的不同可以把 AI 应用大致分成两类。低风险场景包括标题生成、内容润色、闲聊助手、推荐理由生成等。这类场景允许偶尔出错可以直接调用大模型重点放在控制成本和响应速度上。高风险场景包括合同分析、医疗建议、工单自动处理、金额计算等这类场景不能把模型输出直接当最终结论必须叠加规则校验、引用溯源和人工审核。在泡沫破裂后的预算收缩期低风险场景可以先上用比较小的成本验证价值高风险场景需要更保守先做小范围试点用客观数据证明准确率之后再扩大投放范围。这个先易后难、先辅助后自动的路径能让团队在投入产出比还没有被验证的时候少踩很多坑。4. 抗泡沫实战设计一个可降级、可评估的 AI 问答助手下面用一个最小示例来演示怎么把 AI 应用从“单点依赖大模型”改造成“可降级、可评估、可续命”的形态。示例场景是一个企业内部的 FAQ 问答助手。4.1 项目结构示例工程放在resilient_llm_app目录下文件划分如下resilient_llm_app/ ├── model_router.py # 模型路由与降级 ├── simple_cache.py # 简单缓存 ├── cost_tracker.py # Token 成本估算 ├── evaluate.py # 回归评估脚本 └── main.py # 组装入口4.2 模型路由主模型挂了本地模型顶上核心思路是配置多个模型源调用时按顺序尝试。主模型失败后自动降级到备用模型最后还可以降级到本地模型或规则兜底保证服务不中断。# 文件路径resilient_llm_app/model_router.py import logging logger logging.getLogger(__name__) class ModelRouter: 可替换、可降级的模型路由。 def __init__(self, model_configs): model_configs 是模型配置列表示例 [ { name: remote-llm, type: openai_compat, model: gpt-4o-mini, base_url: https://api.example.com/v1, api_key_env: REMOTE_API_KEY }, { name: local-llm, type: openai_compat, model: qwen-plus, base_url: http://127.0.0.1:8000/v1, api_key_env: NOT_REQUIRED } ] self.model_configs model_configs def chat(self, messages, preferNone): candidates self.model_configs if prefer: candidates sorted( candidates, keylambda cfg: cfg[name] ! prefer, ) last_error None for cfg in candidates: try: return self._call(cfg, messages) except Exception as exc: logger.warning(模型 %s 调用失败: %s, cfg[name], exc) last_error exc raise RuntimeError(f所有模型均不可用请检查服务。最后错误: {last_error}) def _call(self, cfg, messages): # 这里以 OpenAI 兼容接口为例实际请按模型服务商 SDK 调整 from openai import OpenAI client OpenAI( base_urlcfg[base_url], api_keycfg.get(api_key_env, EMPTY), ) resp client.chat.completions.create( modelcfg.get(model, gpt-4o-mini), messagesmessages, temperature0.2, ) return resp.choices[0].message.content需要说明的是model_configs列表的顺序就是降级顺序。主模型不可用不代表服务要挂掉本地模型只要部署在一台有显存的机器上就能在远程 API 故障时兜住核心请求。生产环境建议在此基础上再增加超时控制、重试次数限制和健康检查避免某个模型持续超时拖慢整体响应。4.3 缓存层去掉重复的 Token 开销同一个问题被用户反复提问是 AI 应用最常见的成本浪费之一。加一层缓存可以把热点问题的 Token 消耗降到接近零。# 文件路径resilient_llm_app/simple_cache.py import hashlib from collections import OrderedDict class SimpleCache: 一个极简 LRU 缓存生产环境可替换为 Redis。 def __init__(self, max_size256): self._store OrderedDict() self._max_size max_size def _key(self, messages): raw repr(messages) return hashlib.md5(raw.encode(utf-8)).hexdigest() def get(self, messages): key self._key(messages) if key not in self._store: return None self._store.move_to_end(key) return self._store[key] def set(self, messages, answer): key self._key(messages) self._store[key] answer self._store.move_to_end(key) if len(self._store) self._max_size: self._store.popitem(lastFalse)这里把“问题消息列表”序列化后取 MD5 作为缓存 key。实际项目中如果问题文本很长或包含多余空白建议在路由前先做规范化处理例如统一去掉首尾空格、把全角标点转半角这样可以明显提高缓存命中率。多实例部署时不要用进程内缓存建议替换为 Redis并设置合理的过期时间。4.4 成本追踪让每笔调用都算得清很多 AI 项目做到最后才发现成本失控是因为从第一天起就没有把 Token 消耗当作业务成本来记账。我建议在路由层加一个简单的成本追踪器把每次调用的输入长度、输出长度、估算费用全部记录下来。# 文件路径resilient_llm_app/cost_tracker.py # 示例单价美元 / token请根据你的实际模型渠道价格自行调整 PRICE { gpt-4o-mini: {input: 0.15 / 1_000_000, output: 0.60 / 1_000_000}, qwen-plus: {input: 0.8 / 1_000_000, output: 2.0 / 1_000_000}, } def estimate_tokens(text: str) - int: 粗略估算 token 数中文约 1 个字 1 个 token英文约 3~4 个字符 1 个 token。 生产环境建议使用 tiktoken 或模型厂商 SDK 提供的精确计数。 text str(text) chinese_chars sum(1 for ch in text if \u4e00 ch \u9fff) return max(1, chinese_chars (len(text) - chinese_chars) // 3) def log_cost(model: str, input_text: str, output_text: str) - dict: price PRICE.get(model) if not price: return {model: model, cost: 0.0, note: unknown model price} input_tokens estimate_tokens(input_text) output_tokens estimate_tokens(output_text) cost input_tokens * price[input] output_tokens * price[output] return { model: model, input_tokens: input_tokens, output_tokens: output_tokens, cost: round(cost, 6), }在model_router的_call方法里调用log_cost把返回结果写入结构化日志就能按天、按功能统计成本分布。没有这份数据就没有办法判断一个 AI 功能是否值得继续保留。很多团队在复盘时才发现某个功能烧掉了大部分预算原因就是缺少这种最基本的计量能力。4.5 回归评估模型升级前先过测试集“这个模型效果好像好一点”在很多团队是被直接当成结论来用的。更稳妥的做法是准备一份固定的评估集每次换模型、改 Prompt、改知识库之前都跑一遍用通过率来判断效果是提升了还是回退了。# 文件路径resilient_llm_app/evaluate.py EVAL_SET [ { question: 如何重置登录密码, must_contain: [重置, 邮箱], }, { question: 订单超过多久不能申请退款, must_contain: [7天], }, { question: 你们有企业版吗, must_contain: [企业版, 销售], }, ] def run_evaluation(chat_fn): total len(EVAL_SET) passed 0 for item in EVAL_SET: answer chat_fn(item[question]) ok all(keyword in answer for keyword in item[must_contain]) print(f问题{item[question]}) print(f回答{answer}) print(f结果{通过 if ok else 不通过}\n) passed int(ok) rate passed / total print(f评估通过率{passed}/{total} {rate:.2%}) return ratemust_contain是最简单的自动化断言适合初期版本。更完整的效果评估还应该包括回答相关性人工打分、事实错误标注、格式规范校验。这些工作虽然朴素但它是 AI 工程里唯一能让“效果好坏”从主观感受变成可比较指标的手段。只要评估集还在团队就不会在模型升级时彻底失去方向。4.6 组装入口把模块串起来主流程很清晰先查缓存命中就直接返回没有命中就调用模型路由更新缓存再记录成本。# 文件路径resilient_llm_app/main.py from model_router import ModelRouter from simple_cache import SimpleCache from cost_tracker import log_cost # 这里按 4.2 节的说明填写模型配置 router ModelRouter([...]) cache SimpleCache() def chat(question): messages [{role: user, content: question}] cached cache.get(messages) if cached: return cached answer router.chat(messages) cache.set(messages, answer) log_cost(gpt-4o-mini, question, answer) return answer if __name__ __main__: run_evaluation(chat)到这里一个具备基础抗风险能力的 AI 问答服务就完成了。它不会因为某个模型服务商涨价、断连、或者模型策略调整而完全瘫痪这就是“抗泡沫设计”的起点。5. Token 成本控制的工程手段5.1 成本是怎么悄悄失控的一个普通的 RAG 问答请求会把系统 Prompt、多轮历史、检索到的知识库片段、用户问题全部塞给模型。你以为用户只是问了一句“密码怎么改”实际输入可能已经有一两千个 Token。日活一千的场景一个月的模型调用成本就可能达到数千元。问题往往不是模型本身贵而是调用方式太粗放。5.2 从代码层面可做的四件事命中缓存直接返回。重复问题不重复计费这是收益最明显的优化。控制上下文长度。只传最近两轮对话知识库片段做截断系统 Prompt 定期精简。先小模型后大模型。简单意图识别、关键词分类先用小模型或规则处理只有复杂问题才调用大模型。设置调用上限。例如每个用户每分钟最多调用十次防止异常流量打爆成本。结合上一节的代码只需要在chat方法里先查缓存、再更新成本日志就已经完成了最基本的成本控制闭环。在这个闭环跑通之前先不要急着追求复杂的评测平台和指标系统先把“成本可见、可限流、可追溯”这三件事做好。6. 大模型效果“漂移”与幻觉治理6.1 为什么模型升级后效果反而变差模型服务商不会提前通知你行为变化。同一个问题、同一个 Prompt这周和上周的回答可能完全不同。这种“效果漂移”在泡沫破裂后会更加致命因为预算收缩团队没有足够精力持续监控一旦线上回答质量下降用户流失是不可逆的。应对手段不复杂但需要固定下来锁定模型版本。生产环境不要使用自动指向“最新版”的写法而是明确写版本号。即使价格高一点也要保证行为可预期。每次升级先跑评估集。用上一节的evaluate.py跑一遍评估通过率不低于当前版本再考虑切换流量。保留旧模型路由。把旧版本放在model_configs的备用位置万一新版本翻车可以快速回滚。这里要提醒的是如果你使用 Cursor、PyCharm AI 插件这类 AI 编程工具它们同样面临模型版本更新带来的行为变化。把“生成代码”纳入版本管理通过代码评审和自动化测试把关比信任“AI 编程工具输出一定正确”要靠谱得多。AI 编程的价值在于提效而不是替代验证。6.2 幻觉治理的工程边界大模型的“幻觉”很难被完全消除。工程上能做的是让幻觉可以被发现、被追溯。比较实用的组合是给回答加引用来源。如果模型引用了知识库内容把原文片段一并返回用户可以自己核对依据。关键数据做规则校验。金额、日期、订单号这类强格式字段用正则和数据库校验不要轻信模型输出。高风险场景人工兜底。合同、医疗、财务等场景保留人工审核环节模型只负责起草和摘要。说到底不要试图让模型永远正确而是要让系统在模型出错时也能及时发现问题。这比单纯追求“更高准确率”更有工程价值。7. AI 项目下马前的五个信号与排查清单7.1 五个危险信号信号典型表现可能原因解决思路用户留存低上线一个月活跃用户个位数功能没有嵌入真实工作流重新梳理用户任务和业务系统打通评估靠感觉团队说不清效果是变好还是变差缺少评估集和回归机制先建最小评估集再继续迭代成本不可控月底账单远超预算没有缓存、没有限量、上下文过长加缓存、控长度、设置调用上限模型升级就崩同一套 Prompt 换模型后效果大变缺少模型版本锁定和回归流程固定版本升级前跑评估集没有降级方案模型服务抖动时功能完全不可用没有备用模型和兜底逻辑配置多模型路由增加关键词兜底7.2 排查思路如果项目已经出现了多个信号建议按下面的顺序排查不要一上来就换模型。先看业务数据。用户到底在什么场景下使用留存低是入口问题还是回答质量的问题。再看链路数据。打开日志确认每次请求的响应时间、Token 消耗、缓存命中率。最后再动模型。确认数据和链路没有问题后再考虑调整 Prompt 或更换模型。这个顺序的意义在于模型只是 AI 应用链路里的一环。把精力放在数据、链路和评估上效果提升通常比单纯换模型更稳定。反过来如果项目已经连续几个迭代周期拿不出效果数据那就应该果断收缩范围把资源集中到少数有明确指标的功能上。8. 泡沫之后AI 工程师可以沉淀什么8.1 真正能沉淀下来的四类能力如果 AI 泡沫破裂受影响最大的会是三类人只会写 Prompt 的“套壳型”开发者、只会调 API 不愿碰数据的“调用型”开发者以及没有业务判断力的“模型崇拜型”开发者。反过来有四类能力在任何市场周期里都有价值。数据工程能力清洗数据、构造知识库、做数据质量校验。所有 AI 应用的上限都由数据决定。应用工程能力把模型调用嵌入业务流程设计缓存、降级、重试、监控保证系统稳定。评估反馈能力建设评估集、指标看板、线上回归机制让效果可以被度量、被回溯。成本与资源意识用最合适的