Поиск по смыслу: когда векторная база окупается, а когда это лишний слой
"Нам нужна база знаний, чтобы бот отвечал по нашим документам" - за этой фразой стоит векторный поиск. Разбираю, где он окупается, где вместо него нужен обычный запрос, и почему уменьшение числа найденных фрагментов с 30 до 15 улучшило ответы и удешевило работу.
Каждый второй разговор про ИИ в компании рано или поздно приходит к фразе "нам нужна база знаний, чтобы бот отвечал по нашим документам". За этой фразой стоит конкретная технология - векторный поиск, он же поиск по смыслу. Иногда он решает задачу целиком. Иногда это дорогой способ сделать хуже, чем обычный фильтр в базе данных.
Разберу, чем он отличается от привычного поиска, где выигрывает, и что ломается при внедрении - на том, что видел в проде.
В чём разница
Обычный поиск ищет слова. Вы вводите "рассрочка", он находит документы, где написано "рассрочка". Если в документе написано "оплата частями", вы его не найдёте.
Векторный поиск работает иначе. Каждый кусок текста заранее превращается в набор чисел, описывающий его смысл, и складывается в специальную базу. Запрос превращается в такой же набор чисел, и система ищет ближайшие по смыслу. "Оплата частями" и "рассрочка" оказываются рядом, хотя ни одна буква не совпадает.
Отсюда и область применения: он нужен там, где одно и то же говорят разными словами.
Где он реально окупается
Люди и их описания. Задача, на которой я это видел лучше всего: закрытая платформа, где участники ищут друг друга под конкретный запрос - "кто у нас разбирается в логистике для маркетплейсов". Профили заполнены свободным текстом, каждый пишет о себе как умеет. Никакой фильтр по полям тут не работает, а поиск по смыслу работает.
Обращения и заявки. "Не приходит письмо со ссылкой", "не могу подтвердить почту", "не активируется аккаунт" - это одна проблема, описанная тремя людьми. Поиск по смыслу связывает их с одной инструкцией.
Внутренние документы и регламенты. Классический случай: сотрудник задаёт вопрос человеческим языком, а ответ лежит в регламенте, написанном канцеляритом.
Где он не нужен
Здесь я обычно останавливаю разговор на входе, потому что векторную базу часто просят там, где нужен обычный запрос.
Всё, что описывается точными признаками, надо искать обычными средствами: заказы за период, клиенты из города, договоры на сумму больше миллиона, товар с артикулом. Смысл тут ни при чём, а нечёткий поиск по числам и датам даёт нечёткие результаты - что как раз плохо.
Правильная схема почти всегда гибридная: сначала обычные фильтры сужают выборку по точным признакам, потом поиск по смыслу ранжирует то, что осталось. Порядок именно такой - он и точнее, и дешевле.
И отдельно: если ваши документы - это пятнадцать страниц регламента, векторная база не нужна. Современная модель прочитает их целиком за один запрос. Технология начинает окупаться, когда документов сотни и в контекст они не помещаются.
Больше найденного - хуже ответ
Самое неочевидное для тех, кто внедряет впервые.
Логика подсказывает: чем больше подходящих фрагментов мы отдадим модели, тем полнее будет ответ. На практике наоборот. Мы снижали количество подтягиваемых фрагментов с 25-31 до 15, а в одном процессе - с 60 до 20. Расход на модель заметно упал, а качество ответов не изменилось.
Причина понятна, если посмотреть на это глазами модели. Пятнадцать фрагментов, из которых три релевантны, - это три полезных куска и двенадцать отвлекающих. Модель тратит внимание на мусор и иногда цепляется за него в ответе. Меньше, но точнее - лучше, чем много и приблизительно.
Практический вывод: количество фрагментов - это настройка, которую надо подбирать замером на реальных вопросах, а не ставить "побольше, на всякий случай".
Что ломается при внедрении
Нарезка документов. Главный рычаг качества и место, где обычно всё портится. Если резать текст механически по количеству символов, таблица разъедется пополам, а пункт регламента потеряет заголовок и станет бессмысленным. Резать надо по смысловым границам, а к каждому куску добавлять контекст: из какого документа, из какого раздела.
Устаревание. Данные меняются, а индекс - нет. Регламент обновили, а бот полгода отвечает по старой редакции и делает это уверенно. Нужен процесс переиндексации, привязанный к изменению документа, а не к календарю.
Векторная база - это состояние. Её содержимое не восстанавливается из репозитория, как код. У нас автоматическое обновление таких сервисов сознательно выключено: любое неаккуратное движение может пересоздать хранилище и потерять данные. Плата за это - нужно помнить о ручном шаге при развёртывании; один раз про него забыли, и сервис неделю висел без единого работающего экземпляра. Тихо, разумеется.
Оценка качества. Без набора реальных вопросов с проверенными ответами вы не отличите хорошую настройку от плохой. Сорок вопросов, собранных у сотрудников, - это полдня работы, и они окупаются на первой же итерации.
Что забрать себе
- Векторный поиск нужен там, где одно и то же называют разными словами. Для точных признаков используйте обычный запрос.
- Гибрид почти всегда лучше: сначала фильтры, потом смысл.
- Если документов десятки, а не сотни, отдайте их модели целиком и не стройте инфраструктуру.
- Больше найденных фрагментов - не лучше. Подбирайте количество замером, обычно оптимум ниже, чем кажется.
- Заложите переиндексацию при изменении документов. Уверенно отвечающий по старой редакции бот хуже, чем отсутствие бота.
- Сделайте набор контрольных вопросов до внедрения, а не после.
Новые разборы - на почту
Разборы задач автоматизации: что автоматизировать, сколько это стоит и что даёт в цифрах. Одно письмо на статью, без рекламы чужих продуктов.
