Промпт-инжиниринг для аналитика

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

1. Суть темы

Промпт-инжиниринг в контексте работы системного аналитика — методическое конструирование запросов к LLM: что передать модели, в каком порядке, с какими ограничениями и примерами. Это не «умение красиво разговаривать с чатом», а управляемый интерфейс между вашим аналитическим мышлением и стохастическим генератором текста из 11.01 Введение в искусственный интеллект и LLM.

Граница темы: промпт-инжиниринг описывает формулировку одного или серии запросов к модели. Выбор архитектуры (RAG, агенты, on-prem), интеграция с Jira и 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence), настройка модели, работа с вложениями (PDF, скриншоты UI, диаграммы) — в соседних статьях раздела (11.04 Архитектуры использования LLM в корпоративном контуре, 11.05 Интеграция LLM с инструментами аналитика); здесь — как извлечь максимум из уже выбранного инструмента при текстовом входе.

Промпт vs RAG: достаточно промпта с вложенным глоссарием и фрагментами документов, когда контекст помещается в окно модели, источники известны на момент запроса и не нужен автоматический поиск по корпоративной базе. Переходите к 11.04 Архитектуры использования LLM в корпоративном контуре, когда документов много, они часто обновляются, нужна актуальная выборка из wiki/Confluence без ручной вставки или требуется трассировка «ответ → конкретный фрагмент базы знаний» на уровне архитектуры, а не одного запроса.

Эффективный промпт для задач требований опирается на три опоры. В систематическом обзоре PE4RE (Prompt Engineering for Requirements Engineering) их совместное использование на задачах извлечения и структурирования требований даёт примерно на 40% выше согласие с эталоном экспертов (expert agreement / F1) по сравнению с промптом, где явно задан только один из трёх элементов. Цифра зависит от типа задачи, модели и базы сравнения — это ориентир из литературы, а не SLA проекта; конкретные KPI пилота фиксируйте в 11.09 Мониторинг и оценка качества LLM-решений.

Три опоры CCC — логические группы, а не отдельный шаблон: Clarity раскладывается на «Роль и рамка» + «Задача» семи секций ниже; Context — на блок «Контекст»; Constraint — на «Ограничения», «Формат вывода» и «Проверочный блок» (см. блок «Структура промпта для RE-задач» в разделе 2).

flowchart LR
    A[Исходник: интервью, регламент, backlog] --> B[Промпт: clarity + context + constraint]
    B --> C[LLM]
    C --> D[Черновик артефакта]
    D --> E[Human-in-the-loop: V&V]
    E --> F[Утверждённый артефакт]

На схеме V&V — зонтичный этап 02.04.01 Верификация и валидация (V&V): внутри него — статическая проверка формулировок (08.03 Тестирование требований (статическое тестирование)), инспекция по чеклисту (08.04 Рецензирование и инспекции (техники Фейгана)) и сверка критериев приёмки (02.04.02 Критерии приёмки (Acceptance Criteria)). Промпт готовит черновик; финальное утверждение — за аналитиком.

Промпт-инжиниринг — итеративный процесс: первый ответ редко финален. На проекте фиксируйте рабочие шаблоны так же, как шаблоны артефактов из раздела 10.01 — с версией в 07.05 Системы контроля версий (Git) для документации или корпоративной wiki: это снижает разброс качества между аналитиками и сессиями.

2. Ключевые понятия

Базовые техники промптинга

Zero-shot prompting — запрос без примеров: вся необходимая информация в одном промпте. Подходит, когда формат стандартен и домен описан явно (например, первичная классификация комментариев из issue tracker по 02.03.01 Классификация требований (БТ, ФТ, НФТ)). Требует исключительно чётких инструкций: модель опирается только на общие паттерны обучения.

Few-shot prompting — 2–5 эталонных пар «вход → желаемый выход» внутри промпта. Демонстрирует формат, стиль и глубину ответа. Примеры берите из утверждённых артефактов текущего проекта (10.01.01 Шаблон User Story, 10.01.14 Шаблон глоссария и словаря данных) и явно ограничивайте: «не добавляй требований, которых нет во входном тексте» — иначе модель усреднит прошлые проекты и внесёт лишние формулировки.

Chain-of-Thought (CoT) — явная просьба показать шаги рассуждения перед итогом. Рекомендуется при декомпозиции сложных конфликтов требований, root cause analysis и в регуляторных сценариях, где ревьюеру нужно проверить логику. Для простой классификации по готовой таксономии CoT часто избыточен — достаточно zero-shot с чёткими критериями. CoT не заменяет 02.04.01 Верификация и валидация (V&V), но делает проверку возможной.

