★ FEATURED ARTICLE 1. 从两篇论文看推荐与检索系统的演进方向9月21日前后快手和Meta各自放出了一篇值得细读的论文。快手这边聚焦的是广告投放里的自动出价问题Meta那边则是对超大规模检索系统做了一次架构层面的重构。两篇论文看似分属不同业务场景但底层逻辑有共通之处都是在超大规模数据和高并发请求的约束下寻找更优的工程解。如果你在做推荐系统、广告算法、搜索引擎或者大规模检索引擎相关的工作这两篇论文里的思路都值得花时间琢磨。即便你不在这个领域理解它们背后的设计哲学——如何在资源受限时做取舍、如何用统一框架替代碎片化方案——对做任何工程系统都有参考价值。我花了两天时间把这两篇论文的核心内容梳理了一遍结合自己过去在广告系统和检索系统上踩过的坑整理成这篇笔记。不是逐段翻译论文而是把关键设计决策背后的“为什么”讲清楚同时补充一些论文里没展开、但实际落地时一定会遇到的细节问题。2. 快手统一自动出价从碎片化策略到端到端框架2.1 自动出价到底在解决什么问题先给不熟悉广告系统的读者补个背景。在效果广告里广告主需要为每一次曝光出价价高者得。但手动出价有个根本矛盾广告主真正关心的是转化成本比如一个下单、一个激活多少钱而不是曝光本身的价格。手动调价意味着广告主要反复根据转化数据去调整出价既费人力又容易滞后。自动出价要做的就是把这个过程自动化——系统根据广告主设定的目标转化成本自动决定每一次曝光的出价。听起来简单但实际做起来涉及几个核心难点。第一个难点是延迟反馈。用户点了广告之后可能过几个小时甚至几天才完成转化。出价的时候你并不知道这次曝光最终会不会带来转化只能基于历史数据去预估。第二个难点是预算约束。广告主一天给5000块预算系统要在花完预算的前提下尽量多拿转化不能前半天就把钱烧完也不能到晚上还剩一大半没花出去。第三个难点是多目标平衡。不同广告主对成本的敏感度不同有的要求严格控制在目标成本以内有的愿意接受一定波动换取更大的量。快手这篇论文的核心贡献是把过去分散解决的几个子问题——出价决策、预算分配、成本控制——整合到一个统一的框架里。过去常见的做法是分模块处理一个模块负责预估转化率一个模块负责调价一个模块负责控预算。模块之间的目标不一致时就会出现“各自都做了局部最优决策但全局效果不是最优”的情况。2.2 统一框架的设计思路与关键取舍论文提出的统一框架核心思路是把自动出价建模成一个序列决策问题用强化学习的思路来求解。但和直接套用标准强化学习不同他们在几个关键点上做了针对性设计。状态表示的设计。出价决策需要考虑的信息很多当前时间点、已消耗预算、已获得转化数、当前预估的转化率分布、竞品出价环境等等。论文里把这些信息编码成一个固定维度的状态向量但特别强调了时间特征的编码方式。他们没用简单的时间戳归一化而是用了周期性的时间编码让模型能感知到“一天中的哪个时段”和“一周中的哪一天”。这个设计有实际意义——广告流量的时段分布差异很大早高峰和深夜的竞争环境完全不同。动作空间的设计。出价动作是连续值直接输出一个出价金额。但论文里没有让模型完全自由地输出任意值而是让模型输出一个相对于基准出价的调整系数。基准出价由预估转化率和目标成本计算得出模型只负责在这个基准上做微调。这样做的好处是缩小了动作空间的探索范围训练更稳定。我自己的经验是在广告出价场景里让模型从零开始学一个绝对出价收敛非常慢而且容易在训练初期产生极端值导致预算瞬间耗尽。用相对调整的方式相当于给模型加了一个强先验训练效率和稳定性都会好很多。奖励函数的设计。奖励信号直接决定了模型学到的策略长什么样。论文里的奖励函数包含两部分转化收益和成本偏差惩罚。转化收益就是实际获得的转化数乘以广告主设定的转化价值。成本偏差惩罚则是实际转化成本和目标转化成本之间的差距。这里有个细节值得注意惩罚项不是简单的线性惩罚而是用了分段函数——当实际成本低于目标成本时惩罚系数较小当实际成本超出目标成本时惩罚系数急剧增大。这个设计背后的逻辑是广告主对超成本比对省成本敏感得多。省了钱广告主一般不会投诉但超了成本广告主会立刻来问。分段惩罚让模型在策略上学到“宁可稍微保守一点也不要冒超成本的风险”。2.3 训练与部署中的工程细节论文里花了不小篇幅讲训练流程这部分对实际落地的人最有参考价值。离线训练与在线推理的差异处理。离线训练时可以用完整的转化数据但在线推理时转化数据是逐步到达的。论文里用了重要性采样的方法来纠正这种分布差异。具体来说离线数据里那些“曝光后很快转化”的样本会被赋予更高的权重因为在线环境下系统能更快拿到这些样本的反馈。而那些“曝光后很久才转化”的样本权重会被调低因为在线环境下系统在出价时根本等不到这些反馈。探索策略的设计。强化学习训练需要探索但在广告出价场景里无节制的探索意味着真金白银的浪费。论文里用了受限探索的策略只在基准出价附近的一个小范围内做随机扰动而且扰动幅度随着训练轮次逐渐减小。训练初期扰动大一些让模型充分探索训练后期扰动小让策略趋于稳定。这个退火式的探索策略在工业界很常见但论文里给出了具体的退火曲线和参数选择依据对复现很有帮助。冷启动处理。新广告计划没有历史数据模型无法准确预估转化率。论文里的做法是用一个基于相似广告计划的先验估计作为初始值随着新计划积累数据逐渐从先验过渡到模型预测。过渡的速率由一个超参数控制论文里建议这个超参数根据广告计划的日预算来调整——预算大的计划过渡快一些因为能更快积累足够的数据预算小的计划过渡慢一些避免过早依赖不准确的模型预测。实操心得自动出价系统上线初期建议先用规则策略跑一段时间积累数据等数据量足够再切换到模型策略。直接冷启动上模型前几天的成本波动会非常大广告主体验很差。2.4 效果评估与常见误区论文里报告了离线评估和在线AB实验的结果。离线评估用的是历史日志回放的方式在线实验则是在快手广告平台上做的真实流量测试。从报告的数据看统一框架相比之前的模块化方案在转化成本达标率上有明显提升同时预算消耗的平滑度也更好。但这里我想提醒一点看论文里的效果数据时要注意区分“统计显著”和“业务显著”。转化成本降低2%在统计上可能显著但在业务上广告主未必能感知到。真正让广告主有感知的往往是成本波动的降低——比如之前日转化成本在目标值上下浮动20%现在浮动范围缩小到10%以内。这种稳定性的提升对广告主的投放信心影响更大。另一个常见误区是过度追求单次出价的精准度。自动出价是一个序列决策问题单次出价差一点没关系只要整体预算分配合理、成本控制达标就行。我见过一些团队花大量精力去优化单次出价的预估模型但对预算分配策略的优化投入不足结果整体效果提升有限。论文里的统一框架之所以有效很大程度上是因为它把预算分配和出价决策放在一起优化了而不是分开处理。3. Meta超大规模检索重构从多级索引到统一表示3.1 超大规模检索面临的核心瓶颈Meta这篇论文讨论的是超大规模检索系统的架构重构。这里的“超大规模”是什么概念论文里提到的检索库规模在百亿级别每天处理的检索请求在数十亿次量级。在这种规模下传统的多级索引架构——比如先做粗排再做精排——会遇到几个瓶颈。第一个瓶颈是级联误差。粗排阶段会过滤掉大量候选如果粗排阶段漏掉了真正相关的文档精排阶段再准也没用。在百亿级别的库里粗排的召回率哪怕只下降一个百分点绝对数量上就是上亿的文档被错误过滤。第二个瓶颈是表示不一致。粗排和精排通常用不同的模型、不同的特征、不同的向量表示。粗排用的向量维度低、精度低精排用的向量维度高、精度高。两套表示之间的不一致会导致“粗排觉得相关、精排觉得不相关”的情况频繁发生。第三个瓶颈是更新延迟。多级索引的更新是分级的粗排索引更新快但精度低精排索引精度高但更新慢。新内容从入库到能被精排检索到中间有可观的延迟。对于时效性强的检索场景这个延迟是不可接受的。Meta的重构思路是用一套统一的向量表示来替代多级索引所有文档用同一个模型编码成高维向量检索时直接在向量空间里做最近邻搜索。这样就不存在级联误差和表示不一致的问题更新延迟也大大降低——新文档编码成向量后直接插入索引即可。3.2 统一向量表示的技术挑战与解法想法很美好但实现起来有几个硬骨头要啃。第一个硬骨头是向量维度与检索效率的矛盾。高维向量检索精度高但计算量大。论文里用的向量维度是768维在百亿级别的库里做精确最近邻搜索是不现实的。他们的解法是用近似最近邻搜索具体来说是基于量化的方法。把768维的向量压缩成紧凑编码检索时先用压缩编码做快速筛选再对少量候选做精确距离计算。这里有个关键设计量化编码不是简单的降维而是保留了向量之间的相对距离关系。论文里用了乘积量化的变体把768维向量切分成若干子空间每个子空间单独做聚类量化。检索时查询向量和文档向量的距离可以分解成各子空间距离之和这样就能用查表的方式快速计算近似距离。第二个硬骨头是索引更新与检索性能的平衡。向量索引的更新通常需要重建部分索引结构重建期间检索性能会下降。论文里用了增量更新的策略新文档的向量先插入一个小的增量索引检索时同时查主索引和增量索引定期把增量索引合并到主索引。合并的时机选择很关键——太频繁合并会影响检索性能太久不合并增量索引会越来越大检索时需要查的索引数量增多。论文里给出的合并策略是基于增量索引的大小和检索延迟的监控数据来动态决定的。当增量索引的大小超过主索引的5%时或者检索延迟的P99超过阈值时触发合并。这个策略比固定时间间隔合并要合理得多因为它考虑了实际的检索负载情况。第三个硬骨头是模型更新与索引一致性的问题。检索模型不是一成不变的模型更新后所有文档的向量表示都需要重新计算。在百亿级别的库里全量重新编码的成本极高。论文里的解法是双塔结构加增量更新查询编码器和文档编码器分开训练文档编码器的更新频率低于查询编码器。当文档编码器更新时只对活跃文档近期有检索请求的文档重新编码冷门文档的向量保持旧版本直到它们被检索到时再异步更新。3.3 工程实现中的关键参数与调优经验论文里给出了不少工程实现细节这部分对做检索系统的同行最有参考价值。索引分片策略。百亿级别的向量索引不可能放在一台机器上必须分片。论文里用的分片策略是按文档ID的哈希值分片而不是按向量聚类分片。按哈希分片的好处是负载均衡好做每个分片的大小和查询量都比较均匀。按聚类分片虽然能让相似的向量落在同一个分片减少跨分片查询但容易出现热点分片——某些聚类中心附近的向量特别多对应的分片就会成为瓶颈。查询路由策略。查询请求需要路由到所有分片每个分片返回Top-K结果最后合并。论文里用了两阶段路由第一阶段用轻量级的粗筛模型快速排除明显不相关的分片第二阶段只对可能包含相关结果的分片做精确检索。粗筛模型用的是低维的向量表示虽然精度不高但足以排除掉大部分不相关的分片。缓存策略。热门查询的结果会被缓存但缓存什么、缓存多久有讲究。论文里用了基于查询频率和结果稳定性的缓存策略高频查询且结果变化不大的缓存时间长低频查询或结果变化快的缓存时间短或不缓存。结果稳定性用一个滑动窗口内的结果变化率来衡量。注意事项向量索引的量化编码会引入精度损失在评估检索质量时不能只看召回率还要看排序质量。有些情况下召回率没降但排在前面的结果相关性变差了用户体验反而下降。3.4 对检索系统架构设计的启示Meta这篇论文的价值不仅在于它提出的具体方法更在于它展示了一种架构演进的思路当多级索引的复杂度带来的收益不足以抵消其成本时就应该考虑用统一表示来简化架构。这个思路对其他系统也有借鉴意义。比如推荐系统里的多路召回本质上也是一种多级索引——不同召回路径用不同的模型和特征最后合并。如果有一天统一表示的技术足够成熟多路召回是否也可以被单一的高质量向量召回替代当然这取决于业务场景有些场景下多路召回的多样性是必要的单一向量召回可能陷入信息茧房。另一个启示是关于“精度与效率的权衡”。Meta的选择是在保证检索质量的前提下用近似最近邻搜索来换取效率。这个选择的前提是近似搜索的精度损失在可接受范围内。如果业务场景对检索精度要求极高比如法律文书检索近似搜索可能就不合适。架构选择永远要服务于业务目标没有放之四海而皆准的方案。4. 两篇论文的交叉视角LLM Agent在系统优化中的角色4.1 LLM Agent能否辅助出价策略与检索优化这两篇论文本身没有直接涉及LLM Agent但结合当前的技术趋势可以思考一下LLM Agent在这两个场景里能扮演什么角色。在自动出价场景里LLM Agent可以用于策略的解释和诊断。自动出价模型是一个黑盒广告主经常问“为什么今天成本超了”。传统的做法是给广告主看一堆指标曲线但广告主未必能理解。如果用LLM Agent来分析出价日志和成本数据生成自然语言的诊断报告——“今天下午3点到5点竞争环境加剧导致实际出价高于预期建议适当放宽成本容忍度”——广告主的接受度会高很多。在检索场景里LLM Agent可以用于查询理解和结果重排。用户的检索查询往往很短、很模糊传统的查询扩展方法基于统计共现效果有限。用LLM来做查询理解把模糊查询扩展成更明确的检索意图再配合向量检索能提升检索质量。Meta的检索系统里是否用了LLM做查询理解论文里没有明确说但从技术趋势看这是很自然的方向。4.2 从工程落地角度看LLM Agent的局限性不过也要冷静看待LLM Agent的局限性。在出价场景里LLM的推理延迟是个问题。出价决策需要在毫秒级完成LLM的推理延迟通常在百毫秒级以上直接用于在线出价不现实。更可行的方式是用LLM做离线策略分析和诊断在线出价还是用轻量级的模型。在检索场景里LLM的推理成本是个问题。每次查询都调LLM做查询理解成本太高。可行的方式是用LLM离线生成查询扩展词典在线检索时查词典即可。或者用蒸馏的方法把LLM的查询理解能力蒸馏到一个小的模型里在线用蒸馏后的小模型。我自己的经验是LLM Agent在系统优化里的角色更适合定位为“离线分析师”而不是“在线决策者”。让它去分析日志、发现异常、生成报告、提出优化建议这些任务对延迟不敏感LLM的能力能充分发挥。但让它直接做在线决策目前的延迟和成本都还不太现实。5. 实操复现建议与避坑指南5.1 自动出价系统的复现路径如果你想复现快手这篇论文里的自动出价框架我建议按以下路径推进。第一步是搭建仿真环境。不要直接上真实流量先用历史日志搭建一个仿真环境。仿真环境需要模拟几个关键要素流量时段分布、竞品出价分布、转化延迟分布。流量时段分布可以从历史日志里统计得到竞品出价分布可以用历史成交价格来近似转化延迟分布需要根据业务特点来设定——电商类转化延迟短游戏类转化延迟长。第二步是实现基准策略。在实现强化学习策略之前先实现一个基于规则的基准策略。基准策略可以很简单出价等于目标转化成本乘以预估转化率再乘以一个固定的调整系数。这个基准策略的作用是提供一个对比基线同时也能帮你验证仿真环境的合理性——如果基准策略在仿真环境里的表现和它在真实环境里的表现差距很大说明仿真环境有问题。第三步是逐步引入学习策略。不要一上来就用复杂的强化学习先从上下文老虎机开始。上下文老虎机可以看作是强化学习的一个简化版本它不考虑长期回报只考虑即时回报。在出价场景里即时回报就是当前曝光的转化收益减去成本。上下文老虎机的训练更稳定收敛更快可以作为强化学习的一个预热阶段。第四步是在线AB实验。仿真环境里表现好的策略在真实环境里未必好。上线AB实验时建议先用小流量测试观察成本波动和预算消耗情况。如果成本波动在可接受范围内再逐步扩大流量。5.2 向量检索系统的搭建要点复现Meta的向量检索系统门槛比自动出价高不少因为涉及大规模分布式系统的搭建。但如果你只是想在小规模数据上验证核心思路可以按以下步骤来。向量编码模型的选择。论文里没有公开他们用的具体模型结构但根据描述应该是一个双塔结构查询塔和文档塔分开。你可以用开源的句向量模型作为起点比如用对比学习的方法在业务数据上微调。微调时要注意负样本的构造——随机负样本太简单模型学不到有区分度的表示。建议用批内负样本加难负样本挖掘的方式。近似最近邻搜索库的选择。开源的近似最近邻搜索库有不少选择比如Faiss、ScaNN、HNSW等。选择时主要考虑几个因素支持的索引类型、内存占用、查询延迟、更新便利性。Faiss的功能最全但API比较复杂HNSW的查询延迟低但内存占用高ScaNN的量化做得好但社区活跃度相对低一些。建议先用Faiss快速验证再根据实际需求做选型。评估指标的设计。检索系统的评估不能只看召回率。建议同时看几个指标召回率相关文档被检索到的比例、MRR第一个相关结果的平均排名倒数、NDCG考虑排序位置的检索质量。如果业务场景对时效性有要求还要看新文档被检索到的延迟。5.3 常见问题速查问题现象可能原因排查方向自动出价成本持续超标转化率预估偏高检查预估模型的离线AUC和在线校准曲线预算消耗前半天就接近上限出价策略过于激进检查探索策略的扰动幅度和退火曲线向量检索召回率突然下降索引更新导致的一致性问题检查增量索引和主索引的合并日志检索延迟P99升高索引分片负载不均检查各分片的查询量和索引大小分布新文档检索不到增量索引未及时合并检查合并触发条件和合并任务的执行记录避坑提示自动出价系统上线前一定要做压力测试。我见过一个团队在测试环境跑得好好的上线后遇到流量高峰出价服务响应超时导致大量曝光机会被浪费。压力测试要模拟真实的高峰流量不能只用平均流量来测。6. 一些个人体会这两篇论文看下来最大的感受是工业界的系统优化越来越倾向于“端到端”和“统一表示”。快手的自动出价把分散的模块整合成统一框架Meta的检索把多级索引替换成统一向量表示。背后的逻辑是一样的——当系统复杂度带来的维护成本和误差累积超过某个阈值时简化架构、统一表示就是更优的选择。但“统一”不等于“简单”。统一框架内部的复杂度其实更高只是复杂度被封装起来了。快手论文里的强化学习框架训练和调参的复杂度比之前的模块化方案高不少。Meta的向量检索系统工程实现的复杂度也比多级索引高。选择统一方案的前提是团队有足够的技术能力去驾驭这个复杂度。另外一点体会是关于论文里的效果数据。论文里报告的效果提升通常是在特定条件下的换一个业务场景未必能复现。看论文时要关注它的问题定义和约束条件判断这些条件和你自己的场景是否匹配。匹配度高方法可以借鉴匹配度低就要谨慎评估迁移成本。最后说一个实操中的小技巧。不管是做自动出价还是做检索系统建议都先搭一个轻量级的仿真环境。仿真环境不需要很精确能反映主要趋势就行。在仿真环境里快速迭代策略验证有效后再上真实环境。这样试错成本低迭代速度快。我自己的经验是仿真环境里跑一周能验证的东西在真实环境里可能要跑一个月。
阅读完成 · 觉得有帮助？
