Когда вы ищете на маркетплейсе товар «как на картинке», переписываетесь с ботом поддержки или видите подборку «вам может понравиться», за этим стоит ИИ. Последние два года он перестал быть отдельным экспериментом и встроился в обычные продукты. Цифры это подтверждают: в исследовании VK Tech, проведенном командой Tarantool, 45% директоров по данным (CDO) крупных российских компаний назвали внедрение решений на базе ИИ и больших языковых моделей целью № 1 для своей команды на 2026 год.
Применяют его широко. Согласно опросу, охватывающему 150 директоров и руководителей направлений по ИТ и данным, чаще всего ИИ используют в аналитике и отчётности (44% компаний), затем в обслуживании ИТ-инфраструктуры (39%), в кибербезопасности (36%), в автоматизации работы дата-инженеров (33%) и в работе с документацией и базами знаний (21%).
Удивляет не сама цифра, а то, как компании это делают. Я каждый день работаю с инфраструктурой, на которой держатся такие сервисы, и действительно вижу: главный запрос 2026 года звучит не «развернуть отдельный ИИ-стек», а «получить новые возможности, не сломав то, что уже работает».
К середине 2026 года в крупных российских компаниях складывается устойчивый порядок внедрения ИИ. Сначала проверяют, можно ли решить задачу тем, что уже есть, встроенным поиском по смыслу, ИИ-помощником поверх инфраструктуры, умным мониторингом. И только если возможностей не хватает, добавляют отдельный компонент, причем это решение принимают на уровне всей архитектуры данных, а не одной команды. Расскажу о том, почему сложился именно такой порядок.
ИИ-функция почти всегда превращается в задачу для инфраструктуры
Бизнес ставит задачу простыми словами: добавить поиск похожих товаров, сделать помощника для службы поддержки, ловить мошеннические операции на свежих данных. Но у всех этих сценариев общий технический знаменатель. Им нужен поиск «по смыслу», а не по точному совпадению слов, быстрый ответ и доступ к актуальным данным.
Поиск по смыслу обеспечивают так называемые векторные индексы. Текст или картинку превращают в набор чисел — вектор. Далее система ищет не точное слово, а ближайшие по смыслу объекты.
По данным того же исследования, 15% компаний уже используют или тестируют специальные векторные базы данных, еще 34% планируют такие проекты на горизонте двух-трёх лет, а 51% пока не использует и не планирует. То есть половина крупного российского tech-рынка уже думает про такой поиск — и именно эта половина формирует требования к следующему поколению инфраструктуры данных.
Как это обычно начинается: стадия экспериментов
Исследование называет самый распространённый сценарий «спонтанным»: команды разработчиков берут инициативу на себя, подключают подписочные ИИ-помощники, тестируют сторонние модели и разворачивают векторные базы под конкретные задачи — каждая команда отдельно, без единой стратегии и без ответственного за данные в целом.
Скорость и небольшое количество согласований — очевидный плюс такого старта. Но исследование фиксирует и характерные последствия: без централизованного контроля данные могут уходить через сторонние подписочные сервисы, модели ведут себя непредсказуемо, ошибки в запросах сложно отследить. Тестовый сервис незаметно становится рабочим, и через год компания обнаруживает «зоопарк» из разрозненных хранилищ и интеграций, где каждая связка держится на одном человеке. Это закономерная стартовая точка — большинство компаний прошли через неё.
Почему «ещё одна база данных» — дорогое удовольствие
У такого подхода есть фундаментальное ограничение, знакомое любому инженеру. Инфраструктура данных крупной компании и без ИИ выглядит непросто: в среднем по миру 70% компаний используют 5−7 и более продуктов от разных поставщиков, и около трети рабочего времени команд уходит на переключение между инструментами.
Добавить в этот набор ещё одну отдельную базу под векторы кажется быстрым решением, но за ним тянется длинная история. Новый компонент нужно отдельно резервировать и следить за его работой, постоянно синхронизировать данные между основным источником и векторным хранилищем, сопровождать ещё один контур безопасности и держать в команде людей, которые в нём разбираются. Для большой компании каждый такой компонент — это постоянная статья расходов.
Отсюда и общая позиция экспертов: отдельная векторная база сегодня добавляет к ландшафту постоянные обязательства — по резервированию, синхронизации и безопасности. Крупный бизнес берёт их на себя только там, где без специализированного решения не обойтись.
Другой путь: научить ИИ жить в тех базах, что уже есть
Альтернатива звучит просто — добавить поиск по смыслу прямо в те базы данных, которые уже стоят в компании. У популярной базы PostgreSQL для этого есть расширение pgvector — самый распространённый вариант, доступный и в opensource, и в вендорских продуктах. Специальные расширения есть и у других баз, особенно транзакционных. ИИ-возможность встраивается без отдельного хранилища.
В российской практике этот путь хорошо виден. МТС сделал помощника для второй линии поддержки по своим базам знаний на связке PostgreSQL и pgvector — без отдельной векторной базы. Т-Банк сочетает один поиск для базовых запросов и другой для поиска по смыслу. А вот Avito ищет похожие изображения и находит дубликаты уже с отдельной специализированной базой, но там и масштаб другой: от 150 до 240 миллионов векторов, и размер задачи оправдывает такой выбор.
Логика везде одна: сначала смотрят на возможности того, что уже есть, и только если их не хватает — добавляют отдельный компонент. Так сохраняется управляемость, не появляется лишнее хранилище со своей жизнью, а эксплуатацией занимаются те же команды.
Когда специализированная база всё-таки нужна
Отказываться от отдельных векторных баз совсем не стоит. Они остаются лучшим выбором там, где поиск по смыслу — основная функция сервиса, а не дополнение. Это рекомендательные системы в видеосервисах и на маркетплейсах, сценарии с особыми требованиями к производительности и надёжности. Но таких сценариев ограниченное число: большую часть задач можно эффективно решить индексами в уже внедрённых базах.
Граница простая. Если поиск по смыслу — часть более широкой задачи и нужен лишь время от времени, удобнее встроить его в существующую базу. Если это основная нагрузка сервиса — отдельная база окупает себя.
ИИ чаще разгружает команду, чем нагружает инфраструктуру
Поиск по смыслу — лишь одно направление из тех, что я перечислил в начале. Логика везде та же: компании внедряют ИИ-ассистентов там, где они могут снять рутину. X5 Tech запустил сервис, который переводит вопрос бизнес-пользователя на естественном языке в запрос к базе данных: перед генерацией он проверяет, корректен ли запрос и целевой ли он, уточняет детали и учитывает контекст диалога — это снижает риск бессмысленного ответа. В системе Text-to-SQL Газпромбанка работают шесть агентов: проверка безопасности на входе, написание кода запроса, поиск нужных таблиц и данных, анализ намерений пользователя, проверка кода на уязвимости, выполнение кода и проверка результата. В обоих случаях ИИ не добавляет новый кубик в инфраструктуру — он работает поверх неё и упрощает доступ.
Ту же идею мы применяем к эксплуатации высоконагруженных систем. Развиваем направление, в котором система не просто показывает метрики, а помогает понять, что именно происходит внутри и где возникла проблема.
Что это меняет
Курс на единые системы — не консерватизм. ИИ в этой логике встраивается туда, где уже живут данные, а не открывает рядом отдельную параллельную систему. И это меняет ожидания от поставщиков баз данных: поиск по смыслу, ИИ-помощники и умный мониторинг становятся не «дополнительными опциями», а тем, что должно быть в продукте по умолчанию.
По данным исследования VK Tech «Тренды развития рынка СУБД» (декабрь 2025 — февраль 2026): 154 респондента онлайн-опроса, 25+ глубинных интервью, представители 170+ российских компаний.