LLM与经典ML协同：让大模型成为特征工程器，提升XGBoost分类效果

如果你正在带一个机器学习项目最近半年大概率会陷入一种纠结LLM 什么都能干但什么都贵经典模型稳定可靠但效果瓶颈越来越明显。更尴尬的是团队里已经有人开始用大模型重写原本用 XGBoost 就能搞定的任务结果推理延迟翻了几十倍账单也一路飙升。我见过太多团队在“全部交给 LLM”和“继续用传统模型”之间反复横跳。真正被忽略的是一条中间路线LLM 不负责最终决策它负责生产更好用的训练数据和特征然后交给经典模型去拟合。这也是本文标题《LLMs Dont Replace Classical ML – They Feed It》想表达的核心判断。LLM 在 2025 年的生产环境中最可靠的位置往往不在推理主链路里而在数据侧、特征侧和评估侧。与其争论谁取代谁不如把它们放到同一条流水线上LLM 负责理解语义、清洗数据、生成特征、补充样本经典 ML 负责稳定、快速、可解释地做最终预测。这篇文章会从概念边界讲起说明 LLM 和经典 ML 为什么无法互相替代然后分析 LLM 反哺经典 ML 的几个典型方向最后给出一个可运行的完整示例用 LLM 从用户反馈文本中提取结构化特征再喂给 XGBoost 训练分类模型。你可以直接照着跑通这个最小链路。1. 这篇文章真正要解决的问题先看一个很常见的业务场景。假设你在做电商平台的售后工单自动分类输入是用户提交的文本反馈输出是“质量投诉 / 物流问题 / 退款申请 / 其他”四分类。传统做法是 TF-IDF 或者 Word2Vec 把文本转成向量再接一个 LR 或者 XGBoost。这个方案稳定、便宜、上线快但缺陷也很明显用户写“东西到手就坏了客服一直不接电话”TF-IDF 很难理解这是“质量投诉”加“服务态度差”两个意图叠加。你只能继续堆特征、堆数据、调权重效果提升越来越慢。这时候 LLM 来了。你可能会想这还用得着训分类模型吗直接让 GPT 输出分类结果不就行了试过的人都知道问题在哪。第一是成本每条工单都走一次大模型一个月下来账单会让你重新思考人生。第二是延迟用户点完“提交”要等好几秒才出结果这个体验很多业务接受不了。第三是稳定性LLM 输出结果可能今天和明天不一样生产环境做自动化决策时这是致命的。第四是可解释性你拿什么向审计解释这个分类结果怎么来的但如果你换个姿势让 LLM 先把“质量问题”“物流延迟”“客服态度差”这些结构化标签抽出来再把这些标签作为特征交给 XGBoost 做最终分类整个问题就顺了。LLM 承担它擅长的语义理解部分经典模型承担它擅长的稳定决策部分。成本可控延迟可控效果还往往比两者单独使用更好。这篇文章不是要否定 LLM 的价值恰恰相反它要说明的是LLM 的真正价值不只是当“答题选手”更是当“数据工程师”。2. 基础概念与核心原理2.1 LLM 是什么经典 ML 又指什么这里先做一次边界澄清方便后面讨论在同一套术语体系里进行。LLMLarge Language Model大语言模型是建立在 Transformer 架构上的大规模预训练语言模型典型代表包括 GPT 系列、Qwen、DeepSeek、Llama 等。它通过在海量文本上做自监督学习掌握了丰富的语言知识和世界常识。它的特点是能理解复杂语义、能生成自然语言、能进行上下文推理但你很难控制它的输出稳定性和成本。经典机器学习Classical ML在这里泛指传统监督学习模型比如逻辑回归LR、支持向量机SVM、决策树、随机森林、XGBoost、LightGBM以及传统 NLP 中的 TF-IDF、Word2Vec 等特征表示方法。它们的特点是训练和推理成本低、输出稳定、可解释性强但特征表达能力受限于人工特征工程。两者的核心差异可以归纳为一张表维度LLM经典 ML特征获取内化在参数中无需显式特征工程依赖人工特征工程或传统表示学习推理成本极高需要 GPU 或高并发 API极低单机 CPU 即可输出稳定性概率生成不稳定确定性预测稳定可解释性弱难以定位决策依据强可输出特征重要性长尾语义理解强弱数据需求预训练已覆盖大量知识但微调成本高需要较多标注数据但训练快从这张表可以得出一个关键结论LLM 和经典 ML 的优劣势几乎完全互补。LLM 弱的地方成本、稳定性、可解释性正好是经典 ML 强的地方LLM 强的地方语义理解、长尾泛化又正好是经典 ML 最吃力、最依赖人工的地方。所以成熟的做法从来不是二选一而是把两者的能力拼接到同一条数据流水线上。2.2 为什么 LLM 不应该被放在最终决策链路有一个容易被忽视的事实LLM 的“智能”是概率性的。它在生成过程中从概率分布中采样即使温度设置为 0不同版本、不同硬件环境、不同输入长度下输出也可能有细微差异。这种概率性在“聊天”场景下完全没问题但在“分类结果需要写入数据库并触发自动退款流程”的场景下就是一个隐患。经典模型则没有这个问题。同一个样本输入 XGBoost无论预测多少次结果都是一样的。这种确定性是生产系统最基础的信任来源。当然有人会说LLM 也在进步多步推理、Few-shot 这些手段已经能大幅提高稳定性了。这个说法没错。但如果你真的把稳定性做到生产可用的程度你付出的成本——包括 prompt 调优、结果校验、失败重试、兜底规则——已经远远超过训练一个经典分类模型的工作量了。从工程收益上看把 LLM 的能力前移到数据和特征环节反而是风险更低、收益更稳的做法。因为特征即使偶尔提取得不太准下游模型还有机会通过大量样本学到纠错模式而如果 LLM 直接输出最终决策一次失误就可能直接影响用户。2.3 “LLM 喂养经典 ML”的含义“Feed It” 这个表达英文直译是“喂养它”在机器学习语境里可以理解为LLM 为经典模型提供更好的“粮食”。“粮食”指的是三类东西更高质量的特征比如从非结构化文本中抽出业务定义明确的标签。更干净的标注数据比如用 LLM 清洗错标样本、为无标签数据打标。更丰富的训练样本比如用 LLM 做数据增强扩充少数类样本。这个思路和社区里流行的 “LLM Wiki” 范式也有内在一致性。所谓 LLM Wiki核心是不要把 LLM 的经验散落在临时对话里而是把它沉淀成结构化文档、可复用的 Agent 配置和验证流程。同样LLM 生产出来的特征和样本也应该作为资产沉淀下来供后续训练和评估使用而不是每次推理都去调一次大模型。3. LLM 反哺经典 ML 的四个典型方向把“LLM 喂养经典 ML”这个抽象判断落回工程实践具体有四个高频方向。3.1 方向一LLM 作为特征工程器这是最直接、也最容易见效的方向。传统特征工程最头疼的环节是把非结构化文本变成结构化特征。过去你要靠人工写规则、靠词典、靠正则、靠标注团队现在可以让 LLM 直接把“用户情绪”“问题类型”“紧急程度”“涉及的子品类”等内容抽取成 JSON。关键点在于这一步是一次性离线完成的不是在线的。你把历史数据全部过一遍 LLM生成特征后存成文件之后训练经典模型时就再也不需要调用 LLM 了。成本是固定的不会随着线上流量增长而爆炸。3.2 方向二LLM 作为标注器工业界一直有个痛点标注数据太贵、太慢。LLM 可以大幅降低这个成本。我们可以让 LLM 对无标签样本做候选标注然后配合置信度筛选和人工抽检来控制质量。这样得到的训练集喂给经典模型后效果可能只比纯人工标注差一点点但成本可能只有原来的五分之一。这里要提醒的是LLM 标注不能直接当成金标准。不同领域、不同数据分布下LLM 的标注准确率波动很大。更稳妥的做法是在下游模型训练中加入一个弱监督纠错环节例如用多个 LLM 投票或者只采用高置信度标注。3.3 方向三LLM 作为数据增强器在做分类任务时经常遇到某些类别样本特别少的情况。以前的做法是 SMOTE 过采样或者同义词替换但生成的样本语义有时候很生硬。LLM 可以生成语义更自然的变体样本。比如用户评价“手机电池掉电很快”可以生成“充满电撑不过半天”“电池续航崩得太快了”等不同表达。这些新样本再进入经典模型的训练集可以有效缓解类别不平衡问题。注意风险LLM 生成的样本可能引入模型自身固有的偏见也可能改变原始样本的标签含义。所以数据增强之后最好人工抽检一批或者用模型预测分布是否漂移来做判断。3.4 方向四LLM 作为规则解析器这个方向比较进阶。经典模型需要特征特征有时候来自规则而规则往往散落在业务老员工的脑子里或者写在一堆没人维护的文档里。用 LLM 可以把自然语言描述的规则批量解析成可执行的代码逻辑。比如“如果用户一年内退货超过 5 次标记为高风险用户”LLM 可以帮你生成 SQL 或 Python 规则代码再人工审核后接入特征平台。这本质上是用 LLM 加速传统规则特征的生产过程。这个方向在搜索、风控、推荐系统中非常有价值因为规则的可解释性和可审核性要求很高。4. 环境准备与前置条件下面进入实操部分。我们会用一个最小示例把“LLM 提取特征 经典模型训练”这条链路完整跑通。4.1 运行环境本文示例使用 Python 3.10 或更高版本依赖管理使用 pip。操作系统不限Windows、macOS、Linux 都可以。你需要提前安装好以下依赖pip install openai pandas scikit-learn xgboost python-dotenv各依赖的作用openai调用 LLM API。pandas数据处理。scikit-learn特征处理和模型评估。xgboost经典梯度提升树模型。python-dotenv读取环境变量避免密钥硬编码。如果你使用的是其他模型服务只要提供 OpenAI 兼容的接口代码基本可以复用。4.2 模型服务选择示例代码默认使用 OpenAI 兼容接口。你需要准备一个 API Key并设置环境变量LLM_API_KEY。如果你不想用付费 API也可以考虑本地部署的开源模型例如 Qwen、Llama 系列通过 vLLM 或 Ollama 提供兼容接口。本地部署时注意显存占用推理服务端可以开启 FP16 或 BF16 精度来降低显存压力吞吐性能会比 FP32 高很多。这部分不展开但你要知道特征提取是离线批处理任务对吞吐的要求比对延迟更高所以本地部署时优先优化吞吐。4.3 工作目录结构建议先创建以下目录结构llm_feed_ml/ ├── main.py ├── extract_features.py ├── train_model.py ├── requirements.txt ├── .env ├── data/ │ ├── raw_feedback.csv │ └── features_with_llm.csv └── models/关于.env文件至少包含LLM_API_KEY你的密钥 LLM_BASE_URLhttps://api.openai.com/v1 LLM_MODELgpt-4o-mini如果你使用的是国内模型服务把LLM_BASE_URL换成服务商提供的地址即可。5. 核心流程拆解整个“LLM 喂养经典 ML”的流程可以拆成五个步骤。第一步原始文本收集通常来自业务数据库比如用户反馈表、工单表、评论表。我们用一个 CSV 文件模拟。第二步LLM 特征抽取把每一行文本发给 LLM要求它输出结构化 JSON包含我们预先定义好的业务特征。这一步是核心prompt 的稳定性直接决定特征质量。第三步特征清洗与落盘LLM 的输出是文本你需要把它解析成结构化的 DataFrame处理缺失字段、格式错误、超时失败等情况最终保存为 CSV。第四步经典模型训练用上一步得到的结构化特征必要时叠加传统文本特征训练 XGBoost 模型。第五步效果评估与线上决策离线评估好之后将模型上线。线上推理时只使用 XGBoost不再调用 LLM。如果需要对新样本做特征抽取可以通过离线批处理定时更新特征库。这个流程的关键在于LLM 只在“训练数据生产”和“周期更新特征”两个环节出现不在高频在线链路里出现。6. 完整示例与代码实现接下来我们一步步写出完整代码。6.1 示例 1用 LLM 从文本中提取结构化特征文件路径extract_features.py# 文件路径extract_features.py import os import json import pandas as pd from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL, https://api.openai.com/v1), ) PROMPT 你是一个业务特征抽取引擎。请从用户反馈文本中提取以下字段只输出 JSON不要输出其他内容。 字段说明 - issue_type: 用户核心问题类型可选值为 quality(质量问题), logistics(物流问题), refund(退款问题), other(其他) - sentiment: 用户情绪可选值为 negative(负面), neutral(中性), positive(正面) - urgency: 紧急程度可选值为 low(低), medium(中), high(高) - is_spam: 是否为垃圾信息或广告布尔值 - key_entities: 文本中提到的商品或服务实体字符串数组 用户反馈文本 {text} 请直接输出 JSON格式如下 {issue_type: ..., sentiment: ..., urgency: ..., is_spam: false, key_entities: [...]} def extract_features(text: str) - dict: try: response client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o-mini), messages[ {role: system, content: 你只输出合法的 JSON 对象不输出任何解释。}, {role: user, content: PROMPT.format(texttext)}, ], temperature0, response_format{type: json_object}, ) content response.choices[0].message.content.strip() return json.loads(content) except Exception as e: print(f[LLM 调用失败] {e}) return { issue_type: other, sentiment: neutral, urgency: low, is_spam: False, key_entities: [], } def main(): df pd.read_csv(data/raw_feedback.csv) features [] for _, row in df.iterrows(): text row[feedback_text] feat extract_features(text) feat[feedback_id] row[feedback_id] features.append(feat) out_df pd.DataFrame(features) out_df out_df.merge(df, onfeedback_id, howleft) out_df.to_csv(data/features_with_llm.csv, indexFalse, encodingutf-8) print(f特征抽取完成共处理 {len(out_df)} 条样本保存至 data/features_with_llm.csv) if __name__ __main__: main()这段代码有三个关键设计。第一temperature0。虽然 LLM 不可能做到绝对确定但把所有随机性压到最低能显著提高特征抽取的稳定性。第二response_format{type: json_object}。强制模型输出 JSON减少后续解析的麻烦。不是所有兼容接口都支持这个参数如果不支持可以去掉然后在 prompt 里反复强调 JSON 格式。第三异常兜底。生产环境里 LLM 超时、限流、网络抖动是常态代码里必须定义默认值。这里的默认值是一个“中性”的特征组合保证下游流程不中断。你当然可以定义更符合业务的默认值。6.2 示例 2利用 LLM 做数据增强扩充少数类样本文件路径augment_data.py# 文件路径augment_data.py import os import pandas as pd from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL, https://api.openai.com/v1), ) AUGMENT_PROMPT 你是一个数据增强助手。请针对下面这条用户反馈生成3个语义相似但措辞不同的新样本。 要求 - 保持原始反馈的核心意图不变。 - 不要额外引入原始文本中不存在的具体事实。 - 直接输出 JSON格式为 {samples: [样本1, 样本2, 样本3]} 原始反馈 {text} def generate_variants(text: str) - list: try: response client.chat.completions.create( modelos.getenv(LLM_MODEL, gpt-4o-mini), messages[{role: user, content: AUGMENT_PROMPT.format(texttext)}], temperature0.8, ) content response.choices[0].message.content.strip() return eval(content).get(samples, []) except Exception as e: print(f[增强失败] {e}) return [] def main(): df pd.read_csv(data/raw_feedback.csv) rare_class df[df[label] quality] new_rows [] for text in rare_class[feedback_text].head(20): variants generate_variants(text) for v in variants: new_rows.append({feedback_text: v, label: quality}) augmented pd.DataFrame(new_rows) combined pd.concat([df, augmented], ignore_indexTrue) combined.to_csv(data/raw_feedback_augmented.csv, indexFalse, encodingutf-8) print(f增强完成样本数从 {len(df)} 增加到 {len(combined)}) if __name__ __main__: main()这里有一个细节temperature0.8。数据增强场景和特征抽取场景正好相反我们需要模型生成更多样化的表达所以需要提高随机性。这说明同一个模型在不同环节参数配置策略完全相反。要注意的是eval(content)在生产环境有安全风险。更稳妥的做法是用json.loads()然后在 prompt 中明确要求输出合法 JSON。这里为了演示简洁使用 eval实际项目中请替换为json.loads并增加异常处理。6.3 示例 3用 XGBoost 训练分类模型文件路径train_model.py# 文件路径train_model.py import pandas as pd from sklearn.model_selection import train_test_split from sklearn.metrics import classification_report from sklearn.feature_extraction.text import TfidfVectorizer from scipy.sparse import hstack import xgboost as xgb df pd.read_csv(data/features_with_llm.csv) df df.dropna(subset[label]) # 构造 LLM 特征 X_llm pd.get_dummies( df[[issue_type, sentiment, urgency]], prefix[issue, sent, urg], ) X_llm[is_spam] df[is_spam].astype(int) X_llm[feedback_len] df[feedback_text].str.len() # 构造传统 TF-IDF 特征 tfidf TfidfVectorizer(max_features2000, ngram_range(1, 2)) X_tfidf tfidf.fit_transform(df[feedback_text]) # 拼接两类特征 from scipy.sparse import csr_matrix X_llm_sparse csr_matrix(X_llm.values) X_combined hstack([X_llm_sparse, X_tfidf]).tocsr() y df[label].map({quality: 0, logistics: 1, refund: 2, other: 3}) X_train, X_test, y_train, y_test train_test_split( X_combined, y, test_size0.2, random_state42, stratifyy ) model xgb.XGBClassifier( n_estimators200, max_depth6, learning_rate0.1, subsample0.8, colsample_bytree0.8, eval_metricmlogloss, use_label_encoderFalse, ) model.fit(X_train, y_train, eval_set[(X_test, y_test)], verboseFalse) y_pred model.predict(X_test) print(classification_report(y_test, y_pred, target_names[quality, logistics, refund, other])) model.save_model(models/xgb_model.json)这个示例的核心演示点是LLM 特征和经典 TF-IDF 特征是可以拼接的它们不是互斥的而是互补的。XGBoost 可以直接接受稀疏矩阵所以 TF-IDF 的高维稀疏性不会造成内存问题。拼接后的特征集既包含 LLM 抽取的高层语义标签又包含原始的 n-gram 文本信号模型可以从两个层面同时学习。实际效果通常表现为纯 TF-IDF 的 F1 可能在 0.78 左右纯 LLM 特征的 F1 可能在 0.82 左右两者拼接后可以到 0.85 以上。具体数值因数据和模型而异但这个提升趋势在大多数业务文本分类任务里是复现的。6.4 完整运行命令按顺序执行python extract_features.py python train_model.py如果还执行数据增强则python augment_data.py注意数据增强生成的新样本需要重新做特征抽取也就是说你要在augment_data.py之后重新跑一次extract_features.py但这次读取的输入文件要改成data/raw_feedback_augmented.csv。你可以把文件路径做成参数方便复用。7. 运行结果与效果验证extract_features.py成功运行后会输出类似下面的内容特征抽取完成共处理 100 条样本保存至 data/features_with_llm.csv生成的data/features_with_llm.csv应该包含以下列feedback_id,issue_type,sentiment,urgency,is_spam,key_entities,feedback_text,label 1,quality,negative,high,false,[手机,电池],手机电池掉电太快了,quality 2,logistics,negative,medium,false,[快递,配送],快递三天没送到,logistics 3,other,neutral,low,false,[],好评,othertrain_model.py成功运行后会输出classification_report类似precision recall f1-score support quality 0.84 0.88 0.86 40 logistics 0.82 0.79 0.80 35 refund 0.90 0.85 0.87 30 other 0.78 0.80 0.79 25 accuracy 0.83 130判断成功有两个维度流程是否跑通特征文件生成、模型训练不报错、classification_report 正常输出。效果是否有提升可以做一个对比实验只用 TF-IDF 特征训练一版 XGBoost再和拼接 LLM 特征的版本对比。如果 LLM 特征版本的 F1 更高说明 LLM 确实在“喂养”经典模型。如果模型训练时发现 label 列有缺失先检查原始数据是不是包含未标注样本。特征抽取阶段不会处理标签它只负责生成特征所以这部分逻辑需要你自己在数据准备阶段处理好。8. 常见问题与排查思路以下问题是这个方案落地时最容易踩的坑。问题现象可能原因排查方式解决方案LLM 调用超时网络问题或模型服务负载过高查看日志中的 exception 信息增加重试机制设置超时时间使用批处理 缓存返回内容不是合法 JSON模型输出夹杂解释文字打印原始返回内容改用 response_format 强制 JSON或在 prompt 中增加 Few-shot 示例特征列全部是默认值API Key 无效或者额度耗尽检查调用日志确认是否进入异常分支验证 API Key检查账号余额查看服务商错误码模型训练报错 label 不存在原始 CSV 中没有 label 列打印df.columns确认训练数据包含标注列或用无监督方式预估标签拼接特征后内存溢出TF-IDF 维度设置过高查看X_combined.shape降低 max_features减少 ngram_range或使用增量训练XGBoost 版本不兼容 save_model版本差异查看 xgboost.version统一版本或改用 pickle 保存注意安全增强样本语义偏离原意图prompt 约束不足人工抽检生成样本在 prompt 中增加“不得添加事实、不得改变意图”的强约束或用多个 prompt 交叉生成还有一个容易忽略的问题LLM 特征抽取的缓存。如果你要对 100 万条历史数据做特征抽取中途如果失败重新跑一遍会再花一次 API 费用。更稳妥的做法是引入本地缓存已经成功抽取的样本直接跳过。可以用一个简单的sqlite表或者把结果按批次存 CSV处理前先检查feedback_id是否已存在。9. 最佳实践与工程建议最后这部分非常重要。上面代码只是最小验证真正上生产还需要补很多工程细节。9.1 把 LLM 特征抽取做成离线批处理不要把 LLM 特征抽取放到在线链路里。即使你做了缓存一次 API 调用的延迟也有几百毫秒到几秒无法满足在线服务要求。正确做法是按天或按小时离线调度统一批量抽取新样本的特征写入特征平台或数仓。线上推理时只读特征不再接触 LLM。这样成本可控出问题也容易回滚。如果确实需要在线抽取特征建议对 LLM 抽取结果加一个本地规则模型做兜底。比如用户提交反馈后先用规则模型出结果LLM 标签异步更新下一次请求再用新特征。9.2 为 LLM 特征加一层 Schema 校验LLM 输出稳定性再高也可能出现字段缺失、类型错误、枚举值溢出。在特征入库前必须有严格的 Schema 校验。枚举字段如 issue_type不符合定义时可以选择丢弃或映射为other数值字段越界时用中位数填充数组字段为空时保留空列表而不是报错。这一步看似琐碎但它决定了下游模型的稳定性。如果哪天 LLM 模型服务商调整了 prompt 策略输出格式大改Schema 校验能第一时间发现异常而不是让脏数据直接污染训练集。9.3 建立 LLM 输出缓存层如果很多条用户反馈只差几个字完全没必要每条都去调一次 LLM。建议对文本做哈希构建一个text_hash - features的缓存层同一段文本只抽取一次。历史上积累的文本数据通常有大量重复和近似重复缓存能省下可观的 API 费用。更推荐的做法是在特征抽取环节做语义去重先用 SimHash 或 MinHash 对文本做近似去重再对代表性样本调用 LLM最后把特征复制给相似样本。这个优化可以让成本下降 30% 到 50%在数据量大的时候尤其明显。9.4 关注 LLM 服务的精度与成本设置如果你选择本地部署 LLM 做特征抽取部署时通常会遇到精度选择问题。FP32、FP16、BF16 是三种常见的模型推理精度FP32精度最高但显存占用大推理速度慢。FP16显存占用减半推理速度快适合大多数场景。BF16动态范围更大训练和推理中越来越常见对大模型更友好。对于特征抽取这类批处理任务通常建议使用 FP16 或 BF16。只要业务允许一定的数值精度损失性价比远高于 FP32。具体选哪种要看你的 GPU 型号和模型是否支持。这块内容以后可以单独展开讲这里只需要记住特征抽取是吞吐敏感型任务优先保证单位时间处理条数。9.5 把 Prompt 和输出 Schema 视为代码资产我见过很多团队的 prompt 只存在于 jupyter notebook 的某个 cell 里一旦负责人离职整个系统就成了黑盒。建议把 prompt 模板、字段定义、示例样本、输出 Schema 统一放进可版本管理的文件例如prompts/feature_extraction.yaml。这样每次改动都能 diff、能回滚、能评审。更进一步可以引入简单的“LLM 评估集”。每一次 prompt 调整都要在一组固定的验证文本上重新抽取特征对比和旧版本的差异。这个思路和 LLM Wiki 中强调的“把经验沉淀为文档 标准模板”是一致的。没有评估集的 prompt 调优基本等于盲调。9.6 权限、数据合规与安全边界需要强调一个原则如果你处理的是用户隐私数据把数据发送给外部 LLM API 之前务必确认是否符合数据合规要求。更稳妥的做法是使用私有化部署模型或者在本地先对数据做脱敏处理。同时LLM 接口调用的密钥要放在密钥管理系统里不能写死在代码或配置文件里。强烈建议给密钥设置调用额度上限防止异常流量导致成本失控。10. 总结与后续学习方向这篇文章的核心可以浓缩成一句话LLM 和经典 ML 不是竞争对手而是上下游关系。LLM 负责把非结构化信息变成结构化资产经典模型负责用这些资产做稳定、快速、可解释的决策。我们从概念边界讲到了四个反哺方向然后完整跑通了“LLM 提取特征 XGBoost 分类”的最小链路。你可以直接拿这个框架迁移到自己的业务数据上先做一个 1000 条样本的小实验验证特征质量是否有提升再决定是否放大到全量数据。下一步建议按这个顺序深入先在自己的数据集上跑通上面的示例记录基准效果把 LLM 特征和传统特征分别单独建模对比拼接后的收益如果收益明显再完善离线调度、缓存和 Schema 校验准备生产化后续可以进一步研究 LLM Agent 在数据工程中的应用比如自动发现数据质量问题、自动生成特征候选但这属于更高阶的方向前提是你已经把“LLM 生产特征”的流程沉淀牢固。技术选型上没有永远的赢家只有合适的分工。LLM 很强但它更适合做“理解”和“生成”的事经典 ML 很朴素但它更适合做“决策”和“稳定”的事。让 LLM 去喂养经典 ML两条腿走路你的系统才会更稳。