8.0
热点
AI SCORE
编程提效2026-08-08 06:50
经典模型与LLM协同：三种实用架构
dev.to · AI#AI架构#机器学习#系统设计
Editor brief · 编辑速览
两者并非竞争而是互补——经典模型作路由/特征提取/验证器；成本相差3-4个数量级是路由架构的经济基础，延迟差异决定同步路径选型。
真正有用的问题不是哪个更好，而是每个部分应该处理请求的哪些部分。有三种在生产环境中反复奏效的架构——古典模型作为路由、作为提取特征的使用方、或者作为验证器——每种都有不同的经济效益。
用一个廉价模型处理它能处理的，把其余的传递下去。这与"廉价过滤器 + 模型级联"的模式相同，区别在于第一阶段是一个梯度提升分类器，而不是更小的语言模型。
用古典模型对每个传入项打分。支持工单分类、内容审核、文档分类、线索资格审核——任何具有高频简单多数的场景都适用。
直接处理高置信度的案例。使用两个阈值而非一个：高于上阈值的视为正向，低于下阈值的视为负向，落两者之间的则升级处理。两个阈值都来自成本计算，正如阈值页面中的逻辑，升级成本作为比较中的第三个选项。
只将中间段发送给语言模型。这些是有歧义的项目，正是语言模型读取上下文的能力让它赚回它所需成本的地方。
同时记录升级项目的两个决策。语言模型在困难案例上的答案是下一个版本的古典模型的标签训练数据，这使得置信区间会随着时间推移而扩大。
最后一步是让这个架构得以改进而非仅仅存在。每个月廉价模型会吸收更多的流量，昂贵路径则收缩到真正困难的部分。
路由是否值得是一个计算过程，它将"过滤器是否足够准确"这个模糊问题转换为每次错误的成本。下面的费率为示意占位符；代入你自己的数字，结构依然成立。
假设每月：
总量 1,000,000 次请求
一次语言模型调用成本 £0.002 （示意）
一次古典模型推理成本 可忽略
过滤器解决的占比 85%
之前
1,000,000 x £0.002 = £2,000 / 月
之后
150,000 升级 x £0.002 = £300 / 月
850,000 x 古典推理 ~ £0
-------
节省 = £1,700 / 月
过滤器错误可能带来的成本
假设过滤器在 850,000 中错误解决了 2%：
850,000 x 0.02 = 17,000 个错误决策 / 月
每个错误的均衡成本：
£1,700 / 17,000 = £0.10
所以路由是否值得，取决于一次错误的自动解决成本是否低于 10 便士。
对于一个错误路由的支持工单来说这可能是成立的。
对于一个错误自动批准的退款来说显然不成立，
正确的设计是一个非常窄的置信区间——或者干脆不用。
最后一行是推导的关键。阈值不是由过滤器的准确率设定的，而是由它的误差成本与它覆盖所节省的成本来设定的，而这两个数字来自组织中的不同人。
表格模型无法读取支持工单、合同或产品描述。语言模型将非结构化输入转换为列，而梯度提升模型——它仍然是做决策的部分——则获得了一张更宽的表。
原始： 自由文本投诉，400 字
提取（一次 LLM 调用，结构化输出，按内容哈希缓存）：
issue_category 12 个枚举值
product_mentioned 枚举，可为空
severity_expressed 有序 1-5
refund_requested 布尔
previous_contact 布尔
join 到已有的特征表：
account_age_days, plan_tier, tickets_90d, spend_12m, ...
模型：HistGradientBoostingClassifier 对所有这些列
三个特性使得这是三种架构中最强的一个。提取是可缓存的，因为相同的文本总是产生相同的字段，所以成本是按独立文档计而非按决策计。提取是离线运行的，所以语言模型完全不在延迟路径上。而决策仍然由一个可审计、可校准且稳定的模型来做——当决策需要解释时这很重要。
将输出约束为一种 schema。枚举而非自由文本；12 个固定类别而非模型产生的任意短语。一个取值空间会漂移的特征是一个会悄悄破坏模型的特征。结构化输出和枚举优于自由文本，这覆盖了核心机制。
用模型版本管理提取 prompt。改变 prompt 就是改变特征分布。如果更新了提取器而没有重新拟合，你就在一次提交中制造了训练-服务偏差。
固定并监控提取器。提供商在底层更新模型会同时改变所有提取的特征。保留一组固定的评估文档集，其中包含已知正确的提取结果，并定期重新运行；一旦分数下降就是最早期的警告。
Embedding 是另一个选项。当文本中有你无法枚举的信号时， embedding 缩减到少数维度后可以直接进入表中。分类 over embedding 覆盖了这种情况何时优于提取，而它牺牲了枚举版本保持的可解释性。
反转顺序。语言模型产生答案；一个小的监督模型，在人工审查结果上训练，预测这个特定答案是否会被接受。低于阈值时，项目转给人处理。
验证器的特征是廉价且可用的：输出长度、输出是否包含源文档中出现的值、调用重试次数、每个字段的提取置信度，以及任何可以确定性运行的结构性检查——总数是否等于各行之和、日期是否在范围内、引用的标识符是否存在。
值得为此构建的一个关键原因是：它产生一个校准后的概率，而语言模型的自我报告置信度则不是。这意味着升级阈值可以从审查成本和错误答案成本中推导出来，使用阈值页面中完全相同的算术。相关机制见于教模型弃权以及验证模式。
如果你已经在审查输出，训练数据是免费的。每一个在生成项目上的人工决策都是一个标签。经过几千次审查后，验证器通常足够好，可以在固定错误率下大幅削减审查队列，这是一个简单的人员计算论证。
用语言模型替换一个工作正常的表格模型。将行作为待分类的文本输入会慢几个数量级，贵更多，在表格模型拟合的任务上准确率更低，而且不会产生校准概率。这偶尔是正确的选择当你完全没有标签的冷启动时——然后第一件要做的事就是收集标签并拟合分类器。
让语言模型做数值预测。"估算这个客户的流失概率"返回一个看起来合理但与任何频率都无关的数字。然后每个下游的期望值计算都是在这个虚构输入上做的算术。
无限级联。提取器，然后推理器，然后验证器，然后总结器：四个调用而表格模型不需要任何调用，错误率叠加，延迟累加。在架构定型前计算每个决策的调用数并设置上限。
两种不同的重训练节奏。古典模型按你的时间表重训练；语言模型按提供商的时间表变化。只有其中一个是你能控制的，这就是固定版本并保持上述提取评估集的理由。
一个监控面而非两个。路由的升级率、提取器的字段分布和验证器的分数分布都应该与模型自身的漂移指标放在同一个仪表板上。升级率的漂移是上游变化的最早期信号，而漂移页面将其作为其余系列中的一个来处理。
向古典路径倾斜。当语言模型不可用时，系统应该降级到表格决策加上更宽的人工队列，而不是报错误。即使语言模型更准确，这也是保持古典模型在循环中的理由。
按每次决策而非每月来归因成本。支配设计的是每个已解决项目的成本，按路径分开。月度总数掩盖了小部分升级消耗大部分预算这一常见形态。
上面的路由计算需要一条昂贵的路径上每个请求的真实成本，按模型分开，这正是从提供商账单中最难获得的数字。Multigrid 报告每个请求的成本和延迟，所以升级段可以直接定价而不是推算——而且因为路由决策是由你自己的分类器做出的，网关的工作只是让两条路径可比较且 fallback 是自动的。