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

Содержание статьи— 9 разделов
Эмбеддинги — это числовое представление текста, изображения или другого объекта. Векторная база данных хранит такие представления и быстро ищет похожие объекты. Вместе они позволяют локальному 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, то есть генерация с поиском контекста. Для домашней базы знаний процесс выглядит так:
- Собираем документы и очищаем текст от меню, повторов и мусора.
- Делим их на фрагменты по смыслу, обычно с небольшим перекрытием.
- Получаем embedding каждого фрагмента.
- Сохраняем вектор, исходный текст и метаданные в векторной базе.
- При вопросе пользователя строим embedding запроса той же моделью.
- Достаём несколько ближайших фрагментов.
- Передаём найденный контекст локальной LLM и просим отвечать только по нему.
Так можно спросить домашнего ассистента: «какой у меня порядок восстановления NAS после отказа диска?» — и получить ответ по своим инструкциям, а не общий текст из обучающей выборки.
Важно: векторная база не исправляет плохие документы. Если в исходной инструкции нет ответа, RAG не создаст его из воздуха. А если выбрать слишком большие или слишком маленькие фрагменты, поиск будет возвращать нерелевантный контекст.
Минимальный локальный стек
Для домашнего сервера достаточно трёх компонентов. Если готовый интерфейс удобнее собственного скрипта, Open WebUI уже включает загрузку документов и базу знаний:
- 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 и автоматические агенты.




