Как работает векторная база данных?

Оригинал: Amit Shekhar / Outcome School. Источник X: пост Amit Shekhar. Полная статья: How does a Vector Database work?.

В этой статье разберём, как работает векторная база данных. Это один из ключевых компонентов современных AI-поисковиков, рекомендательных систем и инструментов вроде ChatGPT, которые отвечают на вопросы по нашим собственным документам.

Разберём:

• что такое векторная база данных;
• короткое напоминание про эмбеддинги;
• почему обычных баз данных недостаточно;
• что на самом деле хранит векторная база;
• как измеряется похожесть;
• cosine similarity;
• dot product;
• euclidean distance;
• задачу ближайших соседей;
• почему полный перебор слишком медленный;
• Approximate Nearest Neighbour (ANN) и индексацию;
• HNSW простыми словами;
• IVF простыми словами;
• PQ простыми словами;
• небольшой пример кода;
• реальные применения векторных баз данных.

Автор оригинала — Amit Shekhar, основатель Outcome School. Он преподаёт AI и Machine Learning в Outcome School.

Поехали.

Что такое векторная база данных?

Векторная база данных — это специальный тип базы данных, который хранит данные в виде чисел и помогает находить объекты, похожие по смыслу, а не только объекты с точным совпадением.

Проще говоря, обычная база данных хорошо ищет точные совпадения. Векторная база данных хорошо находит то, что близко по смыслу.

Разложим термин:

Vector Database = Vector + Database

База данных — это организованное место для хранения данных, чтобы потом их можно было найти. Вектор — это просто список чисел, например [0.21, 0.87, 0.13].

То есть векторная база данных — это база, построенная для хранения списков чисел и быстрого поиска списков, наиболее похожих на заданный список.

Возникает очевидный вопрос: почему мы вообще храним данные как список чисел? Чтобы ответить, сначала нужно вспомнить, что такое эмбеддинги.

Короткое напоминание про эмбеддинги

Перед тем как переходить к векторным базам данных, важно понимать эмбеддинги, потому что именно из них появляются векторы.

Эмбеддинг — это список чисел, который представляет смысл чего-либо: слова, предложения, изображения или песни.

Специальная AI-модель читает наши данные и превращает их в эти числа. Модель обучена так, что объекты с похожим смыслом получают похожие числа. Вызовы embedding-моделей стоят времени и денег, поэтому в продакшене часто используют кэш эмбеддингов, чтобы не пересчитывать одно и то же.

Допустим, мы превращаем три слова в эмбеддинги:

"king"   ->  [0.91, 0.12, 0.55]

"queen"  ->  [0.89, 0.15, 0.58]

"banana" ->  [0.10, 0.95, 0.03]

Здесь видно, что king и queen имеют близкие числа, потому что связаны по смыслу. А banana сильно отличается, потому что не имеет отношения к королям и королевам.

Ключевая идея: похожий смысл даёт похожие числа. Каждый эмбеддинг — это вектор, и именно его мы храним в векторной базе данных.

Если интересно, как модель учится размещать похожие смыслы рядом, а разные — дальше друг от друга, это обычно объясняют через contrastive learning.

Теперь, когда мы вспомнили эмбеддинги, посмотрим, почему обычной базы данных недостаточно.

Почему обычных баз данных недостаточно

Обычная база данных, например MySQL или PostgreSQL, отлично работает с точными совпадениями.

Если мы ищем слово apple, обычная база найдёт каждую строку, где буквально есть слово apple. Это идеально, когда мы точно знаем значение, которое ищем.

Но есть нюанс. Что если пользователь ищет fruit that keeps the doctor away? Обычная база будет искать именно эти слова. Она не понимает, что ответ — apple. У неё нет чувства смысла.

Допустим, у нас есть документы:

• An apple a day keeps the doctor away.
• Bananas are rich in potassium.
• The doctor recommended eating more fruits.

Если мы ищем healthy fruit advice from a doctor, обычная база может не справиться, потому что ни один документ не содержит эту точную фразу. Она сопоставляет слова, а не смысл.

Разница выглядит так:

Query: "healthy fruit advice from a doctor"

        |                              |
        v                              v

  Normal Database                 Vector Database
  (matches EXACT words)           (matches MEANING)

        |                              |
        v                              v

  No row has these                Finds the apple article
  exact words                     and the doctor article

        |                              |
        v                              v

  Result: misses the meaning      Result: closest in meaning

