目录

1. Manticore中的向量搜索：细节解析
2. 什么是嵌入（以及为什么你应该关心）？
3. 向量搜索是如何工作的？
4. 入门：设置向量搜索
5. 高级搜索功能
6. 实际应用
7. 提升向量搜索速度：性能技巧
8. 保护你的向量数据：备份选项
9. 保持搜索系统可用：复制
10. 观看向量搜索实战：实时演示
11. 在生产环境中运行向量搜索
12. 结论：向量搜索的未来

1. Manticore中的向量搜索：细节解析

如果你一直在关注我们的博客，你已经知道Manticore Search提供了强大的向量搜索功能。在本文中，我们将超越基础知识，展示其背后的工作原理——以及如何充分利用它。

在进入技术细节之前，一个快速公告：2025年6月6日，Manticore团队将赞助 2025向量搜索大会

我们将发表两场聚焦于实际向量搜索的演讲：

• 速度与精度的平衡：向量量化如何加速搜索 —— Sergey Nikolaev
• RAG时间：通过检索增强生成获得更智能的答案 —— Dmitrii Kuzmenkov

如果你正在使用语义搜索、推荐系统或检索增强生成（RAG），这将是一场你不想错过的活动。

现在，回到主题。

Manticore的向量搜索是基于我们的 Columnar Library 构建的，它允许你：

• 即使词语不同，也能找到语义相似的内容
• 构建感觉个性化的推荐系统
• 在无需人工标记的情况下将相似项目分组
• 提供比基础关键词匹配更相关的结果

在底层，Manticore使用一种名为HNSW（分层可导航小世界）的高效算法进行向量搜索。它被设计用于快速找到大型数据集中的最相关结果——就像在大城市中找到最近的邻居，但不需要地图。

让我们分解嵌入如何驱动所有这些功能，以及HNSW如何将这些嵌入转化为快速且准确的搜索结果。

2. 什么是嵌入（以及为什么你应该关心）？

要理解向量搜索，你首先需要了解嵌入。它们是所有概念的核心。

将嵌入想象成一种将事物——如单词、图像或声音——转换为表示其含义的数字列表的方法。这是一种帮助计算机以更接近我们理解世界的方式“理解”世界的方法。

嵌入是如何工作的？

想象一张巨大的地图，其中每个点代表一个事物：一个单词、一个句子、一张图片等。两个点越接近，它们代表的事物就越相似。这就是嵌入所做的——它们将数据转换为向量（仅仅是数字序列），这些向量：

• 在这个多维空间中将相似的事物放在一起
• 捕获数据背后的含义
  让我们对概念进行数学运算（还记得谷歌研究人员从Word2Vec中著名的例子： king – man + woman = queen ？）

你可以将什么转换为向量？

几乎任何东西。一些常见示例包括：

• 文本：单个单词、完整句子，甚至整本书。"beach"的向量会比"mountain"更接近"shore"。
• 图像：旅行照片、产品图片或表情包。狗的图片会比汽车的图片更接近彼此。
• 音频：语音、音乐或音效。重金属音乐会聚在一起，远离安静的钢琴音乐。

这些嵌入是起点。一旦你有了它们，像HNSW这样的算法可以帮助你快速搜索它们。

我们如何衡量相似性？

一旦我们有了这些向量，我们需要一种衡量它们相似性的方式。Manticore Search支持三种相似性度量：

• 欧几里得距离（L2）
• 余弦相似度
• 内积（点积）

然而，需要注意的是，相似性度量的选择并非任意。最佳度量通常取决于生成向量所使用的嵌入模型。许多嵌入模型是在特定相似性度量下训练的。例如，一些模型针对余弦相似度进行了优化，而其他模型可能设计用于内积或欧几里得距离。使用与模型训练时不同的相似性度量可能导致次优结果。

在为Manticore Search设置向量搜索表时，你会在创建表的过程中指定相似性度量。这一选择应与你的嵌入模型的特性保持一致，以确保搜索结果的准确性和效率。

以下是每种度量的简要概述：

• 欧几里得距离（L2）：衡量空间中两个向量之间的直线距离。它对向量的大小敏感，适用于绝对差异有意义的情况。

• 余弦相似度：衡量两个向量之间角度的余弦值，关注它们的方向而非大小。它常用于文本分析，其中向量的方向（代表概念）比长度更重要。

• 内积（点积）：计算两个数列对应项乘积的总和。当向量的大小和方向都重要时，这种方法非常有效。

这些向量是如何创建的？

