Векторные базы данных для бизнеса: что это, зачем нужны ИИ-агентам и когда без них можно обойтись

Проблема, которую решает векторная база

Сотрудник спрашивает ассистента: «что делать, если клиент просит вернуть деньги за услугу, которую уже оказали». В регламенте этот случай описан словами «порядок возврата при частичном исполнении». Ни одно слово из вопроса не совпадает с текстом регламента, и обычный поиск по словам его не найдёт. Человек понимает, что это одно и то же. Чтобы это понимала программа, нужен поиск по смыслу, и для него нужна векторная база.

Это ключевой элемент метода RAG, по которому агенты отвечают по документам компании: сначала найти подходящие фрагменты, потом сформулировать ответ по ним. Как устроен RAG целиком, объяснено в статье «RAG: как научить ИИ отвечать по документам».

Как это работает простыми словами

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

Зачем это бизнесу: четыре задачи

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

• Документов много и они длинные. Сотни страниц регламентов, тысячи карточек, архив договоров. В инструкцию модели они не помещаются.
• Вопросы задаются своими словами. Клиенты и сотрудники не знают терминов из ваших документов.
• Нужен источник ответа. Агент должен показать, откуда взял ответ, а для этого — найти конкретный фрагмент.
• Документы меняются. Обновили регламент — обновили фрагменты; переобучать ничего не нужно, в отличие от дообучения модели. Сравнение подходов — в статье «Дообучение или RAG».

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

• Документов мало. Десяток страниц помещаются в инструкцию агента целиком, и поиск не нужен.
• Данные структурированы. Остатки, цены, статусы лежат в 1С и CRM; их нужно запрашивать обычными запросами, а не искать по смыслу. Агент для аналитики данных векторами не пользуется.
• Нужна точность по ключу. Номер договора, артикул, ИНН ищутся точным совпадением, векторный поиск здесь хуже.
• Задача не про поиск. Разбор письма, классификация, извлечение данных из документа — модель делает это без базы.

На практике большинство агентов для бизнеса сочетают оба подхода: векторный поиск по документам и обычные запросы к учётным системам. Продавать векторную базу «под всё» — признак того, что подрядчик не разобрался в задаче.

Что бывает внутри: варианты

Для компаний с требованиями к данным всё это разворачивается в контуре вместе с моделью; варианты описаны на странице ИИ в контуре компании.

Что определяет качество, кроме самой базы

1. Разбиение документов. Фрагмент должен быть самодостаточным: пункт с заголовком раздела, а не половина предложения. Таблицы и списки требуют особого обращения.
2. Модель векторов. Должна хорошо работать с русским языком и вашей терминологией; проверяется на ваших вопросах, а не по рейтингам.
3. Сочетание с поиском по словам. Точные термины, артикулы и названия лучше находятся по словам; хорошие системы совмещают оба способа.
4. Метаданные и права. Откуда фрагмент, актуален ли он, кто может его видеть. Без прав ассистент покажет сотруднику чужую зарплатную ведомость.
5. Переранжирование. После поиска найденные фрагменты ещё раз оцениваются на соответствие вопросу; это заметно улучшает ответы.
6. Обновление. Регламент изменился — старый фрагмент должен исчезнуть. Процесс обновления важнее выбора базы.

Почему ответы бывают неверными даже при хорошей базе и как это диагностировать по шагам, разобрано в статье «Почему RAG отвечает неверно».

Типичные ошибки в проектах

• Загрузить всё подряд. Устаревшие версии, черновики, дубли. Поиск находит противоречащие фрагменты, ответ получается неверным. Сначала порядок в документах.
• Выбрать базу по моде. Специализированная система там, где хватило бы расширения обычной базы, и наоборот.
• Забыть про права. Все документы в одном индексе без меток доступа.
• Не проверять на своих вопросах. Демонстрация на чужих данных ничего не говорит о ваших регламентах.
• Нет процесса обновления. Через полгода ассистент отвечает по старым правилам.
• Ожидать, что база заменит структурированные данные. Остатки и цены — в 1С, не в векторах.

Как проверить, нужна ли вам векторная база

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

Пример: база знаний сервисной компании

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

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

Сколько это стоит

Сама векторная база редко является отдельной статьёй сметы: она часть агента, отвечающего по документам. Стоимость определяется объёмом и состоянием документов, требованиями к правам и к контуру. Ассистент по базе знаний для одного отдела начинается от 200 000 ₽ после аудита за 50 000 ₽ с зачётом; для всей компании с правами по ролям и несколькими источниками — от 800 000 ₽; установка в контуре — от 1 000 000 ₽. Подробности на странице корпоративный ИИ-ассистент и в статье «Сколько стоит AI-агент».

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

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