Гибридный поиск в базе знаний: точный артикул и смысловой вопрос

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

Гибридный поиск в базе знаний — это схема, где лексический и векторный каналы независимо находят кандидатов, затем результаты сводятся по рангам или нормализованным баллам, а генерация получает уже отранжированные фрагменты. Точный артикул требует повышенного веса лексики и отдельного поля; без тестов на точные, пустые и отрицательные запросы метод не даёт гарантий качества.

Когда артикул важнее смысла: как устроен гибридный поиск в базе знаний

Представим условную сцену: менеджер по продажам вводит в поисковую строку корпоративной базы знаний запрос «фильтр масляный 2105-1012005, есть ли у нас аналог под клиента из Казахстана». Система находит три документа: общий обзор ассортимента фильтров, инструкцию по подбору аналогов и старую карточку товара с похожим, но не тем артикулом. Точного совпадения по номеру нет, а самый релевантный по смыслу документ — регламент подбора — оказывается на четвёртом месте.

Механизм, который здесь ломается, — это попытка решить одну задачу одним инструментом. Лексический поиск хорошо ловит точные строки: артикулы, коды, названия регламентов, номера договоров. Векторный поиск хорошо ловит смысл: «аналог под клиента» без точного номера. Гибридный поиск — это не волшебная кнопка, а конкретная инженерная схема, где два разных способа найти кандидатов работают параллельно, а потом их результаты сводятся в один список до того, как языковая модель начнёт что-то сочинять. Именно на этом стыке — между «нашли кандидатов» и «сгенерировали ответ» — и живёт вся практическая ценность.

Если ваша задача — проверить гибридный поиск, на странице соответствующего направления 404ai можно посмотреть опубликованные возможности и оставить описание текущего процесса. Конкретные подключения, исходные данные и критерии приёмки согласуем отдельно.

Что именно смешивается: два независимых канала поиска

В основе гибрида лежат два канала, которые не заменяют друг друга, а дополняют. Первый — лексический: запрос разбивается на термы, и система ищет документы, где эти термы встречаются, с учётом частоты и длины поля. В Elasticsearch это реализуется через match query, которое анализирует текст запроса, а строгость совпадения термов задаётся параметрами operator и minimum_should_match (Elastic: Match query). Второй канал — векторный: и запрос, и документы превращаются в числовые представления, и система ищет ближайшие по смыслу.

Ключевое обстоятельство, которое часто упускают: у этих каналов разные единицы измерения релевантности. Лексический выдаёт условный балл на основе совпадений термов, векторный — расстояние в пространстве эмбеддингов. Складывать их напрямую нельзя, поэтому в гибридных схемах применяют либо объединение по рангам (например, RRF), либо нормализацию и взвешивание баллов. Microsoft в описании гибридного поиска в Azure AI Search указывает, что результаты векторного и лексического запросов объединяются через Reciprocal Rank Fusion (RRF) (Microsoft: Hybrid search). Это важно для нашей задачи: если мы хотим, чтобы точный артикул не тонул под смысловым соседом, вес лексического канала для запросов с цифровыми паттернами должен быть выше.

Третий элемент, который часто путают с самим поиском, — генерация ответа. Языковая модель получает уже отранжированный список фрагментов и формулирует текст. Если на вход попал нерелевантный фрагмент, модель честно перескажет нерелевантность. Поэтому оценка качества выдачи должна происходить до генерации, на уровне списка кандидатов, а не после того, как красивый абзац уже написан.

Совмещённая поисковая выдача: что мы на самом деле ищем

Прежде чем настраивать веса, стоит зафиксировать, что является единицей поиска. В базе знаний это не «документ» целиком, а фрагмент — чанк. Документ на сорок страниц, превращённый в один эмбеддинг, размывает смысл: в нём смешаны регламент, приложение и историческая справка. Microsoft отдельно описывает практику разбиения документов на чанки для векторного поиска, включая перекрытие соседних фрагментов (Microsoft: Chunk documents for vector search).

Рабочий объект гибридного поиска удобно представить таблицей, где у каждого фрагмента есть и текстовое содержимое, и вектор, и служебные поля. Служебные поля — это не бюрократия, а рычаги управления выдачей.

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

Три стадии, которые нельзя сливать в одну

Гибридный поиск полезно разложить на три стадии, у каждой свой набор тестов. Первая — поиск кандидатов: оба канала независимо возвращают свои топы. Вторая — слияние и ранжирование: кандидаты нормализуются, взвешиваются, отсекаются по фильтрам. Третья — генерация ответа по выбранным фрагментам.

