Skip to content

20 · 演进剧本:MVP 到规模化

一句话点题:19 章 设计出的「第一版」,绝不会是它最终的样子。这一章跟着同一个 AI 客服走完它的三段人生——看它怎么被量化信号一段段推着长大,而每一次「该不该动」,都用尺子量、不靠拍脑袋。


🎯 实战篇第 3 章 · 本章只练一件事

演进判断:不是「怎么设计」,而是「什么时候该升级、什么时候按住别动」。承接 08 章(ADR + 何时升级)和 附录 · 演进触发信号,把它们落到 19 章 那个 AI 客服上。

读完你应该能本章靠什么练
用量化信号(而非感觉)判断何时升级三段之间的「触发信号」
给每次升级写一条 ADR三条样例 ADR
看懂 AI 系统演进特有的两个信号成本漂移 + 质量漂移

开场:别拿成熟期的图去套 MVP

07 章 那句话,在 AI 系统上更要命:架构是会长大的,别一上来就照着「千万级、多租户」的终极形态去盖。 19 章 画的那张图,是你心里的目标,不是第一天上线的样子

真实世界里,这个 AI 客服会这样长大:

   第一段:MVP            第二段:成长期           第三段:规模化
   ┌──────────┐  成本/   ┌──────────┐  多租户/  ┌──────────┐
   │ 调 API   │  延迟/    │ +路由+缓存│  容灾/    │ +网关+多活│
   │ 纯向量RAG │  投诉     │ +混合检索 │  质量漂移  │ +eval门禁 │
   │ 退款全人工│ ───────▶ │ +小额自动 │ ───────▶ │ +多租隔离 │
   └──────────┘  信号触发  └──────────┘  信号触发  └──────────┘
        ▲                                              │
        └──────── 每一步都被「真实信号」推着走,不是被「感觉」推 ──────┘

本章的纪律(也是 09 章 的品味):没有信号,就别动。 没触发还要升级,十有八九是过度设计或追新。下面三段,每段都先给触发信号,再给升级动作,最后落一条 ADR


第一段 · MVP:能调 API 就别自建,能人工就别自动

目标只有一个:验证「AI 客服」这件事到底有没有人用、答得靠不靠谱。 所以越糙越好:

维度MVP 怎么搭(刻意从简)
模型直接调某厂商的 API,不自建 GPU
RAG现成框架 + 固定大小切块 + 纯向量检索,先跑通
会话客户端带历史,服务端无状态、好扩展
退款模型只答问,不自动退——动钱的事,先让人工点确认
省钱先不做路由 / 缓存 —— 先证明有人用,再谈省钱

注意最后两行:MVP 把「最危险的事」直接交给人。这不是偷懒,是 19 章「把不确定性挡在副作用之外」的最极端、也最省事的版本——人就是那道闸门。等量大了,再把「安全的部分」自动化。

这一版欠了一屁股有意识的技术债(没缓存、没路由、切块粗糙、退款靠人肉)——但 08 章 说过:MVP 故意欠债往往是对的,只要你知道自己欠了、并记下来。

第一条 ADR(把「为什么这么糙」记下来):

┌────────────────────────────────────────────────────────────┐
│  ADR-001:MVP 阶段用托管模型 API,不自建推理                  │
├────────────────────────────────────────────────────────────┤
│  状态:已采纳    日期:(上线前)    决策者:架构组            │
│                                                              │
│  ── 背景 ──                                                  │
│  产品还在验证「AI 客服有没有人用」,流量未知,团队没有        │
│  GPU 运维经验。此刻最大的风险是「做了没人用」,不是「太贵」。  │
│                                                              │
│  ── 决策 ──                                                  │
│  调用托管模型 API;RAG 用现成框架;退款由人工确认。           │
│  把降本(路由/缓存/自建)与自动化退款,显式推迟。            │
│                                                              │
│  ── 考虑过的其它选项 ──                                      │
│  A. 一上来自建 GPU + 连续批处理 → 否决:没流量就自建 = 烧钱   │
│     的过度设计,也拖慢上线                                    │
│  B. 让模型自动退款 → 否决:没跑通、没监控就让 AI 碰钱,太险   │
│                                                              │
│  ── 取舍与后果 ──                                            │
│  + 最快上线、最低风险、把钱的事交给人最安全                  │
│  − 单 token 成本偏高、退款靠人不可规模化(已知债,见触发信号)│
└────────────────────────────────────────────────────────────┘

触发信号 ① → 第二段 · 成长期

MVP 跑通了,用户涨起来,这几个信号同时亮红灯——这才是升级的资格,不是「老板说要更智能」:

