摘要：讨论低频、样本少、决策成本高的 B2B 推荐场景，如何组合规则、时效、业务阶段和反馈信号，构建可解释的排序系统。
关键词：推荐系统、B2B 推荐、可解释排序、Learning to Rank、商机推荐、冷启动
推荐系统的经典案例大多来自短视频、电商和音乐：用户行为密集，反馈速度快，模型可以从海量点击中不断学习。但很多 B2B 场景恰好相反。
一次项目决策可能持续数周，真正的正样本很少；用户不点击并不代表不感兴趣，也可能只是尚未处理；一个错误推荐不会只浪费几秒钟，而可能占用销售、售前和管理人员数小时。
在这种低频、高成本场景中，一开始就追求复杂模型通常不会带来最好的投入产出比。更可靠的顺序是：先建立可解释的候选集和排序基线，再逐步引入行为学习。
图 1：推荐结果同时展示匹配度、命中方向和阶段提示。截图取自标脉云的真实业务界面。
先定义“值得推荐”，再定义分数
推荐系统经常从“有哪些特征”开始讨论，但低频 B2B 产品更应该先回答：什么样的项目值得让用户花时间核验？
一个相对完整的定义通常包含四类条件：
- 业务相关：产品、服务、行业或采购主体与企业能力有关；
- 时间有效：项目仍处于可以采取行动的阶段；
- 交付可行：地区、规模、资质和周期没有明显冲突；
- 信息充分：至少能够找到支撑初步判断的正文或附件。
这四类条件里，有些适合做硬过滤，有些适合参与排序。例如，已经过期且无法补救的项目可以直接过滤；地区偏好则更适合作为加减分项，因为企业可能接受跨区域机会。
一个可解释的排序基线
在数据量有限时，可以先用线性评分建立基线：
score = relevance+ freshness+ stage_value+ buyer_affinity+ evidence_quality- expiry_risk- noise_penalty
这里的关键不是公式本身，而是每一项都能向用户解释。
例如，“命中软件开发方向”“当前处于采购阶段”“结果公告已降低优先级”都属于可读的解释。用户可以据此判断排序是否符合自己的业务逻辑，产品团队也能更快定位推荐偏差来自召回、数据还是权重。
业务阶段不能只当普通标签
在项目型业务中，文档阶段直接影响行动价值。采购意向可能适合提前建立关注，采购公告适合评估是否参与，更正公告需要检查原计划是否变化，结果和合同公告则更适合做客户研究或竞争分析。
因此，同一个关键词命中在不同阶段的分数不应相同。更重要的是，阶段权重需要随用户目标变化：销售人员关注即将开始的项目，市场研究人员可能更重视结果和历史合同。
一种简洁做法是让用户先选择任务模式，再应用对应的重排策略，而不是试图用一个全局分数满足所有角色。
冷启动时，企业画像比用户画像更重要
面向个人的产品通常从个人行为学习偏好，而 B2B 工具的第一版更适合从企业画像开始：核心能力、服务区域、典型项目、排除方向和必要资质。
企业画像的优点是可以由团队明确确认，不需要等待大量行为数据。但它也有明显风险：资料可能过期，内部表述与市场用语不同，能力边界也可能被写得过于宽泛。
因此画像字段应该带有更新时间、责任人和来源。推荐理由最好引用具体画像字段，而不是只展示一个无法解释的百分比。
负反馈要比点击更具体
低频场景里，单纯记录“点击/未点击”几乎不够。更有价值的反馈是用户为什么放弃：
- 业务不匹配；
- 地区不可交付；
- 资质不满足；
- 时间已来不及；
- 项目规模不合适；
- 已有其他团队处理；
- 信息不足，暂不判断。
这些原因可以直接反哺规则、画像和训练数据。特别要把“信息不足”与“明确不相关”分开，否则系统会把数据质量问题错误学习成用户偏好。
推荐指标应该贴近业务动作
在低频 B2B 场景中，CTR 很容易误导。更合适的指标包括：
- 推荐结果进入人工核验的比例；
- 被保存或分配负责人的比例；
- 明确反馈原因的覆盖率；
- 从推荐到首次处理的时间；
- 推荐项目最终进入有效跟进的比例；
- 被降权项目中仍被用户恢复查看的比例。
同时需要观察推荐量。如果一天推送几十条“高相关”结果，用户仍然需要重新做一遍搜索，推荐系统就没有真正降低判断成本。
什么时候再引入更复杂的模型
当系统积累了稳定的候选生成逻辑、明确的反馈原因和足够多的团队行为后，再考虑 Learning to Rank、语义匹配或多目标优化会更合适。
模型上线后也不应删除原有解释层。可以让模型负责排序，让规则负责硬约束与安全边界，并保留关键特征贡献或业务理由。对于用户而言，“为什么排在这里”往往比“模型有多先进”更重要。
结语
低频 B2B 推荐系统的核心不是制造更多点击，而是帮助用户更早排除不值得处理的项目，把有限时间留给真正需要判断的机会。
先建立可解释的排序基线，明确阶段价值和负反馈，再用模型优化，是一条更稳健的演进路径。复杂度应该随着证据增长，而不是随着想象增长。