Один и тот же запрос идёт в две системы. Обычная база проваливается, потому что точной фразы нет. Векторная база срабатывает, потому что ищет по смыслу и возвращает ближайшие совпадения.

Важно: некоторые обычные базы сегодня умеют добавлять векторный поиск через расширения, например PostgreSQL с pgvector. Но они используют те же идеи векторного поиска. Поэтому вопрос не в «обычная база против векторной», а в том, умеет ли конкретная система искать по смыслу.

Нам нужна система, которая понимает смысл и находит ближайшие совпадения даже тогда, когда слова отличаются. Здесь и появляется векторная база данных.

Что на самом деле хранит векторная база данных

Для каждого объекта векторная база обычно хранит три вещи:

• вектор — список чисел, то есть эмбеддинг, представляющий смысл;
• исходные данные — текст, ссылка на изображение, товар или другой объект, который нужно показать пользователю;
• метаданные — категория, дата, автор, цена и другие поля для фильтрации.

Например, статья про яблоки внутри векторной базы может выглядеть так:

ID:        101

Vector:    [0.91, 0.12, 0.55, ... ]

Data:      "An apple a day keeps the doctor away."

Metadata:  { "category": "health", "year": 2024 }

Вектор несёт смысл, данные — это то, что мы показываем пользователю, а метаданные помогают фильтровать результаты, например показывать только статьи за 2024 год.

Метаданные можно использовать двумя способами. Можно сначала отфильтровать документы и запускать similarity search только по прошедшим фильтр объектам — это pre-filtering. А можно сначала сделать поиск похожих объектов, а потом удалить результаты, которые не подходят фильтру — это post-filtering. Обычно pre-filtering лучше, потому что не тратит поиск на объекты, которые всё равно будут отброшены.

Так векторная база держит рядом и смысл, и исходный контент.

Как измерять похожесть?

Теперь у нас есть набор сохранённых векторов. Когда пользователь ищет что-то, мы тоже превращаем его запрос в вектор. Затем нужно найти сохранённые векторы, наиболее похожие на него.

Как измерить похожесть двух векторов? Для этого используют метрику похожести — формулу, которая принимает два вектора и возвращает число, показывающее, насколько они близки.

Есть три распространённые метрики: cosine similarity, dot product и euclidean distance. Разберём каждую с формулой, примером и простой схемой.

Cosine similarity

Cosine similarity измеряет угол между двумя векторами. Ей не важно, насколько длинные векторы. Важно только направление.

Проще говоря, если два вектора смотрят в одном направлении, они похожи, даже если один длиннее другого.

Результат всегда находится между -1 и 1:

• значение около 1 означает, что векторы направлены почти одинаково и очень похожи;
• значение около 0 означает, что они примерно под прямым углом и не связаны;
• значение около -1 означает, что они направлены в противоположные стороны и сильно отличаются.

Схематично:

small angle  ->  cosine near 1  (very similar)

       B
      /
     /
    /
   +---------- A


right angle  ->  cosine near 0  (unrelated)

   B
   |
   |
   |
   +---------- A

Маленький угол означает, что стрелки направлены почти одинаково, поэтому значение близко к 1. Прямой угол означает слабую связанность, поэтому значение около 0.

Формула:

cosine similarity = (A · B) / (|A| × |B|)

A · B — это dot product: мы перемножаем соответствующие числа двух векторов и складываем результаты. |A| и |B| — длины векторов.

Пример. Есть два вектора:

A = [2, 3]
B = [4, 6]

B — это A, где каждое число удвоено, поэтому оба вектора направлены одинаково.

Шаг 1: перемножаем соответствующие числа и складываем — получаем dot product.

A · B = (2 × 4) + (3 × 6) = 8 + 18 = 26

Шаг 2: находим длину A.

|A| = √(2² + 3²) = √(4 + 9) = √13 ≈ 3.61

Шаг 3: находим длину B.

|B| = √(4² + 6²) = √(16 + 36) = √52 ≈ 7.21

Шаг 4: делим dot product на произведение длин.

cosine similarity = 26 / (3.61 × 7.21) ≈ 26 / 26.0 ≈ 1.0

Результат 1.0: векторы максимально похожи, потому что направлены одинаково.

Примечание: полный диапазон cosine similarity — от -1 до 1. Но многие современные embedding-модели возвращают нормализованные векторы, поэтому на практике в текстовом поиске значения часто лежат между 0 и 1, и отрицательные встречаются редко.

