2. 业务需求理解与问题定义：从业务方到模型的桥梁

说实话，很多AI项目失败，不是因为模型不够强，而是从一开始就理解错了业务方想要什么。我见过太多团队花三个月调模型，最后业务方说“这不是我要的”。嗯，这章我们就聊聊怎么避免这种悲剧。

2.1 与业务方沟通：听懂“人话”背后的需求

业务方通常不会说“我要一个二分类模型，AUC大于0.9”。他们说的是“我想知道哪些客户会流失”、“帮我预测下个月的销量”。你的任务，就是把这些模糊的需求翻译成技术语言。

我个人习惯，第一次沟通时先问三个问题：

• 现状是什么？ —— 现在怎么做的？痛点在哪？
• 期望是什么？ —— 理想状态下，你希望得到什么？
• 决策是什么？ —— 拿到结果后，你会做什么动作？

沟通时，我建议你准备一个需求澄清清单：

2.2 将业务问题转化为机器学习问题

这是最考验功力的环节。说白了，就是把“人话”翻译成“模型话”。

举个例子：业务方说“我想知道哪些商品该补货”。这可以转化为：

• 分类问题：未来7天，该商品是否会出现缺货？（二分类）
• 回归问题：未来7天，该商品的销量是多少？（数值预测）
• 时序问题：基于历史销量，预测未来每天的销量曲线。

你看，同一个业务需求，可以对应多种模型方案。怎么选？

我遇到过最坑的一次，业务方说“我要预测客户价值”。我一开始做了回归模型，预测每个客户未来消费金额。结果业务方说“我其实是想给客户分群，高价值的推VIP服务，低价值的发优惠券”。你看，这其实是聚类或分类问题。从那以后，我每次都会追问一句：“拿到结果后，你下一步做什么？”

常见的转化对照表：

2.3 定义成功标准（KPI）

没有KPI的项目，就像没有目的地的航行。但很多团队犯的错误是：用技术指标代替业务指标。

举个例子：模型AUC从0.85提升到0.87，业务方会开心吗？不一定。如果业务方关心的是“减少多少客户流失”，那你要看的是挽留率提升了多少，而不是AUC涨了多少。

我个人习惯，定义KPI时分层：

• 业务KPI：流失率降低5%、销售额提升10%、客服成本降低20%
• 模型KPI：准确率、召回率、F1、AUC、RMSE
• 工程KPI：推理延迟<100ms、每天稳定运行、数据延迟<1小时

定义KPI时，我建议你和业务方一起填这个表：

2.4 确定项目范围和约束条件

项目范围，说白了就是“做什么”和“不做什么”。约束条件，就是“在什么限制下做”。

我见过最惨的项目，团队花两个月做了一个全自动的智能客服系统，结果业务方说“我们只需要一个辅助人工的推荐答案工具”。为什么？因为一开始没定范围。

确定范围时，我习惯用MVP思维：

• 必须做：核心功能，不做项目就废了
• 应该做：重要但不紧急，可以后续迭代
• 可以做：锦上添花，有资源再考虑
• 不做：明确排除，避免范围蔓延

约束条件通常包括：

• 时间约束：3个月必须上线
• 数据约束：只有过去1年的数据，且部分字段缺失
• 资源约束：只有2个算法工程师，1台GPU服务器
• 合规约束：不能使用用户隐私数据，模型需要可解释

2.5 知识结构图：从业务到模型的完整链路

下面这张图，是我每次做项目都会画的。它帮你把整个流程串起来：

2.6 实战案例：一个完整的转化过程

最后，我分享一个真实的案例。某电商平台业务方说：“我想做一个智能定价系统，让利润最大化。”

经过沟通，我们发现：

• 真实需求：不是全自动定价，而是给运营人员推荐最优价格
• 数据情况：有历史价格、销量、竞品数据，但竞品数据只有50%覆盖率
• 约束条件：价格变动不能超过±20%，每天只能调整一次

最终我们定义的问题：

• 模型问题：基于历史数据，预测不同价格下的销量（回归），然后结合成本计算最优利润
• KPI：业务KPI是毛利率提升2%，模型KPI是销量预测RMSE<15%
• 范围：第一期只做100个核心SKU，不做全品类

结果呢？上线后毛利率提升了1.8%，接近目标。运营人员也很满意，因为系统给了推荐价格，他们还有最终决定权。