Не весь набор признаков нужен, чтобы понять оффер
В табличных моделях есть соблазн упростить всё до «оставим только самые важные поля». Но в исследованиях на синтетическом бенчмарке SCM3K с 3 450 задачами картина оказалась менее удобной: если модели давали почти идеальный набор признаков из так называемой Markov boundary, качество прогноза часто росло. Особенно заметно это было на более разреженных и больших по размеру датасетах.
Проблема в другом: способы, которыми boundary пытаются находить на практике, нередко не доживают до тех режимов, где этот подход действительно полезен. То есть метод выглядит аккуратно с точки зрения структуры, но в реальной вычислительной среде упирается в стоимость поиска. И даже когда оценщик boundary работает, он не всегда обгоняет полный набор признаков.
Для анализа офферов это хороший ориентир. Красиво отобранные сигналы сами по себе не гарантируют лучший вывод. Можно убрать «шумные» поля, оставить только логичные метрики — и всё равно проиграть более грубой модели, если вырезали признаки, которые ловили редкие, но важные случаи.
Практический вывод простой: при разборе оффера важна не только «правильность» структуры, но и цена ошибок. Ложный пропуск и ложная тревога почти никогда не стоят одинаково. Поэтому сокращать набор сигналов стоит не ради эстетики, а только если это улучшает решение в конкретной задаче.
В табличных моделях есть соблазн упростить всё до «оставим только самые важные поля». Но в исследованиях на синтетическом бенчмарке SCM3K с 3 450 задачами картина оказалась менее удобной: если модели давали почти идеальный набор признаков из так называемой Markov boundary, качество прогноза часто росло. Особенно заметно это было на более разреженных и больших по размеру датасетах.
Проблема в другом: способы, которыми boundary пытаются находить на практике, нередко не доживают до тех режимов, где этот подход действительно полезен. То есть метод выглядит аккуратно с точки зрения структуры, но в реальной вычислительной среде упирается в стоимость поиска. И даже когда оценщик boundary работает, он не всегда обгоняет полный набор признаков.
Для анализа офферов это хороший ориентир. Красиво отобранные сигналы сами по себе не гарантируют лучший вывод. Можно убрать «шумные» поля, оставить только логичные метрики — и всё равно проиграть более грубой модели, если вырезали признаки, которые ловили редкие, но важные случаи.
Практический вывод простой: при разборе оффера важна не только «правильность» структуры, но и цена ошибок. Ложный пропуск и ложная тревога почти никогда не стоят одинаково. Поэтому сокращать набор сигналов стоит не ради эстетики, а только если это улучшает решение в конкретной задаче.