要使用向量搜索，首先需要将数据转换为向量——这就是嵌入模型的作用。这些模型将原始数据如文本、图像或音频转换为能够捕捉含义、上下文或特征的数值表示。

以下是一些广泛使用的生成嵌入的模型：

• Word2Vec：最早的词嵌入模型之一。它展示了词语之间的关系可以通过数学方式捕捉——例如，“国王”之于“王后”就像“男人”之于“女人”。
• GloVe：由斯坦福大学开发，该模型通过分析全局词语共现统计来创建词嵌入。它效率高，仍被广泛使用。
• FastText：来自Facebook的模型，通过理解子词信息改进了Word2Vec。它可以通过将单词拆分为片段来生成未见过的单词的嵌入。
• BERT：Google基于Transformer的模型，能够理解上下文中的词语。例如，它能区分“river bank”（河岸）和“bank account”（银行账户）中的“bank”。它可以生成句子、段落或整个文档的嵌入。
• MPNet / MiniLM / all-MiniLM-L6-v2：这些是SentenceTransformers家族优化的句子嵌入模型，适用于语义搜索、FAQ匹配和重复检测等任务。
• OpenAI嵌入（例如，text-embedding-3-small）：这些是高度通用的嵌入，用于搜索、聚类和分类等应用。
• CLIP：OpenAI开发的模型，能够同时理解图像和文本。例如，给它一张小狗的照片，它可以匹配到文本“可爱的小狗”。
• ResNet：一个深度卷积神经网络，擅长将图像转换为嵌入。常用于视觉相似性和图像分类。
• VGG / EfficientNet / Vision Transformers (ViT)：其他强大的图像模型，广泛用于将图片转换为向量嵌入。
• Whisper：OpenAI用于将音频转录为文本的模型，之后可以嵌入用于语音搜索或音频分类等任务。

Manticore Search支持所有这些模型及其他更多模型。它不会将你锁定在特定模型上——你可以使用最适合你项目的模型，无论你处理的是文本、图像还是音频。只要你能将数据转换为向量，Manticore就能进行搜索。

3. 向量搜索是如何工作的？

现在我们已经了解了嵌入是什么以及它们如何表示相似性，让我们看看Manticore实际是如何执行向量搜索的。幕后真正的强大之处来自于一个聪明的算法，称为HNSW——全称是Hierarchical Navigable Small World。

听起来像是科幻小说里的东西——说实话，它确实有点像。但HNSW并不是引导飞船穿越虫洞，而是帮助我们快速导航大量向量集合。

HNSW：名字糟糕但功能强大的算法

在巨大的向量索引中搜索有点像在 haystack 中寻找针——只不过这个 haystack 有数百万根麦秆，其中一些看起来和针非常相似。如果你必须逐一检查，那会花费很长时间。

这就是HNSW发挥作用的地方。它构建了一个巧妙的结构，让你可以跳过大部分 haystack，快速锁定最佳候选。

以下是它的工作原理：

1. 它创建了多层向量——有点像多层建筑或分层蛋糕。
2. 底层包含每个向量——你的完整数据集。
3. 每个更高层包含更少的向量和更长范围的链接。
4. 当你搜索时，它从顶层开始，帮助你快速跨过数据。
5. 在每一层，它逐渐接近正确的区域，随着向下搜索而细化搜索。
6. 到达底层时，它已经处于正确的邻域。

这种分层方法意味着你无需扫描整个数据集。相反，你可以快速聚焦——这让Manticore中的向量搜索非常高效。

但准确性如何？

有一个小权衡。因为HNSW在搜索过程中跳过了大量数据，它可能找不到绝对最佳匹配——只是非常接近的一个。在大多数现实场景中，这完全没问题。无论是进行语义搜索、产品推荐还是聚类相似文档，“非常接近”已经足够好。

但如果你的应用场景需要100%的精度——比如匹配DNA序列或运行科学分析——你可能需要使用暴力方法。它会更慢，但完全准确。

对于其他所有情况，HNSW给你两全其美的结果：极快的速度和高精度。

HNSW算法结构

根据你的需求进行调整

Manticore中的向量搜索不仅速度快，而且灵活。你可以调整几个关键设置，以更好地适应你的具体用例，具体取决于你最关心的是速度、准确性、内存使用还是索引构建时间。

以下是你可以调整的主要参数：

• hnsw_m（默认：16）：这控制每个向量与其他向量的连接数量——有点像社交网络中每个人的朋友数量。更多的连接意味着更好的搜索准确性，但也意味着更多的内存使用和略微更慢的查询。

