Векторные базы данных: как ИИ находит смысл вместо ключевых слов

Развитие искусственного интеллекта и больших языковых моделей сделало традиционные базы данных недостаточными для решения задач семантического поиска, рекомендаций и обработки неструктурированной информации. Образовательный проект freeCodeCamp.org совместно с автором канала @codeEdx представил подробный технический курс, раскрывающий фундаментальные принципы работы векторных баз данных — от математического аппарата до практической реализации семантического поиска с использованием модели Google Gemini и хранилища ChromaDB.

🧠 Что такое векторные базы данных и почему они необходимы 3:42

Большинство данных в современном цифровом пространстве являются неструктурированными: это произвольные тексты, PDF-документы, аудиозаписи, видеоролики и изображения . В отличие от структурированных таблиц SQL или полуструктурированных JSON-документов, неструктурированные данные несут глубокий смысловой контекст, который невозможно обработать с помощью стандартных реляционных запросов .

Традиционные реляционные базы данных опираются на поиск по точным ключевым словам и конструкции фильтрации WHERE . Если пользователь ищет фразу «как повысить концентрацию внимания», классическая база данных не сможет найти релевантный документ, если в нем используются синонимы вроде «улучшение фокуса» или «борьба с прокрастинацией» .

Векторная база данных создана специально для хранения, индексации и поиска многомерных векторных представлений, сгенерированных моделями эмбеддингов, что открывает возможность полноценного семантического поиска . При этом векторные хранилища не вытесняют классические SQL-системы, а работают с ними в связке: реляционная база остается надежным источником транзакционных данных (system of record), тогда как векторная база формирует слой быстрого семантического извлечения .

Жизненный цикл данных в векторной системе разделен на два ключевых этапа:

• Этап загрузки (Ingestion Pipeline): сырые данные передаются в модель эмбеддингов, преобразуются в массивы чисел с плавающей точкой (векторы) и сохраняются в базе вместе с метаданными и ссылками на исходный контент . На этом же шаге строится специализированный индекс для предотвращения линейного перебора .
• Этап извлечения (Retrieval Pipeline): поисковый запрос пользователя пропускается через ту же самую модель эмбеддингов, чтобы вектор запроса оказался в том же геометрическом пространстве, после чего база находит ближайших соседей, ранжирует результаты и возвращает топ-$K$ наиболее релевантных совпадений .

Ключевые сферы промышленного внедрения векторных баз данных охватывают:

• Рекомендательные платформы гигантов вроде Netflix, Amazon и YouTube, сопоставляющие вектор поведения пользователя (клики, история просмотров) с вектором характеристик контента ;
• Системы генерации с расширенным поиском (RAG), передающие актуальный контекст в большие языковые модели ;
• Алгоритмы обнаружения аномалий и финансового мошенничества .

📐 Геометрия смысла: что такое вектор в машинном обучении 22:40

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

Количество признаков напрямую определяет размерность (dimensionality) пространства . Для наглядности можно рассмотреть пример описания автомобиля:

• 1D-пространство: учитывается только максимальная скорость. Автомобили размещаются на числовой прямой, где машины со схожей скоростью (например, 160 км/ч и 180 км/ч) оказываются рядом, а медленные (80 км/ч) — на удалении .
• 2D-пространство: добавляется показатель пробега. Объекты проецируются на плоскость, формируя кластеры по двум параметрам .
• 3D-пространство: добавление третьего признака — стоимости — формирует трехмерное пространство признаков .

В реальных системах искусственного интеллекта число параметров не ограничивается тремя или четырьмя: современные модели эмбеддингов создают векторы размерностью до 3072 измерений . Несмотря на невозможность визуализировать $N$-мерное пространство человеком, геометрическая логика сохраняется: схожие по смыслу и характеристикам объекты группируются близко друг к другу, а семантически чуждые элементы оказываются на удалении .

📏 Метрики схожести: косинусное сходство против евклидова расстояния 33:37

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

Косинусное сходство (Cosine Similarity) 33:48

Косинусное сходство оценивает ориентацию векторов в пространстве, полностью игнорируя их физическую длину (магнитуду) . Формула рассчитывается как скалярное произведение двух векторов, деленное на произведение их длин :

$$\text{Cosine Similarity} = \frac{A \cdot B}{|A| |B|}$$

Результат вычисления строго лежит в диапазоне от -1 до 1:

• Значение 1: угол между векторами равен $0^\circ$, направления полностью совпадают, объекты идентичны по контексту .
• Значение 0: угол составляет $90^\circ$, векторы ортогональны и не имеют между собой никакой связи .
• Значение -1: угол равен $180^\circ$, векторы диаметрально противоположны по значению, но связаны общей смысловой шкалой .