Role-based prompting — назначение модели профессиональной роли («старший инженер требований», «специалист по compliance»). Активирует релевантный тон и типичные рамки рассуждения; эффективен при обработке свободных комментариев стейкхолдеров, где нужен доменно уместный язык без подмены экспертизы живого специалиста.

Продвинутые техники — tree-of-thought (ветвление рассуждений) и ensemble refinement (несколько прогонов с агрегацией) дают более стабильные результаты на сложных регламентах, но требуют больше итераций и настройки. Для повседневной работы аналитика достаточно zero-/few-shot и CoT; сравнение восьми техник elicitation на модели O1 — в источниках (IDETC-CIE 2025); разбор продвинутых цепочек — в 11.07 Практические кейсы применения LLM в анализе.

Системный и пользовательский промпт

В корпоративных чатах часть инструкций задаётся системным (system / developer) промптом — политики безопасности, тон, запреты — и не видна пользователю. Ваш пользовательский промпт дополняет, но не отменяет системный. Для аудита и воспроизводимости фиксируйте оба слоя: скрытые инструкции влияют на результат так же, как явные. Детали корпоративного контура — 11.04 Архитектуры использования LLM в корпоративном контуре.

Параметры генерации

Temperature и top-p управляют разбросом ответа. Для RE-задач ориентир простой: низкая temperature (0–0,3) — извлечение, классификация, structured output, где нужна воспроизводимость; выше (0,5–0,8) — мозговой штурм гипотез, вариантов формулировок, но только с жёсткими negative constraints («не добавляй фактов вне источника»). Настройка модели под домен — 11.08 Выбор и настройка моделей для корпоративного использования; здесь достаточно зафиксировать значения в библиотеке шаблонов вместе с версией модели.

Структура промпта для RE-задач

Практичный каркас для повторяемых задач. Порядок секций имеет значение: при конфликте инструкций модель чаще следует тому, что ближе к концу промпта и few-shot-примерам. Рекомендуемая последовательность:

1. Роль и рамка — кто «говорит» модель и в каких границах ответственности.
2. Контекст — фрагменты документов, ссылки на источник, глоссарий (механика токенов и лимитов окна — 11.02 Теоретические основы обработки естественного языка; здесь — практика нарезки под RE).
3. Задача — один явный глагол: извлечь, классифицировать, сравнить, найти противоречия.
4. Ограничения (negative constraints) — что запрещено (выдумывать ID, предлагать архитектуру, смешивать БТ и ФТ).
5. Формат вывода — таблица, JSON по схеме, user story по 10.01.01 Шаблон User Story или 04.02 Пользовательские истории (User Stories) и Job Stories, критерии по 10.01.02 Шаблон Use Case и 02.04.02 Критерии приёмки (Acceptance Criteria).
6. Few-shot примеры — после ограничений, чтобы эталон не перебивал запреты.
7. Проверочный блок — «укажи неопределённости», «перечисли, на каком фрагменте источника основан каждый пункт».

Structured output (JSON mode, function calling, явная JSON Schema) надёжнее свободной «таблицы в markdown», когда выход идёт в инструменты (матрица трассировки, поля API). Для SA-артефактов задайте constraint по 10.01.04 Шаблон спецификации REST API или фрагменту схемы из 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) — модель заполнит поля, не перенося сюда содержание стандарта OpenAPI. Схему указывайте в constraint; при ошибке парсинга повторяйте запрос с указанием невалидного фрагмента.

Язык промпта и язык артефакта могут расходиться: интервью на русском → SRS на английском для международной команды. Явно укажите язык вывода в constraint; термины из 03.03.03 Словарь данных (описание) передайте как глоссарий «RU → EN».

Многоходовый диалог и chunking

Elicitation на проекте часто идёт цепочкой уточнений: первый ответ → вопросы → уточнение constraint → финальный синтез. Не полагайтесь на неявную «память» чата для аудита: после серии сообщений соберите consolidated prompt — системные инструкции + итоговый контекст + финальная задача — и сохраните его в библиотеке шаблонов вместе с ответом модели.

Большие наборы требований не помещаются в контекстное окно. Два рабочих приёма:

