Kumo Relational 能找出流失风险，但留存方案仍要验证

10 月 21 日，NVIDIA 推出 Kumo Relational。这款预训练模型可以利用相互关联的数据库表预测结果，客户流失就是官方列出的应用之一。对正在做 AI 产品的小团队来说，下一步很容易想到：接入账号、订阅和使用记录，让模型找出可能离开的客户。

真正的产品决策发生在预测之后。容易流失的客户，不一定是你的挽留方案能够帮助的客户。 按风险从高到低自动发优惠，可能把钱花在原本就会续费的人身上，打扰已经决定离开的客户，也可能错过一个本来可以修好的上手障碍。

本文面向考虑加入留存助手的非技术创始人和小型团队。我们会说明这次发布改变了什么、怎样定义有意义的流失目标，以及如何把模型推荐名单和现有做法放在同等条件下比较。你可以带走一个订阅产品场景和一份可复用的试点表。文中提供的是评估方法，没有部署 Kumo、复现 benchmark，也没有测得任何留存提升。

1. 这次发布降低了哪一部分门槛

NVIDIA 的 10 月 21 日发布文章介绍了一种利用关联表、在预测时读取带标签历史样例的模型。官方报告了 15 个数据库上 41 项任务的评估，也说明了预测信号必须能在有限的关联路径内找到等限制。这些是厂商报告的模型结果，不能证明一场留存活动有效。

它提供了一条值得尝试的路径：团队不必每提出一个预测问题，就先单独训练一个模型。关系型数据库会把有关联的记录放在不同表中，例如一个客户账号对应多个成员、多次订阅事件和多张工单。保留这些关系，有机会保留被单行汇总掩盖的差异。

关系基础模型，可以理解为预先学习过如何利用这种关联结构进行预测的模型。上下文学习，是预测时把带有已知结果的样例一同交给模型；这并不代表模型自动理解了你的商业目标。“无需针对每项任务训练”，也不代表任务定义、数据准备、评估和部署工作都消失了。

发布文章链接的 KumoRFM-2 论文早在 2026 年 4 月就已提交。本次热点是 10 月的产品介绍与分发，不是昨天才问世的一篇论文。判断新增证据有多少时，需要把这两个时间点分开。

对创始人而言，值得做的是一个更小的探索：关联产品数据，能否帮助现有团队发现被忽略的账号？它还不足以成为上线自动挽留 Agent 的理由。模型可用，改变的是研究问题的成本，并没有证明这个问题值得自动化。

在项目说明中，把三种主张分别列出：模型能生成分数；分数能改善待处理名单；按名单联系客户能够改善结果。三者需要不同证据，而这次发布直接回答的主要是第一层。

2. 先定义客户结果，再请求一个分数

“预测流失”不足以交给团队实施。它可能指取消意向、订阅终止、续费失败、停止使用、删除账号，也可能只是活跃度下降。这些事件的负责人和处理方法都不相同。

先用日常语言写目标，例如：“在每个符合条件的付费账号进入续费窗口时，预测它能否在下一次续费及约定的付款宽限期结束后，仍保持付费状态。”具体窗口和宽限期必须符合你的计费系统。这是任务定义示例，不是经过验证、可以直接执行的 Kumo 查询语法。

预测对象，是每条预测对应的单位。团队订阅通常应以账号为单位，而不是分别预测每个席位。标签，是用于核对预测的真实结果记录。预测范围，是要判断未来多远的结果。观察时点，是产品必须作出判断的时间。入选人群，规定哪些账号可以进入这套流程。

假设某个成员不再登录，只是因为同事接手了工作。按个人不活跃定义流失，会把一个正常续费账号里的成员误记成流失。扣款失败可能需要付款协助，而不是折扣。季节性客户也可能不经挽留就回来。客户提出取消，更不代表产品有权阻碍取消。

请计费或数据负责人逐条演示真实历史记录，说明每类情况由哪个事件确定最终结果。不同系统有冲突时，先明确哪个系统的记录作为依据。存在争议的样本应单独保留，不能默默选择更有利于模型的一种解释。

只评估已经走完整个结果窗口的账号。仍在付款宽限期内的账号，结果尚未确定；提前把它计为留存，会让薄弱的流程显得有效。报告结果时，同时列出排除样本和待确认样本。

