LLM不是取代经典ML，而是为它喂数据：一种可落地的特征工程新模式

这两年大模型的热度一直居高不下，几乎每个技术团队都在讨论“要不要用 LLM 重写现在的系统”。但如果你真正做过一段时间业务落地，会发现一个很有意思的现象：那些日活很高、要求稳定低延迟的推荐、风控、搜索排序系统，核心模型依然是 GBDT、逻辑回归、随机森林这些经典机器学习模型。LLM 并没有取代它们，反而在越来越多的场景里变成了它们的数据上游。

这篇文章我想围绕一个核心观点展开：LLM 不是替代经典 ML，而是给经典 ML 喂数据。我们会先讲清楚两者的边界，再拆解一种已经可以落地实践的工程模式：用 LLM 从非结构化文本中提取结构化特征，把特征送入经典模型做训练和推理。最后会给出完整可运行的 Python 示例、工程落地要点、常见问题排查和最佳实践。

如果你正在做推荐系统、风控模型、用户画像、工单分类这一类业务，这篇文章会很有参考价值。

1. 背景：LLM 与经典 ML 不是替代关系，而是分层协作

1.1 为什么会有“LLM 会取代经典 ML”的错觉

过去两年，大语言模型的能力确实让人印象深刻。无论是文本摘要、情感分析、实体抽取、代码生成，还是复杂指令理解，LLM 的表现都远超几年前的 NLP 模型。于是很多技术文章开始渲染“大模型会终结传统机器学习”的观点，甚至有人认为只要把数据丢给 LLM，就能直接得到最终答案。

这种观点的最大问题在于：混淆了“模型能力”和“工程可用性”。

从模型能力上看，LLM 确实能做很多事；但从业务系统角度看，一个模型要落地，不只是“效果够好”就行。它必须满足成本可控、延迟可接受、可回滚、可监控、可解释、可测试这一系列工程要求。在这些方面，经典机器学习模型依然有非常大的优势。

1.2 重新定义 LLM 与经典 ML 的边界

要理清两者的关系，可以先看一张简化分工图：

原始数据（文本、图像、日志、行为序列） ↓ LLM 层：理解、抽取、清洗、结构化、增强 ↓ 结构化特征（数值、类别、向量、规则化标签） ↓ 经典 ML 层：分类、回归、排序、聚类、异常检测 ↓ 业务决策

在这个链路里，LLM 扮演的角色更像是一个“特征工厂”。它负责把难以用传统规则处理的非结构化信息，转换成经典模型喜欢的结构化输入。经典 ML 模型则继续负责最终的业务决策，在稳定性、可解释性和资源消耗上发挥优势。

两者不是竞争关系，而是上下游协作关系。

1.3 我为什么更看好这种“LLM 喂数据”的模式

在真实业务场景里，数据从来不是整齐的表格。大量信息藏在工单文本、客服对话、商品描述、评论内容、合同条款里。过去我们只能用 TF-IDF、Word2Vec、BERT embedding 这些方式做文本表示，但效果有限，尤其是面对长文本、隐含意图、多层语义的时候。

LLM 的出现给了我们一个新选项：与其让经典模型直接理解原始文本，不如让 LLM 先把文本“翻译”成经典模型更容易理解的信号。比如判断一段客服对话里用户是不是愤怒、工单里是否包含财务问题、商品描述里有没有夸大宣传，这些信号过去需要人工打标，现在可以用 LLM 自动生成。

这就是“LLM 喂经典 ML”的核心价值。

2. 为什么经典 ML 仍然不可替代

2.1 成本与延迟：每次预测都调用大模型并不划算

如果你把一个高并发的推荐系统改成每次请求都调一次 LLM，成本会非常夸张。假设接口 QPS 是 2000，每次请求需要生成 300 token，按常见的计费方式计算，一个月的模型调用费用可能比整个推荐团队的年预算还高。

