Почему ИИ-пилоты не доходят до реального производства и как это исправить архитектурой

от автора

8–9 апреля на конференции Data Fusion ВТБ публично признал: их ИИ-проекты массово застревают между пилотом и промышленной эксплуатацией. Это не жалоба, это диагноз от людей, которые потратили на ИИ сотни миллионов и видят картину изнутри.

Яндекс и Сбер об этой проблеме прямо не говорят и в ответ предлагают инструменты: GigaChat, YandexGPT, API, облако.

Но никто не объяснил почему это происходит. Почему пилот работает, а в реальном производстве ломается. Почему это не баг конкретного продукта, а свойство архитектуры.

Вот что я понял.

Что такое энтропия в контексте ИИ

Энтропия здесь — не термодинамика Больцмана. Это мера неопределённости выхода системы в смысле Шеннона — информационная энтропия.

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

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

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


Математика которую никто не считает

Представьте цепочку из восьми ИИ-агентов. Каждый работает с точностью 85%. Эта цифра взята из практики RAG-систем и агентных пайплайнов, реальные показатели варьируются от 70% до 95% в зависимости от задачи.

0,85⁸ = 27%

Общая точность цепочки из восьми агентов с точностью 85% каждый

Каждый шаг без верификации человеком умножает неопределённость на следующую. К восьмому шагу три четверти результатов — мусор, и никто не знает какие именно эти три четверти.

Пилот показывает 85% — там один шаг в контролируемых условиях. На производстве система показывает 27% — реальные данные, реальная цепочка, реальное накопление.

Это называется нарастающая энтропия (compounding entropy). Anthropic формализовал это как bias + variance, где variance растёт с длиной цепочки. Число ИИ-инцидентов в мире выросло на 56% за год — данные открытых реестров инцидентов.


Откуда берётся проблема

Индустрия выбрала неправильную метрику.

Метрика успеха ИИ-продукта сегодня: процент задач, выполненных без человека. Инвесторы любят эту цифру, маркетинг её продаёт, менеджеры по ней отчитываются.

Проблема в том, что эта метрика измеряет автономность, а не точность. На коротком горизонте разница незаметна. На длинном она становится критической.

Пример — радиология. Исследование Dratsch et al. (2023, журнал Radiology): радиологи, работающие с ИИ-подсказками, ошибались чаще чем без ИИ — когда подсказка была неверной. ИИ создал новый класс ошибок — automation bias: человек перестаёт думать самостоятельно и следует за системой даже когда она ошибается.

Из смежной области — авиация. Air France 447, 2009: автопилот отключился, экипаж не смог перехватить управление, 228 человек погибли. Да, автопилот — детерминированная система, не LLM. Но проблема деградации навыков при вытеснении человека из контура универсальна. С ИИ она проявляется быстрее. После катастрофы авиакомпании ввели обязательные программы ручного пилотирования. Урок усвоен.


Ещё одна проблема которую упускают

Разрушение кадровой преемственности.

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

В низкоэнтропийной архитектуре уровень 0 — это не «дешёвая работа которую надо автоматизировать». Это этап профессиональной подготовки. Уровень 0 → уровень 3 — одна карьерная лестница, не два разных рынка труда.


Почему это до сих пор не решено

Проблему видят. Описывают. Называют по-разному — но системного ответа нет.

Human-in-the-loop (HITL) — термин который встречается везде. Все согласны: человек должен быть в контуре. Но никто не отвечает — как именно? На каком уровне? С какой частотой? Как его участие возвращается в модель? HITL как принцип есть. HITL как работающая архитектура с конкретными уровнями, железом и циклом дообучения — нет.

Китай движется интересно, своим путём. В январе 2026 года агентство Синьхуа сообщало про «новые производственные отношения для режима человеко-машинного симбиоза» и зафиксировало точный экономический парадокс: если распознавание дефекта одного винта через облачный инференс стоит 1 юань — это уже дороже самого винта. Dayin Technology строит малые модели на физических данных конкретного оборудования. Диагностика верная. Но вектор противоположный — цель всё равно автономия. Проблема деградации компетенций не поставлена вообще.

На Западе каждый исследователь держит свой кусок пазла. Montgomery описал compounding entropy problem. Marin и Steinert зафиксировали deskilling как структурную проблему. Dratsch показал automation bias в радиологии. Все правы. Все описывают одно с разных сторон. Целостной архитектуры решения не предложил никто — ни в западном, ни в восточном дискурсе.

Низкоэнтропийная автоматизация — первая попытка собрать эти куски в одну работающую архитектуру.


Архитектура которая решает проблему на уровне структуры

Главная метрика не «сколько людей можно убрать», а «сохраняет ли система связь с реальностью при масштабировании».

Низкоэнтропийная архитектура четырёхуровневая:

