От промпта к рабочему сценарию: критерии приёмки, тесты и повторяемость

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

Проблема не обязательно в качестве модели. Промпт — лишь один компонент рабочего сценария. Чтобы повторяющаяся задача стала управляемой, нужны спецификация входа и выхода, разрешённые источники и действия, тестовый набор, измеримые критерии, human review, версии, журнал изменений, fallback и границы остановки. Один красивый ответ доказывает только то, что такой ответ однажды появился при конкретных условиях.

По состоянию на 28 августа 2026 года подробный блок публичной карты Narayana ↗ отмечает Narayana AI Academy & Studio ↗ как направление «В развитии»; в обзорной матрице той же страницы стоит близкий ярлык «В разработке». В серии используется подробный статус «В развитии», а расхождение формулировок нужно нормализовать до публикации. Страница описывает возможные обучение, постановку задач, критерии приёмки и «рабочий AI-сценарий», но это не подтверждает проведённые программы, работающую Studio, внедрённые workflow, QA, автоматизацию, SLA, кейсы, ROI, партнёрства или результаты. Публичный DNS находится под проверкой регистратора и указывает на loopback; материал страницы полностью проверен через верифицированный production-origin `201.24.116.180`, где канонический адрес отвечает по HTTPS. Перед публикацией доступность и факты нужно проверить снова.

Ниже — доказательная модель проектирования. Она не описывает уже внедрённый процесс Narayana AI Academy & Studio и не обещает эффективности.

Промпт, спецификация и workflow — разные объекты

Смешение терминов делает приёмку невозможной. Полезно разделить шесть слоёв.

ISO/IEC/IEEE 29148:2018 ↗, подтверждённый ISO как актуальный в 2024 году, рассматривает requirement как выражение потребности вместе с ограничениями и условиями и охватывает выявление, анализ, верификацию, валидацию и управление требованиями. Для маленького AI-сценария это не повод создавать бюрократию. Это напоминание: формулировка «ответ должен быть хороший» не является проверяемым требованием.

Workflow начинается не с украшения промпта, а с договора о задаче. Кто пользователь? Какое событие запускает работу? Какие данные допустимы? Что должно появиться на выходе? Какой выход считается корректным отказом? Кто вправе принять результат или остановить действие? Что происходит без AI? Пока ответы не записаны, улучшение формулировки создаёт видимость точности вокруг неопределённой задачи.

Паспорт сценария: версия, которую можно испытать

Для одного ограниченного сценария достаточно компактного паспорта из пятнадцати полей.

1. Рабочая цель и пользователь. Не «генерировать контент», а конкретное решение для конкретной роли.
2. Триггер и единица работы. Одно письмо, карточка события, заявка или иной законченный случай.
3. Схема входа. Обязательные и необязательные поля, допустимые форматы, язык, объём и качество.
4. Схема выхода. Структура, обязательные элементы, допустимая длина и машиночитаемые поля, если они нужны.
5. Источники. Разрешённые документы, их владельцы, даты, версии и приоритет при конфликте.
6. Инструменты и действия. Поиск, калькулятор, база, API; что разрешено читать, записывать или отправлять.
7. Границы. Что сценарий не делает и какие решения не делегируются системе.
8. Критерии приёмки. Наблюдаемые требования по каждому важному измерению.
9. Цена ошибки. Вред человеку, данным, договору, безопасности, доступности, репутации и работе команды.
10. Human review. Компетентность, первичные материалы, время, полномочия и право отклонить результат.
11. Fallback. Маршрут без AI, возврат незавершённых случаев и сохранение истории.
12. Техническая конфигурация. Поставщик, модель и версия, параметры, системные сообщения, retrieval, инструменты и код.
13. Данные испытаний. Набор, версия, provenance, правила включения, утечка и срок пересмотра.
14. Владелец и утверждающий. Кто меняет, кто независимо проверяет и кто принимает остаточный риск.
15. Версия и срок действия. Дата, changelog, связанные тесты, статус и условие повторной приёмки.

Паспорт не обязан раскрывать секреты публично. Он создаёт внутренний след, позволяющий понять, что именно испытали. NIST AI RMF Core ↗ связывает определение конкретных задач, ролей human oversight и риск-толерантности с документированными, объективными и повторяемыми TEVV-процессами. Это добровольная рамка, не российское право и не аудит направления.