Если вектор $A$ равен $[2, 0, 1]$, а вектор $B$ равен $[4, 0, 2]$, то магнитуда $B$ ровно вдвое превышает магнитуду $A$, однако угол между ними равен нулю, а косинусное сходство равно $1.0$ . Именно поэтому косинусная метрика считается золотым стандартом для векторных баз данных: в текстовых моделях смысл заложен в направлении вектора, а длина часто отражает лишь объем или частоту употребления терминов .

Евклидово расстояние (Euclidean Distance) 40:37

Евклидово расстояние измеряет длину геометрического отрезка прямой, соединяющего две точки в пространстве, вычисляясь через квадратный корень из суммы квадратов разностей координат :

$$\text{Distance} = \sqrt{\sum (A_i - B_i)^2}$$

Диапазон евклидова расстояния простирается от $0$ (полное совпадение координат) до бесконечности . Эта метрика чувствительна к абсолютным значениям и применяется преимущественно в физических и пространственных системах: робототехнике, GPS-навигации и анализе геоданных, где физическая удаленность важнее смысловой ориентации .

🔤 Токенизация как фундамент цифрового текста 45:16

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

Токены называют «валютой современного ИИ», поскольку облачные провайдеры тарифицируют использование моделей именно на основе количества обработанных токенов .

В обработке естественного языка исторически выделились три подхода к токенизации:

1. Посимвольная (Character Tokenization): каждый символ превращается в отдельный токен. Для короткой фразы «I love vector database» из 13 уникальных знаков формируется 13 токенов . Главный недостаток метода — взрывной рост длины последовательности, перегружающий вычислительные мощности нейросетей .
2. Пословная (Word Tokenization): строка делится по пробелам и знакам препинания. Минус подхода кроется в колоссальном объеме словаря: языки содержат сотни тысяч уникальных слов и словоформ, что приводит к проблемам с редкими терминами .
3. Пословные части (Subword Tokenization): промежуточный компромисс, используемый во всех современных моделях, включая GPT и Gemini . Часто встречающиеся слова остаются едиными токенами, а длинные или сложные конструкции разбиваются на устойчивые морфемы и суффиксы.

На примере токенизатора OpenAI видно, что фраза из 252 символов преобразуется всего в 53 токена . Базовые слова вроде «organization» получают единый идентификатор, тогда как «globalization» разделяется на две части: «global» и повторяющийся суффикс «ization» . Специфические символы Unicode и эмодзи раскладываются на несколько байтовых токенов, а распространенные последовательности цифр (например, «123») агрегируются в единые блоки .

🧬 Модели эмбеддингов и векторная арифметика 57:23

Сами по себе токены представляют собой лишь порядковые номера в словаре и лишены семантики: токен с номером 500 не ближе по смыслу к токену 501, чем к токену 20000 . Задача модели эмбеддингов — перевести последовательность токенов в многомерные векторы, где расстояние отражает смысловую близость .

Векторные пространства эмбеддингов обладают свойством линейной семантической композиции . Векторная модель GloVe 300D демонстрирует классические математические операции со смыслом:

• Вектор слова «король» минус «мужчина» плюс «женщина» дает ближайшую координату слова «королева» ;
• Координата «Дели» минус «Индия» плюс «Япония» математически приводит к вектору «Токио» .

Эволюция архитектур эмбеддингов прошла через несколько этапов:

• Словные эмбеддинги (Word Embeddings): модели Word2Vec и GloVe сопоставляли вектор каждому отдельному слову . Ключевой недостаток архитектуры — полное отсутствие контекста: слово «банк» (финансовая организация) и «банк» (берег реки в английском языке — river bank) получали одну и ту же статическую координату .
• Текстовые эмбеддинги (Text Embeddings): современные трансформеры от OpenAI, Google и Cohere принимают на вход целые предложения, абзацы или документы, формируя вектор с учетом синтаксиса и контекстуального окружения .
• Мультимодальные эмбеддинги (Multimodal Embeddings): передовые модели проецируют текст, изображения, аудио и видеофайлы в единое векторное пространство, позволяя искать картинки по текстовому описанию и наоборот .

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

🧪 Практика: генерация эмбеддингов в Google Gemini и визуализация PCA 1:11:48

Для демонстрации генерации эмбеддингов используется API линейки Google Gemini. Модель gemini-embedding-001, обновленная в июне 2025 года, ориентирована на текст, принимает до 2048 токенов и генерирует векторы гибкой размерности от 128 до 3072 измерений (рекомендуемые значения: 768, 1536 и 3072) . Мультимодальная модель gemini-embedding-2, выпущенная в апреле 2026 года, поддерживает текст, изображения, видео и PDF с контекстным окном до 8000 токенов .

В среде Google Colab процесс создания векторов строится через библиотеку Google GenAI :