更关键的是延迟。LLM 生成 300 token 通常需要几百毫秒到几秒，而推荐系统要求的是几十毫秒级别。如果把 LLM 放在主链路里，整体 RT 会直接超标，用户体验会受到明显影响。

经典模型则完全没有这些问题。一次随机森林的预测只需要微秒到毫秒级别，甚至可以批量并行，部署在廉价 CPU 实例上就能支撑很高的 QPS。所以在高并发、低延迟的核心链路上，经典 ML 依然是首选。

2.2 可解释性与合规要求

在很多行业里，模型决策必须能向用户或监管方解释。比如信贷审批，客户被拒绝后，你有义务告诉他为什么被拒绝。如果是基于“规则变量 + 逻辑回归权重”来做判断，我们可以明确说出“因为最近 3 个月逾期次数为 2，信用分低于阈值，所以被拒绝”。

但如果你把决策完全交给一个黑盒大模型，很难解释它具体参考了哪些变量，更难以向监管方提供可审计的证据。经典模型虽然也有复杂度天花板，但至少在工程上可以通过特征重要性、SHAP 值等方式给出比较清晰的解释路径。

这在风控、金融、医疗、政务等场景里，是硬约束。

2.3 稳定性和可测试性

大模型每次升级都有可能改变输出分布，哪怕只是提示词里加了一个词，都可能导致线上效果波动。这种“版本漂移”在生产环境里非常痛苦。

经典模型在这个问题上要稳定得多。训练完成后，模型参数就固定了，特征分布一旦监控正常，预测结果就是可预期的。测试也更容易，因为输入输出维度都是确定的，可以写非常严格的单元测试和回归测试。

所以从系统工程角度看，经典 ML 在可维护性上的优势，决定了它不会被轻易替换掉。

3. 核心模式拆解：LLM 如何变成“特征工厂”

3.1 传统特征工程的三个瓶颈

在 LLM 出现之前，我们处理非结构化文本特征，主要靠三类方式：

• 词频统计类特征：TF-IDF、词袋模型。这类方式实现简单，但丢失了语序和上下文信息，对语义理解几乎没有帮助。
• 静态词向量：Word2Vec、GloVe。能够表达词的语义，但无法处理一词多义，也没有办法通过上下文动态调整。
• 预训练模型向量：BERT embedding。效果比前两者好很多，但对于“我需要一个明确的业务标签”这件事，仍然需要在下游接一层分类头。

换句话说，传统方式的输出要么是“数值向量”，要么是“粗糙的统计信号”，它们不能直接告诉业务方“这是一条紧急工单”。

3.2 LLM 做特征提取的价值点

LLM 在特征提取上的优势，不只是“理解语义”，而是“可以直接输出业务定义的结构化结果”。

举个例子。过去我们判断一段客服对话是否包含“用户想要退款”的意图，需要标注数据、训练一个意图识别模型。现在可以让 LLM 直接输出一个下拉框级别的结果：

{"has_refund_request": true, "refund_reason": "商品质量问题"}

这个输出可以直接成为特征，也可以进一步映射成数值特征供经典模型使用。

这就是 LLM 作为特征工厂的意义：它把原来需要标注团队、训练团队花几周做的事情，压缩成一次带提示词的批量调用。

3.3 两条典型技术路线

当前工程上比较常用的路线有两条：

• 第一条：LLM 抽取 + 经典模型决策。LLM 负责从文本中抽取结构化信息（类别标签、数值评分、实体、摘要），经典模型负责把这些信息和原有结构化特征融合，做最终预测。这种方式适合业务规则复杂、需要可解释性的场景。
• 第二条：LLM embedding + 经典模型决策。LLM 直接生成文本向量（embedding），然后将向量降维或直接作为特征输入给经典模型。这种方式信息保留更完整，但可解释性稍弱一些。

本文的实战部分，我会以第一条路线为主，因为它的可解释性更强，也更贴近“LLM 喂经典 ML”这个主题。

4. 实战案例：LLM 提取特征 + 经典模型做工单紧急度分类

4.1 场景说明与数据集