Критерий приёмки описывает наблюдение, а не впечатление

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

Критерии лучше раскладывать по измерениям:

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

ISO/IEC 25059:2023 ↗ даёт язык характеристик качества AI-систем, включая correctness, robustness, transparency, user controllability и intervenability; ISO/IEC TS 25058:2024 ↗ посвящён оценке AI-систем через модель качества. Это международные ориентиры, а не российские обязательные нормы, сертификат или доказательство конкретного результата.

Лестница утверждений: от удачного ответа к ограниченной приёмке

Доказательства должны соответствовать силе заявления.

1. Наблюдение: один зафиксированный прогон дал приемлемый выход.
2. Повторный тест: версия прошла несколько прогонов одного случая в заданном диапазоне.
3. Набор случаев: требования выполнены на заранее определённой выборке, включая исключения.
4. Workflow-тест: проверены не только ответы модели, но также данные, инструменты, валидация, человек и fallback.
5. Ограниченная приёмка: назначены область применения, срок, мониторинг, stop-условия и повторная проверка после изменений.

Переход между ступенями не автоматический. Benchmark не равен эксплуатации, а среднее значение не отменяет критический провал. NIST Generative AI Profile ↗ рекомендует документировать методы, ограничения, источники данных, человеческую проверку и residual risk на протяжении жизненного цикла. Профиль добровольный и не гарантирует приемлемость конкретного workflow.

Тестовый набор должен содержать норму и неудобную реальность

Собирать только знакомые «золотые» примеры опасно: команда запоминает их, prompt подгоняется, а тест перестаёт проверять перенос. Минимальный набор лучше проектировать по семействам.

1. Нормальные случаи — типичная работа с корректным входом.
2. Границы — максимум объёма, редкий формат, неоднозначная дата, несколько языков или особая доступность.
3. Неполный вход — отсутствует обязательный факт; приемлемым может быть запрос уточнения.
4. Конфликт — источники расходятся по версии или приоритету.
5. Устаревшее — документ выглядит убедительно, но срок действия закончился.
6. За пределами области — задача похожа, но не разрешена сценарию.
7. Провокация или инъекция — вход пытается отменить ограничения или извлечь закрытые данные.
8. Последствия инструмента — API недоступен, запись не прошла, действие выполнилось частично.
9. Повторный прогон — одинаковый случай запускается несколько раз для оценки разброса.

ISO/IEC TS 42119-2:2025 ↗ связывает риск, требования, уровни, типы и техники испытаний AI-систем и отдельно требует определить stakeholders и тестовую документацию. Стандарт не говорит, что один набор подходит всем сценариям. NIST TEVV-Athlon ↗, опубликованный 7 августа 2026 года как initial public draft, также строит assessment вокруг целей организации и контекстных measurement concepts. Мы используем его как свежий проектный ориентир, открытый для комментариев, не окончательный стандарт.

Поведенческая методика CheckList ↗ предлагает разделять проверяемые capabilities и типы тестов; в исследованиях авторов такие тесты обнаруживали критические ошибки даже в уже испытанных NLP-системах. Это peer-reviewed методология и экспериментальные результаты, но не готовая приёмка для любого бизнеса.

Эталон — это решение людей с правилами расхождения

Для многих текстовых задач нет единственного «правильного» ответа. Поэтому golden set должен хранить не только образец текста, но и основание оценки: обязательные факты, запрещённые выводы, допустимые варианты и причину решения. Независимые reviewer могут расходиться; это не шум, который следует скрыть, а сигнал неясной рубрики или пограничного случая.

До теста задают квалификацию reviewer, слепую или открытую оценку, порядок adjudication, способ измерить согласие и правило, когда спор отправляет критерий на доработку. Автоматический LLM-judge допустим как вспомогательный измеритель только после отдельной проверки его рубрики, устойчивости и ошибок; он не становится независимым лишь потому, что отличается от оцениваемой модели.

