Где возникает потеря

Stattküche GmbH больше сорока лет готовит обеды для школ и детских садов в районе Мюнстера. По данным сети European Digital Innovation Hubs, предприятие выпускает около 22 тысяч порций в день. Семья может заранее заказать обед, но не забрать его и не отменить вовремя. Кухня узнаёт о фактическом спросе слишком поздно, а приготовленную лишнюю еду приходится утилизировать по санитарным правилам.

Задача здесь не в том, чтобы модель «придумала меню». Нужно оценить, сколько заказанных порций по площадке и типу блюда не будет востребовано в конкретный день. Ошибка в обе стороны имеет цену: избыток превращается в отходы и расходы на продукты, а чрезмерное сокращение производства оставляет людей без питания. Поэтому прогноз должен помогать планировщику, а не автоматически диктовать кухне единственное число.

Компания обратилась к европейскому цифровому инновационному центру EDIH-DO. В кейсе описан результат пилота: у кухни появились анализ исторических заказов, ежедневные прогнозы и возможность корректировать объем производства. Но честная оговорка первоисточника важнее красивой презентации: количественные данные о сокращении отходов и экономии ещё не опубликованы. Это рабочий пример внедрения прогнозирования, а не доказанная цифрами окупаемость.

Что сделали с данными

До проекта журналы заказов находились у внешнего ИТ-поставщика, и сама компания не имела удобного аналитического доступа к своей истории. Команда EDIH-DO получила сырые записи за 2020–2023 годы, очистила их и агрегировала по производственной площадке, дате и типу меню. Дополнительно рассматривались праздники, погода и сведения о волнах заболеваний. В небольшом бизнесе это знакомая преграда: данные есть в сервисе, но выгрузка, права на использование и единые названия блюд оказываются сложнее выбора алгоритма.

Проверили несколько подходов: Random Forest, XGBoost, ExtraTrees и временной ряд SARIMAX. По описанию проекта, ExtraTrees дал лучшую точность на отложенных данных. Однако первоисточник не приводит значение ошибки и не показывает, какой выигрыш был относительно простого прогноза по прошлым похожим дням. Поэтому было бы неверно утверждать, что именно этот алгоритм универсально лучше для любой столовой.

Результат оформлен в двух документированных Jupyter-ноутбуках: один для исследования данных, другой для ежедневного прогноза с переключением сценариев. Отдельный Python-скрипт готовит данные, чтобы модель можно было переобучить при появлении регулярной выгрузки. Дополнительного оборудования, согласно кейсу, не потребовалось; центр предоставил экспертизу и вычислительные ресурсы, а компания — сотрудников и знание процесса. Пилот финансировался центром, поэтому его бюджет нельзя напрямую переносить в коммерческий проект российской компании.

Как выглядит повторяемая архитектура

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

Практическая цепочка может быть такой:

  • Договориться о регулярной выгрузке из системы заказов и проверить право хранить и обрабатывать эти записи.
  • Привести к единому справочнику площадки, меню и статусы заказа; отделить возвраты и исправления от реальных отмен.
  • Сравнить простой базовый прогноз с несколькими моделями на последовательных отложенных неделях, не перемешивая будущее с прошлым.
  • Показывать планировщику диапазон, историю ошибки и причины ручной корректировки, а не только одно «магическое» число.
  • Каждый день фиксировать прогноз, фактическую выдачу, приготовленные порции, остаток и случаи нехватки.
  • Переобучать модель по регламенту и отдельно проверять, не ухудшилось ли качество после смены меню или календаря.

Если заказов мало, простой календарный расчет может выиграть у сложной модели за счет прозрачности и низкой стоимости поддержки. Если площадок много и шаблоны спроса отличаются, модель может быть полезна — но выбор определяется измерением на своих данных. Независимая работа о прогнозировании питания в столовых также начинает с истории бронирований и посещаемости и рассматривает сезонность и каникулы как признаки. Она не подтверждает результат Stattküche, зато показывает, что проблема встречается вне одного предприятия.

Локальный контур здесь вполне реалистичен: таблица заказов, пакетная подготовка признаков и небольшой прогнозный сервис могут работать на имеющемся сервере или рабочей станции. Языковая модель не обязательна. Её можно подключить отдельно, например для объяснения отклонений планировщику на русском языке, но она не должна заменять числовой прогноз и проверку исходных данных. Персональные данные учащихся для задачи количества порций обычно можно не передавать в модель: достаточно агрегатов по площадке, дню и меню, если это соответствует процессу.

Экономика и пределы пилота

В собственном расчете сравните расходы на создание и поддержку выгрузки, подготовку данных, вычисления и время сотрудника с двумя эффектами: меньше закуплено и приготовлено лишнего, меньше выброшено после выдачи. Добавьте стоимость недостачи порций и резерв безопасности. Цель не «минимум остатков любой ценой», а минимальная совокупная стоимость при приемлемом уровне сервиса.

Для проверки достаточно начать с одной площадки и нескольких недель теневого режима. Пусть прогноз рассчитывается ежедневно, но решение пока принимает планировщик по старой схеме. Это покажет, где модель переоценивает отмены, как ведет себя в каникулы и можно ли безопасно сократить запас. Затем можно согласовать небольшой коридор изменения производства и измерить результат на реальных днях. Не объявляйте проект успешным по уменьшению ошибки прогноза, пока не измерены отходы, расходы и случаи нехватки питания.

Для руководителя кейс Stattküche ценен своей последовательностью: сначала доступ к заказам и единые данные, потом сравнение алгоритмов, затем понятный инструмент для кухни. Внутрик может радостно принести ещё один пустой поднос «на всякий случай», но сколько порций готовить завтра, решает человек по данным и с учетом сервиса.