Как поставить создание автоматических рабочих процессов на конвейер и снижать стоимость их исполнения по мере накопления опыта.
Зачем создавать параметры, правила и процессы, если можно объяснить задачу сильной генеративной модели? Если она понимает человека, умеет выбирать действия и работать с подключёнными инструментами, дополнительная настройка кажется лишней.
Для некоторых задач так и есть. Разовый анализ, поиск нового подхода или задача с постоянно меняющимися требованиями могут хорошо решаться с высоким участием генеративной модели.
Не рационально нанимать нобелевского лауреата обрабатывать входящие обращения на горячую линию интернет провайдера. Типовую работу, которая повторяется каждый день: приём заявок, сбор сведений, проверку условий, передачу данных во внешнюю систему рациональнее поручать системам, которые умеют не все на свете (и из-за этого потребляют массу энергии и денег на каждую итерацию выполнения процесса), а на что-то, что будет уметь только то, что вы от него хотите.
Способ выполнения повторяющихся типовых операций постепенно становится известен. А раз так, встает вопрос: зачем при каждом новом обращении снова поручать модели решения, которые мы уже нашли и проверили?
В основе идеи Glagol лежит возможность сохранять результат интеллектуальной работы в устройстве самого процесса. Генеративная модель помогает найти способ решения и отлаживать его в процессе. Параметры, правила и программные действия позволяют закрепить его и использовать многократно. Мы называем этот путь кристаллизацией процесса.
Glagol призван помогать получать эти кристализованные маршруты выполнения процесса - структуру. Задачей Glagol становится организовывать путь от первоначальной задачи к проверенному процессу, используя генеративные модели как один из инструментов. Мы развиваем продукт как конвейер кристаллизации, который постепенно берёт на себя работу по разбору задачи, построению решения и его уточнению под воздействием реальной среды.
Почему раньше это требовало столько усилий
Формализовать процесс при помощи Glagol можно было и без ChatGPT (чем мы успешно и занимались, до прихода эры LLM). Для этого нужно подробно разобраться в работе организации: понять каждый шаг, выделить существенные данные, обнаружить скрытые условия и описать исключения.
Не забываем и тот факт, что отдельная задача редко существует сама по себе. Чтобы автоматизировать приём заявки нужно привести в порядок справочники, договориться о статусах, связать несколько систем, определить ответственных и согласовать обработку ошибок. Попытка автоматизировать один участок обнажает целую цепочку смежных операций, которые тоже необходимо изучать и автоматизировать.
Такой путь требует времени, компетенций и готовности организации менять свою работу. Для команды без выделенных аналитиков и разработчиков (или очень эффективных менеджеров) даже простая задача может превратиться в слишком дорогой проект. Объёме работы, который, необходимом для получения хорошо устроенного процесса, часто был запредельный для многих небольших компаний.
С появлением генеративных моделей существенную часть этой работы можно передавать ИИ: разбор исходных материалов, поиск недостающих условий, проектирование шагов, подготовку правил и программных операций, анализ результатов. Однако отдельные ответы модели ещё нужно связать в последовательное создание работоспособной системы.
Задача Glagol - организовать это преобразование и снизить зависимость результата от того, способен ли человек самостоятельно спроектировать каждый узел. Человек задаёт цель, ограничения и критерии приемлемого результата, предоставляет доступ к необходимым сведениям и API. Работа по выявлению структуры и её кристаллизации - это все начинает происходить внутри силовых полей Glagol.
Что значит «кристаллизовать процесс» с помощью Glagol?
В начале мы можем ещё не знать всех существенных условий задачи. Какие сведения потребуются? Какие ситуации будут повторяться? Где человек ответит неоднозначно? Что делать при исключении?
Большая языковая модель помогает работать с этой неопределённостью. В первых версиях агента её участие может быть высоким: она разбирает сообщения, учувствует в выборе следующих шагов, извлекает сведения и формулирует ответы.
По мере работы становится видна устойчивая структура. Оказывается, что для определённого действия всегда нужны одни и те же данные, а часть переходов определяется простыми условиями. Многие операции выполняются одинаково.
Найденная структура получает исполняемую и воспроизводимую формы:
- собранные сведения и состояние работы - в параметрах;
- условия переходов и действий - в правилах;
- известные формулировки - в подготовленных фразах;
- расчёты и обращения к внешним системам - в программных операциях.
Генеративной модели остаются участки, где по-прежнему требуется понимание, интерпретация или поиск решения. Чем реже мы будем обращаться к генеративке, тем эффективнее свою работу сделал Glagol и тем дешевле и устойчивей стал ваш процесс.
Часть интеллектуальной работы переносится из каждого отдельного исполнения в проектирование процесса.
Такой подход позволяет начать с высокой доли генеративного ИИ, а затем постепенно снижать её по мере изучения задачи. Необязательно заранее описывать каждую возможную ситуацию. По мере накопления результатов конвейер должен помогать выделять повторяющиеся решения, переводить их в явную логику и проверять, сохраняется ли нужное качество.
Glagol не только создает кристалл. Glagol - машина, в которой кристаллизованные кристаллы заставляют шестеренки крутиться и выполнять полезную работу.
Создать кристалл процесса — только часть задачи. Вторая часть - обеспечить его работу. Glagol подаёт кристаллу входящие обращения, сохраняет состояние, исполняет правила и программные действия, связывает его с внешними системами и подключает генеративные модели там, где требуется их участие.
Кристалл хранит найденный способ решения, а машина обеспечивает его применение в реальных условиях — снова и снова. При этом условия меняются: появляются новые запросы, исключения, требования. Отчёты и трассировка позволяют увидеть, где прежняя структура перестаёт справляться, а автотесты помогают проверить её изменения перед внедрением. Развиваемый нами цикл калибровки должен всё больше передавать эту работу моделям: анализировать накопленный опыт, предлагать корректировки и проверять их результат.
Пример: как создается и меняется агент приёма заявок
Компания принимает заявки на обслуживание. Агенту нужно выяснить причину обращения, собрать необходимые сведения и по завершении диалога передать информацию во внешнюю систему + сообщить результат.
В первой версии мы можем поручить значительную часть диалога LLM: объяснить цель и задачи, предоставить данные и описать доступные действия. Такая версия помогает проверить идею и увидеть разнообразие реальных обращений.
Затем выясняется, что многие решения повторяются. Для оформления заявки нужны определённые поля. Отсутствующее поле следует уточнить. Передавать данные нужно в установленном формате. Успех следует сообщать после подтверждения внешней системы.
Постепенно обязанности распределяются точнее:
| Участок работы | Что можно закрепить | Где остаётся полезен генеративный ИИ |
|---|---|---|
| Понимание обращения | Набор существенных сведений и вариантов запроса | Понимание свободной речи и извлечение значений |
| Сбор данных | Учёт заполненных полей и условия следующего вопроса | Разбор неоднозначного ответа или встречного вопроса |
| Отправка заявки | Формат запроса и условия его выполнения | Участки интерпретации, если они требуются задаче |
| Обработка результата | Проверка ответа системы и переход в соответствующее состояние | Объяснение нестандартной ситуации |
| Совершенствование агента | Накопленные результаты и проверочные сценарии | Поиск повторяющихся проблем и предложения по изменению процесса |
Далее на базе Glagol начинает происходить кристаллизация процесса. Часть параметров уводятся в re, jev или fts активацию. Процент вызовов сильных LLM моделей снижается. Доля ответов на заранее подготовленных фразах увеличивается.
Итог - снижение зависимости процесса от внешних систем с возможностью полного отказа в некоторых случаях (а как следствие, значимое снижение стоимости, повышение отказоустойчивости и скорости реагирования процесса).
Glagol задаёт силовые линии кристаллизации
Однако если поставить LLM задачу "сделай хорошо", то на длинной дистанции она может произвести больше проблем, чем пользы.
Чтобы этого не допустить внутри Glagol существует система силовых линий, которая обеспечивает с одной стороны безопасность в автоматической отладке процесса, а с другой позволяет прийти к конечному результату как можно быстрее. У этой метафоры есть конкретный смысл:
- Исходные вводные определяют задачу, доступные данные, инструменты и ограничения.
- Точки притяжения задают признаки нужного результата: какие случаи процесс должен обрабатывать, что считается успехом, какое качество требуется и какие расходы допустимы.
- Формы исполнения - параметры, правила, фразы и программные операции - позволяют закреплять результаты работы моделей в устройстве агента.
- Давление среды проявляется через реальные обращения, результаты внешних систем, ошибки, затраты и изменения требований. Оно показывает, какие решения выдерживают проверку практикой и что необходимо пересмотреть.
В этом цикле генеративная модель получает конкретную работу: выявить недостающие условия, предложить структуру, разобрать неудачные исполнения, найти повторяющийся участок или подготовить его более экономную реализацию. Программные операции и проверки используются там, где они лучше подходят задаче. После каждого изменения результат снова сопоставляется с заданными критериями.
Целевое свойство Glagol - делать кристаллизацию закономерным результатом организованного цикла работы с задачей. Проверенное решение сохраняется, обнаруженное отклонение становится основанием для следующего изменения, а критерии результата удерживают направление всей работы.
Сходимость к «кристаллу» здесь - принцип проектирования продукта. Она предполагает задачу с достижимым результатом, необходимые данные и возможность проверить качество; одна архитектура не может гарантировать решение любой произвольной задачи.
Откуда берётся экономия
У этого подхода две экономические цели: уменьшить трудоёмкость создания рабочего процесса и снизить стоимость его повторных исполнений за счёт уже закреплённых решений.
Первая связана с сокращением ручного разбора, согласования и проектирования каждого шага. Вторая - с уменьшением потребности заново решать типовые задачи во время работы агента.
Каждое обращение к генеративной модели требует вычислений. В зависимости от устройства агента ей может потребоваться обработать инструкции, историю, данные инструментов и затем сформировать ответ или решение.
Если часть работы уже однозначно определена, появляется возможность выполнить её без нового генеративного запроса.
Кристаллизация даёт несколько способов уменьшить расходы:
- Сократить число вызовов. Проверка известного состояния или выполнение готового действия не всегда требуют участия модели.
- Уменьшить объём контекста. Для ограниченной задачи можно передавать только необходимые сведения, если их достаточно для правильного решения.
- Выбирать модель под участок работы. Узкая задача иногда допускает менее дорогую модель при сохранении нужного качества.
- Повторно использовать найденный алгоритм. Проверенные расчёты, преобразования и запросы можно исполнять программно.
Затраты на выяснение и настройку способа работы распределяются между множеством последующих исполнений. Чем чаще применяется устойчивая часть процесса, тем больше возможностей окупить её формализацию. Конвейерное создание дополнительно должно уменьшать саму цену, которую приходится заплатить за получение этой структуры.
Но нужно не забывать, что токены - только часть экономики. Нужно учитывать настройку, инфраструктуру, внешние сервисы, сопровождение и исправление ошибок. Увеличение количества отдельных запросов к моделям тоже может свести экономию на нет.
Поэтому основной показатель - стоимость успешно выполненной задачи при заданном качестве. Снижение потребления токенов полезно, когда оно помогает улучшить этот показатель.
При этом мы не забывает, что иногда один дополнительный вызов модели выгоднее десятков сложных и хрупких правил и стремимся к балансу.
Кристалл процесса: компактная готовая способность
Целевой образ - небольшой процесс, который получает определённый класс входных данных и добивается требуемого результата. Его можно встроить в конкретный участок работы: обработку обращений, оформление заявок, сбор сведений или взаимодействие с другой системой.
Условно такой процесс можно назвать макронейроном в реальном мире: готовым блоком, который принимает определённые входные данные и выполняет законченную задачу. Это метафора; реализация может сочетать правила, программный код и обращения к моделям.
Идеал - кристалл, через который проходит подавляющее большинство типовых случаев. Образ «99% типовых входов» выражает это направление развития. Реальная доля зависит от конкретной задачи и должна подтверждаться проверками.
Компактность здесь означает отсутствие ненужных действий и рассуждений. Процесс должен сохранять достаточно гибкости для своей задачи и иметь предусмотренный путь обработки неизвестной ситуации. Для одних участков генеративное участие можно почти убрать, для других оно останется существенным.
Сильные модели оценивают и калибруют систему
По мере кристаллизации у генеративного ИИ появляется работа над процессом в целом.
Модель может помогать анализировать накопленные результаты: какие обращения заканчиваются неудачей, где люди вынуждены повторять информацию, какие исключения стали частыми, какие условия больше не соответствуют действительности.
Даже безошибочно работающий процесс может устареть. Изменился продукт, появились новые потребности клиентов или другой критерий успешного результата - значит, способ работы нужно пересмотреть.
В целевой архитектуре Glagol есть два взаимосвязанных уровня:
| Уровень | Основная работа |
|---|---|
| Исполнение на местах | Обрабатывать типовые входы, сохранять состояние, выполнять предусмотренные действия; обращаться к модели там, где это необходимо |
| Макрооценка и калибровка | Изучать результаты и изменения среды, находить слабые места, предлагать улучшения и помогать проверять новую версию процесса |
Мощную модель может быть выгодно привлекать для оценки серии исполнений и поиска одного улучшения, которое затем используется во всех следующих обращениях. Интеллектуальная работа получает многократное применение.
Предложенные изменения должны проверяться перед внедрением. Сам факт участия сильной модели не делает новую логику правильной. Участие человека не исключается полностью, именно он должен принимать решения в спорных ситуациях и корректировать вектор развития кристалла.
Описанный конвейер - целевой образ развития Glagol. Его зрелость определяется тем, какую часть разбора, проектирования, проверки и калибровки продукт способен выполнять без ручной работы на каждом шаге.
Какую роль в этом играет Glagol
Собрать подобную систему можно и собственным кодом (ценой сотен часов разработчика и кучей сломанных копий). При этом придётся организовать и её исполнение, и сам путь получения работающей структуры: поставить задачи моделям, связать их результаты, подготовить проверки и наладить обратную связь.
Glagol связывает параметры, правила, фразы, программные операции и обращения к моделям в одном агенте. Это позволяет постепенно менять распределение работы: закреплять изученные участки и сохранять генеративное участие там, где оно полезно. Отчёты, трассировка и автотесты помогают проверять такие изменения.
Правила и параметры становятся формой сохранения опыта. Наблюдение за работой и проверочные сценарии помогают убедиться, что при очередном упрощении этот опыт не потерян.
Следующий уровень ценности - эффективно, предсказуемо и быстро доводить исходную задачу до такого процесса.
Важно понимать, что это не исключает участия человека. Его внимание необходимо как на этапах формирования целей работы конкретных агентов, так и при отладке/оценке формирующегося агента в процессе.
Когда этот подход оправдан
Кристаллизация особенно интересна там, где задача повторяется и правильный результат можно определить и проверить. Это создает основу для многократного использования одной и той же структуры.
Для редкой, исследовательской/быстро меняющейся задачи глубокая формализация не окупится. Высокое участие генеративной модели в таком процессе может оставаться разумным выбором и мы не претендуем на участие кристаллов Glagol в этих процессах.
Практический путь - начать с исходной задачи и доступных материалов, получить первую работающую версию с высоким участием моделей, использовать результаты её исполнения для дальнейшей кристаллизации. Цель продукта - последовательно сокращать необходимую для этого ручную работу. Усложнение настроек должно оправдываться качеством результата или снижением совокупных расходов.
Glagol и чаты на базе GPT дополняют друг друга: сильные модели помогают находить и пересматривать решения, Glagol организует их превращение в исполняемую структуру. Итоговые компактные процессы (кристаллы) многократно выполняют работу на местах, экономя деньги пользователей и повышая стабильность процесса.
Умные системы помогают делать массовых недорогих агентных исполнителей на местах. Именно такой результат мы хотим создавать с помощью Glagol.