Короткий ответ: на объёмах малого и среднего бизнеса отдельное векторное хранилище почти никогда не нужно. Расширение pgvector к той PostgreSQL, которая у вас уже работает и уже кем-то администрируется, закрывает задачу до примерно миллиона фрагментов. Типовая корпоративная база регламентов и договоров — это две-три тысячи фрагментов, то есть в сотни раз меньше порога.
Путаница возникает потому, что в презентациях векторное хранилище рисуют отдельным кубиком архитектуры, а рядом ставят название специализированного продукта. Кубик действительно есть, но у него есть и второй, менее заметный ценник: отдельная база — это отдельный сервер, отдельные резервные копии, отдельные обновления и отдельный человек, который умеет всё это чинить в пятницу вечером.
Ниже — что хранилище делает и чего не делает, где проходит порог перехода на специализированное решение, во что обходится владение отдельной базой и четыре вопроса, которые стоит задать подрядчику до подписания. Механику самого поиска мы разбирали в материале про эмбеддинги и векторный поиск — здесь речь только про место, где эти векторы лежат.
Единственная задача хранилища
Место, где лежат числовые представления фрагментов текста вместе с самими фрагментами и их полями — источником, датой, подразделением. Умеет ровно одно: получив вектор вопроса, быстро вернуть несколько ближайших к нему фрагментов. Для этого оно строит специальный индекс, чтобы не перебирать все записи подряд.
Из этого определения следует важное: на качество ответов выбор хранилища почти не влияет. Оно не решает, как порезаны документы, не знает, какая редакция приказа действует, и не понимает вашу отраслевую лексику. Все три вещи определяют, найдётся нужный фрагмент или нет, и все три относятся к подготовке базы знаний, а не к инфраструктуре. Хранилище отвечает лишь за то, чтобы поиск занимал десятки миллисекунд, а не секунды.
Горизонтальная схема из четырёх блоков со стрелками: «Вопрос сотрудника» → «Модель эмбеддингов» → «Хранилище: 2 000 фрагментов и индекс» → «Пять ближайших фрагментов». Под третьим блоком подпись «десятки миллисекунд». Снизу отдельной группой три блока, соединённых с третьим пунктирными линиями и подписанных «нарезка», «метаданные», «актуальность редакций», над ними общая подпись «то, от чего зависит правильность ответа — не здесь». Чертёжный стиль, подписи по-русски.
pgvector: расширение к той базе, которая уже работает
pgvector — расширение к PostgreSQL, то есть не новая система, а дополнительный тип данных и индекс в уже существующей. Устанавливается администратором за полчаса, векторы лежат в обычной таблице рядом с текстом фрагмента и его полями, поиск делается тем же запросом, что и фильтрация по подразделению или дате. Последнее важнее, чем кажется: фильтр по метаданным до поиска — самый дешёвый способ поднять точность выдачи, и в единой базе он делается одной строкой условия.
| Что нужно проекту | pgvector в вашей PostgreSQL | Отдельная векторная база |
|---|---|---|
| Поиск похожих фрагментов | Есть, скорость достаточна до сотен тысяч записей | Есть, оптимизирован под миллионы и десятки запросов в секунду |
| Фильтр по подразделению, типу, дате | Обычное условие в том же запросе | Отдельный механизм фильтрации, возможности зависят от продукта |
| Резервное копирование | Попадает в существующий бэкап базы без отдельной настройки | Собственный бэкап, собственная проверка восстановления |
| Обновления и совместимость | В общем цикле обновления PostgreSQL | Свой цикл версий, свои несовместимости, свои окна простоя |
| Кто администрирует | Тот же человек, который уже ведёт базу | Нужен человек, знающий именно этот продукт |
| Дополнительная стоимость владения | Практически ноль сверх текущей базы | Около 26 000 ₽ в месяц |
Отдельный плюс единого хранилища — целостность. Когда текст фрагмента, его вектор и его метаданные лежат в одной таблице, они физически не могут разъехаться. В схеме с двумя базами рассинхронизация — штатная авария: документ обновили в одной, вектор остался старым в другой, и система начинает уверенно отвечать по редакции, которой больше нет.
У расширения есть и границы, о которых честно сказать проще, чем потом объяснять. Индекс приблизительного поиска надо строить и изредка перестраивать после крупных пополнений — это несколько минут работы администратора, но про них надо знать. Тяжёлый поиск идёт на том же сервере, что и учётные запросы, поэтому при потоке в десятки запросов в секунду соседство начинает мешать обеим сторонам. И горизонтального масштабирования «в несколько узлов из коробки» здесь нет: когда объём действительно вырастет, переезжать придётся. Все три ограничения проявляются за порогом, а не до него.
Порог перехода: три числа, а не ощущение
Специализированное хранилище берут, когда перестаёт хватать одного из трёх ресурсов. Пока ни один из порогов не пройден, переход даёт только расходы.
- Объём — примерно от 1 000 000 фрагментов. Для ориентира: база из 380 документов, на которой мы считаем примеры в этом разделе, даёт около 2 000 фрагментов. Миллион — это архив крупного предприятия или маркетплейсный каталог, а не регламенты компании на 140 человек.
- Частота — устойчиво больше 10 запросов в секунду. Не пиковая за день, а средняя в час нагрузки. Внутренний ассистент на 6 000 обращений в месяц даёт около 0,1 запроса в секунду в рабочее время — на два порядка меньше.
- Задержка — требование быстрее 50 миллисекунд на поиск. Возникает в голосовых сценариях и в подсказках, которые всплывают по мере набора текста. В переписке и в чате разница между 40 и 150 миллисекундами не заметна никому, потому что сама модель отвечает секунды.
Свой объём считается за пять минут и до всякого проекта. Возьмите число документов, умножьте на среднее число страниц и разделите примерно на одну страницу А4 — столько занимает типовой фрагмент в 300–800 слов. Для 380 регламентов по 5–6 страниц получается около 2 000 фрагментов; для архива договоров в 10 000 файлов по 12 страниц — около 120 000. Точность такой прикидки в пределах двух раз, и этого достаточно: пороги отстоят друг от друга на порядки, а не на проценты. Если в результате вы получили меньше 100 000, разговор об отдельном хранилище можно закрывать сразу.
Горизонтальная логарифмическая шкала числа фрагментов от 1 000 до 10 000 000 с отметками: «2 000 — база из 380 документов», «120 000 — архив договоров, 10 000 файлов», «300 000 — весь документооборот среднего предприятия», «1 000 000 — порог перехода на отдельное хранилище». Область слева от порога затонирована и подписана «достаточно pgvector», справа — «отдельная база оправдана». Под шкалой вторая строка с подписями частоты: «0,1 запроса в секунду — внутренний ассистент», «10 запросов в секунду — порог». Чертёжный стиль.
Стоимость владения: почти ноль против 312 000 ₽ в год
Цена отдельной базы — не лицензия: большинство продуктов этого класса бесплатны в базовом варианте, и именно поэтому их так легко ставят в архитектуру. Деньги начинаются после запуска и складываются из инфраструктуры и человеческого времени.
Сравнение полезно проводить не с нулём, а с альтернативным использованием тех же денег. 312 000 ₽ в год — это две недели работы по перенарезке базы и устранению противоречий в документах плюс годовое ведение базы знаний предметным специалистом. По нашему опыту вторая корзина даёт заметный прирост попаданий, а первая — не даёт никакого: скорость поиска в типовой корпоративной базе и так не является узким местом.
Четыре вопроса подрядчику
- 1«Где физически лежат векторы?»
Ответ должен называть конкретную базу и площадку: «в вашей PostgreSQL на том же сервере» или «в отдельном узле у такого-то провайдера». Настораживает формулировка «в облаке платформы» без уточнения страны размещения — вопрос о том, куда уходят данные, разбирается отдельно в материале про приватность запросов к модели.
- 2«Кто и куда их бэкапит?»
Если хранилище отдельное, оно почти наверняка не попадает в существующий бэкап учётного контура. Хороший ответ содержит расписание, место хранения копий и дату последней проверки восстановления. Ответ «векторы можно пересчитать» верен только на маленькой базе — на большой это часы простоя и отдельные деньги.
- 3«Что произойдёт при смене модели эмбеддингов?»
Правильный ответ: вся база пересчитывается, старые и новые векторы несовместимы. На 2 000 фрагментов это около 48 ₽ на сами эмбеддинги и несколько часов работы; на 1 000 000 — уже порядка 24 000 ₽ и сутки-двое с окном переиндексации. Настораживает ответ «просто поменяем модель» — он означает, что человек этого не делал.
- 4«Кто администрирует это после сдачи проекта?»
Самый неудобный и самый важный вопрос. Если ответ «мы, в рамках поддержки» — уточните, что происходит при расторжении договора и остаётся ли у вас инструкция по восстановлению. Что должно входить в передачу системы, разобрано в материале про передачу системы в эксплуатацию.
Сравнение двух схем рядом. Слева «Единая база»: один прямоугольник PostgreSQL, внутри три подписанные строки «текст фрагмента», «вектор», «метаданные», снизу подпись «бэкап и обновления — общие, 0 ₽ сверху». Справа «Две базы»: прямоугольник PostgreSQL с текстом и метаданными, отдельный прямоугольник «векторное хранилище» с векторами, между ними стрелка синхронизации с восклицательным знаком и подписью «документ обновили здесь, вектор остался там». Под правой схемой подпись «отдельный бэкап, отдельные обновления, 26 000 ₽/мес». Чертёжный стиль.
Когда отдельная база действительно нужна, а когда точно нет
Честный список в обе стороны. Сначала случаи, в которых специализированное хранилище оправдано и мы сами его предлагаем.
- Каталог товаров с поиском по описаниям и картинкам от миллиона позиций — типичная задача для интернет-магазинов и маркетплейсов, где объём и частота проходят оба порога сразу.
- Публичный сервис с непредсказуемым потоком запросов, где всплеск нагрузки не должен затрагивать учётную базу компании.
- Готовая платформа, где хранилище уже встроено и отдельно не оплачивается: у Yandex AI Studio это Vector Store и AI Search, у GigaChat Enterprise — собственный контур. Здесь выбор сделан за вас, и спорить с ним смысла нет.
И обратная сторона — четыре ситуации, в которых отдельная база не нужна, а её появление в смете стоит обсудить отдельно.
- База меньше 100 000 фрагментов. Это подавляющее большинство корпоративных внедрений. Разница в скорости поиска на таком объёме измеряется единицами миллисекунд и полностью теряется на фоне времени ответа модели.
- У вас уже есть PostgreSQL и человек, который её ведёт. Добавить расширение дешевле, чем завести новую систему и нового ответственного за неё.
- Основные жалобы — на неправильные ответы, а не на скорость. Это признак того, что деньги нужны в документах и настройке поиска: типичные причины разобраны в материале про то, почему поиск по базе знаний ошибается.
- Проект на стадии пилота. До того как понятно, дойдёт ли система до эксплуатации, любая отдельная инфраструктура — это расход без проверенной пользы. Хранилище всегда можно перенести позже: данные переносятся, а векторы пересчитываются.
Общее правило, которое экономит больше всего: выбор хранилища — последнее решение в проекте, а не первое. Сначала документы, нарезка и метаданные, потом настройка поиска, и только затем разговор о том, где всё это лежит. Обратный порядок встречается часто и почти всегда означает, что архитектуру рисовали до знакомства с вашей базой.
