Как вообще пришла в голову идея использовать для этой цели LLM ? Просто при реальном наличии специализированных инструментов это кажется странным. Ну можно играть в хоккей кием от бильярда. Но клюшкой то сподручней.
Елизавета, в плюсы Вами вынесено “не нужно согласовывать взаимное влияние модулей". Без уточнений.
Нужно понимать, что переход полностью устранил это влияние? Изменение длины поля “Наименование" в модуле “Каталог“ уже можно провести без согласования с модулем "Заказы"? И получить в скором времени знаменитые "пельмени бабушкины останки"?
Не. Всё понятно с плюсами то. Но и о минусах стоит говорить. Особенно аналитикам :)))
Вы привели пример из ритейла. В общем я только поэтому и решил немножко подискутировать, так бы пропустил эту статью мимо, она не первая и не последняя.
То, что Вы называете "подводными камнями" - это не камни. Это жесткие, неустранимые ограничения технологии. SAGA - не серебряная пуля. По сути она и не "паттерн" даже. Изначально эта техника разрабатывалась в условиях распределённых баз, соединенных по модему. Когда длинные транзакции прерывались вместе с обрывом канала. Тогда и была предложена технология разрыва транзакций на "пакеты" со сборкой их на получателе по старт-стоп флагам (хореография) или внешним сервисом (оркестрация). Сейчас эта технология просто всплыла вместе с развитием микросервисов, когда базы начали дробить уже по другой причине.
Ритейл - жёстно зарегулированная область с довольно серьёзными санкциями. Нарушения консистентности баз могут привести к реально серьёзным штрафам, а в случае с "Честным знаком" - и до 171.1 УК довести. Поэтому нужно иметь очень серьёзные аргументы для построения учета (именно учета, а не фронтовых сервисов) для ритейла на распределенных базах. Делать это с полным пониманием ограничений технологий и связанных с этим рисков.
Об этом в Вашей статье ни слова. И может очень больно прилететь новичкам, поверившим в "чудо".
Понятно. Нужно было собрать непредвзятую статистику.
Однако интересно было бы посмотреть на результат другого подхода, о котором я упомянул. Не давать AI задачи, в которых он не тянет (логика, вычисления), и наоборот, не отбирать у AI задачи, в которых он обойдёт человека по скорости (код простого класса).
Я кстати не думаю, что там получился бы какой-то прорывной результат, ибо сам по себе анализ задач для распределения также отнимет время. Просто интересно чисто практически.
За свою область могу сказать, что на задачах системного и бизнес-анализа LLM ведут себя неплохо. Слабые места и пропуски уверенно находят. Но это в основном в качестве инструмента ревью, а не основного аналитика. И выигрыш получается больше не во времени, а в качестве.
Мне не очень понравился один момент, который возможно не совсем верно переведён.
Автор статьи (не перевода) заявлял что работает с ИИ довольно давно. Но при этом решил делить задачи "по монете“, то есть подкидывая нейронке с высокой вероятностью в том числе те задачи, в которых ИИ заведомо слабы.
Думаю, результат был бы иным, если бы человек уже на опыте скармливал нейронке только то, что она гарантированно сделает отлично. По крайней мере в реальной практике такой подход выглядит разумным
Если вдруг очередной Архитектор вдруг решит хотя бы задуматься о том, что ACID не просто так придуман (кстати в те же времена, что и собствено SAGA), и строить учёт на распределённых транзакциях может быть очень больно, уже хорошо.
Почему описывая SAGA, большинство авторов стараются взять кейсы, допускающие откат в 100% случаев ? Опишите обратный кейс. Там, где вы можете словить не техническую, а процессную блокировку в момент отката.
Ну давайте в статье был Заказ, а мы возьмем Возврат.
Клиент оформляет возвратный документ. Вы 1. Создаёте "приходный одер" 2. Ставите товар на остаток 3. Пытаетесь вернуть деньги.
На этапе "3" возникает ошибка - счёт клиента заблокирован. Нужно всё вернуть. При попытке откатить транзакцию "2" Вы натыкаетесь на то, что только что возвращенный товар уже оплачен другим клиентом. Вам уже нужно или откатить новую оплату, или пытаться снова пойти вперёд и вернуть деньги за возвращенный товар.
Что в оркестрации, что в хореографии - какие действия системы ?
Это я сейчас на ходу из головы придумал. Просто в тему статьи. Понятно, что именно этот кейс решается сменой последовательности шагов 2 и 3. Но можно назвать и другие кейсы с нарушением консистентности в распределённой транзакции.
Дополню. Если получится найти статью "A Survey on Hallucination in Large Language Models"
то раздел 3.2 Hallucination from Training описывает как одну из причин галлюцинаций тренировку по методу "поощрение за ответ", штраф за "не знаю" (3.2.2)
Слово "запрет" я явно зря применил. Оно разговорное, но может быть воспринято как явное программное ограничение в контексте обсуждения технической статьи. Благодарю за вопрос, коммент я уже не отредактирую.
Модель не говорит "Не знаю" потому что всё её обучение на человеческих текстах заставляет избегать прерванных ответов и генерировать полное предложение. В итоге она вынуждена додумывать наиболее вероятный ответ.
Вы реально классную задачу подкинули. Пока что в Шедевруме даже рядом не выходит. Без control net и с ограничением длины промпта в 500 символов уже всю бошку сломал :))))
Ну как-то прочитав заголовок, можно было рассчитывать на более развёрнутую аналитику.
Даже простой диалог с любой LLM на эту тему даст больший объём информации.
Та же проблема запрета отвечать "я не знаю" достойна просто отдельной статьи. Я в своё время довольно долго пытался понять причину генерации несуществующих номеров нормативных актов в ответах, пока не докопался до этой особенности
Признаюсь, текст после описания "тревожного расстройства" просто пролистал. Хорошая классификация. Даже наверняка нужная.
Но как понять, что у человека допустим СДВГ чтобы предложить ему персонализированный дизайн?
Это возможно только при явном указании им самим в профиле. Что сразу во-первых ужесточает требования к софту в части 152ФЗ, а во-вторых не гарантирует результата. Допустим, количество людей с клинической депрессией действительно 10%. А сколько из них знают об этом ? Многие узнают о своей депрессии только в момент госпитализации
Камрады уже научились в цифровой профиль. И это хорошо.
Но пока что явно не могут трезво сопоставить реальную ценность своих "глубоко персонализированных предложений" с возможными последстаиями потециальной утечки той инфы, которую они хотят получить для создания "глубокой персонализации".
Это должен быть реально уникальный продукт с очень ощутимым профитом, а не ±0.5% к ставке
Не совсем 😁
Это был чисто человеческий вопрос. Спросил как инженер инженера ;)
Ну вот к чему только уже не прикладывают LLMки. Но мне это даже рядом в голову не приходило чертежи цифровать.
Скажем, по работе (я аналитик), я порой скармливаю LLMкам схемы. Но в plantuml и прочем ".. As Code"
Хорошая статья. Было интересно :)
Один вопрос.
Как вообще пришла в голову идея использовать для этой цели LLM ? Просто при реальном наличии специализированных инструментов это кажется странным. Ну можно играть в хоккей кием от бильярда. Но клюшкой то сподручней.
Это не троллинг. Реально интересно
В смысле ?
MAX - разработка VK так то :)
Елизавета, в плюсы Вами вынесено “не нужно согласовывать взаимное влияние модулей". Без уточнений.
Нужно понимать, что переход полностью устранил это влияние? Изменение длины поля “Наименование" в модуле “Каталог“ уже можно провести без согласования с модулем "Заказы"? И получить в скором времени знаменитые "пельмени бабушкины останки"?
Не. Всё понятно с плюсами то. Но и о минусах стоит говорить. Особенно аналитикам :)))
Как-нибудь на досуге посмотрите спокойно метод профайлинга "7 радикалов"
Особое внимание уделите главам "шизоидный и эпилептоидный психотипы".
Не обращайте внимание на медициское созвучие терминов. Они не об этом.
Зато статья строго о том, как шизоиду временно включить эпилептоидние скилы. Это вообще полезный навык.
Вы привели пример из ритейла.
В общем я только поэтому и решил немножко подискутировать, так бы пропустил эту статью мимо, она не первая и не последняя.
То, что Вы называете "подводными камнями" - это не камни. Это жесткие, неустранимые ограничения технологии. SAGA - не серебряная пуля. По сути она и не "паттерн" даже. Изначально эта техника разрабатывалась в условиях распределённых баз, соединенных по модему. Когда длинные транзакции прерывались вместе с обрывом канала. Тогда и была предложена технология разрыва транзакций на "пакеты" со сборкой их на получателе по старт-стоп флагам (хореография) или внешним сервисом (оркестрация).
Сейчас эта технология просто всплыла вместе с развитием микросервисов, когда базы начали дробить уже по другой причине.
Ритейл - жёстно зарегулированная область с довольно серьёзными санкциями. Нарушения консистентности баз могут привести к реально серьёзным штрафам, а в случае с "Честным знаком" - и до 171.1 УК довести.
Поэтому нужно иметь очень серьёзные аргументы для построения учета (именно учета, а не фронтовых сервисов) для ритейла на распределенных базах. Делать это с полным пониманием ограничений технологий и связанных с этим рисков.
Об этом в Вашей статье ни слова. И может очень больно прилететь новичкам, поверившим в "чудо".
Всех благ.
В процессе чтения почему-то постоянно вертелся в голове фразеологизм “натянуть сову на глобус".
Однако ж стоит признать, натягивание сие прошло очень даже пристойно :))
Спасибо автору за пару минут хорошего настроения
Насчёт умного поиска по нормативной документации - это очень больной вопрос.
До тех пор, пока не будут устранены базовые причины галлюцинаций LLM в виде "ответа любой ценой“, рассчитывать на такие агенты не стоит.
Понятно. Нужно было собрать непредвзятую статистику.
Однако интересно было бы посмотреть на результат другого подхода, о котором я упомянул. Не давать AI задачи, в которых он не тянет (логика, вычисления), и наоборот, не отбирать у AI задачи, в которых он обойдёт человека по скорости (код простого класса).
Я кстати не думаю, что там получился бы какой-то прорывной результат, ибо сам по себе анализ задач для распределения также отнимет время. Просто интересно чисто практически.
За свою область могу сказать, что на задачах системного и бизнес-анализа LLM ведут себя неплохо. Слабые места и пропуски уверенно находят. Но это в основном в качестве инструмента ревью, а не основного аналитика. И выигрыш получается больше не во времени, а в качестве.
Рабочий процесс при этом настраивается однократно или приходится всё делать с нуля под каждую новую версию агента?
Ну то есть сколько процентов рабочего времени на длинном плече планирования (год, скажем) будет отнимать настройка рабочего места?
Мне не очень понравился один момент, который возможно не совсем верно переведён.
Автор статьи (не перевода) заявлял что работает с ИИ довольно давно. Но при этом решил делить задачи "по монете“, то есть подкидывая нейронке с высокой вероятностью в том числе те задачи, в которых ИИ заведомо слабы.
Думаю, результат был бы иным, если бы человек уже на опыте скармливал нейронке только то, что она гарантированно сделает отлично. По крайней мере в реальной практике такой подход выглядит разумным
Сергей, добрый день.
Именно Ганта в системе Вы так и не показали по сути. А хотелось бы.
Очень интересует планирование зависимых, совместных и последовательных, релизов в разных системах, связанных end-to-end задачами
Если вдруг очередной Архитектор вдруг решит хотя бы задуматься о том, что ACID не просто так придуман (кстати в те же времена, что и собствено SAGA), и строить учёт на распределённых транзакциях может быть очень больно, уже хорошо.
Так считаю.
Почему описывая SAGA, большинство авторов стараются взять кейсы, допускающие откат в 100% случаев ?
Опишите обратный кейс. Там, где вы можете словить не техническую, а процессную блокировку в момент отката.
Ну давайте в статье был Заказ, а мы возьмем Возврат.
Клиент оформляет возвратный документ.
Вы
1. Создаёте "приходный одер"
2. Ставите товар на остаток
3. Пытаетесь вернуть деньги.
На этапе "3" возникает ошибка - счёт клиента заблокирован. Нужно всё вернуть.
При попытке откатить транзакцию "2" Вы натыкаетесь на то, что только что возвращенный товар уже оплачен другим клиентом. Вам уже нужно или откатить новую оплату, или пытаться снова пойти вперёд и вернуть деньги за возвращенный товар.
Что в оркестрации, что в хореографии - какие действия системы ?
Это я сейчас на ходу из головы придумал. Просто в тему статьи. Понятно, что именно этот кейс решается сменой последовательности шагов 2 и 3. Но можно назвать и другие кейсы с нарушением консистентности в распределённой транзакции.
Дополню.
Если получится найти статью "A Survey on Hallucination in Large Language Models"
то раздел
3.2 Hallucination from Training
описывает как одну из причин галлюцинаций тренировку по методу "поощрение за ответ", штраф за "не знаю" (3.2.2)
Слово "запрет" я явно зря применил. Оно разговорное, но может быть воспринято как явное программное ограничение в контексте обсуждения технической статьи.
Благодарю за вопрос, коммент я уже не отредактирую.
Имелось в виду:
https://openreview.net/pdf?id=rygGQyrFvH
раздел
4.3 NATURAL LANGUAGE DOES NOT MAXIMIZE PROBABILITY
Модель не говорит "Не знаю" потому что всё её обучение на человеческих текстах заставляет избегать прерванных ответов и генерировать полное предложение.
В итоге она вынуждена додумывать наиболее вероятный ответ.
Вернулся поблагодарить.
Вы реально классную задачу подкинули. Пока что в Шедевруме даже рядом не выходит. Без control net и с ограничением длины промпта в 500 символов уже всю бошку сломал :))))
Ну как-то прочитав заголовок, можно было рассчитывать на более развёрнутую аналитику.
Даже простой диалог с любой LLM на эту тему даст больший объём информации.
Та же проблема запрета отвечать "я не знаю" достойна просто отдельной статьи. Я в своё время довольно долго пытался понять причину генерации несуществующих номеров нормативных актов в ответах, пока не докопался до этой особенности
Признаюсь, текст после описания "тревожного расстройства" просто пролистал. Хорошая классификация. Даже наверняка нужная.
Но как понять, что у человека допустим СДВГ чтобы предложить ему персонализированный дизайн?
Это возможно только при явном указании им самим в профиле. Что сразу во-первых ужесточает требования к софту в части 152ФЗ, а во-вторых не гарантирует результата. Допустим, количество людей с клинической депрессией действительно 10%. А сколько из них знают об этом ? Многие узнают о своей депрессии только в момент госпитализации
Камрады уже научились в цифровой профиль. И это хорошо.
Но пока что явно не могут трезво сопоставить реальную ценность своих "глубоко персонализированных предложений" с возможными последстаиями потециальной утечки той инфы, которую они хотят получить для создания "глубокой персонализации".
Это должен быть реально уникальный продукт с очень ощутимым профитом, а не ±0.5% к ставке