AgTech-стартап купил ML-модель. Поле всё равно болеет

Причина почти всегда одна: модель распознаёт болезнь, но не умеет сказать агроному, что с ней делать в его конкретной ситуации. Какой препарат применить

— с учётом того, что месяц назад на этом поле уже обрабатывались? В какой дозе

— учитывая фазу культуры? Можно ли вообще — если регистрация препарата в Госкаталоге была отозвана?

Красивая ML-модель поверх непроверенных данных проигрывает скучному детерминированному дереву поверх выверенной базы регламентов. В этой нише источник данных важнее алгоритма.

Государственный каталог пестицидов и агрохимикатов — главный источник истины для любой AgTech-системы в России. Нормы расхода препаратов, допустимые культуры, сроки ожидания, условия применения — всё берётся оттуда.

Проблема: Госкаталог — не чистый API с машиночитаемой структурой. Это человекочитаемый массив с неоднозначными формулировками. «0,2–0,4 л/га» — это диапазон или два правила? За разными концами диапазона часто стоят разные условия: тип почвы, степень засорённости, фаза. ETL-слой, который схлопывает диапазон в одно число, тихо ломает рекомендацию.

И главное: Госкаталог меняется. Стартап, который взял данные при запуске и забыл, через полгода рекомендует препараты, применение которых уже нелегально. В нише с контролем со стороны Россельхознадзора это не технический долг — это регуляторный риск.

Правильная архитектура разделяет два слоя. Первый — логика навигации: дерево решений, которое ведёт агронома от симптома к рекомендации. Его редактирует агроном-эксперт через конструктор, без участия разработчика. Второй — верифицированные данные из Госкаталога, регулярно сверяемые с первоисточником.

Когда эти слои смешаны — каждое изменение Госкаталога превращается в задачу для разработчика. А изменений за сезон — сотни. Разделение слоёв решает обе проблемы: агроном редактирует правила сам, ETL следит за дельтами независимо от логики дерева.

DSS без памяти об истории обработок поля агрономически опасна. Если система дважды за сезон порекомендует препараты с одним механизмом действия — патоген выработает резистентность. Защита перестанет работать на годы вперёд.

Антирезистентная ротация по FRAC/HRAC — минимальный порог, ниже которого систему нельзя называть агрономически грамотной. И она требует сущности «поле» с историей обработок. Большинство AgTech-инструментов ломаются именно здесь: они видят симптом, не видят поле.

Детерминированное дерево решений поверх выверенной базы регламентов — это не дорого. Никакого ML. Стоит как небольшой сайт.

ML-диагностика по фото — верхний уровень, к которому приходят позже, когда накоплены размеченные данные. На старте это не нужно: без корректной базы регламентов и памяти о поле результат распознавания всё равно некуда применить.

Стратегия: Начать с детерминированного дерева и выверенного ETL из Госкаталога → накопить размеченные данные через тот же инструмент → добавить CV-модель как дополнительный способ войти в дерево. Дерево и регламенты остаются; меняется только способ навигации к узлу.

Вы уже вложили в ML — а данные, на которых он работает, кто-нибудь проверял с момента запуска?