01 Простыми словами
Поиск по ключевым словам отлично находит точный номер детали или код документа, но плохо справляется, если запрос сформулирован своими словами. Семантический поиск хорошо ловит смысл, но иногда промахивается мимо точного номера или редкого технического кода. Гибридный поиск запускает оба способа сразу и объединяет результат.
02 Как это работает
Технически система параллельно прогоняет запрос через два независимых механизма и потом сводит результаты воедино.
- Один механизм ищет по ключевым словам и точным совпадениям — коды деталей, номера документов, редкие технические термины.
- Второй механизм ищет по смыслу через векторное сравнение — формулировки своими словами, синонимы, похожие по теме случаи.
- Результаты обоих механизмов объединяют и заново ранжируют по общей релевантности — эту финальную сортировку часто доверяют отдельному reranker, который сверяет оба списка и выстраивает единый порядок.
03 Где применяется
- Производство. Поиск по номеру детали и по описанию неисправности работает в одной системе сразу — оператор может ввести и точный код, и описание неисправности своими словами.
- Логистика. Поиск по номеру накладной и по содержанию груза одновременно ускоряет разбор спорной поставки.
- Юристы. Поиск по номеру статьи закона и по смыслу спорного пункта работает в одном запросе без выбора между двумя разными инструментами.
- Поддержка клиентов. Поиск по артикулу товара и по описанию проблемы клиента одновременно находит нужную инструкцию быстрее, чем любой из двух способов по отдельности.
- Бухгалтерия. Поиск по номеру счёта и по содержанию операции сразу упрощает сверку при неполных исходных данных.
- HR. Поиск по номеру приказа и по описанию ситуации сотрудника работает в одном запросе без переключения между базами.
04 Три вопроса технического директора
Технический директор производственной компании перед внедрением гибридного поиска по базе регламентов задаёт интегратору три вопроса — и получает три развёрнутых ответа.
Какой вес дать точному поиску по коду детали? Вес считают по реальным запросам за последний месяц вместо оценки на глаз: если среди них треть содержит точный код или номер документа, поиск по ключевым словам получает заметно больший вес, чем в компании, где сотрудники почти всегда формулируют вопрос своими словами.
Нужен ли отдельный reranker? Пока противоречий между двумя списками результатов немного, простое правило сортировки справляется само; reranker имеет смысл подключать, когда два механизма регулярно выдают разный порядок для одного и того же запроса и простое правило перестаёт покрывать все случаи.
Как логировать оба списка результатов? Каждый механизм пишет свой список отдельно, с меткой источника у каждой строки, — так при жалобе на неверный результат видно, какой из двух механизмов его предложил и на каком месте, вместо разбора уже смешанного финального списка.
05 Ограничения и ошибки
- Два параллельных механизма поиска сложнее в поддержке и медленнее одного — включать гибридную схему стоит только при доказанной необходимости обоих типов запросов.
- Неправильный баланс весов между двумя механизмами портит результат сильнее, чем любой из механизмов по отдельности, — вес стоит настраивать на реальных примерах вместо приблизительной прикидки на глаз.
- Для документов, разбитых на слишком мелкие или слишком крупные куски, качество обоих механизмов страдает одинаково — базовое разбиение на куски стоит проверять в первую очередь, до настройки весов между способами поиска.
- Финальное ранжирование результата от двух источников — отдельная сложная задача, которую эффективнее доверить готовому reranker-инструменту вместо ручных правил склейки списков.
- Гибридная схема без явного лога, какой механизм дал каждый конкретный результат, тяжело отлаживается — держите оба списка отдельно хотя бы для внутренней проверки.
Как выстроить поиск по базе знаний для конкретного отдела — в статье про бота по базе знаний для автосервиса. Как оценить архитектуру поиска под масштаб компании — в разделе про нейросети для документов.