Практическая рациональность.

Оглавление

Постановка задачи

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

Рамка включает вопросы:

• какие факторы среды привели к появлению агентов и почему?
• какой тип организации деятельности переносится в систему?
• что является объектом автоматизации?
• какие архитектурные искажения возникнут?

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

Это поможет лучше понять суть агентов и заодно проверить саму модель.

Модель развития автоматизации

Кратко напомню о модели (подробнее в прошлой статье).

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

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

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

Структурный предел — драйвер начала нового цикла и переноса в систему нового типа организации деятельности.

Исторически мы наблюдали два таких цикла:

• 1-й цикл: автоматизация действий → EAI → SOA;
• 2-й цикл: BPM → DCM, DM.

К моменту появления агентов автоматизация находилась в зрелой завершённой форме 2-го цикла, что соответствовало архитектурной парадигме DCM + DM.

Автоматизация к моменту появления агентов

Согласно нашей модели, агенты должны появиться как механизм снятия структурного предела предыдущего цикла, поэтому для прояснения механики их появления необходимо рассмотреть логику развития этого цикла и выявить проявление его структурного предела. Кратко.

Развитие 2-го цикла автоматизации

Второй цикл автоматизации начался с переноса в систему процессов на этапе BPM.

Основной предпосылкой было предположение, что деятельность можно достаточно полно представить в виде формальной схемы, а отклонения от неё будут редкими и не смогут существенно повлиять на эффективность такой архитектуры.

Однако на практике стало понятно, что это предположение оказалось неверным:

• исключения оказались не такими уж редкими, и их нельзя было игнорировать, а попытка их учесть приводила к резкому усложнению схем;
• некоторые ситуации вообще не удаётся формально описать (предел формализации).

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

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

Параллельно этому развивалась и парадигма DM, которая вынесла формализованную часть решений в отдельный слой.

Завершённая форма архитектуры

Комбинация DCM + DM довела 2-й цикл до зрелой формы: архитектура эффективно представляла деятельность на своём уровне и не имела острых внутренних противоречий.

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

И здесь принципиально важно различать два разных случая:

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

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

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

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

Поясним на примерах, откуда берётся этот неустранимый остаток:

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

Что остаётся на человеке

В рамках архитектуры DCM/DM на человеке неустранимо остаётся та часть деятельности, которая на практике не поддаётся формализации.

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

В этих условиях деятельность не может строиться на готовой схеме. Она требует интерпретации ситуации и выбора действия по ходу работы. Эту способность мы называем практической рациональностью. Именно этим и занимается человек в зрелой архитектуре 2-го цикла.

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

Она — инструмент для работы с практической неопределённостью.

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

Давление среды

Неопределённость присутствовала в деятельности всегда, но её роль со временем возрастала, что фиксируется как в отраслевой практике, так и в исследовательской литературе по BPM.

Это было вызвано следующими основными причинами:

• давлением рынка:
• ростом ожиданий клиента — персонализация, эмпатия, «вникание» в ситуацию клиента;
• ростом скорости изменений — «сжатие» времени; правила меняются быстрее, чем мы их автоматизируем;
• структурным усложнением деятельности компании:
• сквозные процессы;
• локальная оптимизация и конфликты целей;
• неоднозначность и динамичность приоритетов, границ ответственности, целей;
• ростом объёма и разнообразия данных;
• выход процессов за пределы компании — к клиентам и партнёрам.

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

Если короче: бизнес и рынок больше не могут работать в рамках нескольких стабильных «правильных» сценариев. Основная конкурентная сила сейчас — это умение первоклассно работать с теми сценариями, которые раньше были «мусорными» отклонениями. Исключения все больше становятся правилом.

С другой стороны, внешняя среда заставляет постоянно искать способы дальнейшего повышения эффективности деятельности. Применительно к циклической модели развития автоматизации, это проявляется двояко:

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

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

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

Структурный предел архитектуры DCM/DM

Рост неопределённости приводит к росту интерпретационной нагрузки, а поскольку она возложена на человека, то он постепенно становится узким местом системы. Это проявляется как:

• деградация экономики автоматизации — нужно больше людей;
• возникновение барьеров для масштабирования — человек перестаёт масштабироваться вместе с системой.

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