• hnsw_ef_construction (默认值: 200): 此设置会影响索引构建的彻底程度。较高的值会产生更高质量的索引（从而获得更好的搜索结果），但也会使索引过程变慢且内存消耗更大。

这两个参数帮助你在以下方面找到平衡点：

• 🔍 搜索准确性 —— 结果与真实最近邻的接近程度
• ⚡ 搜索速度 —— 结果返回的速度
• 🧠 内存使用 —— 索引消耗的RAM量
• 🏗️ 索引构建时间 —— 构建索引所需的时间

默认设置对大多数使用场景都适用，但如果你想进行调整，这里有一些提示：

• 想要超准确的结果？同时增加 hnsw_m 和 hnsw_ef_construction
• 内存紧张？降低 hnsw_m 以减少连接数
• 需要更快的索引构建？降低 hnsw_ef_construction

随意尝试 —— 关键是为你的工作负载找到最佳平衡点。

4. 入门：设置向量搜索

理解理论很棒 —— 现在让我们动手操作。在 Manticore 中设置向量搜索很简单且灵活，只需几步即可开始使用。

你需要什么

要启用向量搜索，你需要定义一个包含至少一个 float_vector 属性的表。这就是你存储向量（实际嵌入）的地方。

需要定义的关键设置

创建表时，有三个必须设置的参数：

1. knn_type: 设置为 hnsw。（目前这是唯一支持的选项，所以这里无需做决定。）
2. knn_dims: 这定义了你的向量的维度数。该值取决于你使用的嵌入模型：
   • BERT 通常使用 768
   • CLIP 经常使用 512
   • 一些句子转换器使用 384 或 1024
   • 只要确保它与你将要插入的向量大小匹配即可
3. hnsw_similarity: 选择与你的嵌入模型训练方式匹配的相似度度量。选项包括：
   • L2（欧几里得距离）：用于几何数据、图像特征以及任何物理距离相关的场景
   • COSINE：最适合文本嵌入、语义搜索以及当你关心方向而非幅度时
   • IP（内积）：适合归一化向量或像推荐系统这样的用例，其中大小和方向都有意义

🔍 专业提示：大多数现代文本嵌入模型都是以余弦相似度为目标进行训练的。如果你不确定，可以查看模型文档 —— 或者直接从 COSINE 开始并进行实验。

一旦你用这些设置定义了表，你就可以插入向量并开始运行快速的、基于相似度的搜索。

向量搜索工作流程

看一个真实示例

现在动手操作。这是在 Manticore Search 中创建一个存储图像向量的表的方法：

create table cool_images (
    id int,
    title text,
    image_vector float_vector knn_type='hnsw' knn_dims='4' hnsw_similarity='l2'
);

现在添加一些数据：

insert into cool_images values 
    (1, 'yellow bag', (0.653448,0.192478,0.017971,0.339821)),
    (2, 'white bag', (-0.148894,0.748278,0.091892,-0.095406));

（当然，你的真实向量可能有数百个维度 —— 我们在这里保持较小以确保清晰。）

向量操作的事务支持

Manticore 中的向量操作是完全事务性的，这意味着你可以连续执行多个操作，并确保它们要么全部成功，要么全部失败。当你需要同时更新向量和非向量字段并保持一切同步时，这非常有用。

事务基础

• 事务支持实时表中的向量属性
• 每个事务是原子的 - 要么所有操作都成功，要么都失败
• 事务与二进制日志集成以确保持久性和一致性
• 默认情况下，每个命令都是自己的小事务（autocommit = 1）

事务中可以执行的操作

你可以在事务中包含以下操作：

• INSERT：添加新向量
• REPLACE：更新现有向量
• DELETE：删除向量

向量字段不支持 UPDATE 命令。你可以了解更多关于 REPLACE 和 UPDATE 的区别 此处 。

如何控制事务

你可以通过以下两种方式控制事务：

1. 自动模式（默认）:

SET AUTOCOMMIT = 1

在此模式下，每个操作都会自动提交。

2. 手动模式:

SET AUTOCOMMIT = 0

这允许你将多个操作组合成一个事务：

BEGIN;
INSERT INTO cool_images VALUES (3, 'red bag', (0.1, 0.2, 0.3, 0.4));
INSERT INTO cool_images VALUES (4, 'blue bag', (0.5, 0.6, 0.7, 0.8));
COMMIT;

批量操作

对于批量操作，你可以使用 /bulk 端点，它支持多个向量操作的事务：