假设我们运营一个企业客服系统，每天会收到大量客户工单。每条工单有以下几个字段：

• customer_level：客户等级，取值为 1 到 5，数值越大等级越高。
• history_ticket_count：该客户历史提交工单数量。
• ticket_text：工单正文，是一段非结构化文本。

业务方希望构建一个模型，自动判断当前工单是否需要加急处理，标签为is_urgent，取值为 0 或 1。

这里有一个现实问题：历史工单里有很多信息只存在于文本中，比如“客户威胁投诉”“客户多次来电”“涉及金额较大”“服务已经持续三天没有解决”等。这些信息很难通过简单的关键词规则覆盖，但恰恰是判断是否加急的关键信号。

我们的方案是：

1. 用 LLM 从ticket_text中提取 6 个结构化特征。
2. 将这 6 个特征与原始数值特征合并，组成完整训练矩阵。
3. 训练一个逻辑回归模型，对比“只用原始特征”和“加上 LLM 特征”的效果差异。

4.2 环境准备

本文示例使用 Python 3.9+，依赖如下：

• pandas：数据处理。
• scikit-learn：经典机器学习建模与评估。
• openai 或兼容 OpenAI 协议的 SDK：调用 LLM。

安装命令：

pip install pandas scikit-learn openai

由于真实 LLM 调用需要 API Key 且计费，为了方便你直接跑通核心流程，我会在特征提取部分做一个“模拟 LLM 输出”的版本。模拟版本返回的数据结构与真实调用一致，你可以把它替换成真实的 LLM 接口调用，不影响下游建模部分。

4.3 创建示例数据

先创建一份模拟的工单数据，包含 200 条记录。这里为了演示，我只贴出前几行。

import pandas as pd data = { "customer_level": [3, 5, 2, 4, 1, 3], "history_ticket_count": [1, 8, 0, 3, 10, 2], "ticket_text": [ "客户反馈商品颜色不对，希望换货，语气平静。", "客户是大客户，连续三天无法登录系统，威胁要解除合同。", "客户咨询发票抬头如何修改，需要提供操作指引。", "客户要求退款，但商品已经拆封，客服需要进一步核实。", "客户是黑钻会员，反馈物流长时间未更新，情绪激动要求赔偿。", "客户询问周末是否有人工客服值班。", ], "is_urgent": [0, 1, 0, 1, 1, 0], } df = pd.DataFrame(data) print(df)

实际使用中，你可以用自己业务的工单表替换这个 DataFrame。

4.4 用 LLM 抽取结构化特征

这一步是整篇文章的核心：用 LLM 把非结构化工单文本“翻译”成结构化特征。

我们需要让 LLM 从每个工单中输出以下字段：

• is_emotional：客户情绪是否激动或负面，取 0 或 1。
• has_compensation_request：是否包含赔偿或退款诉求，取 0 或 1。
• has_churn_risk：是否包含流失风险信号（如威胁取消、解除合同），取 0 或 1。
• mentions_vip：文本中是否提到客户属于高价值会员，取 0 或 1。
• issue_complexity：问题复杂度评分，范围 1 到 5。
• service_quality_complaint：是否包含对服务质量的投诉，取 0 或 1。

这里我先给出真实调用 LLM 的示例代码，使用的格式是 OpenAI 兼容接口。需要注意，不同平台的接口参数会略有差异，请根据你实际使用的模型服务调整。

import os from openai import OpenAI client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) def extract_features_with_llm(text: str) -> dict: prompt = f""" 你是客服工单分析助手。请阅读下面这条工单内容，抽取以下结构化信息。 只返回 JSON，不要返回其他解释。 工单内容： {text} 需要输出的 JSON 字段： {{ "is_emotional": 0 或 1, // 客户情绪是否激动或负面 "has_compensation_request": 0 或 1, // 是否包含赔偿或退款诉求 "has_churn_risk": 0 或 1, // 是否包含流失风险信号 "mentions_vip": 0 或 1, // 是否提到高价值会员身份 "issue_complexity": 1 到 5, // 问题复杂度评分 "service_quality_complaint": 0 或 1 // 是否包含服务质量投诉 }} """ response = client.chat.completions.create( model="your-model-name", messages=[ {"role": "system", "content": "你是工单特征提取助手。"}, {"role": "user", "content": prompt}, ], temperature=0, response_format={"type": "json_object"}, ) content = response.choices[0].message.content return json.loads(content)