Проблема не в том, что нужны более сложные процессы или правила. Проблема в том, что есть архитектурный остаток, который не может быть автоматизирован через формализацию (процессы и правила) и он остаётся на человеке, а человек перестаёт с этим справляться. Изменения процессов не могут снять интерпретацию с человека.

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

Это признак структурного предела архитектуры 2-го цикла.

С точки зрения повышения эффективности получаем то же самое: поскольку зрелая архитектура второго цикла уже в основном исчерпала возможности дальнейшей оптимизации в пределах собственной логики, значимый рост эффективности может быть достигнут за счёт переноса в систему того остатка деятельности, который всё ещё на человеке. В зрелой DCM/DM-архитектуре таким остатком является интерпретационная работа.

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

Но одного структурного предела для такого переноса недостаточно — нужна и технологическая возможность.

Её дали LLM: они впервые позволили системе работать не только по заранее заданной схеме, но и с не до конца определённой ситуацией.

Это совпадение трёх условий: интерпретация стала критически важной, появилась технологическая возможность для её автоматизации и исчерпание потенциала для дальнейшей оптимизации — и создаёт импульс для перехода.

Практическая рациональность как объект автоматизации

Объект автоматизации — это то, что на данном этапе становится основным предметом переноса в систему и фокусом архитектурного изменения.

В данном случае объектом автоматизации становится не просто ещё один класс задач. Им становится та интерпретационная работа, которая в зрелой архитектуре 2-го цикла остаётся на человеке и под давлением среды превращается в системное узкое место. Иначе говоря, новым объектом автоматизации становится практическая рациональность.

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

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

Новый цикл автоматизации

Согласно нашей модели развития автоматизации, мы имеем дело с переносом в систему нового типа организации деятельности. А это означает не просто уточнение архитектуры предыдущего цикла (DCM/DM), а начало нового, третьего цикла развития автоматизации:

• 1-й цикл: автоматизация действий → EAI → SOA;
• 2-й цикл: BPM → DCM, DM;
• 3-й цикл: Агенты → ...

Этот цикл:

• переносит в систему интерпретационный тип организации деятельности, в котором соответствие между ситуацией и действием устанавливается через интерпретацию и формирование структуры ситуации в ходе работы;
• находится в пределах уровня организации деятельности «ситуация» — работа по-прежнему ведётся с ситуацией как с целостностью, только меняется носитель интерпретации — теперь это агент, а не человек;
• начинается с этапа агентной автоматизации.

Согласно модели, циклы развиваются по схеме:

перенос → разрыв → коррекция → стабилизация.

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

Теперь мы можем добавить в нашу общую схему развития автоматизации новую строку.

А что, если бы LLM появились раньше?

Тезис: агенты возникли не потому, что появились LLM, а как естественный этап развития автоматизации — может показаться слишком сильным. И для этого есть некоторые основания. Попробуем разобраться.

Проведём мысленный эксперимент: что, если LLM появились бы 25–30 лет назад, когда ещё не было никаких структурных пределов? Возникли бы агенты?

Агент — это не просто тот, кто интерпретирует, это ещё и тот, кто получает информацию и действует. Но как он мог бы это делать, в условиях, когда нет API, когда неоткуда получить информацию и нечем управлять? Поскольку нет автоматизированных источников данных, бизнес-операций и процессов?

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

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

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

Выводы

Подведём итоги:

• агенты — это не очередная технология, это закономерный этап развития автоматизации;
• их возникновение вызвано структурным пределом 2-го цикла, проявившимся под давлением среды:
• рост интерпретационной нагрузки на человека;
• необходимость дальнейшего повышения эффективности за пределами возможностей зрелой архитектуры DCM/DM;
• агенты начинают новый цикл развития автоматизации, который переносит в систему интерпретационный тип организации деятельности;
• объект автоматизации агентов — практическая рациональность;
• агенты являются архитектурной формой её реализации в системе.

Отсюда практический критерий: агент нужен там, где есть практическая неопределённость. Там, где её нет — достаточно уже существующих инструментов.

Возникает вопрос: если агент переносит в систему то, что ещё оставалось на человеке, то означает ли это, что агент полностью заменит человека?

Этим мы займёмся в следующей статье.