Хорошее внедрение ИИ начинается с вопроса "А зачем ИИ?" #2
В первой части мы с вами разобрали, почему предложенная балльная шкала автономности не обоснована как инструмент принятия решений. Но, допустим, критерии определены точно, а пороги проверены автором “на практике”. Решит ли это главную задачу?
Нет, потому что оценивается решение, а не исполнитель.
Повторяемость, качество данных, последствия ошибки, обратимость и возможность контроля описывают прежде всего характер задачи и условия ее выполнения. Но они не показывают, способен ли конкретный ИИ выполнять ее надежно.
Давайте представим себе две системы, формирующие заказы по одинаковым правилам. Одна устойчиво обрабатывает исключения и соблюдает лимиты. Другая регулярно ошибается при нестандартном спросе. Для обеих предложенная шкала даст одни и те же баллы: свойства задачи не изменились. Из чего тогда следует разрешение на автономные действия? Из суммы, не учитывающей качество исполнителя?
Павел рекомендует несколько недель сравнивать решения ИИ с результатом и постепенно расширять его полномочия. Сам принцип проверки звучит разумно, но он не устраняет исходную проблему: шкала присваивает уровень автономности еще до оценки фактической надежности системы. В лучшем случае она помогает предварительно отобрать задачи для дальнейшего исследования. Очевидно, что это полезно, но при этом это далеко не то же самое, что определить допустимую автономность ИИ.
А еще надежность нельзя заменить общими словами.
Для делегирования полномочий нужны измеримые требования к “правильности” решений, допустимой частоте и тяжести ошибок, обработке исключений, соблюдению ограничений и действиям при ухудшении качества. Причем проверять здесь надо не модель “в изоляции”, а работающий контур: исходные данные, интеграции, правила запуска, регистрацию действий, мониторинг, остановку и передачу человеку. Иначе можно получить формально безопасную “задачу на 12 баллов”, в которой конкретная система действует абсолютно непредсказуемо.
А теперь к главному вопросу, который автором вообще не задается.
Все перечисленное мной в первой части и выше - это еще не самая интересная проблема. Павел в числе прочего как пример рассматривает автоматическое пополнение запасов: известны остатки, расход, сроки поставки, минимальный запас и лимиты. Система рассчитывает потребность и формирует стандартный заказ.
У меня возникает вопрос, который обычно вызывает дикую тряску в сообществе продавцов ИИ-чудес: а зачем здесь именно ИИ?
Такие операции давно автоматизируются ERP, MRP и специализированными системами управления запасами. Если правила известны, входные данные структурированы, а исключения определены, то обычный алгоритм может оказаться более прозрачным, предсказуемым и экономичным. Возникает парадокс: высокая повторяемость и стандартизированность повышают “балл автономности ИИ”, хотя одновременно могут свидетельствовать и в пользу… традиционной автоматизации. Само наличие подходящей для автоматизации операции еще не доказывает необходимости ИИ. Но сравнения технологических альтернатив методика Павла как-то не предусматривает.
Не с того начинается и управленческое решение.
Операционный директор управляет эффективностью, качеством, стоимостью, устойчивостью и рисками процессов, а не количеством полномочий, выданных технологиям. Корректная последовательность начинается с определения проблемы и целевого результата, затем устанавливаются ограничения и критерии успеха и только потом сравниваются варианты: изменение процесса, организационные меры, обычная автоматизация, ИИ или их сочетание.
Лишь после выбора решения имеет смысл определять, какие действия выполнять автоматически, где нужен человек и какие ограничения обязательны. В обсуждаемой конструкции выбор ИИ уже сделан за рамками методики, остается решить, сколько самостоятельности ему предоставить.
Итог
Критерии Павла могут служить отправной точкой для разговора о рисках делегирования, но они не заменяют оценку надежности системы и не обосновывают сам выбор технологии. Хорошее внедрение ИИ начинается не с вопроса “Что ему поручить?”, а с вопроса:
“Какую проблему мы решаем и зачем нам здесь именно ИИ?”
· 5 ч
Ох, почему вы упорно сводите мою критику к требованиям научной валидации и отраслевой стандартизации, которых я не предъявлял? При этом вы обходите гораздо более серьезный вопрос: потенциальные последствия буквального применения ваших рекомендаций. В своей статье вы предлагаете оценивать решения по шкале, сопоставляете баллы с уровнями автономности, а затем рекомендуете начинать с высокооцененных действий, устанавливать ограничения и несколько недель проверять результаты. При этом сама шкала у вас не учитывает фактическую надежность конкретной системы ИИ, а порядок обязательной проверки до предоставления полномочий вами не определен 😌 Следовательно, руководитель, буквально следующий вашим рекомендациям, может разрешить системе самостоятельные действия на основании произвольно установленных баллов и порогов, не получив предварительного подтверждения ее пригодности. Это уже не вопрос научной валидации, Павел. Это вопрос операционных рисков, создаваемых самой процедурой. Вы вправе называть инструмент предварительным фильтром, эвристикой или методикой, но название не меняет его содержания и возможных последствий его применения. Именно поэтому я неоднократно и спрашиваю: чем обоснованы ваши критерии, пороги и переходы между уровнями автономности? Когда публикуется практическая рекомендация, потенциально влияющая на реальные управленческие решения и ресурсы организации, ссылка на ее предварительный характер не заменяет требований к обоснованности и безопасному порядку применения. Вы уже несколько раз объяснили, чего ваша методика не предполагает, но так и не ответили, почему руководитель должен считать предложенный вами порядок оценки достаточно надежным даже для предварительного определения границ автономности.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён