Пусть точные термины и значение совместно способствуют поиску.
Соедините списки лексических и семантических кандидатов, не рассматривая некомпатибельные оценки поиска как взаимозаменяемые.
Разработчик, ищущий ERR_CACHE_STALE, ожидает соответствующий код ошибки. Другой разработчик может описать ту же проблему как «приложение продолжает отображать данные вчерашнего дня». Эффективный поиск информации должен обрабатывать оба вида запросов.
Лексический поиск полезен, когда точное написание слов несет информационную ценность. Семантический поиск позволяет связывать разные описания одной идеи. Сочетание обоих методов дает каждому из них возможность найти доказательства, которые упускает другой.
Решение о том, где произойдет это сочетание, принимается на этапе проектирования.
Предоставьте каждому поисковику доступ к корпусу
Предположим, семантический поиск находит двадцать кандидатов, после чего лексический оценщик сортирует их. Это может улучшить порядок кандидатов, но точное совпадение вне первых двадцати останется незамеченным.
Для более полного охвата кандидатов применяйте оба метода поиска к соответствующему корпусу данных и объединяйте полученные результаты. В обоих случаях используйте одни и те же правила отбора и фильтры. Документ, исключенный из-за неопределенности его идентичности, не должен снова попасть в результаты поиска с помощью второго метода.
Это напрямую основано на инвентаризации источников: поиск должен осуществляться на основе доказательств, которые вы готовы использовать.
Объединяйте рейтинги до того, как применять арифметику оценок
Оценка BM25 и коэффициент косинусного сходства отражают разные расчеты. Их прямое сложение дает числовое значение, но это число само по себе не означает комбинированную степень релевантности.
Метод слияния рейтингов по принципу взаимности представляет собой простую основу. Каждый рейтинговый список вносит свой вклад, основанный на позиции кандидата:
fused_score(document) = sum(1 / (c + rank_in_list))
Рейтинги начинаются с одного. Список не вносит никакого вклада в документ, который он не извлек. Положительная константа c определяет степень резкости изменения вклада между позициями.
Преимущество заключается в операционной простоте: для объединения не требуется, чтобы масштабы оценок совпадали. Недостаток — потеря информации о величине оценки. Два соседних результата получают схожий вклад, даже если один из поисковиков считал их сильно разными.
Храните константы и количество кандидатов в настройках, затем оценивайте их. Это выборы при проектировании, а не гарантии релевантности.
Удаление дубликатов по идентификатору, а не по названию
Два поисковика могут вернуть один и тот же фрагмент. Объедините этот фрагмент по его стабильному идентификатору, чтобы оба рейтинга влияли на одного кандидата. Не считайте его двумя независимыми доказательствами.
Названия являются слабыми идентификаторами. Разные статьи могут иметь одинаковые названия, а название одной статьи может измениться. Полезный ключ фрагмента включает идентификатор источника, версию контента и местоположение фрагмента.
Также необходимо различать полные дубликаты и фрагменты, находящиеся рядом в одном разделе. Последние могут потребовать объединения позже, как описано в методе разбиения на фрагменты для сохранения доказательств.
Тестируйте типы запросов отдельно
Используйте по меньшей мере три группы вопросов: точные идентификаторы, концептуальные описания и их комбинации. Сравнивайте результаты работы только лексического поиска, только семантического поиска и объединенного варианта.
Перед оценкой качества ответов проверьте, достигают ли релевантные доказательства пула кандидатов. Если объединение помогает при концептуальных запросах, но ухудшает результаты при запросах с точными кодами ошибок, общий средний показатель может скрыть серьезное ухудшение качества.
Небольшая техническая библиотека может уже хорошо справляться с лексическим поиском. Добавьте семантический поиск, если количество неудачных поисков оправдывает это. Сохранение лексического базового уровня также позволяет оценить ценность дополнительных механизмов.
Передайте полезный список далее
Функция слияния данных генерирует список кандидатов, а не фактическое суждение. Документ с высоким рейтингом может всё ещё быть устаревшим, неполным или не соответствовать важному критерию в задании.
На следующем этапе можно переоценить кандидатов с использованием более сильного сигнала релевантности. Однако ни один последующий этап ранжирования не сможет спасти доказательства, которые так и не попали в список кандидатов. Сначала измерьте степень охвата кандидатами; в противном случае вы можете оптимизировать порядок неверных материалов.