你量到的信号(经验区间)说明大概率瓶颈
月度模型账单超预算(如冲到预算 1.5×)AI 特有!token 烧太狠没路由、没缓存,简单问题也用大模型
首字延迟 P99 超标(用户等得烦)体验层信号(演进触发信号)模型调用慢 + 无缓存
「答非所问」投诉率 > 阈值AI 特有!检索拉胯 → 幻觉纯向量 + 粗切块,召回不准
人工退款队列积压(人审被淹)组织/效率信号退款全靠人,扛不住量

升级动作(一次只解被卡住的,别一次重构全家桶):

   MVP                              成长期
   ───                              ─────
   纯向量 + 粗切块      ──▶  混合检索(向量+关键词) + 重排 + 按语义切块
   每轮重算系统提示     ──▶  prompt 缓存(系统提示/知识前缀不重算)
   大模型通吃           ──▶  模型路由:FAQ→小模型,复杂问题才上大模型
   客户端带历史         ──▶  会话存服务端(跨设备、可做长期记忆)
   退款全人工           ──▶  小额低风险退款「自动化」(19 章那道幂等闸门),
                            大额仍走人审
   (没有评测)          ──▶  建第一个 eval 集:盯检索召回率 + 答案质量

注意「小额自动化退款」:这正是把 19 章 设计的那道确定性 + 幂等 + 状态机闸门真正用起来——人审从「每一笔」缩小到「只看大额」,既扛住了量,又守住了钱。

两条 ADR(挑成本和退款两个最关键的记):

┌────────────────────────────────────────────────────────────┐
│  ADR-002:引入模型路由 + prompt 缓存(成本触发)              │
├────────────────────────────────────────────────────────────┤
│  状态:已采纳    背景:月账单冲到预算 1.6×,FAQ 类占咨询 70%, │
│        却全用大模型。                                        │
│  决策:简单 FAQ / 命中知识库的问题路由到小模型或直接走        │
│        语义缓存;只有复杂问题上大模型 + 缓存系统提示前缀。     │
│  其它选项:A. 直接换更便宜的大模型 → 质量不达标;             │
│            B. 砍掉 RAG 省 token → 幻觉飙升,不可接受。        │
│  取舍:+ 单轮成本大幅下降;− 路由判断本身要调优,偶有错路由。 │
└────────────────────────────────────────────────────────────┘

┌────────────────────────────────────────────────────────────┐
│  ADR-003:小额退款自动化,大额保留人审(队列积压触发)        │
├────────────────────────────────────────────────────────────┤
│  状态:已采纳    背景:人工退款日均积压数小时,体验差且不可扩。│
│  决策:金额 ≤ ¥500 且订单状态校验通过的退款,由确定性退款服务 │
│        幂等执行;> ¥500 仍进人审队列。模型只「提议」,不执行。 │
│  其它选项:A. 全自动退款 → 否决:大额错退代价不可逆;         │
│            B. 维持全人工 → 否决:已被信号证明扛不住。         │
│  取舍:+ 人审量骤降、体验变好;− 阈值要随风控数据调,         │
│        且必须有对账兜底防自动化出错。                        │
└────────────────────────────────────────────────────────────┘

💡 看 ADR-002 和 ADR-003 的「背景」栏——全是量化信号,没有一句「感觉该升级了」。 这就是 08 章 那把尺子。


触发信号 ② → 第三段 · 规模化

成长期稳住后,生意做大,新一类信号出现——很多是 AI 系统、多租户系统特有的:

信号说明瓶颈
接入多个商家租户各家知识库不能串味、不能互相检索到缺租户隔离
单一模型 provider 抽风,全站客服瘫可用性上台阶(演进触发信号:消灭单点)模型调用是 SPOF
换模型 / 改提示后,线上质量悄悄退化AI 特有!非确定性导致的质量漂移没有 eval 当门禁
大促洪峰 + 成本继续摊大规模化的力学(13 章)单区域、无弹性

升级动作:

   成长期                            规模化
   ─────                            ──────
   直连一个 provider     ──▶  AI 网关:多 provider 故障转移 + 统一计费限流
                              + 语义缓存(对应 ai-gateway 模板)
   单一知识库            ──▶  多租户隔离:知识库按租户命名空间,
                              检索强制按租户过滤(不能跨租户召回)
   eval 集靠人手跑       ──▶  eval 当 CI 门禁:换模型/改提示先过评测,
                              分数掉了不许上线(防质量漂移)
   单区域                ──▶  多活 + 弹性扩缩(扛大促)
   日志靠 grep           ──▶  全链路 trace:每轮的检索/路由/工具/token 可回放

