Карточка модели и медиа: MODEL_RATING, отзывы, HAS_PICTURE и матчинг офферов

[anna_seo]

О чём этот разбор

Продолжаю серию по факторам товарной вертикали Яндекса (yandex.ru/products плюс товарный колдунщик в основном поиске, код ya/extsearch/goods). Прошлые треды трогали оффер и магазин, тут залезаем в саму карточку модели: рейтинг, отзывы, фото и то, сколько офферов к этой карточке приклеилось. Это та сущность, которую видит покупатель в выдаче товарного поиска: одна модель, под ней пачка предложений от разных магазинов.

Сразу граница. Это реконструкция по реестру факторов и тегам, а не официальная формула Маркета. Ранжирование крутится на CatBoost/MatrixNet (в ya/extsearch/goods/data/formulas лежат скомпилированные деревья, десятки версий meta_models и сотни formulas-JSON). У деревьев решений нет фиксированных процентных весов у отдельного фактора. Поэтому никаких "рейтинг = N процентов" - только качественно: сильный сигнал, слабый, контекстный. Цифры влияния, которые гуляют по блогам, к коду вертикали не привязаны.

Откуда вообще берётся карточка модели

Магазины льют офферы фидами (YML, Yandex Market Language). Дальше upstream-конвейер (это код market/, не наше дерево goods) матчит офферы в карточки моделей, категоризирует и строит индекс. На бекенды report этот индекс приезжает готовым поколением шардов примерно раз в полсуток. То есть на уровне рантайма, который мы разбираем, матчинг уже произошёл - report видит модель и привязанные к ней офферы как факт. Это важно для практических выводов ниже: качество матчинга магазин контролирует на входе (фид), а не на выдаче.

Рейтинг модели

Группа рейтинга в реестре представлена несколькими факторами. Вот реальные имена и теги как в factors_meta_gen.in:

Код: Выделить всё

Name                          Tags
----------------------------  --------------------------------------------------
MODEL_RATING                  TG_BASE TG_BLENDER_PLACE TG_MODEL
                              TG_MODEL_OFFER_PLACE TG_TEXT_PLACE
MODEL_RATING_2                TG_BASE TG_BLENDER_PLACE TG_MODEL
                              TG_MODEL_OFFER_PLACE TG_TEXT_PLACE  (MARKETOUT-46160)
MODEL_RATING_PRECISE          TG_DOCUMENT TG_BASE  ("точный рейтинг до 2 знаков")
MODEL_RATING_PRECISE_2        TG_DOCUMENT TG_BASE
MODEL_RATING_COUNT            TG_DOCUMENT TG_BASE  ("кол-во оценок, не обяз. текстовых")

Что тут читается. MODEL_RATING - базовый рейтинг модели, и он живёт сразу в трёх местах выдачи: TG_TEXT_PLACE (текстовая товарная выдача), TG_MODEL_OFFER_PLACE (карточка товара с офферами) и TG_BLENDER_PLACE (подмешивание товарного блока в общий блендер выдачи). То есть это не локальная декорация - рейтинг доезжает до ранжирования во всех трёх сценариях показа. MODEL_RATING_2 - явно более поздняя итерация того же сигнала (отдельный тикет, свой автор), оба живые, оба в тех же местах. Сосуществование старой и новой версии фактора - обычная история: дерево формулы может опираться на обе.

Зачем отдельно PRECISE и COUNT

MODEL_RATING_PRECISE - тот же рейтинг, но с точностью до сотых. Грубый и точный рейтинг как два разных входа в модель - это не дубль, а возможность для дерева ловить тонкие пороги: например, отличать 4.7 от 4.8 там, где округлённый до целого сигнал их бы слепил. MODEL_RATING_COUNT - сколько всего оценок выставлено (включая нетекстовые звёзды). Это типичный сигнал доверия к самому рейтингу: 4.9 при пяти оценках и 4.9 при пяти тысячах для модели - разные ситуации, и COUNT даёт ей это различать.

Доказано кодом: рейтинг модели существует и как округлённый, и как точный, и сопровождается счётчиком оценок, и эти входы заведены в текстовую выдачу, карточку с офферами и блендер. Реконструкция: модель, скорее всего, использует COUNT как доверительный множитель к рейтингу, а PRECISE - для тонких порогов. Конкретный вес - в деревьях, наружу его не вытащить.

