翻译自 Generative AI: How to Choose the Optimal Database 。
评估新数据库或现有数据库以处理生成 AI 工作负载时要考虑的八个组件。
似乎几乎每一天都带来了一种新的人工智能应用，推动了可能性的边界。尽管生成式人工智能引起了广泛关注，但一些备受关注的错误行为再次提醒世人：“垃圾进，垃圾出。”如果我们忽视底层的数据管理原则，那么输出就不能被信任。
技术专业人员不仅必须发展他们的数据策略和现有的数据基础设施，以利用大型语言模型（LLM）的涌入并解锁新的见解，而且他们还必须确定哪些技术在启用 AI 工作负载方面最好和最有效。
但是，组织需要哪些数据库组件来利用 LLM 在专有数据上的力量？
支持 AI 工作负载的数据库必须支持低延迟和高度可伸缩的查询。LLM 的世界正在以非常快的速度扩展 - 一些模型是完全开源的，而另一些是半开放的，但具有商业 API 。
在决定如何评估新数据库或现有数据库以处理生成 AI 工作负载时，需要考虑许多因素。下图显示了交付 AI 工作负载所需的基本功能，并对其进行了更详细的解释：
- 摄取/向量化
GPT-4 等 LLM 的训练数据基于截至 2021 年 9 月的数据。如果没有浏览器插件等增强功能，响应就会过时 - 组织希望根据最新数据做出决策。
因此，数据库的摄取功能必须包括以下能力：
- 摄取、处理和分析多结构化数据。
- 摄取批处理和实时流数据，包括从各种数据源（包括 Amazon Simple Storage Service （S3）、Azure Blobs、Hadoop 分布式文件系统 （HDFS） 或 Kafka 等流服务）轻松提取数据（每秒多达数百万个事件）的能力。
- 调用 API 或用户定义的函数将数据转换为向量。
- 为快速向量（相似性）搜索的向量编制索引。
- 使数据立即可用，以便在数据落地时对其进行分析。
关系数据库管理系统 （RDBMS） 的优点是在更熟悉的 SQL 中执行上述任务。
- 存储
辩论可以是周期性的。关于使用专门的向量数据结构是否更好的 NoSQL 争论再次上升，关于多模型数据库是否可以同样有效的问题也是如此。经过近 15 年的 NoSQL 数据库，通常会看到关系数据结构在本地存储 JSON 文档。但是，多模型数据库的初始化身将JSON文档存储为BLOB（二进制大型对象）。
虽然现在说多模型数据库是否同样擅长将向量嵌入存储为原生向量数据库还为时过早，但我们预计这些数据结构会收敛。自 2017 年以来，像 SingleStoreDB 这样的数据库一直支持 Blob 列中的向量嵌入。
向量嵌入的大小可以迅速增长。由于向量搜索在内存中运行，因此将所有向量存储在内存中可能不切实际。基于磁盘的向量搜索性能不佳。因此，数据库必须能够索引向量并将其存储在内存中，而向量本身位于磁盘上。
- 性能（计算和存储）
性能调优的一个重要方面是能够为向量编制索引并将其存储在内存中。
数据库应该能够将向量拆分为较小存储桶中的分片，以便可以并行搜索它们并利用硬件优化，例如 SIMD。SIMD 可以实现快速高效的向量相似性匹配，无需并行化应用或将大量数据从数据库移动到应用中。
例如，在最近的 SingleStore 博客文章中描述的测试中，数据库可以在 5ms 内处理 1600 万个向量嵌入，以进行图像匹配和面部识别。
如果给大型语言模型（LLMs）提供大量的嵌入向量，那么响应的延迟将相应地非常高。使用数据库作为中介的目的是执行初始的向量搜索，并确定要发送给 LLM 的较小嵌入向量。
缓存来自 LLM 的提示和响应可以进一步提高性能。我们从 BI 世界中了解到，组织中提出的大多数问题经常重复。
- 成本
成本可能是大规模采用 LLM 的最大障碍之一。我们正在解决部署数据库以帮助对 LLM 进行 API 调用的问题。与任何数据和分析计划一样，必须计算总拥有成本 （TCO）：
- 数据库的基础结构成本。这包括许可、按使用付费、API、许可证等。
- 使用向量嵌入搜索数据的成本。通常，此成本高于全文搜索的传统成本，因为需要额外的 CPU/GPU 处理来创建嵌入。
- 技能和培训。我们已经看到了“提示工程师”角色的创建。此外，Python 和机器学习技能对于为向量搜索准备数据至关重要。
最终，我们预计 FinOps 可观测性供应商将增加跟踪和审计向量搜索成本的能力。
- 数据访问
语义搜索依赖于自然语言处理（NLP）来提问，这意味着最终用户对 SQL 的依赖减少了。 LLM 很有可能取代商业智能报告和仪表盘。此外，处理 API 的强大基础架构变得至关重要。这些 API 可能是传统的 HTTP REST 或 GraphQL。
但是，在支持传统在线事务和在线分析处理的数据库中，使用 SQL 可以允许将传统的关键字（即词汇）搜索与 LLM 启用的语义搜索功能混合在一起。
- 部署、可靠性和安全性
众所周知，应该共享向量以提高向量搜索的性能。数据库供应商也使用这种方法来提高可靠性，因为分片在 Kubernetes 编排的 Pod 中运行。在这种自我修复方法中，如果 Pod 发生故障，它会自动重新启动。
数据库供应商还应将分片地理分布到不同的云提供商或云提供商内的不同区域。这解决了两个问题——可靠性和数据隐私问题。
一个常见的关注点是数据的保密性。组织需要确保聊天机器人或连接到 LLM 的 API 不会存储提示信息或重新训练他们的模型。正如前面提到的，OpenAI 更新的数据使用和保留政策解决了这个问题。
最后，向量搜索和对 LLM 的 API 调用必须执行基于角色的访问控制（RBAC）来维护隐私，就像在传统的关键字搜索中一样。
- 生态系统整合
支持 AI 工作负载的数据库必须与更大的生态系统集成。其中包括：
- Notebooks 或集成开发环境 （IDE），用于编写将启用本文前面所述的 AI 价值链步骤的代码。
- 来自云提供商（如AWS，Azure和Google Cloud）以及独立供应商的现有 MLOps 能力。此外，对 LLMOps 的支持也开始出现。
- 用于生成嵌入的库，例如 OpenAI 和 HuggingFace 。这是一个快速扩展的空间，拥有许多开源和商业库。
现代应用程序空间正在通过链接各种 LLM 的能力而重新定义。这在 LangChain ， AutoGPT 和 BabyAGI 的崛起中很明显。
- 用户体验
关于哪种技术是用于特定任务的最佳技术的争论通常可以通过采用速度来解决。具有卓越用户体验的技术通常占上风。这种体验跨越各种向量（没有双关语）：
- 开发人员体验：能够编写代码来为 AI 工作负载准备数据。
- 消费者体验：轻松生成正确的提示。
- DevOps 体验：与生态系统集成和部署的能力 （CI/CD）。
数据库提供商必须为与其产品交互的所有角色提供最佳实践。
有一点是明确的：生成式人工智能领域还处于萌芽状态，正在进行中。最后，在人工智能方面，仍应遵守适用于其他数据管理学科的指导原则。希望这有助于揭开利用 AI 工作负载所需的神秘面纱以及如何选择最佳数据库技术。