生成式AI不是万能药:我试了5个业务场景只有2个真正落地了我最近在公司内部复盘时发现了一个残酷的事实:我们去年立项的五个 AI 业务场景,最后真正在生产环境稳定运行的只有两个。另外三个要么指标惨不忍睹,要么模型输出完全不可控,最终只能下线回滚。而这一切的根因,不是模型不够新,也不是算力不够强,而是在项目启动初期,我把生成式AI当成了万能药,完全忽略了特征工程。直到我回头扎进机器学习入门课程,才把这次翻车的底层逻辑彻底理清--那门课从特征构建、数据预处理到管道验证讲得特别细,学完我才意识到,没有扎实的特征工程垫底,再花哨的生成式模型也是空中楼阁。当初为什么觉得生成式AI能搞定一切公司年初给研发部定了硬指标:半年内落地三个 AI 应用,用大模型提升业务效率。当时团队里没人真正懂机器学习,我拍板直接上最新的生成式AI方案,理由是「prompt engineering 这么火,不用写特征,不用训模型,描述需求就能出结果」。我们选的五个场景分别是: - 客户工单自动分类与路由 - 销售线索的赢单概率预测 - 内部知识库的智能问答 - 合同条款风险审查 - 用户评论的情感分析每个场景我们都用了几乎同一套模板:把原始文本塞给大模型,写好 prompt,期望模型直接输出标签或摘要。生成式AI课程里演示的 zero-shot 效果让我产生了一种幻觉,以为特征工程可以彻底退休。五个场景复盘:谁活了,谁死了下面这张表是三个月后线上的真实指标,当时看着就后背发凉。场景上线状态关键指标核心问题客户工单分类稳定运行F1 0.87有明确的类别定义,prompt 约束强情感分析稳定运行Accuracy 0.85标签简单,仅正/负/中性赢单概率预测回滚AUC 0.62特征工程缺失,模型无法理解业务上下文智能问答回滚可接受率 43%知识文档混入大量噪音,检索结果差合同审查回滚漏报率 31%条款逻辑复杂,纯文本表达无法捕捉结构信息活下来的两个场景都有一个共同特点:输入和输出之间的映射关系相对扁平,模型不需要理解太多业务隐变量。而挂掉的三个场景,恰恰是我以为靠 prompt 就能绕过的那些传统 ML 项目的核心难题--特征工程。翻车现场:赢单概率预测项目是怎么被我搞砸的赢单概率预测是我们投入资源最多的场景。CRM 里有超过 12 万条历史商机记录,包含销售阶段、沟通次数、客户行业、决策链长度等信息。我当时直接用 Python 把所有字段拼成一个长文本,喂给生成式AI模型,prompt 写道:「你是资深销售分析专家,根据以下商机信息预估赢单概率,输出 0-100 的数字。」# 初次尝试:暴力拼接字段 import pandas as pd def build_prompt(row): text f客户行业:{row[industry]},规模:{row[company_size]}, text f接触次数:{row[touch_count]},上次跟进时长:{row[last_call_duration]}min, text f决策人数:{row[decision_makers]},竞对情况:{row[competitor]}, text f当前阶段:{row[sales_stage]} return text df[prompt] df.apply(build_prompt, axis1)推理结果出来的时候我真的傻眼了:模型给出的概率几乎和销售阶段强线性相关,其他字段的信息完全被忽略。AUC 只有 0.62,连随机猜都好不到哪里去。后来读了AWS机器学习文档里关于数据预处理的部分才明白,我犯了两个致命错误: - 没有做特征工程,模型无法区分高信息量字段和噪音字段 - 原始数值(如沟通次数、通话时长)没有经过归一化就扔进文本,大模型对数字的敏感度远不如树模型痛定思痛:系统补课特征工程三个项目下线后,我给自己报了三门课:机器学习入门打基础,机器学习基础学完整管道,再用深度学习基础补上表示学习的部分。这三段学习经历彻底改变了我对 AI 落地的认知。机器学习入门这门课最大的价值在于,讲师用真实业务场景演示了从原始数据到可用特征的全过程。比如它会教你怎么识别数据漂移、怎么构建特征存储、怎么在管道里做自动化验证。这些概念我之前只在博客里零散看过,但课程里配的动手实验让我真正把特征工程的每个环节都跑了一遍。机器学习基础课程则帮我把零散的知识点串成了完整的机器学习管道--从数据预处理、特征选择、超参调优到过拟合检测,每一环都有对应的工具和最佳实践。尤其是混淆矩阵那部分,学完之后我才理解为什么之前赢单预测模型的指标那么惨,是因为我根本没用对评估方式。深度学习基础让我补上了表示学习的缺口:很多非结构化文本场景下,特征工程不一定靠手工设计,可以借助预训练模型提取隐向量,但这不等于可以跳过特征工程--向量的选择、聚合方式、维度裁剪本身就是特征工程的一部分。拿着新武器重新改造两个失败场景学完课程后,我决定拿赢单概率预测和智能问答两个场景重新开刀。这次我先花了两周时间做特征工程: - 对数值字段做了分桶和 WOE 编码,处理了长尾分布 - 构造了交叉特征,比如「沟通次数 × 决策人数」来刻画决策复杂度 - 把文本字段(如邮件正文、备注)用嵌入模型提取语义向量,然后做特征选择降维 - 搭建了简单的特征存储,实时读入 CRM 增量数据# 重构后的特征工程 pipeline 部分代码 from sklearn.preprocessing import StandardScaler, OneHotEncoder from sklearn.feature_selection import SelectKBest, f_classif from sklearn.compose import ColumnTransformer numerical_features [touch_count, last_call_duration, decision_makers] categorical_features [industry, competitor, sales_stage] text_features [email_thread_embedding] # 已预提取的嵌入向量 preprocessor ColumnTransformer([ (num, StandardScaler(), numerical_features), (cat, OneHotEncoder(handle_unknownignore), categorical_features), (text, passthrough, text_features) ]) # 特征选择 selector SelectKBest(score_funcf_classif, k50)特征工程就位后,我没有再直接把特征塞给生成式AI,而是先用 LightGBM 做了一个基线模型,AUC 直接提到了 0.84。确认特征有效之后,再用生成式模型做推理层面的增强,比如输出可解释的自然语言预警--「该商机过去一周无沟通记录,且决策人数超过 5 人,建议销售跟进频率提升 3 倍」。这次模型给出的建议终于有了业务指导意义。智能问答场景也是同样的思路:我先花了大量精力做知识库的数据清洗和元数据标注,把文档按章节、领域、更新时间做了结构化,再建立索引。这个过程中数据预处理和特征存储的思路完全来自机器学习管道的实践,最终问答可接受率从 43% 拉到了 81%。学完后的真实变化和三点建议这次翻车和重建下来,我觉得最大的收获不是搞懂了某个模型,而是建立了「没有特征工程,AI 落地就是赌博」的认知。现在团队新启动任何 AI 项目,我都会先要求完成下面这五条:先确定数据质量:字段缺失率、异常值、目标变量分布是否均匀。机器学习入门课程里的数据探索环节可以直接复用拿来作为 checklist,非常实用。强制做特征工程评审:所有直接扔给生成式AI的原始数据,必须先经过特征构建和筛选。这门课的实验案例帮我养成了习惯,每个新场景我都会对照着特征工程 checklist 走完才允许进模型。基线模型必做:不要一上来就用大模型,先用简单的逻辑回归或树模型跑一个基线,看看特征工程是否奏效。机器学习基础里关于过拟合和交叉验证的内容把这个道理讲得很透。搭建特征存储:避免每次推理都重新计算特征,保证线上一致性的同时还能大幅降低延迟。AWS基础知识里关于管道的建设方法可以直接套到企业环境里。监控数据漂移:模型上线不是终点,特征分布一旦偏离训练集就要告警。数据漂移这个概念是我在机器学习入门课程里第一次系统接触到的,现在已经成为我们 ML 管道里最关键的监控项之一。回头再看,当初五个场景只落地两个,不是因为生成式AI不够好,而是我把所有希望都压在了 prompt 上,却忘了老祖宗教的那句「garbage in,garbage out」。补完特征工程之后我才真正理解了 AWS 机器学习课程强调的「管道的起点永远是数据」--这六个字值回了我所有翻车损失。