За последнее время большие языковые модели (LLM) стали привычным инструментом для анализа и работы с текстом. Но, что важно, качество ответа зависит не только от самой модели, но и от того, как именно задан запрос.
Обычно промт строят по проверенной схеме: задать роль («представь, что ты эксперт»), дать инструкцию, что и как сделать («сделай краткое резюме»), указать ограничения и уточнить формат (объём, стиль, язык), добавить входные данные и, если есть, пример ответа.
Однако, такой подход не всегда дает нужный ответ в творческих задачах. Заданная «роль» сужает поиск решений; инструкция «как сделать», может навязывать неоптимальный метод или ограничивать варианты поиска более подходящих. А неполное описание задачи (даже то, что кажется очевидным) нередко вынуждает модель придумывать и выдавать галлюцинации.
Цель этой статьи-размышления - предложить альтернативную структуру архитектурного промта, которая не заменяет, а расширяет и дополняет существующие практики. Я попробую показать, как можно сместить акцент с «роли» на логику рассуждений, и добавить метрики - критерии корректности ответа. Такой подход делает прозрачным не только итоговый ответ, но и сам процесс его построения.
Дисклеймер: Я не разработчик. Всё, о чём здесь написано, мой практический опыт работы с языковыми моделями. Это личный метод, который показал результат.
1. Мотивация для расширения
1.1. Ограничения классических практик
Роль как ограничитель. Когда промт задаёт роль («ты — эксперт»), модель усиливает вероятностные ассоциации с этой ролью. Как правило, это работает в прикладных задачах, но в исследовательских и творческих случаях я часто упиралась в ограничение среднестатистического ответа по области, задаваемой ролью и потерю кросс‑дисциплинарных связей.
Инструкция как стратегия. Если инструкция описывает как решить задачу, модель склонна следовать этому методу, даже если он не оптимален или не представлен в корпусах обучения. Это увеличивает риск ошибок или «галлюцинаций».
Неточность входных данных. Если задать неполный контекст, модель будет «додумывать» пропуски. Это часто ведёт к фактическим ошибкам.
Отсутствие метрик успеха. В обычной структуре промта часто нет встроенных критериев, как ответ должен проверяться и на чем нужно основывать его вывод. Результат оценивается уже после генерации.
1.2. Логика предлагаемого расширения
Вместо роли я предлагаю задавать логику — правила, по которым модель должна строить рассуждения, какие можно делать допущения и где можно использовать альтернативные рассуждения. Это смещает фокус с «ответ в заданном стиле» на «устойчивое построение обоснованных цепочек рассуждений» и помогает именно исследовать вопрос, а не просто выдавать наиболее вероятный ответ.
Вместо инструкции «как делать» я пишу в промте только «что сделать»: модель получает цель и связи входов‑выходов, но сама выбирает оптимальный маршрут решения. Так я получаю несколько вариантов вместе с их анализом.
Добавление метрик внутри промта (что считать успехом, какие пункты запроса проверить) позволяет встроить самопроверку прямо в процесс генерации. Модель сверяется с запросом и проверяет соответствие ответу.
Таким образом, предложенный подход нацелен дополнение классического алгоритма промтинга:
сохранить управляемость и предсказуемость;
снизить количество выдуманных деталей;
встроить критерии проверки;
понять, как именно ИИ пришёл к результату.
2. Предлагаемая структура промта
2.1. Общая идея и элементы структуры
Смысл предлагаемой структуры промта в том, чтобы модель работала не только по «эталону ответа», но и по рамке мышления, которую пользователь задаёт в явном виде.
1. Контекст (входные данные)
исходный материал: текст, код, описание области вопроса, собственные рассуждения.
важно задавать контекст полно. Но пользователь может раскрывать детали по ходу - этого достаточно, чтобы модель могла начать работать.
Пример: «Мне нужно отредактировать статью по промтингу. Давай сначала вспомним основные правила промтинга, что рекомендуют разработчики и какой вообще промтинг бывает. Посмотри самые актуальные советы и методы, а потом отредактируем мой текст.»
Такой запрос не содержит полного контекста (текст статьи ещё не предоставлен), но уже задаёт область, цель и структуру диалога. Модель получает рамку: обзор → уточнение → редактирование.
Примечание: совпадает с классическими практиками (контекст всегда важен), но отличается тем, что не требует «вспомнить всё» — промт может начинаться с области или черновых мыслей.
2. Логика (правила обработки)
описание, в какой логике думать, какие допущения допустимы, какие альтернативы стоит рассмотреть.
заменяет «роль» на архитектурную рамку мышления.
Пример: «Строй рассуждение с маркировкой факта, гипотезы и идеи; допускай метафоры, но проверяй их на связность».
Примечание: такого блока обычно нет в классических рекомендациях, но он опирается на ветвление гипотез, когда важна непротиворечивость рассуждений.
3. Инструкция (что сделать)
постановка задачи в терминах цели, а не метода.
вместо «как делать» (например, «реши через метод Х») - «что должно быть на выходе» (например, «найди варианты решения уравнения и объясни шаги»).
Например, есть логическое утверждение А. Если напрямую указывать, как сделать, возможны ошибки:
«Докажи утверждение А» → модель выдаёт доказательство.
«Опровергни утверждение А» → та же модель на то же утверждение строит опровержение.
Проблема в том, что модель не анализирует корректность утверждения, а подстраивается под инструкцию «как делать» («докажи» или «опровергни»), подгоняя логику под условие.
Пример: «Сформулируй возможные подходы к проверке утверждения «А». Рассмотри и покажи варианты доказательства, опровержения или альтернативной трактовки. Сравни и предложи наиболее обоснованный вариант.»
Примечание: модель перестаёт подгонять ответ под формулировку («докажи» / «опровергни») и вместо этого анализирует поле вариантов и связи между ними.
4. Метрика (критерии успеха)
заранее заданные критерии проверки ответа на корректность, непротиворечивость и полезность.
Пример: «Ответ должен содержать маркировку: факт, гипотеза, идея. Обязательно проверь логику построения ответа - нет ли логических противоречий или логической подмены».
5. Примеры логики построения ответа
привести несколько примеров, указать на поиск функционального сходства в них;
показывать ИИ не только стиль ответа, но и пример логики (в том числе метафорический), чтобы задать траекторию reasoning.
Нюанс: потоковый пример в творческих и исследовательских областях.
Иногда я включаю в промт свой «поток сознания»: хаотичные рассуждения, ассоциации из разных дисциплин, даже намеренно ошибочные шаги и их опровержение. Модель анализирует этот поток как пример логики и собирает его в связную структуру. Помогает найти мои заблуждения в вопросе, получает рамку логики, в которой я думаю и учитывает её в дальнейшей генерации ответов.
Примечание: Такой формат показывает модели не готовый ответ, а динамику мышления пользователя. В ответе ИИ отбирает логически обоснованные цепочки, проверяет их на связность и отбрасывает шум. В результате рождаются неожиданные логические ходы и рабочие гипотезы, которые в классической пошаговой схеме не появляются.
2.2. Динамический характер архитектурного промта
Контекст не обязан быть полным с первого шага. Пользователь может давать сырые или сомнительные соображения в привычном формате; задача модели - проверить факты и логику, выделить гипотезы, задать уточнения.
Совместная итеративность. Архитектурный промт предполагает цикл:
Пользователь задаёт исходный запрос.
Модель формирует предварительный ответ с указанием пробелов и гипотез.
Пользователь уточняет, ставит акценты, добавляет мысли.
Модель дорабатывает ответ, опираясь на уточнённый контекст.
Оптимальная глубина. По практическим наблюдениям, 2–4 повторения такого взаимодействия дают наилучший результат: ответ становится точным, связным и содержит меньше «галлюцинаций».
Избежание избыточности. Метод нацелен на быстрое достижение устойчивой логики, а не на бесконечные переписки.
2.3. Чем полезно:
Устойчивость к неполному контексту: модель знает, в какой логике достраивать ответ. Даже если контекст не полный, появляются интересные гипотезы, которые в дальнейшем можно проверить или развить.
Гибкость: модель ищет альтернативы.
Прозрачность: встроенная метрика показывает, как строился ответ.
Расширяемость: можно комбинировать с классическими форматами.
Классическая структура промта чаще предполагает статичную модель взаимодействия: пользователь задал вопрос — модель дала ответ. Я предпочитаю рассматривать запросы, как процесс согласования логики между пользователем и моделью. Итеративность становится встроенной частью метода, а не внешней практикой «править промт вручную».
3. Отличие и взаимодополняемость подходов
Элемент | Классический промтинг | Архитектурный промтинг | Дополнение / отличие: | Метрики: |
|---|---|---|---|---|
Контекст | Вводятся данные задачи; предполагается, что пользователь старается быть максимально точным. | Контекст может быть неполным: пользователь включает и свои соображения, даже если не уверен; модель проверяет их и задаёт уточняющие вопросы. | Расширение: снимает требование «идеальной полноты» и вводит диалоговую проверку. | Число уточнений от модели; снижение частоты ошибок из-за неполного контекста. |
Роль / Логика | Роль («ты эксперт…») задаёт стиль и тональность, но может ограничивать пространство поиска. | Роль заменяется на Логику: «в какой логике рассуждать, какие допущения допустимы, где искать альтернативы». | Смещение от стилистического ограничения → к управлению рассуждений модели. | Проверка на соответствие запросу; количество найденных альтернативных решений. |
Инструкция | «Что сделать» часто совмещается с «как сделать». | Фокус на «что сделать». Модель сама оптимизирует маршрут. | Расширение: снижает риск «навязанной стратегии». | Доля решений без методологической ошибки; экспертная оценка глубины ответа. |
Ограничения и формат | Чётко задаются: длина, стиль, язык, таблицы. | Используются при необходимости, но не как главный элемент. Важнее проверка когерентности. | Совместимость: формат остаётся, но не подавляет логику. | Соответствие формату при сохранении глубины. |
Пример | One-shot/few-shot: показывает формат. Работает как in-context learning. | Пример также может задавать траекторию логики (включая метафорические аналоги). | Пример = логика связей между решениями, а не только образец формата. | Понимание пользователем логики; снижение ошибок структуры. |
Метрика (что считать успехом) | Обычно отсутствует, успех = «ответ получен». | Явно задаётся: критерии корректности, непротиворечивости, полезности. | встроенная система самопроверки | Кол-во логических ошибок; прозрачность reasoning |
Характер взаимодействия | Статичен: «вопрос → ответ». | Динамичен: 2-4 итерации уточнений и доработки дают устойчивый результат. | Встроенная итеративность без избыточности. | Среднее число итераций до точного ответа; качество ответа по оценке пользователя. |
Общие выводы
Классический промтинг остаётся оптимальным для прикладных задач, где важны скорость и предсказуемость.
Архитектурный промтинг расширяет возможности в исследовательских и творческих сценариях: он усиливает прозрачность reasoning, снижает риск «галлюцинаций» и делает процесс диалоговым.
Вместе оба подхода формируют гибкость методов: от формата → к архитектуре мышления, которую можно масштабировать под разные задачи
Пользователь может формулировать запросы привычным для себя языком
Примеры использования
Пример 1. Совместное написание текущей статьи
Ситуация
Задача ставится не «сразу написать статью» и не вместо пользователя, а поэтапно: сначала вспомнить структуру классического промта, затем обсудить план, после этого последовательно прорабатывать введение, обзор, таблицы и кейсы. Каждый раздел рассматривается как отдельная задача.
Ход работы
На старте задается общая рамка рассуждений и черновые мысли.
Каждый блок обсуждается и дорабатывается отдельно.
Пользователь вносит уточнения.
Модель адаптирует логику на каждом шаге, сохраняя общую структуру и непрерывность смысла.
Итоговая логика текста собирается пошагово, без перегрузки.
Плюсы для пользователя:
Не нужно готовить громоздкий промт «сразу обо всём».
Каждый блок можно уточнять по ходу работы.
Формулировки и акценты корректируются естественно, в процессе диалога-обсуждения.
Плюсы для модели:
Итеративность снижает риск ошибок: уточнения сразу встроены в ход reasoning.
Общая структура известна заранее, детали раскрываются постепенно.
Важные элементы не теряются, как в длинных статичных промтах.
Корректировки встроить проще - они идут модульно.
Результат
После 2–3 итераций каждый блок написан пользователем согласованно. В итоге получена статья без перегрузки контекста, с помощью ИИ, а не вместо пользователя.
Пример 2. Разработка плагина Obsidian (Markdown → RTF) архитектурным промтом
Ситуация
Нужна простая утилита для 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. Не идеален, но функцию выполняет.
Предлагаемая структура запроса не освободит от работы над текстом или логикой проекта. В любом случае потребуется четкое понимание, что именно должно получиться и по каким критериям оценивать результат. Архитектурный промт - это не «волшебная команда», а метод взаимодействия с ИИ, который позволяет ему эмулировать поэтапный подход с регулярной проверкой и корректировкой сообразно задаче.