Поиск по смыслу: когда векторная база окупается, а когда это лишний слой

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

Обычный поиск ищет слова. Вы вводите "рассрочка", он находит документы, где написано "рассрочка". Если в документе написано "оплата частями", вы его не найдёте.

Векторный поиск работает иначе. Каждый кусок текста заранее превращается в набор чисел, описывающий его смысл, и складывается в специальную базу. Запрос превращается в такой же набор чисел, и система ищет ближайшие по смыслу. "Оплата частями" и "рассрочка" оказываются рядом, хотя ни одна буква не совпадает.

Отсюда и область применения: он нужен там, где одно и то же говорят разными словами.

Лучше всего я видел это на закрытой платформе, где участники ищут друг друга под конкретный запрос - "кто у нас разбирается в логистике для маркетплейсов". Профили заполнены свободным текстом, каждый пишет о себе как умеет. Никакой фильтр по полям тут не работает, а поиск по смыслу работает.

Обращения и заявки. "Не приходит письмо со ссылкой", "не могу подтвердить почту", "не активируется аккаунт" - это одна проблема, описанная тремя людьми. Поиск по смыслу связывает их с одной инструкцией.

Внутренние документы и регламенты. Классический случай: сотрудник задаёт вопрос человеческим языком, а ответ лежит в регламенте, написанном канцеляритом.

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

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

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

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

Самое неочевидное для тех, кто внедряет впервые.

Логика подсказывает: чем больше подходящих фрагментов мы отдадим модели, тем полнее будет ответ. На практике наоборот. Мы снижали количество подтягиваемых фрагментов с 25-31 до 15, а в одном процессе - с 60 до 20. Расход на модель упал пропорционально, а ответы хуже не стали - правда, замера качества до и после у меня нет, только наблюдение.

Дальше - моё объяснение, а не измеренный факт. Пятнадцать фрагментов, из которых три релевантны, - это три полезных куска и двенадцать отвлекающих. Модель тратит внимание на мусор и иногда цепляется за него в ответе.

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

Нарезка документов. Главный рычаг качества и место, где обычно всё портится. Если резать текст механически по количеству символов, таблица разъедется пополам, а пункт регламента потеряет заголовок и станет бессмысленным. Резать надо по смысловым границам, а к каждому куску добавлять контекст: из какого документа, из какого раздела.

Устаревание замечают последним. Данные меняются, а индекс - нет: регламент обновили, а бот полгода отвечает по старой редакции и делает это уверенно. Нужен процесс переиндексации, который запускается при изменении документа.

Это данные, которые живут только внутри неё: если базу снесёт при обновлении, из репозитория она не вернётся - индекс придётся собирать заново по всем документам, а это время и повторный счёт за модель. Поэтому автоматическое обновление таких сервисов у нас выключено намеренно: одно неаккуратное движение может пересоздать хранилище пустым.

Оценка качества. Без набора реальных вопросов с проверенными ответами вы не отличите хорошую настройку от плохой. Сорок вопросов, собранных у сотрудников, - это полдня работы, и они окупаются на первой же итерации.

Посчитайте на своих цифрах. Пятеро сотрудников по часу в день ищут ответ в регламентах и переспрашивают друг друга - это 100 часов в месяц, при ставке 500 рублей в час 50 000 рублей. Поиск по смыслу снимает не всё, но большую часть. Отдельно экономит настройка: пятнадцать фрагментов вместо тридцати - вдвое меньший счёт за модель на каждом вопросе.