Именно поэтому cosine similarity так популярна для текстового и семантического поиска: два предложения с одинаковым смыслом смотрят в одном направлении, даже если одно гораздо длиннее другого.

Dot product

Dot product — самая простая из трёх метрик. Мы перемножаем соответствующие числа двух векторов и складываем все результаты в одно число.

Формула:

A · B = (a₁ × b₁) + (a₂ × b₂) + (a₃ × b₃) + ...

Проще говоря, выравниваем два списка чисел, умножаем элементы позиция к позиции и складываем всё вместе.

Пример:

A = [1, 2, 3]
B = [4, 5, 6]

Dot product:

A · B = (1 × 4) + (2 × 5) + (3 × 6)
      =    4    +   10    +   18
      =            32

Та же идея на схеме:

A:    1      2      3
      ×      ×      ×        (multiply each matching pair)
B:    4      5      6
      =      =      =
      4   +  10  +  18   =   32     (then add the results)

Каждое число из A умножается на число под ним из B, затем всё складывается и получается 32.

Чем больше dot product, тем больше похожесть. Проверим ещё один вектор:

C = [0, 0, 1]

A · C = (1 × 0) + (2 × 0) + (3 × 1) = 0 + 0 + 3 = 3

A и B дают 32, а A и C — только 3. Значит, A гораздо больше похож на B, чем на C.

Но есть подвох: dot product зависит не только от направления, но и от размера векторов. Более длинный вектор может дать больший dot product даже при неидеальном совпадении направления. Поэтому dot product лучше всего работает, когда все векторы нормализованы — то есть приведены к одной длине. Тогда dot product и cosine similarity согласуются.

Dot product — быстрый и популярный выбор, если векторы уже нормализованы.

Euclidean distance

Euclidean distance измеряет прямое расстояние между двумя точками. Это то же расстояние, которое мы измерили бы линейкой между двумя точками на бумаге.

Здесь каждый вектор рассматривается как точка в пространстве. Чем ближе точки, тем они похожее. В отличие от предыдущих метрик, здесь меньшее значение означает большую похожесть.

Формула:

distance = √( (a₁ - b₁)² + (a₂ - b₂)² + ... )

Мы вычитаем соответствующие числа, возводим каждую разницу в квадрат, складываем и берём квадратный корень.

Пример:

A = [1, 2]
B = [4, 6]

Шаг 1: вычитаем соответствующие числа.

(1 - 4) = -3      and      (2 - 6) = -4

Шаг 2: возводим результаты в квадрат.

(-3)² = 9      and      (-4)² = 16

Шаг 3: складываем и берём квадратный корень.

distance = √(9 + 16) = √25 = 5

Расстояние между A и B равно 5.

На простой сетке:

y
 6 |                  B (4, 6)
 5 |                / :
 4 |              /   :  vertical gap = 4
 3 |            /     :
 2 | A (1, 2) ........:
 1 |          horizontal gap = 3
 0 +----------------------- x
   0   1   2   3   4   5

Горизонтальный разрыв равен 3, вертикальный — 4, а euclidean distance — длина прямой между точками, то есть 5.

Ещё одна точка:

C = [1, 3]

distance from A = √( (1 - 1)² + (2 - 3)² ) = √(0 + 1) = 1

C находится на расстоянии 1 от A, а B — на расстоянии 5. Значит, C ближе и похожее на A, чем B.

Euclidean distance естественно подходит для изображений и пространственных данных, где важны фактическое положение и расстояние между точками.

Сравним метрики:

Cosine similarity и dot product дают большее число для похожих объектов, а euclidean distance — меньшее. Мы выбираем метрику под данные и задачу.

Задача ближайших соседей

Когда пользователь делает запрос, мы превращаем его в вектор. Затем нужно найти сохранённые векторы, ближайшие к нему.

Это называется задачей ближайших соседей. Простыми словами: по одному вектору найти ближайшие векторы среди миллионов сохранённых.

Допустим, пользователь ищет healthy fruit. Мы превращаем это в вектор, сравниваем со всеми сохранёнными векторами и выбираем несколько наиболее похожих.

В топе окажутся статья про яблоко и статья про банан, потому что обе о полезных фруктах, хотя пользователь не вводил эти слова буквально. В этом магия поиска по смыслу.

Полный путь запроса:

User query (text)
"healthy fruit"

      |
      v

Embedding Model
(turns text into numbers)

      |
      v

Query Vector
[0.90, 0.13, 0.56, ...]

      |
      v

Vector Database
(similarity search)

      |
      v