Исследование CheckList ↗ полезно именно decoupling testing from implementation. А NIST-проект evaluation probes ↗ в 2026 году разрабатывает структурированный audit trail, связывающий выводы с доверенным корпусом и рубрикой. Это текущий исследовательский проект NIST, не доказательство готового универсального аудитора.

Повторяемость — не требование одинаковых слов

Генеративный выход может различаться даже при похожем входе. Требовать буквального совпадения обычно бессмысленно; требовать стабильного соблюдения критических свойств — разумно. Для каждого теста определяют, что должно быть инвариантно: факты, запреты, структура, ссылки, действие или корректный отказ; и где допустима вариативность: стиль, порядок безопасных формулировок, примеры.

Репликация требует зафиксировать доступные условия: модель и snapshot, параметры семплирования, системные и пользовательские сообщения, порядок контекста, версию retrieval-индекса, инструменты и разрешения, код pre- и post-processing, дату, регион, run ID и известные изменения поставщика. Если сервис не позволяет закрепить версию или seed, это ограничение нужно записать, а не скрывать словом «детерминированно».

Работа Mizrahi et al. ↗ охватила 6,5 млн примеров, 20 LLM и 39 задач и обнаружила заметную зависимость абсолютных и относительных результатов от перефразировки инструкции. Sclar et al. ↗ показали чувствительность ряда моделей к смыслосохраняющим изменениям формата, вплоть до больших разрывов на отдельных условиях. Эти эффекты нельзя переносить как точную цифру на конкретный сценарий, но они обосновывают тест нескольких допустимых формулировок и отчёт о диапазоне, а не одном лучшем prompt.

HELM ↗, опубликованный в TMLR, демонстрирует многомерную оценку и открытое сохранение prompts и completions. Это научная инфраструктура общего назначения, не критерий приёмки Narayana. Для малого workflow принцип остаётся полезным: качество нельзя свести к одной средней метрике.

Детерминированные ограждения вокруг недетерминированного ядра

Часть требований лучше не поручать модели. Схему полей, обязательность, типы дат, диапазоны чисел, список допустимых статусов, домены ссылок и факт выполнения API можно проверять обычным кодом. Retrieval может ограничивать корпус; policy engine — запрещённые действия; очередь — не допускать двойную отправку. Модель работает там, где нужна языковая интерпретация, а не заменяет все проверки разом.

Human review тоже проектируется как компонент, а не подпись. Reviewer видит исходные материалы и отмеченные неопределённости, имеет достаточно времени и право отказать без давления. Исследование Amershi et al. ↗ сформировало и проверило 18 guidelines взаимодействия человека и AI, включая корректировку, объяснение возможностей и управление ошибкой. Это общий научный ориентир, не гарантия эффективного надзора в конкретной организации.

Правильный отказ — полноценный результат теста. Если не хватает подтверждённой цены, согласия или полномочия на действие, сценарий должен остановиться и передать случай человеку. «Всегда отвечать» — опасный критерий производительности.

Change control: новая версия требует старых вопросов заново

Измениться может не только промпт. Новый model snapshot, источник, retrieval, инструмент, политика доступа, схема выхода, threshold или роль reviewer способны изменить поведение. Поэтому каждый change request содержит причину, затронутые требования, риск, автора, reviewer, версию, набор regression tests и решение о повторной приёмке.

Практичная классификация:

• редакционное изменение без смены смысла — smoke и выборочные regression tests;
• изменение инструкции или контекста — полный набор затронутых поведений и повторные прогоны;
• смена модели, инструмента или данных — расширенная переоценка интеграций, устойчивости и безопасности;
• смена цели, адресата или действия — новая спецификация и новое решение `go / hold / stop`;
• инцидент или критический провал — остановка области, анализ причины, исправление и независимая повторная проверка.

Черновик NIST AI 800-2 ↗, опубликованный для комментариев в 2026 году, структурирует automated evaluation вокруг цели, выбора benchmark, реализации, запуска, анализа и отчёта, акцентируя validity, transparency и reproducibility. Он касается benchmark evaluations и не покрывает все цели operational QA; его статус draft должен сохраняться в атрибуции.

Audit trail без превращения в склад персональных данных

