В продолжение предыдущего поста
Попробуем копнуть глубже на примере одного стартапа по доставке продуктов. Допустим, вам надо предсказывать время доставки заказа после его оформления.
Нам нужно предсказывать эту величину для двух вещей: во-первых, показывать клиенту в приложении, чтобы он мог планировать свое время; во-вторых, использовать это время как ориентир для внутренней логистики. Для клиента нужно предсказывать достаточно точно, как без большого количества опозданий (все мы не любим, когда заказ опаздывает), так и без ранних привозов (опять все идет не по плану клиента).
Очевидно, ваш первый бейзлайн — линейная регрессия на расстоянии от магазина до клиента, с ориентиром на медиану, это помогает балансировать опоздания и ранние доставки. Для такого бейзлайна достаточно хранить в БД для каждого магазина два коэффициента, которые даже имеют смысл в реальном мире: средняя скорость курьера и добавочное время на сбор заказа.
Окей, вы выкатили, потестили, вроде работает, вы восхитительны.

Что дальше? Наверняка через пару дней/спринтов к вам придет продакт и потребует улучшений, так бейзлайн хорош, но недостаточно.
Можно начать копать в сервисы, можно попробовать поулучшать текущую модель.
Есть прекрасная идея от моего бывшего коллеги: давайте обучим две модели.
Одна — простая, линейная регрессия на расстоянии, другая — большая (например, бустинг), на большем наборе признаков, какие вы только можете придумать, за исключением расстояния. Примеры признаков — различные агрегаты, вроде средних скоростей доставки,сборки,количества айтемов, заказываемых из точки.
Дальше просто, ваше предсказание — это ax+b+GB(y). Что мы можем сделать? Конечно же посчитать b+G(y) разово для магазина и заливать как один из параметров в базу.
Затем повторяете это упражнение раз в 1-3 дня, и качество вашего предсказания становится ощутимо лучше, чем предыдущий бейзлайн. Не забудьте измерить качество в оффлайне и онлайне.