Векторную базу обычно ставят раньше, чем формулируют задачу поиска. Логика такая: если в системе есть языковая модель, значит нужен поиск по смыслу, а для поиска по смыслу нужна специальная база. Каждый шаг по отдельности выглядит разумно, вместе они дают инфраструктуру, которую потом никто не может обосновать.
Ниже модель расчёта в часах и деньгах, куда подставляются ваши значения. Считать её можно до того, как что-то поднято.
Тупик: сравнить качество поиска на примерах
Первое, что пробуют, — взять десяток запросов, прогнать через обычный текстовый поиск и через векторный, сравнить выдачу. Векторный почти всегда выигрывает: он находит документ, где нужное сказано другими словами.
Не помогает это по двум причинам.
Демонстрация построена на запросах, которые придумал тот, кто её делает, — а придумывает он ровно те случаи, где ожидает выигрыша. Реальные запросы пользователей распределены иначе: значительная их часть — точные названия, коды, артикулы, фамилии, — то есть именно то, где текстовый поиск сильнее, а векторный уверенно возвращает похожее, но не то.
И главное: сравнивается качество, а решение принимается про деньги и часы. Векторный поиск может выигрывать и всё равно не окупаться.
Что считать
Обе стороны имеют цену — считайте симметрично.
Разовые часы на векторную базу. Развернуть или подключить сервис. Выбрать модель векторизации и зафиксировать её. Написать конвейер: разбиение документов на фрагменты, векторизация, загрузка. Написать переиндексацию — она понадобится при любой смене модели или схемы разбиения. Связать поиск с исходными документами, чтобы показывать пользователю не фрагмент, а место.
Регулярные часы. Следить за расхождением индекса с источником. Обновлять при изменении документов. Разбирать жалобы вида «нашлось не то» — они принципиально тяжелее, чем в текстовом поиске, потому что объяснить, почему выдался этот фрагмент, нельзя без отдельного расследования. Переиндексировать при смене модели.
Деньги. Хранение векторов, вычисления при векторизации нового и изменённого, вычисления при каждом запросе. Отдельно — стоимость первичной векторизации всего корпуса, которая повторяется при каждой переиндексации.
Скрытая строка: привязка к модели векторизации. Векторы, посчитанные одной моделью, несопоставимы с векторами другой. Смена модели — это не обновление зависимости, а полная переиндексация корпуса с простоем поиска или с параллельным индексом. Заложите это как регулярное событие, а не как исключительное: модели меняются чаще, чем схемы баз данных.
Цена альтернативы. Полнотекстовый поиск в базе, которая у вас уже есть, тоже не бесплатен: настройка морфологии, синонимы, ранжирование, поддержка. Но большая часть этих часов — разовые, а регулярных почти нет.
Выгода. Считается не в качестве выдачи, а в поведении: сколько запросов сейчас заканчиваются ничем и сколько из них закончились бы находкой при поиске по смыслу.
Где проходит граница
Соотношение, которое обычно определяет ответ: векторная база окупается, когда пользователи ищут формулировками, а не названиями.
Вопросы своими словами, описания проблем, запросы на естественном языке, поиск похожего документа по образцу — здесь текстовый поиск проваливается системно, и никакие синонимы этого не чинят.
Названия, коды, идентификаторы, фамилии, точные фразы из документа — здесь векторный поиск не просто не нужен, он мешает: возвращает похожее вместо точного, и пользователь считает это ошибкой.
Второй признак — размер корпуса. На небольшой базе документов разница в качестве почти не проявляется: пользователь всё равно просматривает выдачу целиком. Векторный поиск начинает окупаться там, где выдачу глазами не проверить.
Третий — частота изменений. Корпус, который меняется ежедневно, делает конвейер векторизации постоянной работой. Корпус, который меняется раз в квартал, снимает почти всю регулярную часть расходов.
Промежуточный вариант, который пропускают
Между полнотекстовым поиском и отдельной векторной базой есть путь, который часто закрывает задачу целиком: расширение поиска в той базе, где данные уже лежат. Современные реляционные и документные базы умеют хранить векторы и искать по ним рядом с обычными условиями.
Это дешевле по всем строкам: не нужен второй источник правды, не нужна синхронизация, права и резервные копии остаются одни. Проигрыш появляется на больших объёмах и высокой частоте запросов — но проверить, достаточно ли этого, стоит первым, а не последним.
Второй промежуточный вариант — гибрид: текстовый поиск как основа, векторный как дополнение для запросов, где текстовый ничего не нашёл. Он даёт большую часть выгоды при меньшей части расходов и, что важнее, оставляет точные запросы работать точно.
Как посчитать за две недели
Расчёт не требует прототипа. Он требует журнала запросов, который у вас, скорее всего, уже есть.
Первую неделю разметьте поток поисковых запросов на три корзины: точные (название, код, идентификатор), формулировки своими словами и всё остальное. Разметка грубая, руками, по выборке — точность здесь не нужна, нужен порядок величины. Соотношение первых двух корзин отвечает на главный вопрос почти целиком.
Одновременно посчитайте, сколько запросов заканчивается пустой выдачей или уходом без перехода. Это ваша верхняя граница выгоды: больше, чем эти запросы, векторный поиск не спасёт, а спасёт он из них только часть.
Вторую неделю потратьте на оценку внедрения по своей инфраструктуре: разовые часы, регулярные часы, деньги за хранение и вычисления. Считайте по тому, как у вас реально проходит эксплуатация похожих систем, а не по описаниям в документации поставщика.
Дальше арифметика. Разделите разовые часы на недельную выгоду, выраженную в тех же часах — сэкономленное время пользователей плюс снятая нагрузка на поддержку. Если срок окупаемости выходит за полгода, решение стоит отложить: за это время изменится и корпус, и модели, и, вероятно, сама задача.
Чего расчёт не покажет
Он не учитывает качество разбиения документов на фрагменты — а именно оно чаще всего определяет, будет ли поиск по смыслу полезен. Плохо нарезанный корпус портит выдачу сильнее, чем выбор базы.
Он не учитывает, что вопрос «искать» иногда решается не поиском. Половина запросов к внутренним базам знаний — это попытка найти то, чего там нет; поиск любого качества на это ответит одинаково.
И он не заменяет разговор о том, кто отвечает за содержание корпуса. Индекс не делает документы актуальными.
Позиция редакции
Мы считаем, что отдельную векторную базу стоит заводить, когда поиск по смыслу — основной способ добраться до данных, а корпус большой и меняется редко. Практический вывод: сначала посчитайте регулярные часы на синхронизацию и переиндексацию, потом сравнивайте качество выдачи. Обратный порядок всегда даёт ответ «нужна».
Мы неправы, если поиск — это и есть ваш продукт: тогда качество выдачи не одна из строк расчёта, а сама выручка, и считать надо не окупаемость инфраструктуры, а то, сколько вы теряете на каждом неудачном запросе.