Для каждого прогона достаточно следа, позволяющего расследовать решение: `workflow_version`, `test_case_id`, хеш входа или безопасная ссылка на него, конфигурация, время, результат валидаторов, версия рубрики, решение reviewer, эскалация, действие и статус закрытия. Необязательно копировать весь исходный документ в каждый лог.

Если workflow обрабатывает персональные данные, журнал не получает автоматического права хранить их «на всякий случай». Статья 5 Федерального закона № 152-ФЗ ↗ в редакции от 26 июля 2026 года закрепляет конкретные цели, соответствие объёма цели, неизбыточность, точность и ограничение хранения. Ссылка ведёт на консолидированный текст в правовой справочной системе; применимость и правовое основание определяются для реального процесса отдельно.

Работа Raji et al. ↗ предлагает end-to-end внутренний audit framework и подчёркивает необходимость следа ответственности по жизненному циклу. Это научная модель, не независимый аудит и не основание продавцу единолично подтверждать собственное качество.

No-go и право остановить workflow

Даже высокий средний балл не компенсирует критический дефект. До теста полезно закрепить no-go:

• нет владельца решения, компетентного reviewer или безопасного fallback;
• вход содержит данные без установленной цели, основания, доступа и срока удаления;
• система может совершить необратимое действие без подтверждения;
• обязательный источник отсутствует, конфликтует или устарел, а workflow продолжает угадывать;
• критический тест безопасности, прав, доступности или обоснованности провален;
• версия модели, инструмента или инструкции неизвестна;
• тестовая выборка попала в prompt tuning или была заменена после просмотра результата без отметки;
• историю изменений и неудачных прогонов удаляют;
• продавец решения единолично устанавливает критерии и подтверждает их выполнение;
• сотрудника заставляют «принимать» ответ, прикрываясь скоростью, авторитетом или духовной миссией.

После stop сохраняют безопасный след, возвращают живые случаи в fallback, закрывают автоматические действия, уведомляют затронутых по установленной процедуре и решают: `rework`, `hold`, ограничение области или отказ. Остановка — не поражение, а предусмотренное состояние управляемой системы.

Восемь шагов от промпта к проверяемому сценарию

1. Выбрать одну уже понятую и достаточно ограниченную операцию; выбор AI-пилота и baseline относятся к отдельному readiness-решению.
2. Заполнить паспорт задачи и назвать жёсткие границы, источники, действия, владельца и fallback.
3. Перевести ожидания в наблюдаемые критерии, отдельные critical no-go и допустимые диапазоны.
4. Собрать версионированный тестовый набор до оптимизации: норма, границы, пропуски, конфликт, устаревшее, out-of-scope, атака и сбой инструмента.
5. Зафиксировать prompt, model/config, retrieval, tools, валидаторы и human-review protocol.
6. Провести повторные прогоны, сохранить распределение и не прятать неудачные случаи.
7. Выполнить independent review критических требований и принять `go`, `rework`, `hold` или `stop` только в заявленной области и на ограниченный срок.
8. Включить мониторинг, incident route, change control, regression tests и дату следующей приёмки до реальной эксплуатации.

Как это относится к Narayana AI Academy & Studio

Для направления «В развитии» путь от промпта к workflow может быть принципом будущего обучения: участник приносит одну повторяющуюся задачу и уходит не с «магической формулой», а со спецификацией, набором тестов, критериями и правом остановить сценарий. Но публично заявлять такую практику можно только после подтверждения программы, оператора, компетенций, инструментов, договоров, данных, оценки, жалобы и результатов.

Возможная Studio не должна одновременно продавать решение, определять единственный критерий и единолично подтверждать качество. Обучение не является согласием на данные; внутренний handoff не передаёт их автоматически; общий бренд не заменяет договор и независимую проверку. Экосистема Narayana не описана как единая юридическая организация, поэтому ответственность каждого участника требует отдельной ясности.

Повторяемость не означает одинаковые слова, универсальную модель или гарантированный эффект. Это способность назвать версию, условия и область; провести заранее придуманные тесты; объяснить разброс; увидеть критический провал; воспроизвести след решения; и безопасно остановиться. Ни prompt engineering, ни QA-процедура не гарантируют SLA, ROI, скорость, лиды, прибыль, отсутствие ошибок, безопасность без исключений, замену специалиста, лечение или духовный результат.