В поддержку приходит обычный вопрос.
«Что такое личный кабинет пользователя?»
В базе знаний — 4 862 страницы. Ответ там есть. Причём не один.
В первой статье объясняется, что это за раздел сайта, как в него войти и что в нём можно сделать. Во второй — устаревший список изменений сервиса. В третьей — длинная страница, где словосочетание «личный кабинет» встречается двадцать семь раз. В четвёртой — инструкция по восстановлению пароля, которая вообще называет его «профилем пользователя».
Поиск выбирает третью.
Он не сломан. Он честно нашёл больше совпадений.
И именно поэтому он опасен.
Человек, который откроет третью страницу, потратит время на чтение и вернётся с тем же вопросом. Человек, который попадёт в нужный раздел первой статьи, сразу поймёт, что это за раздел сайта и зачем он ему нужен. Главной для такого запроса должна стать именно первая статья. Разница между этими сценариями не в качестве текста и не в способности пользователя искать. Она в том, как система понимает документ.
Для человека документ никогда не был просто набором слов. Заголовок раздела «Личный кабинет: вход и возможности» означает одно. Упоминание тех же слов в архиве изменений — другое. Таблица с возможностями, адрес страницы и основной текст несут разные виды информации. Поисковая система должна замечать эту разницу, иначе она будет с одинаковой уверенностью выдавать инструкцию и её тень.
BM25F — один из ответов на эту проблему.
Когда документ перестал быть плоским текстом
Классические модели поиска долгое время работали с удобным упрощением: документ представлялся последовательностью слов. Система знала, что редкое слово обычно полезнее распространённого, а несколько совпадений лучше одного. Из этой логики выросла модель TF-IDF, оценивающая редкость слов, а затем BM25 — формула, которая помогает расставить найденные страницы по порядку.
BM25 добавила два важных ограничения. Повторение слова не должно бесконечно увеличивать уверенность в том, что страница нужна человеку: первое упоминание «личного кабинета» существенно, второе подтверждает тему, а двадцать седьмое уже не делает страницу в двадцать семь раз полезнее. Кроме того, длинный документ не должен выигрывать только потому, что в нём больше места для случайных совпадений.
Это сделало BM25 хорошей основой для полнотекстового поиска. Но по мере того как документы становились структурированнее, проявилось ограничение: BM25 умеет работать со словами, но сама по себе не знает, где именно они стоят.
Одна фраза — четыре разных сигнала
«личный кабинет» в названии страницы говорит о её теме.
«личный кабинет» в заголовке раздела указывает на тему конкретного фрагмента.
«личный кабинет» в таблице возможностей может быть одной из доступных опций.
«личный кабинет» в основном тексте может оказаться инструкцией, контекстом или случайным упоминанием.
Это не различие оформления. Для поиска это различие смысла.
Ошибка очевидного решения
Когда у документа появились структурные части, первое решение было почти неизбежным: посчитать совпадения отдельно для названия страницы, основного текста и адреса страницы, а затем сложить оценки. Названию дать коэффициент десять, основному тексту — один. В документации добавить к ним заголовок раздела, место раздела в оглавлении и имена важных объектов.
Звучит разумно. Но порядок вычислений имеет значение.
BM25 устроен так, что каждое следующее повторение добавляет всё меньше уверенности. Если сначала оценить каждую часть документа, а потом сложить готовые результаты, эта логика начинает работать иначе. Каждая часть успевает достичь своего предела отдельно, а система затем складывает их как независимые свидетельства.
Проблема не в весах. Проблема в том, на каком этапе поиска они появляются.
В 2004 году Stephen Robertson, Hugo Zaragoza и Michael Taylor описали более аккуратный путь в работе Simple BM25 Extension to Multiple Weighted Fields. Так появилась BM25F — расширение BM25 для документа, разделённого на части. Подробнее — в источнике 1.
Что меняет BM25F
BM25F сначала собирает совпадения из разных частей документа с учётом их веса и длины, а затем применяет нелинейное насыщение BM25 к общему сигналу.
В упрощённом виде это выглядит так:
Для каждого слова в запросе:
общий сигнал =
название страницы × его вес
+ заголовок раздела × его вес
+ названия объектов × их вес
+ основной текст × его вес
Затем общий сигнал проходит через насыщение BM25.В полной формуле для каждой части документа есть собственная поправка на длину. Это важно: название страницы состоит из нескольких слов, а основной текст — из тысяч. Одинаковая нормализация длины для них была бы такой же ошибкой, как одинаковая оценка совпадения в заголовке и в подвале страницы.
Мысленный эксперимент
В документе А «личный кабинет» стоит в названии страницы и в заголовке раздела «Что можно сделать в личном кабинете». В документе Б это словосочетание восемь раз встречается в разделе с частыми вопросами.
BM25F не обязана всегда выбрать А. Но она позволяет объяснимо решить, почему два сильных структурных сигнала могут оказаться важнее восьми повторов в длинном тексте.
В этом примере первая статья должна стать главным результатом: она отвечает на вопрос целиком. Длинный список изменений не исчезает из результатов, но больше не заслоняет объяснение, которое человеку действительно нужно.
Так можно настраивать поиск для разных видов документов. В каталоге особенно важны бренд, категория и свойства товара. В научной базе — название статьи, аннотация и ключевые слова. В справочном разделе сайта — название страницы, заголовок раздела и основной текст.
Где эта идея живёт на практике
BM25F не осталась университетской формулой. В Apache Lucene есть механизм, который рассматривает несколько частей документа как единое целое и позволяет задавать их относительную важность. Подробнее — в источнике 2.
SharePoint прямо называет свой полевой вариант BM25 — BM25F — и позволяет задавать веса и нормализацию длины для управляемых свойств. Подробнее — в источнике 3.
Manticore Search даёт BM25F как отдельный способ расставить результаты с учётом весов частей документа. Подробнее — в источнике 4.
Важно не подменять понятия. Поиск по нескольким частям документа или искусственный приоритет названия страницы ещё не обязательно означают классическую BM25F: система может оценивать части независимо, усиливать уже найденное совпадение или объединять текст иначе. Эти подходы могут быть полезны, но ведут себя по-разному.
Граница точного совпадения
Вернёмся к исходному вопросу. Пока пользователь пишет «личный кабинет», BM25F работает в своей сильной зоне: видит эти слова и их место в структуре документа.
Но пользователь может спросить иначе: «Где посмотреть начисления и оплатить счёт?» Этот вопрос может вести именно в личный кабинет, но не содержит его названия. Здесь полевая модель уже не может опереться на точное совпадение.
Это не недостаток BM25F, а граница её задачи. Она отвечает на вопрос: где слова запроса стоят в наиболее подходящем месте документа? Она не обязана сама понять, что две разные фразы описывают одну ситуацию.
Поиск не выбирает одного победителя
Точное название, код ошибки, имя настройки или артикул — поиск точного совпадения.
Перефразированный вопрос — смысловой поиск: он сопоставляет близкие по смыслу фразы.
Связанные документы — поиск по связям между страницами и понятиями.
Несколько сильных вариантов — дополнительное сравнение результатов.
В хорошем поиске эти способы не вытесняют друг друга. Точный поиск хорошо удерживает коды ошибок, названия тарифов, имена настроек, юридические формулировки и артикулы. Смысловой поиск помогает, когда пользователь помнит ситуацию, но не точное название. Затем система сравнивает несколько сильных результатов и выбирает те, которые лучше отвечают на вопрос целиком.
Где здесь Dzen
В Dzen поиск по словам тоже учитывает устройство источника: название страницы, адрес страницы, заголовок фрагмента и основной текст рассматриваются по-разному. Это позволяет использовать точные совпадения не как случайный побочный эффект, а как отдельный сигнал.
Но этот сигнал не получает последнее слово. Он соединяется со смысловым поиском и поиском по связям между страницами, после чего несколько результатов сравниваются перед подготовкой ответа. Поэтому точное совпадение в заголовке не теряется, но и не может в одиночку решить, какой источник увидит пользователь.
Идея BM25F здесь важнее конкретной формулы. Она напоминает: поиск должен видеть форму знания — слова документа и роль, которую они в нём играют.
Как поиск выбирает страницу о личном кабинете
Переключайте способы поиска и меняйте, насколько важны название страницы и заголовок раздела.
