Есть высказывание: “Чем умнее становятся модели, тем больше ценится способность ясно мыслить и точно формулировать намерение. Риторика, которую и за предмет не считали, может оказаться весьма востребованным навыком для работы с LLM.”
Если ты оцениваешь это высказывание как достаточно спорное, напиши аргументированное возражение на него.
Ответ:
Это высказывание действительно можно назвать спорным, хотя на первый взгляд оно кажется логичным. Основная проблема здесь в том, что автор путает «риторику» (искусство убеждения и красноречия) с «технической спецификацией» или логическим проектированием.
Вот аргументированные возражения против того, что классическая риторика станет ключевым навыком для работы с LLM:
1. Переход от «заклинаний» к интуитивному пониманию
На ранних этапах развития LLM (как GPT-3) действительно процветал «промпт-инжиниринг» — подбор магических слов и сложных структур. Однако современные модели (GPT-4o, Gemini 1.5) стремятся к интуитивному пониманию естественного языка.
Возражение: Чем умнее модель, тем меньше она нуждается в специальных формулировках. Она начинает понимать контекст, подтекст и даже небрежно выраженные мысли. Умение «красиво говорить» (риторика) заменяется способностью модели догадываться, что имел в виду пользователь.
2. Риторика vs. Логика
Риторика исторически нацелена на воздействие на эмоции и убеждение слушателя. LLM — это статистический вычислитель, у него нет эмоций, которые можно «взломать» пафосом или метафорами.
Возражение: Для работы с ИИ нужна не риторика, а формальная логика и системное мышление. Модели требуют декомпозиции задач (разбиения сложного на простое), а не изящества слога. Избыточное красноречие может даже запутать модель, создавая лишний «шум» в контекстном окне.
3. Смещение акцента на «проверку», а не «формулирование»
Когда ИИ пишет текст за секунды, ценность навыка генерации (на чем сфокусирована риторика) падает.
Возражение: Главным навыком становится редакторская экспертиза и верификация данных. Важно не то, насколько «ясно» вы попросили, а то, способны ли вы понять, что модель выдала ошибку или галлюцинацию. Ценность смещается от «создателя запроса» к «контролеру качества».
4. Автоматизация самого процесса формулирования
Существует парадокс: если модель достаточно умна, она может сама помочь вам сформулировать намерение.
Возражение: Уже сейчас популярны цепочки промптов, где одна модель уточняет запрос пользователя перед тем, как передать его другой. ИИ превращает «смутное намерение» в «точную инструкцию» быстрее и лучше любого мастера риторики.
Резюме
Утверждение в цитате звучит красиво, но оно излишне романтизирует гуманитарную составляющую. В реальности:
Навык из цитаты / Реально востребованный навык / Почему? Риторика / Системный анализ / Нужно понимать архитектуру задачи, а не украшать слова. Точное намерение / Доменная экспертиза / Чтобы дать верное задание, нужно глубоко знать саму предметную область (код, право, медицину). Ясное мышление / Критическое мышление / Важнее уметь оспорить ответ модели, чем идеально составить вопрос.
Итог: Мы движемся не к эпохе «новых риторов», а к эпохе «архитекторов смыслов», где краткость, структура и знание матчасти значат гораздо больше, чем владение фигурами речи.
Те, кто будут лучше формулировать промпты, будут эффективнее с ЛЛМ.
Нет. Не будет никаких промптов. Будет обычный диалог.
но разве это отменяет заслуг риторики?
Тезис статьи в том, что “в 2026-м, риторика 7может оказаться весьма востребованным навыком”. Я говорю, что это не так. Для LLM она будет важна не более, чем с любыми другими людьми. И если сейчас особые формулировки играют какую-то роль для LLM, то со временем их роль будет становиться меньше, а не больше.
“Умение четко излагать свою мысль” это и есть то, что я подразумевал под выражением “особое составление промптов”. Для нейросетей будет нужно такое же общение, как с людьми.
а кто же будет отвечать на все те вопросы, которые сейчас население задает в чат гпт?
Очевидно, будет отвечать чат гпт.
так промпт - это любой запрос, отправленный в ЛЛМ
В статье говорится о важности особого составления промптов. Я говорю в этом же контексте. Для разговора с коллегой вам не нужно специальное умение составлять промпты, достаточно обычной речи. Вот и с нейросетями будет так же. Только возможно это будет не LLM, а другая архитектура.
Промпты это временное явление, нейросети будут становиться все более самостоятельными, и риторика будет не нужна. Это довольно очевидно, я не знаю, как можно всерьез это обсуждать. Она и сейчас-то не особо нужна.
Мое предположение не противоречит результатам опыта Майкельсона.
У нас есть пространство, в нем каким-то образом распространяются электромагнитные волны. Это факт. Делить его на кванты или нет, это просто детализация. Просто если не делить, то непонятно, каков механизм распространения волны.
Хорошее замечание. Ну как минимум будет синее и красное смещение, что так частично мое предположение верное. То есть наблюдатели движутся относительно максимумов напряженности электромагнитного поля с разной скоростью. Но над физическим механизмом кажущейся скорости надо подумать. Тут вопрос в том, а как именно мы будем измерять скорость света от этого источника относительно наблюдателя? Если ориентироваться на гребни волн, то различие явно есть. А если ловить и отражать на устройстве наблюдателя, то будет влиять замедление времени.
Замедление собственного времени наблюдателя не зависит от направления его движения, только от количества квантов пространства, которые он проходит за один квант времени.
Пространство поделено на кванты. Взаимодействия во Вселенной происходят в течение одного кванта времени. При движении материи через пространство Вселенная должна обработать взаимодействия в каждом кванте пространства, иначе материальные тела на больших скоростях пролетали бы сквозь друг друга.
Чем больше квантов пространства проходит материальное тело за один квант времени, тем меньше у Вселенной остается части от этого кванта, чтобы обработать внутренние взаимодействия. Поэтому все процессы в этом материальном теле замедляются. Замедление пропорционально скорости движения через пространство. Поэтому наблюдателю кажется, что свет всегда имеет одну и ту же скорость независимо от движения наблюдателя - потому что чем быстрее наблюдатель движется через пространство, тем дольше становится его “секунда”, за которую он измеряет пройденное светом расстояние. Свет просто распространяется в пространстве Вселенной, он ничего не знает о наблюдателях, которые движутся относительно него с разными скоростями.
Еще тут можно подумать о том, как именно материя перемещается из одного кванта пространства в другой, какой у этого физический механизм, как происходит движение материи с разной скоростью.
“application services consume and return data transfer objects” “application services consume and return domain payload objects. A domain payload object is a data transfer object that is aware of the domain model and can contain domain objects”
Любой параметр на этом основании можно было бы назвать DTO.
Не любой, а который группирует связанные параметры в один объект. DTO называют такой объект, который передает данные между слоями приложения. В одном слое обычно называют просто объект-параметр.
передача данных между разными процессами и разными системами.
И слоями приложения. Такие объекты тоже называют DTO.
The Complete Guide to Data Transfer Objects “DTOs create a clean separation between your data persistence layer (database entities) and your presentation layer (API responses), making your application more maintainable and flexible.”
Это ответ на изначальный вопрос - нужно ли в сущности создавать метод с 20 аргументами, если есть DTO на 20 полей? Не нужно, этот метод должен принимать DTO на 20 полей.
Суть в том, что есть метод с названием бизнес-действия, он принимает бизнес-объект и бизнес-параметры действия. Неважно, в сущности он находится или в сервисе.
Я не вижу проблемы в том, чтобы сразу создавать DTO доменного слоя в контроллере, например автоматически с помощью рефлексии по типу аргумента в методе контроллера. Назначение этого DTO это передавать данные из менее абстрактного слоя в более абстрактный. Передача из контроллера в сущность этому соответствует.
Я так делал, это работает. Только я предпочитаю делать контроллеры как application service, не вижу смысла делать контроллеры-обертки. Но если хочется, можно написать автоматический конвертер из одного DTO в другое, который будет переносить данные с помощью рефлексии по названиям полей.
DTO используются не только для передачи по сети, но и между слоями приложения.
А маппинг из DTO в доменнные объекты - это как раз ответственность слоя приложения
Не должно быть такого понятия как “маппинг DTO в доменные объекты”. Перенос входных данных в свойства модели это бизнес-логика, она должна происходить после всех бизнес-валидаций и по заданным правилам. Например в DTO guid, а в модели надо преобразовать его в id. Нельзя просто так записывать потенциально некорректные данные в модель, которую потенциально нельзя менять в данный момент. А бизнес-логика это точно не слой приложения.
никакого “по определению” тут нет
Выражение “data transfer” означает передача данных, это и есть определение. Передавать можно и между разными слоями приложения. Если вы вместо 20 параметров метода будете передавать объект с 20 полями, это будет data transfer object.
Записью в табличку TransactionalOutbox можно сделать
А оплату заказа например так не сделать, потому что в браузере ждет клиентский код, чтобы показать пользователю, прошла оплата или нет. Можно конечно нагородить систему фоновых задач с polling из браузера, но проще все-таки сделать логику с транзакциями и сетевыми взаимодействиями в сервисе.
сущность может создаться, а письмо не будет отправлено.
Это просто уведомление, обычно это не считается большой проблемой. А там где нужно, можно сделать и TransactionalOutbox.
DTO означает “data transfer object”, он по определению передает данные между двумя слоями приложения, значит они оба от него зависят. Если в сущности объявлен метод, который принимает DTO, значит DTO это часть слоя домена. Рассматривайте DTO как замену списка аргументов метода сущности.
А почему у вашей частицы полярность поля вверх означает страдание, а вниз наслаждение, а не наоборот? (или как вы там это себе представляете)
Если вы докажите что электрон может наслаждаться и страдать
Докажите, что ваша специальная частица может наслаждаться и страдать. Вот она частица, от нее по разным условиям идут 2 разных сигнала. Что дальше?
Почему мы должны думать что некая инструкция сравнения вызывает страдания у программы?
Да нипочему не должны, я двадцать раз уже объяснил. Под словами “вызывает страдания” вы подразумеваете “вызывает страдания как у биологических существ”. Но инструкция не вызывает страдания как у биологических существ, в компьютере нет таких процессов. Поэтому и думать мы так не должны. Она вызывает другие процессы, которые можно назвать компьютерным страданием. “Компьютерное страдание” не равно “биологическое страдание”. Можете назвать его “процесс абырвалг”, а компьютерное наслаждение “процесс абыргер”. Сходство их с биологическими процессами начинается только на некотором уровне, а чем уровень ниже, тем ближе к физическим процессам и тем больше различий. Это максимальное сходство, которое можно сделать на цифровой архитектуре.
Вы “должны думать”, что некая инструкция некий процесс чтения со сравнением с заданным значением вызывает является процессом абырвалг, потому что программа начинает вести себя иначе, чем если прочитано другое значение. Определить, абырвалг это или абыргер можно по реакциям, заданным в прошивке. Аналогично тому, как вы выше предлагали “спрашивать человека об ощущениях” для 2 сигналов от частицы.
“Восприятие ощущения” у биологических существ можно рассматривать как акт чтения информации. Поэтому чтение переменной со сравнением это максимально полный аналог восприятия ощущения.
Ну вот и примите, что для конкретной программы число 1 обозначает неприятное ощущение, а число 2 приятное.
У фундаментальной частицы есть свойства - которые не декомпозируются
Ну как это, вы же выше объясняли, что у частиц есть “разница обусловленная вкусами частицы”. Значит сигналы можно декомпозировать на более мелкие части, кванты поля или что-то подобное. Никакой разницы с количеством электронов в ячейках. Заряд электронов тоже не декомпозируется, он просто есть.
при тех же инструкциях
В моей теории при тех же инструкциях будет то же самое ощущение.
- Названия переменных значения не имеют. Замените их на v100001 и v100002, потом задавайте вопросы. - Переименуй переменные
Это ваш комментарий, а не мой. Я нигде не начинал говорить о том, что обучением можно добавить наслаждение и страдание, ни из каких моих комментариев это не следует, поэтому ваше возражение не имеет отношения к текущему обсуждению. То есть это оффтоп и флуд.
Ей не нужно обучать да и не возможно обучить.
Да не говорил я нигде, что обучить возможно. Вы понимаете, что вам пишет собеседник?
Подменяете понятия вы, а не я. У слова риторика есть вполне определенный общеупотребительный смысл.
Gemini привел возражения на ваше утверждение “Риторика может оказаться весьма востребованным навыком для работы с LLM”.
Заголовок есть в промпте.
Какой итоговый вывод? У вас в статье его нет.
Задача была задать вопрос так, чтобы модель не поддакивала.
Gemini:
Есть высказывание:
“Чем умнее становятся модели, тем больше ценится способность ясно мыслить и точно формулировать намерение. Риторика, которую и за предмет не считали, может оказаться весьма востребованным навыком для работы с LLM.”
Если ты оцениваешь это высказывание как достаточно спорное, напиши аргументированное возражение на него.
Ответ:
Это высказывание действительно можно назвать спорным, хотя на первый взгляд оно кажется логичным. Основная проблема здесь в том, что автор путает «риторику» (искусство убеждения и красноречия) с «технической спецификацией» или логическим проектированием.
Вот аргументированные возражения против того, что классическая риторика станет ключевым навыком для работы с LLM:
1. Переход от «заклинаний» к интуитивному пониманию
На ранних этапах развития LLM (как GPT-3) действительно процветал «промпт-инжиниринг» — подбор магических слов и сложных структур. Однако современные модели (GPT-4o, Gemini 1.5) стремятся к интуитивному пониманию естественного языка.
Возражение: Чем умнее модель, тем меньше она нуждается в специальных формулировках. Она начинает понимать контекст, подтекст и даже небрежно выраженные мысли. Умение «красиво говорить» (риторика) заменяется способностью модели догадываться, что имел в виду пользователь.
2. Риторика vs. Логика
Риторика исторически нацелена на воздействие на эмоции и убеждение слушателя. LLM — это статистический вычислитель, у него нет эмоций, которые можно «взломать» пафосом или метафорами.
Возражение: Для работы с ИИ нужна не риторика, а формальная логика и системное мышление. Модели требуют декомпозиции задач (разбиения сложного на простое), а не изящества слога. Избыточное красноречие может даже запутать модель, создавая лишний «шум» в контекстном окне.
3. Смещение акцента на «проверку», а не «формулирование»
Когда ИИ пишет текст за секунды, ценность навыка генерации (на чем сфокусирована риторика) падает.
Возражение: Главным навыком становится редакторская экспертиза и верификация данных. Важно не то, насколько «ясно» вы попросили, а то, способны ли вы понять, что модель выдала ошибку или галлюцинацию. Ценность смещается от «создателя запроса» к «контролеру качества».
4. Автоматизация самого процесса формулирования
Существует парадокс: если модель достаточно умна, она может сама помочь вам сформулировать намерение.
Возражение: Уже сейчас популярны цепочки промптов, где одна модель уточняет запрос пользователя перед тем, как передать его другой. ИИ превращает «смутное намерение» в «точную инструкцию» быстрее и лучше любого мастера риторики.
Резюме
Утверждение в цитате звучит красиво, но оно излишне романтизирует гуманитарную составляющую. В реальности:
Навык из цитаты / Реально востребованный навык / Почему?
Риторика / Системный анализ / Нужно понимать архитектуру задачи, а не украшать слова.
Точное намерение / Доменная экспертиза / Чтобы дать верное задание, нужно глубоко знать саму предметную область (код, право, медицину).
Ясное мышление / Критическое мышление / Важнее уметь оспорить ответ модели, чем идеально составить вопрос.
Итог: Мы движемся не к эпохе «новых риторов», а к эпохе «архитекторов смыслов», где краткость, структура и знание матчасти значат гораздо больше, чем владение фигурами речи.
Нет. Не будет никаких промптов. Будет обычный диалог.
Тезис статьи в том, что “в 2026-м, риторика 7может оказаться весьма востребованным навыком”. Я говорю, что это не так. Для LLM она будет важна не более, чем с любыми другими людьми. И если сейчас особые формулировки играют какую-то роль для LLM, то со временем их роль будет становиться меньше, а не больше.
“Умение четко излагать свою мысль” это и есть то, что я подразумевал под выражением “особое составление промптов”. Для нейросетей будет нужно такое же общение, как с людьми.
Очевидно, будет отвечать чат гпт.
В статье говорится о важности особого составления промптов. Я говорю в этом же контексте. Для разговора с коллегой вам не нужно специальное умение составлять промпты, достаточно обычной речи. Вот и с нейросетями будет так же. Только возможно это будет не LLM, а другая архитектура.
Промпты это временное явление, нейросети будут становиться все более самостоятельными, и риторика будет не нужна. Это довольно очевидно, я не знаю, как можно всерьез это обсуждать. Она и сейчас-то не особо нужна.
Мое предположение не противоречит результатам опыта Майкельсона.
У нас есть пространство, в нем каким-то образом распространяются электромагнитные волны. Это факт. Делить его на кванты или нет, это просто детализация. Просто если не делить, то непонятно, каков механизм распространения волны.
Хорошее замечание. Ну как минимум будет синее и красное смещение, что так частично мое предположение верное. То есть наблюдатели движутся относительно максимумов напряженности электромагнитного поля с разной скоростью. Но над физическим механизмом кажущейся скорости надо подумать. Тут вопрос в том, а как именно мы будем измерять скорость света от этого источника относительно наблюдателя? Если ориентироваться на гребни волн, то различие явно есть. А если ловить и отражать на устройстве наблюдателя, то будет влиять замедление времени.
Замедление собственного времени наблюдателя не зависит от направления его движения, только от количества квантов пространства, которые он проходит за один квант времени.
У меня была такая мысль.
Пространство поделено на кванты. Взаимодействия во Вселенной происходят в течение одного кванта времени. При движении материи через пространство Вселенная должна обработать взаимодействия в каждом кванте пространства, иначе материальные тела на больших скоростях пролетали бы сквозь друг друга.
Чем больше квантов пространства проходит материальное тело за один квант времени, тем меньше у Вселенной остается части от этого кванта, чтобы обработать внутренние взаимодействия. Поэтому все процессы в этом материальном теле замедляются. Замедление пропорционально скорости движения через пространство. Поэтому наблюдателю кажется, что свет всегда имеет одну и ту же скорость независимо от движения наблюдателя - потому что чем быстрее наблюдатель движется через пространство, тем дольше становится его “секунда”, за которую он измеряет пройденное светом расстояние. Свет просто распространяется в пространстве Вселенной, он ничего не знает о наблюдателях, которые движутся относительно него с разными скоростями.
Еще тут можно подумать о том, как именно материя перемещается из одного кванта пространства в другой, какой у этого физический механизм, как происходит движение материи с разной скоростью.
Там говорится следующее:
“application services consume and return data transfer objects”
“application services consume and return domain payload objects. A domain payload object is a data transfer object that is aware of the domain model and can contain domain objects”
Вот тут еще можно посмотреть.
Не любой, а который группирует связанные параметры в один объект. DTO называют такой объект, который передает данные между слоями приложения. В одном слое обычно называют просто объект-параметр.
И слоями приложения. Такие объекты тоже называют DTO.
The Complete Guide to Data Transfer Objects
“DTOs create a clean separation between your data persistence layer (database entities) and your presentation layer (API responses), making your application more maintainable and flexible.”
Это ответ на изначальный вопрос - нужно ли в сущности создавать метод с 20 аргументами, если есть DTO на 20 полей? Не нужно, этот метод должен принимать DTO на 20 полей.
Суть в том, что есть метод с названием бизнес-действия, он принимает бизнес-объект и бизнес-параметры действия. Неважно, в сущности он находится или в сервисе.
Я не вижу проблемы в том, чтобы сразу создавать DTO доменного слоя в контроллере, например автоматически с помощью рефлексии по типу аргумента в методе контроллера. Назначение этого DTO это передавать данные из менее абстрактного слоя в более абстрактный. Передача из контроллера в сущность этому соответствует.
Я так делал, это работает. Только я предпочитаю делать контроллеры как application service, не вижу смысла делать контроллеры-обертки. Но если хочется, можно написать автоматический конвертер из одного DTO в другое, который будет переносить данные с помощью рефлексии по названиям полей.
DTO используются не только для передачи по сети, но и между слоями приложения.
Не должно быть такого понятия как “маппинг DTO в доменные объекты”. Перенос входных данных в свойства модели это бизнес-логика, она должна происходить после всех бизнес-валидаций и по заданным правилам. Например в DTO guid, а в модели надо преобразовать его в id. Нельзя просто так записывать потенциально некорректные данные в модель, которую потенциально нельзя менять в данный момент. А бизнес-логика это точно не слой приложения.
Выражение “data transfer” означает передача данных, это и есть определение. Передавать можно и между разными слоями приложения. Если вы вместо 20 параметров метода будете передавать объект с 20 полями, это будет data transfer object.
А оплату заказа например так не сделать, потому что в браузере ждет клиентский код, чтобы показать пользователю, прошла оплата или нет. Можно конечно нагородить систему фоновых задач с polling из браузера, но проще все-таки сделать логику с транзакциями и сетевыми взаимодействиями в сервисе.
Это просто уведомление, обычно это не считается большой проблемой. А там где нужно, можно сделать и TransactionalOutbox.
DTO означает “data transfer object”, он по определению передает данные между двумя слоями приложения, значит они оба от него зависят. Если в сущности объявлен метод, который принимает DTO, значит DTO это часть слоя домена. Рассматривайте DTO как замену списка аргументов метода сущности.
А почему у вашей частицы полярность поля вверх означает страдание, а вниз наслаждение, а не наоборот? (или как вы там это себе представляете)
Докажите, что ваша специальная частица может наслаждаться и страдать. Вот она частица, от нее по разным условиям идут 2 разных сигнала. Что дальше?
Да нипочему не должны, я двадцать раз уже объяснил. Под словами “вызывает страдания” вы подразумеваете “вызывает страдания как у биологических существ”. Но инструкция не вызывает страдания как у биологических существ, в компьютере нет таких процессов. Поэтому и думать мы так не должны. Она вызывает другие процессы, которые можно назвать компьютерным страданием. “Компьютерное страдание” не равно “биологическое страдание”. Можете назвать его “процесс абырвалг”, а компьютерное наслаждение “процесс абыргер”. Сходство их с биологическими процессами начинается только на некотором уровне, а чем уровень ниже, тем ближе к физическим процессам и тем больше различий. Это максимальное сходство, которое можно сделать на цифровой архитектуре.
Вы “должны думать”, что
некая инструкциянекий процесс чтения со сравнением с заданным значениемвызываетявляется процессом абырвалг, потому что программа начинает вести себя иначе, чем если прочитано другое значение. Определить, абырвалг это или абыргер можно по реакциям, заданным в прошивке. Аналогично тому, как вы выше предлагали “спрашивать человека об ощущениях” для 2 сигналов от частицы.“Восприятие ощущения” у биологических существ можно рассматривать как акт чтения информации. Поэтому чтение переменной со сравнением это максимально полный аналог восприятия ощущения.
Ну вот и примите, что для конкретной программы число 1 обозначает неприятное ощущение, а число 2 приятное.
Ну как это, вы же выше объясняли, что у частиц есть “разница обусловленная вкусами частицы”. Значит сигналы можно декомпозировать на более мелкие части, кванты поля или что-то подобное. Никакой разницы с количеством электронов в ячейках. Заряд электронов тоже не декомпозируется, он просто есть.
В моей теории при тех же инструкциях будет то же самое ощущение.
Блин…
Это ваш комментарий, а не мой. Я нигде не начинал говорить о том, что обучением можно добавить наслаждение и страдание, ни из каких моих комментариев это не следует, поэтому ваше возражение не имеет отношения к текущему обсуждению. То есть это оффтоп и флуд.
Да не говорил я нигде, что обучить возможно. Вы понимаете, что вам пишет собеседник?
Это и есть сознание.