大家好，欢迎来到在线频道。我是 Shashi，Super Agent DKR 的创始人。今天我们将探讨如何在保持搜索质量的前提下，将智能体检索的内存成本降低五倍。让我们直接进入正题。在开始演讲之前，我们先来看看试图解决的问题。如果你使用过任何智能体或通用智能体，你可能会发现随着上下文的增长，性能会下降。这通常是因为 KV 缓存。如果你不了解 KV 缓存，可以将其理解为对话的历史记录。

如果你使用的是基于云端的模型，你可能没有听说过这个问题，因为它们自己处理了所有的 KV 缓存。但如果你尝试在自己的设备上加载模型，你可能已经亲眼见过这个问题。你需要加载模型，然后加载上下文，随着上下文的增长，KV 缓存也会增长。如果将上下文推得足够远，你的 KV 缓存可能会变得比模型本身还大。

因此，如果你使用的是 Mac 设备，情况会更糟，因为哈希、向量索引等都在争夺有限的共享 RAM 池。基本上，有一点是明确的：你的嵌入向量使用的内存远超所需。默认情况下，它们使用全精度，如 32 位，但搜索可能只需要 3 或 4 位。这意味着你在检索过程中浪费了五倍的内存。

在 Turbo Quant 出现之前，人们使用不同的方法来解决这个问题。其中一种方法是量化。量化允许你将模型量化为 4 位或 8 位，使模型能够适应内存。模型被压缩并放入内存中。你可能在编码智能体中看到的另一件事是上下文压缩。当你到达上下文末尾时，上下文会被压缩并总结，以便用于下一个会话。

有些人使用较小的嵌入向量，有些人使用 CPU 或磁盘卸载。但每种方法都有权衡。你必须牺牲质量、速度，或者可能需要特殊的硬件。这就是 Turbo Quant 登场的时候。让我们看看什么是 Turbo Quant。Turbo Quant 论文由 Google 研究团队在 ICLR 2026 会议上发布。

它基本上是一种压缩算法，将嵌入向量以 3-4 位而不是 32 位存储在 KV 缓存中。就是这样。在幕后，它使用了两种技术。一种是 Polar Quant，另一种是 QJL。Polar Quant 基本上是对向量进行压缩，而 QJL 则修复剩余的任何误差。

你可以看到关于此主题的完整论文。如果你来自机器学习背景，你可以阅读这篇论文。但如果你来自软件背景，你可能会发现这篇论文非常技术化和数学化。Google 还发布了关于 Turbo Quant 的发布帖子，解释了它是如何工作的。他们提到了使用仅 1 位的 QJL 技术和 Polar Quant。

如果你想了解更多，可以阅读这篇博客文章。但简而言之，Turbo Quant 的观点是不将向量存储在 32 位中，而是将其存储为 3 到 4 位。就是这样。这篇论文的承诺基本上是你可以在不损失质量的情况下将向量放入少于 4 位的空间中。这是压缩的有趣之处，也是 Turbo Quant 背后的魔力所在。

一个值得理解的概念是：搜索并不关心向量看起来是什么样，它只关心哪个向量最接近你的查询。无论是全精度还是 Turbo Quant 都没关系。如果你使用传统的压缩方法，除非你看到质量的下降，否则你不会注意到它。

Turbo Quant 基本上使用两个阶段，你可以进一步细分为三个阶段。在第一阶段，Turbo Quant 通过打乱向量来平衡数据。然后，它使用称为标量量化的技术将其舍入到桶中。在最后阶段，称为 QJL，它仅用 1 位修复剩余的误差。这就是魔力发生的地方。

如果你想自己使用 Turbo Quant，你可能需要了解这些阶段。你唯一需要关心的是选择你的预算，即你想使用多少位。好消息是其他一切都由库本身处理。你不需要手动调整任何东西。你需要决定在质量下降之前你能推进多远。

行业理想的甜点通常是 3.5 位。但如果适合你的用例，你可以使用更小的位数。但在实践中，你可以接近 4 位。目前，Turbo Quant 已被大多数你可能已经在使用的推理引擎所采用。例如，如果你使用本地模型，你可能正在使用 llama.cpp、MLX、Ollama 或 LM Studio。

