Запрос к искусственному интеллекту предлагают рассматривать как техническое задание: с контекстом, измеримой целью, ограничениями и заранее определенным форматом ответа. Такой подход описан в работе об архитектуре инструкций для больших языковых моделей, опубликованной 30 октября в журнале Acta Innovations. Для компаний практический вопрос заключается не в поиске одной удачной формулировки, а в том, как получать результат, который можно проверить и повторно использовать.
Работа объединяет приемы проектирования промптов, организации многоэтапных задач и оценки ответов. В центре предложенной схемы находится CORE: Context, Objective, Restrictions и Expected Output. Это четыре обязательных элемента задания, а не специальная команда, которая сама по себе повышает точность любой модели.
Практическая ценность подхода определяется тем, позволяет ли он сократить число ошибок, время проверки и затраты на выполнение задачи. Оценивать его эффективность необходимо на конкретных рабочих процессах: убедительный ответ в отдельном диалоге еще не свидетельствует о надежности системы.
От короткого запроса к спецификации задачи
Команды вроде «подготовь анализ рынка» оставляют модели слишком много решений: какой рынок исследовать, за какой период, на основании каких данных и для какой аудитории. Полученный текст может выглядеть убедительно, но не отвечать задаче заказчика. Если критерии качества появились только после чтения ответа, проверить результат последовательно будет трудно.
Авторы предлагают задавать структуру заранее: роль, задачу, контекст, ограничения, формат результата и критерии оценки. Роль определяет профессиональный ракурс и стиль, контекст задает исходные условия, а ограничения фиксируют допустимые действия. Критерии оценки нужны, чтобы отделять корректно выполненную работу от просто хорошо написанного текста.
Такое разделение особенно важно в повторяющихся процессах: обработке документов, подготовке отчетов, разработке программ и редакционной работе. Вместо нового запроса с нуля компания получает шаблон, в котором меняются входные данные, но сохраняются требования к результату.
CORE: четыре элемента управляемого задания
В статье CORE представлен как минимальный контрольный список. Его ценность заключается в явном описании условий работы. Одного указания «будь точным» недостаточно: нужно определить, какие данные разрешено использовать и что делать, когда их не хватает.
| Элемент | Что необходимо задать | Пример для деловой редакции |
|---|---|---|
| C: Context, контекст | Исходные данные, обстоятельства и допущения. | Официальный статистический релиз, отчетный период, единицы измерения и аудитория материала. |
| O: Objective, цель | Конкретный результат, который требуется получить. | Объяснить изменение показателя и его значение для бизнеса, не выходя за пределы доступных данных. |
| R: Restrictions, ограничения | Запреты, границы и правила работы с неопределенностью. | Не придумывать причины, цитаты и отсутствующие значения; не сравнивать несопоставимые периоды. |
| E: Expected Output, ожидаемый результат | Структуру, глубину и стиль ответа. | Заголовок, краткий вводный абзац, таблицу фактов, объяснение динамики и перечень вопросов для проверки. |
Для внедрения этого подхода не требуется менять языковую модель. Но потребуется описать сам рабочий процесс. Если у команды нет согласованных правил расчета, проверки источников и приемки результата, промпт не сможет заменить эти правила.
Практический пример: новость по статистическому релизу
Рассмотрим условное задание редакции. Это пример FinFly, а не эксперимент или результат измерений из исследования. Короткая версия запроса могла бы звучать так: «Напиши новость о росте зарплат». Она не определяет ни источник, ни период, ни способ сравнения.
Более содержательная инструкция может выглядеть следующим образом:
Подготовь деловую новость по приложенному официальному релизу и таблице за сопоставимый прошлый период. Аудитория: предприниматели и наемные работники Азербайджана. Сначала выдели подтвержденные значения, отчетные периоды и единицы измерения. Сравни показатели только при совпадении их определений и охвата. Не смешивай среднемесячную зарплату за январь-август с зарплатой только за август. Отдели номинальное изменение от изменения покупательной способности. Если подходящего индекса цен или предыдущего значения нет, прямо укажи, что соответствующий вывод сделать нельзя. Верни заголовок, вводный абзац, таблицу фактов и короткое объяснение с обозначенными ограничениями. Для каждой цифры укажи место в приложенном документе.
Здесь меняется не только объем запроса. Инструкция задает проверяемые условия: сопоставимость периодов, происхождение чисел и порядок действий при нехватке информации. Редактор получает основания для проверки, а не только готовый текст.
При этом даже такой ответ остается черновиком. Ссылки на страницы, арифметику и трактовку показателей нужно сверять с оригиналом. Требование привести источник не гарантирует, что модель указала его правильно.
Сложную работу лучше разделять на проверяемые этапы
Еще одна линия статьи касается декомпозиции: вместо одного большого задания предлагается последовательность связанных операций. Для редакционного процесса это могут быть извлечение фактов, проверка сопоставимости, подготовка текста и финальная сверка. Каждому этапу соответствует отдельный результат, который можно проверить до продолжения работы.
Такой процесс полезен там, где ранняя ошибка переходит в итоговый вывод. Если модель неверно прочитала единицы измерения, последующее улучшение стиля не исправит расчет. Промежуточная таблица позволяет заметить проблему до появления полноценной публикации.
Не стоит путать проверяемые промежуточные результаты с обещанием доступа ко всему внутреннему рассуждению модели. Для контроля нужны исходные значения, формулы, допущения и основания вывода. Подробное объяснение само по себе не подтверждает истинность ответа.
Роль и примеры помогают задать формат, но не подтверждают компетентность
В работе рассматриваются ролевые инструкции и few-shot prompting: включение нескольких образцов желаемого ответа. Первая техника задает профессиональный ракурс, вторая показывает модель оформления и уровень детализации. Однако фраза «ты финансовый аналитик» не дает системе реальную квалификацию, доступ к свежей отчетности или право принимать решения.
С примерами действует похожее ограничение. Если образец содержит ошибочную логику, неподтвержденные выводы или неудачную структуру, модель может воспроизвести их. Для постоянного рабочего шаблона нужны проверенные и достаточно разнообразные примеры, а не просто наиболее эффектный ответ из предыдущего диалога.
Официальные рекомендации разработчиков моделей также делают акцент на ясных инструкциях, качественных примерах и проверке результата. Документация Google отдельно предупреждает, что избыточное количество примеров может привести к чрезмерной подстройке под них. В руководстве Anthropic предлагается сначала определить критерии успеха и способ их измерения. Эти документы дополняют практическую часть подхода, но не являются независимой проверкой именно CORE.
Как компании оценить пользу без рекламных обещаний
Для бизнеса важен не объем промпта, а изменение качества и стоимости процесса. Мы предлагаем проверять новый шаблон на наборе реальных задач, сохраняя одинаковые входные данные, версию модели и доступные инструменты. На части задач полезно выполнить несколько запусков, чтобы увидеть разброс результатов, а не выбрать один удачный ответ.
- Фактическая точность: сколько утверждений и чисел подтверждается входными материалами.
- Выполнение задания: соблюдены ли формат, обязательные поля и ограничения.
- Работа с пробелами: отмечает ли система отсутствие данных вместо их выдумывания.
- Затраты редактора или специалиста: сколько времени занимает проверка и исправление результата.
- Стоимость и скорость: сколько запросов требуется и какова итоговая цена выполнения задачи.
Последний пункт особенно важен для многоэтапных схем. Дополнительные проверки могут улучшить управляемость, но увеличивают число обращений к модели, задержку и расходы. Поэтому более длинный процесс не следует автоматически считать более эффективным.
Рабочие инструкции имеет смысл хранить с номером версии, назначением, тестовыми примерами и известными ограничениями. После смены модели, источников данных или требований тесты нужно повторять. Успех вчерашнего шаблона не подтверждает его пригодность для новой задачи.
Что работа подтверждает, а что остается гипотезой внедрения
Статья представляет методический обзор и систематизацию приемов. В ней нет описания единого контролируемого сравнительного испытания CORE, которое позволяло бы обещать конкретное снижение ошибок или экономию для любого бизнеса. Представленные рекомендации следует воспринимать как основу для настройки процесса и собственных тестов, а не как универсально доказанный стандарт.
Также промпт не заменяет актуальные данные, расчетный инструмент, защиту конфиденциальной информации или настройку прав доступа. Если ИИ подключен к отправке писем, публикации материалов или изменению записей в системе, ограничения должны обеспечиваться программно. Одного текстового запрета на нежелательное действие недостаточно.
Практический вывод для компаний: начинать стоит с описания задачи, допустимых источников и критериев приемки. CORE помогает собрать эти требования в одном месте. Решение о внедрении должно опираться на результаты проверки в конкретном процессе, включая ошибки, стоимость и необходимость участия человека.
Авторы оригинала и источники
Авторы исходной научной статьи: Kirill Patyrykin и Aleksey Dudkin. Instruction Architecture in Generative AI: A Framework for Prompt Engineering and Reasoning Control in Large Language Models. Acta Innovations, том 64, № 1s, страницы 1324-1335. Опубликовано 30 октября 2026 года. Страница публикации, DOI: 10.62441/actainnovations.vi.2839, полный текст PDF.
Публикация о работе в блоге Кирилла Патырыкина. Оригинальная статья распространяется по лицензии Creative Commons Attribution 4.0. Этот материал представляет собой самостоятельное русскоязычное изложение и адаптацию редакции FinFly с дополнительными пояснениями; это не дословный перевод. Практический пример и рекомендации по редакционной проверке подготовлены FinFly.
Дополнительные первоисточники: Google AI: Prompt design strategies; Anthropic: Define success criteria and build evaluations. Обложка: тематическая ИИ-иллюстрация из коллекции FinFly.
