Machine Learning Mastery: لماذا متجر المتجهات الواحد غير كافٍ لتطبيقات الذكاء الاصطناعي

Machine Learning Mastery разобрал распространённую ошибку в архитектуре AI-приложений: считать vector store полноценной базой для всего продукта. На этапе демо этого часто хватает, но в продакшне рядом с векторным поиском почти всегда нужен классический реляционный слой.

Где силён vector store

Векторные базы стали стандартной деталью RAG-систем, потому что решают задачу, с которой обычный SQL справляется плохо: поиск по смыслу, а не по точному совпадению слов. Когда пользователь задаёт вопрос, система превращает его в embedding и ищет ближайшие по смыслу фрагменты документов. За счёт этого AI может находить релевантные тексты даже тогда, когда в них нет тех же формулировок, что и в запросе.

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

Именно поэтому vector store стал базовым компонентом AI-поиска там, где формулировки почти никогда не совпадают слово в слово.

Где нужен SQL

Проблема в том, что гибкость vector search одновременно делает его неточным инструментом для операционных задач. Он хорошо отвечает на вопрос «что похоже по смыслу», но плохо подходит там, где нужен жёсткий ответ без вероятностей и допусков. Как только в продукте появляются пользователи, лимиты, платежи и статусы объектов, приближённый поиск начинает мешать, а не помогать.

Именно поэтому в продакшн-системе реляционная база остаётся местом, где живут все «твёрдые факты»: права доступа и tenant-границы, где ошибка превращается в утечку данных; метаданные документов — автор, URL, дата загрузки, хэш файла, статус публикации; биллинг, аудит, логи и любые записи, которые должны быть консистентными; состояние приложения: архивирован ли чат, включён ли флаг, какой тариф у пользователя. Есть и ещё один практический момент: точная SQL-фильтрация снижает галлюцинации модели. Если AI должен суммировать только high-priority тикеты, закрытые за последние 7 дней фронтенд-командой, сначала нужно жёстко отобрать именно эти записи, и только потом отдавать их текст модели.

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

Гибридная схема

Автор предлагает не выбирать между двумя подходами, а собирать их в один слой данных. Типовой сценарий выглядит так: сначала реляционная база проверяет пользователя, его роль и список документов, к которым у него есть доступ, а уже потом vector store ищет смысловые совпадения только внутри этого безопасного подмножества. Для корпоративных AI-ассистентов это не оптимизация, а граница безопасности.

Без такого предварительного фильтра система рискует показать пользователю данные другой команды или даже другого клиента. Работает и обратный паттерн. После того как векторный поиск вернул релевантные фрагменты, приложение может подтянуть из SQL метаданные: кто автор документа, когда он обновлялся, какой у него статус доверия.

Тогда модель отвечает не абстрактно, а с контекстом — например, с привязкой к свежести документа или отделу, который его выпустил. Для внутренних knowledge base и support-агентов это заметно повышает доверие к ответу и помогает пользователю быстро проверить его происхождение. Для команд, которые не хотят держать две разные базы, Machine Learning Mastery отдельно выделяет pgvector — расширение PostgreSQL для similarity search.

В этом варианте embeddings лежат рядом со структурированными полями, и один запрос может одновременно проверять права, фильтровать записи по дате и статусу, а затем ранжировать их по смысловой близости. Компромисс простой: на умеренном масштабе это заметно упрощает инфраструктуру, но на объёмах в миллиарды векторов специализированные системы вроде Pinecone или Milvus всё ещё быстрее. Зато для сотен тысяч или нескольких миллионов векторов такой подход часто оказывается самым прагматичным стартом.

Что это значит

Главный вывод простой: vector store — это важная часть AI-стека, но не его замена целиком. Если продукт работает с пользователями, доступами, деньгами и состоянием системы, без реляционной базы не обойтись. Для большинства команд разумный старт — PostgreSQL с pgvector или связка SQL + отдельная векторная БД, где каждая технология отвечает только за тот класс задач, который умеет решать лучше всего. Чем раньше это разделение появляется в архитектуре, тем меньше шансов, что демо-версия развалится при первом же реальном росте.