做系统设计这件事，后端程序员通常心里多少有些底：高并发订单怎么拆状态，缓存怎么失效，消息队列怎么削峰……一碰到“AI系统设计”，很多人却会卡住。这也是我写下这篇的原因。它不讲算法推导，只讲程序员的视角如何补上这块短板——当你面对一个需要“智能”来处理核心逻辑的系统时，该怎么把数据、模型、服务、监控串成一个完整可交付的工程方案。如果你是后端、全栈或者客户端开发，平时会用模型接口、也会写服务，正在为系统设计评审或者内部项目前期方案做准备，那么这一篇可以直接当作你的答题框架。全文整个思路浓缩成一句话：AI 系统设计不是选一个最牛的模型，而是把带有不确定性的概率输出，装进一个可测试、可回滚、可监控的确定性工程外壳里。1. 先想清楚：程序员补AI系统设计，补的是哪一块1.1 为什么画链路图很容易，落到工程细节却漏掉大半很多程序员的习惯是：先画一个框写“模型”，输入从左边进，结果从右边出，然后就开始讨论用什么模型。等到评审追问几个细节，才会发现自己漏了一大半。训练样本从哪来、怎么清洗、怎么标注、如何保证不同批次样本不互相污染？模型离线指标可接受，但上线后的业务指标如何对齐？服务在线时不只调用模型接口，还要做预处理、后处理、缓存、降级，这些谁负责？模型几个月后准确率下滑，怎么发现、怎么重训、怎么小流量替换？这些问题不是单纯算法同学能覆盖的，而是成熟 AI 系统的数据-服务闭环。传统后端那种“确定性”的方案在这个闭环里会失效，因为线上的真实环境里，模型输出的是概率，而不是一个个可断言的返回值。所以“补”的其实是对不确定性的感知：我该在哪些接口上做容错，该盯哪些指标做监控，数据哪天变了应该如何感知。把这些想明白，AI 系统设计的骨架才算立住。1.2 三个本质差异，先给系统设计“换脑子”用一个表格对比，最快理解差异：维度传统后端AI 系统输出给定输入，输出固定概率性输出，置信度可能变化错误模式逻辑错误修完就不再出现错误样本分布会变，必须靠评估集兜底容量规划主要靠流量模型，增长可预测除了流量，数据分布的变异也会改变成本质量保证单元测试、断言、集成测试离线评估、线上抽样、灰度对比传统后端里，代码变更完，测试不通过就回滚，事情可以收得很干净。AI 系统则经常出现离线指标很好，线上却翻车的情况。更麻烦的是会出现“行为的漂移”：用户表达方式变了、业务规则变了、同一条数据在不同时间点跑，结果都可能不一样。所以程序员做 AI 系统设计时，最该练的不是调参技巧，而是区分“系统故障”和“模型退化”。前者靠监控系统、服务降级就能救回来，后者靠数据回流、定期重训、灰度切换来兜底。两者得用一套闭环支撑，缺一边都会让工程非常被动。2. 从业务目标到系统指标：AI系统设计的前两步，永远和模型无关2.1 先谈评估口径，再聊模型我见过不少项目，“准确率差不多就行”这句话一说出来，后面的设计边界就散了。准确率是一个不错的底线指标，但业务永远不止关心准确率。拿客服工单分类举例，四类工单占比如果明显不均衡，A 类占 90%，B、C、D 加起来才占 10%，那一个只输出“A 类”的模型就可以拿到 90% 的准确率。它把 B、C、D 全部塞给 A 客服团队，等于什么都没做。正确做法是先把业务约束翻译成指标矩阵：主要业务指标：分类正确率；细分指标：各类别的查准率/查全率，尤其是少数类；线上一致性指标：人工改派率、用户重复提交率、平均客服处理时长；服务指标：P95 延迟、失败率、回退率。评估模型之前，要把这些写进设计文档。指标定下来之后，模型选哪个自然就有筛选清单了，因为候选模型都要跑在同一个评估集上，比谁的指标线更稳，而不是比谁的单点指标更高。另外一个特别便宜的建议是：先做一个规则基线，用关键词和正则把简单样本吃掉。它成本极低，还能给模型一个对比槽位——如果后期模型连规则都不如，说明数据或训练有问题，这时候不该硬上线。2.2 样本设计：先定数据版本，再谈样本均衡决定模型上限的往往不是模型结构，而是训练样本。样本设计里有两种常见坑：一是不同时间段的样本混在一起随机切分，模型用未来数据“预测”过去，离线指标虚高；二是标注员之间的标准不一致，让模型学到带噪声的标签，能力被带偏。正确操作按顺序说：按时间线切分数据：近期历史数据做训练，更晚一段做验证和测试。这能模拟模型上线后会面对的真实场景，宁可牺牲一点离线分数。训练集可以做类别平衡，比如少数类过采样；但验证/测试集保持自然分布，这样线上指标的预判才不容易乐观。每条数据保留原始 ID、采集时间、脱敏后的标记，在训练配置里引用数据集版本，并把数据处理脚本的哈希值一起锁进实验记录。这些内容写进设计文档，代表你是一个严格的工程实践者，也能避免评审会问到“数据版本是什么”的时候现场翻找。2.3 模型选型的朴素框架：从“能不能降级”出发很多程序员面对模型选择，多少会有点“选最大最强”的情节。从工程可用性来说，选型层级应该是自底向上的兜底阶梯：规则筛选：能秒回的场景绝不进模型；轻量分类模型：文本语义相对单一、样本到万级，先跑通再优化；深度文本模型：数据充足、句子复杂，离线收益明显；大模型接口：新业务冷启动、复杂推理需求，同时考虑成本、限流和延迟。我长期在项目里先做两层，用规则加轻量模型的架构跑通整个链路，再把深度模型放上去对比。这样最坏情况下系统仍然可用，又不会因为依赖高复杂度模型导致上线后不可控。另一个关键点是先把处理的业务范围收窄：别指望一个模型接口消化所有场景，而是分流——简单规则先拦，常规文本进小模型，疑难样本再走大模型兜底。顺便也能控制住成本。2.4 基础设施：CPU/GPU的账，从延迟和利用率两个角度算AI 系统需要用到 GPU，但不代表所有服务都要上 GPU。训练和推理的资源规划差异非常大：训练阶段：对延迟容忍度高，重点看 GPU 利用率，可以少量大实例长时占用；推理阶段：对延迟敏感，实例要按 QPS 弹性扩缩，GPU 利用率反而常被批处理参数影响。常见问题是我见过不少团队部署了 8 卡实例，QPS 只有两位数，GPU 利用率不到百分之十。这不是模型问题，是系统设计问题——推理请求串行直连、批处理没开，显卡看起来在工作，实际大部分时间在空转，成本烧得很冤枉。省钱的办法有两个：一是批量拼接请求，把互相独立的请求合到同一批里，提高算子效率；二是对延迟不敏感的接口，动态调大 batch，用一点延迟换吞吐。把这些量化指标写进方案，比空谈“使用 GPU 加速”有说服力得多。3. 核心架构怎么搭：数据、训练、推理、迭代四段闭环既然 AI 系统不能靠一次上线就结束，架构设计就必须把“更新和回退”当成一等公民。整个系统的最简闭环分成四段：数据管线、训练实验、推理服务、监控迭代。3.1 数据管线：先让脏数据死在门口，不要拖到模型训练数据管线是把原始事件变成可训练样本的第一道关卡。常见环节是采集、脱敏、清洗校验、切分流、统一格式存储。很多项目只写了“采集+存储”，漏掉了“校验”，结果数据字段改了名，训练脚本照样跑，模型效果却悄悄往下掉。实测比较可靠的套路是：数据校验脚本在采集后立刻运行，字段缺失率、长度分布、文本重复率都要设置阈值，超阈值直接告警；原始文本先脱敏再落存储，避免隐私问题；特征和样本按“数据集名+版本号”的路径保存，训练任务只认版本号，不认路径。这些功能写起来不难，难点在于你有没有把它当作设计的一部分。评审会上如果只讨论模型，不讨论数据管线，有两层可能：一种是你讲得足够顺，别人没机会打断；另一种是大家都觉得这个系统还没达到“系统”的门槛。3.2 训练实验：代码版本、数据版本、配置、模型产物四个数字必须对上程序员对代码版本管理很熟练，但“训练实验”管理经常很原始。模型不是直接拉出来的一个包，而是“数据 + 配置 + 训练代码”共同产生的产物。如果这四个要素没有记录，过一个月你根本说不清线上这个模型为什么比上一个好、好在哪里。建一套最小闭环：每次训练生成一个实验 ID，统一记录：训练代码哈希、数据版本号、模型配置参数；训练结束自动生成评估报告，包括整体指标、各分类指标、错误样本抽样；模型产物上传到模型仓库，命名带上实验 ID，避免“model_v2_final”这种无语义命名；训练 GPU 资源池化，避免几个人抢卡导致随机失败。这套机制不炫酷，但能让每一次模型更新都可解释、可回溯。系统设计评审听到这一层，评价通常不错。3.3 推理服务：QPS、延迟、Batch、缓存是同一个数学问题模型推理服务设计的开端是容量评估。业务给的日请求量，先换算成高峰 QPS，再留出峰值倍数和容错冗余。公式不复杂：峰值 QPS = 日均 QPS × 峰值因子。拿客服工单举例，日均 1 万请求、高峰集中在 8 小时，平均 QPS 大概是 1 万除以 8 小时的秒数，约等于 0.35，峰值因子给 4 倍，也只有 1.4 QPS。很多场景从容量上根本不需要太豪华的实例。但服务上线后，真正的账在批处理。请求进模型接口时，不是每个请求都能独立占满一次推理，把多个样本拼成一批去跑，总时延增加不多，但吞吐成本会明显下降。工程做法是做一个“批处理聚合线程”：请求先进入队列，循环里攒够 N 条或等待 M 毫秒后，再一次性发给模型，然后把结果分发给队列里的所有请求。另外两个细节容易被漏：预热：模型加载后的首次推理会很慢，老接口可不想等它，因此上线流量进入前要跑一遍预热请求；缓存：完全相同的文本在短期内重复出现的概率很高，比如用户反复提交、客服查看同样工单，缓存命中率往往不错，所以缓存要作为服务设计的一部分，而不是后续优化项。3.4 在线监控与模型更新：不能只盯“调用失败”和“P95”AI 系统的监控要分两层，系统指标是一层，数据和业务指标是另一层。只看错误率和 P95 延迟，看不出来模型效果正在失效。我在生产环境里长期监控四个额外指标：模型回退率、平均置信度、标签类别分布变化、人工改判率。模型回退率：模型服务没报错，但规则层拦截了大量请求，说明模型对这批输入已经不太靠谱，分布可能正在变化；平均置信度：整体置信度持续下滑，往往是数据漂移的信号；类别分布变化：线上预测比例和训练样本分布产生明显偏差，可能是业务规则已经变了；人工改判率：客服手工改派的比例上升，这是最接近业务真实反馈的信号。模型更新必须走灰度路径。新模型先部署到部分流量，比如 10%，跑影子比较：同一份请求同时交给新旧模型，对比输出差异，确认大盘指标没有回退，再逐步扩大流量。把这条链路跑通之后，发一次模型版本会从“事故级操作”变成常规更新。4. 完整案例：客服工单自动分类系统的设计全过程为了让前面的框架足够具体，我模拟一个相对真实的场景：某公司每天上万条客服工单，希望用系统自动判断工单类型并分派到对应客服队列。这就是典型的“文本分类 + 分布式服务”AI 系统设计题。4.1 先把约束和业务目标固化成表格我会把需求固化成下面这张表：条目数值工单类型4 类（A、B、C、D）日工单量约 1 万条日均 QPS0.35（集中在 8 小时）峰值 QPS按 4 倍估算，约 1.5目标准确率整体 ≥ 92%，D 类查准率 ≥ 85%P95 延迟≤ 500ms失败降级规则兜底，不允许单点不可用这里所有数字都来自需求对齐，尤其是“D 类查准率 ≥ 85%”这条，是为了避免类别不均衡把少数类吞掉。如果不写这一条，系统做成“什么都是 A”也能拿到 92% 准确率，但线上会变成问题。这个系统的设计目标首先是满足这七行数字，而不是“用上了最新模型”。4.2 数据和标注方案：少而准，好过全而乱先拿到近 30 天的历史工单，大概是 5 万条。按时间切分：前 21 天做训练，后 9 天做验证和测试，而不是随机切。再抽一部分做人工清洗，去掉口语气和冗余信息，统一简繁体，把文本里的姓名、电话等身份信息全部脱敏。标注环节最怕不一致。我习惯安排两位有业务经验的同学各自标注，然后计算两人对同一批样本的标注一致率，低于某个阈值（一般看 Kappa 值）的样本重新讨论，统一标完之后把结论写进标注规范文档。整个样本量哪怕只有几千条也没关系，先建立稳定基线，后续再把线上反馈样本回流进来，逐步优化。4.3 服务架构和模型落地方案这套系统里我采用分层五段式设计：接入层、规则层、缓存层、模型层、兜底层。接入层负责解析、鉴权、接口校验；规则层通过正则和关键词能直接识别的工单直接返回结果；缓存层对同一文本内容做快速命中；模型层跑小型文本分类模型，支持批处理和动态池化；兜底层设置默认分类和“转人工”标记，保证任何情况下都有结果。代码结构可以参考下面这种模式：class TicketClassifier: def __init__(self, model_adapter, rule_engine, cache): self.model_adapter = model_adapter self.rule_engine = rule_engine self.cache = cache def classify(self, ticket): text = self.preprocess(ticket.content) rule_result = self.rule_engine.match(text) if rule_result is not None: return rule_result cached = self.cache.get(text) if cached is not None: return cached result = self.model_adapter.predict([text], batch_size=16)[0] self.cache.set(text, result, ttl=600) return result代码本身不复杂，真正的工程难点在 model_adapter 内部的批处理和超时控制。模型推理调用必须设置清晰超时，比如主超时 700ms，超时即回退到规则层结果，并在监控指标里增加“模型超时回退”计数。设计文档里应该写清楚“模型不可用时的行为是什么”，而不是笼统地说“增加节点”。4.4 压测、灰度、回滚：没有这三样就不算完整交付服务上线前的压测必须做。用线上脱敏数据回放，按峰值 QPS 的 4 倍作为压测目标，同时人为给模型接口注入延迟，验证规则兜底是否顺利生效、缓存命中是否正常。压测结束后，有两件事容易被忽略：清空旧缓存，然后用预热脚本把常用类别的模型权重加载进内存。否则正式流量一进来，前几分钟的 P95 延迟会非常难看。上线时走灰度：新模型只接 10% 流量，观察人工改派率和模型回退率两个线上指标。旧模型实例保持运行至少一周，任何一轮指标超标，直接切回旧模型，同时重置新模型产生的缓存。这样即便新模型上线后完全失效，也不需要回退模型文件，只需要把路由重新指回旧版本。这套切换动作能覆盖绝大多数发布事故。5. 踩坑记录：常见问题与排查技巧5.1 高频故障速查表整理几个我自己最常遇到的现象：现象可能原因优先排查方式延迟从 200ms 涨到 2s并发升高导致批处理队列堆积，或批量参数过小看 QPS、队列长度、GPU 利用率和 batch 大小线上准确率持续下滑数据漂移：新用户说法、新商品、业务规则变化按周切分测试集做回归评测，对比类别分布服务内存持续增长模型加载多份、旧模型没卸载、缓存没设过期时间查看进程内模型数量、缓存命中率和 TTL 配置发新模型后指标反而变差评估集与真实分布不一致，或模型排序变化同一批请求跑新旧模型 shadow 对比发布后首次请求“卡死”模型预热缺失，或刚扩容后实例状态是冷的增加启动预热脚本，完成后才接流量纯后端直觉在这些问题上容易跑偏。比如延迟从 200ms 涨到 2s，很多后端第一反应是加机器。但在 AI 服务里，这一般是批处理被打散或者 GPU 利用率不足，加机器反而更贵更低效。先确认 batch 是否稳定，再看实例数量和短瞬并发是否匹配。准确率下滑也不一定要立即重训。优先检查规则拦截率有没有升高，如果明显升高，说明输入分布变了；再检查平均置信度的趋势，确认是模型退化还是只是评估口径变了。定位清楚之后再决定是重训、回滚，还是单纯更新规则。5.2 一份可以直接带进评审的AI系统设计自检清单我反复被问过、也反复问过别人，最后沉淀出八个问题。建议在做方案前先自己答一遍：业务目标对应哪些线上指标？指标允许差到什么程度？离线评估集是怎么切分的？有没有做时间顺序验证？训练数据集版本号、清洗脚本哈希是否已经记录？模型选型是否从规则、轻量模型、深度模型到大模型接口逐级排过？模型接口的超时值是多少？调用失败会落到哪个降级动作？推理实例如何处理批处理、预热、缓存过期？模型更新如何灰度？如果不通过，怎么快速回滚？监控指标里是否包含回退率、置信度、类别分布、人工改判率？这八条不会直接问“模型结构是什么”，但任何一条答不好，AI 系统设计都不好圆过去。建议拿一个熟悉的业务场景，按这八条走通一遍，做到细节都能说清楚。这不是为了应付面试，而是设计真实系统时最靠谱的底线。做多了 AI 系统设计之后，我的体会是它并没有想象中那么“玄”。它只是传统系统设计多了一个必须时刻处理的“不确定性维度”。以前测试通过就是通过，现在做 AI 系统，还要接受数据会变、输出会漂、模型会被业务淘汰。但这些冗余说到底都是工程问题，可以用数据版本、灰度、监控、回退这些老办法兜住。最后分享一个我常用的练习：找一个小场景，从指标定义、样本设计、服务降级、上线回滚各写一小段方案，然后对照自检清单改一遍。把这条路走通，再遇到 AI 系统设计，你就不会心里没底了。
做系统设计这件事，后端程序员通常心里多少有些底：高并发订单怎么拆状态，缓存怎么失效，消息队列怎么削峰……一碰到“AI系统设计”，很多人却会卡住。这也是我写下这篇的原因。它不讲算法推导，只讲程序员的视角如何补上这块短板——当你面对一个需要“智能”来处理核心逻辑的系统时，该怎么把数据、模型、服务、监控串成一个完整可交付的工程方案。如果你是后端、全栈或者客户端开发，平时会用模型接口、也会写服务，正在为系统设计评审或者内部项目前期方案做准备，那么这一篇可以直接当作你的答题框架。全文整个思路浓缩成一句话：AI 系统设计不是选一个最牛的模型，而是把带有不确定性的概率输出，装进一个可测试、可回滚、可监控的确定性工程外壳里。1. 先想清楚：程序员补AI系统设计，补的是哪一块1.1 为什么画链路图很容易，落到工程细节却漏掉大半很多程序员的习惯是：先画一个框写“模型”，输入从左边进，结果从右边出，然后就开始讨论用什么模型。等到评审追问几个细节，才会发现自己漏了一大半。训练样本从哪来、怎么清洗、怎么标注、如何保证不同批次样本不互相污染？模型离线指标可接受，但上线后的业务指标如何对齐？服务在线时不只调用模型接口，还要做预处理、后处理、缓存、降级，这些谁负责？模型几个月后准确率下滑，怎么发现、怎么重训、怎么小流量替换？这些问题不是单纯算法同学能覆盖的，而是成熟 AI 系统的数据-服务闭环。传统后端那种“确定性”的方案在这个闭环里会失效，因为线上的真实环境里，模型输出的是概率，而不是一个个可断言的返回值。所以“补”的其实是对不确定性的感知：我该在哪些接口上做容错，该盯哪些指标做监控，数据哪天变了应该如何感知。把这些想明白，AI 系统设计的骨架才算立住。1.2 三个本质差异，先给系统设计“换脑子”用一个表格对比，最快理解差异：维度传统后端AI 系统输出给定输入，输出固定概率性输出，置信度可能变化错误模式逻辑错误修完就不再出现错误样本分布会变，必须靠评估集兜底容量规划主要靠流量模型，增长可预测除了流量，数据分布的变异也会改变成本质量保证单元测试、断言、集成测试离线评估、线上抽样、灰度对比传统后端里，代码变更完，测试不通过就回滚，事情可以收得很干净。AI 系统则经常出现离线指标很好，线上却翻车的情况。更麻烦的是会出现“行为的漂移”：用户表达方式变了、业务规则变了、同一条数据在不同时间点跑，结果都可能不一样。所以程序员做 AI 系统设计时，最该练的不是调参技巧，而是区分“系统故障”和“模型退化”。前者靠监控系统、服务降级就能救回来，后者靠数据回流、定期重训、灰度切换来兜底。两者得用一套闭环支撑，缺一边都会让工程非常被动。2. 从业务目标到系统指标：AI系统设计的前两步，永远和模型无关2.1 先谈评估口径，再聊模型我见过不少项目，“准确率差不多就行”这句话一说出来，后面的设计边界就散了。准确率是一个不错的底线指标，但业务永远不止关心准确率。拿客服工单分类举例，四类工单占比如果明显不均衡，A 类占 90%，B、C、D 加起来才占 10%，那一个只输出“A 类”的模型就可以拿到 90% 的准确率。它把 B、C、D 全部塞给 A 客服团队，等于什么都没做。正确做法是先把业务约束翻译成指标矩阵：主要业务指标：分类正确率；细分指标：各类别的查准率/查全率，尤其是少数类；线上一致性指标：人工改派率、用户重复提交率、平均客服处理时长；服务指标：P95 延迟、失败率、回退率。评估模型之前，要把这些写进设计文档。指标定下来之后，模型选哪个自然就有筛选清单了，因为候选模型都要跑在同一个评估集上，比谁的指标线更稳，而不是比谁的单点指标更高。另外一个特别便宜的建议是：先做一个规则基线，用关键词和正则把简单样本吃掉。它成本极低，还能给模型一个对比槽位——如果后期模型连规则都不如，说明数据或训练有问题，这时候不该硬上线。2.2 样本设计：先定数据版本，再谈样本均衡决定模型上限的往往不是模型结构，而是训练样本。样本设计里有两种常见坑：一是不同时间段的样本混在一起随机切分，模型用未来数据“预测”过去，离线指标虚高；二是标注员之间的标准不一致，让模型学到带噪声的标签，能力被带偏。正确操作按顺序说：按时间线切分数据：近期历史数据做训练，更晚一段做验证和测试。这能模拟模型上线后会面对的真实场景，宁可牺牲一点离线分数。训练集可以做类别平衡，比如少数类过采样；但验证/测试集保持自然分布，这样线上指标的预判才不容易乐观。每条数据保留原始 ID、采集时间、脱敏后的标记，在训练配置里引用数据集版本，并把数据处理脚本的哈希值一起锁进实验记录。这些内容写进设计文档，代表你是一个严格的工程实践者，也能避免评审会问到“数据版本是什么”的时候现场翻找。2.3 模型选型的朴素框架：从“能不能降级”出发很多程序员面对模型选择，多少会有点“选最大最强”的情节。从工程可用性来说，选型层级应该是自底向上的兜底阶梯：规则筛选：能秒回的场景绝不进模型；轻量分类模型：文本语义相对单一、样本到万级，先跑通再优化；深度文本模型：数据充足、句子复杂，离线收益明显；大模型接口：新业务冷启动、复杂推理需求，同时考虑成本、限流和延迟。我长期在项目里先做两层，用规则加轻量模型的架构跑通整个链路，再把深度模型放上去对比。这样最坏情况下系统仍然可用，又不会因为依赖高复杂度模型导致上线后不可控。另一个关键点是先把处理的业务范围收窄：别指望一个模型接口消化所有场景，而是分流——简单规则先拦，常规文本进小模型，疑难样本再走大模型兜底。顺便也能控制住成本。2.4 基础设施：CPU/GPU的账，从延迟和利用率两个角度算AI 系统需要用到 GPU，但不代表所有服务都要上 GPU。训练和推理的资源规划差异非常大：训练阶段：对延迟容忍度高，重点看 GPU 利用率，可以少量大实例长时占用；推理阶段：对延迟敏感，实例要按 QPS 弹性扩缩，GPU 利用率反而常被批处理参数影响。常见问题是我见过不少团队部署了 8 卡实例，QPS 只有两位数，GPU 利用率不到百分之十。这不是模型问题，是系统设计问题——推理请求串行直连、批处理没开，显卡看起来在工作，实际大部分时间在空转，成本烧得很冤枉。省钱的办法有两个：一是批量拼接请求，把互相独立的请求合到同一批里，提高算子效率；二是对延迟不敏感的接口，动态调大 batch，用一点延迟换吞吐。把这些量化指标写进方案，比空谈“使用 GPU 加速”有说服力得多。3. 核心架构怎么搭：数据、训练、推理、迭代四段闭环既然 AI 系统不能靠一次上线就结束，架构设计就必须把“更新和回退”当成一等公民。整个系统的最简闭环分成四段：数据管线、训练实验、推理服务、监控迭代。3.1 数据管线：先让脏数据死在门口，不要拖到模型训练数据管线是把原始事件变成可训练样本的第一道关卡。常见环节是采集、脱敏、清洗校验、切分流、统一格式存储。很多项目只写了“采集+存储”，漏掉了“校验”，结果数据字段改了名，训练脚本照样跑，模型效果却悄悄往下掉。实测比较可靠的套路是：数据校验脚本在采集后立刻运行，字段缺失率、长度分布、文本重复率都要设置阈值，超阈值直接告警；原始文本先脱敏再落存储，避免隐私问题；特征和样本按“数据集名+版本号”的路径保存，训练任务只认版本号，不认路径。这些功能写起来不难，难点在于你有没有把它当作设计的一部分。评审会上如果只讨论模型，不讨论数据管线，有两层可能：一种是你讲得足够顺，别人没机会打断；另一种是大家都觉得这个系统还没达到“系统”的门槛。3.2 训练实验：代码版本、数据版本、配置、模型产物四个数字必须对上程序员对代码版本管理很熟练，但“训练实验”管理经常很原始。模型不是直接拉出来的一个包，而是“数据 + 配置 + 训练代码”共同产生的产物。如果这四个要素没有记录，过一个月你根本说不清线上这个模型为什么比上一个好、好在哪里。建一套最小闭环：每次训练生成一个实验 ID，统一记录：训练代码哈希、数据版本号、模型配置参数；训练结束自动生成评估报告，包括整体指标、各分类指标、错误样本抽样；模型产物上传到模型仓库，命名带上实验 ID，避免“model_v2_final”这种无语义命名；训练 GPU 资源池化，避免几个人抢卡导致随机失败。这套机制不炫酷，但能让每一次模型更新都可解释、可回溯。系统设计评审听到这一层，评价通常不错。3.3 推理服务：QPS、延迟、Batch、缓存是同一个数学问题模型推理服务设计的开端是容量评估。业务给的日请求量，先换算成高峰 QPS，再留出峰值倍数和容错冗余。公式不复杂：峰值 QPS = 日均 QPS × 峰值因子。拿客服工单举例，日均 1 万请求、高峰集中在 8 小时，平均 QPS 大概是 1 万除以 8 小时的秒数，约等于 0.35，峰值因子给 4 倍，也只有 1.4 QPS。很多场景从容量上根本不需要太豪华的实例。但服务上线后，真正的账在批处理。请求进模型接口时，不是每个请求都能独立占满一次推理，把多个样本拼成一批去跑，总时延增加不多，但吞吐成本会明显下降。工程做法是做一个“批处理聚合线程”：请求先进入队列，循环里攒够 N 条或等待 M 毫秒后，再一次性发给模型，然后把结果分发给队列里的所有请求。另外两个细节容易被漏：预热：模型加载后的首次推理会很慢，老接口可不想等它，因此上线流量进入前要跑一遍预热请求；缓存：完全相同的文本在短期内重复出现的概率很高，比如用户反复提交、客服查看同样工单，缓存命中率往往不错，所以缓存要作为服务设计的一部分，而不是后续优化项。3.4 在线监控与模型更新：不能只盯“调用失败”和“P95”AI 系统的监控要分两层，系统指标是一层，数据和业务指标是另一层。只看错误率和 P95 延迟，看不出来模型效果正在失效。我在生产环境里长期监控四个额外指标：模型回退率、平均置信度、标签类别分布变化、人工改判率。模型回退率：模型服务没报错，但规则层拦截了大量请求，说明模型对这批输入已经不太靠谱，分布可能正在变化；平均置信度：整体置信度持续下滑，往往是数据漂移的信号；类别分布变化：线上预测比例和训练样本分布产生明显偏差，可能是业务规则已经变了；人工改判率：客服手工改派的比例上升，这是最接近业务真实反馈的信号。模型更新必须走灰度路径。新模型先部署到部分流量，比如 10%，跑影子比较：同一份请求同时交给新旧模型，对比输出差异，确认大盘指标没有回退，再逐步扩大流量。把这条链路跑通之后，发一次模型版本会从“事故级操作”变成常规更新。4. 完整案例：客服工单自动分类系统的设计全过程为了让前面的框架足够具体，我模拟一个相对真实的场景：某公司每天上万条客服工单，希望用系统自动判断工单类型并分派到对应客服队列。这就是典型的“文本分类 + 分布式服务”AI 系统设计题。4.1 先把约束和业务目标固化成表格我会把需求固化成下面这张表：条目数值工单类型4 类（A、B、C、D）日工单量约 1 万条日均 QPS0.35（集中在 8 小时）峰值 QPS按 4 倍估算，约 1.5目标准确率整体 ≥ 92%，D 类查准率 ≥ 85%P95 延迟≤ 500ms失败降级规则兜底，不允许单点不可用这里所有数字都来自需求对齐，尤其是“D 类查准率 ≥ 85%”这条，是为了避免类别不均衡把少数类吞掉。如果不写这一条，系统做成“什么都是 A”也能拿到 92% 准确率，但线上会变成问题。这个系统的设计目标首先是满足这七行数字，而不是“用上了最新模型”。4.2 数据和标注方案：少而准，好过全而乱先拿到近 30 天的历史工单，大概是 5 万条。按时间切分：前 21 天做训练，后 9 天做验证和测试，而不是随机切。再抽一部分做人工清洗，去掉口语气和冗余信息，统一简繁体，把文本里的姓名、电话等身份信息全部脱敏。标注环节最怕不一致。我习惯安排两位有业务经验的同学各自标注，然后计算两人对同一批样本的标注一致率，低于某个阈值（一般看 Kappa 值）的样本重新讨论，统一标完之后把结论写进标注规范文档。整个样本量哪怕只有几千条也没关系，先建立稳定基线，后续再把线上反馈样本回流进来，逐步优化。4.3 服务架构和模型落地方案这套系统里我采用分层五段式设计：接入层、规则层、缓存层、模型层、兜底层。接入层负责解析、鉴权、接口校验；规则层通过正则和关键词能直接识别的工单直接返回结果；缓存层对同一文本内容做快速命中；模型层跑小型文本分类模型，支持批处理和动态池化；兜底层设置默认分类和“转人工”标记，保证任何情况下都有结果。代码结构可以参考下面这种模式：class TicketClassifier: def __init__(self, model_adapter, rule_engine, cache): self.model_adapter = model_adapter self.rule_engine = rule_engine self.cache = cache def classify(self, ticket): text = self.preprocess(ticket.content) rule_result = self.rule_engine.match(text) if rule_result is not None: return rule_result cached = self.cache.get(text) if cached is not None: return cached result = self.model_adapter.predict([text], batch_size=16)[0] self.cache.set(text, result, ttl=600) return result代码本身不复杂，真正的工程难点在 model_adapter 内部的批处理和超时控制。模型推理调用必须设置清晰超时，比如主超时 700ms，超时即回退到规则层结果，并在监控指标里增加“模型超时回退”计数。设计文档里应该写清楚“模型不可用时的行为是什么”，而不是笼统地说“增加节点”。4.4 压测、灰度、回滚：没有这三样就不算完整交付服务上线前的压测必须做。用线上脱敏数据回放，按峰值 QPS 的 4 倍作为压测目标，同时人为给模型接口注入延迟，验证规则兜底是否顺利生效、缓存命中是否正常。压测结束后，有两件事容易被忽略：清空旧缓存，然后用预热脚本把常用类别的模型权重加载进内存。否则正式流量一进来，前几分钟的 P95 延迟会非常难看。上线时走灰度：新模型只接 10% 流量，观察人工改派率和模型回退率两个线上指标。旧模型实例保持运行至少一周，任何一轮指标超标，直接切回旧模型，同时重置新模型产生的缓存。这样即便新模型上线后完全失效，也不需要回退模型文件，只需要把路由重新指回旧版本。这套切换动作能覆盖绝大多数发布事故。5. 踩坑记录：常见问题与排查技巧5.1 高频故障速查表整理几个我自己最常遇到的现象：现象可能原因优先排查方式延迟从 200ms 涨到 2s并发升高导致批处理队列堆积，或批量参数过小看 QPS、队列长度、GPU 利用率和 batch 大小线上准确率持续下滑数据漂移：新用户说法、新商品、业务规则变化按周切分测试集做回归评测，对比类别分布服务内存持续增长模型加载多份、旧模型没卸载、缓存没设过期时间查看进程内模型数量、缓存命中率和 TTL 配置发新模型后指标反而变差评估集与真实分布不一致，或模型排序变化同一批请求跑新旧模型 shadow 对比发布后首次请求“卡死”模型预热缺失，或刚扩容后实例状态是冷的增加启动预热脚本，完成后才接流量纯后端直觉在这些问题上容易跑偏。比如延迟从 200ms 涨到 2s，很多后端第一反应是加机器。但在 AI 服务里，这一般是批处理被打散或者 GPU 利用率不足，加机器反而更贵更低效。先确认 batch 是否稳定，再看实例数量和短瞬并发是否匹配。准确率下滑也不一定要立即重训。优先检查规则拦截率有没有升高，如果明显升高，说明输入分布变了；再检查平均置信度的趋势，确认是模型退化还是只是评估口径变了。定位清楚之后再决定是重训、回滚，还是单纯更新规则。5.2 一份可以直接带进评审的AI系统设计自检清单我反复被问过、也反复问过别人，最后沉淀出八个问题。建议在做方案前先自己答一遍：业务目标对应哪些线上指标？指标允许差到什么程度？离线评估集是怎么切分的？有没有做时间顺序验证？训练数据集版本号、清洗脚本哈希是否已经记录？模型选型是否从规则、轻量模型、深度模型到大模型接口逐级排过？模型接口的超时值是多少？调用失败会落到哪个降级动作？推理实例如何处理批处理、预热、缓存过期？模型更新如何灰度？如果不通过，怎么快速回滚？监控指标里是否包含回退率、置信度、类别分布、人工改判率？这八条不会直接问“模型结构是什么”，但任何一条答不好，AI 系统设计都不好圆过去。建议拿一个熟悉的业务场景，按这八条走通一遍，做到细节都能说清楚。这不是为了应付面试，而是设计真实系统时最靠谱的底线。做多了 AI 系统设计之后，我的体会是它并没有想象中那么“玄”。它只是传统系统设计多了一个必须时刻处理的“不确定性维度”。以前测试通过就是通过，现在做 AI 系统，还要接受数据会变、输出会漂、模型会被业务淘汰。但这些冗余说到底都是工程问题，可以用数据版本、灰度、监控、回退这些老办法兜住。最后分享一个我常用的练习：找一个小场景，从指标定义、样本设计、服务降级、上线回滚各写一小段方案，然后对照自检清单改一遍。把这条路走通，再遇到 AI 系统设计，你就不会心里没底了。