• Итеративная суммаризация — сжатие документа по слоям с сохранением решений, исключений и ссылок на разделы.
• Chunking с перекрытием — разбиение текста на фрагменты с overlap, чтобы не терять связи на границах; итоговый синтез — отдельным промптом с явным указанием, что выводы из разных chunk нужно сопоставить на противоречия.

Промпт-шаблоны как актив команды

Зрелый подход — библиотека валидированных шаблонов под типовые RE-задачи: «извлечение из протокола интервью», «разбор регуляторной оговорки», «черновик матрицы трассировки». Шаблон включает few-shot из ваших успешных артефактов, а не из интернета — так сохраняется корпоративный стиль и терминология. Версионируйте шаблоны параллельно шаблонам Confluence и артефактам в Git (07.05 Системы контроля версий (Git) для документации).

3. Как применяется в работе аналитика

Промпт-инжиниринг закрывает задачи на всех этапах, где вход — текст (или текстовое описание вложения), а выход — структурированный аналитический артефакт. Цифры из литературы и PE4RE ниже — ориентиры для пилота, не норматив проекта; методику замеров и доменные KPI — 11.09 Мониторинг и оценка качества LLM-решений, кейсы — 11.07 Практические кейсы применения LLM в анализе.

Сценарии генерации и ревью чужого артефакта разделяйте: для инспекции по 08.04 Рецензирование и инспекции (техники Фейгана) промпт задаёт чеклист замечаний и ссылки на источник, а не просит «улучшить текст».

Выявление и первичная спецификация

Из неструктурированной обратной связи (комментарии в Jira, протоколы 02.02.01 Интервьюирование и анкетирование, заметки 02.02.02 Воркшопы, фасилитация и совместные сессии) few-shot промпт с примерами вашего формата 02.03.03 Спецификация требований (SRS, Use Case, User Story) даёт черновик первого прохода. По обзору PE4RE на задачах elicitation отдельно фиксируют полноту (порядка 60–70% критичных элементов относительно экспертного эталона) и скорость (сокращение времени первичного разбора примерно вдвое при том же наборе документов) — это разные метрики из сопоставимых, но не одного эксперимента; не складывайте их в один «эффект LLM». Оставшиеся пробелы, неоднозначности и доменные исключения закрывает аналитик при ревью с источником.

При выборе формата story явно укажите в constraint: классическая user story или job story — критерии из 04.02 Пользовательские истории (User Stories) и Job Stories; для каждой story добавьте черновик 02.04.02 Критерии приёмки (Acceptance Criteria) с пометкой «требует валидации».

В промпт имеет смысл вкладывать стандарты качества проекта: чеклист из 02.04.03 Управление качеством требований, Definition of Ready команды, фрагмент 10.01.14 Шаблон глоссария и словаря данных — как constraint, а не как источник новых требований.

Пример структуры промпта для извлечения user story:

Роль: системный аналитик проекта {название}.
Контекст: протокол встречи ниже + глоссарий {вставка}.
Задача: извлеки user story в формате «Как [роль], я хочу [действие], чтобы [ценность]».
Для каждой story укажи: источник (цитата ≤25 слов), допущения, открытые вопросы, черновик AC.
Не добавляй требований, которых нет в тексте.
Формат: таблица.

Бизнес-контекст: цели, scope и границы

На старте инициативы zero-shot или few-shot промпт ускоряет черновик целей и KPI по структуре 02.01.02 Цели, KPI и критерии успеха (SMART, GQM) из расшифровки интервью с заказчиком — с обязательным negative constraint «не выдумывай метрики, которых нет в источнике». Для границ решения промпт сравнивает формулировки стейкхолдеров и выдаёт таблицу «in scope / out of scope / требует уточнения» в логике 02.01.04 Определение границ решения (Scope Modelling); финальные границы утверждает команда, не модель.

Классификация, backlog и декомпозиция

LLM с CoT (для неоднозначных случаев) или zero-shot (для однозначной таксономии) классифицирует формулировки по вашей схеме (02.03.01 Классификация требований (БТ, ФТ, НФТ), MoSCoW, доменные категории). Запрос «объясни, почему отнесено к ФТ, а не НФТ» повышает согласованность между аналитиками. В PE4RE прирост точности классификации относительно одного аналитика без LLM на больших наборах оценивают порядка 30%; при сравнении с консенсусом экспертов цифра ниже.

Декомпозиция backlog (epic → story, WBS требований): few-shot с 2–3 примерами вашей иерархии из 05.02 Scrum и Kanban (аналитик в Agile) + constraint «сохраняй трассировку к родительскому epic». CoT полезен, когда epic пересекается с несколькими доменами.