这项定义属于产品规格。即便界面上仍写着“高风险”，从账号续费改成每周活跃度，也改变了功能的含义。给定义加上版本，下一次评估才能真正比较同一件事。

3. 把流失风险和联系客户的收益分开

流失分数根据数据中已有的模式估计结果。它本身不会告诉你：同一个客户在接受与不接受某项帮助时，分别会怎样。

后者是因果问题：如果为这个账号提供协助，相比维持现有服务，是否更可能留下？增量效果，指由这项干预带来的差异。可以用“能否被这项方案改变结果”来理解客户的可干预性，但它不是高流失分数的另一种叫法。

考虑三位客户：一位因为你无法满足某项要求，已经选定竞品；一位卡在初次设置，可能欢迎帮助；另一位最近使用减少，但通常都会续费。三者都可能进入风险名单，适当的行动及其收益却可能完全不同。

历史联系记录还会让解释变复杂。团队可能一直在主动联系看起来有风险的账号，这些账号后来的结果，同时受自身处境和所获帮助影响。用这些历史做训练或上下文，不会自动把两种影响分离。增加一列“是否联系过”，也不会让普通预测分数变成干预效果估计。

原作者提供的网络受控实验指南解释了随机对照为什么适合回答因果问题，也强调样本量和实验设计。应用到这里，意味着应面向未来比较联系策略，不能仅因部分收到消息的客户后来续费，就宣称挽留成功。

不要为了制造对照组而撤掉承诺过的支持或必要的付款通知。可以测试现有服务之外的可选帮助，例如额外提供一次上手指导。在联系任何客户之前，先确定谁可以入选、怎样分组，以及两组都继续享有哪些服务。

如果账号数不足以支持有意义的比较，团队仍可检查名单是否找对了人、员工是否觉得有用。这是运营层面的学习，不能包装成降低流失率的证据。

4. 具体场景：客服资源有限的订阅应用

假设有一款帮助小型代理公司制作客户报告的 AI 应用，拥有账号、成员、订阅、使用事件和客服工单等表。这是虚构的设计场景，以下数字只是规划假设，不是客户实测结果。

创始人想知道，留存助手是否值得替代每周整理的表格。客服每周最多能额外安排二十次设置辅导。目前的表格优先列出临近续费、最近没有完成报告的账号；新方案则利用关联历史，由模型给符合条件的账号排序。

比较之前，团队先确定一种固定帮助：围绕尚未完成的报告流程，提供一次简短设置辅导。已拒绝此类联系的账号、有投诉需要正常支持的账号，以及在规定间隔内已被联系的账号，都不进入本轮可选联系名单。取消订阅和付款问题仍按原流程处理。

再看一个导出报告变少的账号。简单粗暴的助手可能直接发：“您可能要离开，给您一个折扣。”人工审核者看到的则是尚未完成的数据源设置、待回复工单和续费日期。审核者先核实这些事实，再判断额外辅导是否合适。如果现有工单已经在处理同一件事，就不要再发一条重复消息。

模型给出的解释只是调查线索，不是客户离开原因的证明。负责起草消息的语言模型，不能把使用行为的相关性改写成“我们知道您不满意”。它可以在核实且适合提及的前提下，描述一个尚未完成的操作并提供帮助，而不替客户断言内心意图。

第一阶段以相同客服容量和入选规则比较名单，后续再用实验判断额外帮助是否有效。分开这两个问题，才能解释失望的结果：模型可能确实找到了容易离开的账号，只是团队提供的帮助没有解决他们的问题。

再漂亮的仪表盘也不能替你分清这两种情况。最初交付的应是一份可审核的小名单，有行动负责人，也能追踪结果。自动折扣和自动外发消息暂不进入首轮范围。

5. 按团队实际处理得完的名单评估

汇总 benchmark 分数，不等于每周名单对团队有用。AUROC 衡量的是模型在不同阈值下，把正例排在负例前面的能力；它不会直接告诉你，可联系的这些账号中有多少最终流失，更不会说明联系能否帮助他们。

RelBench为关系型数据提供了明确的预测任务和评估工具，是有价值的研究参考。但其任务和人群不是你的订阅约定或客服队列，而且 benchmark 的作者与模型研究可能有人员交集。它不能独立证明商业留存价值。

