Если вдруг очередной Архитектор вдруг решит хотя бы задуматься о том, что 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% к ставке
А я то всё думал зачем у меня через Госуслуги просят доступ к вот этому вот всему.
Я всё искал запрос цвета горошка на трусах, но не нашёл. Вот и не дал.
А это оказывается ребро графа такое. Чтобы значит решить стоит мне чего продавать или нет. Вон оно чё. Так бы дал конечно разрешение, если б знал. А так не дал. Сорян, ребят
Есть ощущение, что в начало статьи нужно было добавить "выхолащивание управленческих компетенций среднего звена руководителей дошло до такой степени, что HR вынуждены искать самоуправляемых сотрудников".
У меня под руками были Шедеврум 2.5 и GigaChat в MAX - достаточно стандартный набор для телефона. Я не стал размещать в статье все варианты промптов, которые перебрал. Но их было много, пока не пошёл в сторону разбора токенов.
Моё предположение - в эти модели загружены в основном dataset-ы c полноценной сервировкой. И они перевешивают запросы на уникальные сюжеты артов (одна чашка, один бокал).
В общем следующие шаги (убрать чашку из промпта) подтверждают эту догадку. Модели упорно продолжают "досервировывать" сюжет.
В StableDiffusion этого нет - он сразу делает чёткую композицию.
И да, писать промпт сразу по-английски я не пробовал.
На практике большинство бизнес-задач решается в рамках одного модуля.
Если задача требует одновременно ковырнуть SD и FI (наиболее частая пара на моей практике), то ролл-аут общий идёт. Вернее, одновременный. Разными пакетами
Есть ещё пара вещей, о которых стоило бы упомянуть на мой взгляд.
Совмещение бэклогов для end2end задач. Если надробить монолит без учёта регулярной совместной разработки функций, можно сильно проиграть по time-to-market
Бухгалтерский и управленческий учёт таки требуют ACID. Без него слишком больно
Если вдруг очередной Архитектор вдруг решит хотя бы задуматься о том, что 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% к ставке
А я то всё думал зачем у меня через Госуслуги просят доступ к вот этому вот всему.
Я всё искал запрос цвета горошка на трусах, но не нашёл. Вот и не дал.
А это оказывается ребро графа такое. Чтобы значит решить стоит мне чего продавать или нет. Вон оно чё. Так бы дал конечно разрешение, если б знал. А так не дал. Сорян, ребят
Есть ощущение, что в начало статьи нужно было добавить "выхолащивание управленческих компетенций среднего звена руководителей дошло до такой степени, что HR вынуждены искать самоуправляемых сотрудников".
Добрый день.
В StableDiffusion всё нормально выходит. А если ненормально – можно выправить через control net.
Речь в статье о "карманных" моделях, доступных с телефона.
Замок за 2000 ₽ врядли позиционируется как квартирный.
Для небольшой гостиницы такое вполне подойдёт. Или для комнат "для персонала" в общественных заведениях типа поликлиник.
Какое применение у производителя указано? Интересно.
Благодарю. Вот прямо сегодня и займусь.
Интересная идея.
У меня под руками были Шедеврум 2.5 и GigaChat в MAX - достаточно стандартный набор для телефона.
Я не стал размещать в статье все варианты промптов, которые перебрал. Но их было много, пока не пошёл в сторону разбора токенов.
Моё предположение - в эти модели загружены в основном dataset-ы c полноценной сервировкой. И они перевешивают запросы на уникальные сюжеты артов (одна чашка, один бокал).
В общем следующие шаги (убрать чашку из промпта) подтверждают эту догадку. Модели упорно продолжают "досервировывать" сюжет.
В StableDiffusion этого нет - он сразу делает чёткую композицию.
И да, писать промпт сразу по-английски я не пробовал.
В ряде из поиведённых Вами компаний (а также и в не приведённых) действует принцип "фронт на сервисах, учёт в монолите". Это работает
На практике большинство бизнес-задач решается в рамках одного модуля.
Если задача требует одновременно ковырнуть SD и FI (наиболее частая пара на моей практике), то ролл-аут общий идёт. Вернее, одновременный. Разными пакетами
Реально хорошая работа.
Есть ещё пара вещей, о которых стоило бы упомянуть на мой взгляд.
Совмещение бэклогов для end2end задач. Если надробить монолит без учёта регулярной совместной разработки функций, можно сильно проиграть по time-to-market
Бухгалтерский и управленческий учёт таки требуют ACID. Без него слишком больно