Проблема в том, что на практике эти стадии часто оценивают одним взглядом «нравится/не нравится ответ». Если ответ плохой, непонятно, виноват ли поиск (не нашёл), ранжирование (нашёл, но не поднял) или генерация (нашёл, поднял, но пересказал криво). Раздельная оценка стадий — это не академическая строгость, а способ не чинить генерацию, когда сломан поиск.

Для каждой стадии имеет смысл держать свой маленький набор проверочных запросов. Не «сто вопросов от пользователей», а десяток целенаправленно сконструированных случаев: точный артикул, синоним без точного слова, пустой результат, устаревшая версия, короткий запрос из двух слов, запрос, который должен найти документ другого подразделения, и запрос, который не должен.

Эпизод первый: код модели и синоним в одном запросе

Условный пример. Компания торгует промышленными подшипниками. В базе знаний лежат: каталог с артикулами, регламент подбора аналогов, письма поставщиков и внутренняя таблица совместимости. Менеджер вводит: «подшипник 6205 закрытый, чем заменить у другого производителя».

Лексический канал цепляется за «6205» и находит карточки с этим номером — хорошо. Но слово «закрытый» в карточках может быть записано как «2RS», «с защитной шайбой» или вообще отсутствовать в тексте, оставаясь в характеристиках. Векторный канал по смыслу подтягивает регламент подбора аналогов и таблицу совместимости — тоже хорошо. Плохо становится на этапе слияния: если веса равные, регламент (длинный, богатый смыслом) может обогнать точную карточку с артикулом, потому что векторный балл у регламента высокий, а лексический балл у карточки не нормализован относительно длины.

Здесь и проявляется конкретное обстоятельство: для запросов, содержащих цифровой паттерн, похожий на артикул, вес точного совпадения должен повышаться, а не усредняться с остальными. Это не универсальное правило, а настраиваемый параметр, который проверяется на наборе тестовых запросов. Если после настройки точная карточка стабильно в топе, а регламент остаётся в тройке — значит, оба канала работают, и генерация получит и точные данные, и правило подбора.

Отдельно стоит проговорить, что извлечение артикулов в отдельное поле — это не разовая работа, а регулярный процесс. Новые карточки приходят с разными форматами номеров, и парсер, который вчера ловил «6205-2RS», сегодня может не поймать «6205 2RS» с пробелом. Тест на точные запросы должен включать варианты написания, иначе поле «артикул» тихо перестанет помогать.

Где коммерческая ссылка уместна, а где нет

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

Эпизод второй: пустой результат и устаревшая версия

Другой условный случай, из другой области. Юридический отдел, база знаний по типовым договорам. Сотрудник вводит: «штраф за просрочку поставки в рамочном договоре, редакция 2023».

Лексический канал ищет «штраф», «просрочку», «рамочный договор», «2023». Векторный — смысл про ответственность за задержку. Оба находят документы. Но в базе есть две редакции рамочного договора: 2022 и 2023, и обе содержат слово «штраф». Если поле версии не заполнено или фильтр по нему не применён, система честно вернёт обе, и генерация может смешать условия из разных редакций в одном ответе. Это не ошибка поиска — это ошибка модели данных: версия не была выделена в отдельное поле, и ранжирование не могло её учесть.

Второй сбой в этом же эпизоде — пустой результат. Запрос «неустойка за задержку оплаты в рамочном» может не найти ничего, если в документах используется только слово «пеня», а синонимический словарь не настроен. Гибридный поиск снижает вероятность пустоты за счёт векторного канала, но не устраняет её полностью: если в базе нет ни одного фрагмента, близкого по смыслу, векторный поиск тоже вернёт пусто или, что хуже, вернёт далёкий по смыслу документ с высоким баллом из-за особенностей эмбеддингов.

Отсюда практическое правило: пустой результат — это валидный исход, который нужно уметь показывать. Лучше честное «ничего не найдено, уточните запрос», чем уверенный ответ по нерелевантному фрагменту. И второе правило: устаревшие версии не удаляются, а помечаются статусом и фильтруются на этапе ранжирования, чтобы их можно было найти по прямому запросу «редакция 2022», но они не всплывали в общем потоке.

Совмещённая поисковая выдача: исключения и проверка условий

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

Первое исключение — краткий запрос. «Договор» из одного слова. Векторный канал на таком запросе почти бесполезен: эмбеддинг одного общего слова близок ко многим документам, и ранжирование становится шумным. Лексический канал тоже размыт: слово встречается везде. Здесь помогает не взвешивание, а подсказки: предложить уточнить, показать частые фильтры, ограничить зону поиска. Гибрид не спасает от неконкретного вопроса — он лишь честно показывает, что кандидатов слишком много.

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

