个性化是一个排序问题——架构使其成为可能
内容提要
文章探讨个性化推荐的架构问题，指出许多团队面临的并非数据或算法质量不足，而是系统架构碎片化，导致检索、排序和业务逻辑分离，信号延迟且不完整。作者主张将个性化视为实时排序问题，通过统一管道整合文本、向量、用户行为及业务规则，并使用张量计算实现灵活评分，从而提升相关性和响应速度。
延伸解读
架构问题而非数据问题
文章指出，许多团队在个性化上的困境并非源于数据或算法不足，而是系统架构碎片化。检索、排序和业务逻辑分离，导致信号延迟或不完整，最终影响用户体验。这提醒我们，在优化个性化时，应优先审视架构是否支持实时整合多源信号，而非一味增加数据或调参。
实时排序的关键：统一管道
作者强调，个性化本质上是实时排序问题，需要将文本检索、向量相似度、用户行为、库存和业务规则等信号统一到同一查询管道中。通过张量计算，这些异构信号可以转化为可比较的评分项，从而在毫秒级内做出决策。这种架构避免了多次系统间传递带来的延迟和信号漂移。
业务规则作为排序信号而非硬约束
文章提出，业务规则（如促销、清库存）不应作为过滤或强制置顶的硬约束，而应作为排序表达式中的加权信号。这样既能实现商业目标，又不损害相关性。例如，在雨天提升雨伞的权重，但不会让所有搜索都变成雨伞推荐。这种灵活性也便于进行A/B测试和快速调整。
性能与灵活性的平衡
针对“更复杂的排序必然更慢”的担忧，文章介绍了多阶段排序策略：先用低成本的第一阶段快速缩小候选集，再对剩余结果应用更精确的评分（包括张量运算和模型推理）。这样既保证了大规模数据下的低延迟，又保留了足够的灵活性，使个性化成为可能。
Q&A
为什么很多团队的个人化推荐效果不好？
很多团队的个人化推荐效果不好，不是因为数据或算法质量不足，而是因为系统架构碎片化，导致检索、排序和业务逻辑分离，信号延迟且不完整。
个人化推荐应该被看作什么问题？
个人化推荐应该被看作一个实时排序问题，系统需要在每个请求中，综合用户、物品、上下文和业务目标，决定哪个结果应该排在哪个位置。
传统搜索和向量数据库在个人化推荐中有什么局限？
传统关键词搜索擅长词汇匹配，但无法处理同义词和长尾语言；向量数据库擅长语义相似性，但无法结合实时行为、库存、价格等业务信号。两者都无法单独实现真正的个人化排序。
Vespa如何实现实时个人化排序？
Vespa将文本搜索、向量相似度、结构化过滤、排名表达式、张量计算和模型推理整合在同一个查询管道中，使得检索和排序可以同时进行，并利用张量表示用户和物品特征，通过点积计算个人化得分。
如何将业务规则融入个人化排序而不损害相关性？
将业务规则作为排名表达式中的信号，而不是硬性过滤或覆盖。例如，可以提升积压库存的权重，但不会忽略用户意图；可以推广雨伞，但不会让所有搜索都变成雨伞搜索。这样既满足业务目标，又保持相关性。
实时个人化排序如何保证性能？
通过多阶段排序：先用快速的第一阶段缩小候选集，再对较小的候选集应用更精确的排序，包括张量运算、业务逻辑和模型推理。这样既保证了全语料库的速度，又保证了最终排名的准确性。
个人化排序架构适用于哪些领域？
个人化排序架构不仅适用于电商，还适用于新闻推荐、招聘匹配、内容流、广告投放等任何需要根据用户行为实时调整排序的产品。不同领域只需调整特征，架构模式相同。
