Согласен, кейс описан слишком легко для технической аудитории. Хотел показать типовую управленческую ошибку, когда измеряют активность ИИ вместо бизнес-интеграции. "Математически безупречный" вольность с моей стороны. ИТ оценивал точность на исторических данных, но без сравнения с baseline это действительно поверхностно. Анализ причин расхождений -именно его отсутствие и стало проблемой. Система выдавала рекомендации, но не объясняла логику. Логисты не понимали, почему алгоритм предлагает именно такие объемы.
Про "ненадежного поставщика" вы правы, контрдовод не опровергнут. Это как раз пример того, как локальная экспертиза не была учтена в модели. Согласен: без детального технического разбора такие кейсы теряют доказательную силу. Спасибо за детальный разбор.
Прямо сейчас я в проекте по внедрению LLM+RAG, у меня много описанных бизнес процессов в Дракон. По причинам кондифициальности, не могу публиковать рабочие Дракон схемы...
@itGuevara, большое спасибо за такой развернутый и профессиональный комментарий! Вы подняли абсолютно верные и важные вопросы, которые помогли сделать статью точнее. Я внес несколько уточнений в текст, чтобы эти моменты были более очевидны для читателей.
Про СЭД vs BPM. Вы совершенно правы, Directum — это в первую очередь СЭД. Я упомянул его в одном ряду с BPM-системами лишь как пример дорогостоящего корпоративного ПО, внедрение которого часто является неподъемным.
Про аналитический и исполняемый BPM. Подход LLM + ДРАКОН — это, безусловно, инструмент для аналитического BPM. Его главная задача — быстро, дешево и, что самое важное, понятно для всей команды описать и проанализировать процесс.
Про "цифровых самозванцев". Спасибо, очень крутая статья на эту тему! И полностью разделяю ваш скепсис по поводу маркетингового хайпа вокруг "цифровых двойников". По сути вы правы: то, что мы создаем — это не полноценный DTO, а скорее "интерактивная модель" или "живая карта" процессов. Это доступный для МСБ шаг на пути к созданию настоящего двойника в будущем. Спасибо, что заострили на этом внимание, — это позволило мне сделать формулировки в 9-й главе более точными.
Sap_ru,я думаю вы правы — это фундаментальная проблема.
Аппроксимация vs реальность
Ваша формулировка про "промежуточные значения функции" точно описывает суть проблемы. Модель обучается на дискретных точках данных, а между ними пытается интерполировать. И в этих промежутках может выдать что угодно.
В исследовании это называется IIV-редукцией — связь между тем, насколько хорошо модель может отличить правду от лжи, и тем, как часто она врет при генерации. Формула показывает, что ошибки генерации минимум в 2 раза больше ошибок классификации.
Singleton rate как мера проблемы
То, что вы описываете, исследование измеряет через singleton rate — долю фактов, встреченных только один раз. Чем больше таких "одиночек", тем больше промежутков, где функция не определена надежно.
Практический вывод
OpenAI показали: полностью убрать галлюцинации нельзя, но можно изменить поведение модели в промежуточных областях. Вместо попытки угадать — честно сказать "не знаю".
Это не решает математическую проблему аппроксимации, но делает ее предсказуемой и безопасной. Модель перестает врать и начинает признавать границы своих знаний.
По сути, речь идет не об улучшении функции, а об изменении стратегии ее применения
Повторений действительно много. Это осознанное решение, но понимаю, что может раздражать.
Почему так получилось
Исследование OpenAI — это страницы со сложной математикой. Когда я его читал, сам несколько раз терялся в формулах и доказательствах. Поэтому решил использовать классический принцип технических писателей:
"Скажи что скажешь → скажи → скажи что сказал"
Структура для разных читателей
Введение — для тех, кто хочет понять суть за 2 минуты
Математика — для тех, кто хочет разобраться в механизме
Практика — для тех, кто хочет применить прямо сейчас
Ключевые тезисы (формула 2:1, singleton rate) намеренно повторяются в разных контекстах — так они лучше запоминаются. Как в хорошей презентации.
Но вы правы
Для тех, кто читает всю статью целиком, это выглядит избыточно. Классическая дилемма технического писателя: структура для "сканеров" vs комфорт для "читателей".
В следующих материалах попробую найти баланс — возможно, сделать блоки более независимыми или добавить навигацию "читал уже — переходи сразу к практике".
А какой раздел показался наиболее полезным? Интересно понять, на чем стоит фокусироваться в будущих статьях.
Да, вы попали в суть. ДРАКОН действительно не был создан для формального workflow-моделирования в том смысле, который вы описываете. И книга Паронджанова "Как улучшить работу ума" это подтверждает — он создавался как "суперязык интеллектуального общения" для космических проектов, где главной задачей было заставить сотни институтов понимать друг друга.
Про маркеры и семантику движения — вы правы на 100%. В ДРАКОНе есть четкая концепция "дракон-поезда", но она коммуникационная, а не процессная. Когда я рисовал схему с Output'ами, я решал задачу "как объяснить директору, что происходит", а не "как формально описать движение токена". Это принципиально разные задачи.
И вот тут главный фокус. Возьмите приложенную схему кофе-автомата. Видите эти параллельные ветки с двумя учеными, синхронизацию через "монеткоприёмник", условия ожидания? По этой ДРАКОН-схеме я объясню любому руководителю за 5 минут всю логику работы системы. То, что в BPMN или текстовом регламенте потребует намного больше времени для объяснений.
Вот в чем фокус — в 95% бизнес-случаев эта "неформальность" не баг, а фича. У меня была похожая ситуация при описании: две параллельные ветки процесса (прием заказа + проверка склада), и я действительно описывал их синхронизацию словами в комментариях. Работало прекрасно — потому что главная боль бизнеса не в том, что процесс работает на 87% эффективности вместо 92%. Главная боль — в том, что люди друг друга не понимают и тратят часы на объяснения.
А теперь конструктивная часть. Вы описываете потребности двух совершенно разных миров:
Мир бизнес-коммуникации — где ДРАКОН король. Директор смотрит на схему 5 минут и говорит: "Понятно, делаем". Новый сотрудник за день въезжает в логику работы.
Мир математического моделирования — где нужны Петри-сети, формальные семантики и точные расчеты пропускной способности.
Первый мир составляет 95% всех бизнес-задач. Второй — это специальные ниши: производственные линии, высоконагруженные системы, финансовые алгоритмы.
ДРАКОН — это не универсальная отмычка для математического моделирования. Это революционный инструмент экономии времени на коммуникацию. Когда вместо 40-минутных объяснений достаточно 5 минут — это и есть главная ценность для бизнеса. А точное математическое моделирование — следующий этап, для узких специальных задач.
Спасибо, что помогли мне еще четче обозначить одно из главных преимуществ инструмента — скорость понимания.
В ДРАКОНе икона действия предназначена для отображения простого, однозначного шага, который выполняется по ходу алгоритма.
Формулировка «Брось монетку» — это явное действие, совершаемое исполнителем процесса (в данном случае — учёным), и отлично подходит для блока действия.
Такой стиль (императивное указание, глагол в повелительном наклонении) полностью соответствует духу и рекомендациям ДРАКОН: делать формулировки шагов максимально ясными, короткими и однозначными для любого участника процесса, чтобы не возникало разночтений.
Я вижу ситуацию вот так. Если коллега хлопнул по руке остановил действие, то учёный уходит в режим ожидания. Мы формально хлопок коллеги принимаем как занятие машины. Этот вариант предполагает что действие брось монету, уже происходит.
Я конечно наворотил, конечно учёный должен хлопнуть своего товарища по руке. Но тогда мы каким то образом руководим человеком, каким образом интересно... И если человек засунет монету чтоб никому ничего не досталось (даже при наличии команды) тоже вариант.
Хотелось бы конечно уточнить что за атрактор выступает как создатель сигнала, машина которая сьела монетку? Или какой внешний наблюдатель? Божественная сущность или эскин подглядевший процесс? Если это практичный вопрос то как будем воздействовать, чтоб отбить бросок, напугаем или устраним? По хорошему не надо давать чтоб в щель машины пролезала вторая монета, то есть ширина щели пускает только одну монету, а шторка которая падает решает вопрос возможности засунуть вторую.
Хочу уточнить правильно ли я понял Задача заблокировать маркер выполнения паралельного процесса "Учёный 1 или 2" в моменте когда монеты брошены и одна из них попала в приёмник. Всё верно в этом моменте происходит блокировка, отбитие броска?
Если вам удобно работать в BPMN я же не призываю вас отказываться от этого языка, да признаю что иногда визуально в нём на уровне программных средств удобнее видеть связи для программиста переходя на разные уровни. Дракон схема это другая логика описания процесса, для меня она лучше так как даёт понимание и мне и бизнесу и программисту что нужно улучшать так как эти вопросы зашиты в структуре Дракон схем при описании возникают вопросы. BPMN это специализированный язык для описания Бизнес Процессов у него не такая структура и связи там про что вы здесь говорите действительно видны лучше. Но читаемость самих схем намного хуже потому что не учитывают особенности человеческого восприятия. Описать в Дракон схеме можно что угодно и понять тоже в BPMN описать можно что угодно, но понимание чего угодно под большым вопросом. Хотя человеку который 10 лет описывал в BPMN будет намного проще разобраться. Тут я не спорю.
Спасибо за конструктивную критику. Добавил в статью примеры.
Согласен, кейс описан слишком легко для технической аудитории. Хотел показать типовую управленческую ошибку, когда измеряют активность ИИ вместо бизнес-интеграции.
"Математически безупречный" вольность с моей стороны. ИТ оценивал точность на исторических данных, но без сравнения с baseline это действительно поверхностно. Анализ причин расхождений -именно его отсутствие и стало проблемой. Система выдавала рекомендации, но не объясняла логику. Логисты не понимали, почему алгоритм предлагает именно такие объемы.
Про "ненадежного поставщика" вы правы, контрдовод не опровергнут. Это как раз пример того, как локальная экспертиза не была учтена в модели. Согласен: без детального технического разбора такие кейсы теряют доказательную силу. Спасибо за детальный разбор.
Прямо сейчас я в проекте по внедрению LLM+RAG, у меня много описанных бизнес процессов в Дракон. По причинам кондифициальности, не могу публиковать рабочие Дракон схемы...
На форуме языка Дракон большое количество различных тем и Дракон схем
@itGuevara, большое спасибо за такой развернутый и профессиональный комментарий! Вы подняли абсолютно верные и важные вопросы, которые помогли сделать статью точнее. Я внес несколько уточнений в текст, чтобы эти моменты были более очевидны для читателей.
Про СЭД vs BPM. Вы совершенно правы, Directum — это в первую очередь СЭД. Я упомянул его в одном ряду с BPM-системами лишь как пример дорогостоящего корпоративного ПО, внедрение которого часто является неподъемным.
Про аналитический и исполняемый BPM. Подход LLM + ДРАКОН — это, безусловно, инструмент для аналитического BPM. Его главная задача — быстро, дешево и, что самое важное, понятно для всей команды описать и проанализировать процесс.
Про "цифровых самозванцев". Спасибо, очень крутая статья на эту тему! И полностью разделяю ваш скепсис по поводу маркетингового хайпа вокруг "цифровых двойников". По сути вы правы: то, что мы создаем — это не полноценный DTO, а скорее "интерактивная модель" или "живая карта" процессов. Это доступный для МСБ шаг на пути к созданию настоящего двойника в будущем. Спасибо, что заострили на этом внимание, — это позволило мне сделать формулировки в 9-й главе более точными.
ну это не так, никто никуда не носится...
Sap_ru,я думаю вы правы — это фундаментальная проблема.
Аппроксимация vs реальность
Ваша формулировка про "промежуточные значения функции" точно описывает суть проблемы. Модель обучается на дискретных точках данных, а между ними пытается интерполировать. И в этих промежутках может выдать что угодно.
В исследовании это называется IIV-редукцией — связь между тем, насколько хорошо модель может отличить правду от лжи, и тем, как часто она врет при генерации. Формула показывает, что ошибки генерации минимум в 2 раза больше ошибок классификации.
Singleton rate как мера проблемы
То, что вы описываете, исследование измеряет через singleton rate — долю фактов, встреченных только один раз. Чем больше таких "одиночек", тем больше промежутков, где функция не определена надежно.
Практический вывод
OpenAI показали: полностью убрать галлюцинации нельзя, но можно изменить поведение модели в промежуточных областях. Вместо попытки угадать — честно сказать "не знаю".
Это не решает математическую проблему аппроксимации, но делает ее предсказуемой и безопасной. Модель перестает врать и начинает признавать границы своих знаний.
По сути, речь идет не об улучшении функции, а об изменении стратегии ее применения
Спасибо за отзыв, EmoCube!
Повторений действительно много. Это осознанное решение, но понимаю, что может раздражать.
Почему так получилось
Исследование OpenAI — это страницы со сложной математикой. Когда я его читал, сам несколько раз терялся в формулах и доказательствах. Поэтому решил использовать классический принцип технических писателей:
"Скажи что скажешь → скажи → скажи что сказал"
Структура для разных читателей
Введение — для тех, кто хочет понять суть за 2 минуты
Математика — для тех, кто хочет разобраться в механизме
Практика — для тех, кто хочет применить прямо сейчас
Ключевые тезисы (формула 2:1, singleton rate) намеренно повторяются в разных контекстах — так они лучше запоминаются. Как в хорошей презентации.
Но вы правы
Для тех, кто читает всю статью целиком, это выглядит избыточно. Классическая дилемма технического писателя: структура для "сканеров" vs комфорт для "читателей".
В следующих материалах попробую найти баланс — возможно, сделать блоки более независимыми или добавить навигацию "читал уже — переходи сразу к практике".
А какой раздел показался наиболее полезным? Интересно понять, на чем стоит фокусироваться в будущих статьях.
Да, вы попали в суть. ДРАКОН действительно не был создан для формального workflow-моделирования в том смысле, который вы описываете. И книга Паронджанова "Как улучшить работу ума" это подтверждает — он создавался как "суперязык интеллектуального общения" для космических проектов, где главной задачей было заставить сотни институтов понимать друг друга.
Про маркеры и семантику движения — вы правы на 100%. В ДРАКОНе есть четкая концепция "дракон-поезда", но она коммуникационная, а не процессная. Когда я рисовал схему с Output'ами, я решал задачу "как объяснить директору, что происходит", а не "как формально описать движение токена". Это принципиально разные задачи.
И вот тут главный фокус. Возьмите приложенную схему кофе-автомата. Видите эти параллельные ветки с двумя учеными, синхронизацию через "монеткоприёмник", условия ожидания? По этой ДРАКОН-схеме я объясню любому руководителю за 5 минут всю логику работы системы. То, что в BPMN или текстовом регламенте потребует намного больше времени для объяснений.
Вот в чем фокус — в 95% бизнес-случаев эта "неформальность" не баг, а фича. У меня была похожая ситуация при описании: две параллельные ветки процесса (прием заказа + проверка склада), и я действительно описывал их синхронизацию словами в комментариях. Работало прекрасно — потому что главная боль бизнеса не в том, что процесс работает на 87% эффективности вместо 92%. Главная боль — в том, что люди друг друга не понимают и тратят часы на объяснения.
А теперь конструктивная часть. Вы описываете потребности двух совершенно разных миров:
Мир бизнес-коммуникации — где ДРАКОН король. Директор смотрит на схему 5 минут и говорит: "Понятно, делаем". Новый сотрудник за день въезжает в логику работы.
Мир математического моделирования — где нужны Петри-сети, формальные семантики и точные расчеты пропускной способности.
Первый мир составляет 95% всех бизнес-задач. Второй — это специальные ниши: производственные линии, высоконагруженные системы, финансовые алгоритмы.
ДРАКОН — это не универсальная отмычка для математического моделирования. Это революционный инструмент экономии времени на коммуникацию. Когда вместо 40-минутных объяснений достаточно 5 минут — это и есть главная ценность для бизнеса. А точное математическое моделирование — следующий этап, для узких специальных задач.
Спасибо, что помогли мне еще четче обозначить одно из главных преимуществ инструмента — скорость понимания.
В предыдущих схемах была моя ошибка
икона "переключатель"
как понятно из названия,
не может запустить два паралельных процесса
В ДРАКОНе икона действия предназначена для отображения простого, однозначного шага, который выполняется по ходу алгоритма.
Формулировка «Брось монетку» — это явное действие, совершаемое исполнителем процесса (в данном случае — учёным), и отлично подходит для блока действия.
Такой стиль (императивное указание, глагол в повелительном наклонении) полностью соответствует духу и рекомендациям ДРАКОН: делать формулировки шагов максимально ясными, короткими и однозначными для любого участника процесса, чтобы не возникало разночтений.
Я вижу ситуацию вот так.
Если коллега хлопнул по руке остановил действие, то учёный уходит в режим ожидания. Мы формально хлопок коллеги принимаем как занятие машины.
Этот вариант предполагает что действие брось монету, уже происходит.
Я конечно наворотил, конечно учёный должен хлопнуть своего товарища по руке. Но тогда мы каким то образом руководим человеком, каким образом интересно...
И если человек засунет монету чтоб никому ничего не досталось (даже при наличии команды) тоже вариант.
Хотелось бы конечно уточнить что за атрактор выступает как создатель сигнала, машина которая сьела монетку? Или какой внешний наблюдатель? Божественная сущность или эскин подглядевший процесс? Если это практичный вопрос то как будем воздействовать, чтоб отбить бросок, напугаем или устраним?
По хорошему не надо давать чтоб в щель машины пролезала вторая монета, то есть ширина щели пускает только одну монету, а шторка которая падает решает вопрос возможности засунуть вторую.
Хочу уточнить правильно ли я понял
Задача заблокировать маркер выполнения паралельного процесса "Учёный 1 или 2"
в моменте когда монеты брошены и одна из них попала в приёмник.
Всё верно в этом моменте происходит блокировка, отбитие броска?
Если вам удобно работать в BPMN я же не призываю вас отказываться от этого языка, да признаю что иногда визуально в нём на уровне программных средств удобнее видеть связи для программиста переходя на разные уровни. Дракон схема это другая логика описания процесса, для меня она лучше так как даёт понимание и мне и бизнесу и программисту что нужно улучшать так как эти вопросы зашиты в структуре Дракон схем при описании возникают вопросы.
BPMN это специализированный язык для описания Бизнес Процессов у него не такая структура и связи там про что вы здесь говорите действительно видны лучше. Но читаемость самих схем намного хуже потому что не учитывают особенности человеческого восприятия.
Описать в Дракон схеме можно что угодно и понять тоже в BPMN описать можно что угодно, но понимание чего угодно под большым вопросом. Хотя человеку который 10 лет описывал в BPMN будет намного проще разобраться. Тут я не спорю.