POST /bulk
{
    "insert": {"table": "cool_images", "id": 5, "doc": {"title": "green bag", "image_vector": [0.1, 0.2, 0.3, 0.4]}},
    "insert": {"table": "cool_images", "id": 6, "doc": {"title": "purple bag", "image_vector": [0.5, 0.6, 0.7, 0.8]}}
}

需要注意的事项

• 事务仅限于单个实时表
• 事务中的向量操作是原子且一致的
• 变更在显式提交后才可见
• 二进制日志确保了向量操作的持久性
• 当你需要在向量数据和其他属性之间保持一致性时，事务特别有用

搜索相似内容

现在是酷的部分 —— 搜索相似的图像：

使用 SQL：

select id, title, knn_dist() 
from cool_images 
where knn (image_vector, 5, (0.286569,-0.031816,0.066684,0.032926), 2000);

这会给我们：

+------+------------+------------+
| id   | title      | knn_dist() |
+------+------------+------------+
|    1 | yellow bag | 0.28146550 |
|    2 | white bag  | 0.81527930 |
+------+------------+------------+

黄色的袋子更接近我们的查询向量（更小的距离值），因此它更类似于我们正在寻找的内容。

使用 HTTP API：

Manticore 提供了一个用于向量搜索操作的 RESTful HTTP API。向量搜索的主要端点是：

POST /search

请求体应为 JSON 格式，结构如下：

{
    "table": "<table_name>",
    "knn": {
        "field": "<vector_field_name>",
        "query_vector": [<vector_values>],
        "k": <number_of_results>,
        "ef": <search_accuracy>
    }
}

关键参数：

• table: 要搜索的表的名称
• knn.field: 要搜索的向量字段的名称
• knn.query_vector: 作为浮点值数组的查询向量
• knn.k: 要返回的最近邻数量
• knn.ef:（可选）搜索期间使用的动态列表大小。较高的值会提供更准确但更慢的结果

示例请求：

POST /search
{
    "table": "products",
    "knn": {
        "field": "image_vector",
        "query_vector": [0.1, 0.2, 0.3, 0.4],
        "k": 5,
        "ef": 2000
    }
}

响应将为 JSON 格式：

{
    "took": 6,
    "timed_out": false,
    "hits": {
        "total": 2,
        "total_relation": "eq",
        "hits": [
            {
                "_id": 1,
                "_score": 1,
                "_knn_dist": 0.28146550,
                "_source": {
                    "title": "yellow bag",
                    "image_vector": [0.653448, 0.192478, 0.017971, 0.339821]
                }
            },
            {
                "_id": 2,
                "_score": 1,
                "_knn_dist": 0.81527930,
                "_source": {
                    "title": "white bag",
                    "image_vector": [-0.148894, 0.748278, 0.091892, -0.095406]
                }
            }
        ]
    }
}

响应包括：

• took：搜索所用的时间（以毫秒为单位）
• timed_out：搜索是否超时
• hits.total：找到的匹配项总数
• hits.hits：匹配文档数组，每个包含：
  • _id：文档ID
  • _score：搜索得分（KNN搜索始终为1）
  • _knn_dist：到查询向量的距离
  • _source：原始文档数据

您还可以将KNN搜索与附加筛选器结合使用：

POST /search
{
    "table": "products",
    "knn": {
        "field": "image_vector",
        "query_vector": [0.1, 0.2, 0.3, 0.4],
        "k": 5,
        "filter": {
            "bool": {
                "must": [
                    { "match": {"_all": "white"} },
                    { "range": { "id": { "lt": 10 } } }
                ]
            }
        }
    }
}

5. 高级搜索功能

在掌握了设置和配置的基础知识后，让我们探索向量搜索为您的应用程序带来的强大功能。这些功能远远超越了传统的关键词搜索。

两种搜索方式

您可以通过两种主要方式搜索：

1. 直接向量搜索：给我与这个向量相似的东西。当您有想要的东西的向量表示（如图像嵌入或文本嵌入）时非常有用。

   -- Example: Find items similar to a specific vector
   SELECT id, knn_dist() 
   FROM products 
   WHERE knn(image_vector, 5, (0.286569,-0.031816,0.066684,0.032926));
   

2. 相似文档搜索：给我与索引中这个文档相似的东西。非常适合“类似这个”的功能，用户可以点击他们喜欢的东西并找到相似的项目。

   -- Example: Find items similar to document with ID 1
   SELECT id, knn_dist() 
   FROM products 
   WHERE knn(image_vector, 5, 1);
   

两种方法都会根据与查询的相似性（距离）对结果进行排序，最相似的项目会首先出现。

调整您的搜索

两个重要设置控制搜索的行为：

