Разбираю по исходникам товарной вертикали Яндекса (дерево ya/extsearch/goods), а не по официальной формуле Маркета. Реестр факторов лежит в base/factors/factors_meta_gen.in, всего там 3144 фактора, и заметная их часть - это классические текстовые меры релевантности: насколько слова запроса встречаются в полях документа. Документ здесь - это карточка модели или оффер, а поля - в первую очередь название (title) и описание (body), плюс их объединение (full).
Когда пользователь вбивает запрос (наушники sony wh-1000xm5 беспроводные), движок не просто ищет точное совпадение строки. Он раскладывает запрос на слова, лемматизирует, учитывает синонимы и считает целый набор числовых характеристик пересечения запроса с текстом карточки. Эти числа потом скармливаются в CatBoost/MatrixNet-модель ранжирования.
Семейства факторов: что реально лежит в кодеВажно сразу: у CatBoost-формулы нет фиксированных процентных весов на фактор. Дерево решений использует значение фактора как точку ветвления, а не умножает на коэффициент. Поэтому все оценки силы сигнала ниже - качественные (сильный/слабый) и помечены как реконструкция, а не как 'этот фактор даёт N процентов'.
Все текстовые меры в реестре идут триплетами по полю: суффикс _TITLE (название), _BODY (описание), _FULL (всё вместе). Это видно прямо по выводу из factors_meta_gen.in.
Код: Выделить всё
СЕМЕЙСТВО СУТЬ МЕРЫ ПОЛЯ В КОДЕ
BM25 классическая частотная релевантность BM25_TITLE / BM25_BODY / BM25_FULL
(term frequency с насыщением,
поправка на длину поля)
BOCM пословное покрытие (best occurrence BOCM_TITLE / BOCM_BODY / BOCM_FULL
coverage match) - сколько слов
запроса вообще нашлось
BCLM покрытие с учётом близости/цепочек BCLM_TITLE / BCLM_BODY / BCLM_FULL
слов (cover + lite match), важна
компактность совпадения
TOCM покрытие с учётом порядка/title TOCM_TITLE / TOCM_BODY / TOCM_FULL
occurrence, насколько кучно слова
HAS_ALL_WORDS факт: все ли слова запроса есть HAS_ALL_WORDS_LE_TITLE / _EX_TITLE ...
NUM_WORDS сколько слов запроса покрыто полем NUM_WORDS_LE_TITLE / _EX_TITLE ...
Код: Выделить всё
ВАРИАНТ ЧТО МЕНЯЕТ ПРИМЕРЫ ИМЁН ИЗ КОДА
_W / _W1 / _W_ веса слов (важность термина) BOCM_W_TITLE, BM25_W1_TITLE, BCLM_WEIGHTED_W1_K4_TITLE
_EX exact, точные формы без лемм BM25_EX_TITLE, HAS_ALL_WORDS_EX_TITLE, NUM_WORDS_EX_TITLE
_LE lemma, по леммам HAS_ALL_WORDS_LE_TITLE, NUM_WORDS_LE_TITLE
_SY synonyms, с учётом синонимов BM25_SY_TITLE, BM25_SY_W1_TITLE
_HI_REL high relevance, по сильным BM25_HI_REL_TITLE, BM25_HI_REL_SY_TITLE
(высокорелевантным) совпадениям
_PAIR парные совпадения слов BM25_PAIR_TITLE, BM25_PAIR_SY_TITLE
_BREAK с учётом разрывов предложений BM25_BREAK_TITLE, BM25_BREAK_SY_TITLE
_DOUBLE_K7 удвоенное покрытие, параметр K7 BOCM_DOUBLE_K7_TITLE
_HARD / _K1 / _K2 жёсткость и параметр K BCLM_HARD_W1_K1_TITLE, BCLM_HARD_W1_K2_TITLE
Где сигнал сильнее: название против описания
Прямого веса в коде нет, но кое-что видно по структуре. Есть отдельные именованные факторы именно для title, которых нет для body:
Код: Выделить всё
TITLE_BM_25_EX Tags: TG_DOCUMENT_STATIC, TG_BLENDER_PLACE, TG_BASE,
TG_MODEL_OFFER_PLACE, TG_TEXT_PLACE
TITLE_LRBM_25 аналогично, отдельная BM25-мера по заголовку
TITLE_COMM совпадение коммерческой/категорийной части заголовка
TITLE_IN_LINKS_TRIGRAMS триграммы заголовка в ссылках
BOCM_TITLE_Q0..Q100 квантильные версии покрытия заголовка
FIXED_BOCM_TITLE_Q0..Q100
Нейросетевой слой: BERT поверх частотных мерРеконструкция (не доказано весами, выведено из структуры реестра): совпадение по названию - более сильный текстовый сигнал, чем по описанию. У title больше выделенных факторов и есть квантильные варианты. Но описание не мусор: BM25_BODY, BCLM_BODY, TOCM_BODY реально присутствуют и идут в модель.
Частотные меры (BM25 и компания) ловят буквальное пересечение слов. Поверх них в реестре есть семантические факторы на базе BERT - они оценивают смысловую близость запроса и карточки, даже если слова не совпали дословно.
Код: Выделить всё
BERT_ASSESSMENT Tags: TG_BASE, TG_TEXT_PLACE
Релевантность по бертовой модели (маркетный сервис)
BERT_CHEBYSHEV Tags: TG_TEXT_PLACE
макс. расстояние эмбеддингов документа и запроса
BERT_MARKET_MODEL Tags: TG_BASE, TG_TEXT_PLACE, TG_UNIMPLEMENTED <- мёртвый
BERT_MARKET_MODEL_2 Tags: TG_BASE, TG_TEXT_PLACE, TG_UNIMPLEMENTED <- мёртвый
BERT_MARKET_MODEL_3 Tags: TG_BASE, TG_TEXT_PLACE, TG_UNIMPLEMENTED <- мёртвый
Практический смысл: семантика частично закрывает кривые формулировки. Если в названии нет слова из запроса, но карточка про тот же товар, BERT_ASSESSMENT может это подхватить. Но полагаться только на неё нельзя - частотные BM25/BOCM по-прежнему в строю.Граница: BERT_MARKET_MODEL, _2 и _3 помечены TG_UNIMPLEMENTED - это слоты, которые в коде есть, но не реализованы/не считаются. Не подавайте их как рабочий сигнал. А вот BERT_ASSESSMENT и BERT_CHEBYSHEV таких меток не несут - это живые семантические факторы текстовой выдачи (TG_TEXT_PLACE).
Что из этого реально контролирует магазин
Текстовые факторы считаются по тому тексту, который магазин сам отдаёт в фиде (YML/Yandex Market Language) и в карточке. Значит, рычаги такие:
- Название (title в фиде) - главный текстовый рычаг. Сюда идут BM25_TITLE, BCLM_TITLE, BOCM_TITLE, TOCM_TITLE, TITLE_BM_25_EX, HAS_ALL_WORDS_LE_TITLE. Формула 'основной запрос + бренд + модель + ключевая характеристика' закрывает сразу несколько факторов: и BM25 (частота слов), и HAS_ALL_WORDS (все слова на месте), и NUM_WORDS (покрытие).
- Не лить воду в название. BM25 имеет насыщение и поправку на длину поля - десять повторов слова не дают линейного роста, а удлинение заголовка размывает плотность. Перечисление 'купить недорого со скидкой акция' только разбавляет сигнал.
- Порядок и компактность слов. Семейство BCLM и TOCM реагирует на близость слов запроса друг к другу. Естественная формулировка, где ключевые слова стоят рядом и в осмысленном порядке, выигрывает у мешка слов.
- Описание (body) - вторичный, но рабочий слой. BM25_BODY, BCLM_BODY, TOCM_BODY существуют. Туда уходят средне- и низкочастотные запросы, синонимы, характеристики - то, что не влезло в название. Естественное вхождение, без спама.
- Синонимы. Есть _SY-варианты (BM25_SY_TITLE и т.п.), движок сам подтягивает синонимы, но если у товара есть народное название (робот-пылесос / робот пылесос), стоит дать обе формы в тексте.
- Совпадение фида и карточки. По требованиям Маркета данные в фиде должны совпадать с карточкой; рассинхрон бьёт по доверию и может ломать матчинг оффера в модель.
- Матчинг оффера в карточку модели и категоризация происходят выше по конвейеру (upstream в дереве market/, не в этом коде). Текстовые факторы уровня модели считаются уже по агрегированной карточке, а не только по вашему тексту.
- Веса и пороги. CatBoost решает сам, при каком значении BM25_TITLE ветвиться. Накрутить конкретное число бессмысленно - нет линейного веса.
- BERT-эмбеддинги. Семантику не оптимизируешь подстановкой слов; она реагирует на смысл целиком.
Итог простой: пишите название как для человека, но с обязательным вхождением главного запроса, бренда и модели рядом и в начале; описание - подробно, с характеристиками и синонимами, без спама; и держите фид в синхроне с карточкой. Этого достаточно, чтобы накормить весь текстовый блок факторов, который реально живёт в коде вертикали.Доказано кодом: перечисленные факторы (BM25_*, BOCM_*, BCLM_*, TOCM_*, HAS_ALL_WORDS_*, NUM_WORDS_*, TITLE_BM_25_EX, BERT_ASSESSMENT, BERT_CHEBYSHEV) реально присутствуют в factors_meta_gen.in с тегами TG_TEXT_PLACE / TG_BASE и считаются по полям title/body/full. Мёртвые: BERT_MARKET_MODEL/_2/_3 (TG_UNIMPLEMENTED).
Реконструкция: относительная сила title над body, смысл вариантов _W/_EX/_LE/_SY/_HI_REL, влияние длины и компактности. Это вывод из структуры реестра и общей теории BM25, а не из весов формулы. Конкретных процентов влияния не существует - не верьте таким цифрам ни от кого.