Уровень 0 — человек на земле. Оператор, лесник, медсестра. Физически рядом с объектом. Видит то что датчики не видят. Это нижний контур сброса энтропии данных.

Уровень 1 — модели датчиков. Это не «маленькие LLM» — это модели конкретных физических параметров. Одна модель знает температуру, другая — влажность, третья — спектральный индекс вегетации. Минимум параметров, температура инференса = 0, чистый детерминизм. Работают на CPU или Raspberry Pi 4/5 прямо на объекте. Ключевое поведение: умеет говорить «не знаю» — не галлюцинирует, запрашивает разметку у человека.

Уровень 2 — координатор. Агрегирует выходы моделей датчиков, рассуждает, формирует рекомендацию для эксперта. Температура выше 0 — здесь нужны рассуждения. Работает на GPU. Именно эту модель обучал эксперт на своём датасете — она говорит его языком и его логикой.

Уровень 3 — доменный эксперт. Тот самый человек который создал датасет для координатора. Знает как модель рассуждает — потому что сам её этому учил. Верифицирует рекомендацию, корректирует. Каждая коррекция возвращается в веса.

Ключевой момент: система архитектурно не работает без человека. Это не ограничение — это принцип.


Как это работает технически

Стандартный подход: берём большую модель, пишем системный промпт, добавляем RAG. Промпт — инструкция которую модель читает и забывает. RAG — внешняя база которую ищут при каждом запросе. Знание не зашито в модель, оно подтягивается снаружи.

В низкоэнтропийной архитектуре основной носитель знания — весовой адаптер, а не промпт и не база данных.

Адаптер против промпта

LoRA/QLoRA адаптер — это небольшой набор весов (50–200 МБ) который накладывается поверх базовой модели. Он не читается при каждом запросе — он является частью модели. Знание зашито в веса и остаётся там навсегда.

Промпт забывается в конце контекстного окна. Адаптер — никогда.

RAG работает для справочных данных: регуляторные требования, документация. Но доменная интуиция эксперта — «вот это сочетание признаков означает начало вспышки энтомовредителя» — в RAG не ложится. Это паттерн, а не факт. Паттерны живут в весах.

Цикл дообучения: SFT → DPO

SFT (Supervised Fine-Tuning) — эксперт видит вопрос и правильный ответ, подтверждает или исправляет. Модель учится что делать правильно.

DPO (Direct Preference Optimization) — эксперт видит два варианта, выбирает лучший. Пары chosen/rejected. Модель учится почему один ответ лучше другого.

Вместе это даёт двухконтурное обучение: знание (SFT) + предпочтения (DPO). Модель не просто «знает факты домена» — она рассуждает как эксперт.

Ночной цикл: знания из вчера уже в весах сегодня

К концу рабочего дня в системе накопились логи всех сессий. Отдельная роль — агент обработки логов. Его задача: просмотреть все сессии за день и подготовить кандидатов на обучающие пары — но не финализировать их самостоятельно.

Сначала люди. Оператор с уровня 0 просматривает кандидатов по своим сессиям — калибровки датчиков, аномалии, случаи «не знаю». Эксперт с уровня 3 просматривает кандидатов по своим сессиям — верификации, коррекции координатора, выбор лучшего из двух ответов. Каждый валидирует то, что видел своими глазами в течение дня.

Только после их валидации агент формирует финальные пары для SFT (вход → верный выход) и DPO (chosen vs rejected) и раскладывает по нужным адаптерам.

Ночью запускается QLoRA-дообучение. Утром адаптеры обновлены. Всё что произошло вчера — утром уже в весах. Не в RAG. Не в базе. В весах.

Почему это несовместимо с публичными API

LoRA-адаптер — это изменение весов конкретной модели. У публичных API — GigaChat, YandexGPT, OpenAI — весов нет. Есть только эндпоинт.

Адаптер нельзя «прикрутить» к чужому API. Физически.

Есть кривые варианты:

  • Препроцессинг запроса — дообученная маленькая модель переформулирует запрос. Костыль на входе.

  • Постпроцессинг ответа — маленькая модель фильтрует ответ API. Костыль на выходе.

Оба не решают проблему: основная модель не знает вашего домена. Вся архитектура требует локальной модели под вашим контролем.

Я не против публичных LLM как таковых. Просто понял что это не финальное решение — это инструмент с конкретной ролью.

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

В низкоэнтропийной архитектуре публичные LLM тоже есть — но не в рантайме. Агент обработки логов видит неизвестный паттерн, формирует запрос к публичной LLM, эксперт верифицирует — и только после этого это идёт в SFT/DPO. Публичная LLM расширила доменную модель, но не участвовала в принятии решений.

Разные инструменты для разных задач.

Сколько это стоит железа

Компонент

Назначение

Примерная стоимость

Сервер с RTX 4090/5090

Координатор уровня 2 + ночное дообучение