• k参数：您想要返回的结果数量。太少可能会错过好匹配，太多可能会得到不相关的内容。
• ef参数：算法寻找最佳匹配的强度。较高的值会给出更准确的结果，但需要更长时间。

结果按接近程度排序

所有搜索结果都会自动按与查询向量的接近程度排序。knn_dist()函数会显示每个结果的实际距离值，因此您可以看到它们到底有多相似（或不同）。

例如，如果我们搜索与查询向量相似的图像：

select id, title, knn_dist() 
from images 
where knn (image_vector, 3, (0.1, 0.2, 0.3, 0.4));

结果将自动按距离排序，最接近的匹配项排在最前面：

+------+----------------+------------+
| id   | title          | knn_dist() |
+------+----------------+------------+
|    1 | sunset beach   | 0.12345678 |
|    3 | ocean view     | 0.23456789 |
|    2 | mountain lake  | 0.34567890 |
+------+----------------+------------+

请注意，随着列表向下，knn_dist()值会增加——这表明每个结果与我们的查询向量的相似性逐渐降低。

与常规搜索混合使用

当您将向量搜索与传统筛选器结合使用时，真正的魔法就发生了。例如，您可以找到与向量相似的图像，同时匹配文本：

select id, title, knn_dist() 
from cool_images 
where knn (image_vector, 5, (0.286569,-0.031816,0.066684,0.032926)) 
and match('white');

这会找到与我们的向量相似的图像，但仅当它们包含“白色”时：

+------+-----------+------------+
| id   | title     | knn_dist() |
+------+-----------+------------+
|    2 | white bag | 0.81527930 |
+------+-----------+------------+

尽管黄色袋子在向量上技术上更相似，但它不匹配我们的文本筛选器，因此只有白色袋子出现。

6. 实际应用

现在我们已经涵盖了核心功能，让我们看看向量搜索在哪些实际应用中可以改变您的用户体验。这些示例将帮助您了解如何在自己的项目中应用这些概念。

理解您意图的智能搜索

您是否曾经搜索过某样东西，然后想“那不是我的意思！”？智能搜索理解您查询背后的含义，而不仅仅是确切的词语。

使用向量搜索，您可以：

• 找到与您寻找的内容匹配的结果，即使它们使用了不同的词语
• 跨语言搜索（含义被翻译，而不仅仅是词语）
• 真正理解用户在寻找什么

实际示例：一个知识库，客户即使使用与文档不同的术语，也能找到正确的帮助文章。

有道理的推荐系统

我们都经历过糟糕的推荐：“您买了冰箱，要再买一个冰箱吗？”向量搜索有助于构建有道理的推荐：

• 找到客户喜欢的产品的相似产品
• 将用户偏好与商品匹配
• 基于底层属性跨类别推荐
• 根据浏览历史个性化搜索结果

实际示例：一个电子商务网站，您查看了蓝色皮革包后，可以推荐蓝色皮革夹克，因为它理解了风格的联系。

像您一样“看”的图像搜索

传统图像搜索依赖于文本标签和元数据。向量搜索让您：

• 找到外观相似的图像
• 上传图像并找到匹配的图像（反向图像搜索）
• 在无需手动标记的情况下将相似图像分组
• 检测重复或近似重复的图像

实际示例：一个图库网站，设计师可以通过上传参考图像或概念草图找到视觉上相似的图像。

超越标签的视频和声音搜索

将相同原理应用于视频和音频：

• 根据内容找到相似的视频片段
• 通过“听起来像这样”而不是仅仅通过流派标签搜索音乐
• 找到具有相似视觉元素的视频片段
• 检测重复或相似的音频轨道

实际示例：一个视频编辑平台，可以立即找到所有项目中具有相似视觉构图的片段。

跨不同语言的搜索

当涉及到多语言应用时，向量搜索真正闪耀。使用正确的嵌入，您可以跨不同语言进行搜索——无需手动翻译查询或文档。

跨语言搜索的工作原理

1. 语言无关的嵌入
   现代多语言模型如 mBERT、XLM-R 和 LaBSE 都经过训练，使语义相似的文本——即使在不同语言中——在同一个向量空间中彼此靠近。
   这意味着英语中的 "apple" 和西班牙语中的 "manzana" 会彼此接近。因此，当你用一种语言搜索时，可以找到用另一种语言写的结果。
2. 简单的表格设置

   create table multilingual_docs (
       id bigint,
       content text,
       language string,
       content_vector float_vector knn_type='hnsw' knn_dims='768' hnsw_similarity='cosine'
   );
   

   • 将文档存储在其原始语言中
   • 使用多语言模型生成嵌入
   • 搜索功能直接可用——无论查询或文档使用何种语言