Top matching results
(apple article, banana article)

Пользователь вводит обычный текст, embedding-модель превращает его в query vector, векторная база сравнивает этот вектор с сохранёнными и возвращает результаты, ближайшие по смыслу.

Цель проста: найти ближайших соседей query vector. Следующий большой вопрос — как сделать это быстро.

Независимо от технической области, полезно разобраться с темами:

• LLM;
• RAG;
• MCP;
• Agent;
• Fine-tuning;
• Quantization.

Теперь вернёмся к теме.

Почему полный перебор слишком медленный

Самый простой способ найти ближайших соседей — brute force, полный перебор.

При полном переборе мы сравниваем query vector с каждым сохранённым вектором по очереди и оставляем ближайшие.

Если у нас 10 векторов, сравнить со всеми легко. Но в реальных приложениях не 10 векторов, а миллионы или миллиарды.

Представим 100 миллионов векторов, и в каждом 1000 чисел. Для одного поиска нужно выполнить 100 миллионов сравнений, а каждое сравнение трогает 1000 чисел. Это 100 миллиардов вычислений на один запрос.

Пользователи при этом ждут ответ за несколько миллисекунд. Полный перебор на таком масштабе не справляется.

Проблема этого подхода — он слишком медленный для больших данных. Следующий подход решает её.

Approximate Nearest Neighbour (ANN) и индексация

Здесь помогает Approximate Nearest Neighbour, или ANN.

Ключевая идея: нам не всегда нужен идеально ближайший результат. Нам нужен очень близкий результат, но очень быстро.

ANN обменивает небольшую долю точности на огромный прирост скорости. Вместо проверки каждого вектора алгоритм умно пропускает большую часть и проверяет только те, которые, вероятно, близки.

Сравнение:

Brute force (exact):
query  ->  compare with ALL 100,000,000 vectors  ->  perfect match, but very slow

ANN (approximate):
query  ->  jump to the promising area  ->  check only a few thousand  ->  very close match, super fast

Brute force проверяет всё и получает идеальный ответ, но медленно. ANN прыгает близко к ответу и проверяет только малую часть данных.

Насколько «близко» достаточно? Это измеряют через recall. Recall показывает, сколько из действительно ближайших векторов поиск сумел найти.

Например, истинный top-10 — идеальный ответ. Если ANN вернул 9 из этих 10, recall равен 90%. Во многих реальных приложениях получить 9 из 10 за миллисекунды лучше, чем получить все 10 за секунды.

Чтобы пропускать большую часть данных, векторная база строит индекс. Индекс — это умная структура, которая заранее организует векторы, чтобы во время поиска можно было сразу перейти в перспективную область, а не сканировать всё.

Простой пример: найти друга в городе. Brute force — это стучаться в каждую дверь во всей стране. Индекс — сначала выбрать нужный город, потом улицу, и только потом проверить несколько домов. Так мы добираемся до ответа быстрее.

Три популярные техники: HNSW, IVF и Product Quantization (PQ). HNSW и IVF помогают выбрать, какие векторы проверять. PQ помогает сжать каждый вектор и сэкономить память.

HNSW простыми словами

HNSW означает Hierarchical Navigable Small World. Название тяжёлое, но идея простая.

• Hierarchical — структура построена слоями, один над другим.
• Navigable Small World — точки соединены друг с другом как друзья в социальной сети, где почти до любого можно добраться за несколько переходов.

Можно думать об этом как о слоистой карте связей, где похожие векторы соединены друг с другом.

Верхний слой содержит очень мало точек, расположенных далеко друг от друга. Это как карта с крупными городами: можно быстро перепрыгивать на большие расстояния.

Средние слои содержат больше точек, ближе друг к другу. Это как карта городков внутри региона.

Нижний слой содержит все точки, очень плотно. Это как карта на уровне улиц и домов.

При поиске мы начинаем сверху и делаем большие прыжки к области рядом с запросом. Затем спускаемся на слой ниже и делаем более мелкие шаги. Так идём вниз до нижнего слоя, где находим финальных ближайших соседей.

Простая схема поиска: ищем точку, ближайшую к запросу, и ответ оказывается E.

Layer 2 (top):     A --------------- F        few points, big jumps
                                     |
                                     v
Layer 1 (middle):  A --- C --- D --- F        more points, medium steps
                           |
                           v
Layer 0 (bottom):  A-B-C-D-E-F-G-H            all points, fine steps  ->  reach E

