百度推荐算法外包前应整理哪些需求：先分清推荐与搜索两条线
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /17a9a55576b0.html
📄
百度推荐算法外包前应整理哪些需求：先分清推荐与搜索两条线
百度推荐算法外包前，最该整理的不是“我要做推荐”，而是把业务目标、数据现状、推荐场景和验收口径写成可执行的需求清单。百度体系里，搜索排序和推荐分发是两套不同逻辑：搜索更依赖查询词与页面相关性，推荐更依赖用户行为与内容特征。外包需求若混在一起，接单方只能按自己的理解做，最终交付往往对不上你的预期。
准备阶段：先明确你要解决的是推荐还是搜索
这一步是整份需求里最关键的分界线。很多团队把“百度推荐算法”理解成“让内容被百度搜到”，但推荐算法通常服务于站内信息流、相关阅读、个性化列表等场景，目标是把合适内容推给合适的人；而搜索优化关注的是用户主动查询时，页面能否被抓取、索引并出现在结果中。两者可以共存，但外包合同、数据接口和验收指标完全不同。
整理时可以用一张对照表把需求钉死：
- 场景：是站内“猜你喜欢”，还是搜索结果排序？前者看点击率、停留时长、转化；后者看查询相关性、索引覆盖。
- 数据：推荐需要用户行为日志、内容标签、曝光点击序列；搜索需要页面文本、链接结构、抓取状态。
- 交付物：推荐通常交付模型、特征管道、在线服务接口；搜索优化通常交付页面结构调整、内链方案、内容策略。
如果外包方在沟通时把两者混为一谈，要求你“先做关键词密度”，而你的真实目标是提升信息流点击率，这就是需求没写清的信号。适用条件是：你已有一定量的用户行为数据，且日活或内容量足以支撑模型训练；如果数据量极小，先做规则推荐或人工运营位，比直接外包复杂模型更划算。
实施阶段：需求清单要写到可验收的粒度
外包前把下面几类信息整理成文档，能显著减少返工：
- 目标定义：写清优化指标，例如“提升推荐列表的点击率”或“降低重复推荐率”。不要只写“提升推荐效果”。
- 数据现状：有哪些日志字段、埋点是否完整、历史数据保留多久、是否有内容标签体系。缺失项要标注由谁补。
- 场景约束：推荐出现在哪些页面、每次展示几条、是否允许实时更新、冷启动用户怎么处理。
- 技术边界：现有服务端语言、能否接受新增依赖、模型部署在自有服务器还是云端、响应时间上限。
- 验收方式：用离线指标还是在线 A/B 测试，测试周期多长，达到什么数值算通过。
这里可以给一个假设例子说明验收口径的写法：假设你的站内信息流当前点击率为 4%，希望外包后提升到 5%。需求里应写明“以连续 7 天在线 A/B 测试为准，实验组相对对照组点击率提升不低于 1 个百分点，且人均停留时长不下降超过 5%”。这只是示例，不是真实项目数据。适用条件是你能稳定分流并控制变量；如果流量太小，在线测试波动大，应改用离线评估加人工抽检。
验证阶段：区分“可能原因”和“已经定位的原因”
外包交付后，推荐效果不达预期时，不要直接断定是算法问题。可能原因包括：埋点数据缺失、特征口径不一致、曝光日志重复、测试流量分配不均、内容池本身供给不足。已经定位的原因则必须有证据，例如日志比对发现某字段为空、A/B 分组比例明显偏离设定。
核查时按顺序做：
- 先检查数据管道：输入特征是否与训练时一致，有无空值或时间错位。
- 再检查在线服务：接口返回是否稳定，响应时间是否超出约定。
- 最后检查实验设计：对照组和实验组是否真的只差推荐策略这一个变量。
如果外包方只给一个“模型准确率”数字，而不提供可复现的评估脚本和数据集划分，验收就很难成立。判断结果是：能复现、能解释、能对照，才算验证通过；只能演示一次效果，不能算。
维护阶段：把迭代责任和退出条件写进需求
推荐算法不是一次交付就结束。外包需求里要明确维护期内的责任：谁负责监控指标下降，谁负责重新训练，数据漂移时多久响应，代码和模型文件归属谁。退出条件也要写清，例如“连续两周核心指标低于约定下限，且非数据供给问题，则触发整改或终止条款”。
同时保留自有能力：至少让内部人员能读懂特征表、能跑通评估脚本、能替换模型文件。这样即使更换外包方，也不会被单一供应商锁死。适用条件是项目会持续运营；如果只是一次性活动页推荐，维护条款可以简化，但仍要拿到数据和代码。
下一步，把上面四类内容整理成一页需求摘要，先和候选外包方做一次场景对齐，再决定是否进入报价和合同阶段。