第三段最关键的一条 ADR——也是 AI 系统演进独有的:

┌────────────────────────────────────────────────────────────┐
│  ADR-005:eval 评测集纳入 CI 门禁(质量漂移触发)             │
├────────────────────────────────────────────────────────────┤
│  状态:已采纳                                                │
│  背景:上次升级模型版本后,某类政策问题答案悄悄变差,两周后    │
│        才从投诉里发现。非确定性让「质量退化」无法靠传统断言    │
│        发现(同样输入未必同样输出)。                         │
│  决策:维护一个代表性「问题→期望要点」评测集;换模型、改提示、 │
│        改检索策略前,CI 跑 eval(规则 + LLM-as-judge 打分),  │
│        分数低于基线一律拦截,不许上线。                       │
│  其它选项:A. 靠人工抽查 → 否决:漏、慢、不可持续;           │
│            B. 锁死模型版本不升级 → 否决:放弃模型进步红利。   │
│  取舍:+ 把「够好」量化、挡住悄悄退化;                       │
│        − 要持续维护评测集、评分本身有成本(这是 22 章的主题)。│
└────────────────────────────────────────────────────────────┘

架构智慧:传统系统靠「同样输入 → 同样输出」的断言守质量;AI 系统这块地基被抽走了(17 章),只能用「评测集 + 评分」守一个分布。 所以「eval 当门禁」对 AI 系统不是锦上添花,而是演进期防退化的刹车——没有它,你每次「升级模型」都是在闭着眼睛赌。


一张总表:信号 → 升级 → ADR

阶段触发信号升级动作ADR
MVP(上线起点)调 API、纯向量 RAG、退款人工ADR-001
→ 成长账单超预算 / P99 超标 / 投诉率高 / 人审积压路由+缓存、混合检索+重排、会话上服务端、小额退款自动化、建 eval 集ADR-002/003
→ 规模化多租户 / provider 单点 / 质量漂移 / 大促AI 网关容灾、多租户隔离、eval 进 CI 门禁、多活、全链路 traceADR-004/005

两个 AI 系统演进独有**、传统系统没有的信号,务必盯死:**

  1. 成本漂移:token 账单会随规模线性甚至超线性地烧。普通系统「先上线再优化成本」没事,AI 系统不盯成本,毛利说没就没
  2. 质量漂移:模型版本、提示、检索策略任一变动,质量可能悄悄退化且无声无息。必须用 eval 当门禁主动盯。

🎯 随堂检验

🤔AI 客服上线后想升级架构,以下哪个才是「该动手」的合格依据?
  • A团队觉得现在的代码不够「AI 原生」,该重构得更高级
  • B月度 token 账单冲到预算 1.6×、且 FAQ 类占 70% 却全用大模型——成本被真实瓶颈卡住
  • C看到友商上了多 Agent,我们也该上
🤔为什么「eval 评测集进 CI 门禁」对 AI 系统的演进特别重要,而传统系统较少需要?
  • A因为 AI 系统代码更复杂
  • B因为 AI 系统是非确定性的:同样输入未必同样输出,传统的「断言相等」失效,换模型/改提示后质量可能悄悄退化,只能用评测集+评分守住质量分布
  • C因为 CI 跑得更快

本章小结

  • 别拿成熟期的图套 MVP:同一个 AI 客服有三段人生——调 API 的 MVP → 加路由/缓存/混合检索/小额自动退款的成长期 → 加网关/多租户/eval 门禁/多活的规模化。
  • MVP 把最危险的事交给人:退款先全人工,是「把不确定性挡在副作用之外」最省事的版本;量大了再把安全的部分自动化。
  • 每段升级都由量化信号触发,不靠感觉:账单、P99、投诉率、人审积压、provider 单点、质量漂移——没信号就别动(08/09 的品味)。
  • 每次升级写一条 ADR:背景栏全是信号,这就是判断的留痕。
  • AI 系统演进独有两个信号:成本漂移(token 线性烧)和质量漂移(非确定性导致悄悄退化)——分别用「成本盯控 + 模型路由」和「eval 当门禁」来管。

承上启下:走到规模化末段,你会发现一个新麻烦:编排、RAG、工具、计费、退款……当初为了快,全揉在一个部署单元里。现在改一处动一片、谁都不敢动、多团队互相阻塞——这是 演进触发信号 里「组织/效率」那一类红灯。下一章 21 · 拆分与迁移实战,我们就给这个飞行中的 AI 客服换引擎:用 14 章 的绞杀者、并行运行、零停机迁移,把它一块块安全拆开。


相关链接

💬 评论