所有这些都最终会在推理引擎中内置 Turbo Quant。所以你不必担心自己做任何事情。Turbo Quant 可用于模型的推理层 KV 缓存，但也可用于你的 RAG 和向量搜索。它可以服务于这两个目的。它可以压缩索引中的嵌入向量。

如果你正在构建智能体，我们在 Super Agentic AI 构建的一种方法是 Turbo Agent。这是一个开源库，允许你使用相同的智能体框架和相同的向量数据库。你只需要替换检索层并使用 Turbo Agent，你就能获得 Turbo Quant 的好处。你可以采取类似的方法，构建自己的工具并在智能体检索中使用 Turbo Quant。

对于 Turbo Agent，它允许你保留现有的智能体框架和现有的向量数据库。它的工作原理基本上是说，例如，如果你有一个 Pinecone AI 智能体，你唯一需要做的就是使用你的检索器，无论你使用的是 Chroma DB 还是任何其他向量数据库，你只需要用你感兴趣的位数替换索引部分。

这就是所有魔力发生的地方。我们有了智能体，我们提出问题。首先，我们使用普通的基线 float 32 位索引运行。然后，我们用更小的尺寸压缩并重新排序，然后再次运行。通过这样做，我们将获得相同的结果，但尺寸要小得多。我们现在可以在行动中看到演示。

如果你想查看其他向量数据库（如 SurrealDB 或 Lance DB）的演示，它们已经在 GitHub 上可用。你可以去尝试一下。但现在，让我们切换到本地演示。我这里有一个演示仓库。我可以运行脚本。首先，让我向你展示脚本。我有一个智能体演示脚本。

这基本上就是加载模型的过程。我们拥有基线检索器和Turbo检索器。然后我们提出问题，使用本地提供的LLaMA模型。我们运行脚本并获取答案。因此，让我们运行脚本，并使用名为“20亿参数”的小模型，这样速度会更快。

现在你可以看到，我们使用的是Quantri嵌入模型，参数量为0.6亿，维度为256。我们正在提出问题。现在你可以看到，基线检索器已加载为Float 32格式，其使用的索引内存为8KB。我们需要等待模型加载完成，然后才能看到答案。你可能需要等待一段时间让模型加载，但之后你就能从32位浮点数中获取由智能体回答的答案。

现在，我们使用的是带有压缩和重排序功能的Turbo Quant。现在你可以看到，索引内存仅为1.6KB，这比Float 32使用的内存小了将近五倍。现在你可以看到，我们从Turbo Quant中获得了相同的答案。因此，两个检索器得出的答案都是正确的。但你可以看到内存差异是五倍。

这里的变化在于，我们没有更改任何智能体，也没有更改文档。我们唯一做的改变是更换了检索器。正是这一改变带来了巨大的差异。让我们切回幻灯片。

现在我们有另一个关于内存的演示。重排序步骤是保持重排序准确性的关键。因此，我们有另一个演示。我已经运行过了，因为它花费了一些时间。基本上，你有Float 32，你有Turbo Quant。你可以看到那里的质量和速度。你可以看到结果，内存减少了五倍，同时检索质量得以保留。

Turbo Quant并不是唯一的选择，市场上已经有一些其他方法可用。Turbo Quant使用三到四位，为KV缓存和向量使用一种方法。工具仍在发展中。但行业中还有其他一些方法可用，例如Milvus中的Rabbit和You，它们使用一到四位。这对于大型静态索引非常强大，但它仅支持向量搜索，不支持KV缓存。

另一种方法是F，使用八位。它已经在VLLM和SGLine中可用。从这次演讲中你可以得出的主要结论是，你需要改变思维方式，仅针对重排序进行压缩。因为搜索只关心最接近的向量，而不关心它的外观。你可以尝试Turbo Quant，并将你当前使用的检索器之一替换为Turbo Quant，看看它会产生什么差异。从小处着手。

在你自己的数据上运行召回率和延迟基准测试。看看你得到的结果。如果你在内层使用Turbo Quant，希望你会在检索中看到一些神奇的结果。

如果你需要更多信息，你可以在GitHub上找到Turbo Agents。你可以分叉它并制作自己的版本。或者你可以尝试这个使用Lance DB和Serial DB的最小演示。如果你有任何进一步的问题，你可以通过X、LinkedIn或GitHub联系我。感谢大家聆听我的演讲。谢谢。