为了本地跑通流程，我再给一个模拟版本。模拟输出基于简单的关键词规则生成，仅用于展示建模代码，不代表真实 LLM 效果。

import random def extract_features_with_llm_simulated(text: str) -> dict: text = text or "" return { "is_emotional": 1 if any(k in text for k in ["激动", "威胁", "愤怒", "投诉"]) else 0, "has_compensation_request": 1 if any(k in text for k in ["退款", "赔偿", "换货"]) else 0, "has_churn_risk": 1 if any(k in text for k in ["解除合同", "流失", "不再续约"]) else 0, "mentions_vip": 1 if any(k in text for k in ["大客户", "黑钻", "VIP"]) else 0, "issue_complexity": random.randint(1, 5), "service_quality_complaint": 1 if any(k in text for k in ["服务太差", "没有解决", "客服态度"]) else 0, }

把真实版本和模拟版本放在一起，是想强调一个工程思路：LLM 调用层应该被封装成统一接口，这样你在开发环境可以用模拟函数测试下游逻辑，在生成环境再切换成真实调用。

4.5 批量处理并构造特征矩阵

拿到单条工单的特征后，我们需要批量处理整个训练集。要注意，真实 LLM 调用会消耗时间和费用，所以工程上会先做缓存，避免重复调用。

import json # 为每条工单生成 LLM 特征 llm_feature_list = [] for text in df["ticket_text"]: feat = extract_features_with_llm_simulated(text) llm_feature_list.append(feat) llm_feature_df = pd.DataFrame(llm_feature_list) # 合并原始特征与 LLM 特征 feature_df = pd.concat([df[["customer_level", "history_ticket_count"]], llm_feature_df], axis=1) label = df["is_urgent"] print(feature_df.head())

合并之后，每一条工单就变成了一行“数值特征 + 类别特征”的结构化数据，可以直接喂给经典模型了。

4.6 训练经典 ML 模型并对比效果

这里使用逻辑回归作为分类器。为了说明 LLM 特征的价值，我训练两个模型：

• 模型 A：只用原始数值特征。
• 模型 B：原始数值特征 + LLM 抽取特征。

然后比较两个模型在测试集上的 AUC（曲线下面积）和 F1 值。

from sklearn.model_selection import train_test_split from sklearn.linear_model import LogisticRegression from sklearn.metrics import roc_auc_score, f1_score # 为了演示多一些样本，这里把数据复制扩充到 1000 条 df_expanded = pd.concat([df] * 50, ignore_index=True) # 重新生成 LLM 特征（模拟） llm_feature_list = [] for text in df_expanded["ticket_text"]: feat = extract_features_with_llm_simulated(text) llm_feature_list.append(feat) llm_feature_df = pd.DataFrame(llm_feature_list) base_features = df_expanded[["customer_level", "history_ticket_count"]] full_features = pd.concat([base_features, llm_feature_df], axis=1) labels = df_expanded["is_urgent"] # 训练集 / 测试集划分 X_train_base, X_test_base, y_train, y_test = train_test_split( base_features, labels, test_size=0.3, random_state=42 ) X_train_full, X_test_full, _, _ = train_test_split( full_features, labels, test_size=0.3, random_state=42 ) model_base = LogisticRegression(max_iter=1000) model_base.fit(X_train_base, y_train) model_full = LogisticRegression(max_iter=1000) model_full.fit(X_train_full, y_train) # 预测与评估 pred_base = model_base.predict_proba(X_test_base)[:, 1] pred_full = model_full.predict_proba(X_test_full)[:, 1] auc_base = roc_auc_score(y_test, pred_base) auc_full = roc_auc_score(y_test, pred_full) pred_base_label = model_base.predict(X_test_base) pred_full_label = model_full.predict(X_test_full) f1_base = f1_score(y_test, pred_base_label) f1_full = f1_score(y_test, pred_full_label) print(f"原始特征模型 - AUC: {auc_base:.4f}, F1: {f1_base:.4f}") print(f"LLM特征增强模型 - AUC: {auc_full:.4f}, F1: {f1_full:.4f}")

