您需要的不仅是向量数据库

除非您过去两年与世隔绝，否则您很可能在关于生成式 AI (GenAI) 的讨论中遇到过“向量数据库”这个术语。

我于 2022 年加入 Redis，那时 ChatGPT 尚未出现，向量对于大多数软件开发者来说还鲜为人知。当时，我的团队倡导向量和向量搜索的用例，但在大型语言模型 (LLM) 兴起之前，推广起来很困难。只需看看该术语在 Google 搜索趋势中的热度随时间推移如何爆炸式增长就知道了。

如今有超过 40 种选项可供选择，包括 Redis。

在 2024 年，向量数据库成为构建检索增强生成 (RAG) 系统的首选。为什么？因为向量支持用户问题和文档块之间的语义搜索。但事情并非如此简单。

回顾我们客户的成功经验、吸取的教训以及快速变化的 AI 格局，仍有一个显而易见但对某些人来说可能是新闻的问题需要解决：您需要的不仅仅是向量数据库。

信息检索并非新鲜事物

早在 LLM 和向量搜索热潮兴起之前，信息检索 (IR) 社区就已经花费了数十年的时间来理解大量的文本和非结构化数据。TF-IDF 和 BM25 等算法至今仍在为世界一流的搜索引擎提供支持。这些方法根据单词在文档中出现的频率以及在整个语料库中的稀有程度来生成分数，从而突出最能描述文档的术语。

尽管焦点已转向向量，但向量数据库产品正争相追赶词汇搜索——仿佛回到了 1990 年代。

为什么？最有效的检索解决方案不会非此即彼。相反，它们通常实现某种形式的混合搜索，结合向量和词汇搜索的信号。向量可能是当今的热门话题，但它们是建立在数十年的创新基础之上的——站在巨人的肩膀上。

向量只是数字列表

在这个领域，我见过非技术领导者听到向量和语义搜索的强大之处时眼前一亮。但向量并非魔法；它们只是数据的数字指纹。

部分问题在于我们倾向于将事物描述得比实际情况更复杂。

谷歌、亚马逊和 Meta 等顶级科技公司几十年来一直在使用嵌入进行推荐和个性化。在我之前的初创公司，我不得不从头开始（花了好几天）训练一个双塔深度学习模型，只为了生成高质量的词嵌入。

今天，我们可以利用 HuggingFace、Cohere 和 OpenAI 等公司的现成 API 按需创建它们。

工具和技术有所改进，但核心概念保持不变。

向量搜索是应用线性代数

从本质上讲，向量搜索通过比较数字列表来查找“最近邻”。点积、余弦相似度或欧氏距离等数学概念已经被很好地理解了数十年。像 HNSW 或微软的 DiskANN 等用于加速搜索的先进向量索引技术如今在向量数据库中广为人知并得到普遍实现。

难的不是向量数学。

真正的挑战始于数学之外

在实践中，将 RAG 系统投入生产中最困难的部分根本与向量数学无关。复杂性源于管理实时更新、动态重新索引、海量数据、波动的查询负载、灾难预防和恢复。这些是决定您的平台能否在规模化下提供一致性能的运维挑战。例如，Redis 长期以来一直提供多租户、高可用性、双活复制和持久性——这些能力是纯向量数据库供应商现在正在努力实现的功能。

正如著名机器学习研究员兼创始人 Chip Huyen 指出，LLM 响应的模糊性、提示版本控制和评估的需求以及对成本和延迟的仔细考量，都表明成功不仅仅在于掌握检索。虽然我不会在这里详细介绍整个 LLMOps 框架，但让我们强调一些关键考虑因素，这些因素强调了为什么您需要的不仅仅是向量数据库。

管理访问：安全和治理

您很可能遇到的第一个障碍是保护您最宝贵的资产：您的专有数据和客户的敏感信息。不幸的是，通过网络将错误的信息片段传递给第三方模型太容易了。这在开发生命周期中引入了新的要求。

与我们合作的金融服务公司在模型风险管理 (MRM) 流程上投入巨资，以减轻潜在的损害。其他公司则引入严格的文档治理，以确保用户只能根据其角色访问文档。

虽然有必要，但这些流程会增加复杂性并减缓交付时间。

管理状态：会话管理

LLM 在推理调用之间不保留记忆。其次，任何分布式应用都需要一个“会话”。因此，如果您正在构建对话式应用或多步骤 LLM 工作流，您将需要一个数据层来实时存储和检索会话上下文和聊天历史记录。一旦扩展到单个用户之外，依赖于进程内应用内存将充满危险！

使用缓存控制成本

几周前在 AWS re:Invent 大会上与我们的一位主要 RAG 客户交流时，他们分享说，他们仅在文本生成方面（输入和输出 token）每季度在 OpenAI 账单上花费超过 8 万美元。他们估计，大约 30-40% 的调用与之前提出的问题类似（这也与关于该主题的学术研究相符）。首席架构师表示，他担心年底与 CTO 和 CFO 就成本优化进行对话。

我不怪他。

第三方 LLM 可能很昂贵。重复调用它们处理冗余查询是浪费的。语义缓存是一种有用的技术，可以最大程度地减少延迟、提高吞吐量并降低成本。通过根据语义相似性而不是精确字符串对结果进行缓存，您可以快速提供答案，而无需重复调用 LLM。

还有更多

随着应用复杂性的增加，您可能会发现其他技术或模式很有帮助

AI 网关：集中管理对 LLM 的访问并跨团队强制执行速率限制。像 Kong 或 LiteLLM 等开源代理服务通常是控制流向不同模型的请求的必要手段。我们在大型银行和金融机构中看到大量应用这种模式。
语义路由：根据查询的含义/意图进行路由查询。产品支持问题发送到一个管道，人力资源问题发送到另一个。将简单查询发送到更便宜的 LLM，将更复杂的基于推理的请求发送到像 GPT o1 这样的重量级模型。

嵌入缓存：缓存嵌入，避免重复嵌入完全相同的块数据。
代理检查点：如果您正在使用类似 CrewAI 或 LangGraph 等工具的代理架构，请保存中间状态，以便它们可以恢复推理而无需重头开始。
消息代理和流处理：使用消息流（例如 Redis Streams）来协调多步骤 LLM 管道并高效处理实时更新。

下面是一个基于 Redis 的示例架构，其中包含端到端流程中的许多这些组件。

另外，请查看Dell AI Factory 提供的这个出色的参考架构，它展示了类似的内容。

TLDR（太长不看）：向量搜索只是难题的一部分。

随着 GenAI 市场的成熟，用户将需要涵盖全方位功能的平台——全文搜索、向量、缓存、消息流、会话管理等等。预计会出现整合；在构建实际应用时，没有人希望同时应付六七种单一用途的工具。

我们还在走向一个代理驱动工作流的世界，每次请求包含多次 LLM 调用。您将需要健壮的基础设施、久经考验的功能以及一个可以处理这一切的数据平台。Redis 多年来一直在企业规模下提供卓越的运维能力，而新来者正争相追赶。

未来属于那些超越炒作、拥抱整体解决方案的人。您需要的不仅仅是向量数据库——今天就开始全面思考。毕竟，一旦您搞定了数学部分，真正的挑战才刚刚开始。

要了解更多信息，请查看面向 AI 的 Redis 或阅读我们的文档。