AI项目的失败往往被归咎于模型或算力，但真正致命的是交易数据的错误处理。从数据采集埋点到分布漂移，从噪声污染到合规踩雷，本文深度剖析四种典型死法背后的数据根源，揭示为什么90%的AI项目都倒在同一条起跑线上——并给出产品经理必须介入的四大关键节点。
过去一年，我密集地读了很多AI产品失败的复盘文章，也跟不少做过AI项目的产品经理聊过。
我发现一个有意思的规律：这些项目的死法，惊人地相似。
模型换了一个又一个，版本迭代了十几轮，Demo效果看起来很漂亮，但上线之后效果崩了，业务方放弃，团队复盘时互相甩锅。
表面上的死因各不相同——需求没对齐、算法选型错了、工程落地慢。但当我把这些案例拆开来看，发现几乎所有问题都能追溯到同一个根源：
不是模型不够好。是交易数据，从一开始就错了。
我入行两年，见过的项目不多，但这件事我想认真说清楚——因为它几乎没有人在产品经理的视角下讲透过。
每次AI项目出问题，复盘会上最常听到的几句话是这样的：
“我们用的模型架构太老了，换个Transformer试试。” “算力不够，特征没跑完整。” “业务方需求一直在变，数据跟不上。”
这些说法并非完全错误，但它们有一个共同的特点——都在回避一个更根本的问题：喂进模型的数据，本身是否可靠？
机器学习有一条铁律，在业内被称为”Garbage In, Garbage Out”——垃圾进，垃圾出。模型本质上是一个放大器，它放大的不是你的期望，而是数据本身的质量。数据好，模型把好信号放大；数据烂，模型把噪声和偏差放大。
但奇怪的是，在大多数AI项目的启动阶段，产品经理和算法工程师的注意力几乎全部集中在模型选型和功能设计上，数据准备被默认为”数据团队的事”，往往到了特征工程阶段才发现问题，而这时候距离上线可能只剩两个月。
在所有数据类型中，交易数据是被忽视得最彻底、代价也最惨重的一类。
为什么这么说？因为交易数据在大多数公司里有一个天然的”身份错位”——它在财务部门是账单，在数据团队是流水，在业务部门是GMV报表。没有人把它当作AI产品的核心原材料来对待，也没有人从AI产品设计的角度去定义它应该长什么样。
而恰恰是这种忽视，埋下了项目失败的种子。
在深入讲问题之前，我需要先把交易数据这个概念说清楚，因为很多人对它的理解停留在”订单表”这个层面，这个认知本身就已经造成了损失。
交易数据的定义，远比一张订单表复杂。
从AI产品的视角来看，交易数据是指用户在产品中完成或尝试完成某种价值交换行为时，系统所记录的全部信号集合。这里的”价值交换”不只是付款，它包括：加购、收藏、下单、支付、取消、退款、评价、复购……每一个节点都是信号，每一个节点的缺失都是损失。
一条完整的交易数据，至少应该包含以下核心字段：
但更重要的，是理解交易数据的生命周期。一条交易数据从业务发生到真正可以被模型使用，要经历一条相当漫长的链路：
这条链路上的每一个节点都可能出问题，而且越靠前的问题，代价越大——因为它会污染整条链路下游的所有环节。
有一个认知我认为非常关键，需要在这里单独强调：交易数据不只是财务记录，它是用户真实意图最诚实的镜子。
用户可以在问卷里撒谎，可以在评论里言不由衷，但他们的交易行为——买了什么、在什么时间买、买了多少、最终有没有退——这些行为是真实意图的直接投票。这也是为什么交易数据在所有数据类型中，信号密度最高、商业价值最大。
好，概念讲完了。现在来说说那些项目到底是怎么死的。
我把它们归纳成四种典型死法，每一种背后都指向交易数据的一个具体问题。
这是最常见、也是最隐蔽的死法。
有一个做用户复购预测的项目，算法团队拿到数据后发现，退款记录里的”退款金额”字段有将近40%的数据是空值。原因是什么？因为当初做埋点的工程师认为”退款金额等于订单金额，没必要单独记”，所以这个字段从来没有被正确采集过。
但在实际业务中，部分退款（用户只退了订单中的部分商品）和全额退款的业务含义完全不同，对用户满意度和复购意愿的影响也截然不同。这个字段的缺失，直接导致模型无法区分这两种用户，预测结果严重失真。
更糟糕的是，这个问题在项目启动时没有人发现，直到模型训练了两个月之后做特征分析才暴露出来。
埋点设计的问题，是AI项目最难被提前发现的风险，但也是最致命的风险。因为它意味着你需要重新采集数据，而数据是有时间窗口的——历史数据补不回来，项目周期直接拉长。
字段缺失只是其中一种情况，口径不统一同样危险。比如”成交时间”这个字段，有的系统记的是用户点击支付的时间，有的记的是支付网关回调成功的时间，两者之间可能相差几秒到几分钟。在实时风控场景里，这几分钟的差异可能直接导致特征计算错误。
这个死法更加隐蔽，因为它往往在项目上线之后才开始显现，而且表现出来的症状是”模型效果逐渐变差”，很容易被误诊为”模型需要重新训练”。
真正的病因叫做分布漂移（Distribution Shift）。
用一个真实场景来说明：某电商平台在2023年用历史交易数据训练了一个智能定价模型，训练数据的时间窗口是2021年到2022年。但2023年平台做了一次大规模的品类扩张，新增了大量客单价在500元以上的高端商品。这些商品的用户购买行为模式与原有品类完全不同，但模型完全没有见过这类交易数据，自然也无法为这部分商品给出合理的定价建议。
结果是：模型对新品类的定价持续偏低，平台在这部分商品上的毛利损失了将近15%，而这个问题在上线后整整三个月才被发现。
交易数据有一个特殊的时效性问题：用户的消费行为会随着市场环境、平台策略、外部事件的变化而持续演变。一个在特定时间窗口内训练出来的模型，如果没有持续的数据更新机制，它的”世界观”就会越来越落后于真实世界。
这不是模型的问题，是产品经理在设计阶段就没有把数据更新策略纳入产品方案。
“我们有五年的交易数据，总量超过10亿条。”
这句话在AI项目启动会上听起来非常令人振奋。但我每次听到这句话，都会多问一个问题：这10亿条里，有多少是干净的？
交易数据的污染源比你想象的多得多：
刷单数据是最典型的污染源。在电商场景里，刷单行为会产生大量虚假的”高质量用户”信号——这些账号的购买频次高、客单价稳定、几乎不退款，看起来是模型最喜欢的优质用户特征。但如果这些数据进入训练集，模型学到的就是刷单行为模式，而不是真实用户行为。
测试数据是另一个常见污染源。很多公司的测试环境和生产环境共用同一套数据管道，测试账号产生的交易数据如果没有被正确过滤，就会混入训练集。我见过一个项目，训练集里有将近8%的数据来自内部测试账号，这些账号的行为模式极度异常（比如一天之内下了200单又全部退款），直接拉偏了模型对正常用户行为的判断。
促销期异常数据也需要特别处理。双十一、618等大促期间的交易数据，用户的购买行为受到价格刺激，与日常行为模式差异极大。如果不加区分地把这部分数据混入训练集，模型会高估用户的价格敏感度，导致日常场景下的推荐和定价策略出现系统性偏差。
数据量大给了团队一种虚假的安全感，让人觉得”样本够多，模型自然会学好”。但在噪声主导的数据集里，模型学到的只是噪声的规律。
这是四种死法里最”冤”的一种，因为它往往发生在项目已经做了大半、甚至已经上线之后。
交易数据天然涉及用户的财务隐私，在《个人信息保护法》和GDPR的框架下，对交易数据的采集、存储、使用都有明确的合规要求。但很多AI项目在设计阶段完全没有法务介入，产品经理和算法工程师按照”技术上能做什么”来设计方案，而不是”法律上允许做什么”。
常见的踩雷点包括：未经用户明确授权就将交易数据用于画像建模；跨业务线共享交易数据时没有做数据隔离；将含有个人身份信息的交易数据直接用于模型训练而未做脱敏处理。
我见过一个金融科技公司的AI风控项目，在上线半年后因为一起用户投诉，被监管机构介入审查，最终发现项目在数据使用授权上存在重大缺陷，整个系统被强制下线整改，前期投入全部打水漂。
合规不是法务部门的事，是AI产品经理在设计阶段就必须完成的功课。
说了这么多失败案例，我也需要说说，当交易数据被正确对待时，它能为AI产品带来什么。
传统的协同过滤推荐依赖的是用户的静态偏好（买过什么、看过什么），而基于交易序列的深度推荐模型，能够捕捉用户购买行为的时序规律。
比如，一个用户在过去三个月里按照”运动鞋→运动袜→运动裤→运动上衣”的顺序完成了四次购买，模型可以从这个序列中学到”这个用户正在逐步完善运动装备”的意图，并在下一次触达时主动推荐他还缺少的品类，而不是继续推他已经买过的东西。
这种基于交易序列的意图预测，比点击行为数据准确得多，因为付款行为是用户意图最强的确认信号。
实时风控是交易数据价值密度最高的应用场景之一。一笔异常交易的识别，需要在用户点击”确认支付”到支付网关处理完成的几百毫秒内完成判断。
这个链路的每一个环节都依赖高质量的交易数据：历史交易特征需要实时更新，特征存储需要支持毫秒级读取，模型需要在极低延迟下完成推理。任何一个环节的数据质量问题，都会直接影响风控的准确率和用户体验。
经典的RFM模型（最近一次消费、消费频率、消费金额）是基于交易数据做用户分层的经典方法。但传统RFM是静态的、基于规则的，而AI化的RFM可以做到动态预测。
AI化的进阶之处在于：它不只是描述用户”现在是谁”，而是预测用户”未来会怎样”。基于交易序列，模型可以预测一个用户在未来30天内流失的概率、下一次购买的品类偏好、以及其生命周期总价值（LTV）。这让运营策略从”事后响应”变成了”事前干预”。
价格敏感度建模是交易数据最直接的商业应用之一。通过分析不同用户群体在不同价格区间下的购买转化率，模型可以为每个用户、每个商品、每个时间段计算出最优定价区间。
这不是简单的”打折促销”，而是基于交易数据对用户支付意愿的精细化建模。一个做对了智能定价的平台，可以在不降低整体GMV的前提下，显著提升毛利率——因为它知道哪些用户对价格不敏感，不需要给他们发优惠券。
说到这里，我想直接给出一个可执行的行动框架。作为AI产品经理，你需要在项目的四个关键节点主动介入交易数据的管理，而不是等着数据团队”准备好了再来找你”。
需求阶段是最关键的介入节点。在项目立项时，产品经理就应该输出一份数据需求清单，明确AI功能所需的每一个字段、口径定义、数据时效要求和历史数据覆盖周期。这份清单需要与数据团队对齐，确认现有数据是否满足需求，如果不满足，补采集的周期是多久——这直接决定项目的可行性和时间线。
设计阶段，产品经理需要参与埋点规范的制定，而不是把它完全甩给工程师。埋点文档应该是产品设计文档的一部分，明确每个交易节点需要采集哪些字段、字段的数据类型和枚举值是什么、异常值如何处理。同时，这个阶段必须推动法务部门完成数据合规审查，确认数据使用方式符合相关法规要求。
上线阶段，产品经理需要推动建立数据监控看板，将数据质量指标（字段完整率、异常值比例、数据延迟）与模型效果指标放在同一个视图下监控。当数据质量出现问题时，需要有明确的告警机制和响应流程，而不是等到模型效果崩了才去排查原因。
迭代阶段，用交易数据做效果归因是AI产品经理最容易被忽视的能力。很多人在迭代时只看模型的离线指标（AUC、NDCG等），但这些指标和业务结果之间的关系并不直接。应该建立从交易数据出发的归因链路，搞清楚模型的哪些预测结果最终转化成了真实的业务价值，哪些没有——这才是驱动下一轮迭代方向的正确依据。
我写这篇文章，不是为了给AI泼冷水。恰恰相反，我非常相信AI在产品中的价值，也见过它真正发挥作用时的样子。
但我也见过太多人把AI项目的失败归因于技术不够成熟、算力不够强、模型不够先进。这些理由有时候是真的，但更多时候，它们是一种体面的说法，用来掩盖一个更难承认的真相：我们没有认真对待数据。
交易数据是AI产品的地基。地基没打好，楼盖得越高，倒得越快。
启动一个AI项目，问自己的第一个问题不是”我们用什么模型”，而是：
“我们的交易数据准备好了吗？”
好的AI产品经理，是从数据开始设计产品的，而不是从功能开始。这不是一句口号，是我见过足够多的失败之后，得出的最朴素的结论。
本文由 @van ner 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Pixabay，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。