在这个示例中，受限于模拟数据的写法，两个模型的效果差异可能不直观。但在真实业务场景里，当文本中的关键信号无法被传统规则覆盖时，LLM 特征带来的 AUC 提升通常会在 0.02 到 0.1 之间，尤其是在工单分类、舆情判断、风险识别这类任务上。

4.7 结果说明与落地意义

从这个案例可以看出，整个流程实际上是在做两件事：

1. 用 LLM 解决“非结构化文本怎么变成业务信号”的问题。
2. 用经典 ML 解决“多特征如何组合决策”的问题。

LLM 部分可以持续迭代：换更强的模型、优化提示词、增加新的抽取字段。经典模型部分保持稳定：只要特征分布不变，线上行为就是可控的。两者解耦后，团队可以分别迭代，互不阻塞。

5. 工程落地要点：别把 LLM 调用写进主链路

5.1 LLM 调用层要做缓存与批量离线化

在真实生产环境里，直接在线调用 LLM 抽取特征通常不是最优选择。更推荐的方式是“离线批量抽取 + 特征存储 + 在线读取”。

流程大致是：

1. 每天定时任务读取新增工单。
2. 调用 LLM 抽取特征，将结果写入特征表。
3. 在线服务从特征表读取特征，送入经典模型。

这样做的好处是，LLM 调用产生的延迟和波动被隔离在离线链路中，不影响在线服务稳定性。同时，缓存结果可以避免重复计费。

5.2 特征版本管理

LLM 提示词的微小改动可能导致特征分布发生变化。做好特征版本管理非常重要。推荐做法是给每个版本的 LLM 特征加一个feature_version字段，例如v1、v2。模型训练时记录使用了哪个版本的特征。

这样当线上效果出现波动时，你可以快速定位是特征变了，还是模型参数变了，还是数据分布变了。

5.3 超时与重试机制

LLM 接口调用不可避免会出现超时、限流、返回格式异常。工程上建议：

• 设置合理的超时时间，例如 10 秒。
• 失败重试 2 到 3 次，但要注意退避策略，避免打爆上游接口。
• 解析 JSON 失败时，要有兜底策略，比如将特征置为默认值并写入日志。

这里有一个判断逻辑值得注意：如果 LLM 特征解析失败，是保存一条默认特征还是丢弃这条数据？我的建议是，在离线批量抽取阶段，保存默认特征并记录失败原因，同时用人工或规则补采的方式修复，而不是直接丢弃，否则会导致测试集和线上特征分布不一致。

6. 常见问题与排查思路

在实际项目中，你大概率会遇到下面这些问题。这里整理了一张排查表。

排查这类问题有一个通用套路：先确认数据链路。特征是从哪里产出的，有没有缓存，版本是什么，解析有没有失败。再确认模型链路。模型是谁训练的，用的哪个版本特征，训练集和线上特征是否同源。最后确认业务链路。标签口径有没有变，业务规则是否更新。

7. 最佳实践与工程建议

基于我接触到的项目经验，下面这些建议会帮你在实际落地时少踩很多坑。

7.1 明确 LLM 的职责边界

LLM 不是万能的。在你的系统里，它应该只负责“理解文本、抽取信号”这件事，不要让它直接做业务决策。业务决策应该由经典模型结合所有特征来完成。这样职责清晰，出现问题也容易回溯。

7.2 设计稳定的特征映射