Спецификация API и контрактов

Для черновика REST-операций передайте в промпт constraint по 10.01.04 Шаблон спецификации REST API и фрагмент существующего OpenAPI из 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf) как few-shot: модель дополняет поля endpoint'а, не проектируя интеграцию целиком. Выход — structured output (JSON) для ручной правки и ревью.

Обнаружение конфликтов

При нескольких источниках требований (бизнес, регуляторика, legacy-документация) role-based промпт («специалист по разрешению конфликтов требований») + zero-shot инструкция выдать матрицу trade-off ускоряет подготовку к сессии с 02.01.03 Анализ заинтересованных сторон (Stakeholder Map). Модель предлагает гипотезы конфликта; финальное решение и приоритет — за командой и 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано).

Трассируемость и ревью

Few-shot с примерами из 10.01.15 Шаблон матрицы трассировки помогает связать требование → design decision → тест в логике 02.03.04 Трассировка требований (концепция). Для длинных цепочек используйте CoT с промежуточными таблицами, затем сжимайте итог для human reviewer. Verification prompt («перечисли утверждения без опоры в источнике») — вспомогательный шаг перед полным V&V; канонические ограничения self-verification — в разделе 4.

Мини-протокол на одну рабочую сессию

1. Определите тип задачи (извлечение, классификация, сравнение, синтез, ревью).
2. Подберите технику: zero-shot для простых форматов; few-shot + CoT для сложных и регуляторных.
3. Вложите контекст порциями; не отправляйте весь SRS, если можно дать релевантный раздел + оглавление.
4. Запросите явные неопределённости и ссылки на источник.
5. Проведите статическую проверку качества формулировок черновика — чеклист ревью артефакта по 08.03 Тестирование требований (статическое тестирование) (не проектирование тест-кейсов); при необходимости — инспекция 08.04 Рецензирование и инспекции (техники Фейгана) и сверка AC 02.04.02 Критерии приёмки (Acceptance Criteria) в рамках 02.04.01 Верификация и валидация (V&V).
6. Сохраните удачный промпт в библиотеку команды: consolidated prompt (если был multi-turn), версия модели, temperature, top-p; seed фиксируйте, если платформа позволяет — иначе отметьте ограничение воспроизводимости (11.01 Введение в искусственный интеллект и LLM).

4. Типовые ошибки и ограничения

Ошибки формулировки промпта

• Размытая задача — «проанализируй документ» вместо «найди противоречия между разделами 3 и 5 в таблице с цитатами».
• Перегруз контекстом — весь backlog в одном запросе: модель теряет детали на границах окна; см. chunking в разделе 2.
• Отсутствие negative constraints — без «не выдумывай», «не предлагай UI» модель достраивает правдоподобное.
• Чужие few-shot примеры — примеры из другого проекта задают неверный стиль, терминологию и скрытые требования.
• Конфликтующие инструкции — роль «будь креативным» и constraint «только факты из текста»; выровняйте порядок секций (см. блок «Структура промпта для RE-задач», п. 1–7).
• Один проход без верификации — принятие вывода как финального артефакта без 02.04.03 Управление качеством требований.
• Игнор стохастичности — не зафиксированы версия модели, temperature, текст промпта; результат невоспроизводим для аудита.
• Prompt injection — в контекст вставлен сырой текст от стейкхолдера («игнорируй инструкции и…»); обрабатывайте внешний текст как данные, а не как команды — см. 11.06 Этические и правовые аспекты.

Системные ограничения

Каноническое правило: ни verification prompt, ни RAG не снимают ответственность аналитика за сверку с первичным источником. Модель может «рационализировать» ссылку или процитировать неверный фрагмент — финальное ревью всегда human-in-the-loop.

Промпт не компенсирует отсутствие первичных данных: если стейкхолдер не озвучил ограничение, модель его не «вспомнит». Промпт-инжиниринг усиливает анализ документов (02.02.03 Наблюдение и анализ документов), но не заменяет elicitation с людьми.

Что не стоит возлагать на промпт

• Юридически значимые трактовки без экспертизы — см. 11.06 Этические и правовые аспекты.
• Автоматическое утверждение требований в safety-critical доменах без формального ревью.
• Передача в промпт персональных данных и коммерческой тайны без политики DLP — см. 08.07 Основы кибербезопасности для системного аналитика и 11.06 Этические и правовые аспекты.