在虚构应用中，应选取同一批历史上符合条件的账号，分别运行模型和现有规则，只使用当时作决策已经可用的信息。每个周批次都只允许给出二十个建议。记录模型、上下文选择、目标定义和基线规则的版本，否则之后重新运行，比较条件可能悄悄发生变化。

查看名单中最终满足流失标签的比例、两种名单的重叠程度、遗漏账号，以及人工审核耗时。同时检查推荐是否几乎全挤在某个套餐或客户类型。整体指标有所提升，也可能对你主要服务的细分人群毫无帮助。

如果要在界面把百分比当作概率展示，就应确认它在相关人群中是否经过校准。scikit-learn 的概率校准指南区分了预测概率与真实发生频率的一致性，以及区分不同结果的能力。排序更好，不保证概率标签可信。如果尚不清楚这个数字对本地人群意味着什么，就不要展示“流失概率 83.7%”一类虚假的精确感。

不要根据哪个名单长度最能让新模型胜出，来倒推团队容量。容量应由真实客服流程决定；并列分数、排除账号怎么处理，也应提前写清。用来选择设置的数据，应与最终评估时段分开。

如果在相同投入下，名单确实更有用，这一阶段可以支持有限的线上试点。但它仍不能证明联系客户带来了额外续费。

6. 验证联系策略，分清分组与实际触达

线上试点需要一个足够窄、能够回答的问题。例如：对模型选出的合格账号，增加设置辅导邀请，相比现有服务能否改善续费？另一个问题是：在相同联系预算下，模型选人是否优于表格选人？两者需要不同的设计，不能拼成一张简单的上线前后对比图。

若要验证选人策略，请实验负责人先把符合条件的全部账号分到不同策略组，再分别生成名单。两种策略从自己的组里选人，每个合格账号对应的联系容量一致，提供的帮助也一致。分析时应覆盖分配到各策略的全部账号，包括没有被该组名单选中的账号。只比较实际联系名单，会比较两群经过不同方式筛选的客户，还可能遗漏对其他账号的影响。这套设计需要独立规划样本和容量，是帮助方案实验的另一种选择，不能事后从中多画一张图就算完成。

若要回答帮助本身是否有效，则请具备实验设计能力的人，在模型选出的合格人群内规划随机分组。启动前确定主要结果、观察范围、值得投入的最小效果、可接受损害、分析规则和所需样本。本文不给一个通用样本量：流失率低、希望发现的差异小，或账号差异大时，所需样本可能远超小团队的直觉。

多人共享订阅时，按账号分组。否则同事可能进入不同组，相互影响比较。即便员工没能联系到某个账号，也保留其原始分组。主要分析按最初分组比较结果；只报告接听或回复的人，会偏向本来就更愿意参与的客户。

分别记录分配与触达。“被分配到邀请组”“消息送达”“客户接受”“完成设置”是四个不同事件。所有人都继续获得正常客服，也应记录通过其他渠道发生的联系。如何处理这些交叉情况，应在查看结果前确定。

一轮有边界的实验只保持一种帮助方案。如果同时改价格、消息、选人规则和模型，就不能把结果归因于模型。重大变化应开启新实验版本，而不是悄悄混入原有批次。

停止新一轮投放后，还要留出观察时间。今天联系的账号，可能数周后才续费。活动结束时，应显示仍待确认的结果，不能提前定性。续费数据应同时报告不确定性及约束指标，例如投诉、拒收、员工耗时和方案成本。

即使得到正面结果，它也只适用于被测帮助、所选人群和该时段。不能由此推广到所有客户，更不能说模型已经学会找出“发折扣就能留下的人”。

7. 直接复用这份留存试点表

在把分数接到外发动作之前，先填完下表。这是建议采用的产品工作表，不是 NVIDIA 的要求。示例仍来自前面的虚构报告应用。

空白项不是无关紧要的文书工作。没有结果负责人，就没人能确定干预是否有效；没有数据边界，一次快速试验就可能暴露不必要的信息；没有容量规则，系统可能一边增加工作量，一边宣称提高生产力。

再保留一份逐账号记录，包含原始分组、资格检查、打分时间、人工判断、实际行动和最终结果。把“不符合联系条件”与“联系失败”分开。这些原因能够揭示模型是在生成好名单，还是把清理工作转交给客服。

