ДомЛаб

Эмбеддинги и векторные базы данных: что это простыми словами

Как текст превращается в вектор, зачем локальному AI нужна векторная база данных и как устроен RAG на домашнем сервере.

6 мин чтенияРедакция ДомЛаб
Иллюстрация к статье: Эмбеддинги и векторные базы данных: что это простыми словами

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

Главная идея не в том, что нейросеть «запоминает файл». Документ разбивается на фрагменты, каждый фрагмент превращается в вектор, а при вопросе система находит ближайшие по смыслу фрагменты и передаёт их языковой модели в контексте.

Эмбеддинги — это не перевод текста в ключевые слова

Классический поиск ищет совпадение слов. Запрос «роутер не раздаёт интернет» может не найти инструкцию, где написано «пропал WAN после перезагрузки». Семантический поиск сравнивает не только отдельные слова, но и получившийся смысловой профиль.

Embedding-модель получает фразу и возвращает массив чисел фиксированной длины. Например, условный текст может превратиться в такой вектор:

[0.021, -0.118, 0.407, 0.003, ...]

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

Эмбеддинг-модель и чат-модель — не одно и то же. Первая превращает данные в векторы, вторая формулирует ответ. Для RAG нужны обе, но у них разные задачи и требования к памяти.

Зачем нужна векторная база данных

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

ЧастьЧто в ней лежит
VectorЧисловой embedding документа или фрагмента
PayloadТекст, заголовок, путь к файлу, дата, права доступа
IndexСтруктура для быстрого поиска похожих векторов

Qdrant, например, организует данные в коллекции и точки. Каждая точка может иметь вектор и дополнительные поля payload. Размер вектора коллекции должен соответствовать embedding-модели: если модель возвращает 768 чисел, коллекция на 384 измерения не подойдёт.

Как работает RAG

RAG — retrieval-augmented generation, то есть генерация с поиском контекста. Для домашней базы знаний процесс выглядит так:

  1. Собираем документы и очищаем текст от меню, повторов и мусора.
  2. Делим их на фрагменты по смыслу, обычно с небольшим перекрытием.
  3. Получаем embedding каждого фрагмента.
  4. Сохраняем вектор, исходный текст и метаданные в векторной базе.
  5. При вопросе пользователя строим embedding запроса той же моделью.
  6. Достаём несколько ближайших фрагментов.
  7. Передаём найденный контекст локальной LLM и просим отвечать только по нему.

Так можно спросить домашнего ассистента: «какой у меня порядок восстановления NAS после отказа диска?» — и получить ответ по своим инструкциям, а не общий текст из обучающей выборки.

Важно: векторная база не исправляет плохие документы. Если в исходной инструкции нет ответа, RAG не создаст его из воздуха. А если выбрать слишком большие или слишком маленькие фрагменты, поиск будет возвращать нерелевантный контекст.

Минимальный локальный стек

Для домашнего сервера достаточно трёх компонентов:

  • Ollama — запускает embedding-модель и локальную LLM;
  • Qdrant — хранит векторы и выполняет поиск;
  • небольшой скрипт — читает документы, индексирует их и формирует запросы.

Сначала установите embedding-модель в Ollama:

ollama pull embeddinggemma

Проверьте генерацию вектора через API:

curl http://localhost:11434/api/embed -d '{
  "model": "embeddinggemma",
  "input": "Как восстановить домашний NAS из резервной копии?"
}'

В ответе будет массив embeddings. Ollama также принимает массив строк, поэтому документы можно обрабатывать пачками, а не по одному запросу.

Запустите Qdrant только на локальном интерфейсе для первого эксперимента:

docker run -d \
  --name qdrant \
  --restart unless-stopped \
  -p 127.0.0.1:6333:6333 \
  -v qdrant_storage:/qdrant/storage \
  qdrant/qdrant

После запуска REST API будет доступен на http://localhost:6333, а панель — на /dashboard. Размер коллекции нужно выбрать по фактической длине вектора вашей модели, а не скопировать из чужого примера.

Qdrant по умолчанию запускается без шифрования и аутентификации. Публикация порта 6333 в интернет или в недоверенную домашнюю VLAN без защиты даёт доступ к чтению, изменению и удалению данных.

Маленький пример на Python

Официальная библиотека Ollama возвращает embedding-массив, а клиент Qdrant принимает его как вектор. Упрощённая проверка выглядит так:

import ollama
 
text = "Home Assistant работает локально и запускает автоматизации без облака."
result = ollama.embed(model="embeddinggemma", input=text)
vector = result["embeddings"][0]
 
print("Размер вектора:", len(vector))
print("Первые значения:", vector[:5])

Дальше приложение создаёт коллекцию с size=len(vector) и расстоянием Cosine, загружает точки, а при новом вопросе повторяет вызов ollama.embed и отправляет результат в поиск Qdrant.

Самое важное правило — использовать одну и ту же embedding-модель при индексации и запросах. Если заменить модель, нужно переиндексировать документы или хранить новую версию в отдельном поле/коллекции.

Как не испортить качество поиска

Режьте по смыслу. Один фрагмент должен содержать законченный ответ или часть инструкции. Заголовок статьи и название раздела полезно добавлять к тексту перед индексацией.

Храните метаданные. Путь к файлу, страницу PDF, дату и раздел сайта можно использовать для фильтрации и вывода источника ответа.

Не берите слишком много результатов. Для начала попробуйте 3–5 фрагментов. Десятки совпадений перегружают контекст и иногда ухудшают ответ.

Оставляйте обычный поиск. Уникальные имена, модели, артикулы и команды лучше ищутся по словам. Гибридный поиск, где объединяются семантическое сходство и BM25, часто надёжнее одного векторного поиска.

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

Когда векторная база не нужна

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

Для небольшого Python-прототипа можно начать с локального хранилища в составе приложения. Для постоянного HomeLab-сервиса Qdrant удобнее, когда нужны отдельный API, фильтры, коллекции и понятное резервное копирование.

Итог

Эмбеддинги — это слой представления смысла, а векторная база данных — быстрый индекс для такого представления. В связке с Ollama и локальной LLM они превращают чат в полезный интерфейс к вашим документам, но не заменяют качество исходной базы и проверку результата.

Для старта достаточно одного embedding-моделя, локального Qdrant и десятка хорошо подготовленных документов. Сначала добейтесь, чтобы поиск находил правильный фрагмент, и только потом добавляйте сложные цепочки, reranking и автоматические агенты.

Полезные ссылки