~600–700 тыс. руб. в сборке (сама карта ~200–250 тыс.)

5–10× Raspberry Pi 5

Модели датчиков уровня 1, непосредственно на объекте

~200–350 тыс. руб.

NAS / накопитель для логов

Хранение сессий для ночного цикла

~100–150 тыс. руб.

Итого железо

~900 тыс. — 1,2 млн руб.


Числа из реального проекта

Цифровой двойник лесной экосистемы, более 180 000 га.

Архитектура полная: лесник на земле калибрует датчики (уровень 0), узкие модели (фитопатолог, энтомолог, гидролог) анализируют каждый свой поток данных (уровень 1), координатор формирует рекомендацию (уровень 2), доменный эксперт верифицирует и корректирует (уровень 3).

При росте площади с 2 000 до 50 000 га — в 25 раз:

  • Капитальные затраты выросли в 2,1 раза

  • Операционные — в 2,2 раза

  • Персонал — с 4 до 8 человек

При традиционном подходе потребовалось бы 20–30 полевых сотрудников.

IRR модели — 83–114% при консервативных допущениях (капитальные затраты 56,7 млн руб., операционные 23,5 млн руб./год, ставка дисконтирования 12%). Это не экономия на увольнениях — это рост производительности на единицу персонала.


Куда это ведёт

Если каждое предприятие строит ансамбль узкодоменных моделей непрерывно дообучаемых экспертами — и эти системы объединить в децентрализованную сеть — получается нечто принципиально иное чем любая существующая LLM.

Не единая модель обученная на тексте из интернета. А тысячи специализированных моделей, каждая из которых обучена на верифицированном опыте практиков в своей области. Знание основано не на статистике текста — а на реальных измерениях и экспертных коррекциях.

Такая сеть в пределе точнее любой универсальной модели в каждом конкретном домене. Не за счёт размера — за счёт качества данных.

Есть и более широкое следствие — но это уже тема отдельного исследования. Универсальные LLM обучены на тексте из интернета: их знание второго порядка, статистика чужих слов о мире. Модели уровня 1 обучены на физических измерениях — они знают температуру, потому что их учили на данных о температуре. Сеть из тысяч таких доменных экспертов — качественно иной тип знания.

Возможно, более правильный путь к сильному ИИ, чем масштабирование GPU.

Но это требует отдельного разговора.


Ограничения — честно

Система не работает без людей. Если нет оператора на нижнем уровне и нет эксперта на верхнем — она не запускается. Для кого-то это проблема, для меня это принцип.

Есть домены где эксперт уровня 3 стоит дороже всей системы — нефтегаз, юриспруденция, редкие инженерные специальности. Там стоимость разметки SFT-пар может не окупиться. Низкоэнтропийная архитектура экономически выгодна прежде всего там где экспертная верификация — часть обычного рабочего процесса.

Система не защищена от коллективного незнания. Если паттерн настолько редкий что его не видел ни один оператор — модель уровня 1 запросит разметку у человека который тоже не знает. Это край, но он существует.

Узкая модель решает вопрос «как» но не «зачем». Если процесс неправильный — система делает неправильное эффективнее. Целеполагание остаётся за человеком.

Первый результат требует 4–8 недель. Это дольше чем «подключить API».


Две архитектуры — два разных мира

Параметр

Высокоэнтропийная

Низкоэнтропийная

Метрика

% задач без человека

Точность при масштабировании

Роль рабочего

Подлежит замене

Нижний контур: калибровка данных

Роль эксперта

Настраивает, потом не нужен

Верхний контур: верификация + обучающий сигнал

Переобучение

Смена профессии

Надстройка ИИ поверх своей экспертизы

Компетенции

Деградируют (deskilling)

Развиваются через верификацию

Зависимость от вендора

Высокая (облачные API)

Низкая (локальные модели)

Масштабирование

Сокращение штата

Расширение зоны деятельности

Реакция на сбой

Человек не готов

Человек готов


Итог

Барьеры между людьми и ИИ — это не проблема обучения и не сопротивление прогрессу. Это следствие архитектуры, заточенной на замену человека.

Когда метрика «% задач без человека» — система оптимизируется на автономность. Ошибки накапливаются скрыто. Компетенции деградируют. Кадровая преемственность разрушается. Пилот работает, в реальном производстве он ломается.

Поменяйте метрику на «насколько точнее работает специалист с этим инструментом» — архитектура меняется полностью. Человек становится несущим элементом, а не помехой. Энтропия сбрасывается на каждом уровне, а не накапливается.

Это низкоэнтропийная автоматизация.

Я работаю над этой проблемой несколько лет — в том числе в рамках реального проекта цифрового двойника лесной экосистемы. Архитектура описанная выше — не теория, а работающая система.


*Расширенная академическая версия опубликована на dtwin.ninja.

ссылка на оригинал статьи https://habr.com/ru/articles/1024350/