Мы начинаем с больших прыжков наверху, потом делаем средние шаги, затем тонкую настройку внизу и приходим к E. При этом не проверяем каждую точку.

По шагам:

• Шаг 1: войти на верхний слой, где мало точек. Перейти к точке, ближайшей к запросу. Это покрывает большое расстояние одним прыжком.
• Шаг 2: спуститься на средний слой. От достигнутой точки перейти к ещё более близкому соседу.
• Шаг 3: спуститься на нижний слой. Делать маленькие аккуратные шаги среди плотных точек, пока не найдём ближайшую.

Так HNSW даёт очень быстрый и точный поиск. Это один из самых широко используемых индексов в современных векторных базах данных.

IVF простыми словами

IVF означает Inverted File Index. Это ещё один способ ускорить поиск.

Идея — заранее сгруппировать похожие векторы в кластеры. Группировка выполняется один раз до поиска.

Допустим, мы делим все векторы на несколько кластеров. У каждого кластера есть центральная точка — среднее представление группы.

Cluster 1          Cluster 2          Cluster 3
  +----------+       +----------+       +----------+
  |  x    x  |       |  x   x   |       |  x  x  x |
  |    C1    |       |    C2    |       |    C3    |
  |  x    x  |       |   x   x  |       |   x   x  |
  +----------+       +----------+       +----------+

  C1, C2, C3 are the center points (the average of each group)
  each x marks one stored vector inside the cluster

Векторы поделены на группы, у каждой группы есть центр.

Когда пользователь ищет, мы сначала сравниваем query vector только с центрами кластеров, а не с миллионами векторов. Затем выбираем несколько кластеров, центры которых ближе всего к запросу, и ищем только внутри них.

Query
  |
  v
Compare with cluster centers only      (cheap, just a few comparisons)
  |
  v
Pick the closest clusters              (say, the 3 nearest clusters)
  |
  v
Search only inside those clusters      (ignore all the other clusters)

IVF сначала сужает область до нескольких кластеров, а потом ищет только внутри них.

Числовой пример: у нас 100 миллионов векторов, разбитых на 100 кластеров. В каждом кластере по 1 миллиону векторов. Если мы ищем только в 3 ближайших кластерах, проверяем 3 миллиона векторов вместо 100 миллионов. Экономия огромная, поиск становится намного быстрее полного перебора.

Компромисс: если истинно ближайший вектор оказался в пропущенном кластере, мы его не найдём. Чтобы снизить риск, можно проверять больше кластеров: точность растёт, но время тоже. Это настраивается под задачу.

PQ простыми словами

PQ означает Product Quantization. HNSW и IVF помогают выбрать, какие векторы проверять. PQ делает другое: сжимает каждый вектор, чтобы он занимал меньше памяти.

Сначала про проблему памяти. Допустим, в каждом векторе 128 чисел, каждое число занимает 4 байта. Один вектор — 512 байт. Для 1 миллиарда векторов нужно около 512 гигабайт только на сами векторы. Держать это в памяти дорого.

Можно ли хранить каждый вектор в меньшей форме, не теряя слишком много смысла? Это и делает PQ: сжимает вектор в маленький код.

Шаг 1: разбить вектор на маленькие части. Например, 128-мерный вектор делим на 8 частей по 16 чисел.

Шаг 2: для каждой части заранее подготовить небольшой набор типовых фрагментов — codebook. Можно представить коробку из 256 готовых образцов.

Шаг 3: для каждой части нашего вектора найти ближайший образец из codebook и сохранить только номер этого образца от 0 до 255 вместо всех 16 чисел.

В итоге вместо 128 вещественных чисел мы храним 8 маленьких кодов. Каждый код занимает 1 байт, весь вектор — 8 байт вместо 512. Экономия памяти в 64 раза.

Original vector (128 numbers, 512 bytes)

[ piece 1 ][ piece 2 ][ piece 3 ] ... [ piece 8 ]
     |          |          |              |
     v          v          v              v
  code 37    code 12    code 200  ...   code 5      (each code is 1 byte)

Compressed vector (8 codes, 8 bytes)

Каждая часть заменяется ближайшим готовым образцом из своего codebook, и мы храним только номер образца. Вектор сжимается с 512 байт до 8 байт.

Во время поиска сравнение выполняется по этим маленьким кодам: нужно меньше памяти, и поиск работает быстрее.

PQ немного жертвует точностью ради огромной экономии памяти, потому что сжатый вектор — только приближение исходного. На практике PQ часто комбинируют с IVF: IVF сначала сужает поиск до нескольких кластеров, а PQ хранит каждый вектор компактно. Комбинация IVF-PQ делает поиск по миллиардам векторов экономически возможным.

