За последнее время большие языковые модели (LLM) стали привычным инструментом для анализа и работы с текстом. Но, что важно, качество ответа зависит не только от самой модели, но и от того, как именно задан запрос.
Обычно промт строят по проверенной схеме: задать роль («представь, что ты эксперт»), дать инструкцию, что и как сделать («сделай краткое резюме»), указать ограничения и уточнить формат (объём, стиль, язык), добавить входные данные и, если есть, пример ответа.
Однако, такой подход не всегда дает нужный ответ в творческих задачах. Заданная «роль» сужает поиск решений; инструкция «как сделать», может навязывать неоптимальный метод или ограничивать варианты поиска более подходящих. А неполное описание задачи (даже то, что кажется очевидным) нередко вынуждает модель придумывать и выдавать галлюцинации.
Цель этой статьи-размышления - предложить альтернативную структуру архитектурного промта, которая не заменяет, а расширяет и дополняет существующие практики. Я попробую показать, как можно сместить акцент с «роли» на логику рассуждений, и добавить метрики - критерии корректности ответа. Такой подход делает прозрачным не только итоговый ответ, но и сам процесс его построения.
Дисклеймер: Я не разработчик. Всё, о чём здесь написано, мой практический опыт работы с языковыми моделями. Это личный метод, который показал результат.
Роль как ограничитель. Когда промт задаёт роль («ты - эксперт»), модель усиливает вероятностные ассоциации с этой ролью. Как правило, это работает в прикладных задачах, но в исследовательских и творческих случаях я часто упиралась в ограничение среднестатистического ответа по области, задаваемой ролью и потерю кросс-дисциплинарных связей.
Инструкция как стратегия. Если инструкция описывает как решить задачу, модель склонна следовать этому методу, даже если он не оптимален или не представлен в корпусах обучения. Это увеличивает риск ошибок или «галлюцинаций».
Неточность входных данных. Если задать неполный контекст, модель будет «додумывать» пропуски. Это часто ведёт к фактическим ошибкам.
Отсутствие метрик успеха. В обычной структуре промта часто нет встроенных критериев, как ответ должен проверяться и на чем нужно основывать его вывод. Результат оценивается уже после генерации.
Вместо роли я предлагаю задавать логику - правила, по которым модель должна строить рассуждения, какие можно делать допущения и где можно использовать альтернативные рассуждения. Это смещает фокус с «ответ в заданном стиле» на «устойчивое построение обоснованных цепочек рассуждений» и помогает именно исследовать вопрос, а не просто выдавать наиболее вероятный ответ.
Вместо инструкции «как делать» я пишу в промте только «что сделать»: модель получает цель и связи входов-выходов, но сама выбирает оптимальный маршрут решения. Так я получаю несколько вариантов вместе с их анализом.
Добавление метрик внутри промта (что считать успехом, какие пункты запроса проверить) позволяет встроить самопроверку прямо в процесс генерации. Модель сверяется с запросом и проверяет соответствие ответу.
Таким образом, предложенный подход нацелен дополнение классического алгоритма промтинга:
сохранить управляемость и предсказуемость;
снизить количество выдуманных деталей;
встроить критерии проверки;
понять, как именно ИИ пришёл к результату.
Смысл предлагаемой структуры промта в том, чтобы модель работала не только по «эталону ответа», но и по рамке мышления, которую пользователь задаёт в явном виде.
исходный материал: текст, код, описание области вопроса, собственные рассуждения.
важно задавать контекст полно. Но пользователь может раскрывать детали по ходу - этого достаточно, чтобы модель могла начать работать.
Пример: «Мне нужно отредактировать статью по промтингу. Давай сначала вспомним основные правила промтинга, что рекомендуют разработчики и какой вообще промтинг бывает. Посмотри самые актуальные советы и методы, а потом отредактируем мой текст.»
Такой запрос не содержит полного контекста (текст статьи ещё не предоставлен), но уже задаёт область, цель и структуру диалога. Модель получает рамку: обзор → уточнение → редактирование.
Примечание: совпадает с классическими практиками (контекст всегда важен), но отличается тем, что не требует «вспомнить всё» - промт может начинаться с области или черновых мыслей.
описание, в какой логике думать, какие допущения допустимы, какие альтернативы стоит рассмотреть.
заменяет «роль» на архитектурную рамку мышления.
Пример: «Строй рассуждение с маркировкой факта, гипотезы и идеи; допускай метафоры, но проверяй их на связность».
Примечание: такого блока обычно нет в классических рекомендациях, но он опирается на ветвление гипотез, когда важна непротиворечивость рассуждений.
постановка задачи в терминах цели, а не метода.
вместо «как делать» (например, «реши через метод Х») - «что должно быть на выходе» (например, «найди варианты решения уравнения и объясни шаги»).
Например, есть логическое утверждение А. Если напрямую указывать, как сделать, возможны ошибки:
«Докажи утверждение А» → модель выдаёт доказательство.
«Опровергни утверждение А» → та же модель на то же утверждение строит опровержение.
Проблема в том, что модель не анализирует корректность утверждения, а подстраивается под инструкцию «как делать» («докажи» или «опровергни»), подгоняя логику под условие.
Пример: «Сформулируй возможные подходы к проверке утверждения «А». Рассмотри и покажи варианты доказательства, опровержения или альтернативной трактовки. Сравни и предложи наиболее обоснованный вариант.»
Примечание: модель перестаёт подгонять ответ под формулировку («докажи» / «опровергни») и вместо этого анализирует поле вариантов и связи между ними.
заранее заданные критерии проверки ответа на корректность, непротиворечивость и полезность.
Пример: «Ответ должен содержать маркировку: факт, гипотеза, идея. Обязательно проверь логику построения ответа - нет ли логических противоречий или логической подмены».
привести несколько примеров, указать на поиск функционального сходства в них;
показывать ИИ не только стиль ответа, но и пример логики (в том числе метафорический), чтобы задать траекторию reasoning.
Нюанс: потоковый пример в творческих и исследовательских областях.
Иногда я включаю в промт свой «поток сознания»: хаотичные рассуждения, ассоциации из разных дисциплин, даже намеренно ошибочные шаги и их опровержение. Модель анализирует этот поток как пример логики и собирает его в связную структуру. Помогает найти мои заблуждения в вопросе, получает рамку логики, в которой я думаю и учитывает её в дальнейшей генерации ответов.
Примечание: Такой формат показывает модели не готовый ответ, а динамику мышления пользователя. В ответе ИИ отбирает логически обоснованные цепочки, проверяет их на связность и отбрасывает шум. В результате рождаются неожиданные логические ходы и рабочие гипотезы, которые в классической пошаговой схеме не появляются.
Контекст не обязан быть полным с первого шага. Пользователь может давать сырые или сомнительные соображения в привычном формате; задача модели - проверить факты и логику, выделить гипотезы, задать уточнения.
Совместная итеративность. Архитектурный промт предполагает цикл:
Пользователь задаёт исходный запрос.
Модель формирует предварительный ответ с указанием пробелов и гипотез.
Пользователь уточняет, ставит акценты, добавляет мысли.
Модель дорабатывает ответ, опираясь на уточнённый контекст.
Оптимальная глубина. По практическим наблюдениям, 2–4 повторения такого взаимодействия дают наилучший результат: ответ становится точным, связным и содержит меньше «галлюцинаций».
Избежание избыточности. Метод нацелен на быстрое достижение устойчивой логики, а не на бесконечные переписки.
Устойчивость к неполному контексту: модель знает, в какой логике достраивать ответ. Даже если контекст не полный, появляются интересные гипотезы, которые в дальнейшем можно проверить или развить.
Гибкость: модель ищет альтернативы.
Прозрачность: встроенная метрика показывает, как строился ответ.
Расширяемость: можно комбинировать с классическими форматами.
Классическая структура промта чаще предполагает статичную модель взаимодействия: пользователь задал вопрос - модель дала ответ. Я предпочитаю рассматривать запросы, как процесс согласования логики между пользователем и моделью. Итеративность становится встроенной частью метода, а не внешней практикой «править промт вручную».
Элемент | Классический промтинг | Архитектурный промтинг | Дополнение / отличие: | Метрики: |
---|---|---|---|---|
Контекст | Вводятся данные задачи; предполагается, что пользователь старается быть максимально точным. | Контекст может быть неполным: пользователь включает и свои соображения, даже если не уверен; модель проверяет их и задаёт уточняющие вопросы. | Расширение: снимает требование «идеальной полноты» и вводит диалоговую проверку. | Число уточнений от модели; снижение частоты ошибок из-за неполного контекста. |
Роль / Логика | Роль («ты эксперт…») задаёт стиль и тональность, но может ограничивать пространство поиска. | Роль заменяется на Логику: «в какой логике рассуждать, какие допущения допустимы, где искать альтернативы». | Смещение от стилистического ограничения → к управлению рассуждений модели. | Проверка на соответствие запросу; количество найденных альтернативных решений. |
Инструкция | «Что сделать» часто совмещается с «как сделать». | Фокус на «что сделать». Модель сама оптимизирует маршрут. | Расширение: снижает риск «навязанной стратегии». | Доля решений без методологической ошибки; экспертная оценка глубины ответа. |
Ограничения и формат | Чётко задаются: длина, стиль, язык, таблицы. | Используются при необходимости, но не как главный элемент. Важнее проверка когерентности. | Совместимость: формат остаётся, но не подавляет логику. | Соответствие формату при сохранении глубины. |
Пример | One-shot/few-shot: показывает формат. Работает как in-context learning. | Пример также может задавать траекторию логики (включая метафорические аналоги). | Пример = логика связей между решениями, а не только образец формата. | Понимание пользователем логики; снижение ошибок структуры. |
Метрика (что считать успехом) | Обычно отсутствует, успех = «ответ получен». | Явно задаётся: критерии корректности, непротиворечивости, полезности. | встроенная система самопроверки | Кол-во логических ошибок; прозрачность reasoning |
Характер взаимодействия | Статичен: «вопрос → ответ». | Динамичен: 2-4 итерации уточнений и доработки дают устойчивый результат. | Встроенная итеративность без избыточности. | Среднее число итераций до точного ответа; качество ответа по оценке пользователя. |
Классический промтинг остаётся оптимальным для прикладных задач, где важны скорость и предсказуемость.
Архитектурный промтинг расширяет возможности в исследовательских и творческих сценариях: он усиливает прозрачность reasoning, снижает риск «галлюцинаций» и делает процесс диалоговым.
Вместе оба подхода формируют гибкость методов: от формата → к архитектуре мышления, которую можно масштабировать под разные задачи
Пользователь может формулировать запросы привычным для себя языком
Ситуация.
Задача ставится не «сразу написать статью» и не вместо пользователя, а поэтапно: сначала вспомнить структуру классического промта, затем обсудить план, после этого последовательно прорабатывать введение, обзор, таблицы и кейсы. Каждый раздел рассматривается как отдельная задача.
Ход работы.
На старте задается общая рамка рассуждений и черновые мысли.
Каждый блок обсуждается и дорабатывается отдельно.
Пользователь вносит уточнения.
Модель адаптирует логику на каждом шаге, сохраняя общую структуру и непрерывность смысла.
Итоговая логика текста собирается пошагово, без перегрузки.
Плюсы для пользователя:
Не нужно готовить громоздкий промт «сразу обо всём».
Каждый блок можно уточнять по ходу работы.
Формулировки и акценты корректируются естественно, в процессе диалога-обсуждения.
Плюсы для модели:
Итеративность снижает риск ошибок: уточнения сразу встроены в ход reasoning.
Общая структура известна заранее, детали раскрываются постепенно.
Важные элементы не теряются, как в длинных статичных промтах.
Корректировки встроить проще - они идут модульно.
Результат.
После 2–3 итераций каждый блок написан пользователем согласованно. В итоге получена статья без перегрузки контекста, с помощью ИИ, а не вместо пользователя.
Ситуация.
Нужна простая утилита для Obsidian: конвертировать заметку .md в формат, понимаемый текстовыми редакторами типа Word/LibraOffice, чтобы удобно открывать её в том числе на планшетах. Пользователь - не разработчик, поэтому решение должно быть максимально простым в установке и использовании.
Почему «одним промтом» не сработает.
Запрос вида «напиши плагин» заставляет модель просто сгенерировать код «по вероятности». Проверки среды, сборки и критериев приёмки нет - и результат почти всегда ломается. Архитектурный промт, задаёт рамку: сначала план и критерии, потом шаги реализации, с обязательной самопроверкой и уточнениями по ходу.
1. Контекст.
На вход подаётся задача и ограничения: «Obsidian (Win/macOS), выбрать вариант конвертера, минимальная установка, выбор места сохранения файла». Этого достаточно, чтобы очертить цель и условия.
2. Логика.
Сначала модель уточняет параметры окружения: структура плагина, сборка, API Obsidian. Затем предлагает план из 5–7 шагов и критерии приёмки для каждого.
3. Инструкция.
Шаг A: создать каркас плагина с пустой командой. Критерий: плагин загружается.
Шаг B: минимальный экспорт — генерируется .rtf с простым текстом. Критерий: файл создаётся.
Шаг C: поддержка Markdown-разметки (заголовки, жирный/курсив, списки), настройка каталога вывода, лог ошибок.
4. Метрики.
M1: плагин включается без ошибок.
M2: файл .rtf создаётся.
M3: базовая разметка сохраняется.
M4: цель достигается за несколько шагов уточнений.
5. Пример.
Загружен на анализ известный плагин конвертации в HTML.
Итеративность.
Итерация 1: анализ окружения и нюансов + скелет.
Итерация 2: рабочая команда + минимальный RTF.
Итерация 3-4: добавление настроек + лог.
На каждом шаге пользователь тестировал плагин, а модель корректировала код по обратной связи.
Через 4 итерации получился стабильный плагин, проверенный в работе. Количество ошибок и «галлюцинаций» оказалось минимальным: каждое решение проверялось по критериям и уточнялось в процессе, а не в виде одного готового ответа.
Плагин доступен на GitHub. Не идеален, но функцию выполняет.
Предлагаемая структура запроса не освободит от работы над текстом или логикой проекта. В любом случае потребуется четкое понимание, что именно должно получиться и по каким критериям оценивать результат. Архитектурный промт - это не «волшебная команда», а метод взаимодействия с ИИ, который позволяет ему эмулировать поэтапный подход с регулярной проверкой и корректировкой сообразно задаче.