LLM 输出的原始结果通常是文字，比如"service_quality_complaint": "是"。在送入模型前，需要统一映射为数值。建议在特征抽取层输出规范 JSON 后，再做一次字典映射：

FEATURE_MAP = { "is_emotional": {"是": 1, "否": 0, "unknown": 0}, "has_compensation_request": {"是": 1, "否": 0, "unknown": 0}, "has_churn_risk": {"是": 1, "否": 0, "unknown": 0}, "mentions_vip": {"是": 1, "否": 0, "unknown": 0}, }

所有无法解析的值，统一落到unknown，再映射到 0。这样可以避免特征解析失败导致模型异常。

7.3 对 LLM 特征做质量监控

每个特征都应该有对应的监控指标。最简单的监控方式是：统计每个字段的取值分布，观察分布是否在周维度、日维度发生明显漂移。一旦发现某个字段大量出现默认值，或者取值为 1 的比例突然从 20% 涨到 60%，就要立刻检查上游 LLM 调用是否出了问题。

也可以把 LLM 特征当作普通特征，做模型训练前的特征重要性分析。如果某个字段在业务上很重要但重要性始终很低，可能需要检查提示词是不是写得不准确。

7.4 处理好冷启动与人工回流

LLM 特征抽取输出的标签并不 100% 准确。无论模型效果多好，建议在高风险决策场景保留人工抽检机制。给每批 LLM 抽取结果做一定比例的人工复核，把复核数据存入样本库，后续可以用于评估 LLM 特征的质量变化。

这也是“LLM 喂经典 ML”和“纯 LLM 决策”相比的一个重要工程优势：中间多了一层可审计、可干预的特征层。

7.5 控制样本量和特征维度

经典模型对特征维度是有限制的。如果你一次性让 LLM 抽取 50 个特征，但又只有 2000 条训练样本，很容易过拟合。建议先抽取业务上最关键的 5 到 10 个特征，跑通链路后再迭代增加。

特征选择上也可以借助模型本身的系数或树模型的特征重要性，逐步收敛到稳定特征集。

7.6 安全与数据合规

如果工单文本包含用户隐私信息，直接调用外部大模型需要格外小心。两种情况要区分开：

• 私有化部署的 LLM：数据不出内网，合规风险相对可控。
• 云端 API 调用：数据会离开本地环境，需要先做脱敏处理，并且要确认是否符合公司数据安全规范。

在实践中最简单的做法是：在调用 LLM 前，用规则或者小模型把姓名、电话、身份证号、地址等敏感实体替换为占位符，比如[NAME]、[PHONE]。这样既能降低合规风险，也不影响文本语义理解。

8. 总结：把大模型放进生产线，而不是把整条生产线换掉

这篇文章的核心信息其实就一句话：LLM 和经典 ML 不是二选一的关系，更常见也更务实的做法，是把 LLM 当作一个高质量的特征提取器，给下游的经典模型提供更有业务语义的信号。

我建议你按下面的顺序去实践：

第一步，找到当前业务中最难处理的“非结构化信息瓶颈”。它可能是工单文本、客服对话、商品描述、合同条款、舆情评论。

第二步，设计一个 LLM 提示词，让模型输出 5 到 10 个业务相关的结构化字段。先不用着急训练模型，先抽样看抽取结果是否符合业务直觉。

第三步，把抽取字段作为新特征，和原有结构化特征一起送入经典模型，计算效果增量。

第四步，设计缓存、监控、人工抽检机制，把整个流程工程化。

如果你在未来项目中能把这套链路跑通，你会发现一个很有意思的变化：原本团队里最花时间的是“业务数据怎么变成可用特征”，现在这部分被 LLM 大幅压缩，大家可以把精力放到更上层的事情上，比如业务策略、模型调优、系统架构。这才是大模型在实际业务中真正的价值。

如果你正在做类似的事情，欢迎在实践中多验证这套“LLM 做特征、经典模型做决策”的思路。遇到什么问题，也欢迎一起交流讨论。