Бизнес — это потоки данных
Когда я занимался ИИ-трансформацией Сбера, поле моей работы уже было описано.
В компании было более трех тысяч процессов, включая совсем небольшие. Каждый был описан в нотации BPMN.
Директор по данным каждого блока отвечал за цифровизацию своих процессов. Директор по искусственному интеллекту — за внедрение в них ИИ.
Отдельный центр координировал эту работу на уровне всей компании.
Передо мной уже находилась карта бизнеса. Нужно было оцифровать процессы, понять, где применить ИИ, и встроить его в общую систему.
Но в большинстве компаний такой карты нет.
Основателю часто кажется, что он и так знает, как работает его бизнес. Однако при анализе выясняется, что сотрудники выполняют процессы совсем не так, как он себе представляет.
Например, он уверен, что у него многое автоматизировано. А в реальности сотрудники продолжают делать все вручную.
Поэтому я смотрю на компанию не как на набор отделов, а как на систему потоков данных.
Возможно, это мое профессиональное искажение, так как я начинал карьеру как инженер данных.
Для меня не так важно, что находится передо мной: экономический прогноз, HR-процесс, маркетинговое исследование, продажи или разработка продуктов.
В любой предметной области есть входящие данные, последовательность операций, точки принятия решений, результат и связи с другими процессами.
Предметная область меняется, но общая логика остается неизменной.
Нужно видеть сквозные цепочки создания ценности.
Если продукт или сервис предназначен для внешнего клиента — это основной бизнес-процесс.
Если сервис нужен сотруднику или другому подразделению — это поддерживающий процесс.
Но в обоих случаях мы создаем и передаем кому-то ценность.
Поэтому объектом анализа должен быть весь процесс целиком. И уже внутри него нужно находить функции, влияющие на конечный результат.
Современную компанию можно представить как матрицу.
По горизонтали находятся процессы — потоки данных, ведущие к конкретному результату.
По вертикали — функции, которые вызываются внутри процессов в определенном порядке. Одна функция может использоваться в нескольких процессах и по-разному влиять на их результат.
Именно такое мышление я хочу сформировать у вас этим курсом.
Представьте полностью автоматизированную компанию.
В ней уже нет привычного разделения на маркетинг, продажи, HR и другие отделы.
Есть сквозной процесс, который создает и доставляет клиенту то, что ему нужно.
Важно не название подразделения, а то, насколько правильно работает каждая функция и как она встроена в общую цепочку создания ценности.
Еще я заметил одну закономерность.
Основатели, которые любят свое дело и живут им, относятся к бизнесу как к системе.
Они уважают себя, свое время и то, что создают. Поэтому превращают компанию в отлаженный механизм, освобождают себя от операционки и становятся архитекторами системы.
Как по мне, сегодня это и есть главная задача основателя — быть архитектором цепочки создания ценности.
Основатели, для которых бизнес остается только способом зарабатывать деньги, иногда не могут назвать даже основные метрики.
Они не знают, как оценить успешность бизнеса, эффективность процессов и работу сотрудников.
Честно говоря, такие случаи я встречал редко, но почти всегда у руля стояли люди, которые не особо ценили то дело, которым занимались.
Если вы несете ответственность за свой бизнес, то у него обязательно должны быть измеримые показатели.
После метрик появляются описанные процессы — и тогда вы становитесь управленцем.
Но сегодня быть просто управленцем уже недостаточно. Это только первая ступень. Следующая — цифровизация. И только после нее начинается полноценная ИИ-автоматизация бизнеса.
Об этом новая статья.
В следующий раз разберем, как менялась автоматизация, почему ИИ-агент нужен не всегда и как можно запустить сотни пилотов, после которых в компании ничего не изменится.
👉 Полная статья
Когда я занимался ИИ-трансформацией Сбера, поле моей работы уже было описано.
В компании было более трех тысяч процессов, включая совсем небольшие. Каждый был описан в нотации BPMN.
Директор по данным каждого блока отвечал за цифровизацию своих процессов. Директор по искусственному интеллекту — за внедрение в них ИИ.
Отдельный центр координировал эту работу на уровне всей компании.
Передо мной уже находилась карта бизнеса. Нужно было оцифровать процессы, понять, где применить ИИ, и встроить его в общую систему.
Но в большинстве компаний такой карты нет.
Основателю часто кажется, что он и так знает, как работает его бизнес. Однако при анализе выясняется, что сотрудники выполняют процессы совсем не так, как он себе представляет.
Например, он уверен, что у него многое автоматизировано. А в реальности сотрудники продолжают делать все вручную.
Поэтому я смотрю на компанию не как на набор отделов, а как на систему потоков данных.
Возможно, это мое профессиональное искажение, так как я начинал карьеру как инженер данных.
Для меня не так важно, что находится передо мной: экономический прогноз, HR-процесс, маркетинговое исследование, продажи или разработка продуктов.
В любой предметной области есть входящие данные, последовательность операций, точки принятия решений, результат и связи с другими процессами.
Предметная область меняется, но общая логика остается неизменной.
Нужно видеть сквозные цепочки создания ценности.
Если продукт или сервис предназначен для внешнего клиента — это основной бизнес-процесс.
Если сервис нужен сотруднику или другому подразделению — это поддерживающий процесс.
Но в обоих случаях мы создаем и передаем кому-то ценность.
Поэтому объектом анализа должен быть весь процесс целиком. И уже внутри него нужно находить функции, влияющие на конечный результат.
Современную компанию можно представить как матрицу.
По горизонтали находятся процессы — потоки данных, ведущие к конкретному результату.
По вертикали — функции, которые вызываются внутри процессов в определенном порядке. Одна функция может использоваться в нескольких процессах и по-разному влиять на их результат.
Именно такое мышление я хочу сформировать у вас этим курсом.
Представьте полностью автоматизированную компанию.
В ней уже нет привычного разделения на маркетинг, продажи, HR и другие отделы.
Есть сквозной процесс, который создает и доставляет клиенту то, что ему нужно.
Важно не название подразделения, а то, насколько правильно работает каждая функция и как она встроена в общую цепочку создания ценности.
Еще я заметил одну закономерность.
Основатели, которые любят свое дело и живут им, относятся к бизнесу как к системе.
Они уважают себя, свое время и то, что создают. Поэтому превращают компанию в отлаженный механизм, освобождают себя от операционки и становятся архитекторами системы.
Как по мне, сегодня это и есть главная задача основателя — быть архитектором цепочки создания ценности.
Основатели, для которых бизнес остается только способом зарабатывать деньги, иногда не могут назвать даже основные метрики.
Они не знают, как оценить успешность бизнеса, эффективность процессов и работу сотрудников.
Честно говоря, такие случаи я встречал редко, но почти всегда у руля стояли люди, которые не особо ценили то дело, которым занимались.
Если вы несете ответственность за свой бизнес, то у него обязательно должны быть измеримые показатели.
После метрик появляются описанные процессы — и тогда вы становитесь управленцем.
Но сегодня быть просто управленцем уже недостаточно. Это только первая ступень. Следующая — цифровизация. И только после нее начинается полноценная ИИ-автоматизация бизнеса.
Об этом новая статья.
В следующий раз разберем, как менялась автоматизация, почему ИИ-агент нужен не всегда и как можно запустить сотни пилотов, после которых в компании ничего не изменится.
👉 Полная статья
Датаист / Обучение
Бизнес как система процессов: как потоки данных создают ценность
Автоматизация начинается не с выбора модели и не с платформы, а с вопроса: как в компании создаётся ценность. Клиент не видит отделов — он видит результат, поэтому бизнес полезнее смотреть как поток данных, который превращает действия и решения в полезный…
👍2
Почему бизнесу не нужен очередной хайповый ИИ-инструмент
Ко мне часто обращались клиенты с вопросами о том, как внедрить OpenClaw или какой-нибудь другой инструмент в свой бизнес.
Но гораздо реже задают вопрос: «Мы хотим улучшить конкретную бизнес-метрику. Как нам здесь поможет ИИ?»
Хотя именно с этого вопроса и должна начинаться любая автоматизация.
Потому что после разбора процесса иногда оказывается, что компании вообще не нужен ИИ-агент. Достаточно изменить сам процесс или написать обычный скрипт на питоне.
В других случаях выясняется, что проблема находится в данных: они неполные, хранятся в разных системах или вообще не собираются.
Но вместо анализа процессов и данных некоторые компании сразу смотрят на хайповые инструменты как на волшебную таблетку.
Думаю, здесь работает обычный FOMO. Инфлюенсеры показывают красивую картинку (зачастую это просто ложь), все вокруг обсуждают новый инструмент, и предпринимателю начинает казаться, что он что-то упускает.
На самом деле — нет.
Именно поэтому я не использую OpenClaw и подобные универсальные инструменты для автоматизации критических бизнес-процессов.
Их работа построена на LLM, что позволяет решать сложные интеллектуальные задачи, но не обеспечивает абсолютной надежности и повторяемости результата.
У меня есть несколько знакомых предпринимателей, которые сначала очень вдохновились такими инструментами, а затем сильно разочаровались. Они не смогли добиться того, чтобы система изо дня в день выполняла процесс одинаково и давала устойчивый результат.
Так устроены языковые модели: иногда они могут неправильно интерпретировать задачу или просто сгаллюцинировать.
Для эксперимента это допустимо. Но представьте, что на такой системе завязан реальный бизнес-процесс.
Если через него проходит тысяча заявок, даже одна неправильно обработанная заявка означает потерянного или недовольного клиента и негативный отзыв о вашей компании. А при увеличении масштаба редкие ошибки превращаются в постоянную проблему.
Там, где действительно требуется интеллектуальная операция, нужно использовать LLM или ИИ-агентов. Там, где интеллектуальной операции нет, они могут только снизить надежность, увеличить время выполнения и создать дополнительные расходы.
Например, если нужно проверить, заполнено ли обязательное поле или соответствует ли телефон заданному формату, языковая модель попросту не нужна.
Обычный скрипт выполнит такую проверку за доли секунды, практически бесплатно и всегда по одним и тем же правилам.
А вот если нужно понять свободный текст клиента, определить смысл обращения или проанализировать нестандартный документ, это уже задача для языковой модели.
Есть и другая ошибка — пытаться решать с помощью LLM задачи, для которых она сама по себе не предназначена.
Например, меня спрашивают, как через ChatGPT прогнозировать цены акций. Но языковая модель прогнозирует следующий токен на основе выученных паттернов, а не будущую цену актива.
Для таких задач нужно отдельно собирать и готовить данные, выделять признаки, обучать и проверять специальную математическую модель или модель машинного обучения.
ChatGPT может помочь написать код, проанализировать текст или картинку, но просто загрузить историю котировок и спросить: «Что будет дальше?» — недостаточно.
Получается, что сначала нужно полностью описать процесс, а затем определить, какой тип автоматизации требуется на каждом его этапе.
Об этом новая статья. А в следующей статье разберем, с какого процесса стоит начинать автоматизацию.
👉 Полная статья
Ко мне часто обращались клиенты с вопросами о том, как внедрить OpenClaw или какой-нибудь другой инструмент в свой бизнес.
Но гораздо реже задают вопрос: «Мы хотим улучшить конкретную бизнес-метрику. Как нам здесь поможет ИИ?»
Хотя именно с этого вопроса и должна начинаться любая автоматизация.
Потому что после разбора процесса иногда оказывается, что компании вообще не нужен ИИ-агент. Достаточно изменить сам процесс или написать обычный скрипт на питоне.
В других случаях выясняется, что проблема находится в данных: они неполные, хранятся в разных системах или вообще не собираются.
Но вместо анализа процессов и данных некоторые компании сразу смотрят на хайповые инструменты как на волшебную таблетку.
Думаю, здесь работает обычный FOMO. Инфлюенсеры показывают красивую картинку (зачастую это просто ложь), все вокруг обсуждают новый инструмент, и предпринимателю начинает казаться, что он что-то упускает.
На самом деле — нет.
Именно поэтому я не использую OpenClaw и подобные универсальные инструменты для автоматизации критических бизнес-процессов.
Их работа построена на LLM, что позволяет решать сложные интеллектуальные задачи, но не обеспечивает абсолютной надежности и повторяемости результата.
У меня есть несколько знакомых предпринимателей, которые сначала очень вдохновились такими инструментами, а затем сильно разочаровались. Они не смогли добиться того, чтобы система изо дня в день выполняла процесс одинаково и давала устойчивый результат.
Так устроены языковые модели: иногда они могут неправильно интерпретировать задачу или просто сгаллюцинировать.
Для эксперимента это допустимо. Но представьте, что на такой системе завязан реальный бизнес-процесс.
Если через него проходит тысяча заявок, даже одна неправильно обработанная заявка означает потерянного или недовольного клиента и негативный отзыв о вашей компании. А при увеличении масштаба редкие ошибки превращаются в постоянную проблему.
Там, где действительно требуется интеллектуальная операция, нужно использовать LLM или ИИ-агентов. Там, где интеллектуальной операции нет, они могут только снизить надежность, увеличить время выполнения и создать дополнительные расходы.
Например, если нужно проверить, заполнено ли обязательное поле или соответствует ли телефон заданному формату, языковая модель попросту не нужна.
Обычный скрипт выполнит такую проверку за доли секунды, практически бесплатно и всегда по одним и тем же правилам.
А вот если нужно понять свободный текст клиента, определить смысл обращения или проанализировать нестандартный документ, это уже задача для языковой модели.
Есть и другая ошибка — пытаться решать с помощью LLM задачи, для которых она сама по себе не предназначена.
Например, меня спрашивают, как через ChatGPT прогнозировать цены акций. Но языковая модель прогнозирует следующий токен на основе выученных паттернов, а не будущую цену актива.
Для таких задач нужно отдельно собирать и готовить данные, выделять признаки, обучать и проверять специальную математическую модель или модель машинного обучения.
ChatGPT может помочь написать код, проанализировать текст или картинку, но просто загрузить историю котировок и спросить: «Что будет дальше?» — недостаточно.
Получается, что сначала нужно полностью описать процесс, а затем определить, какой тип автоматизации требуется на каждом его этапе.
Об этом новая статья. А в следующей статье разберем, с какого процесса стоит начинать автоматизацию.
👉 Полная статья
Датаист / Обучение
От механизации до ИИ-агентов: как эволюционировала автоматизация
Двести лет автоматизация занималась физическим трудом: сначала станки взяли на себя отдельные операции, потом конвейеры собрали их в процессы. Сегодня то же самое повторяется на уровне мышления. В этом материале — этапы эволюции автоматизации, четыре её уровня…
Как выбрать правильный процесс для автоматизации
Помогая компаниям внедрять ИИ, я часто вижу одну ошибку.
Даже если компания выбирает бизнес-метрику и начинает автоматизировать процесс, который на нее влияет, она не всегда учитывает, что произойдет со всей системой.
Возьмем для примера финтех. Компания хочет увеличить прибыль. Для этого ей нужны новые клиенты, поэтому она внедряет ИИ в продажи и строит дополнительные воронки.
Компания начинает проводить автоматический онбординг и быстрее подключает больше клиентов.
Но больше клиентов — это больше транзакций и диспутов.
Если при этом компания не внедрила ИИ в поддержку и не увеличила ее пропускную способность, поддержка просто захлебнется в потоке обращений.
В итоге продажи вырастут, но удовлетворенность клиентов снизится. Локальная метрика улучшится, а вся система начнет работать хуже.
Поэтому нельзя автоматизировать отдельный процесс в вакууме. Нужно смотреть на всю цепочку создания ценности и заранее понимать, куда переместится нагрузка после оптимизации.
У меня был кейс, когда компания хотела стать AI-First, но найм разработчиков занимал несколько месяцев.
Можно было сколько угодно говорить об ИИ-трансформации в презентациях, но компания не могла двигаться с нужной скоростью, потому что ее главным ограничением оказался рекрутинг.
Поэтому ИИ нужно было внедрять именно туда.
Но здесь возникла другая проблема. Инструменты внедрили, а рекрутеры продолжили работать по-старому.
Они боялись, что ИИ их заменит, так как значительная часть их работы сводилась к вопросам вроде: «Готов ли кандидат к релокации?»
Такие операции можно автоматизировать, но рекрутеры все равно выполняли их вручную.
Получается, что технически процесс был автоматизирован, но организационно оставался ручным.
Об управлении такими изменениями я отдельно расскажу в одной из следующих статей.
При этом стать AI-First не означает передать ИИ всю работу.
Я бы не стал полностью автоматизировать процессы, в которых требуется персональная ответственность за решения.
Например, ИИ может помогать формулировать цели и предлагать варианты. Но ставить цели и отвечать за них должен человек.
То же самое касается финансов.
Для работы с цифрами я никогда не использую LLM. Здесь нужны детерминированные алгоритмы, а машинное обучение можно применять для финансовых прогнозов.
В юридической работе ИИ тоже должен оставаться ассистентом.
Он может искать документы и прецеденты, готовить черновики и подсвечивать потенциальные риски.
Но юридическая интерпретация зависит от контекста и практики. Поэтому окончательное заключение должно оставаться за человеком.
И вообще, помогая компаниям проходить ИИ-трансформацию, я пришел к выводу, что сегодня создать AI-First компанию с нуля зачастую проще, чем трансформировать существующую.
В действующем бизнесе приходится менять процессы, роли, оргструктуру и мышление людей.
Сотрудники продолжают работать по-старому, руководители защищают свои зоны ответственности, а устаревшие процессы постоянно воспроизводят сами себя.
Поэтому некоторые основатели уже не пытаются трансформировать старую компанию, а говорят прямо: «Мы строим новую компанию с нуля».
Они сносят старые процессы, создают новые вакансии под новые роли с новыми требованиями к людям и строят полностью новую операционную модель.
Если кто-то из прежней команды подходит для новой компании и готов работать по новым правилам, его переводят туда. Если нет — новую организацию строят без него.
Это уже по сути корпоративная ИИ-революция, а не ИИ-трансформация.
А предпринимателю, который начинает с нуля, вообще не нужно ничего трансформировать. Он может сразу строить AI-First компанию.
Раньше для этого требовался стартовый капитал на зарплаты, но сегодня опытный специалист может в одиночку управлять ИИ-агентами и выдавать результат, для которого раньше требовалась целая команда.
В новой статье разбираемся, как выбрать правильный процесс для автоматизации, почему нельзя смотреть только на локальную метрику и где искать главное ограничение всей системы.
👉 Полная статья
Помогая компаниям внедрять ИИ, я часто вижу одну ошибку.
Даже если компания выбирает бизнес-метрику и начинает автоматизировать процесс, который на нее влияет, она не всегда учитывает, что произойдет со всей системой.
Возьмем для примера финтех. Компания хочет увеличить прибыль. Для этого ей нужны новые клиенты, поэтому она внедряет ИИ в продажи и строит дополнительные воронки.
Компания начинает проводить автоматический онбординг и быстрее подключает больше клиентов.
Но больше клиентов — это больше транзакций и диспутов.
Если при этом компания не внедрила ИИ в поддержку и не увеличила ее пропускную способность, поддержка просто захлебнется в потоке обращений.
В итоге продажи вырастут, но удовлетворенность клиентов снизится. Локальная метрика улучшится, а вся система начнет работать хуже.
Поэтому нельзя автоматизировать отдельный процесс в вакууме. Нужно смотреть на всю цепочку создания ценности и заранее понимать, куда переместится нагрузка после оптимизации.
У меня был кейс, когда компания хотела стать AI-First, но найм разработчиков занимал несколько месяцев.
Можно было сколько угодно говорить об ИИ-трансформации в презентациях, но компания не могла двигаться с нужной скоростью, потому что ее главным ограничением оказался рекрутинг.
Поэтому ИИ нужно было внедрять именно туда.
Но здесь возникла другая проблема. Инструменты внедрили, а рекрутеры продолжили работать по-старому.
Они боялись, что ИИ их заменит, так как значительная часть их работы сводилась к вопросам вроде: «Готов ли кандидат к релокации?»
Такие операции можно автоматизировать, но рекрутеры все равно выполняли их вручную.
Получается, что технически процесс был автоматизирован, но организационно оставался ручным.
Об управлении такими изменениями я отдельно расскажу в одной из следующих статей.
При этом стать AI-First не означает передать ИИ всю работу.
Я бы не стал полностью автоматизировать процессы, в которых требуется персональная ответственность за решения.
Например, ИИ может помогать формулировать цели и предлагать варианты. Но ставить цели и отвечать за них должен человек.
То же самое касается финансов.
Для работы с цифрами я никогда не использую LLM. Здесь нужны детерминированные алгоритмы, а машинное обучение можно применять для финансовых прогнозов.
В юридической работе ИИ тоже должен оставаться ассистентом.
Он может искать документы и прецеденты, готовить черновики и подсвечивать потенциальные риски.
Но юридическая интерпретация зависит от контекста и практики. Поэтому окончательное заключение должно оставаться за человеком.
И вообще, помогая компаниям проходить ИИ-трансформацию, я пришел к выводу, что сегодня создать AI-First компанию с нуля зачастую проще, чем трансформировать существующую.
В действующем бизнесе приходится менять процессы, роли, оргструктуру и мышление людей.
Сотрудники продолжают работать по-старому, руководители защищают свои зоны ответственности, а устаревшие процессы постоянно воспроизводят сами себя.
Поэтому некоторые основатели уже не пытаются трансформировать старую компанию, а говорят прямо: «Мы строим новую компанию с нуля».
Они сносят старые процессы, создают новые вакансии под новые роли с новыми требованиями к людям и строят полностью новую операционную модель.
Если кто-то из прежней команды подходит для новой компании и готов работать по новым правилам, его переводят туда. Если нет — новую организацию строят без него.
Это уже по сути корпоративная ИИ-революция, а не ИИ-трансформация.
А предпринимателю, который начинает с нуля, вообще не нужно ничего трансформировать. Он может сразу строить AI-First компанию.
Раньше для этого требовался стартовый капитал на зарплаты, но сегодня опытный специалист может в одиночку управлять ИИ-агентами и выдавать результат, для которого раньше требовалась целая команда.
В новой статье разбираемся, как выбрать правильный процесс для автоматизации, почему нельзя смотреть только на локальную метрику и где искать главное ограничение всей системы.
👉 Полная статья
Датаист / Обучение
Как выбрать правильный процесс для автоматизации
Автоматизировать всё сразу невозможно — и не нужно. Начинать стоит не с процесса, а с бизнес-цели: сначала определить метрику, которую компания хочет изменить, затем найти процесс, сильнее всего на неё влияющий, и только после этого выбрать конкретные операции.…
Как провести рентген бизнеса и извлечь знания экспертов
В новой статье про рентген бизнеса я разобрал только часть методов, которыми можно восстанавливать реальные процессы и извлекать знания экспертов.
В официальном BABOK (Business Analysis Body of Knowledge) описано 50 техник бизнес-анализа.
Но я бы не воспринимал BABOK как инструкцию, по которой нужно последовательно пройти все 50 пунктов. Это скорее большой набор инструментов, из которого под конкретную проблему выбирается несколько нужных.
Например, в статье я коротко рассказал про интервью, наблюдение, анализ документов, воркшопы, опросы, фокус-группы, моделирование процессов, бизнес-правила и решения.
Но для полноценной ИИ-трансформации одного бизнес-анализа недостаточно. Значительная часть реальной экспертизы компании существует в головах людей.
Опытный сотрудник знает, какого клиента лучше не онбордить и почему кандидат с хорошим резюме на практике не подойдет.
Причем часть реального процесса вообще может быть скрыта внутри его мышления. На схеме написано «проанализировать заявку», но внутри человек замечает необычный сигнал, сравнивает его с прошлыми кейсами, оценивает несколько признаков и только после этого принимает решение.
Поэтому я бы дополнял классический бизнес-анализ методами, которых нет в BABOK.
Например, Process Mining позволяет восстанавливать фактический процесс по цифровым следам в информационных системах, а не только по тому, что сотрудники рассказывают на интервью.
Task Mining показывает, что человек делает непосредственно на компьютере: между какими системами переключается, что копирует вручную и какие операции повторяет.
А когнитивный анализ задач (Cognitive Task Analysis, CTA) нужен для извлечения того, что происходит уже в голове эксперта. Тут вы становитесь своего рода психологом.
Для когнитивного анализа я бы выделил шесть вопросов для интервью:
1. Информация — на что человек смотрит? Какие данные важны? Что он замечает первым и с чем сравнивает?
2. Интерпретация — что он понимает из увиденного? Что означает конкретный признак? Какую гипотезу он строит? И какие признаки рассматривает вместе?
3. Логика решения — как выбирается результат? Какие есть варианты? По каким критериям выбирается каждый? И где проходят границы?
4. Опыт и эвристики — что находится только в голове эксперта?
Что он замечает быстрее новичка? Какие негласные правила использует? И что сложно формализовать?
5. Неопределенность и исключения — когда обычное правило не работает?
Что делать, когда данных недостаточно? Что вызывает сомнение? И когда нужно запросить дополнительную информацию и передать решение человеку?
6. Качество и обратная связь — как понять, что решение хорошее? Как проверить результат? Какие ошибки критичны? И что заставит пересмотреть решение?
В итоге нужно восстановить всю когнитивную цепочку: что человек увидел, как это интерпретировал, с чем сравнил, какое решение принял, как обработал исключение и по каким признакам понял, что результат правильный.
Получается, что бизнес-анализ показывает, что делает человек, а когнитивный анализ — что он думает, когда это делает.
Для ИИ-агентов это важно, потому что автоматизировать нужно не только видимые действия, но и скрытые правила и логику принятия решений.
При этом эксперт тоже может ошибаться. Поэтому извлеченные знания нужно проверять и только после этого передавать агенту. Все же мы, люди, склонны к когнитивным искажениям. Включайте свое критическое мышление и здравый смысл.
Задача не в том, чтобы научить агента повторять действия сотрудника, а в том, чтобы отделить знания компании от конкретных людей, проверить их и превратить в воспроизводимый интеллектуальный процесс.
Тогда человек может уйти из компании, а накопленная экспертиза останется внутри.
В следующей статье разберемся, как увидеть бизнес-процесс таким, какой он есть на самом деле: как использовать Process Mining с помощью цифрового следа, находить расхождения с реальностью и описывать процесс так, чтобы его одинаково понимали и люди и ИИ.
👉 Полная статья
В новой статье про рентген бизнеса я разобрал только часть методов, которыми можно восстанавливать реальные процессы и извлекать знания экспертов.
В официальном BABOK (Business Analysis Body of Knowledge) описано 50 техник бизнес-анализа.
Но я бы не воспринимал BABOK как инструкцию, по которой нужно последовательно пройти все 50 пунктов. Это скорее большой набор инструментов, из которого под конкретную проблему выбирается несколько нужных.
Например, в статье я коротко рассказал про интервью, наблюдение, анализ документов, воркшопы, опросы, фокус-группы, моделирование процессов, бизнес-правила и решения.
Но для полноценной ИИ-трансформации одного бизнес-анализа недостаточно. Значительная часть реальной экспертизы компании существует в головах людей.
Опытный сотрудник знает, какого клиента лучше не онбордить и почему кандидат с хорошим резюме на практике не подойдет.
Причем часть реального процесса вообще может быть скрыта внутри его мышления. На схеме написано «проанализировать заявку», но внутри человек замечает необычный сигнал, сравнивает его с прошлыми кейсами, оценивает несколько признаков и только после этого принимает решение.
Поэтому я бы дополнял классический бизнес-анализ методами, которых нет в BABOK.
Например, Process Mining позволяет восстанавливать фактический процесс по цифровым следам в информационных системах, а не только по тому, что сотрудники рассказывают на интервью.
Task Mining показывает, что человек делает непосредственно на компьютере: между какими системами переключается, что копирует вручную и какие операции повторяет.
А когнитивный анализ задач (Cognitive Task Analysis, CTA) нужен для извлечения того, что происходит уже в голове эксперта. Тут вы становитесь своего рода психологом.
Для когнитивного анализа я бы выделил шесть вопросов для интервью:
1. Информация — на что человек смотрит? Какие данные важны? Что он замечает первым и с чем сравнивает?
2. Интерпретация — что он понимает из увиденного? Что означает конкретный признак? Какую гипотезу он строит? И какие признаки рассматривает вместе?
3. Логика решения — как выбирается результат? Какие есть варианты? По каким критериям выбирается каждый? И где проходят границы?
4. Опыт и эвристики — что находится только в голове эксперта?
Что он замечает быстрее новичка? Какие негласные правила использует? И что сложно формализовать?
5. Неопределенность и исключения — когда обычное правило не работает?
Что делать, когда данных недостаточно? Что вызывает сомнение? И когда нужно запросить дополнительную информацию и передать решение человеку?
6. Качество и обратная связь — как понять, что решение хорошее? Как проверить результат? Какие ошибки критичны? И что заставит пересмотреть решение?
В итоге нужно восстановить всю когнитивную цепочку: что человек увидел, как это интерпретировал, с чем сравнил, какое решение принял, как обработал исключение и по каким признакам понял, что результат правильный.
Получается, что бизнес-анализ показывает, что делает человек, а когнитивный анализ — что он думает, когда это делает.
Для ИИ-агентов это важно, потому что автоматизировать нужно не только видимые действия, но и скрытые правила и логику принятия решений.
При этом эксперт тоже может ошибаться. Поэтому извлеченные знания нужно проверять и только после этого передавать агенту. Все же мы, люди, склонны к когнитивным искажениям. Включайте свое критическое мышление и здравый смысл.
Задача не в том, чтобы научить агента повторять действия сотрудника, а в том, чтобы отделить знания компании от конкретных людей, проверить их и превратить в воспроизводимый интеллектуальный процесс.
Тогда человек может уйти из компании, а накопленная экспертиза останется внутри.
В следующей статье разберемся, как увидеть бизнес-процесс таким, какой он есть на самом деле: как использовать Process Mining с помощью цифрового следа, находить расхождения с реальностью и описывать процесс так, чтобы его одинаково понимали и люди и ИИ.
👉 Полная статья
Датаист / Обучение
Как провести рентген бизнеса и извлечь знания экспертов
Описанного в регламенте процесса, скорее всего, не существует. Версий обычно набирается три: та, что записана; та, что в голове у руководителя; и та, по которой люди работают каждый день, — нужна последняя. В этом материале: какими методами её собирают, что…
Как увидеть бизнес-процесс таким, какой он есть на самом деле
Бизнес-процессы можно описывать разными способами: UML, классическим BPMN, S-BPM и другими нотациями.
BPMN самый распространенный вариант. Но мне больше нравится субъектно-ориентированный подход — S-BPM.
В нем процесс строится вокруг субъектов. Субъектом может быть человек, система или ИИ-агент.
У каждого субъекта есть свое поведение, а между собой они обмениваются артефактами.
Такой подход с одной стороны, простой, а с другой — хорошо переносится на архитектуру мультиагентной системы.
Но в целом я бы не зацикливался на конкретной нотации.
Главное, чтобы вы могли прочитать схему, бизнес понимал, что на ней происходит, а инженер мог на ее основе построить работающую систему.
Гораздо важнее понять, соответствует ли эта схема реальности.
Интервью здесь полезны, но, как мы знаем, люди часто лгут. Причем иногда даже не специально.
Поэтому я рекомендую дополнять интервью Process Mining.
В Сбере мы использовали для этого самописный инструмент, но я бы рекомендовал открытую библиотеку PM4Py. С помощью ИИ сегодня можно легко разобраться и с самой библиотекой, и с тем, как запускать анализ.
Идея Process Mining в том, что информационные системы оставляют цифровой след, и по нему можно восстановить то, как процесс действительно проходил.
Для этого нужен журнал событий минимум с тремя полями:
• Case ID — конкретный экземпляр процесса: заявка, заказ, сделка.
• Activity — какое действие произошло.
• Timestamp — когда оно произошло.
• Дополнительно полезен Resource — кто выполнил действие: человек, система или агент.
Но на практике самая трудозатратная часть Process Mining в подготовке данных.
Информационные системы почти никогда не хранят события сразу в нужном формате.
Например, Jira может хранить историю изменения задачи примерно так:
А Process Mining хотелось бы получить:
То есть сначала нужно понять схему данных системы, а потом смапить их в стандартный лог событий.
И здесь сделать полностью универсальный инструмент довольно сложно.
У Jira один формат. У CRM другой. У ERP третий. У внутренней самописной системы четвертый.
Поэтому универсальным может быть сам движок Process Mining, но не слой извлечения данных из любой системы.
Зато здесь очень хорошо помогает ИИ.
Можно взять небольшой сэмпл реальных данных, показать его ИИ и попросить написать скрипт на питоне, который преобразует исходные поля в нужный формат.
После этого проверить несколько кейсов вручную, убедиться, что события интерпретированы правильно, и только потом прогонять весь массив через PM4Py.
После подготовки лога событий можно восстановить честную карту процесса.
В интервью вам расскажут одно, а на деле часть кейсов могут возвращаться назад, часть проходит через другие подразделения, а некоторые несколько дней ждут согласований.
И здесь мы уже смотрим не на представление человека о процессе, а на цифровой след того, что действительно происходило в системе.
Можно находить возвраты, петли, задержки, обходные маршруты, расхождения с регламентом и аномальное поведение.
Поэтому Process Mining используют не только для оптимизации процессов, но и коллеги из кибербезопасности.
Но полностью заменять интервью данными тоже нельзя.
Process Mining хорошо показывает, что произошло, но далеко не всегда объясняет, почему.
По журналу видно, что заявка трижды вернулась назад. А сотрудник может объяснить, что данные приходят из другой системы в неправильном формате и их приходится исправлять вручную.
Поэтому я бы всегда сочетал несколько источников.
Люди дают контекст. Данные дают факты.
Интервью показывает, как человек понимает процесс. Process Mining показывает цифровой след того, что реально происходило.
И только их комбинация позволяет собрать действительно честную AS-IS модель.
В следующей статье разберем как найти точки автоматизации с максимальной отдачей.
👉 Полная статья
Бизнес-процессы можно описывать разными способами: UML, классическим BPMN, S-BPM и другими нотациями.
BPMN самый распространенный вариант. Но мне больше нравится субъектно-ориентированный подход — S-BPM.
В нем процесс строится вокруг субъектов. Субъектом может быть человек, система или ИИ-агент.
У каждого субъекта есть свое поведение, а между собой они обмениваются артефактами.
Такой подход с одной стороны, простой, а с другой — хорошо переносится на архитектуру мультиагентной системы.
Но в целом я бы не зацикливался на конкретной нотации.
Главное, чтобы вы могли прочитать схему, бизнес понимал, что на ней происходит, а инженер мог на ее основе построить работающую систему.
Гораздо важнее понять, соответствует ли эта схема реальности.
Интервью здесь полезны, но, как мы знаем, люди часто лгут. Причем иногда даже не специально.
Поэтому я рекомендую дополнять интервью Process Mining.
В Сбере мы использовали для этого самописный инструмент, но я бы рекомендовал открытую библиотеку PM4Py. С помощью ИИ сегодня можно легко разобраться и с самой библиотекой, и с тем, как запускать анализ.
Идея Process Mining в том, что информационные системы оставляют цифровой след, и по нему можно восстановить то, как процесс действительно проходил.
Для этого нужен журнал событий минимум с тремя полями:
• Case ID — конкретный экземпляр процесса: заявка, заказ, сделка.
• Activity — какое действие произошло.
• Timestamp — когда оно произошло.
• Дополнительно полезен Resource — кто выполнил действие: человек, система или агент.
Но на практике самая трудозатратная часть Process Mining в подготовке данных.
Информационные системы почти никогда не хранят события сразу в нужном формате.
Например, Jira может хранить историю изменения задачи примерно так:
`issue = DATA-4712`
`field = status`
`from = In Progress`
`to = Review`
`author = Andre`
`created = 14:42`
А Process Mining хотелось бы получить:
`case_id = DATA-4712`
`activity = Sent to Review`
`timestamp = 14:42`
`resource = Andre`
То есть сначала нужно понять схему данных системы, а потом смапить их в стандартный лог событий.
И здесь сделать полностью универсальный инструмент довольно сложно.
У Jira один формат. У CRM другой. У ERP третий. У внутренней самописной системы четвертый.
Поэтому универсальным может быть сам движок Process Mining, но не слой извлечения данных из любой системы.
Зато здесь очень хорошо помогает ИИ.
Можно взять небольшой сэмпл реальных данных, показать его ИИ и попросить написать скрипт на питоне, который преобразует исходные поля в нужный формат.
После этого проверить несколько кейсов вручную, убедиться, что события интерпретированы правильно, и только потом прогонять весь массив через PM4Py.
После подготовки лога событий можно восстановить честную карту процесса.
В интервью вам расскажут одно, а на деле часть кейсов могут возвращаться назад, часть проходит через другие подразделения, а некоторые несколько дней ждут согласований.
И здесь мы уже смотрим не на представление человека о процессе, а на цифровой след того, что действительно происходило в системе.
Можно находить возвраты, петли, задержки, обходные маршруты, расхождения с регламентом и аномальное поведение.
Поэтому Process Mining используют не только для оптимизации процессов, но и коллеги из кибербезопасности.
Но полностью заменять интервью данными тоже нельзя.
Process Mining хорошо показывает, что произошло, но далеко не всегда объясняет, почему.
По журналу видно, что заявка трижды вернулась назад. А сотрудник может объяснить, что данные приходят из другой системы в неправильном формате и их приходится исправлять вручную.
Поэтому я бы всегда сочетал несколько источников.
Люди дают контекст. Данные дают факты.
Интервью показывает, как человек понимает процесс. Process Mining показывает цифровой след того, что реально происходило.
И только их комбинация позволяет собрать действительно честную AS-IS модель.
В следующей статье разберем как найти точки автоматизации с максимальной отдачей.
👉 Полная статья
Датаист / Обучение
Как увидеть бизнес-процесс таким, какой он есть на самом деле
Сотрудники описывают процесс таким, каким он задуман. Журнал событий хранит то, как он шёл в действительности, — и вместо единственного маршрута их там оказывается несколько десятков. В этом материале: из каких полей складывается журнал, чем режим исследования…
Как найти точки автоматизации с максимальной отдачей
Есть ошибка, о которой мы уже говорили, но которую я регулярно наблюдаю на практике, — попытка использовать ИИ там, где он вообще не нужен.
Если операция выполняется по понятным правилам и результат заранее определен, обычная автоматизация будет работать быстрее, дешевле и стабильнее. Поэтому иногда нужен просто скрипт.
В ИИ-трансформации нужно понять, где достаточно правила, где действительно нужен ИИ, а где решение должен принимать человек.
Отсюда возникает второй вопрос — границы автономности.
Сейчас мне периодически встречаются основатели, которые хотят построить полностью автономный бизнес или стартап-студию, в которой ИИ сам придумывает продукты, разрабатывает приложения, запускает их и принимает следующие решения.
Теоретически такую систему можно построить. Но я бы не ставил полную автономность конечной целью.
В бизнесе есть решения, где важна ответственность за последствия.
Можно ли запустить продукт на рынок «для взрослых»? Стоит ли принимать неэтическое решение? Стоит ли идти на финансовый риск? А может вообще закрыть неперспективное направление?
В бизнесе должен быть человек, который определяет цели, задает границы и в критических точках принимает итоговое решение.
Поэтому при проектировании процесса я бы заранее определял, где агент работает самостоятельно, где человек контролирует результат, а где без его подтверждения действие вообще не выполняется.
Но даже правильно выбранную операцию не всегда можно сразу автоматизировать. Иногда к внедрению просто не готов сам процесс.
У меня был кейс, где у службы поддержки не было конкретного владельца. В компании было несколько продуктов, а каждый владелец продукта внедрял свой сервис поддержки.
Мы разработали достаточно универсального агента для унификации службы поддержки, но возник простой вопрос: а кто вообще должен сказать, что результат удовлетворительный и его можно катить в прод?
То есть нельзя нормально сравнить, сколько занимал процесс до изменений и сколько стал занимать после. Непонятно, стало лучше или хуже и кто за это отвечает. Тут нужно было сначала унифицировать саму службу поддержки, назначить владельца, а только потом внедрять агента.
Бывают и чисто технические проблемы. Например, данные находятся в старой легаси-системе, к которой нет нормального доступа.
Где-то нужной базы данных вообще нет. Где-то данные есть, но необходимые метрики никто никогда не собирал.
Получается, что иногда первый этап ИИ-трансформации вообще не связан с ИИ. Тут мы возвращаемся к статье об индексе ИИ-зрелости.
Сначала нужно привести в порядок сам процесс. Назначить владельца. Определить метрики и снять текущее состояние. Подготовить данные и доступы. Понять границы процесса и ответственность.
И только после этого проектировать, как этот процесс должен работать вместе с ИИ и какую роль в нем будет выполнять человек.
Поэтому рассматривайте автоматизацию не как набор отдельных идей, а как нормальный портфель проектов.
Самый простой способ расставить приоритеты — посмотреть на матрицу ценности и сложности.
Если ценность высокая, а сложность низкая — это быстрые победы. С них я бы начинал в первую очередь.
Если ценность высокая и сложность тоже высокая — подготовку таких проектов можно запускать параллельно с быстрыми победами. Часто сначала нужно подготовить процесс к ИИ: собрать данные, сделать интеграции, внедрить метрики или изменить сам процесс.
Если ценность низкая и сложность тоже низкая — такие задачи можно оставить на потом или сделать попутно, если позволяет ресурс.
А если ценность низкая, а сложность высокая, я бы вообще возвращался к ним в самый последний момент. А иногда не возвращался бы совсем.
При этом ценность должна вытекать из целей бизнеса, которые мы хотим достичь.
В следующий раз разберемся, как спроектировать целевую TO-BE модель процесса и определить в ней роль человека..
👉 Полная статья
Есть ошибка, о которой мы уже говорили, но которую я регулярно наблюдаю на практике, — попытка использовать ИИ там, где он вообще не нужен.
Если операция выполняется по понятным правилам и результат заранее определен, обычная автоматизация будет работать быстрее, дешевле и стабильнее. Поэтому иногда нужен просто скрипт.
В ИИ-трансформации нужно понять, где достаточно правила, где действительно нужен ИИ, а где решение должен принимать человек.
Отсюда возникает второй вопрос — границы автономности.
Сейчас мне периодически встречаются основатели, которые хотят построить полностью автономный бизнес или стартап-студию, в которой ИИ сам придумывает продукты, разрабатывает приложения, запускает их и принимает следующие решения.
Теоретически такую систему можно построить. Но я бы не ставил полную автономность конечной целью.
В бизнесе есть решения, где важна ответственность за последствия.
Можно ли запустить продукт на рынок «для взрослых»? Стоит ли принимать неэтическое решение? Стоит ли идти на финансовый риск? А может вообще закрыть неперспективное направление?
В бизнесе должен быть человек, который определяет цели, задает границы и в критических точках принимает итоговое решение.
Поэтому при проектировании процесса я бы заранее определял, где агент работает самостоятельно, где человек контролирует результат, а где без его подтверждения действие вообще не выполняется.
Но даже правильно выбранную операцию не всегда можно сразу автоматизировать. Иногда к внедрению просто не готов сам процесс.
У меня был кейс, где у службы поддержки не было конкретного владельца. В компании было несколько продуктов, а каждый владелец продукта внедрял свой сервис поддержки.
Мы разработали достаточно универсального агента для унификации службы поддержки, но возник простой вопрос: а кто вообще должен сказать, что результат удовлетворительный и его можно катить в прод?
То есть нельзя нормально сравнить, сколько занимал процесс до изменений и сколько стал занимать после. Непонятно, стало лучше или хуже и кто за это отвечает. Тут нужно было сначала унифицировать саму службу поддержки, назначить владельца, а только потом внедрять агента.
Бывают и чисто технические проблемы. Например, данные находятся в старой легаси-системе, к которой нет нормального доступа.
Где-то нужной базы данных вообще нет. Где-то данные есть, но необходимые метрики никто никогда не собирал.
Получается, что иногда первый этап ИИ-трансформации вообще не связан с ИИ. Тут мы возвращаемся к статье об индексе ИИ-зрелости.
Сначала нужно привести в порядок сам процесс. Назначить владельца. Определить метрики и снять текущее состояние. Подготовить данные и доступы. Понять границы процесса и ответственность.
И только после этого проектировать, как этот процесс должен работать вместе с ИИ и какую роль в нем будет выполнять человек.
Поэтому рассматривайте автоматизацию не как набор отдельных идей, а как нормальный портфель проектов.
Самый простой способ расставить приоритеты — посмотреть на матрицу ценности и сложности.
Если ценность высокая, а сложность низкая — это быстрые победы. С них я бы начинал в первую очередь.
Если ценность высокая и сложность тоже высокая — подготовку таких проектов можно запускать параллельно с быстрыми победами. Часто сначала нужно подготовить процесс к ИИ: собрать данные, сделать интеграции, внедрить метрики или изменить сам процесс.
Если ценность низкая и сложность тоже низкая — такие задачи можно оставить на потом или сделать попутно, если позволяет ресурс.
А если ценность низкая, а сложность высокая, я бы вообще возвращался к ним в самый последний момент. А иногда не возвращался бы совсем.
При этом ценность должна вытекать из целей бизнеса, которые мы хотим достичь.
В следующий раз разберемся, как спроектировать целевую TO-BE модель процесса и определить в ней роль человека..
👉 Полная статья
Датаист / Обучение
Как найти точки автоматизации с максимальной отдачей
Автоматизировать можно почти любой шаг процесса, но далеко не каждый стоит отдавать ИИ. Когда реальная модель AS-IS уже собрана, для каждой операции нужно выбрать подходящий способ исполнения: правило, ИИ, человек или гибрид. Разбираемся, как отличить детерминированные…
Как перестроить процесс под ИИ-агентов
Когда вы переходите от AS-IS процесса к TO-BE, главная ошибка — взять существующую диаграмму и просто добавить в несколько квадратиков слово ИИ.
Для начала нужно полностью пересмотреть его с учетом новых возможностей ИИ.
В старом процессе могут быть операции, которые теперь вообще не нужны.
Поэтому TO-BE — это не автоматизированная версия AS-IS. Это заново спроектированный процесс.
И только после этого нужно определять, какие функции выполняет ИИ, а какие остаются у человека.
Причем роль человека нужно фиксировать заранее.
Когда вы приходите к сотрудникам и говорите, что часть их работы теперь будет выполнять ИИ, естественно возникает вопрос: а что тогда буду делать я?
Отсюда появляется сопротивление.
Нужно сразу объяснить человеку, какой становится его новая роль. А затем обучить его работать в этой роли. Про обучение мы еще поговорим отдельно.
Я бы выделял четыре основные роли человека.
1. Оператор. Процесс может работать автономно, но у системы все равно должен быть ответственный.
Оператор следит, чтобы она работала, контролирует метрики, качество результата, ошибки и данные.
Если результаты работы агента используются для дальнейшего улучшения моделей или самого процесса, оператор контролирует и это.
То есть он уже не выполняет операцию руками — он отвечает за работающую систему.
2. Супервайзер. Здесь ИИ выполняет работу самостоятельно, но в определенных точках должен запросить решение человека.
Одобрять ли действие? Запускать следующий этап или останавливать процесс?
Человек принимает решение, а дальше ИИ продолжает работу.
3. Менеджер. Здесь ИИ тоже готовит информацию: собирает контекст, делает анализ и предлагает варианты.
Но следующее действие выполняет уже сам человек. В этом основное различие.
Супервайзер принимает решение для ИИ, после чего агент продолжает процесс.
Менеджер использует подготовленный ИИ контекст и уже сам что-то делает на его основе.
4. Эксперт. Здесь человек и ИИ работают вместе.
ИИ помогает искать информацию, анализировать данные и готовить материалы. Но конечная ценность создается за счет человеческой экспертизы.
Например, примерно так устроена моя работа с Лабораторией Датаиста.
Каждый день агент собирает мне научные статьи по нужным направлениям. Их может быть по 30 штук в день.
На этом этапе я выступаю как оператор.
Мне не нужно вручную искать статьи по десяткам источников. Я просто слежу за тем, чтобы агент каждый день работал, а материалы приходили.
Дальше из этих статей я выбираю ту, которую хочу изучить глубже.
Здесь я уже супервайзер.
Агент дает мне выбор, а я принимаю решение, какую статью изучить.
После этого агент делает полный обзор исследования и автоматически превращает идеи из статьи в контент.
Я читаю получившийся материал, могу поменять формулировку, исправить какие-то слова или добавить собственную мысль.
Здесь я уже выступаю как менеджер.
А дальше все разобранные исследования остаются в моей базе знаний.
Когда ко мне приходит компания с консультацией по ИИ, я могу быстро найти нужное исследование, вспомнить его выводы и сопоставить их с конкретным бизнес-запросом.
И здесь я уже эксперт, который работает вместе с ИИ.
Получается, что все четыре роли могут существовать даже внутри одного процесса.
Не нужно пытаться назначить человеку одну роль навсегда.
В одной точке процесса он оператор, в другой — супервайзер, дальше менеджер, а где-то эксперт.
Поэтому и на самого агента я бы не смотрел как на одного виртуального «сотрудника».
Агент — это набор функций или навыков. Эти навыки соединяются между собой в определенной последовательности.
По сути, агент — это граф навыков, по которому текут данные.
А компания — это огромный граф взаимосвязанных навыков, по которому постоянно движутся данные.
Поэтому при проектировании TO-BE модели я бы начинал с вопроса:
И уже после этого проектировать новый процесс целиком, роль человека и граф навыков агента.
👉 Полная статья
Когда вы переходите от AS-IS процесса к TO-BE, главная ошибка — взять существующую диаграмму и просто добавить в несколько квадратиков слово ИИ.
Для начала нужно полностью пересмотреть его с учетом новых возможностей ИИ.
В старом процессе могут быть операции, которые теперь вообще не нужны.
Поэтому TO-BE — это не автоматизированная версия AS-IS. Это заново спроектированный процесс.
И только после этого нужно определять, какие функции выполняет ИИ, а какие остаются у человека.
Причем роль человека нужно фиксировать заранее.
Когда вы приходите к сотрудникам и говорите, что часть их работы теперь будет выполнять ИИ, естественно возникает вопрос: а что тогда буду делать я?
Отсюда появляется сопротивление.
Нужно сразу объяснить человеку, какой становится его новая роль. А затем обучить его работать в этой роли. Про обучение мы еще поговорим отдельно.
Я бы выделял четыре основные роли человека.
1. Оператор. Процесс может работать автономно, но у системы все равно должен быть ответственный.
Оператор следит, чтобы она работала, контролирует метрики, качество результата, ошибки и данные.
Если результаты работы агента используются для дальнейшего улучшения моделей или самого процесса, оператор контролирует и это.
То есть он уже не выполняет операцию руками — он отвечает за работающую систему.
2. Супервайзер. Здесь ИИ выполняет работу самостоятельно, но в определенных точках должен запросить решение человека.
Одобрять ли действие? Запускать следующий этап или останавливать процесс?
Человек принимает решение, а дальше ИИ продолжает работу.
3. Менеджер. Здесь ИИ тоже готовит информацию: собирает контекст, делает анализ и предлагает варианты.
Но следующее действие выполняет уже сам человек. В этом основное различие.
Супервайзер принимает решение для ИИ, после чего агент продолжает процесс.
Менеджер использует подготовленный ИИ контекст и уже сам что-то делает на его основе.
4. Эксперт. Здесь человек и ИИ работают вместе.
ИИ помогает искать информацию, анализировать данные и готовить материалы. Но конечная ценность создается за счет человеческой экспертизы.
Например, примерно так устроена моя работа с Лабораторией Датаиста.
Каждый день агент собирает мне научные статьи по нужным направлениям. Их может быть по 30 штук в день.
На этом этапе я выступаю как оператор.
Мне не нужно вручную искать статьи по десяткам источников. Я просто слежу за тем, чтобы агент каждый день работал, а материалы приходили.
Дальше из этих статей я выбираю ту, которую хочу изучить глубже.
Здесь я уже супервайзер.
Агент дает мне выбор, а я принимаю решение, какую статью изучить.
После этого агент делает полный обзор исследования и автоматически превращает идеи из статьи в контент.
Я читаю получившийся материал, могу поменять формулировку, исправить какие-то слова или добавить собственную мысль.
Здесь я уже выступаю как менеджер.
А дальше все разобранные исследования остаются в моей базе знаний.
Когда ко мне приходит компания с консультацией по ИИ, я могу быстро найти нужное исследование, вспомнить его выводы и сопоставить их с конкретным бизнес-запросом.
И здесь я уже эксперт, который работает вместе с ИИ.
Получается, что все четыре роли могут существовать даже внутри одного процесса.
Не нужно пытаться назначить человеку одну роль навсегда.
В одной точке процесса он оператор, в другой — супервайзер, дальше менеджер, а где-то эксперт.
Поэтому и на самого агента я бы не смотрел как на одного виртуального «сотрудника».
Агент — это набор функций или навыков. Эти навыки соединяются между собой в определенной последовательности.
По сути, агент — это граф навыков, по которому текут данные.
А компания — это огромный граф взаимосвязанных навыков, по которому постоянно движутся данные.
Поэтому при проектировании TO-BE модели я бы начинал с вопроса:
«Как должен выглядеть этот процесс, если сегодня работу между собой могут разделить человек, ИИ и обычная автоматизация?»
И уже после этого проектировать новый процесс целиком, роль человека и граф навыков агента.
👉 Полная статья
Датаист / Обучение
Как перестроить процесс под ИИ-агентов и не потерять контроль
Просто добавить ИИ в несколько блоков старой схемы — не значит трансформировать процесс. Настоящий редизайн начинается с пересборки TO-BE: часть шагов исчезает, часть объединяется, у части меняется исполнитель. Разбираем семь вопросов к каждому шагу, границы…
❤1👀1
AI-First компания: какая работа остаётся человеку в мире ИИ-агентов
Многие предприниматели сейчас пытаются построить компанию, в которой человека вообще не останется.
Они хотят сделать так, чтобы всё работало автономно. Но я думаю, что цель должна быть другой.
Человека нужно не убрать из процесса, а оставить именно там, где он создает максимальную ценность.
Так и формируется гибридный интеллект компании — когда человек и ИИ усиливают друг друга. Поэтому я бы вообще не говорил, что ИИ заменяет человека.
Человека не заменяют — его повышают.
Если раньше специалист сам решал задачи, то теперь их решают агенты, а человек переходит на уровень выше: проектирует систему, контролирует работу, принимает решения и отвечает за результат.
Мне часто задают вопрос: а что тогда вообще нужно изучать человеку, если все больше работы начинают выполнять агенты?
На мой взгляд, сегодня особенно важны четыре вещи.
Первая — системное мышление.
Раньше человек часто выполнял отдельную операцию внутри большого процесса. Теперь важнее уметь видеть процесс целиком. То есть задача человека постепенно смещается от выполнения работы к проектированию систем, которые эту работу выполняют.
Вторая — критическое мышление.
Даже хорошо построенные системы могут ошибаться. Агенты могут галлюцинировать или выдавать результат, который выглядит правильным, но не решает бизнес-задачу. Поэтому человек должен уметь находить слабые места системы.
Третья — креативное мышление.
Если задача уже хорошо описана, повторяется и имеет понятный результат, рано или поздно ее можно автоматизировать. Ценность человека там, где еще нет готового алгоритма: придумать новый продукт или найти нестандартное решение.
Четвертая — доменная экспертиза.
Предприниматель должен разбираться в бизнесе, а разработчик — в архитектуре систем. Чтобы управлять агентами, нужно понимать предметную область. Потому что в конечном счете именно человек определяет, является ли результат хорошим и можно ли на его основе принимать решение.
Важно понимать, что метрики нужны не только агенту, но и человеку. Нужно измерять не только точность и скорость работы агента, но и то, насколько быстро человек проверяет его результат, сколько ошибок замечает и насколько качественно принимает итоговое решение.
В гибридном процессе измерять нужно всю систему из человека и ИИ.
И здесь появляется ответственность.
Можно делегировать агенту выполнение задач, но ответственность за систему все равно остается у человека.
Поэтому базовым навыком специалиста уже сегодня является умение работать с агентами и создавать их. В передовых компаниях это уже становится новой нормой.
Раньше хороший специалист умел хорошо выполнять свою работу, а теперь должен уметь построить систему, которая выполняет эту работу за него под его контролем.
Поэтому задача ИИ-трансформации — не построить компанию без людей, а поднять человека на следующий уровень и построить вокруг него систему из агентов.
👉 Полная статья
Многие предприниматели сейчас пытаются построить компанию, в которой человека вообще не останется.
Они хотят сделать так, чтобы всё работало автономно. Но я думаю, что цель должна быть другой.
Человека нужно не убрать из процесса, а оставить именно там, где он создает максимальную ценность.
Так и формируется гибридный интеллект компании — когда человек и ИИ усиливают друг друга. Поэтому я бы вообще не говорил, что ИИ заменяет человека.
Человека не заменяют — его повышают.
Если раньше специалист сам решал задачи, то теперь их решают агенты, а человек переходит на уровень выше: проектирует систему, контролирует работу, принимает решения и отвечает за результат.
Мне часто задают вопрос: а что тогда вообще нужно изучать человеку, если все больше работы начинают выполнять агенты?
На мой взгляд, сегодня особенно важны четыре вещи.
Первая — системное мышление.
Раньше человек часто выполнял отдельную операцию внутри большого процесса. Теперь важнее уметь видеть процесс целиком. То есть задача человека постепенно смещается от выполнения работы к проектированию систем, которые эту работу выполняют.
Вторая — критическое мышление.
Даже хорошо построенные системы могут ошибаться. Агенты могут галлюцинировать или выдавать результат, который выглядит правильным, но не решает бизнес-задачу. Поэтому человек должен уметь находить слабые места системы.
Третья — креативное мышление.
Если задача уже хорошо описана, повторяется и имеет понятный результат, рано или поздно ее можно автоматизировать. Ценность человека там, где еще нет готового алгоритма: придумать новый продукт или найти нестандартное решение.
Четвертая — доменная экспертиза.
Предприниматель должен разбираться в бизнесе, а разработчик — в архитектуре систем. Чтобы управлять агентами, нужно понимать предметную область. Потому что в конечном счете именно человек определяет, является ли результат хорошим и можно ли на его основе принимать решение.
Важно понимать, что метрики нужны не только агенту, но и человеку. Нужно измерять не только точность и скорость работы агента, но и то, насколько быстро человек проверяет его результат, сколько ошибок замечает и насколько качественно принимает итоговое решение.
В гибридном процессе измерять нужно всю систему из человека и ИИ.
И здесь появляется ответственность.
Можно делегировать агенту выполнение задач, но ответственность за систему все равно остается у человека.
Поэтому базовым навыком специалиста уже сегодня является умение работать с агентами и создавать их. В передовых компаниях это уже становится новой нормой.
Раньше хороший специалист умел хорошо выполнять свою работу, а теперь должен уметь построить систему, которая выполняет эту работу за него под его контролем.
Поэтому задача ИИ-трансформации — не построить компанию без людей, а поднять человека на следующий уровень и построить вокруг него систему из агентов.
👉 Полная статья
Датаист / Обучение
AI-First компания: какая работа остаётся человеку в мире ИИ-агентов
Когда рутинную интеллектуальную работу забирает агент, человек не исчезает из процесса — он переходит на уровень управления системой. Разбираем четыре роли человека в гибридном контуре, восемь компетенций, которые от этого только дорожают, метрики совместной…
👍1🔥1
Как превратить мышление эксперта в работающего ИИ-агента
Мне часто приходится слышать, что есть эксперты, которых невозможно автоматизировать.
В каком-то смысле я с этим согласен. Если речь идет о творческой работе, стратегии, высокой ответственности или действительно неоднозначных ситуациях, человека не нужно просто пытаться убрать из процесса.
Но агенты нужны не только для автоматизации простых действий.
Когда мы описываем бизнес-процесс, мы в первую очередь отвечаем на вопрос: «Что делает человек?» Например, у рекрутера в процессе может быть действие «проанализировать резюме».
На входе — резюме, на выходе — оценка кандидата и решение, двигать его дальше или нет.
Но сама эта формулировка почти ничего не говорит о реальной экспертизе. Главное скрыто внутри: на что рекрутер смотрит, какие признаки замечает, как их интерпретирует, с чем сравнивает и почему в итоге принимает конкретное решение.
Именно поэтому для создания агентов нужен когнитивный анализ, который мы уже разбирали раньше. Он помогает понять, как думает эксперт, когда решает задачу.
Например, рекрутер видит, что кандидат за три года сменил четыре компании. Сам по себе этот факт еще ничего не означает. Дальше эксперт смотрит, рос ли кандидат при переходах, менялась ли индустрия, насколько последовательно развивалась карьера и как все это связано с требованиями вакансии.
Вот эту структуру мышления уже можно переносить в агента.
Я бы выделил четыре базовых варианта.
1. Вход — выход
Самый простой случай. Мы даем агенту резюме и набор критериев: опыт, стек и индустрия. Агент извлекает данные и заполняет карточку кандидата.
Здесь почти нет сложного рассуждения: есть вход, правила и структурированный результат.
2. Цепочка размышлений
Решение строится последовательно. Например, сначала агент определяет уровень кандидата, затем оценивает релевантность опыта, после этого находит пробелы, определяет, насколько они критичны, и только потом формирует рекомендацию.
Каждый следующий шаг использует результат предыдущего.
3. Дерево размышлений
Иногда у эксперта возникает несколько возможных веток.
Допустим, у кандидата нет опыта в нужной индустрии. Если при этом он решал похожие задачи — идем по одной ветке. Если подобного опыта тоже нет — по другой. А если человек быстро рос и работал в сильных смежных доменах — появляется третья.
То есть агент должен уже не просто идти по фиксированной цепочке, а выбирать направление дальнейшего анализа.
4. Граф размышлений
В сложной экспертной работе новые данные могут заставлять пересматривать предыдущие выводы.
Например, сначала частая смена работы кажется признаком нестабильности. Потом оказывается, что каждый переход сопровождался ростом ответственности, и первоначальную гипотезу приходится пересмотреть. Затем выясняется, что часть переходов происходила внутри одной группы компаний, и оценка снова меняется.
Здесь рассуждение превращается уже в граф: эксперт возвращается к предыдущим выводам, связывает разные признаки и обновляет гипотезы.
Поэтому для создания хорошего агента недостаточно написать: «Ты опытный рекрутер, проанализируй резюме».
Сначала нужно извлечь саму архитектуру мышления эксперта: какие данные он использует, что считает важным, как принимает решение и в каких случаях возвращается к предыдущим выводам.
Получается, что когнитивное интервью — это способ оцифровать экспертное мышление.
При этом эксперта нельзя просто копировать. Он тоже может быть подвержен когнитивным искажениям. Поэтому извлеченную логику нужно сначала проверить и только потом передавать агенту.
Задача не в том, чтобы научить ИИ механически повторять действия человека, а в том, чтобы отделить знания компании от конкретного сотрудника и превратить их в воспроизводимый интеллектуальный процесс.
Тогда экспертиза будет находиться не только в голове человека, а станет частью системы.
👉 Полная статья
Мне часто приходится слышать, что есть эксперты, которых невозможно автоматизировать.
В каком-то смысле я с этим согласен. Если речь идет о творческой работе, стратегии, высокой ответственности или действительно неоднозначных ситуациях, человека не нужно просто пытаться убрать из процесса.
Но агенты нужны не только для автоматизации простых действий.
Когда мы описываем бизнес-процесс, мы в первую очередь отвечаем на вопрос: «Что делает человек?» Например, у рекрутера в процессе может быть действие «проанализировать резюме».
На входе — резюме, на выходе — оценка кандидата и решение, двигать его дальше или нет.
Но сама эта формулировка почти ничего не говорит о реальной экспертизе. Главное скрыто внутри: на что рекрутер смотрит, какие признаки замечает, как их интерпретирует, с чем сравнивает и почему в итоге принимает конкретное решение.
Именно поэтому для создания агентов нужен когнитивный анализ, который мы уже разбирали раньше. Он помогает понять, как думает эксперт, когда решает задачу.
Например, рекрутер видит, что кандидат за три года сменил четыре компании. Сам по себе этот факт еще ничего не означает. Дальше эксперт смотрит, рос ли кандидат при переходах, менялась ли индустрия, насколько последовательно развивалась карьера и как все это связано с требованиями вакансии.
Вот эту структуру мышления уже можно переносить в агента.
Я бы выделил четыре базовых варианта.
1. Вход — выход
Самый простой случай. Мы даем агенту резюме и набор критериев: опыт, стек и индустрия. Агент извлекает данные и заполняет карточку кандидата.
Здесь почти нет сложного рассуждения: есть вход, правила и структурированный результат.
2. Цепочка размышлений
Решение строится последовательно. Например, сначала агент определяет уровень кандидата, затем оценивает релевантность опыта, после этого находит пробелы, определяет, насколько они критичны, и только потом формирует рекомендацию.
Каждый следующий шаг использует результат предыдущего.
3. Дерево размышлений
Иногда у эксперта возникает несколько возможных веток.
Допустим, у кандидата нет опыта в нужной индустрии. Если при этом он решал похожие задачи — идем по одной ветке. Если подобного опыта тоже нет — по другой. А если человек быстро рос и работал в сильных смежных доменах — появляется третья.
То есть агент должен уже не просто идти по фиксированной цепочке, а выбирать направление дальнейшего анализа.
4. Граф размышлений
В сложной экспертной работе новые данные могут заставлять пересматривать предыдущие выводы.
Например, сначала частая смена работы кажется признаком нестабильности. Потом оказывается, что каждый переход сопровождался ростом ответственности, и первоначальную гипотезу приходится пересмотреть. Затем выясняется, что часть переходов происходила внутри одной группы компаний, и оценка снова меняется.
Здесь рассуждение превращается уже в граф: эксперт возвращается к предыдущим выводам, связывает разные признаки и обновляет гипотезы.
Поэтому для создания хорошего агента недостаточно написать: «Ты опытный рекрутер, проанализируй резюме».
Сначала нужно извлечь саму архитектуру мышления эксперта: какие данные он использует, что считает важным, как принимает решение и в каких случаях возвращается к предыдущим выводам.
Получается, что когнитивное интервью — это способ оцифровать экспертное мышление.
При этом эксперта нельзя просто копировать. Он тоже может быть подвержен когнитивным искажениям. Поэтому извлеченную логику нужно сначала проверить и только потом передавать агенту.
Задача не в том, чтобы научить ИИ механически повторять действия человека, а в том, чтобы отделить знания компании от конкретного сотрудника и превратить их в воспроизводимый интеллектуальный процесс.
Тогда экспертиза будет находиться не только в голове человека, а станет частью системы.
👉 Полная статья
Датаист / Обучение
Как превратить человеческое мышление в работающего ИИ-агента
Экспертную интуицию нельзя автоматизировать целиком, но её можно разобрать на части. Разбираем, как решение эксперта раскладывается на когнитивные функции, почему один большой промт проигрывает набору из шести измеримых навыков, какие связи превращают набор…
👍1
Что нужно, чтобы ИИ-автоматизация реально заработала
Мы подходим к концу разбора бизнес-процессов. Со следующего занятия уже начинаем непосредственно собирать ИИ-агентов.
Но перед этим у вас должен быть готов паспорт агента:
1. Карточка процесса;
2. Модель AS-IS;
3. Узкие места;
4. Карта точек автоматизации;
5. Модель TO-BE;
6. Новая роль человека;
7. Данные и интеграции;
8. Граф навыков агента;
9. Метрики пилота;
10. План внедрения.
Тут возникает вопрос: почему ИИ часто не получается внедрить, даже если сам агент работает нормально?
Конечно, проблема может быть технической. Модель может ошибаться или агент может не справляться с задачей. На практике часто причина лежит вообще не в агенте.
Например, агенту просто не дали доступ к нужным данным. Или нет интеграции с CRM, почтой и другими системами, в которых происходит реальная работа.
Вторая проблема — люди продолжают работать по-старому. Вы внедрили агента, но сотрудник все равно делает ту же работу вручную, потому что его роль никто не изменил. Поэтому вместе с агентом нужно проектировать и новую роль человека, а потом обучать людей работать уже в новой системе.
И наконец — метрики нужно определить до разработки. Не «сделаем агента поддержки». А, например: сократим среднее время обработки обращения с восьми до двух минут, при этом качество не должно ухудшиться.
Должно быть понятно: что было, что хотим получить, как измерим и за какой срок.
Потому что агент может прекрасно работать технически, но если мы заранее не договорились, какой бизнес-результат он должен дать, мы никогда не поймем, было внедрение успешным или нет.
Получается вся методология довольно простая:
И только после этого мы переходим от проектирования к практике — и начнем собирать агентов.
👉 Полная статья
Мы подходим к концу разбора бизнес-процессов. Со следующего занятия уже начинаем непосредственно собирать ИИ-агентов.
Но перед этим у вас должен быть готов паспорт агента:
1. Карточка процесса;
2. Модель AS-IS;
3. Узкие места;
4. Карта точек автоматизации;
5. Модель TO-BE;
6. Новая роль человека;
7. Данные и интеграции;
8. Граф навыков агента;
9. Метрики пилота;
10. План внедрения.
Тут возникает вопрос: почему ИИ часто не получается внедрить, даже если сам агент работает нормально?
Конечно, проблема может быть технической. Модель может ошибаться или агент может не справляться с задачей. На практике часто причина лежит вообще не в агенте.
Например, агенту просто не дали доступ к нужным данным. Или нет интеграции с CRM, почтой и другими системами, в которых происходит реальная работа.
Вторая проблема — люди продолжают работать по-старому. Вы внедрили агента, но сотрудник все равно делает ту же работу вручную, потому что его роль никто не изменил. Поэтому вместе с агентом нужно проектировать и новую роль человека, а потом обучать людей работать уже в новой системе.
И наконец — метрики нужно определить до разработки. Не «сделаем агента поддержки». А, например: сократим среднее время обработки обращения с восьми до двух минут, при этом качество не должно ухудшиться.
Должно быть понятно: что было, что хотим получить, как измерим и за какой срок.
Потому что агент может прекрасно работать технически, но если мы заранее не договорились, какой бизнес-результат он должен дать, мы никогда не поймем, было внедрение успешным или нет.
Получается вся методология довольно простая:
Метрики → AS-IS → точки автоматизации → TO-BE → новая роль человека → граф навыков агента → пилот и внедрение
И только после этого мы переходим от проектирования к практике — и начнем собирать агентов.
👉 Полная статья
Датаист / Обучение
Что нужно, чтобы ИИ-автоматизация реально заработала
Хороший ИИ-агент не спасает проект, если вокруг него ничего не выстроено. Разбираем десять артефактов, без которых ИИ-агент не заработает, порядок работы с метриками эффекта, шесть причин, по которым автоматизация проваливается, и всю методологию целиком…
Как превратить бизнес-процесс в работающего ИИ-агента
Недавно я делился аналитикой о том, что многие недооценивают роль обучения. При этом именно обучение помогает адаптироваться к происходящим изменениям.
Поэтому я стараюсь передавать все, что знаю и использую сам, чтобы помочь другим быстрее войти в новую экономику.
Доступен третий модуль курса «Автоматизация бизнес-процессов с помощью ИИ-агентов».
В прошлом модуле мы разобрали, как восстановить реальный бизнес-процесс AS-IS, найти в нем точки автоматизации и спроектировать целевой процесс TO-BE.
Теперь следующий вопрос: как из этого TO-BE получить работающего ИИ-агента?
На практике многие начинают не с того конца. Открывают n8n или другую платформу, выбирают модель, подключают несколько инструментов, пишут большой промт — и пытаются заставить все это работать.
Но прежде чем что-либо собирать, нужно понять, как ИИ-агент встраивается в поток данных, создающий ценность для бизнеса: какие данные он получает, что с ними делает, какой результат передает дальше и где заканчивается его автономность.
Поэтому в третьем модуле мы проходим весь путь от бизнес-процесса до работающего агента.
• Связываем TO-BE с автоматизацией: где достаточно обычного правила, где нужен ИИ, где решение остается за человеком и чем воркфлоу отличается от настоящего агента;
• Проектируем граф навыков агента: какие операции он умеет выполнять и какие решения принимает;
• Разбираем основные ИИ-операции: классификацию, извлечение информации, генерацию и вызов инструментов;
• Разрабатываем воркфлоу: определяем, как между шагами передаются данные и где появляются условия и циклы;
• Пишем промты: из чего состоит хороший промт, как получать структурированный результат и как улучшать промты;
• Собираем контекст: какие данные агенту нужны сейчас, что хранить в состоянии и долгосрочной памяти;
• Подключаем инструменты и ИИ-платформу: как агент вызывает внешние сервисы и как настроить общий доступ к данным для множества агентов;
• Настраиваем базовую надежность: права, ограничения и контроль работы агентов;
• Учимся тестировать весь путь работы агента после каждого изменения модели, промта, контекста или инструмента.
В конце модуля вас ждет тест и практическое задание.
Вы возьмете свой целевой TO-BE процесс из предыдущего модуля, превратите его в архитектуру одного ИИ-агента и соберете его в n8n или на любой другой платформе.
В итоге у вас появится первый работающий агент для вашего бизнес-процесса.
В модуле доступны презентация, видеоурок и подробный текстовый материал. А в этом канале я дополнительно делюсь своим опытом и подробнее разбираю отдельные темы.
В следующих модулях мы детально разберем, как объединять нескольких агентов в мультиагентную систему и на ее основе строить целую AI-First компанию, обсудим разработку кастомных сервисов с ИИ-агентами, создадим дашборд для мониторинга их работы, научимся управлять изменениями в компании и считать экономический эффект.
Если у вас есть свой бизнес и вы еще не автоматизируете его с помощью ИИ-агентов, то чем вы вообще занимаетесь?
А если своего бизнеса нет — сегодня самое время начать. Работа по найму уже не гарантирует стабильности. ИИ впервые дает одному человеку или небольшой команде доступ к ресурсам, которые раньше были доступны только крупным компаниям.
Так что путь к свободе сегодня может начинаться с собственного AI-First бизнеса. Курс доступен для всех бесплатно — бери не хочу.
👉 Смотреть третью лекцию
Недавно я делился аналитикой о том, что многие недооценивают роль обучения. При этом именно обучение помогает адаптироваться к происходящим изменениям.
Поэтому я стараюсь передавать все, что знаю и использую сам, чтобы помочь другим быстрее войти в новую экономику.
Доступен третий модуль курса «Автоматизация бизнес-процессов с помощью ИИ-агентов».
В прошлом модуле мы разобрали, как восстановить реальный бизнес-процесс AS-IS, найти в нем точки автоматизации и спроектировать целевой процесс TO-BE.
Теперь следующий вопрос: как из этого TO-BE получить работающего ИИ-агента?
На практике многие начинают не с того конца. Открывают n8n или другую платформу, выбирают модель, подключают несколько инструментов, пишут большой промт — и пытаются заставить все это работать.
Но прежде чем что-либо собирать, нужно понять, как ИИ-агент встраивается в поток данных, создающий ценность для бизнеса: какие данные он получает, что с ними делает, какой результат передает дальше и где заканчивается его автономность.
Поэтому в третьем модуле мы проходим весь путь от бизнес-процесса до работающего агента.
• Связываем TO-BE с автоматизацией: где достаточно обычного правила, где нужен ИИ, где решение остается за человеком и чем воркфлоу отличается от настоящего агента;
• Проектируем граф навыков агента: какие операции он умеет выполнять и какие решения принимает;
• Разбираем основные ИИ-операции: классификацию, извлечение информации, генерацию и вызов инструментов;
• Разрабатываем воркфлоу: определяем, как между шагами передаются данные и где появляются условия и циклы;
• Пишем промты: из чего состоит хороший промт, как получать структурированный результат и как улучшать промты;
• Собираем контекст: какие данные агенту нужны сейчас, что хранить в состоянии и долгосрочной памяти;
• Подключаем инструменты и ИИ-платформу: как агент вызывает внешние сервисы и как настроить общий доступ к данным для множества агентов;
• Настраиваем базовую надежность: права, ограничения и контроль работы агентов;
• Учимся тестировать весь путь работы агента после каждого изменения модели, промта, контекста или инструмента.
В конце модуля вас ждет тест и практическое задание.
Вы возьмете свой целевой TO-BE процесс из предыдущего модуля, превратите его в архитектуру одного ИИ-агента и соберете его в n8n или на любой другой платформе.
В итоге у вас появится первый работающий агент для вашего бизнес-процесса.
В модуле доступны презентация, видеоурок и подробный текстовый материал. А в этом канале я дополнительно делюсь своим опытом и подробнее разбираю отдельные темы.
В следующих модулях мы детально разберем, как объединять нескольких агентов в мультиагентную систему и на ее основе строить целую AI-First компанию, обсудим разработку кастомных сервисов с ИИ-агентами, создадим дашборд для мониторинга их работы, научимся управлять изменениями в компании и считать экономический эффект.
Если у вас есть свой бизнес и вы еще не автоматизируете его с помощью ИИ-агентов, то чем вы вообще занимаетесь?
А если своего бизнеса нет — сегодня самое время начать. Работа по найму уже не гарантирует стабильности. ИИ впервые дает одному человеку или небольшой команде доступ к ресурсам, которые раньше были доступны только крупным компаниям.
Так что путь к свободе сегодня может начинаться с собственного AI-First бизнеса. Курс доступен для всех бесплатно — бери не хочу.
👉 Смотреть третью лекцию
Andre AIT
Модуль 3 — Инженерия ИИ-агентов
Вы научитесь проектировать процесс до автоматизации, отличать воркфлоу от агента, писать спецификацию агента, собирать промт, контекст и обвязку, тестировать поведение и выводить агента в работу.
👍2🔥1
Где бизнес-процессу нужен ИИ-агент, а где нет
В прошлом модуле мы разбирали, как описать процесс AS-IS, найти точки автоматизации и спроектировать целевую TO-BE модель.
Освежим в памяти, что важно не просто поставить ИИ на место человека. Если в старом процессе документ пересылают между пятью сотрудниками и дважды переносят одни и те же данные, автоматизация этих действий просто ускорит лишнюю работу. Сначала нужно пересобрать процесс, а уже потом выбирать, как выполнять каждый шаг.
Любую автоматизацию можно разложить на три части: триггер, обработка и действие. Пришла заявка — триггер. Система проверила данные и определила дальнейший маршрут — обработка. Изменила статус и отправила ответ — действие.
Но когда мы проектируем эту систему, нужно ответить на два разных вопроса.
Первый: чем решать конкретную задачу — кодом или ИИ?
Допустим, платежи больше 10 000 долларов должны уходить на дополнительное согласование. Здесь достаточно сравнить сумму с порогом. LLM здесь не нужна: она только увеличит стоимость, задержку и риск ошибки.
А вот если клиент написал сообщение в свободной форме, то может потребоваться понять его смысл: он просит возврат или хочет изменить заказ? В таком случае имеет смысл подключить модель.
Это первая распространенная ошибка: люди строят LLM-воркфлоу там, где задачу нужно решать обычным кодом.
Второй вопрос: кто определяет последовательность шагов — мы заранее или система во время работы?
Если маршрут известен, нужен воркфлоу. Получить обращение, определить его категорию и направить нужному сотруднику. Внутри такого воркфлоу может быть и код, и вызов ИИ-модели. Но возможные переходы между шагами мы спроектировали заранее.
Если следующий шаг зависит от того, что выяснится в процессе, тогда может понадобиться ИИ-агент. Ему задают цель, инструменты и ограничения, а путь он выстраивает сам: ищет недостающие данные, оценивает результат и решает, что делать дальше.
Я смотрю на агента как на «динамический воркфлоу». В обычном воркфлоу весь путь задан до запуска. У агента путь возникает по ходу выполнения задачи.
Здесь вторая распространенная ошибка: агента заставляют делать то, где путь давно известен.
Сегодня он выполнит задачу за пять шагов, завтра — за восемь. Может выбрать другие инструменты и прийти к несколько иному результату. Вместе с новым маршрутом меняются время, стоимость и предсказуемость работы. Такая гибкость оправданна, только если есть некоторая степень неопределенности.
Поэтому я рекомендую начинать со стабильных RUN-процессов: повторяющихся задач с понятными входами и результатом. Для них можно заранее задать маршрут, а внутри него использовать код везде, где решение формализуется. Это проще поддерживать и считать экономику каждого запуска.
Агентность стоит добавлять в исследовательской задаче или сложных задачах без понятного способа решения. При этом агенту не обязательно отдавать весь процесс. Воркфлоу может задавать основной каркас процесса, а агент — работать на отдельном участке.
Человек тоже остается частью системы: он задает цель и ограничения, утверждает решения и подключается по необходимости.
Получается, выбор делается на двух уровнях. Для отдельного шага — правило или ИИ. Для маршрута в целом — воркфлоу или агент. И только после этого становится понятно, какую роль в TO-BE процессе оставить человеку.
👉 Полная статья
В прошлом модуле мы разбирали, как описать процесс AS-IS, найти точки автоматизации и спроектировать целевую TO-BE модель.
Освежим в памяти, что важно не просто поставить ИИ на место человека. Если в старом процессе документ пересылают между пятью сотрудниками и дважды переносят одни и те же данные, автоматизация этих действий просто ускорит лишнюю работу. Сначала нужно пересобрать процесс, а уже потом выбирать, как выполнять каждый шаг.
Любую автоматизацию можно разложить на три части: триггер, обработка и действие. Пришла заявка — триггер. Система проверила данные и определила дальнейший маршрут — обработка. Изменила статус и отправила ответ — действие.
Но когда мы проектируем эту систему, нужно ответить на два разных вопроса.
Первый: чем решать конкретную задачу — кодом или ИИ?
Допустим, платежи больше 10 000 долларов должны уходить на дополнительное согласование. Здесь достаточно сравнить сумму с порогом. LLM здесь не нужна: она только увеличит стоимость, задержку и риск ошибки.
А вот если клиент написал сообщение в свободной форме, то может потребоваться понять его смысл: он просит возврат или хочет изменить заказ? В таком случае имеет смысл подключить модель.
Это первая распространенная ошибка: люди строят LLM-воркфлоу там, где задачу нужно решать обычным кодом.
Второй вопрос: кто определяет последовательность шагов — мы заранее или система во время работы?
Если маршрут известен, нужен воркфлоу. Получить обращение, определить его категорию и направить нужному сотруднику. Внутри такого воркфлоу может быть и код, и вызов ИИ-модели. Но возможные переходы между шагами мы спроектировали заранее.
Если следующий шаг зависит от того, что выяснится в процессе, тогда может понадобиться ИИ-агент. Ему задают цель, инструменты и ограничения, а путь он выстраивает сам: ищет недостающие данные, оценивает результат и решает, что делать дальше.
Я смотрю на агента как на «динамический воркфлоу». В обычном воркфлоу весь путь задан до запуска. У агента путь возникает по ходу выполнения задачи.
Здесь вторая распространенная ошибка: агента заставляют делать то, где путь давно известен.
Сегодня он выполнит задачу за пять шагов, завтра — за восемь. Может выбрать другие инструменты и прийти к несколько иному результату. Вместе с новым маршрутом меняются время, стоимость и предсказуемость работы. Такая гибкость оправданна, только если есть некоторая степень неопределенности.
Поэтому я рекомендую начинать со стабильных RUN-процессов: повторяющихся задач с понятными входами и результатом. Для них можно заранее задать маршрут, а внутри него использовать код везде, где решение формализуется. Это проще поддерживать и считать экономику каждого запуска.
Агентность стоит добавлять в исследовательской задаче или сложных задачах без понятного способа решения. При этом агенту не обязательно отдавать весь процесс. Воркфлоу может задавать основной каркас процесса, а агент — работать на отдельном участке.
Человек тоже остается частью системы: он задает цель и ограничения, утверждает решения и подключается по необходимости.
Получается, выбор делается на двух уровнях. Для отдельного шага — правило или ИИ. Для маршрута в целом — воркфлоу или агент. И только после этого становится понятно, какую роль в TO-BE процессе оставить человеку.
👉 Полная статья
Датаист / Обучение
Где процессу нужен ИИ-агент, а где хватит правила
Собрать ИИ-агента — ещё не значит получить систему, которая работает каждый день. Для этого нужно продумать процесс, самого агента и его эксплуатацию. Начнём с процесса: почему нельзя автоматизировать лишние шаги, из чего состоит автоматизация, когда хватает…
ИИ-платформа: как собрать агентов в единую систему
Сначала мы делаем пилот одного агента. Собрали, проверили — работает. Но дальше, конечно, захотим второго, третьего, десятого. И что, каждый раз заново выдавать инструменты, настраивать подключения к системам и память? Конечно нет.
Уже на втором агенте возникает вопрос платформенности. Хороший технический специалист всегда стремится переиспользовать компоненты и подходы. Если подключение к CRM уже сделано, следующие агенты должны использовать его, а не получать каждый свою отдельную интеграцию.
В перспективе нам нужно управлять целой командой агентов. Поэтому им нужны общая память о работе компании, согласованные данные и единое понимание сущностей. При этом каждый агент получает только те данные и полномочия, которые нужны для его роли.
Собрать одного агента для пилота несложно. Объединить их так, чтобы они вместе выполняли работу компании, — уже архитектурная задача.
Этот фундамент нужно продумывать с первого пилота, а не когда десяток отдельных решений уже разросся.
Для этого удобно разделить платформу на четыре слоя:
1. Инфраструктура. Физическая среда, в которой работают агенты. Это может быть облако или закрытый контур — с учётом конфиденциальности данных и требований безопасности.
2. Сервисы. Внутренние и внешние системы, интеграции и инструменты, через которые агенты действуют: CRM, почта, документооборот, API. Тут готовые подключения и компоненты переиспользуются.
3. Данные. Информация, знания и память, с которыми работают агенты. Здесь важно определить источники, обеспечить актуальность и согласованность данных, а также настроить доступ по ролям.
4. Интеллект. Сами модели, на которых работают агенты. Верхний слой опирается на инфраструктуру, сервисы и данные.
Когда проектируете агента, смотрите на все четыре слоя и сразу думайте, что понадобится следующим.
При этом платформу можно взять готовую или построить свою.
Например, в n8n и подобных платформах уже можно собирать агентов и воркфлоу, использовать готовые интеграции, подключать модели и инструменты.
Есть и механизмы хранения учётных данных, управления доступами и совместной работы — конкретные возможности зависят от редакции и тарифа.
Вы используете готовую среду, создаёте решения, делитесь ими с коллегами и переиспользуете компоненты. Но свои данные, общую память, права и бизнес-правила всё равно нужно организовать.
Готовую платформу тоже можно развернуть внутри компании: например, n8n поддерживает самостоятельное размещение. Поэтому «готовая или своя платформа» и «облако или закрытый контур» — два отдельных выбора.
В большой компании проблема усиливается: каждая команда начинает делать своих агентов, повторно собирает одни и те же доступы и данные. Постепенно всё равно появляется потребность в общей платформе и ответственном за неё.
Поэтому я поддерживаю централизацию ИИ-функции. Она должна отвечать за общую платформу и единые стандарты. А ещё — за то, чтобы было видно, какой агент что выполнил, где произошёл сбой и какой результат получен.
На этой основе каждая команда сможет создавать агентов под свои задачи и включать их в общую работу компании.
Продумать это и выбрать платформу стоит до внедрения первого агента.
Будущее принадлежит не тем, кто создаст тысячи разных агентов, а тем, кто построит платформу для быстрого создания неограниченного числа агентов.
👉 Полная статья
Сначала мы делаем пилот одного агента. Собрали, проверили — работает. Но дальше, конечно, захотим второго, третьего, десятого. И что, каждый раз заново выдавать инструменты, настраивать подключения к системам и память? Конечно нет.
Уже на втором агенте возникает вопрос платформенности. Хороший технический специалист всегда стремится переиспользовать компоненты и подходы. Если подключение к CRM уже сделано, следующие агенты должны использовать его, а не получать каждый свою отдельную интеграцию.
В перспективе нам нужно управлять целой командой агентов. Поэтому им нужны общая память о работе компании, согласованные данные и единое понимание сущностей. При этом каждый агент получает только те данные и полномочия, которые нужны для его роли.
Собрать одного агента для пилота несложно. Объединить их так, чтобы они вместе выполняли работу компании, — уже архитектурная задача.
Этот фундамент нужно продумывать с первого пилота, а не когда десяток отдельных решений уже разросся.
Для этого удобно разделить платформу на четыре слоя:
1. Инфраструктура. Физическая среда, в которой работают агенты. Это может быть облако или закрытый контур — с учётом конфиденциальности данных и требований безопасности.
2. Сервисы. Внутренние и внешние системы, интеграции и инструменты, через которые агенты действуют: CRM, почта, документооборот, API. Тут готовые подключения и компоненты переиспользуются.
3. Данные. Информация, знания и память, с которыми работают агенты. Здесь важно определить источники, обеспечить актуальность и согласованность данных, а также настроить доступ по ролям.
4. Интеллект. Сами модели, на которых работают агенты. Верхний слой опирается на инфраструктуру, сервисы и данные.
Когда проектируете агента, смотрите на все четыре слоя и сразу думайте, что понадобится следующим.
При этом платформу можно взять готовую или построить свою.
Например, в n8n и подобных платформах уже можно собирать агентов и воркфлоу, использовать готовые интеграции, подключать модели и инструменты.
Есть и механизмы хранения учётных данных, управления доступами и совместной работы — конкретные возможности зависят от редакции и тарифа.
Вы используете готовую среду, создаёте решения, делитесь ими с коллегами и переиспользуете компоненты. Но свои данные, общую память, права и бизнес-правила всё равно нужно организовать.
Готовую платформу тоже можно развернуть внутри компании: например, n8n поддерживает самостоятельное размещение. Поэтому «готовая или своя платформа» и «облако или закрытый контур» — два отдельных выбора.
В большой компании проблема усиливается: каждая команда начинает делать своих агентов, повторно собирает одни и те же доступы и данные. Постепенно всё равно появляется потребность в общей платформе и ответственном за неё.
Поэтому я поддерживаю централизацию ИИ-функции. Она должна отвечать за общую платформу и единые стандарты. А ещё — за то, чтобы было видно, какой агент что выполнил, где произошёл сбой и какой результат получен.
На этой основе каждая команда сможет создавать агентов под свои задачи и включать их в общую работу компании.
Продумать это и выбрать платформу стоит до внедрения первого агента.
Будущее принадлежит не тем, кто создаст тысячи разных агентов, а тем, кто построит платформу для быстрого создания неограниченного числа агентов.
👉 Полная статья
Датаист / Обучение
ИИ-платформа: как собрать агентов в единую систему
Первого ИИ-агента можно собрать как отдельное решение. Со вторым возникает новый вопрос: как согласовать их данные, доступы и работу? Если каждый агент устроен по-своему, компания быстро получает зоопарк решений. Разберём, чем ИИ-платформа отличается от отдельного…
👍1
Архитектура ИИ-агента: от LLM-функции до графа навыков
Мой подход к архитектуре агента простой: сначала нужно разложить бизнес-задачу на атомарные операции и понять, где нужно самостоятельно выбирать следующий шаг, а где шаги заранее понятны. После этого уже выбирать модель, писать промты и подключать инструменты.
Несколько советов, которые я бы добавил к этой теме:
1. Не перестаю повторять — отдавайте коду или обычным скриптам всё, что нужно надёжно выполнить. Каждый лишний вызов модели добавляет время, стоимость и риск ошибки. Используйте LLM только там, где нужно разобраться в тексте или поработать с неопределённостью. Если процесс имеет понятные шаги — собираем воркфлоу из LLM-функций. Если воркфлоу невозможно спроектировать заранее — в работу включается агент.
2. Разделяйте задачу на навыки, которые можно проверить отдельно. «Обработать обращение клиента» — слишком широкая задача: при ошибке трудно понять, что именно пошло не так. «Определить категорию», «найти заказ», «проверить условия возврата» — вот это уже понятные операции. У каждой должны быть входные данные, ожидаемый результат и критерий корректности. При этом для каждого навыка необязательно создавать отдельного агента.
3. Делайте ответы инструментов понятными. «Ничего не найдено», «нет доступа» и «сервис временно недоступен» требуют разных следующих действий. Если инструмент во всех случаях возвращает пустой ответ, агенту приходится угадывать. Поэтому заранее определите, как инструмент сообщает об успехе, отсутствии данных и ошибке.
4. Проверяйте, безопасно ли повторять действие. Допустим, агент создал заявку, но не получил ответ из-за ошибки. Повторный вызов может создать вторую заявку. Ошибка ещё не означает, что операция не выполнилась. Нужна проверка её статуса или защита от повторного выполнения. Особенно когда речь идёт о письмах и изменениях в системах.
5. Передавайте между навыками конкретные артефакты. Отдельно храните подтверждённые факты, предположения и уже выполненные действия. Тогда следующий шаг получает понятное состояние задачи, а после сбоя можно продолжить с нужного места.
6. Сразу проверяйте сценарии, в которых что-то идёт не так. Например, может отсутствовать нужный документ, данные противоречат друг другу или сервис не отвечает. Для каждого такого случая заранее определите следующий шаг: может, нужно уточнить, повторить попытку, остановиться или передать человеку.
Задавайте лимиты на общее число шагов, время и стоимость запуска. Написать агенту «пытайся, пока не получится» может дорого вам обойтись.
Для меня хорошая архитектура агента — это когда каждый навык можно проверить, понятно, почему система выбрала следующий шаг, и предусмотрено, что делать после ошибки.
👉 Полная статья
Мой подход к архитектуре агента простой: сначала нужно разложить бизнес-задачу на атомарные операции и понять, где нужно самостоятельно выбирать следующий шаг, а где шаги заранее понятны. После этого уже выбирать модель, писать промты и подключать инструменты.
Несколько советов, которые я бы добавил к этой теме:
1. Не перестаю повторять — отдавайте коду или обычным скриптам всё, что нужно надёжно выполнить. Каждый лишний вызов модели добавляет время, стоимость и риск ошибки. Используйте LLM только там, где нужно разобраться в тексте или поработать с неопределённостью. Если процесс имеет понятные шаги — собираем воркфлоу из LLM-функций. Если воркфлоу невозможно спроектировать заранее — в работу включается агент.
2. Разделяйте задачу на навыки, которые можно проверить отдельно. «Обработать обращение клиента» — слишком широкая задача: при ошибке трудно понять, что именно пошло не так. «Определить категорию», «найти заказ», «проверить условия возврата» — вот это уже понятные операции. У каждой должны быть входные данные, ожидаемый результат и критерий корректности. При этом для каждого навыка необязательно создавать отдельного агента.
3. Делайте ответы инструментов понятными. «Ничего не найдено», «нет доступа» и «сервис временно недоступен» требуют разных следующих действий. Если инструмент во всех случаях возвращает пустой ответ, агенту приходится угадывать. Поэтому заранее определите, как инструмент сообщает об успехе, отсутствии данных и ошибке.
4. Проверяйте, безопасно ли повторять действие. Допустим, агент создал заявку, но не получил ответ из-за ошибки. Повторный вызов может создать вторую заявку. Ошибка ещё не означает, что операция не выполнилась. Нужна проверка её статуса или защита от повторного выполнения. Особенно когда речь идёт о письмах и изменениях в системах.
5. Передавайте между навыками конкретные артефакты. Отдельно храните подтверждённые факты, предположения и уже выполненные действия. Тогда следующий шаг получает понятное состояние задачи, а после сбоя можно продолжить с нужного места.
6. Сразу проверяйте сценарии, в которых что-то идёт не так. Например, может отсутствовать нужный документ, данные противоречат друг другу или сервис не отвечает. Для каждого такого случая заранее определите следующий шаг: может, нужно уточнить, повторить попытку, остановиться или передать человеку.
Задавайте лимиты на общее число шагов, время и стоимость запуска. Написать агенту «пытайся, пока не получится» может дорого вам обойтись.
Для меня хорошая архитектура агента — это когда каждый навык можно проверить, понятно, почему система выбрала следующий шаг, и предусмотрено, что делать после ошибки.
👉 Полная статья
Датаист / Обучение
Архитектура ИИ-агента: от LLM-функции до графа навыков
Вызов языковой модели ещё не делает систему агентом. Агент появляется там, где система сама выбирает следующие действия для достижения цели. Разберём, когда достаточно LLM-функции, как описать поведение агента до разработки, где ограничить его автономность…
ИИ-операции и инструменты: как решение модели становится действием
Можно подключить ИИ-агента к любой системе, но само подключение ещё мало говорит о том, насколько хорошо агент будет выполнять задачу.
Тут главный вопрос: «Что именно модель должна решить, а что система может выполнить программно?»
Допустим, клиент пишет:
На первый взгляд всё просто: найти заказ, обновить адрес и сообщить клиенту результат.
Но внутри сразу появляются вопросы. Как определить клиента? Что считать последним заказом? Можно ли ещё изменить адрес? А если найдено несколько заказов? И что делать, если новый адрес указан не полностью?
В этих деталях решение модели превращается в действие.
Я бы выделил четыре вещи, которые стоит продумать заранее:
1. Какие параметры действительно должна выбирать модель
Если пользователь уже авторизован, его ID и организацию система знает. Эти данные можно передать инструменту программно.
Модель при этом разбирается в том, что человек хочет сделать, какие данные сообщил и чего не хватает.
Модели стоит поручать выбор параметров и извлечение данных из обращения. Значения, которые уже известны системе, лучше подставлять программно.
При этом ID конкретного заказа нужно получить из результатов поиска. Придумывать его агент не должен.
2. Как описать инструмент для модели
Описание «обновить заказ» слишком неполное для агента.
Нужно указать, какие поля можно менять, какие данные обязательны и в каких случаях операция допустима.
То же самое с параметрами. «Дата — строка» не объясняет формат и часовой пояс. «Сумма — число» не объясняет валюту и единицы измерения.
Поэтому к сложным инструментам полезно добавлять примеры вызовов. По ним проще понять, какие значения ожидаются и как параметры связаны между собой.
Допустимость операции и корректность параметров должна проверять программа.
3. Что агент узнает из результата
Инструмент должен вернуть информацию, по которой можно выбрать следующий шаг.
Например, поиск нашёл два подходящих заказа. Тогда агенту нужны их идентификаторы и признаки, позволяющие различить записи: дата, состав или статус.
Если показана только часть результатов, об этом тоже нужно сообщить. Иначе агент может принять неполную выдачу за все найденные данные.
После изменения адреса нужен подтверждённый результат операции. На его основе агент уже может ответить клиенту.
4. Где можно заранее определить последовательность действий
Чтобы понять, можно ли изменить адрес, иногда нужно получить заказ, проверить его статус и узнать условия доставки.
Если порядок этих проверок заранее понятен, их можно объединить внутри одного инструмента. Код выполнит обращения к API и вернёт результат.
Модель подключается там, где действительно возникает выбор: нужно ли уточнить заказ, запросить недостающие данные, предложить другой вариант или завершить задачу.
При этом вопрос «можно ли поменять адрес?» должен приводить к проверке возможности, а не автоматически к изменению.
Когда агент ошибается, я бы сначала проверял весь путь: какие инструменты он получил, какие аргументы сформировал, что программа отправила в API и какой результат вернула.
Так становится понятно, где именно возникла проблема.
Качество агента определяется тем, насколько хорошо спроектирована связь между его решением и действием системы. Чем понятнее эта связь, тем проще проверить результат и разобраться в ошибке.
👉 Полная статья
Можно подключить ИИ-агента к любой системе, но само подключение ещё мало говорит о том, насколько хорошо агент будет выполнять задачу.
Тут главный вопрос: «Что именно модель должна решить, а что система может выполнить программно?»
Допустим, клиент пишет:
«Найдите мой последний заказ и поменяйте адрес доставки».
На первый взгляд всё просто: найти заказ, обновить адрес и сообщить клиенту результат.
Но внутри сразу появляются вопросы. Как определить клиента? Что считать последним заказом? Можно ли ещё изменить адрес? А если найдено несколько заказов? И что делать, если новый адрес указан не полностью?
В этих деталях решение модели превращается в действие.
Я бы выделил четыре вещи, которые стоит продумать заранее:
1. Какие параметры действительно должна выбирать модель
Если пользователь уже авторизован, его ID и организацию система знает. Эти данные можно передать инструменту программно.
Модель при этом разбирается в том, что человек хочет сделать, какие данные сообщил и чего не хватает.
Модели стоит поручать выбор параметров и извлечение данных из обращения. Значения, которые уже известны системе, лучше подставлять программно.
При этом ID конкретного заказа нужно получить из результатов поиска. Придумывать его агент не должен.
2. Как описать инструмент для модели
Описание «обновить заказ» слишком неполное для агента.
Нужно указать, какие поля можно менять, какие данные обязательны и в каких случаях операция допустима.
То же самое с параметрами. «Дата — строка» не объясняет формат и часовой пояс. «Сумма — число» не объясняет валюту и единицы измерения.
Поэтому к сложным инструментам полезно добавлять примеры вызовов. По ним проще понять, какие значения ожидаются и как параметры связаны между собой.
Допустимость операции и корректность параметров должна проверять программа.
3. Что агент узнает из результата
Инструмент должен вернуть информацию, по которой можно выбрать следующий шаг.
Например, поиск нашёл два подходящих заказа. Тогда агенту нужны их идентификаторы и признаки, позволяющие различить записи: дата, состав или статус.
Если показана только часть результатов, об этом тоже нужно сообщить. Иначе агент может принять неполную выдачу за все найденные данные.
После изменения адреса нужен подтверждённый результат операции. На его основе агент уже может ответить клиенту.
4. Где можно заранее определить последовательность действий
Чтобы понять, можно ли изменить адрес, иногда нужно получить заказ, проверить его статус и узнать условия доставки.
Если порядок этих проверок заранее понятен, их можно объединить внутри одного инструмента. Код выполнит обращения к API и вернёт результат.
Модель подключается там, где действительно возникает выбор: нужно ли уточнить заказ, запросить недостающие данные, предложить другой вариант или завершить задачу.
При этом вопрос «можно ли поменять адрес?» должен приводить к проверке возможности, а не автоматически к изменению.
Когда агент ошибается, я бы сначала проверял весь путь: какие инструменты он получил, какие аргументы сформировал, что программа отправила в API и какой результат вернула.
Так становится понятно, где именно возникла проблема.
Качество агента определяется тем, насколько хорошо спроектирована связь между его решением и действием системы. Чем понятнее эта связь, тем проще проверить результат и разобраться в ошибке.
👉 Полная статья
Датаист / Обучение
ИИ-операции и инструменты: как решение модели становится действием
Прежде чем строить ИИ-агента, стоит понять, какую работу нужно поручить модели. Разберём шесть типовых ИИ-операций, выбор модели под задачу, вызов функций и описание инструментов. Затем посмотрим, как среда исполнения обращается к внешним системам через API…
Как данные движутся по ИИ-воркфлоу
В одной компании я создавал агента-оркестратора, который использовал другие воркфлоу в качестве инструментов.
В такой архитектуре агент выбирает, какой процесс выполнить, а выбранный воркфлоу запускает заранее определённую последовательность действий и возвращает результат.
Допустим, клиент просит оформить возврат. Один воркфлоу находит его заказы, другой проверяет условия возврата, третий создаёт заявку.
По пути текст обращения превращается в структурированные данные, из списка заказов выбирается нужный, а результат проверки определяет, можно ли двигаться дальше.
Для меня основная работа здесь — инженерия данных. Нужно организовать их движение: получить из нужного источника, преобразовать, связать между собой и передать следующему шагу, сохранив смысл.
Я бы выделил шесть пунктов, которые стоит продумать:
1. Разделяйте процесс на подпроцессы
Инструмент агента необязательно должен выполнять один запрос к API. Если для проверки возврата нужно получить заказ, посмотреть его статус и проверить сроки, эту последовательность можно собрать в отдельный воркфлоу.
С такими подпроцессами удобнее работать: их можно отдельно проверять, дорабатывать и использовать в разных задачах.
Компания в этом смысле похожа на конструктор LEGO. Из одних и тех же операций и подпроцессов можно собирать разные бизнес-процессы. Но у каждого такого «кубика» должны быть понятные входные данные и результат. Тогда оркестратор сможет выбрать нужный инструмент и использовать его.
2. Передавайте данные, с которыми можно работать дальше
Ответа «клиент найден» недостаточно, если следующий шаг должен получить его заказы. Нужен идентификатор клиента. А для работы с конкретным заказом — идентификатор заказа и необходимые сведения о нём.
Важно сохранять связь между объектами. Если одна ветка получила заказы, а другая — контакты клиентов, объединять результаты просто по позиции в списке опасно: порядок мог измениться. Связывать такие записи нужно по идентификаторам.
3. Определите, что обрабатывает каждый шаг
Нам нужно работать с одним объектом, с каждым объектом отдельно или со всем списком объектов целиком?
Например, воркфлоу нашёл пять документов. Если шаг отправки сообщения выполняется для каждого документа, клиент получит пять сообщений вместо одного.
4. Проверяйте результат, а не только успешность выполнения
Все шаги могут завершиться без ошибок, но данные попадут не в те поля или часть записей потеряется. Важно проверять, что действительно изменилось в системе, сколько объектов обработано и что осталось.
То же самое с ответами инструментов. Разные ошибки требуют разных следующих действий.
Если несколько веток собирают данные, заранее определите, что делать, когда одна из них не вернула результат. Можно ли продолжать без него или нужно остановиться?
5. Учитывайте, что данные меняются во время выполнения
Позднее полученное событие может содержать более старое состояние заказа. Если просто применить его, актуальные данные будут перезаписаны устаревшими.
При обновлении нужно проверять, какое состояние действительно новее. Похожая ситуация может возникнуть при согласовании. Человек одобрил возврат, но до выполнения изменился статус заказа.
Поэтому перед выполнением действия нужно повторно проверить все условия.
6. Сохраняйте структуру и контекст при преобразовании данных
Допустим, воркфлоу получает прайс в PDF и извлекает из него текст. Все названия и числа сохранились, но структура таблицы потерялась. Теперь непонятно, какая цена относится к какой услуге и за какую единицу она указана.
На следующем шаге агент может использовать эти данные неправильно.
Поэтому при преобразовании важно сохранять заголовки, связи между полями и единицы измерения. После каждого такого шага данные должны оставаться понятными для дальнейшей работы.
Бизнес-процесс — это поток данных, а в хорошем ИИ-воркфлоу на каждом переходе понятно, какие данные пришли, как они изменились и что следующий шаг может с ними сделать.
👉 Полная статья
В одной компании я создавал агента-оркестратора, который использовал другие воркфлоу в качестве инструментов.
В такой архитектуре агент выбирает, какой процесс выполнить, а выбранный воркфлоу запускает заранее определённую последовательность действий и возвращает результат.
Допустим, клиент просит оформить возврат. Один воркфлоу находит его заказы, другой проверяет условия возврата, третий создаёт заявку.
По пути текст обращения превращается в структурированные данные, из списка заказов выбирается нужный, а результат проверки определяет, можно ли двигаться дальше.
Для меня основная работа здесь — инженерия данных. Нужно организовать их движение: получить из нужного источника, преобразовать, связать между собой и передать следующему шагу, сохранив смысл.
Я бы выделил шесть пунктов, которые стоит продумать:
1. Разделяйте процесс на подпроцессы
Инструмент агента необязательно должен выполнять один запрос к API. Если для проверки возврата нужно получить заказ, посмотреть его статус и проверить сроки, эту последовательность можно собрать в отдельный воркфлоу.
С такими подпроцессами удобнее работать: их можно отдельно проверять, дорабатывать и использовать в разных задачах.
Компания в этом смысле похожа на конструктор LEGO. Из одних и тех же операций и подпроцессов можно собирать разные бизнес-процессы. Но у каждого такого «кубика» должны быть понятные входные данные и результат. Тогда оркестратор сможет выбрать нужный инструмент и использовать его.
2. Передавайте данные, с которыми можно работать дальше
Ответа «клиент найден» недостаточно, если следующий шаг должен получить его заказы. Нужен идентификатор клиента. А для работы с конкретным заказом — идентификатор заказа и необходимые сведения о нём.
Важно сохранять связь между объектами. Если одна ветка получила заказы, а другая — контакты клиентов, объединять результаты просто по позиции в списке опасно: порядок мог измениться. Связывать такие записи нужно по идентификаторам.
3. Определите, что обрабатывает каждый шаг
Нам нужно работать с одним объектом, с каждым объектом отдельно или со всем списком объектов целиком?
Например, воркфлоу нашёл пять документов. Если шаг отправки сообщения выполняется для каждого документа, клиент получит пять сообщений вместо одного.
4. Проверяйте результат, а не только успешность выполнения
Все шаги могут завершиться без ошибок, но данные попадут не в те поля или часть записей потеряется. Важно проверять, что действительно изменилось в системе, сколько объектов обработано и что осталось.
То же самое с ответами инструментов. Разные ошибки требуют разных следующих действий.
Если несколько веток собирают данные, заранее определите, что делать, когда одна из них не вернула результат. Можно ли продолжать без него или нужно остановиться?
5. Учитывайте, что данные меняются во время выполнения
Позднее полученное событие может содержать более старое состояние заказа. Если просто применить его, актуальные данные будут перезаписаны устаревшими.
При обновлении нужно проверять, какое состояние действительно новее. Похожая ситуация может возникнуть при согласовании. Человек одобрил возврат, но до выполнения изменился статус заказа.
Поэтому перед выполнением действия нужно повторно проверить все условия.
6. Сохраняйте структуру и контекст при преобразовании данных
Допустим, воркфлоу получает прайс в PDF и извлекает из него текст. Все названия и числа сохранились, но структура таблицы потерялась. Теперь непонятно, какая цена относится к какой услуге и за какую единицу она указана.
На следующем шаге агент может использовать эти данные неправильно.
Поэтому при преобразовании важно сохранять заголовки, связи между полями и единицы измерения. После каждого такого шага данные должны оставаться понятными для дальнейшей работы.
Бизнес-процесс — это поток данных, а в хорошем ИИ-воркфлоу на каждом переходе понятно, какие данные пришли, как они изменились и что следующий шаг может с ними сделать.
👉 Полная статья
Датаист / Обучение
Как данные движутся по ИИ-воркфлоу
Надёжная автоматизация начинается с понимания того, какие данные получает каждый шаг и что передаёт дальше. Разберём, как шаги связаны маппингом, зачем преобразовывать данные и как ветвление, разветвление и объединение задают маршруты. Затем посмотрим, как…
Почему идеальный промт не спасает плохого агента
Недавно я создавал агента-оркестратора, который использовал другие воркфлоу в качестве инструментов. Агент выбирал, какой процесс запустить, а выбранный воркфлоу выполнял последовательность действий и возвращал результат.
В такой архитектуре неправильный ответ может возникнуть по разным причинам. Агенту не хватило данных, описание инструмента оказалось неоднозначным, проверка пропустила ошибку или результат предыдущего шага потерялся.
Поэтому, когда агент ошибается, я сначала разбираюсь, где именно возникла проблема. Уже после этого решаю, нужно ли менять промт.
Вот несколько важных нюансов:
1. Определите, что считать правильным выполнением задачи
«Помоги клиенту оформить возврат» — понятная цель, но для работы агента её недостаточно. Какие данные нужно получить, когда возврат допустим и что агент может сделать самостоятельно? Важно проверить, не противоречат ли инструкции друг другу.
У таких требований должен быть понятный приоритет. А если конфликт нельзя разрешить по заданным правилам, агент должен сообщить о нём и запросить уточнение.
2. Проверяйте, что модель действительно получила
В редакторе мы видим шаблон промта. Во время запуска к нему добавляются переменные, история разговора, документы и ответы инструментов.
Поэтому при отладке я смотрю на контекст конкретного запуска.
Например, агент может снова предлагать вариант, который пользователь уже отверг. В истории сохранилось обсуждение, но при её сокращении потерялись отказ и его причина.
3. Убирайте неоднозначность из инструментов
Допустим, поиск клиента вернул три записи. Если в результате нет признаков, по которым их можно различить, агенту приходится угадывать.
Здесь полезнее доработать инструмент. Описание инструмента тоже должно объяснять, какие параметры он принимает, когда его можно использовать и что означает результат.
При этом права доступа, допустимость операций и обязательные ограничения должна проверять программа. Инструкция в промте сама по себе этого не обеспечивает.
4. Превращайте ошибки в тесты
После каждого сбоя легко дописать ещё одно «никогда не делай так». Постепенно промт превращается в длинный список исключений.
Я сначала сохраняю проблемный случай как тест и выясняю причину. Если нужна новая инструкция, формулирую правило, которое поможет и в похожих ситуациях.
В тестах полезны не только примеры правильного действия. Нужны и случаи, когда действовать не следует.
Например, «оформите возврат» и «можно ли оформить возврат?» — разные запросы. Второй требует проверки условий, а не автоматического создания заявки. Такие примеры помогают обозначить границы поведения агента.
5. Проверяйте результат по нескольким критериям
Правильный JSON может содержать неправильное решение. Ответ с достоверными фактами и ссылкой на источник может заканчиваться ошибочным выводом.
Поэтому я отдельно проверяю формат, соответствие исходным данным и итоговый результат.
Если агент должен создать заявку, важно убедиться, что она действительно появилась в системе и содержит нужные данные. Успешный вызов инструмента ещё не подтверждает выполнение всей задачи.
Если ответ оценивает другая модель, её оценки тоже нужно сверять с примерами, где правильный результат заранее известен.
6. Оценивайте, как правка влияет на весь процесс
После изменения промта я смотрю на качество результата, число шагов, время, стоимость и частоту передачи человеку.
Правка может улучшить ответ, но заставить агента делать лишние вызовы инструментов. А более подробный ответ — перестать помещаться в установленный лимит.
Поэтому важные сценарии стоит запускать несколько раз в сопоставимых условиях. А выбранную версию проверять на новых примерах, которые не использовались при настройке промта.
Этот цикл можно автоматизировать: собирать ошибки, предлагать изменения и сравнивать версии по заданным критериям. Главное — заранее определить, какие показатели нужно улучшить и что при этом должно продолжать работать.
Для меня работа над промтом — часть инженерной работы над агентом.
Нужно понимать, какие данные он получает, какие решения принимает, как использует инструменты и по каким признакам мы считаем задачу выполненной.
Тогда становится понятно, что именно нужно изменить в агенте и помогла ли эта правка.
👉 Полная статья
Недавно я создавал агента-оркестратора, который использовал другие воркфлоу в качестве инструментов. Агент выбирал, какой процесс запустить, а выбранный воркфлоу выполнял последовательность действий и возвращал результат.
В такой архитектуре неправильный ответ может возникнуть по разным причинам. Агенту не хватило данных, описание инструмента оказалось неоднозначным, проверка пропустила ошибку или результат предыдущего шага потерялся.
Поэтому, когда агент ошибается, я сначала разбираюсь, где именно возникла проблема. Уже после этого решаю, нужно ли менять промт.
Вот несколько важных нюансов:
1. Определите, что считать правильным выполнением задачи
«Помоги клиенту оформить возврат» — понятная цель, но для работы агента её недостаточно. Какие данные нужно получить, когда возврат допустим и что агент может сделать самостоятельно? Важно проверить, не противоречат ли инструкции друг другу.
У таких требований должен быть понятный приоритет. А если конфликт нельзя разрешить по заданным правилам, агент должен сообщить о нём и запросить уточнение.
2. Проверяйте, что модель действительно получила
В редакторе мы видим шаблон промта. Во время запуска к нему добавляются переменные, история разговора, документы и ответы инструментов.
Поэтому при отладке я смотрю на контекст конкретного запуска.
Например, агент может снова предлагать вариант, который пользователь уже отверг. В истории сохранилось обсуждение, но при её сокращении потерялись отказ и его причина.
3. Убирайте неоднозначность из инструментов
Допустим, поиск клиента вернул три записи. Если в результате нет признаков, по которым их можно различить, агенту приходится угадывать.
Здесь полезнее доработать инструмент. Описание инструмента тоже должно объяснять, какие параметры он принимает, когда его можно использовать и что означает результат.
При этом права доступа, допустимость операций и обязательные ограничения должна проверять программа. Инструкция в промте сама по себе этого не обеспечивает.
4. Превращайте ошибки в тесты
После каждого сбоя легко дописать ещё одно «никогда не делай так». Постепенно промт превращается в длинный список исключений.
Я сначала сохраняю проблемный случай как тест и выясняю причину. Если нужна новая инструкция, формулирую правило, которое поможет и в похожих ситуациях.
В тестах полезны не только примеры правильного действия. Нужны и случаи, когда действовать не следует.
Например, «оформите возврат» и «можно ли оформить возврат?» — разные запросы. Второй требует проверки условий, а не автоматического создания заявки. Такие примеры помогают обозначить границы поведения агента.
5. Проверяйте результат по нескольким критериям
Правильный JSON может содержать неправильное решение. Ответ с достоверными фактами и ссылкой на источник может заканчиваться ошибочным выводом.
Поэтому я отдельно проверяю формат, соответствие исходным данным и итоговый результат.
Если агент должен создать заявку, важно убедиться, что она действительно появилась в системе и содержит нужные данные. Успешный вызов инструмента ещё не подтверждает выполнение всей задачи.
Если ответ оценивает другая модель, её оценки тоже нужно сверять с примерами, где правильный результат заранее известен.
6. Оценивайте, как правка влияет на весь процесс
После изменения промта я смотрю на качество результата, число шагов, время, стоимость и частоту передачи человеку.
Правка может улучшить ответ, но заставить агента делать лишние вызовы инструментов. А более подробный ответ — перестать помещаться в установленный лимит.
Поэтому важные сценарии стоит запускать несколько раз в сопоставимых условиях. А выбранную версию проверять на новых примерах, которые не использовались при настройке промта.
Этот цикл можно автоматизировать: собирать ошибки, предлагать изменения и сравнивать версии по заданным критериям. Главное — заранее определить, какие показатели нужно улучшить и что при этом должно продолжать работать.
Для меня работа над промтом — часть инженерной работы над агентом.
Нужно понимать, какие данные он получает, какие решения принимает, как использует инструменты и по каким признакам мы считаем задачу выполненной.
Тогда становится понятно, что именно нужно изменить в агенте и помогла ли эта правка.
👉 Полная статья
Датаист / Обучение
Почему идеальный промт не спасает плохого агента
Хорошо написанный промт не исправит ошибки в архитектуре агента. Разберём, как спецификация превращается в инструкцию для модели, почему структура промта важнее его длины, зачем автоматизации структурированный вывод и как генерировать и выбирать варианты…
Инженерия контекста: как научить ИИ-агента понимать ситуацию
Представим: клиент просит перенести доставку. Агент находит заказ, проверяет условия и предлагает варианты.
Потом клиент уточняет: «Ой, я ошибся, доставить нужно в другой район».
Агент учитывает новый адрес, но продолжает предлагать сроки, рассчитанные для старого.
Уточнение он получил, а картину ситуации обновил лишь частично.
Когда я разрабатываю агента, мне важно продумать, какие данные он получает на каждом шаге, что сохраняет и какие выводы должен пересмотреть после новых сведений.
Это и есть часть инженерии контекста. Я бы выделил десять моментов:
1. Собирайте данные под конкретное решение
Чтобы найти заказ, нужны одни данные. Чтобы проверить возможность переноса — другие. Перед каждым вызовом модели стоит понимать, какой вопрос она сейчас решает и какой информации для этого достаточно.
2. Проверяйте, что актуально сейчас
Вчера заказ собирали, сегодня его могли передать курьеру. Для нового решения нужен текущий статус из системы заказов. А если источники противоречат друг другу, важно понимать, чему доверять: старое обсуждение условий и действующий договор имеют разный вес.
3. После уточнения пересматривайте связанные выводы
Изменился район доставки — могли измениться сроки, стоимость и доступные службы доставки. Я бы отдельно определял, какие результаты зависят от исправленных данных и какие проверки нужно выполнить заново.
4. Храните состояние задачи отдельно от диалога
Какой заказ выбран, что сообщил клиент и какого ответа мы ждём. Эти данные полезно хранить явно. Тогда продолжить задачу можно без восстановления всей ситуации из переписки, даже если работа растянулась на несколько сессий.
5. При сокращении истории сохраняйте причины
«Пятница не подходит» — тут мало информации. «В пятницу клиент уезжает, заказ нужен до четверга» помогает оценивать новые варианты. Если потерять причину отказа, агент может снова предложить то, что уже обсуждали и отвергли.
6. Определяйте, что стоит запоминать надолго
«Этот заказ привезите в офис» ещё не означает, что туда нужно отправлять все следующие заказы. У записи в памяти должны быть понятные границы: к чему она относится, когда полезна и при каких изменениях её нужно обновить.
7. Давайте возможность получить подробности
Основные данные можно подготовить заранее, а детали получать через инструменты. Полный регламент не обязательно нужен на каждом шаге. Но после сокращения контекста должна оставаться возможность открыть исходный документ и проверить нужный раздел.
8. Передавайте данные вместе с их смыслом
«Перенос возможен за 24 часа» — до какого события и для какой услуги, или по каким критериям определяется «Постоянный клиент»? Условия, исключения, единицы измерения и внутренние определения компании тоже входят в контекст. Без них даже верные данные можно понять неправильно.
9. Обозначайте границы поиска
Если инструмент проверил только последние десять заказов, агент должен об этом знать. Отсутствие результата в этой выборке ещё не означает, что заказа нет. Также важно различать отсутствие данных и недоступность источника.
10. Смотрите, что действительно дошло до модели
Нужный документ может быть в базе, но потеряться при поиске или сокращении истории. При отладке я бы проверял весь этот путь. А в тесты добавлял уточнения клиента, противоречащие документы и случаи, когда для решения не хватает данных.
Инженерия контекста — во многом инженерия данных. Нужно собрать сведения из разных источников, сохранить связи между ними и вовремя обновить картину ситуации.
Тогда агенту будет понятно, на основе чего принимать решения.
👉 Полная статья
Представим: клиент просит перенести доставку. Агент находит заказ, проверяет условия и предлагает варианты.
Потом клиент уточняет: «Ой, я ошибся, доставить нужно в другой район».
Агент учитывает новый адрес, но продолжает предлагать сроки, рассчитанные для старого.
Уточнение он получил, а картину ситуации обновил лишь частично.
Когда я разрабатываю агента, мне важно продумать, какие данные он получает на каждом шаге, что сохраняет и какие выводы должен пересмотреть после новых сведений.
Это и есть часть инженерии контекста. Я бы выделил десять моментов:
1. Собирайте данные под конкретное решение
Чтобы найти заказ, нужны одни данные. Чтобы проверить возможность переноса — другие. Перед каждым вызовом модели стоит понимать, какой вопрос она сейчас решает и какой информации для этого достаточно.
2. Проверяйте, что актуально сейчас
Вчера заказ собирали, сегодня его могли передать курьеру. Для нового решения нужен текущий статус из системы заказов. А если источники противоречат друг другу, важно понимать, чему доверять: старое обсуждение условий и действующий договор имеют разный вес.
3. После уточнения пересматривайте связанные выводы
Изменился район доставки — могли измениться сроки, стоимость и доступные службы доставки. Я бы отдельно определял, какие результаты зависят от исправленных данных и какие проверки нужно выполнить заново.
4. Храните состояние задачи отдельно от диалога
Какой заказ выбран, что сообщил клиент и какого ответа мы ждём. Эти данные полезно хранить явно. Тогда продолжить задачу можно без восстановления всей ситуации из переписки, даже если работа растянулась на несколько сессий.
5. При сокращении истории сохраняйте причины
«Пятница не подходит» — тут мало информации. «В пятницу клиент уезжает, заказ нужен до четверга» помогает оценивать новые варианты. Если потерять причину отказа, агент может снова предложить то, что уже обсуждали и отвергли.
6. Определяйте, что стоит запоминать надолго
«Этот заказ привезите в офис» ещё не означает, что туда нужно отправлять все следующие заказы. У записи в памяти должны быть понятные границы: к чему она относится, когда полезна и при каких изменениях её нужно обновить.
7. Давайте возможность получить подробности
Основные данные можно подготовить заранее, а детали получать через инструменты. Полный регламент не обязательно нужен на каждом шаге. Но после сокращения контекста должна оставаться возможность открыть исходный документ и проверить нужный раздел.
8. Передавайте данные вместе с их смыслом
«Перенос возможен за 24 часа» — до какого события и для какой услуги, или по каким критериям определяется «Постоянный клиент»? Условия, исключения, единицы измерения и внутренние определения компании тоже входят в контекст. Без них даже верные данные можно понять неправильно.
9. Обозначайте границы поиска
Если инструмент проверил только последние десять заказов, агент должен об этом знать. Отсутствие результата в этой выборке ещё не означает, что заказа нет. Также важно различать отсутствие данных и недоступность источника.
10. Смотрите, что действительно дошло до модели
Нужный документ может быть в базе, но потеряться при поиске или сокращении истории. При отладке я бы проверял весь этот путь. А в тесты добавлял уточнения клиента, противоречащие документы и случаи, когда для решения не хватает данных.
Инженерия контекста — во многом инженерия данных. Нужно собрать сведения из разных источников, сохранить связи между ними и вовремя обновить картину ситуации.
Тогда агенту будет понятно, на основе чего принимать решения.
👉 Полная статья
Датаист / Обучение
Инженерия контекста: как научить ИИ-агента понимать ситуацию
Разберём, как собирать контекст под конкретную задачу и почему хороший промт не компенсирует устаревшие, неполные или неверные данные. Рассмотрим, чем состояние процесса отличается от долговременной памяти, зачем агенту уметь забывать и как выбирать данные…
Инженерия обвязки: что делает ИИ-агента управляемым и надёжным
Агент может правильно понять задачу и всё равно выполнить её дважды.
Допустим, агент помогает сотруднику оформить командировку. Он выбирает отель, получает согласование и отправляет запрос на бронирование.
Сервис создаёт бронь, но ответ до агента не доходит. Тот повторяет запрос. Теперь у сотрудника две брони.
Модель правильно поняла задачу. Проблема возникла в том, как система выполнила действие и обработала сбой.
Когда я разрабатываю агента, мне важно продумать и эту часть. За неё отвечает обвязка — код вокруг модели, который управляет выполнением задачи, проверяет действия и сохраняет ход работы.
Вот восемь советов:
1. Закрепляйте ограничения в коде
Возможность вызвать инструмент бронирования ещё не означает право оплатить любой номер.
Код должен проверять, кто может оформлять поездки, какой действует бюджет и когда требуется согласование.
Промт помогает объяснить правила модели, но само соблюдение обязательных ограничений нужно обеспечивать кодом.
2. Не считайте потерянный ответ неудавшимся действием
После тайм-аута важно выяснить, появилась ли бронь.
Если сервис поддерживает защиту от дублей, повторные попытки одной операции должны передавать тот же идентификатор. По нему сервис распознает повтор.
Если результат установить нельзя, нужно предусмотреть остановку или передачу человеку. Иначе каждая новая попытка может создавать новую проблему.
3. Сохраняйте прогресс отдельно от переписки
Что выбрано, что согласовано, какие запросы отправлены и какие результаты получены — эти данные должны переживать перезапуск.
Важно учитывать и частичный успех. Если отель забронирован, а уведомление сотруднику не отправлено, продолжить нужно с уведомления. Повторять бронирование уже не требуется.
4. Ограничивайте повторы на всех уровнях
Три попытки у агента, три у воркфлоу и три внутри инструмента могут превратиться в 27 обращений к сервису.
Поэтому нужно заранее определить, кто управляет повторами и какие ошибки имеет смысл повторять. Недоступность сервиса можно переждать, неверные даты нужно уточнить.
Лимиты по времени, вызовам и расходам должны учитывать всю задачу, включая работу дочерних агентов.
5. Проверяйте, что согласование ещё актуально
Руководитель одобрил поездку с понедельника по среду. Пока агент оформлял бронь, сотрудник перенёс командировку на неделю.
Прежнее согласие не должно разрешать бронирование на новые даты. Подтверждение нужно связывать с конкретными условиями: отелем, датами и стоимостью.
Перед действием система должна проверить, что выполняет именно согласованный вариант.
6. Заранее определите, откуда продолжать работу
Агент отправил руководителю запрос на согласование и перешёл в ожидание. Затем произошел перезапуск.
Если весь этап начнётся заново, руководитель может получить второй запрос. Поэтому отправку и ожидание стоит разделять, а результат отправки — сохранять.
После перезапуска система должна понимать, что запрос уже отправлен и сейчас нужно дождаться ответа. Если результат отправки неизвестен, сначала нужно выяснить, был ли запрос доставлен.
7. Различайте остановку и отмену сделанного
Сотрудник написал: «Командировка отменяется». Оркестратор должен остановить дальнейшие действия, включая работу запущенных им процессов.
Но уже отправленный запрос на бронирование сам по себе не исчезнет. Нужно выяснить его результат, а затем при необходимости запустить отмену.
8. Проверяйте восстановление намеренными сбоями
Я бы отдельно проверял, что произойдёт, если остановить программу сразу после создания брони, но до сохранения ответа.
После перезапуска важно понять: восстановился ли прогресс, появились ли дубли и знает ли система, что делать дальше.
Для разбора нужна история выполнения, которая связывает согласование, параметры запроса и фактический результат операции.
Когда агент использует другие воркфлоу как инструменты, важно видеть ход выполнения всей задачи.
Хорошая обвязка позволяет даже после сбоя понять, что уже сделано, какие процессы ещё выполняются и где требуется решение человека.
👉 Полная статья
Агент может правильно понять задачу и всё равно выполнить её дважды.
Допустим, агент помогает сотруднику оформить командировку. Он выбирает отель, получает согласование и отправляет запрос на бронирование.
Сервис создаёт бронь, но ответ до агента не доходит. Тот повторяет запрос. Теперь у сотрудника две брони.
Модель правильно поняла задачу. Проблема возникла в том, как система выполнила действие и обработала сбой.
Когда я разрабатываю агента, мне важно продумать и эту часть. За неё отвечает обвязка — код вокруг модели, который управляет выполнением задачи, проверяет действия и сохраняет ход работы.
Вот восемь советов:
1. Закрепляйте ограничения в коде
Возможность вызвать инструмент бронирования ещё не означает право оплатить любой номер.
Код должен проверять, кто может оформлять поездки, какой действует бюджет и когда требуется согласование.
Промт помогает объяснить правила модели, но само соблюдение обязательных ограничений нужно обеспечивать кодом.
2. Не считайте потерянный ответ неудавшимся действием
После тайм-аута важно выяснить, появилась ли бронь.
Если сервис поддерживает защиту от дублей, повторные попытки одной операции должны передавать тот же идентификатор. По нему сервис распознает повтор.
Если результат установить нельзя, нужно предусмотреть остановку или передачу человеку. Иначе каждая новая попытка может создавать новую проблему.
3. Сохраняйте прогресс отдельно от переписки
Что выбрано, что согласовано, какие запросы отправлены и какие результаты получены — эти данные должны переживать перезапуск.
Важно учитывать и частичный успех. Если отель забронирован, а уведомление сотруднику не отправлено, продолжить нужно с уведомления. Повторять бронирование уже не требуется.
4. Ограничивайте повторы на всех уровнях
Три попытки у агента, три у воркфлоу и три внутри инструмента могут превратиться в 27 обращений к сервису.
Поэтому нужно заранее определить, кто управляет повторами и какие ошибки имеет смысл повторять. Недоступность сервиса можно переждать, неверные даты нужно уточнить.
Лимиты по времени, вызовам и расходам должны учитывать всю задачу, включая работу дочерних агентов.
5. Проверяйте, что согласование ещё актуально
Руководитель одобрил поездку с понедельника по среду. Пока агент оформлял бронь, сотрудник перенёс командировку на неделю.
Прежнее согласие не должно разрешать бронирование на новые даты. Подтверждение нужно связывать с конкретными условиями: отелем, датами и стоимостью.
Перед действием система должна проверить, что выполняет именно согласованный вариант.
6. Заранее определите, откуда продолжать работу
Агент отправил руководителю запрос на согласование и перешёл в ожидание. Затем произошел перезапуск.
Если весь этап начнётся заново, руководитель может получить второй запрос. Поэтому отправку и ожидание стоит разделять, а результат отправки — сохранять.
После перезапуска система должна понимать, что запрос уже отправлен и сейчас нужно дождаться ответа. Если результат отправки неизвестен, сначала нужно выяснить, был ли запрос доставлен.
7. Различайте остановку и отмену сделанного
Сотрудник написал: «Командировка отменяется». Оркестратор должен остановить дальнейшие действия, включая работу запущенных им процессов.
Но уже отправленный запрос на бронирование сам по себе не исчезнет. Нужно выяснить его результат, а затем при необходимости запустить отмену.
8. Проверяйте восстановление намеренными сбоями
Я бы отдельно проверял, что произойдёт, если остановить программу сразу после создания брони, но до сохранения ответа.
После перезапуска важно понять: восстановился ли прогресс, появились ли дубли и знает ли система, что делать дальше.
Для разбора нужна история выполнения, которая связывает согласование, параметры запроса и фактический результат операции.
Когда агент использует другие воркфлоу как инструменты, важно видеть ход выполнения всей задачи.
Хорошая обвязка позволяет даже после сбоя понять, что уже сделано, какие процессы ещё выполняются и где требуется решение человека.
👉 Полная статья
Датаист / Обучение
Инженерия обвязки: что делает ИИ-агента управляемым и надёжным
Модель отвечает за интеллектуальную часть ИИ-агента. Обвязка управляет его работой: передаёт контекст, подключает инструменты, проверяет действия и сохраняет состояние. Разберём, чем она отличается от ИИ-платформы, как ограничить права агента и продолжить…
Как понять, что ИИ-агент действительно стал лучше
Допустим, клиент попросил изменить адрес доставки. Агент сохранил новый адрес, тест пройден.
Но вместе с адресом он поменял способ оплаты, а проверка этого не заметила.
Когда я дорабатываю агента, мне важно понимать, что именно улучшилось после изменения промта, модели или инструментов и чем это подтверждается.
Вот несколько кейсов, которые стоит учитывать при оценке:
1. Проверяйте саму проверку
Агент может получить плохую оценку из-за ошибки в самом тесте.
Например, он нашёл нужные данные другим способом, а проверка ожидала строго определённую последовательность вызовов. Если обязательные условия соблюдены и результат верный, такой путь тоже может быть допустим.
Поэтому сначала нужно понять, за что именно тест отклонил решение. А если результат оценивает другая модель, её оценки тоже стоит сверять с оценками эксперта.
2. Повторяйте важные сценарии
Один удачный запуск ещё мало говорит о стабильности.
Я бы запускал важные сценарии несколько раз в сопоставимых условиях. Перед каждой попыткой нужно восстанавливать исходное состояние: иначе агент может воспользоваться данными, которые остались от предыдущего запуска.
Важно учитывать все попытки, включая неудачные. Если выбирать только лучший ответ, можно не заметить, насколько часто система ошибается.
3. Проверяйте побочные изменения
Для действий, которые меняют данные, полезно заранее определить, что должно измениться и что должно остаться прежним.
Проверка должна замечать и лишние действия. Поэтому подтверждения, что нужное изменение выполнено, недостаточно. Стоит сравнить состояние системы до и после выполнения задачи.
4. Смотрите, решилась ли проблема клиента
Клиент перестал отвечать агенту. Возможно, вопрос решён. Но человек мог устать объяснять и уйти.
Завершение диалога само по себе ещё не подтверждает успех.
Для оценки полезно смотреть на подтверждение клиента, фактический результат в системе и повторные обращения по той же проблеме. Иначе можно улучшать показатель закрытых диалогов, пока сотрудники продолжают разбирать те же вопросы.
5. Считайте эффект на всём потоке задач
Допустим, агент получает только 10% обращений компании и самостоятельно решает 90% из них.
Получается, он закрывает 9% всего потока.
Поэтому рядом с процентом успешности важно видеть, какие задачи вообще передаются агенту и какая работа остаётся людям.
Я бы также учитывал время и стоимость завершённой задачи — вместе с неудачными попытками, повторами и ручными исправлениями.
6. Сравнивайте с более простой архитектурой
После очередной ошибки легко добавить ещё один промт, инструмент или проверяющего агента.
Но полезно провести и обратный эксперимент: упростить набор инструментов или убрать промежуточный этап, сохранив обязательные ограничения.
Такие изменения стоит проверять по очереди на том же наборе задач. Тогда понятнее, какую пользу даёт каждый компонент.
Если упрощённая версия сохраняет качество, делает меньше вызовов и быстрее завершает работу, это тоже улучшение.
Помните, что оценка агента должна помогать принять конкретное решение: какую версию оставить, что исправить и оправдывает ли полученный результат затраты на его достижение.
👉 Полная статья
Допустим, клиент попросил изменить адрес доставки. Агент сохранил новый адрес, тест пройден.
Но вместе с адресом он поменял способ оплаты, а проверка этого не заметила.
Когда я дорабатываю агента, мне важно понимать, что именно улучшилось после изменения промта, модели или инструментов и чем это подтверждается.
Вот несколько кейсов, которые стоит учитывать при оценке:
1. Проверяйте саму проверку
Агент может получить плохую оценку из-за ошибки в самом тесте.
Например, он нашёл нужные данные другим способом, а проверка ожидала строго определённую последовательность вызовов. Если обязательные условия соблюдены и результат верный, такой путь тоже может быть допустим.
Поэтому сначала нужно понять, за что именно тест отклонил решение. А если результат оценивает другая модель, её оценки тоже стоит сверять с оценками эксперта.
2. Повторяйте важные сценарии
Один удачный запуск ещё мало говорит о стабильности.
Я бы запускал важные сценарии несколько раз в сопоставимых условиях. Перед каждой попыткой нужно восстанавливать исходное состояние: иначе агент может воспользоваться данными, которые остались от предыдущего запуска.
Важно учитывать все попытки, включая неудачные. Если выбирать только лучший ответ, можно не заметить, насколько часто система ошибается.
3. Проверяйте побочные изменения
Для действий, которые меняют данные, полезно заранее определить, что должно измениться и что должно остаться прежним.
Проверка должна замечать и лишние действия. Поэтому подтверждения, что нужное изменение выполнено, недостаточно. Стоит сравнить состояние системы до и после выполнения задачи.
4. Смотрите, решилась ли проблема клиента
Клиент перестал отвечать агенту. Возможно, вопрос решён. Но человек мог устать объяснять и уйти.
Завершение диалога само по себе ещё не подтверждает успех.
Для оценки полезно смотреть на подтверждение клиента, фактический результат в системе и повторные обращения по той же проблеме. Иначе можно улучшать показатель закрытых диалогов, пока сотрудники продолжают разбирать те же вопросы.
5. Считайте эффект на всём потоке задач
Допустим, агент получает только 10% обращений компании и самостоятельно решает 90% из них.
Получается, он закрывает 9% всего потока.
Поэтому рядом с процентом успешности важно видеть, какие задачи вообще передаются агенту и какая работа остаётся людям.
Я бы также учитывал время и стоимость завершённой задачи — вместе с неудачными попытками, повторами и ручными исправлениями.
6. Сравнивайте с более простой архитектурой
После очередной ошибки легко добавить ещё один промт, инструмент или проверяющего агента.
Но полезно провести и обратный эксперимент: упростить набор инструментов или убрать промежуточный этап, сохранив обязательные ограничения.
Такие изменения стоит проверять по очереди на том же наборе задач. Тогда понятнее, какую пользу даёт каждый компонент.
Если упрощённая версия сохраняет качество, делает меньше вызовов и быстрее завершает работу, это тоже улучшение.
Помните, что оценка агента должна помогать принять конкретное решение: какую версию оставить, что исправить и оправдывает ли полученный результат затраты на его достижение.
👉 Полная статья
Датаист / Обучение
Как понять, что ИИ-агент действительно стал лучше
Разберём, как задать агенту условие завершения и технические лимиты, почему нескольких удачных примеров недостаточно для оценки надёжности и зачем проверять весь путь выполнения. Рассмотрим, по каким метрикам сравнивать версии агента, как находить регрессии…