这份表也应允许团队拒绝上线预测功能。如果同一轮分析发现了更值得优先修复的问题，例如损坏的集成，试点可以作为产品发现取得价值，而不必交付一个预测功能。照实记录发现，别把它重新命名成“模型带来的留存提升”。

8. 把模型周围的服务也计入预算

官方客户端仓库区分了发送预测请求的客户端，以及实际执行推理的 NIM 服务端点。客户端不需要 GPU，不等于整套系统不需要计算或托管资源。NIM 概览另行链接了部署、身份验证和预测指引。估算集成工作之前，先确认当前支持的路径。

问清谁负责运行端点、发送哪些数据、请求和结果记录在哪里，以及如何落实账号级访问权限。即使关联有助于预测，也不能把包含多个客户的产品数据库变成任意可读的数据池。起步可使用经过审查的数据提取，或适当受限的访问方式；用于上下文的历史样例也要纳入数据权限审查。

模型卡写明权重采用 OpenMDW 1.1。不能因为客户端仓库采用 Apache 许可证，就推断权重条款也一样。记录相关版本，并由负责人核对计划分发方式实际适用的许可证。

每周处理一次的名单，批量运行也许已经够用。如果客服周五才看名单，实时打分未必增加价值。把全流程成本记录下来：数据读取、推理、人工审核、消息发送、实际辅导时间，以及可能提供的优惠。在相同服务容量下，与现有流程比较。

试点前定义失败时的处理办法：分数不可用或已过期，应保留现有客服做法，不能把全部账号标记为安全，也不能突然启动群发活动。让团队能简单暂停额外联系，同时维持正常服务。

9. 什么时候简单规则或修复产品更合适

不要仅因为预测能力刚发布，就引入预测层。Google 的机器学习规则建议在增加复杂度之前，先建立指标和简单系统。对创始人而言，就是先认真比较已经在创造价值的流程。

客户很少、历史标签不可靠，或只有一个明显故障时，明确的规则可能更好。例如大家都卡在同一个集成步骤，修好集成，也许比预测谁会受其影响帮助更多客户。小团队也可能本来就逐个熟悉每次续费，再加一份模型名单只是重复劳动。

本文试点适用于可重复的账号级流程：有可信的结果记录、有用的关联数据，也有能够稳定提供一种可选帮助的团队。它不适合还没有完整续费历史的新产品、账号定义经常变化的业务，或员工根本无法兑现邀请中所承诺帮助的活动。

不要把这套轻量方法直接扩展到授信、雇佣、保险资格、医疗等后果重大的判断。这些场景需要自己的领域专业能力和评估要求。Benchmark 涉及这些领域，不代表本文工作表因此适用。

10. 下一步决策要看证据，而不是演示效果

开发布决策会时，带上四样东西：目标定义、与现有名单的同容量比较、填完的试点表，以及尚未解决的问题。一个看起来很准的预测样例还不够；团队必须能够还原谁符合条件，并最终核对真实结果。

几种结果应分别处理。如果模型没有明显增加价值，就继续用现有规则；如果分析暴露了基础问题，就先修数据或客户流程；如果名单有用、但帮助的增量效果未知，就做一次范围有限的可选帮助实验。只有在完整观察结果、成本和损害后，证据支持扩大，才扩大。

Kumo Relational 让预测式产品试验在今天值得考虑。创始人需要控制承诺的范围：找到值得关注的账号，提供团队真正交付得了的帮助，再测量这种帮助是否有效。

参考资料

• NVIDIA 10 月 21 日 Kumo Relational 发布文章：第一方发布及其评估结果，不是独立复现。
• KumoRFM-2 论文：模型背后的研究，提交于 2026 年 4 月。
• RelBench benchmark 项目：原始任务和评估参考，不是留存活动研究。
• NVIDIA Structured Data Models Client：客户端与服务端点结构；文档会更新。
• Kumo Relational NIM 概览：官方部署和使用文档入口。
• Kumo Relational 模型卡：模型身份、推理示例及权重许可证。
• scikit-learn 概率校准指南：概率解释与校准的限制。
• 网络受控实验实用指南：原作者的实验设计资料，最初发表于 2007 年。
• Google 机器学习规则：指标、基线与实际系统设计。