Отзывы: текстовые против оценок

Маркет в коде аккуратно разделяет "оценку" и "текстовый отзыв" - это две разные сущности, и факторы под них разные:

Код: Выделить всё

MODEL_OPINIONS_COUNT          TG_DOCUMENT TG_BASE  "кол-во ТЕКСТОВЫХ отзывов у модели"
MODEL_REVIEW_COUNT            TG_BASE TG_BLENDER_PLACE TG_MODEL
                              TG_MODEL_OFFER_PLACE TG_TEXT_PLACE
MODEL_POSITIVE_OPINIONS_PART  TG_DOCUMENT TG_BASE  "доля положит. от всех текстовых"

MODEL_OPINIONS_COUNT - именно текстовые отзывы (где человек что-то написал), MODEL_RATING_COUNT выше - просто оценки. MODEL_REVIEW_COUNT - ещё один счётчик отзывов, и в отличие от OPINIONS_COUNT он разложен по всем трём местам выдачи (TEXT_PLACE, MODEL_OFFER_PLACE, BLENDER_PLACE), то есть это тот счётчик, который реально участвует в ранжировании показа, а не только в базовом наборе документа.

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

Отзывы о магазине - другая сущность

Не путать с отзывами на модель. Это уровень оффера/магазина:

Код: Выделить всё

SHOP_OPINION_COUNT            TG_BASE TG_BLENDER_PLACE TG_OFFER
                              TG_MODEL_OFFER_PLACE TG_TEXT_PLACE
LOG_SHOP_OPINION_COUNT        TG_OFFER TG_BASE  "двоичный логарифм кол-ва отзывов о магазине"
FIXED_SHOP_OPINION_COUNT_Q0   ... _Q25 _Q50 _Q75 _Q100  (квантильные нарезки)

LOG_SHOP_OPINION_COUNT логарифмирован не случайно: разница между магазином с 10 и 100 отзывами огромна, между 10000 и 100000 - почти никакая. Логарифм гасит этот хвост. Квантильные FIXED_SHOP_OPINION_COUNT_Q* - та же идея нормировки через перцентили. Для нашего треда это фон: отзывы о магазине влияют на конкретный оффер внутри карточки, а не на саму модель.

Фото и медиа

Код: Выделить всё

HAS_PICTURE       TG_DOCUMENT TG_BASE TG_BLENDER_PLACE TG_MODEL_OFFER_PLACE TG_TEXT_PLACE
BG_IS_PICTURE     TG_BASE TG_TEXT_PLACE TG_FROM_META TG_BLENDER_PLACE TG_QUERY_ONLY
WR_PICTURE        TG_CATEGORY

HAS_PICTURE - бинарный флаг наличия картинки, и он заведён во все три места показа. Это самый прямой и при этом самый базовый медиа-сигнал: есть фото или нет. Сильный по охвату (доезжает везде), но грубый - он отвечает на "да/нет", а не "хорошее ли фото". BG_IS_PICTURE помечен TG_QUERY_ONLY и TG_FROM_META - это сигнал уровня запроса/блендера (нужен ли вообще показ с картинкой под этот интент), а не свойство карточки. WR_PICTURE висит на TG_CATEGORY, то есть это категорийная характеристика, а не контролируемое магазином свойство конкретного оффера.

Важно: в коде вертикали нет фактора "качество фото 2000x2000" или "соотношение 3:4". Требования к разрешению, белому фону и формату изображений (это активно меняли в 2025-2026) проверяются на стадии приёма и модерации фида (upstream market/), а в рантайм-ранжирование доезжает по сути флаг HAS_PICTURE. Так что "красивое фото ранжирует выше" - неверная формулировка для уровня report: фото влияет на приём оффера, на матчинг и на поведение пользователя (CTR), а не как отдельный фактор красоты в формуле.

Матчинг и количество офферов

Код: Выделить всё

NUMBER_OFFERS                       TG_BASE TG_BLENDER_PLACE TG_MODEL TG_MODEL_OFFER_PLACE
                                    TG_TEXT_PLACE TG_FORMULA_CHECK_PARROT
