大型玩家的扩展技巧正变得越来越重要，这导致了架构反转的激增。
译自 Architecture Inversion: Scale by Moving Computation, Not Data，作者 Jon Bratseth。
你是否曾经想过，世界上最大的互联网和社交媒体公司是如何如此快速地向如此多的用户提供算法内容的？
想想像 TikTok 这样的公司需要做些什么才能为人们提供源源不断的个性化视频片段。他们拥有 某个模型 来代表用户，他们需要使用这个模型从数十亿个备选视频中找到最适合向特定用户展示的视频片段。而且，由于他们也有数十亿用户，他们需要每秒进行数百万次这样的操作。
解决 TikTok 问题的简单方法是将用户模型与每个视频片段进行比较，以确定每个视频片段与该用户的匹配程度。众所周知，这种蛮力方法无法扩展——对于十亿个视频和每秒一百万个请求，这将变成每秒一千万亿次比较！
对此的明显解决方案是索引：维护一个 数据结构，使之能够从用户模型中找到合适的视频片段，而无需考虑每个片段。例如，如果用户模型注意到对英语视频的偏好，则可以将视频与 B 树索引，该 B 树直接指向英语视频，以便可以忽略其余视频。或者，如果用户表示为兴趣向量嵌入，则可以使用向量索引（如分层可导航小世界 (HNSW) 算法）来查找具有相似向量的视频，而无需考虑其余视频。
实际系统将使用这些索引的组合。现在，索引只提供关于哪些视频可能适合用户的粗略指示。为了真正呈现用户发现最有趣或最有用的内容，你需要在用户模型和每个候选项目之间进行更准确的比较——如今通常使用 神经网络 来完成。这就是事情变得有趣的地方。
重新评分的常见方法是将从索引中检索到的候选项目传递给架构中的另一个组件，该组件执行每个项目的详细评分。应该以这种方式重新评分多少个项目？这应该是所有候选项目的一定比例。
要了解这一点，请考虑索引检索加上重新评分是对所有候选项目的蛮力评分的近似值，我们需要考虑的是这种优化带来的质量损失。这可以用给定视频（如果使用蛮力评估将显示给用户）出现在要重新排序的集合中的概率来表示。
随着该集合相对于候选项目完整集合的大小变小，该概率趋于零。随着要重新评分的比例减小，质量损失会变大，并且随着完整评分算法的改进，质量损失也会变大，因为有更多东西要失去。
让我们具体一点，假设我们想要重新评分 1% 的候选项目，并且每个项目包含 2kb 的对最终评分有用的数据（大约一个向量和一百个属性）。对于十亿个项目，这意味着每个请求需要重新评分 1000 万个项目，而对于每秒一百万个请求，这意味着我们需要每秒移动 20 PB 的数据进行重新排序！即使是这个小比例也显然离可行性很远，那么大型公司在做什么呢？
答案是他们没有将数据移动到评分计算节点，而是将评分计算移动到索引中，以便在数据所在的位置本地执行，从而绕过了整个问题。
现在，为什么我们其他人应该关心这个问题，因为我们很幸运地没有像 TikTok、Google 等公司那样拥有数十亿用户？许多因素变得越来越重要：
- ML 算法正在改进，本地计算能力也在提高，这意味着完全评分项目比以前更能提高质量和最终利润。
- 随着 向量嵌入 的出现，此类算法消耗的信号数量增加了 1 到 2 个数量级，使得网络瓶颈更加严重。
- 使用越来越多的数据来解决问题越来越具有成本效益，这意味着需要重新评分更多数据以保持恒定的质量损失。
- 随着此类系统数据的消费者从主要为人类转变为主要为 LLM，RAG 解决方案，它在比以前更多的应用程序中更快地提供大量评分数据方面变得有利。这将最终导致大多数应用程序都与向 LLM 提供高质量数据以进行长链推理有关，从而以非人速度做出高质量的业务决策。
出于这些原因，最大玩家的扩展技巧对于我们其他人来说变得越来越重要，这导致了当前的架构反转的激增，从传统的两层系统（其中数据从搜索引擎或数据库中查找并发送到无状态计算层）转变为将该计算插入数据本身。
现在，要真正做到这一点，您还需要一个能够实际管理您的数据的平台，以这种方式对数据进行索引和计算。这导致了 Vespa.ai 的普及，该平台最初是雅虎在还是大型玩家之一时用于架构反转的解决方案。该技术后来开源了。
Vespa.ai 允许您将结构化数据、向量/张量和全文一起存储和索引在任意数量的机器上，并在数据存储的本地执行任何类型的张量计算和机器学习推理。