Третье исключение — отрицательные запросы. «Что делать, если поставщик не прислал документы» — здесь слово «не» меняет смысл, а лексический поиск может проигнорировать отрицание, найдя документы про «поставщик прислал документы». Векторный канал обычно справляется лучше, но не гарантированно. Тестовый набор должен включать отрицания, иначе этот класс ошибок останется незамеченным.

Четвёртое — омонимия артикулов и обычных чисел. «2105» может быть артикулом и годом. Если поле артикула заполняется слишком агрессивно, поиск по году начнёт выдавать товарные карточки. Извлечение точных сущностей требует контекстных правил, а не регулярки «все цифры подряд».

Совмещённая поисковая выдача на экране сотрудника

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

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

Второй элемент интерфейса — возможность сузить поиск до генерации. Фильтры по подразделению, типу документа, дате — это не «продвинутые настройки для гиков», а способ сделать запрос конкретным. Краткий запрос «договор» с фильтром «отдел закупок, 2024» превращается в осмысленный.

Третий элемент — обратная связь. Кнопка «этот фрагмент нерелевантен» даёт материал для настройки весов и пополнения тестового набора. Без сбора таких сигналов команда настраивает поиск вслепую.

Как проверять: тесты до генерации и после

Проверка гибридного поиска — это не один тест, а слоёный пирог. Начните с того, что зафиксируйте эталонные пары «запрос — ожидаемый фрагмент» для каждого класса: точный артикул, синоним, пустой результат, устаревшая версия, краткий запрос, чужое подразделение, отрицание. Для каждой пары проверяйте отдельно: попал ли ожидаемый фрагмент в топ-10 кандидатов (поиск), попал ли он в топ-3 после ранжирования (слияние), и упомянут ли он в сгенерированном ответе (генерация).

Такая разбивка сразу показывает, где проблема. Если фрагмент не в топ-10 — чините поиск или извлечение полей. Если в топ-10, но не в топ-3 — чините веса и фильтры. Если в топ-3, но не в ответе — чините промпт генерации или формат подачи фрагментов.

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

Практикум: настройка весов на конкретном наборе

Возьмём другой пример, не про артикулы. Условная компания ведёт базу знаний по внутренним процессам: командировки, закупки, отпуска. Задача — сделать так, чтобы сотрудник, спрашивающий «как оформить командировку за границу», получал актуальный регламент, а не общий документ про командировки по России.

Шаг первый — соберите десять запросов, которые реально задают сотрудники, и для каждого отметьте ожидаемый фрагмент. Не «правильный ответ», а именно фрагмент-источник: пункт регламента, а не весь документ.

Шаг второй — прогоните запросы и посмотрите, где ожидаемый фрагмент в топе. Скорее всего, обнаружится, что «за границу» лексически не совпадает с «зарубежная командировка», и векторный канал тянет общий документ. Это сигнал, что нужен либо синонимический словарь, либо более мелкие чанки, где пункт про зарубежные поездки отделён от общего.

Шаг третий — настройте веса. Если точные термины важны (названия форм, коды), поднимите вес лексического канала. Если важнее смысл (перефразы), поднимите векторный. Не пытайтесь найти «идеальные» веса раз и навсегда: они зависят от корпуса и меняются при пополнении базы.

Шаг четвёртый — проверьте отрицательные и граничные случаи. Запрос «командировка» без уточнений не должен выдавать уверенный ответ про заграницу. Запрос про отпуск не должен находить командировочный регламент из-за слова «дни».

Шаг пятый — зафиксируйте набор тестов в репозитории и прогоняйте его при каждом изменении базы или настроек. Это скучно, но именно так настройка перестаёт быть вкусовой и становится проверяемой.

Что делать с генерацией, когда выдача уже хорошая

Даже при идеальном топ-3 генерация может ошибаться: смешивать пункты из разных редакций, добавлять то, чего нет в источниках, или терять отрицания. Здесь работают три приёма, не требующие магии.

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

Второй — требовать цитирования: каждый тезис в ответе должен ссылаться на конкретный фрагмент. Если тезис не на что сослаться, его не должно быть в ответе. Это дисциплинирует и модель, и проверяющего.

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

Границы метода: где гибрид не поможет

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

И он не даёт гарантий качества по названию метода. «Гибридный поиск» — это описание архитектуры, а не сертификат точности. Реальная точность зависит от корпуса, чанкинга, извлечения полей, весов и тестового набора — то есть от работы, которую никто не сделает за вас одним переключением настройки.

Один шаг проверки, с которого стоит начать

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

Смежный вопрос разобран отдельно: RAG-система: как ИИ находит ответ в ваших документах.