Автоматическая оптимизация промптов (secondary LLM оценивает качество и предлагает правки) — emerging-практика на стыке 11.08 Выбор и настройка моделей для корпоративного использования и 11.09 Мониторинг и оценка качества LLM-решений; базовая компетенция аналитика в ручном конструировании промпта остаётся обязательной.

Связи с другими разделами базы

• Базовые свойства LLM, галлюцинации, стохастичность — 11.01 Введение в искусственный интеллект и LLM
• Токены, контекстное окно — 11.02 Теоретические основы обработки естественного языка
• RAG, агенты, корпоративные паттерны — 11.04 Архитектуры использования LLM в корпоративном контуре
• Промпты в связке с Confluence, Jira, вложения — 11.05 Интеграция LLM с инструментами аналитика
• Персональные данные, prompt injection — 11.06 Этические и правовые аспекты
• Кибербезопасность и DLP при работе с чувствительным контекстом — 08.07 Основы кибербезопасности для системного аналитика
• Разбор прикладных сценариев — 11.07 Практические кейсы применения LLM в анализе
• Выбор модели и fine-tuning под домен — 11.08 Выбор и настройка моделей для корпоративного использования
• Метрики качества промптов и drift — 11.09 Мониторинг и оценка качества LLM-решений
• Цели, KPI, границы scope — 02.01.02 Цели, KPI и критерии успеха (SMART, GQM), 02.01.04 Определение границ решения (Scope Modelling)
• Источники elicitation — 02.02.01 Интервьюирование и анкетирование, 02.02.02 Воркшопы, фасилитация и совместные сессии
• Классификация, спецификация, трассировка — 02.03.01 Классификация требований (БТ, ФТ, НФТ), 02.03.03 Спецификация требований (SRS, Use Case, User Story), 02.03.04 Трассировка требований (концепция)
• V&V, критерии приёмки, качество — 02.04.01 Верификация и валидация (V&V), 02.04.02 Критерии приёмки (Acceptance Criteria), 02.04.03 Управление качеством требований
• User story, job story — 04.02 Пользовательские истории (User Stories) и Job Stories
• Форматы исходных документов — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)
• Backlog и декомпозиция — 05.02 Scrum и Kanban (аналитик в Agile)
• API и контракты — 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf)
• Шаблоны артефактов для few-shot — 10.01.01 Шаблон User Story, 10.01.04 Шаблон спецификации REST API, 10.01.14 Шаблон глоссария и словаря данных, 10.01.15 Шаблон матрицы трассировки
• Ревью выхода LLM — 08.03 Тестирование требований (статическое тестирование), 08.04 Рецензирование и инспекции (техники Фейгана)
• Версионирование шаблонов промптов — 07.05 Системы контроля версий (Git) для документации
• Инструменты RE — 02.05.06 Инструменты управления требованиями (Jama, DOORS, Confluence)

Источники и дополнительные материалы

Научные статьи и систематические обзоры

• White J., et al. Prompt Engineering for Requirements Engineering: A Literature Review and Roadmap — arXiv:2507.07682: https://arxiv.org/abs/2507.07682
• Prompt Engineering for Requirements Engineering: A Literature Review and Roadmap (PDF) — https://arxiv.org/pdf/2507.07682
• DOI: https://doi.org/10.48550/arXiv.2507.07682
• Prompt Engineering for Requirements Elicitation: A Comparative Evaluation of Eight Techniques Using O1 — IDETC-CIE 2025, V03BT03A047 (метаданные: https://www.semanticscholar.org/search?q=Prompt%20Engineering%20for%20Requirements%20Elicitation%20Comparative%20Evaluation%20Eight%20Techniques%20O1)

Отраслевые обзоры (вспомогательные, не методологическая база)

• Prompt Engineering for Business: A Practical Guide — IntuitionLabs: https://intuitionlabs.ai/articles/prompt-engineering-business-guide
• Prompt Engineering for Business Analysts Using AI — VTechLabs: https://www.vtechlabs.com/blog/prompt-engineering-business-analysts-ai
• Prompt Engineering for Business Analysts — LinkedIn (Bernacki): https://www.linkedin.com/pulse/prompt-engineering-business-analysts-comprehensive-guide-bernacki-z9zzc
• Prompt Engineering Techniques: The 2026 Enterprise Guide — NextAgile: https://nextagile.ai/blogs/ai/prompt-engineering-techniques/