Гульнара Абдрахманова

Хорошее объяснение про «сужение пространства вероятностей». Добавлю из практики: в рабочих задачах одного точного промта всё равно мало. Модель даже на идеальный запрос иногда уверенно додумывает то, чего не было во входных данных. Мне помогло другое: заставить модель отвечать в строгом формате (JSON по схеме) и проверять ответ обычным кодом. Не прошёл проверку — модель получает список ошибок и переделывает. Промт задаёт направление, а проверки не дают уехать в сторону.

Очень понравился совет начинать с одного подпроцесса, а не с «полной архитектуры за полгода». Добавлю, что на этом первом шаге часто и застревают. У компании уже есть «сто разрозненных регламентов», и перевод каждого из них в BPMN вручную съедает силы аналитика ещё до того, как он доберётся до ArchiMate и связей.
Зато этот перевод — лучший способ найти то, о чём вы пишете: противоречия и дыры. Когда регламент превращаешь в схему, сразу видно ветку «если документы в порядке», у которой нет пары, или «передать дальше» без получателя. Я поэтому сделала инструмент, который строит черновую BPMN-схему прямо из текста регламента и подсвечивает такие места.
Константин, а вы на старте опираетесь на регламенты или сразу на интервью с исполнителями? По опыту, регламент и реальный процесс часто расходятся сильнее, чем хотелось бы.

Раздел про «рамку для агента» — самое ценное в статье, подписываюсь под каждым словом. Я пришла к тому же, только в BPMN. Делаю сервис, который строит схемы процессов по регламентам. Первая мысль была очевидная: пусть модель сразу пишет BPMN XML. Результат — уверенные схемы со связями, которых нет в тексте, и XML, который не открывается.
Сработало ровно как у вас: модель не пишет BPMN вообще, а заполняет узкую промежуточную модель процесса, где у каждой связи обязан быть номер предложения-источника. Остальное — проверки кода. Нет номера — нет стрелки, и «галлюцинация» превращается из незаметной логической ошибки в явный пропуск, о котором сервис спрашивает пользователя.
Интересно, что у вас тот же эффект с контроллерами: раздувание кода как сигнал, что не хватает выразительности языка. У меня так же: если модель начинает «объяснять» в полях что-то лишнее, значит, в схеме модели не хватает поля. Вы свой DSL сценариев потом переиспользовали на других проектах?

Точно подмечено про системы-конструкторы, где «логику бизнес-процессов прописываете с нуля». По опыту, это самая недооценённая часть перехода с Excel. Таблица прячет не только дубли «Ноутбук-Иванов» и «NB_Ivanov_15», но и процессы, которые живут в головах: кто согласует новый ноутбук, что делать, если бюджета нет, кому передаётся заявка после склада.
Когда такой процесс начинаешь описывать в BPMN перед внедрением, выясняется, что половина веток нигде не записана. А как в ваших проектах: процессы вокруг активов описывают до внедрения ITAM или настраивают по ходу, «как в Excel было»?

Хорошая мысль про то, что нейросеть отвечает на вопрос «как выбрать подрядчика», а не «купить X». Для маленького продукта это даже шанс: крупные игроки пишут про себя каталогом, а разбор конкретной проблемы с примерами нейросеть процитирует охотнее.
Я как раз по этой логике написала первую статью про свой сервис: не «что он умеет», а разбор одной проблемы на примере. Интересно, через сколько такой контент реально начинает появляться в ответах ИИ — есть у вас наблюдения по срокам?

Полностью согласна, особенно про «спросить у Олега». Добавлю нюанс, который вижу постоянно: регламент сам по себе Олега не отменяет. Часто он написан, согласован и лежит в базе знаний, а «Олег» прячется внутри текста. «Если документы в порядке — передать на согласование», а если не в порядке? «Заявка передаётся дальше» — кому дальше? Новый сотрудник по такому регламенту дойдёт до первой развилки и пойдёт к тому же Олегу.
Поэтому я сначала перевожу регламент в BPMN-схему и только потом считаю его готовым: на схеме такие места видны сразу, ветка просто обрывается. А как вы в RL Expert проверяете, что регламент полный, перед тем как отдать его отделу?

У меня «Конвейер»: я QA Senior в банке. Узнала всё, особенно «ТЗ, которое никто не читает, но все подписывают».
Добавлю наблюдение с нашей стороны баррикад. В «Конвейере» BPMN часто рисуют один раз, при согласовании, а регламент потом живёт своей жизнью. В итоге до тестирования доходят процессы, где описано, что делать, если документы корректны, и ни слова о том, что делать, если нет. И эти дыры всплывают уже в баг-репортах, когда исправлять дорого.
Я из-за этого даже сделала себе инструмент, который строит схему прямо по тексту регламента и подсвечивает такие места. А как у вас: BPMN в «Конвейере» обновляют вслед за регламентами или он так и остаётся картинкой «для согласования»?

Про гейты вкуса — очень узнаваемо. Добавлю взгляд со стороны QA: часть гейтов можно вообще не тратить на человека и на модель. Если результат агента проверяется детерминированно, пусть это делает обычный код.
Я делаю сервис, который строит BPMN-схемы из регламентов, и пришла ровно к этому. Модель разбирает текст, но каждую связь в схеме код сверяет с конкретным предложением-источником, а вопросы, которые модель хочет задать пользователю, код сначала проверяет: нет ли ответа в самом тексте. Ложных вопросов стало в разы меньше, а лимит на это не тратится.
Степан, а у вас между субагентами есть такие автоматические проверки, без LLM, или все гейты — через оркестратора и вас?

Очень точная мысль про ошибку «скопировать старую CRM один в один». Добавлю, с чем сталкивалась сама: шаг «определить, какие процессы действительно нужны», на практике упирается в то, что процессов как модели ни у кого нет. Есть регламенты, инструкции и «так исторически сложилось». И когда их начинаешь переводить в BPMN, почти всегда всплывают дыры: описано, что делать, если документы в порядке, и ничего — если нет; «передаётся дальше», а кому — непонятно. В старой системе эти места годами закрывались скриптами и ручными обходами, поэтому их никто не видит.
Сергей, а как у вас на проектах с этим работают — дыры в логике вскрывают на обследовании, ещё до моделирования, или они всплывают уже на настройке процессного движка?