«Разница не в возможностях модели, а в том, как вы формулируете запрос»: AWS выпустила двухчастное руководство по промптам в Amazon Quick

Две части одной серии

Материал вышел 29 сентября 2026 года в блоге AWS Machine Learning в категории Amazon Quick Suite — Best Practices, с уровнем Intermediate (200), и подписан четырьмя авторами AWS: Daiquan Nkere, Dalien Ahiekpor, Vishnu Elangovan и Praney Mahajan. Первая часть посвящена универсальным принципам и многоразовым фреймворкам, которые работают независимо от того, каким компонентом Quick пользуется команда, вторая — приёмам под конкретные компоненты: Research, Flows, Sight, Chat Agents и Action Integrations. Логика серии простая: сначала общая грамматика промпта, потом диалекты отдельных компонентов.

Промпт-инжиниринг в Amazon Quick определяет, насколько точно и надёжно платформенные ИИ-функции отвечают на запросы на естественном языке — идёт ли речь о сборке собственных агентов, описании автоматизаций или разговорной аналитике данных.

Часть 1: конкретика, контекст и CRISPE

Базовые принципы первой части AWS называет грамматикой промпт-инжиниринга: конкретика вместо общих слов, контекст, который задаёт глубину анализа и формат рекомендаций, и обучение на примере, когда нужную структуру вывода не описывают словами, а показывают образцом. Вместо «покажи данные о продажах» в посте предлагается запрос о помесячной выручке подразделения корпоративного ПО за Q3–Q4 2025 года с тремя самыми быстрорастущими продуктовыми линиями и проверкой связи с запуском маркетинговой кампании: каждое добавленное уточнение убирает допущение, которое модель сделала бы сама.

Для сложных корпоративных задач предлагается CRISPE — шаблон из шести элементов: контекст и ограничения, роль и ответственность, намерение и входные данные, шаги и охват, перспектива и форма подачи, критерии оценки. Рядом AWS описывает три специализированных фреймворка: RADAR для поиска по пространствам знаний, где запрос собирают из стратегии извлечения, подхода к анализу, целевых документов, формирования ответа и прозрачности рассуждений; ARCHITECT для сборки чат-агентов, где каждый элемент напрямую ложится на поле в конструкторе агента Quick; и QUEST для сложных вопросов к агентам.

Дальше идут приёмы для случаев, когда простые промпты перестают работать: метаданные в запросе (указать документ по имени, расшифровать внутренние аббревиатуры, назвать конкретные пространства), многоракурсный анализ с финансовой, операционной и стратегической точек зрения и сценарное планирование с тремя-четырьмя именованными сценариями, у каждого из которых есть допущения, последствия, нужные действия и ранние признаки.

Показательный кейс серии — обработка RFI-анкет: многостраничные Excel с неоднородным форматированием превращаются в структурированный CSV, подвопросы склеиваются с контекстом родительского вопроса, формулировки и метаданные сохраняются дословно. Ручная работа над такой книгой обычно занимает часы, автоматизация укладывается в минуты.

Эффективность промптов AWS предлагает измерять по пяти измерениям — точность, согласованность, полнота, число итераций до результата и удобство для команды, то есть возможность переиспользовать и поправить промпт, не объясняя контекст заново, — и замыкать цикл практиками: библиотека удачных шаблонов, разбор неудач, обратная связь пользователей, метрики и регулярный пересмотр критичных промптов.

Часть 2: у каждого компонента свой язык

Вторая часть построена по компонентам. Quick Research требует не поискового запроса, а цели исследования: агент сам разбивает её на подтемы и собирает структурированный отчёт со ссылками, а набор источников выбирается вручную — корпоративные данные через Quick Index, более 200 доверенных новостных изданий и премиальные наборы данных от S&P Global, FactSet, IDC, патентных данных США и PubMed. AWS советует сужать набор источников: конкурентному анализу не нужен PubMed, а клиническому обзору литературы — новостные статьи.

Quick Flows превращает описание словами в рабочий процесс, поэтому все детали запроса становятся шагами: вместо общих «сделай отчёт по продажам» в посте предлагается «каждый понедельник в 8:00 выгрузить продажи прошлой недели из CRM, посчитать общую выручку и топ-10 товаров по штукам, собрать одностраничный PDF и отправить его списку sales-managers». Логику из трёх и более операций советуют писать нумерованными шагами: Flows поддерживает условия, циклы и пользовательский ввод, а нумерация совпадает с внутренней структурой шагов и упрощает отладку. Достраивать процесс можно разговором с агентом, а не переписыванием промпта целиком.

Quick Sight ждёт от запроса шесть элементов: бизнес-вопрос, метрики, измерения, период, тип визуализации и дополнительный анализ вроде трендовой линии или порогов. Пропуск любого из них заставляет систему угадывать и выдаёт технически корректную, но бесполезную картинку; типовые шаблоны AWS показывает на временных рядах, сравнениях, связях, распределениях и гео-данных. Вычисляемые поля вроде «Customer Health Score» из вероятности продления, динамики использования и частоты обращений задаются обычным текстом — с весами 40, 35 и 25 процентов и шкалой от 0 до 100.

Для чат-агентов ключевое поле — идентичность в Builder Mode: роль, экспертиза и границы, например «отвечай только на вопросы об оптимизации облачных затрат, по остальным подскажи нужную команду». Пробел в знаниях закрывается не догадкой, а явной инструкцией на случай, когда уверенного ответа нет; привязка к пространствам знаний подбирается по роли, потому что агент, подключённый ко всем Quick Spaces организации, начнёт выдавать нерелевантные ответы. Рекомендуемые промпты на стартовом экране AWS советует делать конкретными: они задают привычку пользователей формулировать запрос.

Для действий во внешних системах — Jira, Slack, Confluence и Salesforce — нужен полный набор параметров, явная последовательность шагов и указание, чей результат идёт на вход следующему шагу. Отдельная рекомендация — для разрушительных и массовых операций встраивать в промпт шаг проверки: сначала отчёт, потом действие после явного подтверждения, и делать это в самом промпте, а не полагаться только на системные ограничения.

Что AWS считает типичными ошибками

Общий список невелик: размытые формулировки, перегруженный требованиями одиночный запрос, приписанный модели контекст, которого у неё нет, отсутствие формата вывода, тесты без реалистичных крайних случаев и не задокументированные удачные шаблоны. Дальше ошибки расходятся по компонентам: в Research — поисковые запросы вместо целей исследования, отсутствие аудитории и пропущенная проверка плана; во Flows — перегруженный промпт, неописанные пользовательские входы и молчание о сбоях; в Sight — метрики без агрегации, потерянный контекст времени и неоднозначные измерения; у чат-агентов — размытая идентичность, устаревшие Spaces, отсутствие инструкции на случай незнания и запуск без теста в Preview; у интеграций — неполные параметры, неясные зависимости и пропущенный шаг проверки.

План на четыре недели

Внедрять практику AWS предлагает фазами: на первой неделе выбрать три самых частых сценария и переписать существующие промпты по CRISPE, зафиксировав результат «до и после»; на второй — взять один компонент и довести его шаблоны до многоразовых; на третьей — включить метаданные в поиск, собрать агента по ARCHITECT и построить поток с условной логикой; на четвёртой — вынести удачные промпты в общую библиотеку, обучить команду и настроить обратную связь. Вывод авторов: организации выигрывают не за счёт самой сложной технологии, а за счёт умения с ней разговаривать.