1. Инициализируется клиент через защищенный API-ключ: client = genai.Client().
2. Формируется массив текстовых строк на разные темы (программирование, покупка смартфонов, бытовые команды) .
3. Вызывается метод client.models.embed_content с указанием модели gemini-embedding-001, входного контента, типа задачи semantic_similarity и желаемой выходной размерности 768 .

Матрица косинусного сходства, рассчитанная с помощью библиотеки pandas и sklearn, наглядно доказывает работу семантики: фраза «How to write a Python function?» демонстрирует наивысший коэффициент сходства с вопросом «How to create a Java class?», а запрос о лучшей камере смартфона связывается с выбором лучшего Android-устройства .

Поскольку человек не может воспринимать 768-мерное пространство, для анализа применяется метод главных компонент (PCA — Principal Component Analysis) . Алгоритм сокращает размерность матрицы с 768 до 3 измерений с сохранением максимального объема дисперсии данных . С помощью интерактивной библиотеки Plotly семантические кластеры отображаются в виде трехмерного графа, где близкие по смыслу фразы формируют компактные визуальные группы .

🏗 Внутренняя архитектура векторной базы данных 1:22:07

Линейное сканирование базы из миллиона векторов требует попарного вычисления расстояний с вычислительной сложностью $O(N)$, что делает отклик неприемлемо долгим . Векторная база данных решает эту проблему за счет четырехкомпонентной внутренней архитектуры :

+-------------------------------------------------------------+
|                         API Gateway                         |
|   (Маршрутизация CRUD, парсинг запросов, аутентификация)   |
+------------------------------+------------------------------+
                               |
+------------------------------v------------------------------+
|                    Query Processing Engine                  |
|    (Координация поиска, пост-фильтрация, ранжирование Top-K)|
+---------------+------------------------------+--------------+
                |                              |
+---------------v--------------+ +-------------v--------------+
|        Indexing Layer        | |        Storage Layer       |
| (Индексы ANN: IVF и HNSW для | |(Хранилище сырых векторов,  |
|      быстрого поиска)        | | репликация, шардинг)       |
+------------------------------+ +----------------------------+

1. Шлюз API (API Gateway): точка входа в систему, предоставляющая клиентам интерфейсы для двух изолированных процессов — загрузки данных (CRUD-операции) и выполнения поисковых запросов .
2. Слой индексации (Indexing Layer): ядро базы данных, организующее многомерные векторы с помощью алгоритмов приближенного поиска ближайших соседей (ANN — Approximate Nearest Neighbor) . Наиболее распространены два метода:
   • IVF (Inverted File Index): делит векторное пространство на кластеры по алгоритму Вороного, сужая поиск до векторов внутри ближайшего центроида ;
   • HNSW (Hierarchical Navigable Small World): многослойный граф, обеспечивающий логарифмическую скорость навигации между удаленными и локальными узлами .
3. Слой хранения (Storage Layer): отвечает за долговечность, низкую задержку операций чтения/записи, шардирование больших коллекций для горизонтального масштабирования и репликацию для отказоустойчивости .
4. Движок обработки запросов (Query Processing Engine): координирует обращение к индексам и физическому хранилищу, применяет фильтры по метаданным и формирует финальный список лучших $K$ результатов .

🛠 Создание семантического поиска в ChromaDB 1:29:26

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

Подготовка инфраструктуры начинается с установки библиотеки:

pip install chromadb

Создание хранилища и загрузка эмбеддингов выполняются следующим образом :

import chromadb

# Инициализация постоянного клиента с локальной директорией
chroma_client = chromadb.PersistentClient(path="./chroma_db_data")

# Создание коллекции (аналог таблицы в SQL)
collection = chroma_client.get_or_create_collection(name="codedx_chromadb_demo")

# Добавление документов, их эмбеддингов и уникальных ID
collection.add(
    documents=text_list,
    embeddings=generated_embeddings, # Размерность 768 от Gemini
    ids=[f"id_{i}" for i in range(len(text_list))]
)

Критически важное правило векторного поиска: поисковый запрос пользователя должен быть векторизован строго той же самой моделью и приведен к той же размерности (в данном случае — gemini-embedding-001 и 768 измерений), иначе векторы окажутся в несовместимых геометрических пространствах .

При выполнении запроса collection.query(query_embeddings=[query_embedding], n_results=2) по слову «programming» база данных возвращает документы «How to write a Python function?» и «How to create a Java class?» . Примечательно, что само слово «programming» ни разу не встречается в исходном тексте . Аналогично запрос «electronics» безошибочно извлекает новости о новом iPhone и характеристиках камер смартфонов .

Этот практический пример показывает главное преимущество векторных баз данных перед классическими поисковыми системами: алгоритм оценивает контекст и смысл понятий, а не занимается поверхностным сопоставлением буквенных совпадений.