Виктор Р
Про «обучение на сломанном процессе» согласен, это классическая проблема холодного старта в ML. Если кормить модель данными, где процесс уже хромает, она выдаст «нормализованный» хромой процесс и просто перестанет видеть реальные инциденты.
Мы также делаем ставку на режим «тени» (shadow mode) и кросс-валидацию. Первые недели система для пользователей вообще никак себя не проявляет, тихо сопоставляет свои гипотезы с их реальными действиями (тем самым журналом, о котором вы упомянули) и калибруется.
Про привязку к смене - отдельный респект. Мы заложили в фичи время и дни недели, но явно ночные и дневные смены не выделяли. А они действительно работают в разных ритмах и с разной терпимостью к отклонениям. Возьмём на заметку для следующих итераций.
Отвечая на ваш вопрос про гранулярность: мы идём от конкретной линии или единицы техники. Настраивать чувствительность на уровне целого элеватора (или цеха) бессмысленно - это слишком агрегированная единица, где «всегда что-то да происходит».
Отличный, очень предметный диалог. Спасибо!
Кстати, а как вы на внедрениях решаете проблему «дрейфа базовой линии»? Когда процесс эволюционирует (например, поменяли поставщика запчастей или изменили логистику), модель начинает ловить ложные срабатывания на новой норме. Периодически переобучаете или есть какой-то механизм адаптации?
@id6086550, правило "нет действия — график уходит с панели" —
надо на стену повесить в каждом центре управления.)))))
По вашему вопросу: на практике чаще всего пороги «из коробки» ставит вендор (или интегратор), а технолог потом месяцами пытается их подкрутить, потому что универсальных цифр не существует. Это и рождает тот самый шум, о котором я писал.
В нашем подходе мы хотим уйти от жестких статических порогов, заданных вендором. Система будет сама формировать динамические базовые линии на основе исторических данных, а технолог настраивает не «цифру алерта», а бизнес-правила и уровень чувствительности (например, «игнорировать простои до 2 часов на известных элеваторах»). Это переносит фокус с бесконечной настройки датчиков на управление бизнес-логикой.
@id5097874 , полностью согласен. Формула «событие — решение — действие — результат» — это именно то, чего не хватает большинству пользователей BI.
От себя добавлю: проблема в том, что эту цепочку часто разрывают на этапе "решение". Событие зафиксировано, действие произошло (кто-то что-то сделал), результат измерили (через неделю цифры изменились). А вот РЕШЕНИЕ — оно осталось в головах, в переписке, в телефонных разговорах. И когда через месяц - полгода - год похожая ситуация повторяется — никто уже не помнит, что именно сработало в прошлый раз.
@id6039062, честно скажу — сейчас это действительно разрыв: система не видит принимаемых решений. И да, предиктивка на таких данных учится криво — она видит корреляции, но не понимает каузальности. По архитектуре, которую мы закладываем: фиксировать решение должен
не агроном вручную (он никогда не будет этого делать), а сама
система. Механизм такой:
1. Система видит проблему и генерирует гипотезу с вариантами действий
2. Профильный специалист выбирает вариант (один клик в интерфейсе) или отклоняет с комментарием
3. Это решение автоматически фиксируется как "контекст" для будущих обучений моделей.
По сути, это закрытие того самого "аналогового API", только не через заставление пользователей что то заносить в систему, а через минимальное действие.
Спасибо, что второй раз задаёте вопросы по теме и болям — это реально помогает проверить архитектуру на прочность.
Примерно половина на сельхозтехнику. И эта боль нам хорошо знакома. Собственно поэтому и решил заняться этой темой, а то ТП на стену уже лезет от потока запросов на подтверждение реальности слива.
Антон, абсолютно верно. Geofencing данных — это только первый слой защиты. Второй и более сложный для ИБ — это управление привилегиями и аудитом действий самого AI-агента внутри контура.
Мы тоже пришли к выводу, что «черный ящик» с root-доступом или широкой сетевой видимостью вызывает отторжение даже при локальном хранении. Поэтому наша архитектура строится на принципе least privilege: агент видит только те API-эндпоинты и таблицы, которые необходимы для конкретной задачи.
Плюс критична возможность мгновенного отзыва доступа («kill switch» на уровне учетной записи агента), чтобы в случае аномального поведения система могла быть изолирована без остановки всего производства. Спасибо за дополнение, это действительно ключевой пункт для прохождения security review.