OpenAI 的 GPT-3.5-Turbo 模型显著缩短了流式响应的首字节响应时间。然而，构建发送给 GPT-3.5-Turbo 模型的提示通常是一个冗长且缓慢的过程，可能需要多次调用其他模型，以及第三方或内部服务，以生成被 GPT-3.5-Turbo 用来生成响应的情境学习内容。
虽然我们通常在创建提示之前就将文件嵌入，但搜索词的嵌入必须在执行搜索时实时完成。因此，嵌入的速度成为生成 GPT-3.5-Turbo 结果的关键。
最常见的提示生成任务之一是使用向量数据库从文档集合中检索相关信息。向量数据库存储了一个被称为嵌入的文档的数学表示，并使用近似最近邻等技术比较文档之间，或者与搜索词的相似度。在机器学习中，这个任务被称为语义搜索。
嵌入是由专门设计用于执行此任务的语言模型生成的。有许多不同的嵌入模型，每个模型都有独特的性能特征：准确性、速度、存储和内存使用等。它们也可能是多语言的，或者针对特定的自然语言进行训练。有些甚至针对特定的商业或科学领域进行训练。
虽然文件通常在创建提示之前就被嵌入，但是搜索词嵌入必须在执行搜索时即时创建。这使得嵌入的速度成为生成 LLM 结果的关键路径。
正如我们上文所讨论的，缓慢的文本生成影响用户体验，而生成文本的关键任务之一就是使用语义搜索查找相关内容。虽然我们应该考虑嵌入模型的成本、内存使用和实施的便利性，但这次调查仅关注嵌入的速度，以及在有的情况下，对语义相似性搜索任务的MTEB 基准性能。
我们测试了两个嵌入 API 服务和几个由 sentence-transformers 包支持的开源嵌入模型。我们选取的开源模型代表了在 MTEB 基准测试中得分高，且在 CPU 上表现良好的模型族。还有许多其他模型，你应该根据你的使用场景进行实验，以基准作为指导，而非铁律。
API 测试在 GCP 和 AWS 上进行，这符合了当今许多应用的场景。本地模型在几个云实例和我的 MacBook Pro M1（配备16GB RAM）上进行了测试。详细信息请见下文。
Google 的新嵌入 API 比 OpenAI 的快得多，而本地 CPU 上的开源模型最快。Google 的模型尚无检索基准，但 OpenAI 的模型在 MTEB 上得分最高。如果延迟是你的关注点，你可以考虑 Google 或开源模型。
OpenAI 的 text-embedding-ada-002 模型是许多开发者的首选。由于应用程序常常使用 OpenAI 的模型，因此开发者使用同样的 API 来嵌入文档是合理的。OpenAI 最近也大幅降低了这个 API 的价格。
事实证明，无论是从 AWS 还是 GCP 测量，OpenAI 嵌入 API 的延迟显著高于 Google 新的 textembedding-gecko@001 模型（仅从 GCP 测量）。
OpenAI 的性能波动较大——许多人都经历过在一些时候 OpenAI 的 API 扩展性差的情况。使用 Azure OpenAI Service 运行在 Microsoft Azure 中的应用，模型的延迟可能会更低。
152 6996 6441