Цепочка возрастания ответственности (про риски, и про AI)
Про математику и мат.статистику, которую не на_бёшь. Про то, как копятся риски, если их вовремя не обрабатывать (или просто некем, если вы фанат AI-интеграций).
Знаете, есть такой бородатый анекдот родом из девяностых:
— этот компьютер возьмет на себя 50% твоей работы!
— отлично, дайте два!
К 2026 году мы, как индустрия, получили штуку в виде AI, которая неплохо справляется с какими-то прикладными задачами. Задачи обычно укладываются в описание «текст на входе, текст на выходе», что полностью логично — это именно то, чем занимаются нейросетевые генераторы текста. Аббревиатура GPT, кто забыл, означает архитектуру «генеративный предиктивный трансформер». Трансформер текста.
Два класса задач, которые убедительно получили выигрыш в этой связи
- генерация текста, будь то читаемый связный нарратив, программный код, отчеты или просто теоретизирования
- распознавание человеческого текста в неопрятной форме, то есть написанное в формах, сказанное вслух или найденное в интернетах
С какой-то долей применимости вышеозначенные классы задач можно заменить на программного агента. Или несколько. Выигрышным (для автоматизации) моментом можно назвать и то, что огромная доля интерфейсов для взаимодействия любых систем в нашем мире изначально текстовая. Даже HTTP, квартальная отчетность или интерфейс «Наташенька, подготовьте решение, пожалуйста».
Можно — не значит нужно. Потому что к выполненной задаче обычно прилагается такая штука, как ответственность за ее выполнение.
- если мы хотим, чтобы код был написан, значит нам от него потребуется применимость, выполнимость, качество и прочие формальные штуки
- если мы хотим, чтобы квартальные отчеты решили поставленную задачу, значит в них должна быть написана не херня
- если мы хотим, чтобы «Наташенька подготовила решение», значит нам нужно получить не просто абы какой выход, а что-то отдаленно напоминающее это самое решение
Здесь фундаментальный затык. Потому что программная система или железный агент нам ничего не должен. И никому, в общем-то, ничего не должен. То, что сетка решает 89% процентов тестовых задач тестовой выборки с ответами, напоминающими правильные — ничего не гарантирует относительно реальной поставленной задачи, вот этой, в этом контексте и в этот момент времени.
Приходится полагаться на статистику. Причем чужую.
Для простоты мы (даже) можем говорить про статистику «одноразового» решения — и даже там 89%, и даже 99% не равны 100%. Вопрос цены ошибки. Шанс в 1% обосраться на 1 миллион зеленью уже не выглядит сильно надежным, предсказуемым и допустимым для большого класса прикладных задач.
Есть баянистый пример про конфетки:
В одной миске 100 конфеток, неотличимых друг от друга. В другой миске также 100 конфеток, также неотличимых. Но мы точно знаем, что одна из конфеток во второй (1%) = смертельно отравлена.
Желающих стырить конфетку из второй миски будет совсем немного.
У нас есть метрика риска. Спасибо примеру, наглядная. Давайте перенесем эту концепцию на процессы и на умозрительную систему. В которой 10 акторов, 10 выполняемых задач, и каждая из них может продолбаться с шансом 1% и выставить нас на $1m.
- у нас есть риск в (1% х 10 =) 10%, что любой из рисков триггернет (минус $1m)
- у нас есть риск в 0,1%, что триггернут все одновременно (минус $10m)
- и какое-то распределение между ними.
Будет кривая с привкусом Эйлера (на бумаге), но на практике риски бывают взаимосвязанными и взаимо-исключающими, так что здесь перекос «в нашу пользу» (например, при уже триггернувшем 1% нам нет смысла проверять и рисковать остальными 9%).
Очевидно, что в реальной жизни мы как раз хотим риски друг от друга отвязать, дифференцировать, ограничить и даже друг об друга сторнировать. Чтобы вероятность наступления композитного worst case с его 0,1% и минус $10m была как можно меньше.
Для этого мы изолируем задачи друг от друга; риск не выполнить одну проблемную задачу и не_встрять на $1m нам явно выгоднее, чем разбираться с последствиями и огребаться по сумме на $10m.
Вопрос: а в какой момент и кем мы это проверяем?
Кто и как несет за это ответственность?
Предположим, мы в том же сетапе заменили 10 исполнителей 10 задач на, соответственно, 10 групп программных агентов. Которые дали нам что-то, что похоже на решение задач. С уверенностью в суммарно 90% — или, если считать «наоборот», с риском облажаться в 10%.
Решение и получение результата дифференцировано. А его оценка = нет.
В результате тот человек, которому потребуется принять и применить готовые 10 решений, должен будет в моменте решить достаточно неприятную задачу: оценить 10 решений разом, с риском в 10% обосраться на $1m, или с риском в 0,1% обосраться на $10m. Потому что риски накопились, никуда не делись, и никем в этой цепочке не обработаны.
Если бы риски, напротив, обрабатывались сепаратно и по отдельности (а не по сумме и по факту в конце цепочки), то цена ошибки была бы 1%, а не 10%. И «стоимость риска» не превысила бы $1m, потому что одна проблемная задача исключает накопление рисков.
Чтобы понимать фундаментальную разницу между 1% и 10%, просто напомню, что вероятность выигрыша (х36) в рулетку составляет 2,7%.
В бизнесовых терминах, если у вас где-то процессный совокупный риск более 2,7%, то вам выгоднее в казино пойти.
Вот у нас горе-оптимизаторы заменили 10 разработчиков на 10 AI-агентов. Остался один горе-руководитель, которому надо принять ровно одно финальное решение.
У него риски и нагрузка, по оценке ответственности, выросли с 1% на +9%, = 10%, в 10 раз. Зарплата если он наемный работник, как обычно, в 10 раз не выросла. Мозгов и внимания в 10 раз точно не прибавилось.
Налицо бутылочное горлышко, причем очень тонкое — сразу по нескольким факторам. Оценивать черный чужой ящик, на глаз, и затем нести за него ответственность самому = дураков мало.
Попытка «выиграть за счет скейла» тоже в такой постановке задачи скорее мешает, чем помогает.
Предположим, вот у вас был человек, который решает задачи из джирки. Код пишет. Отдаёт на ревью умному тимлиду. Человек решает 1 задачу в единицу времени, с выходом корректного результата в 95%. 5% ошибки, которые на ревью находит умный тимлид. Это его задача и ориентир по нагрузке контроля.
Мы можем заменить человека (5% fail) на модель (10% fail). Но модель же умеет «писать код» в параллель. Давайте возьмем их 10! Вон сколько задач решат, ну.
Нагрузка на «умного тимлида» по части проверок и ревью возрастает с 5% до (10%х10% =) 100% в условных единицах время-затрат.
В двадцать, суко, раз. По весьма сложной задаче.
Чтобы не наговаривать излишне на агентов и AI (я не являюсь AI-хейтером, просто прагматик и люблю считать деньги), в такой постановке задачи можно заменить иллюстративных исполнителей на джунов-индусов.
Суть та же: выход есть, ответственности ноль, за риски никто не отвечает, пока отдельный человек не пойдет и не проверит.
Почему-то в 2000-2010 все быстро поняли, что так работать с индусами нельзя. На точке финальной принятия ответственности сразу вырастает проблемный и неприятный перекос, чреватый граблями и потерями денег.
— Но проблем май фрьенд, ай вилл ду экзактли эз ю сей, ноу ворриез.
Даже в обозначенном примере, что нам надо сделать, чтобы получить хотя бы те же показатели по рискам, в одной ключевой точке?
Ответ = снизить риски по отдельным компонентам, с 1% до 0,1%.
Тогда математика суммы остается прежней; как минимум прежней, то есть мы заебались по качеству на х10, что вообще-то весьма дорого, просто для того, чтобы суммарно остаться на том же месте.
Чот пока так себе выигрыш. Если вы можете по каждой решаемой задаче запросто, по щелчку пальцев, поднять гарантии в 10 раз, то что вам мешало пойти и именно это сделать прямо сейчас?
Исторически грамотный и корректный путь снижения рисков — инженерный/процессный. У нас по каждой решаемой задаче есть технология ее решения, с вот такими ожидаемыми показателями по риску. По худшему случаю, и уже заранее проверенными и оцененными цифрами.
Если мы применяем технологию, и делаем это корректно, то мат.ожидание вот такое. Если мы нарушаем технологию, то ебёмся сами.
Ответственность за применение технологии, и за соответствие ей, можно проверить. У грамотной технологии для этого предусмотрен инструмент.
Для автоматизации и даже AI, в общем-то, применяется аналогичный путь: вводи технологии, технологические карты с балансировкой, контуры проверок на каждом отдельном этапе. Добавляй приёмку, формальное тестирование, ОТК, выборочный контроль, кросс-проверки и отдельные проверяющие механизмы. Да хоть черную магию; всё, что ты можешь выжать из средств автоматизации и инструментов, чтобы от 1% риска перейти к 0,1%.
Но, тот же вопрос: если (бы) это было так просто сделать, то кто мешает сделать и внедрить всё означенное прямо сейчас? Без игрищ в автоматизацию, а прямо там где есть.
С точки зрения агентских инструментов нам опять всё подсирает статистика. Топовые модели показывают нам 89%. Но это оценочные данные статистические — окей, предположим мы им верим. 11% процентов зоны риска мы можем митигировать другой системой, проверочной; у которой тоже 89% качества, и даже в идеальном случае они обе точно обосрутся на (0.11*0.11)= 1,2%. Вес идеального случая положительного будет (0.89*0.89)= 79%.
Разница между 79% и 99% уходит в какую-то серую зону комбинаторики.
А 20% это достаточно дофига неопределенности.
Если мы продолжаем плодить комбинации, то вероятность гарантированно негативного кейса снижается. А вот «зона неопределенности» растёт.
10 агентских систем с топовым 89% это всего (0.89^10)= 31% (!!!) гарантии результата. Или 70% неопределенностей.
Ваш бизнес готов работать с 70% неопределенностей по рискам?
Если да, то удачи, очень рад за вас.
Честно скажу, я такое даже видел. Когда шанс получить что-то применимое, с вероятностью в 31%, гораздо лучше «полного нуля» если нихера не делать, и цена ошибки пренебрежимо мала.
Это сфера прототипирования, стартапов, экспериментов. С вероятностью в 1/3 ты получишь на выходе что-то осмысленное и подходящее, затратив на это сколько-то фикса денег на агентов.
Следует вслух внятно сказать тогда, в этой связи, что на ответственность за результат, и за его качество, и на риски все положили жирного болта. Вам не надо, вам шанс потенциального профита важнее шанса обосраться, или просто его не-получить. Окей, acceptable для ряда задач.
И как инженер (раз), и потому что есть еще unknown unknowns которые никто не оценил, и не заложил в модель (два).
Что надо из описанного вынести:
- если не обрабатывать риски, то риски копятся в распределенной системе, и поднимаются «выше» до точки принятия решений
- ответственность принятия ключевого решения с кратно возросшими, накопившимися рисками и неопределенностями — сложная, болезненная и непростая (сюрприз: рисковая!) задача
- AI ничего не знает про ваши риски, и ответственности за результат у него нет (и быть не может), а есть только статистика
- люди в «точке принятия решений» разруливать кратно возросшие риски и неопределенности (например, из-за AI или индусов, или фрилансеров, или аутсорсеров) точно не подписывались, и обычно не готовы