3. 跨语言搜索：

   select id, content, language, knn_dist() 
   from multilingual_docs 
   where knn (content_vector, 5, (0.1, 0.2, ...));
   

   • 在任何支持的语言中输入查询
   • 结果基于语义而非语言返回
   • 无需翻译或语言检测

实际应用场景

多语言向量搜索解锁了广泛的应用场景，例如：

• 全球电子商务：跨语言搜索和推荐产品，并支持国际客户查询
• 内容管理：查找相似文档，检测重复项，并构建多语言知识库
• 客户服务：跨语言匹配问题与答案，并智能路由支持工单
• 社交媒体与社区：跨语言边界发现内容、趋势和用户

使用合适的多语言嵌入，你可以构建无缝的搜索体验——无论用户使用何种语言。

实施建议

• 选择合适的模型
  根据语言需求和任务选择多语言嵌入模型，如 LaBSE、XLM-R 或 mBERT。确保所使用的模型支持查询和文档中预期的语言。
• 仔细预处理
  在生成嵌入之前，跨语言一致地规范化和清理输入文本。即使微小的预处理差异（如标点或大小写）也会影响向量质量。
• 存储语言信息
  在数据中保留 language 字段。虽然向量搜索不需要它，但它有助于过滤、分析或提升用户体验。
• 设计清晰性
  在搜索结果中显示语言信息，并允许用户轻松过滤或切换语言——特别是如果您的应用混合了多种语言。

有了这些措施，您将准备好构建跨语言自然运行的搜索功能——无需翻译层。

7. 提高向量搜索速度：性能建议

构建酷炫的功能很棒，但它们在生产环境中需要良好性能。让我们深入探讨性能考虑和优化策略，以确保您的向量搜索实现顺畅运行。

理解 RAM 与磁盘存储

在 Manticore 中，向量搜索的工作方式取决于向量是存储在 RAM 块还是磁盘块中：

1. 磁盘块：
   • 每个磁盘块维护其独立的 HNSW 索引
   • 对于跨越多个磁盘块的 KNN 查询，每个块的索引会单独搜索
   • 这可能会影响搜索准确性，因为每个块的 HNSW 图仅限于该块内的向量
   • 当搜索大量磁盘块时，查询性能可能较慢
   • 对于具有向量属性的表，Manticore 会自动设置较低的 optimize_cutoff 值（物理 CPU 核心数除以 2），以提高向量搜索性能
2. RAM 块：
   • 使用更直接的向量搜索方法
   • 可能为最近添加的数据提供更快的结果
   • 随着 RAM 块增长，向量搜索性能可能会逐渐下降
   • 每个 RAM 块最终会成为磁盘块，当其达到由 rt_mem_limit（默认 128M）定义的大小限制时，或当您显式使用 FLUSH RAMCHUNK 转换时

为了获得最佳向量搜索性能，请考虑：

• 使用批量插入以减少 RAM 块片段化
• 利用 Manticore 的 auto-optimize 功能，该功能会自动合并磁盘块以保持最佳性能
• 根据特定工作负载和 CPU 资源调整 optimize_cutoff
• 使用 diskchunk_flush_write_timeout 和 diskchunk_flush_search_timeout 设置来控制自动刷新行为

跨磁盘块的向量搜索性能取决于块的数量和分布方式。较少的磁盘块通常会比许多小块提供更好的 KNN 搜索性能。

理解 ef 参数

ef 参数允许您在速度和准确性之间取得平衡：

1. 它的作用：
   • 较高值会提供更准确的结果，但耗时更长
   • 较低值更快，但可能会错过一些良好匹配
2. 找到最佳平衡点：
   • 从默认值（200）开始
   • 如果准确性至关重要，请增加
   • 如果速度至关重要，请减少
   • 用实际数据进行测试！

8. 保护您的向量数据：备份选项

随着您的向量搜索实现增长，确保数据安全变得至关重要。让我们探讨专为 Manticore 中的向量数据设计的备份策略。

物理备份

物理备份特别适合向量数据，因为：

• 速度：它们直接复制原始向量数据文件，这对于大型向量数据集至关重要
• 一致性：它们确保所有向量数据和 HNSW 索引一起备份
• 较低系统负载：它们不需要额外处理向量数据

您可以使用以下两种方式之一：

1. manticore-backup 命令行工具：

manticore-backup --backup-dir=/path/to/backup --tables=your_vector_table

2. SQL BACKUP 命令：

BACKUP TABLE your_vector_table TO /path/to/backup

逻辑备份

当您需要以下情况时，逻辑备份对向量数据可能很有用：

• 可移植性：在不同系统之间移动向量数据
• 选择性恢复：恢复特定的向量属性或维度
• 版本迁移：在不同 Manticore 版本之间切换。较新版本通常支持向后兼容，因此升级时可能不需要使用数据转储。但是，如果您要降级到旧版本，使用数据转储可能会很有用。

您可以使用 mysqldump 对向量数据进行逻辑备份：

mysqldump -h0 -P9306 -e "SELECT * FROM your_vector_table" > vector_backup.sql

向量数据备份的最佳实践

与任何其他类型的备份一样，在备份向量数据时也有一些良好的实践需要遵循。

1. 定期备份：
   • 设置定期备份，尤其是在对向量数据进行重大更新后
   • 在决定备份频率时，请考虑您的向量数据大小
2. 备份位置：
   • 将备份保存在有足够的空间存储大型向量数据的位置
   • 如果向量数据非常大，请使用压缩
3. 测试：
   • 定期测试备份以确保可以恢复
   • 恢复后，请检查向量搜索是否仍能正常工作
4. 版本控制：
   • 记录您正在使用的 Manticore 版本
   • 如果需要恢复，请确保备份与该版本兼容
5. 监控：
   • 注意备份的大小和所需时间
   • 在备份失败时设置警报

9. 保持搜索系统可用：复制

除了备份之外，高可用性对于生产系统至关重要。让我们探讨 Manticore 的复制功能如何与向量搜索配合使用，以确保您的系统保持可用和一致。

多主复制

Manticore 支持使用 Galera 库 进行复制，并提供以下关键功能：

• 真正的多主：任何时候都可以在任何节点上执行读写操作
• 几乎同步：节点崩溃后没有从属延迟和数据丢失
• 热备用：故障切换场景下零停机时间
• 紧密耦合：所有节点保持相同状态，没有数据分歧
• 自动节点配置：新节点不需要手动备份/恢复
• 基于认证的复制：确保集群中的数据一致性

为向量搜索设置复制

要为向量搜索启用复制：

1. 配置要求：
   • data_dir 选项在 searchd 配置中默认设置
   • 可选的 listen 指令带有可访问的 IP 地址 - 即使没有它复制也可以工作
   • 可选地为每个节点设置唯一的 server_id 值
2. 创建复制集群：

   CREATE CLUSTER vector_cluster
   

3. 将向量表添加到集群中：

   ALTER CLUSTER vector_cluster ADD vector_table
   

4. 将节点加入集群：

   JOIN CLUSTER vector_cluster AT 'host:port'
   

在复制环境中处理向量数据时：

1. 写操作：
   • 所有向量修改（INSERT、REPLACE、DELETE、TRUNCATE）必须使用 cluster_name:table_name 语法
   • 更改会自动传播到所有副本
   • 向量操作在集群中保持一致性
2. 事务支持：
   • 向量操作在集群中是原子的
   • 更改在显式提交之前不可见
   • 二进制日志确保向量操作的持久性

限制和注意事项

• 复制支持具有向量属性的实时表
• Windows 本地二进制文件不支持复制（请改用 WSL）
• macOS 的复制支持有限（仅推荐用于开发）
• 每个表只能属于一个集群

10. 亲眼见证向量搜索：实时演示

理论和配置都很重要，但亲眼所见才能相信。让我们探索一些实际演示，展示 Manticore 向量搜索功能的强大之处。

GitHub 问题搜索

我们的 GitHub 问题搜索演示 让您能够通过理解词语的含义来搜索 GitHub 问题。与 GitHub 本机搜索仅匹配关键词不同，我们的演示理解您正在寻找的内容。

这个演示基于 Manticore Search 的向量功能，并且完全开源。您可以在 GitHub 上查看源代码 ，了解我们是如何实现它的。

尝试搜索概念而不是仅仅关键词 - 即使没有完全匹配的词语，搜索也能理解您要找的内容！

GitHub 问题演示的工作原理

GitHub 问题搜索演示使用强大的嵌入模型将 GitHub 问题和您的搜索查询都转换为语义向量表示。这使得系统能够找到与您的查询在概念上相似的问题，即使它们使用了不同的术语。

关键功能：

• 智能搜索数千个 GitHub 问题
• 实时按仓库、标签等进行过滤
• 带语法高亮的用户友好界面
• 由 Manticore 的 HNSW 算法提供支持的快速响应时间

