在大模型能力持续走强的背景下“LLM 会不会取代经典机器学习”这个问题经常出现在技术讨论里。这里先把结论说清楚在生产系统里LLM 和 Classical ML 不是替代关系而是分工关系。更准确地说LLM 是在给经典机器学习“喂数据”——生成特征、弱标签、候选集和训练语料经典模型再基于这些数据完成最终决策。很多人看到对话模型能写代码、能做摘要、能分类就认为经典机器学习栈会被 LLM 完全替代。但真实的生产系统往往不是这样。LLM 的强项是理解语义、生成内容和跨任务泛化弱项是高并发成本、延迟控制、稳定性和可解释性。经典 ML 恰好补上这些短板训练完就是一个静态模型推理成本低、延迟可控、行为稳定、便于做权限和审计。两者的组合不是“过渡态”而是会长期存在的工程架构。本文会围绕“LLM 喂养经典 ML”这条主线讲清楚混合架构的工作原理、适用场景、典型代码实现、验证方法和排错路径。文章中的案例以客服工单多分类为例用一个最小的闭环展示如何用 LLM 生成弱标签清洗后训练一个可上线的经典分类器再和“直接调 LLM 做分类”做对比。读者学完后可以直接把同一套思路迁移到搜索排序、推荐召回、命名实体识别、文本审核等场景。1. 核心判断LLM 是上游数据生产器经典 ML 是下游落地执行器1.1 LLM 的强项和瓶颈先看 LLM 在生产链路中的角色。LLM 本质上是一个条件文本生成模型它根据用户提供的 prompt 生成后续内容。因为预训练阶段见了大量语料它能把不同领域的语义知识压缩进参数里所以面对新的分类任务、抽取任务或生成任务时即使没有专门训练也能给出看起来合理的输出。这个能力非常有用但它也有明确的边界。第一推理成本高。一次大模型请求的算力消耗远高于一次传统模型的 predict。单条请求在 GPU 上可能要几百毫秒甚至几秒吞吐量也受上下文长度和 batch size 限制。把它直接放在每秒几千次请求的在线链路上成本和延迟会迅速失控。第二输出不可控。LLM 是概率采样模型同一段文本在不同批次调用中可能给出不同的标签、不同的格式。只要设置 temperature 大于 0输出就会有随机性。即使设置为 0某些推理框架和量化版本也可能因为浮点精度导致结果漂移。第三可解释性弱。LLM 给出的分类理由通常是自然语言不是权重、不是特征贡献值。在金融、医疗、政务场景里这种结果很难作为审计依据。第四高频调用容易出现线路抖动。在线服务一旦出现超时、限流或 API 故障整个业务链路都会被拖垮。而经典 ML 模型只要加载到内存里就可以在 CPU 上持续稳定提供服务。1.2 经典 ML 为什么还留在生产链路经典机器学习包括逻辑回归、决策树、随机森林、梯度提升树、SVM、贝叶斯模型等虽然在语义理解上不如大模型但它们的工程特性非常适合作业化系统。一是推理速度快。一个 TF-IDF 特征加逻辑回归的分类器在普通 CPU 上处理一条几十字的文本通常只需要毫秒级。相比大模型的秒级响应这种延迟对实时业务很关键。二是成本稳定。模型参数固定推理只做矩阵运算和概率计算没有 token 费用、没有外部 API 计费部署在普通服务器上即可。三是可解释。逻辑回归的系数可以量化每个词对结果的影响树模型可以输出特征重要性。即使不做复杂归因也能解释“为什么这条样本被判为这个类别”。四是易监控。模型输入和输出结构完全确定可以方便地记录特征、预测分、线上对比和回滚。LLM 的 prompt 和输出格式则更难统一管控。这些特性决定了凡是需要高并发、低延迟、强稳定性、可审计的场景经典 ML 都仍然是主力。LLM 适合做那些“低频、高价值、需要语义理解”的辅助环节。1.3 “Feed”到底指什么LLM 如何喂养经典 ML“LLM 喂养经典 ML”这个说法容易引起误解它不是指 LLM 直接输出最终预测结果而是指 LLM 在离线或异步场景中产出经典 ML 模型训练和运行所需的资产。常见的“喂养”方式有四类生成弱标签LLM 给一批无标注样本打标输出类别、置信度和理由经清洗后作为训练数据。生成特征LLM 从文本中抽取关键词、主题、情感极性、实体关系这些结构化结果再变成经典模型的输入特征。扩充候选集LLM 生成相似问题、同义改写、合成样本用于扩充训练集或构造负样本。生成规则和字典LLM 从已有语料中提取规则雏形或词表再由工程师校验后落到规则引擎或特征词典。这四类方式的共同特点是LLM 不直接面向线上用户而是面向“数据集”和“特征工程”。真正承载线上预测任务的是经典 ML 模型。核心判断不要用 LLM 替代经典 ML要把 LLM 放到数据生产的环节让经典 ML 消化这些数据并负责线上决策。这样既利用了语义理解能力又保住了延迟、成本和可解释性。2. 混合架构模式LLM 在经典 ML 链路中的几个常见位置2.1 模式一LLM 做特征抽取器经典模型做决策器这种模式下LLM 不输出最终类别而是输出一组结构化特征再拼接到原有特征里。经典模型把这些特征作为输入学习特征与业务目标之间的关系。典型示例电商评论情感分类。原始特征是词袋、TF-IDF、评论长度、用户历史行为。LLM 负责从评论中抽取“物流是否及时”“商品质量评价”“售后体验”三个维度每个维度输出一个情感分。经典分类器再把这三个分数和原始特征拼在一起判断整条评论是差评还是好评。这样做的好处是LLM 只负责它擅长的事——抽取语义维度经典模型只负责它擅长的事——组合特征并做稳定决策。即使 LLM 抽取结果有噪声经典模型也能学到一个更鲁棒的组合方式。关键点是LLM 的输出必须被固定为稳定的结构化格式。比如统一要求返回 JSON提前用 Pydantic 或 JsonSchema 做校验解析失败时丢弃或重试不能把自由文本直接灌进模型。2.2 模式二LLM 生成弱标签经典模型做监督学习这是当前最典型、也最容易落地的模式。业务没有标注数据时用 LLM 给一批样本打标再用这些弱标签训练经典分类器。这样既能绕过昂贵的人工标注又能得到一个低延迟、可上线的模型。这里要注意LLM 生成的标签不是金标。通常需要做几道清洗逻辑标签是否在允许集合内。confidence 是否达到阈值。reason 字段是否有实际内容。同一文本是否出现了冲突标签。针对类别做分层抽样确认分布没有严重偏移。清洗后的弱标签数据进入经典 ML 训练流程。训练完成后线上服务完全走经典模型不再每次请求都调用 LLM。这种模式尤其适合冷启动项目先用 LLM 铺一轮弱标签训练第一版模型跑起来后通过在线反馈和人工抽检积累高质量标注再迭代第二版、第三版模型。2.3 模式三LLM 做候选生成经典模型做精排搜索、推荐和检索类场景里也经常能看到这种混合链路。LLM 根据用户查询生成一批可能匹配的候选内容经典排序模型对候选集做精排。这里的逻辑是LLM 适合做开放式的语义召回但最终给用户看什么、按什么顺序展示仍然需要一套可解释、可调参、能记录分数的排序机制。粗排和精拆之后每个候选品的最终得分来自经典模型。LLM 负责扩大召回面经典模型负责稳定排序。与传统关键词召回相比LLM 能处理同义改写和口语化表达比如“手机电池不耐用”能召回“续航差”相关商品。这种能力在传统词法匹配里很难实现。这种模式下LLM 的调用仍然是离线的候选扩展或异步的索引更新。在线检索阶段系统直接查向量索引或倒排索引再由精排模型打分保证查询延迟在可控范围内。2.4 三种模式的选型思路面对实际问题先不要纠结“要不要上大模型”而是问自己要解决哪个环节的问题。混合模式解决的核心问题LLM 在链路中的角色经典模型承担的任务适合场景LLM 特征抽取 经典决策语义维度太多人工特征维护成本高离线特征生成器在线分类/回归/排序评论分析、工单分类、用户意图识别LLM 弱标签 经典训练没有标注数据人工标注太贵离线标注器低延迟在线分类冷启动分类、内容质检、风控初筛LLM 候选生成 经典精排同义召回不足召回率低离线候选扩展器在线排序打分搜索、推荐、检索扩充选择时还要评估数据规模。如果业务本身只有几千条样本而且对延迟不敏感直接调用 LLM 做分类也许更经济。如果业务每日请求量在十万以上或者需要长期稳定的预测服务就应该把 LLM 的成果沉淀成模型或特征而不是让每个请求都经过大模型。选型原则凡是高频、低延迟、需要稳定审计的决策路径尽量让经典模型承接凡是低频、高语义复杂度、可以容忍异步的环节放心交给 LLM 生产数据。3. 完整案例用 LLM 生成弱标签训练一个客服工单分类模型3.1 业务场景与整体流程假设业务方有一批客服工单需要按内容自动归类到“账单费用”“技术支持”“销售咨询”“其他”四个类别。当前没有标注数据只有几万条未标注的工单文本和少量业务规则。目标不是写一个 prompt 让 LLM 直接分类而是先让 LLM 给一部分工单打标清洗后训练一个逻辑回归分类器最终在线上用逻辑回归完成分类。整体流程从数据库或日志文件中抽取未标注工单。分批调用 LLM要求返回结构化 JSON。校验和清洗弱标签丢弃无效输出。使用 TF-IDF 向量化文本。训练逻辑回归模型。用留出集评估并和“直接调用 LLM 分类”的结果做对比。导出模型部署为离线批量预测或在线接口。3.2 环境准备下面的命令用于安装核心依赖。实际项目请根据 Python 版本和已有环境确认各依赖版本不要直接无脑安装最新版。pip install pandas scikit-learn transformers pydantic不同运行环境还可能需要以下工具包按需安装pip install openai # 如果你使用 OpenAI 兼容接口 pip install anthropic # 如果你使用 Anthropic 接口 pip install fastapi uvicorn # 如果需要本地封装在线推理服务这里不绑定具体模型供应商代码中的llm_client是一个示意对象落地时替换成公司已接入的 SDK。关键是保持相同的方法签名传入 messages返回带 content 的响应对象。3.3 用 LLM 生成弱标签弱标签任务的关键是提示词设计。提示词里需要明确四件事任务目标、类别定义、输出格式、约束条件。下面是一个生成弱标签的示例模块。示例使用 Pydantic 校验输出避免脏数据直接进入训练集。import json from typing import Optional from pydantic import BaseModel, ValidationError class WeakLabel(BaseModel): label: str confidence: float reason: str class WeakLabeler: def __init__( self, llm_client, model_name: str, allowed_labels: Optional[list[str]] None, ): self.llm_client llm_client self.model_name model_name self.allowed_labels allowed_labels or [billing, technical, sales, other] property def label_definitions(self): return { billing: 账单、费用、扣款、退款、发票相关, technical: 登录、报错、接口、网络、安装、设备故障相关, sales: 下单、折扣、促销、商品咨询、售前问题相关, other: 无法归入以上类别的其他问题, } def build_prompt(self, text: str) - str: defs json.dumps(self.label_definitions, ensure_asciiFalse) return f 你是客服工单打标助手。请从以下类别中选择一个类别 {defs} 只允许输出以下类别之一 {, .join(self.allowed_labels)} 工单内容 {text} 输出严格 JSON 格式包含 label、confidence、reason 三个字段。 label 必须是上面允许的类别之一。 confidence 是 0 到 1 之间的浮点数代表打标置信度。 reason 是用一句话说明判断依据不要超过 50 字。 不要输出额外解释。 def generate_one(self, text: str) - WeakLabel: resp self.llm_client.complete( messages[ {role: user, content: self.build_prompt(text)} ], modelself.model_name, temperature0, max_tokens200, ) content resp.choices[0].message.content try: parsed json.loads(content) return WeakLabel(**parsed) except (json.JSONDecodeError, ValidationError) as exc: # 解析失败不应该静默跳过要保留原始输出便于复盘 raise ValueError( fLLM 输出无法解析: {content[:200]}, 原始异常: {exc} )这段代码的关键点有三个。第一temperature 设置为 0尽量降低输出随机性。虽然不能完全消除漂移但比默认值稳定很多。第二输出格式约束放在 prompt 里要求 JSON。如果你的模型供应商支持response_format{type: json_object}可以在请求参数里加上它提高 JSON 格式稳定性。不支持时就依赖后处理解析。第三解析失败不直接丢弃而是抛异常。批量任务里这种异常会累积到一个错误文件里方便集中分析是 prompt 问题、模型问题还是样本本身问题。3.4 清洗和校验弱标签数据LLM 返回的数据不能直接当作训练集。必须做一次清洗把格式正确但语义不可靠的样本剔除掉。清洗规则至少包括label 是否在允许集合中。confidence 是否是 0 到 1 之间的数值。reason 是否有实际内容不能为空字符串。同一文本是否被标注了多次且标签冲突。示例如下import json from pathlib import Path def clean_llm_labels( raw_path: Path, cleaned_path: Path, allowed_labels: set[str], min_confidence: float 0.6, ): kept 0 skipped 0 with raw_path.open(r, encodingutf-8) as reader, \ cleaned_path.open(w, encodingutf-8) as writer: for line in reader: line line.strip() if not line: continue try: item json.loads(line) except json.JSONDecodeError: skipped 1 continue label item.get(label) confidence item.get(confidence) reason item.get(reason, ) text item.get(text, ) if label not in allowed_labels: skipped 1 continue if not isinstance(confidence, (int, float)): skipped 1 continue if not (0 confidence 1): skipped 1 continue if confidence min_confidence: skipped 1 continue if len(reason) 5: skipped 1 continue if len(text.strip()) 3: skipped 1 continue writer.write(json.dumps(item, ensure_asciiFalse) \n) kept 1 return kept, skipped if __name__ __main__: raw Path(data/llm_labels.jsonl) cleaned Path(data/cleaned_labels.jsonl) allowed {billing, technical, sales, other} kept_count, skipped_count clean_llm_labels(raw, cleaned, allowed) print(f保留 {kept_count} 条丢弃 {skipped_count} 条) print(f清洗后文件: {cleaned})清洗时最容易被忽略的是数据集分布。假设原始工单里有 80% 是技术问题LLM 打标后技术类别也占 80%那么即使模型只预测“technical”也能得到很高的准确率。实际业务中评价模型不能只看整体准确率还要看每个类别的精确率、召回率和 F1。建议在清洗后输出一个类别分布报告python -c import pandas as pd; import json; data[json.loads(l) for l in open(data/cleaned_labels.jsonl)]; dfpd.DataFrame(data); print(df[label].value_counts())看到分布严重偏斜时不要急着训练先判断是样本抽取本身偏斜还是 LLM 打标偏差。后者需要调整 prompt 或补充类别示例。3.5 训练经典 ML 分类器清洗完成后进入经典机器学习训练阶段。这里选用的组合是 TF-IDF 逻辑回归。它不一定是最强模型但非常适合作为第一版基线参数量少、训练快、可解释、容易排查。import pandas as pd from sklearn.feature_extraction.text import TfidfVectorizer from sklearn.linear_model import LogisticRegression from sklearn.metrics import classification_report from sklearn.pipeline import make_pipeline from sklearn.model_selection import train_test_split # 读取清洗后的弱标签数据 df pd.read_json(data/cleaned_labels.jsonl, linesTrue) X df[text] y df[label] # 划分训练集和验证集。弱标签场景下可以保留略低比例的测试集因为数据量可能不够大 X_train, X_test, y_train, y_test train_test_split( X, y, test_size0.2, random_state42, stratifyy, ) pipeline make_pipeline( TfidfVectorizer( ngram_range(1, 2), max_features20000, stop_wordsenglish, ), LogisticRegression(max_iter1000), ) pipeline.fit(X_train, y_train) report classification_report( y_test, pipeline.predict(X_test), zero_division0, ) print(report)这里有一个工程取舍要讲清楚。max_features20000限制了特征数量。如果语料是中文默认的英文停用词表不生效需要自己维护停用词表或关掉stop_words。特征数量不是越大越好过大的词表会让逻辑回归训练变慢也容易过拟合弱标签噪声。ngram_range(1, 2)让模型能看见相邻词组合对“不退款”“登录失败”这类表达有帮助。但它会放大特征维度所以同时设置max_features做截断。逻辑回归的max_iter1000是为了避免默认迭代次数不足导致不收敛。如果训练日志里出现“ConvergenceWarning”可以先增大这个值。3.6 直接调用 LLM 和 LLM 喂养经典模型的对比训练完成后最直观的验证方式是把“LLM 直接分类”和“LLM 弱标签训练出的经典模型”放在同一个测试集上对比。直接调用 LLM 的区别在于每个测试样本都即时请求大模型经典模型则是本地预测。可以用下面的脚本对比import time import pandas as pd from sklearn.metrics import accuracy_score def evaluate_llm_direct(labeler, texts): preds [] for text in texts: try: result labeler.generate_one(text) preds.append(result.label) except Exception: preds.append(other) return preds def evaluate_classical_model(model, texts): return model.predict(texts) # 假设已经准备好测试文本和真实标签 test_df pd.read_json(data/test_samples.jsonl, linesTrue) X_test_texts test_df[text] y_test_true test_df[label] # 构建 LLM direct 分类器 llm_labeler WeakLabeler(llm_clientllm_client, model_namesome-llm) start time.time() llm_preds evaluate_llm_direct(llm_labeler, X_test_texts) llm_cost time.time() - start start time.time() classic_preds evaluate_classical_model(pipeline, X_test_texts) classic_cost time.time() - start print(LLM 直接分类 accuracy:, accuracy_score(y_test_true, llm_preds)) print(经典模型 accuracy:, accuracy_score(y_test_true, classic_preds)) print(LLM 耗时(秒):, round(llm_cost, 3)) print(经典模型耗时(秒):, round(classic_cost, 3))这里有几个现象需要理解。第一LLM 直接分类在语义复杂样本上往往更强但在大批量、标准化样本上优势和经典模型差距不会太大。因为工单文本本身有固定句式TF-IDF 特征已经能抓住很多关键词。第二经典模型具备速度优势。假设测试集有 1000 条样本LLM 直接分类通常要几十秒到几分钟经典模型只需几毫秒。放到生产环境这个差距就是每秒吞吐量的差距。第三LLM 直接分类每次都会产生费用经典模型只在训练阶段和 LLM 有关推理阶段完全本地化。样本量越大成本差异越明显。把二者结合的正确姿势是用 LLM 生成的弱标签训练经典模型再把少数 LLM 高置信度输出作为“难例补充”或“人工抽检候选”而不是把每个线上请求都透传给 LLM。4. 工程细节LLM 和经典 ML 的分工边界与关键参数4.1 什么场景该用 LLM什么场景该用经典 ML在具体项目里判断标准不是“哪个模型更聪明”而是“这个环节能不能接受高延迟、高成本和高不确定性”。如果满足以下任一条件优先考虑经典 ML线上请求量超过每秒百次。延迟要求小于 200 毫秒。每次请求都需要记录预测理由或审计证据。模型行为必须完全稳定不能因为上游版本变化导致结果漂移。离线推理或批量处理的样本量在百万级以上。如果满足以下条件把任务交给 LLM 更合适任务不是简单的分类而是开放式生成。业务刚冷启动没有任何标注数据。样本量小几千条到几万条不值得投入大量人力标注。延迟要求不高且调用频率低。需要理解隐含语义比如反讽、上下文关联、长文本摘要。边界不是一成不变的。随着数据积累原来只能用 LLM 的任务可以逐步转移到经典模型或小模型。这也是“LLM 喂养经典 ML”最重要的价值LLM 帮经典模型度过冷启动阶段之后经典模型承担规模化服务。4.2 混合链路中的关键参数无论 LLM 处于哪个环节都需要关注几个直接影响生成质量的参数。参数含义建议值调大影响调小影响temperature采样的随机程度生成弱标签时建议 0创意任务可 0.7 到 1.0输出更多样但也更不稳定输出更保守趋于高频词max_tokens生成内容的最大 token 数结构化输出建议 200 到 500允许更长输出但延迟和成本上升输出可能被截断导致 JSON 不完整top_p核采样概率累积阈值0.9 到 1.0增大候选词范围减少候选词范围单批请求数每次调用处理的样本数单条分类建议 1 条生成类任务可多条提高吞吐但改变输出粒度成本上升但更稳定重试次数网络异常后的重试次数2 到 3 次提高成功率但增加放大延迟偶发网络抖动会导致任务失败这里特别强调 temperature。弱标签场景里绝大多数任务应当设置 0。即使设置的 0不同模型对 JSON 格式的支持程度也不同所以必须在后处理阶段做容错。不要认为“设置 0 就一定稳定”这只是一种降低随机性的手段不是保证。max_tokens也不能设得太小。客服工单分类任务输出 JSON 大约需要 100 到 200 token。如果设成 50LLM 可能只输出了一半 JSON后续解析必然失败。建议根据实际输出长度调整并留出 20% 余量。4.3 数据版本与缓存管理LLM 生成的弱标签属于数据资产必须把它当作代码一样做版本管理。具体要记录的内容包括LLM 模型名称和版本。Prompt 文件内容和版本。采样参数和批次大小。原始输入样本的来源表和抽取时间。LLM 输出原始结果包括解析失败的结果。清洗规则的版本和阈值。清洗后进入训练集的样本量、类别分布。推荐把每次 LLM 批量生成任务写入一个清单文件{ task_id: label_20250321_01, model: some-llm-model-version, prompt_version: v1, temperature: 0, max_tokens: 200, sample_count: 5000, cleaned_count: 4120, skipped_count: 880, label_distribution: { billing: 1100, technical: 2100, sales: 520, other: 400 } }有了这份记录后续如果要复现训练、对比模型迭代、排查标签漂移都能定位到具体是哪一批 LLM 输出出了问题。同时对线上推理链路里的 LLM 调用要做缓存。同一个文本在短时间内多次请求时不需要每次都调用大模型。可以用text_hash - llm_output的映射存储在 Redis 中TTL 根据业务需要设置。缓存能明显降低成本和延迟。4.4 防止 LLM 输出直接进入线上决策LLM 输出的弱标签和特征本质上都是“带噪声的信息源”。经典 ML 模型负责消化这些噪声但如果直接在线上使用 LLM 输出的原始结果做决策反而会引入更多不确定性。规避措施可以这样设计强制所有 LLM 输出经过解析层和校验层统一转成结构化对象。对每条输出记录 confidence 和 reason。对低置信度样本走规则兜底或人工抽检而不是默认接受。不在主链路上直接依赖外部 API 的实时返回。对 LLM 在线调用设置超时、重试、熔断和降级。注意LLM 生成内容只能作为决策参考或训练数据来源不能直接当作审计依据。真正对外输出的结论必须来自可控的、有明确逻辑的决策模块。5. 常见问题排查弱标签效果差、结果漂移和成本失控5.1 LLM 打标质量差训练后效果不如规则现象清洗后训练出的经典模型准确率低于直接用规则分类。第一步检查 prompt 里的类别定义是否清晰。如果类别定义只有一句话LLM 容易混淆边界。给每个类别补充 3 到 5 个典型示例效果会明显提升。第二步检查清洗阈值。如果min_confidence设得太低大量低质量标签进入训练集模型学到的是噪声。建议输出弱标签后先做一个置信度分布把 0.5 到 0.8 区间的样本抽取出来人工查看。第三步检查原始样本质量。如果工单里混着大量空文本、乱码和重复内容LLM 也会跟着出错。清洗弱标签之前先对原始文本做去重、去空、去超长文本。# 查看置信度分布 python -c import json, collections data[json.loads(l) for l in open(data/llm_labels.jsonl)] conf[d.get(confidence, 0) for d in data] print(collections.Counter([round(c, 1) for c in conf])) 如果低置信度样本集中出现在某个类别说明该类别的定义存在歧义需要调整 prompt。5.2 同一文本在不同批次的 LLM 标注结果不一致现象同一批文本跑两次 LLM 打标label 不一致的比例很高。先检查 temperature。如果大于 0输出随机性必然存在。改到 0 后观察漂移率是否下降。再检查模型版本。外部模型供应商经常会发布新版本相同 prompt 在不同模型版本上的表现可能完全不同。所有打标任务必须固定模型版本。最后检查是否做了多轮投票。如果对稳定性要求高可以对高价值样本做多次采样比如同一个文本调用 3 次取多数标签。这么做会增加成本只建议用在人工抽检或关键样本上。5.3 经典模型上线后解析不了新类别现象业务新增了一个类别比如“账号安全”但经典模型仍然只会分到老类别。这是经典模型的固有限制。它只能输出训练时见过的类别。新增类别时必须生成新类别弱标签重新训练模型。处理方法把新类别样本加入 LLM 弱标签生成任务重新清洗重新训练灰度发布。在线服务要做好新旧模型切换和回滚。这里要避免一个错误做法让经典模型输出一个“other”再把“other”的样本转发给 LLM 实时分类。这种设计会让线上请求高频打到 LLM 上延迟和成本都会失控。更好的做法是定期把“other”样本收集起来离线做新类别挖掘再迭代模型。5.4 LLM 调用成本疯涨但准确率没有提升现象为了提升弱标签质量不断增加调用次数成本上升但效果没有明显改善。问题往往出在数据选择上。不是因为 LLM 调用次数不够而是因为输入样本里大量是重复或低价值文本。应该先对原始数据做质量过滤再抽取有代表性的样本给 LLM 打标。实践中可以参考以下策略先聚类或去重把相似文本归并只对代表性样本打标。对高置信度容易样本不重复调用 LLM。对难样本做多次采样。定期评估新增弱标签是否确实提升了模型指标如果一周内指标没有变化就该调整数据采样策略而不是继续扩大调用量。5.5 排查清单从现象倒推根因以下清单可以在每次混合链路效果异常时使用按顺序执行。步骤检查内容操作1原始输入文本是否正常查看抽样文本检查空值、乱码、重复2Prompt 是否清晰检查类别定义、示例、格式约束3LLM 输出是否能稳定解析统计 JSON 解析失败率和失败样本4清洗规则是否合理检查阈值、过滤条件、类别分布5训练集分布是否偏斜输出 label 分布和文本长度分布6特征配置是否合适检查 ngram、max_features、停用词7模型是否收敛查看训练日志中的 loss 或收敛警告8验证集是否有泄漏检查 text 是否和 label 一起被去重9线上和离线特征是否一致对比训练时的预处理和线上接口预处理10监控指标是否对齐确认线上准确率、无效样本率、耗时指标来源一致排查顺序建议输入数据 - prompt - LLM 输出 - 清洗 - 训练 - 特征 - 模型 - 验证 - 线上一致性。不要一上来就怀疑模型结构多数问题出在数据链路。6. 生产落地最佳实践和扩展方向6.1 把 LLM 放在离线链路经典模型放在在线链路生产环境里最稳妥的架构是LLM 离线生产数据经典模型在线消费数据。离线链路适合做这些事批量生成弱标签。定期抽取新特征。根据业务反馈重训模型。批量挖掘新类别和新规则。在线链路只做这些事加载已经训练好的模型。对请求做特征预处理。调用模型 predict。返回结果和模型版本信息。这样做的好处非常明显。就算 LLM 供应商出现故障离线链路可以暂停线上服务不受影响。模型已经在本地预测完全可预测。就算要升级模型也是先训练、再评估、再灰度上线而不是让线上请求依赖外部大模型。6.2 至少记录哪些元数据混合链路里模型效果变差时最难查的就是“数据是哪来的、规则是谁定的、模型是怎么训的”。所以必须记录元数据。建议在训练数据和预测请求中至少记录以下几个字段字段含义示例sample_id样本唯一标识work_order_20250321_0001text_hash文本内容哈希sha256:xxxxsource_table数据来源表名ods_work_orderllm_model生成标签的模型llm-model-nameprompt_version使用的 prompt 版本prompt_v1label最终标签technicalconfidence弱标签置信度0.92reasonLLM 给出的判断理由用户反馈系统登录报错cleaned是否通过清洗truetrain_version进入训练集的任务版本train_v1timestamp数据生成时间2025-03-21 10:00:00这些字段不只用于审计也用于排查。当某个类别效果变差时可以快速定位是 LLM 标注变化、清洗阈值变化、训练数据分布变化还是线上特征变化。6.3 每轮迭代都要设置评估门槛经典模型在弱标签数据上训练时很容易出现“离线指标好看线上效果差”的情况。原因是弱标签本身存在系统性偏差模型可能把偏差学进去了。正确的做法是每轮迭代设置三个门槛弱标签质量门槛抽样 100 到 200 条人工核对 LLM 标签准确率不低于某个值比如 85%。离线评估门槛在保留测试集上新模型相比旧模型在目标类别上的 F1 不能下降。线上灰度门槛先让 10% 流量使用新模型观察 CTF、准确率、无效输出率等指标再逐步放量。任何一个门槛不通过都要回到上游找原因而不是直接调整阈值去“适配”不好的模型。6.4 演进路线从规则到 LLM 喂养再到经典 ML最后按需上大模型一个业务从零启动到成熟通常不是一步到位而是沿着以下路径演进阶段一纯规则。关键词、正则、黑白名单快速上线效果有限。阶段二规则 少量标注。人工标注几百条训练数据用经典模型提升泛化能力。阶段三LLM 生产数据。用 LLM 扩充弱标签、生成特征、构造负样本训练更完整的经典模型。阶段四经典模型 小模型蒸馏。把 LLM 的知识蒸馏到一个更小、更快、可部署到 CPU 的模型上。阶段五按需调用 LLM。仅对低置信度、复杂语义或新出现的业务问题异步调用 LLM 做二次分析。很多生产系统的最终形态不是“一个巨大的模型”而是多条链路并行规则层兜底、经典模型主力、LLM 做难例分析和数据生产。这种架构的价值在于每一层都能独立替换、独立回滚、独立监控。经典模型的升级不需要大模型参与LLM 版本的升级也不会影响线上已有用户。整条链路的复杂度可控排错路径清晰。6.5 可以继续扩展的方向如果这篇案例已经跑通下一步可以从三个方向深入。第一个方向是做主动学习。用经典模型的置信度作为信号把低置信度样本抽出来交给 LLM 或人工复核再补充进训练集。这样能用更少的 LLM 调用达到更高的模型效果。第二个方向是做多任务蒸馏。LLM 不只输出类别还可以输出结构化原因、关键词、实体关系。这些输出作为辅助任务可以联合训练一个小模型让小模型在主干任务上的表现更接近大模型。第三个方向是做在线缓存和难例回流。线上经典模型预测失败或低置信度的样本离线存入特征仓库定期用 LLM 重新打标然后进入下一轮训练。这样整个系统就形成了一个持续进化的数据闭环。在真实项目中这套架构已经能覆盖很多常见场景客服工单分类、评论审核、意图识别、商品短标题生成、搜索同义扩展、风险文本初筛等。核心思路都是一样的让 LLM 做语义理解和数据生产让经典 ML 做稳定决策和规模化服务。把注意力放在“如何让两种模型协作”比争论“哪个模型会取代另一个”更有实际价值。LLM 不会让经典 ML 消失反而会让经典 ML 在生产链路里活得更好因为模型在训练时拿到了更高质量、更全面的数据资产。