Есть и более простые формы сжатия: scalar quantization и binary quantization. Они уменьшают размер каждого числа и проще в использовании, поэтому популярны в продакшене, когда нужно сэкономить память без лишней сложности.

Теперь посмотрим небольшой пример кода.

Небольшой пример кода

Используем FAISS — популярную open-source библиотеку Meta для векторного поиска.

import faiss
import numpy as np

# Suppose each vector has 4 numbers (dimensions)
dimension = 4

# Create a simple index that uses euclidean distance
index = faiss.IndexFlatL2(dimension)

# Our stored vectors (each row is one item's embedding)
vectors = np.array([
    [0.91, 0.12, 0.55, 0.10],   # apple article
    [0.10, 0.95, 0.03, 0.40],   # banana article
    [0.88, 0.15, 0.58, 0.12],   # doctor and fruit article
], dtype="float32")

# Add the vectors to the index
index.add(vectors)

# The user's search, turned into a vector
query = np.array([[0.90, 0.13, 0.56, 0.11]], dtype="float32")

# Find the 2 nearest neighbours
distances, ids = index.search(query, 2)

print(ids)
print(distances)

Что здесь происходит:

• создаём индекс IndexFlatL2, который использует euclidean distance;
• добавляем три сохранённых вектора в индекс;
• создаём query vector для пользовательского поиска;
• просим top-2 ближайших соседей через index.search.

Вывод:

[[0 2]]

[[0.0004 0.0013]]

Ближайшие совпадения — объект 0 (статья про яблоко) и объект 2 (статья про доктора и фрукты), потому что их векторы ближе всего к запросу. Маленькие distance-значения подтверждают, что они близки по смыслу.

Нюанс: IndexFlatL2 возвращает квадрат euclidean distance. Он пропускает финальный квадратный корень ради скорости. Поэтому 0.0004 и 0.0013 — это квадрат расстояния, а не обычное расстояние из формулы выше. Порядок результатов от этого не меняется.

IndexFlatL2 — это brute force, и он хорош для маленьких данных. Для миллионов векторов используют ANN-индексы вроде HNSW или IVF, которые FAISS тоже поддерживает. Код поиска почти не меняется, но работает намного быстрее.

Так всего в несколько строк можно сохранить векторы и найти наиболее похожие.

Реальные применения векторных баз данных

Теперь — где векторные базы используются на практике. Они лежат в основе многих продуктов, которыми мы пользуемся каждый день.

Семантический поиск. Это поиск по смыслу. Когда мы вводим cheap flights to the beach, система понимает намерение и возвращает релевантные результаты, даже если точных слов нет.

RAG для LLM. RAG означает Retrieval Augmented Generation. Так инструменты вроде ChatGPT отвечают на вопросы по нашим документам. Сначала документы превращаются в векторы и сохраняются в векторной базе. Затем, когда мы задаём вопрос, база находит самые релевантные фрагменты. Потом эти фрагменты передаются LLM, которая пишет ответ на их основе. Так AI отвечает по нашим приватным данным, а не угадывает.

Рекомендации. Когда интернет-магазин показывает товары, которые могут понравиться, он превращает товары и наши предпочтения в векторы, затем ищет товары с похожими векторами. Так появляются рекомендации, которые действительно соответствуют интересам.

Поиск по изображениям. Когда мы ищем, загрузив фото, изображение превращается в вектор. Векторная база находит изображения с похожими векторами и возвращает визуально похожие картинки.

Поиск дублей и мошенничества. Похожие транзакции или документы получают похожие векторы. Векторная база быстро находит близкие совпадения, что помогает ловить дубли и подозрительную активность.

Следующий шаг после базового понимания — изучить hybrid search, где векторный поиск смешивается с традиционным keyword search. Так система получает и смысловые совпадения, и точные совпадения слов. Кроме HNSW и IVF есть другие индексы, например DiskANN и ScaNN, созданные для эффективного поиска по очень большим данным. А когда есть короткий список кандидатов, reranker может переупорядочить их по настоящей релевантности перед передачей в LLM.

Именно так векторная база данных хранит смысл в виде чисел и на огромном масштабе находит самые похожие объекты. Это делает возможными современные AI-поиск, рекомендации и ассистентов.

На этом всё.

Спасибо, Amit Shekhar, Founder @ Outcome School