与传统的基于关键词的搜索相比，这种方法显著提高了搜索质量，帮助开发人员更高效地找到解决问题的方法。

图像搜索演示

我们的 图像搜索演示 展示了向量搜索如何实现视觉相似性搜索。上传任何图像，系统将根据图像中实际内容查找视觉上相似的图像，而不仅仅是标签或元数据。

这个演示使用机器学习模型将图像转换为向量，然后使用 Manticore 的 KNN 搜索查找相似图像。源代码可在我们的 manticore-image-search 仓库 中找到。

图像搜索演示的工作原理

图像搜索演示利用预训练的视觉模型从图像中提取有意义的特征，并将其表示为高维向量。当您上传图像或从画廊中选择一个图像时：

1. 图像由视觉模型处理以生成特征向量
2. Manticore 的向量搜索会找到与此向量最接近的邻居
3. 返回最相似的图像，并按相似性评分进行排序
4. 所有这些操作都在毫秒内完成，提供流畅的用户体验

该演示可以处理各种类型的图像，并可根据图像中的内容、风格、颜色模式甚至抽象概念找到相似之处。

创建您自己的演示

这两个演示都是构建您自己的向量搜索应用程序的绝佳起点。无论您对以下哪项感兴趣：

• 智能文档搜索
• 图像或视频检索系统
• 推荐引擎
• 内容分类

您都可以利用相同的架构并将其调整为您的特定用例。两个演示的源代码提供了如何实现以下内容的实用示例：

1. 为您的数据生成嵌入
2. 为向量搜索结构化您的 Manticore 表
3. 实现高效的搜索 API
4. 构建用户友好的界面

这些演示展示了向量搜索如何应用于现实世界的问题并取得令人印象深刻的结果。它们也是完全开源的，因此您可以从它们学习，甚至部署您自己的版本！

通过调整这些设置，您可以为您的特定需求使向量搜索变得非常快速。请记住，正确的配置取决于您的数据、您的硬件以及您试图实现的目标。不要害怕进行实验！

11. 在生产环境中运行向量搜索

在探索了所有这些功能和能力之后，现在是时候讨论在生产环境中部署向量搜索需要什么了。让我们涵盖确保您的实现可靠、可扩展并能高效运行的关键因素。

您需要的：基础设施要求

1. 硬件考虑：
   • CPU：向量操作是 CPU 密集型的
     • 推荐使用现代多核处理器
     • 考虑向量操作的 CPU 缓存大小
     • 在高峰期监控 CPU 利用率
   • 内存：
     • HNSW 索引需要大量 RAM
     • 计划为向量数据大小的 2-3 倍
     • 考虑随时间推移的内存碎片化
   • 存储：
     • 推荐使用快速 SSD 用于磁盘块
     • 考虑 RAID 配置以提高可靠性
     • 计划备份存储需求
2. 网络配置：
   • 复制需要高带宽
   • 分布式设置需要低延迟
   • 为集群通信设置适当的防火墙规则
   • 高可用性负载均衡器配置

12. 结论：向量搜索的未来

向量搜索代表了我们在现代应用程序中处理搜索和相似性匹配方式的根本转变。在整个深入探讨中，我们探讨了 Manticore Search 如何实现这种强大的技术，从嵌入的基础概念到生产就绪的部署策略。

我们探索的关键要点：

1. 强大功能：向量搜索使我们能够理解词语背后的含义，超越传统的关键词匹配，根据含义和上下文找到真正相关的结果。
2. 灵活实现：Manticore 的向量搜索可以应用于各种用例，从文本搜索到图像匹配、推荐和多语言应用程序。
3. 生产就绪：凭借复制、备份选项和性能优化等功能，Manticore 的向量搜索已准备好用于企业部署。
4. 易于入门：尽管具备复杂的功能，Manticore 中的向量搜索是可访问的，可以通过最小的配置实现。

展望未来，向量搜索将继续发展并成为现代应用程序中更加不可或缺的一部分。基于含义而非仅关键词来理解和匹配内容的能力正在改变用户与数据的交互方式。无论您是在构建搜索引擎、推荐系统还是内容发现平台，向量搜索都为创建更智能和用户友好的应用程序提供了基础。

要开始在您自己的项目中使用向量搜索，请查看我们的 GitHub 仓库 并加入我们的 社区 。我们很期待看到您使用 Manticore 的向量搜索功能构建的内容！

记住：了解向量搜索力量的最佳方式是亲自尝试。从我们的 演示 开始，并尝试您自己的用例。可能性是无限的，我们在这里帮助您探索它们。