TOTAL_NUMBER_OFFERS                 те же теги + TG_FORMULA_CHECK_PARROT
NUMBER_OFFERS_TO_TOTAL_NUMBER_OFFERS    те же теги
BLOCK_NUMBER_OFFERS                 TG_BASE TG_BLENDER_PLACE TG_MODEL TG_MODEL_OFFER_PLACE TG_TEXT_PLACE
HEAD_AVG_TOTAL_NUMBER_OFFERS        TG_AVERAGE  "усреднённое TOTAL_NUMBER_OFFERS по HEAD"

Это самая говорящая группа. NUMBER_OFFERS - сколько офферов приклеено к модели в текущем контексте, TOTAL_NUMBER_OFFERS - всего по модели. А NUMBER_OFFERS_TO_TOTAL_NUMBER_OFFERS - их отношение, доля. Отношение само по себе как фактор означает, что модель смотрит не только на абсолют, но и на относительную полноту: насколько в данной выдаче представлена вся карточка. Все три помечены TG_FORMULA_CHECK_PARROT - это служебный тег контроля формулы, косвенный признак того, что факторы рабочие и за ними следят, а не заброшены. HEAD_AVG_TOTAL_NUMBER_OFFERS усредняет число офферов по топу документов - это уже относительный сигнал популярности категории/модели на фоне соседей.

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

Что из этого реально контролирует магазин

• Качество фида и атрибутов - чтобы оффер корректно сматчился в нужную карточку модели, а не повис отдельно или не приклеился к чужой. Шумные атрибуты, неверные единицы, кривой бренд/модель в названии бьют именно по матчингу. Это upstream, но именно тут магазин решает судьбу NUMBER_OFFERS своей карточки.
• Наличие изображения - HAS_PICTURE бинарный, его надо просто закрыть. Дальше уже не "красивее", а "проходит ли модерацию по разрешению/фону/формату" (требования меняются, сейчас в ходу sRGB, белый или прозрачный фон, минимум около 1000px, для одежды допускается фото на модели).
• Полнота карточки - название по формуле тип+бренд+модель+свойства, характеристики заполнены по максимуму. Это влияет на матчинг и на текстовую релевантность (соседняя группа факторов BMRKT_*_DESCRIPTION_OF_MODEL_*MATCH*, к этому треду напрямую не относится).
• Работа с отзывами и рейтингом модели - это коллективная сущность карточки (не одного магазина), но твои реальные продажи и сервис кормят MODEL_OPINIONS_COUNT, MODEL_RATING и особенно MODEL_POSITIVE_OPINIONS_PART. Долю позитива нельзя накрутить объёмом - доля и считается отдельно.
• Отзывы о магазине (SHOP_OPINION_COUNT, LOG_SHOP_OPINION_COUNT) - это уже про конкретный оффер внутри карточки: помогает выиграть позицию среди продавцов одной модели.

Мёртвое не подавать как живое

В этой же тематике есть нейро/поведенческие факторы из группы DJ, например DJ_DOCUMENT_CTR_MODEL_PICTURE_THEMATIC_CATEGORIES_BERU_COUNT7D - он помечен TG_DEPRECATED (плюс это BERU-эпоха, старый бренд). Не опирайтесь на него: deprecated значит исключён из боевой формулы. Если где-то в советах всплывает "CTR картинки модели в тематиках" - это про мёртвый фактор.

Итог

Доказано кодом: рейтинг модели (грубый, точный, со счётчиком), текстовые отзывы и доля позитива, бинарное наличие фото и число/доля офферов - всё это реальные базовые факторы, заведённые в текстовую выдачу, карточку с офферами и блендер. Реконструкция (помечаю как гипотезу): COUNT работает как доверие к рейтингу, доля офферов - как полнота карточки, доля позитивных отзывов - как демотор негативных карточек. Конкретные веса лежат в CatBoost-деревьях и наружу не выводятся. Качество фото и фида решается на приёме оффера (upstream market/), а в рантайм доезжает упрощённый сигнал. Практический рычаг магазина - чистый фид и корректный матчинг плюс живые отзывы, а не косметика, которой в формуле просто нет.