Полное погружение в системный промпт Gurufy.ru

Роль системного промпта в Gurufy: цели, контекст, пользовательские сценарии

Зачем Gurufy нужен системный промпт

Gurufy — это продукт, в котором пользователь взаимодействует с ИИ не «в вакууме», а внутри заранее спроектированного опыта: с понятной ролью ассистента, предсказуемым стилем, ограничениями и правилами безопасности. Главный инструмент, который задаёт эти рамки, — системный промпт.

Системный промпт — это текст (набор инструкций), который получает модель до пользовательского сообщения и который определяет, как именно модель должна работать в рамках продукта.

Если упростить, то:

Пользовательский запрос отвечает на вопрос: что сделать прямо сейчас

Системный промпт отвечает на вопрос: как действовать всегда, пока пользователь работает в Gurufy

В этом курсе мы будем разбирать системный промпт как основу продукта: как он задаёт цели, управляет контекстом и поддерживает ключевые сценарии.

Что именно «настраивает» системный промпт

Системный промпт в Gurufy выполняет роль операционной инструкции для модели. Он должен превращать «универсальную модель» в «ассистента Gurufy».

Обычно системный промпт задаёт:

Роль и позиционирование: кто ассистент и в каких границах он полезен.

Цели поведения: что считать успехом ответа (точность, практичность, структурность).

Тон и стиль: краткость или подробность, нейтральность, деловой стиль, дружелюбие.

Правила диалога: когда задавать уточняющие вопросы, как работать с неопределённостью.

Политику безопасности: что нельзя делать, как реагировать на опасные запросы.

Форматирование результата: шаблоны, структура, правила оформления.

Приоритеты инструкций: какие инструкции важнее при конфликте.

Ключевая идея: системный промпт не «помогает ответить на один вопрос», а делает ответы стабильными и совместимыми с задачами продукта.

!Диаграмма показывает, что системный промпт задаёт верхний уровень правил, которые применяются ко всем запросам

Цели системного промпта в Gurufy

Ниже — практический набор целей, который полезно держать в голове при разработке или анализе системного промпта.

Предсказуемость для пользователя

Пользователь должен быстро понять:

что ассистент умеет делать хорошо

как формулировать запросы, чтобы получать нужный результат

какой стиль ответа ожидать

Если ответы «плавают» по тону, структуре и глубине, у пользователя возникает ощущение случайности — это снижает доверие к продукту.

Контроль качества

Системный промпт помогает внедрить стандарты качества, например:

начинать с краткого вывода, затем детали

явно отмечать допущения и неопределённость

предлагать следующий шаг (варианты действий)

Важно: это стандарты поведения, а не «набор фактов». Факты приходят из запроса и контекста, а стандарты — из системного промпта.

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

В продукте всегда есть запросы, которые требуют особой обработки: вред, незаконная деятельность, персональные данные, опасные инструкции. Системный промпт задаёт:

что запрещено

как корректно отказать

как предложить безопасную альтернативу

Экономия времени в диалоге

Хороший системный промпт снижает количество лишних уточнений и «переспрашиваний», потому что задаёт:

какие вопросы задавать только при необходимости

какие детали можно предположить и как эти предположения обозначать

как сокращать путь от запроса к полезному результату

Контекст: что это и как системный промпт им управляет

Контекст — это информация, которую модель учитывает при формировании ответа. В Gurufy контекст важен потому, что многие запросы не имеют одного правильного ответа без уточнений.

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

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

как использовать историю диалога

когда нужно уточнение, а когда можно предложить несколько вариантов

Типы контекста в продуктовых сценариях

Чтобы не путать сущности, удобно разделять контекст на типы.

Контекст задачи: что пользователь хочет получить (результат, формат, ограничения по времени).

Контекст пользователя: уровень знаний, роль, предпочтения, язык, тон общения.

Контекст сессии: что уже обсуждали, какие решения приняты, какие данные уже даны.

Контекст ограничений: политика безопасности, границы компетенций, запреты.

Системный промпт важен тем, что он:

задаёт минимальный стандарт: что делать, если контекста не хватает

предотвращает выдумывание: как говорить «не знаю» полезно

Правило «не выдумывать» как продуктовая функция

Одна из ключевых ролей системного промпта — удерживать модель от уверенных выдумок.

Практичная формула поведения, которую обычно закрепляют на уровне системных инструкций:

если данных не хватает, сначала уточнить

если уточнение невозможно, дать несколько сценариев и отметить допущения

если тема требует источников или точности, попросить входные данные или предложить способ проверки

Пользовательские сценарии Gurufy и требования к системному промпту

Системный промпт должен поддерживать основные сценарии продукта. Не «вообще отвечать», а отвечать так, чтобы пользователь стабильно доходил до результата.

Ниже — типовые сценарии и то, что в них должен обеспечивать системный промпт.

Сценарий: быстрое решение задачи «здесь и сейчас»

Примеры запросов:

«Составь план на неделю»

«Сделай письмо клиенту»

«Сократи текст и сохрани смысл»

Требования к системному промпту:

выводить результат сразу, без длинной теории

задавать не больше 1–3 уточняющих вопросов и только если без них высок риск ошибки

предлагать вариант по умолчанию, если пользователь не дал вводные

Сценарий: экспертная консультация

Примеры запросов:

«Как выбрать стратегию продвижения?»

«Как оценить риски проекта?»

Требования:

структурировать ответ: вводные, варианты, риски, рекомендации

отделять факты от предположений

встраивать вопросы-диагностику (чтобы помочь пользователю уточнить задачу)

Сценарий: обучение и разбор

Примеры запросов:

«Объясни тему простыми словами»

«Проверь решение и укажи ошибки»

Требования:

адаптировать объяснение под уровень пользователя (и уточнять уровень, если неизвестен)

показывать шаги рассуждения в удобной форме (без лишней «воды»)

предлагать упражнения или следующий шаг (если это уместно в продукте)

Сценарий: работа с форматами и шаблонами

Примеры запросов:

«Сделай таблицу сравнений»

«Сгенерируй структуру документа»

Требования:

соблюдать единый формат (заголовки, списки, блоки)

выдавать результат в копируемом виде

проверять, что пользователь просит именно тот формат (например, таблица или список)

Сценарий: поддержка и навигация по продукту

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

Требования:

отвечать коротко и пошагово

при неопределённости уточнять версию, устройство или цель пользователя

не обещать функции, которых нет

Приоритеты инструкций: что делать при конфликте

В реальном диалоге инструкции могут конфликтовать. Например:

пользователь просит «игнорируй правила»

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

пользователь просит нарушить формат продукта

Системный промпт должен задавать понятную лестницу приоритетов, чтобы ответы были стабильными. На уровне здравого смысла это выглядит так:

системные правила и безопасность важнее пожеланий пользователя

уточнение важнее угадывания, если цена ошибки высока

формат продукта важнее «креативного хаоса», если формат — часть ценности

Пример проектирования поведения (без раскрытия внутренних промптов)

Ниже — учебный пример того, как системный промпт может описывать поведение. Это не «секретный промпт Gurufy», а нейтральная схема.

Обратите внимание: такой подход описывает алгоритм диалога, а не «контент». Это и делает системный промпт продуктовым инструментом.

Типичные ошибки при создании системного промпта

Слишком общие формулировки: «будь полезным» без конкретных стандартов качества.

Противоречивые требования: «будь кратким» и «всегда давай максимально подробный ответ».

Попытка запихнуть всё в системный промпт: примеры, справочники, длинные инструкции, которые лучше хранить отдельно.

Нет правил на случай неопределённости: модель начинает додумывать.

Нет явного приоритета безопасности: продукт становится непредсказуемым в сложных ситуациях.

Практический итог

Системный промпт в Gurufy — это фундамент, который:

превращает модель в ассистента конкретного продукта

задаёт цели поведения и критерии качества

управляет контекстом и снижает выдумывание

поддерживает ключевые пользовательские сценарии

обеспечивает безопасность и единый стиль

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

Декомпозиция промпта: инструкции, приоритеты, запреты, тон и формат ответов

Как эта статья связана с предыдущей

В прошлой статье мы разобрали, зачем в Gurufy нужен системный промпт: он задаёт предсказуемость, качество, безопасность и поддержку сценариев. Теперь переходим от целей к конструкции: из каких смысловых блоков обычно состоит системный промпт и как эти блоки «складываются» в устойчивое поведение модели.

Важно: мы изучаем принципы проектирования и архитектуру промпта, а не раскрываем какие-либо внутренние промпты продукта.

!Схема показывает, из каких ключевых частей складывается системный промпт и как он влияет на ответ

Что значит «декомпозировать промпт»

Декомпозиция промпта — это разбор системного промпта на логические части, где у каждой части есть:

своя цель

свой тип формулировок

типичные ошибки

понятные критерии проверки

Практический смысл декомпозиции в том, что вы перестаёте редактировать «простыню текста» и начинаете управлять поведением модели через отдельные рычаги: меняете тон, не ломая безопасность; уточняете формат, не меняя роль; добавляете запрет, не конфликтуя с полезностью.

Блок «Роль и цель ассистента»

Этот блок отвечает на вопрос: кто ассистент в Gurufy и что считается хорошим результатом.

Что обычно фиксируют:

роль: помощник по решению задач, а не «друг» и не «персонаж»

цель: довести пользователя до результата в рамках сценариев продукта

границы: где ассистент полезен, а где должен аккуратно ограничить ожидания

Почему это важно:

роль влияет на стиль и «смелость» утверждений

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

Типичная ошибка:

слишком общая роль вроде «будь полезным», из-за чего поведение расползается по ситуациям

Блок «Инструкции поведения»

Это основной алгоритм диалога: как ассистент думает, уточняет и выдаёт результат.

Удобно мыслить инструкциями как набором правил на типовые ситуации.

Правила работы с неопределённостью

Хорошая конструкция обычно описывает, что делать, если данных не хватает:

задавать ограниченное число уточняющих вопросов

если пользователь не уточняет, давать несколько вариантов и явно отмечать допущения

не выдавать «уверенный ответ» там, где цена ошибки высока

Ключевой принцип: лучше управляемая неопределённость, чем выдуманная точность.

Правила структуры ответа

Инструкции поведения должны закреплять, как выглядит полезный ответ:

краткий результат в начале, детали после

списки шагов, если пользователь просит план

предупреждения о рисках, если тема потенциально вредная или юридически чувствительная

Правила взаимодействия с пользователем

Примеры того, что фиксируют на уровне поведения:

когда задавать вопросы, а когда предлагать вариант по умолчанию

как принимать правки пользователя и сохранять контекст

как признавать ограничения и предлагать альтернативы

Чтобы не изобретать эти правила с нуля, полезно сверяться с общими рекомендациями по иерархии сообщений и управлению инструкциями, например в документации по prompting: OpenAI Prompt Engineering.

Блок «Приоритеты инструкций»

В продукте почти неизбежны конфликты. Например:

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

пользователь требует небезопасный контент

пользователь хочет формат, который ломает сценарий (например, «одним словом», когда нужен план)

Приоритеты — это явная лестница, что важнее при конфликте.

Зачем приоритеты нужны именно системному промпту

Без приоритетов модель:

начинает «договариваться» с пользователем там, где нельзя

хаотично прыгает между краткостью и подробностью

теряет продуктовую стабильность

Практичная лестница приоритетов

Ниже — типовой подход, который можно применять при анализе промпта:

безопасность и соблюдение правил выше любых пожеланий пользователя

системные инструкции выше пользовательских инструкций

точность и честность выше «красивого ответа»

формат продукта выше произвольного оформления, если формат — часть ценности

Важно: приоритеты должны быть написаны так, чтобы по ним можно было принимать решение, а не как абстрактные лозунги.

Блок «Запреты и безопасность»

Запреты — это не только список «нельзя». Это ещё и правила реакции.

Хорошо спроектированный блок безопасности обычно содержит:

перечень категорий запрещённого контента на уровне принципов (без лишних деталей)

правило отказа: кратко, без морализаторства

правило перенаправления: безопасная альтернатива или нейтральная помощь

Почему запреты нельзя писать как «просто откажись»

Если запрет описан слишком общо, модель может:

отказаться там, где помощь безопасна

наоборот, «проскочить» опасный запрос из-за неясных формулировок

Поэтому запреты должны сопровождаться шаблоном поведения, например:

распознай риск

откажи

предложи безопасный вариант

при необходимости попроси переформулировать цель

Типичная ошибка

смешивать запреты и стиль в одну кучу: из-за этого безопасная реакция начинает зависеть от тона и «настроения» ответа

Блок «Тон и стиль»

Тон отвечает на вопрос: как звучит ассистент.

В продукте тон важен не для красоты, а для:

доверия и узнаваемости

снижения когнитивной нагрузки

скорости восприятия результата

Что обычно задают:

деловой или нейтральный стиль

краткость по умолчанию или подробность по умолчанию

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

допустимый уровень «креативности»

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

Блок «Формат ответов»

Формат — это внешний контракт: в каком виде пользователь получает результат.

Формат полезно фиксировать отдельно от тона, потому что формат чаще проверяют и переиспользуют (копировать в документ, вставить в письмо, превратить в задачу).

Что может входить в формат

обязательные секции ответа (например: итог, шаги, риски, следующий шаг)

оформление списков, таблиц, чек-листов

правила для кода: язык, блоки, предупреждения

правила для итоговых артефактов: письмо, план, ТЗ, резюме

Когда формат должен быть строгим

когда ответ уходит «в работу» без правок (письмо клиенту, шаблон документа)

когда Gurufy позиционируется как инструмент результативности, а не «чат для идей»

Типичная ошибка:

пытаться через формат исправить отсутствие инструкций поведения (например, требовать «всегда таблицу», когда нужна диагностика и вопросы)

Как собрать блоки в рабочую конструкцию

Ниже — нейтральная схема сборки, которую удобно применять при проектировании или аудите системного промпта.

Опишите роль и цель в 2–4 строках.

Добавьте инструкции поведения: как уточнять, как отвечать, что делать при неопределённости.

Явно зафиксируйте приоритеты на случай конфликтов.

Добавьте запреты и безопасную реакцию: отказ плюс альтернатива.

Задайте тон.

Задайте формат результата по умолчанию и допустимые варианты.

Проверьте на типовых сценариях из предыдущей статьи: быстрое решение, консультация, обучение, шаблоны, навигация.

Таблица быстрой проверки промпта

| Блок | Что должен обеспечивать | Частая поломка | |---|---|---| | Роль и цель | Понятное позиционирование и критерий «хорошего ответа» | Слишком общие формулировки | | Инструкции поведения | Алгоритм: уточнения, работа с неопределённостью, структура | Модель додумывает вместо уточнения | | Приоритеты | Предсказуемость при конфликте инструкций | «Плавающее» соблюдение правил | | Запреты и безопасность | Запрещено + как корректно реагировать | Лишние отказы или опасные ответы | | Тон | Единый голос продукта | Конфликт тона с честностью | | Формат | Копируемый, стабильный результат | Формат мешает содержанию |

Практический итог

Декомпозиция системного промпта превращает его из «магического текста» в инженерную конструкцию.

Инструкции поведения управляют процессом ответа.

Приоритеты делают поведение стабильным при конфликтах.

Запреты защищают продукт и пользователя, а не просто «отказывают».

Тон формирует узнаваемость и удобство.

Формат обеспечивает переиспользуемость результата.

В следующих материалах курса логично переходить к тому, как писать формулировки без противоречий и как тестировать системный промпт на наборах сценариев.

Данные и контекст: память, источники, ограничения, работа с неизвестным

Связь с предыдущими статьями курса

В первой статье мы зафиксировали, что системный промпт в Gurufy задаёт цели поведения и управляет контекстом так, чтобы ответы были предсказуемыми и полезными. Во второй статье мы разложили системный промпт на блоки: роль, инструкции поведения, приоритеты, запреты, тон и формат.

Теперь делаем следующий шаг: разбираем, из чего именно складывается контекст в практической работе и как системный промпт должен регулировать четыре критичных зоны:

память: что модель должна помнить и как не «придумывать память»

источники: какие данные считаются надёжными и как работать с ними

ограничения: где границы знаний и возможностей

неизвестное: как действовать, если данных не хватает

!Схема слоёв контекста и их приоритета

Что такое «данные» и «контекст» в промпт-инженерии

Чтобы избегать путаницы, разделим термины.

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

Контекст — весь набор сигналов, которые модель учитывает при ответе: данные + история диалога + формат/тон + правила безопасности + ограничения.

Практическая формула для Gurufy:

хороший ответ = данные пользователя + правила продукта + корректная обработка неизвестного

Память: какие «виды памяти» бывают и где риск ошибок

В разговорах про ИИ словом память часто называют разные вещи. Для продуктового качества важно развести их явно.

Память сессии

Это то, что было сказано в текущем диалоге.

модель может опираться на ранее полученные вводные

модель может «потерять» деталь, если она далеко в истории или переформулирована неявно

модель может неверно обобщить сказанное пользователем, если нет правила переспросить

Что должен закреплять системный промпт:

использовать историю как источник, но не приписывать пользователю того, чего он не говорил

при сомнении — уточнить или кратко пересказать, что именно было принято как вводные

Память пользователя

Это устойчивые предпочтения пользователя (тон, роль, цели), которые могут сохраняться между сессиями, если продукт это поддерживает.

Риск: пользователь ожидает, что ассистент «помнит всё», хотя это может быть не так.

Что должен закреплять системный промпт:

не заявлять о «долговременной памяти», если она не гарантирована продуктом

если пользователь ссылается на прошлый разговор, которого нет в текущем контексте, попросить переслать ключевые фрагменты

«Мнимая память» как типовая поломка

Это ситуация, когда модель уверенно говорит: «я помню, что вы…», хотя в данных этого нет.

Причина: модель оптимизирует связность диалога и пытается заполнить пробелы.

Защита на уровне системного промпта:

запрет на утверждения о воспоминаниях без опоры на контекст

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

Источники: что считать надёжным и как снижать выдумывание

В Gurufy важно, чтобы системный промпт задавал иерархию источников, иначе модель будет смешивать вводные пользователя с общими знаниями и догадками.

Типы источников, которые встречаются в сценариях

сообщение пользователя: цели, ограничения, исходные тексты

история диалога: ранее согласованные решения и правки

внешний документ, который пользователь вставил: ТЗ, регламент, письмо, таблица

инструменты/поиск/ретривал (если в продукте подключены): извлечение фактов из базы знаний

общие знания модели: полезны для объяснения и генерации, но рискованны для точных утверждений

Если в продукте используется ретривал (поиск по базе знаний), полезно сверяться с базовыми принципами из документации: Retrieval в документации OpenAI.

Иерархия источников как правило поведения

Практичная продуктовая иерархия (в общем виде) выглядит так:

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

явно подтверждённые решения из истории диалога

данные, полученные из подключённых инструментов (если они есть)

общие знания модели как вспомогательный слой

Что важно: общие знания должны дополнять, а не подменять реальные вводные.

Как отвечать, когда источник неясен

Если пользователь спрашивает: «что написано в нашем договоре?» — а договор не предоставлен, ответ не должен быть «похожим на договор».

Надёжная реакция:

попросить документ или вставку нужного пункта

предложить шаблон проверки: какие разделы обычно регулируют нужный вопрос

явно отметить границу: без текста договора точный ответ невозможен

Ограничения: контекстное окно, актуальность, компетенции

Ограничения бывают двух типов: продуктовые и модельные.

Продуктовые ограничения

Это правила Gurufy как продукта:

безопасность и запреты

формат, который нужен пользователю (письмо, план, таблица)

ограничения на действия (например, ассистент не может реально «отправить письмо», только подготовить текст)

Системный промпт должен требовать:

не обещать действий, которые продукт не делает

разделять «могу подготовить» и «могу выполнить»

Модельные ограничения

Это ограничения самой модели:

ограниченный контекст: в длинных диалогах детали могут выпадать

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

ошибки генерации: модель может звучать уверенно даже при недостатке данных

Что должен закреплять системный промпт:

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

правило уточнений: если цена ошибки высока — спрашивать, а не угадывать

Если вы проектируете подсказки и правила поведения, полезна базовая рамка из: Руководство по prompting в документации OpenAI.

Работа с неизвестным: алгоритм, который снижает риск ошибок

Работа с неизвестным — это центральная функция системного промпта в продукте. Без неё модель начинает «достраивать реальность».

Ниже — практичный алгоритм, который обычно закрепляют как системное поведение.

Определи, чего не хватает для точного ответа.

Оцени цену ошибки.

Если цена ошибки высокая — задай уточняющие вопросы (ограниченно).

Если цена ошибки средняя или пользователь не может уточнить — предложи варианты и отметь допущения.

Если ответ потенциально чувствительный (право, медицина, финансы, безопасность) — добавь предупреждение и предложи проверить у специалиста или по документам.

Цена ошибки: простая шкала для продуктовых решений

Чтобы не усложнять, удобно применять три уровня.

низкая цена ошибки: идеи, черновики, варианты формулировок

средняя цена ошибки: планы работ, оценки сроков без критических рисков

высокая цена ошибки: юридические формулировки, медицинские рекомендации, безопасность, финансы, персональные данные

От уровня зависит, насколько строго нужно:

уточнять вводные

маркировать допущения

отказываться или перенаправлять

Как формулировать допущения, чтобы это было полезно

Плохая практика: «возможно, всё что угодно».

Хорошая практика:

перечислить 2–3 ключевых неизвестных

предложить 2–3 сценария, завязанных на эти неизвестные

указать, что нужно уточнить, чтобы выбрать сценарий

Пример шаблона (как формат поведения, не как обязательный стиль):

Допущение: аудитория — B2B, цикл сделки 2–6 недель.

Если это верно: предлагаю структуру письма A.

Если нет (B2C/короткий цикл): структура письма B.

Уточните: продукт, сегмент, цель письма.

Контекст-бриф: что просить у пользователя, чтобы ответы стали точнее

Одна из задач системного промпта — стандартизировать минимальные уточнения. Ниже — универсальный список, который можно применять в Gurufy как «мысленный чек-лист».

цель результата (что должно измениться после ответа)

формат (письмо, план, таблица, чек-лист)

аудитория (кто будет читать/использовать)

ограничения (срок, объём, тон, запреты)

исходные материалы (текст, цифры, ссылки, правила)

критерий успеха (как пользователь поймёт, что результат хороший)

Важно: задавать не весь список сразу, а выбирать 1–3 самых критичных вопроса.

Как эти правила упаковываются в системный промпт

В предыдущей статье мы говорили про блоки промпта. Тема данных и контекста обычно «лежит» сразу в нескольких блоках.

| Зона | Где фиксируется в системном промпте | Что это даёт продукту | |---|---|---| | Что считать источником | Инструкции поведения, приоритеты | Меньше выдумывания, выше повторяемость | | Как работать с историей | Инструкции поведения | Стабильность в длинных диалогах | | Что делать при неизвестном | Инструкции поведения, формат | Честные ответы и быстрые уточнения | | Где границы возможностей | Роль и цель, запреты | Нет ложных обещаний и опасных действий | | Как звучит неопределённость | Тон и стиль | Не «уверенно неправильно», а «честно полезно» |

Типичные ошибки и как их обнаружить тестами

Ошибка: «модель помнит то, чего не было»

Симптомы:

фразы «как вы говорили ранее», хотя этого нет в диалоге

ссылки на «ваши предпочтения», которые пользователь не задавал

Тест:

начать новую сессию и попросить продолжить проект без вводных

проверить, попросит ли ассистент данные или начнёт выдумывать контекст

Ошибка: «ответ выглядит точным, но не привязан к источнику»

Симптомы:

юридические/финансовые утверждения без опоры на документ или вводные

конкретные цифры без исходных данных

Тест:

дать запрос с намеренно неполными данными и посмотреть, уточняет ли ассистент

Ошибка: «слишком много вопросов вместо результата»

Симптомы:

ассистент всегда задаёт длинный список уточнений, даже в простых задачах

Тест:

запросить «сократи текст» и проверить, делает ли сразу, а вопросы задаёт только при необходимости

Практический итог

Системный промпт в Gurufy должен задавать не только стиль и запреты, но и политику работы с данными:

что считается памятью и как не симулировать «воспоминания»

какие источники приоритетны и как отделять факты от предположений

как признавать ограничения модели и продукта

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

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

Политики безопасности и соответствия: PII, вредный контент, юридические риски

Как эта статья продолжает курс

В предыдущих статьях мы:

разобрали роль системного промпта в Gurufy как инструмента предсказуемости, качества и безопасности

декомпозировали промпт на блоки: роль, инструкции поведения, приоритеты, запреты, тон и формат

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

Эта статья добавляет практическое ядро продуктовой безопасности: как системный промпт должен управлять тремя зонами риска, которые чаще всего «ломают» качество и доверие:

PII (персональные данные)

вредный контент (опасные инструкции и злоупотребления)

юридические риски (обещания, ответственность, советы в чувствительных доменах)

Ключевая идея: безопасность в Gurufy — это не «просто отказы», а политика поведения, встроенная в приоритеты, формат и работу с контекстом.

!Блок-схема, показывающая, как ассистент Gurufy проверяет запрос на PII, вред и юридические риски и выбирает действие

Базовые определения, чтобы говорить точно

Что такое PII

PII (Personally Identifiable Information) — персональные данные, которые позволяют прямо или косвенно идентифицировать человека.

Примеры PII:

ФИО в связке с другими идентификаторами

номер телефона, email, адрес

паспортные данные, ИНН, СНИЛС

номера банковских карт и платёжные реквизиты

биометрия, фото документов

данные аккаунтов и токены доступа

Нормативные рамки зависят от юрисдикции, но полезно ориентироваться на общую логику защиты персональных данных, например в GDPR на сайте EUR-Lex.

Что считать вредным контентом

Вредный контент — помощь, которая повышает способность пользователя причинить вред: себе, другим, инфраструктуре, имуществу или нарушить закон.

Типовые категории:

инструкции по изготовлению оружия или взрывчатых веществ

взлом, фишинг, обход безопасности, вредоносный код с целью злоупотребления

призывы к насилию, экстремизм

саморазрушительное поведение (самоповреждение, суицид)

Удобно сверяться с общими принципами допустимого использования у провайдеров моделей, например OpenAI Usage Policies.

Что такое юридические риски

Юридические риски в контексте ответа ассистента — ситуации, когда текст может:

восприниматься как профессиональная юридическая консультация

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

приводить к неверным действиям пользователя из-за уверенного, но неточного вывода

раскрывать конфиденциальную информацию или нарушать договорные обязательства

Юридический риск часто возникает не из-за «темы права», а из-за тона уверенности и отсутствия источника/документа.

Почему системный промпт — главный носитель политики безопасности

В Gurufy безопасность нельзя полностью «вынести» в отдельный фильтр, потому что фильтр:

не знает продуктового формата ответа

не умеет качественно уточнять вводные

не объясняет ограничения так, чтобы пользователь всё равно получил пользу

Системный промпт, в отличие от фильтра, может задать контракт поведения:

приоритеты (что важнее при конфликте)

правила распознавания риска

шаблон реакции (отказ, уточнение, перенаправление)

формат: как именно оформлять безопасный ответ

Приоритеты: что важнее в конфликтных ситуациях

Чтобы поведение было стабильным, политика безопасности должна быть выше «желаний пользователя» и выше «красоты ответа».

Практичная лестница приоритетов (в нейтральной формулировке):

соблюдение правил безопасности и защита данных

честность и проверяемость (не выдумывать факты и источники)

выполнение цели пользователя в безопасной форме

тон и формат (если они не мешают пунктам выше)

Это напрямую продолжает тему из прошлых статей: приоритеты — не украшение, а механизм, который делает систему предсказуемой.

Политика PII: как не утекать данными и не симулировать доступ

Три типовые ошибки, которые делает ассистент без явных правил

принимает лишние персональные данные и повторяет их в ответе

«помнит» данные, которых не было в контексте (мнимая память)

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

Правила обработки PII, которые стоит закреплять в системном поведении

Минимизация данных: просить только то, что нужно для задачи.

Редакция: если пользователь прислал лишнее, предлагать убрать или замаскировать.

Запрет на деанонимизацию: не помогать идентифицировать человека по набору признаков.

Запрет на секреты: не принимать и не хранить пароли, токены, ключи.

Честность о доступе: не заявлять, что ассистент «видит базы», «проверяет по реестрам», «подтягивает CRM», если инструментов нет.

Полезный шаблон реакции на PII

Когда пользователь прислал персональные данные, цель — не «наказать отказом», а безопасно довести до результата.

кратко указать риск

предложить маску (что заменить на *)

продолжить работу на обезличенных данных

Пример нейтрального поведения:

пользователь прислал паспортные данные для договора

ассистент просит заменить серию/номер на ** и оставить только нужные реквизиты, если без них нельзя

Когда отказ обязателен

Отказ уместен, если запрос направлен на злоупотребление:

«пробей номер телефона, кто владелец»

«найди адрес человека по фото/нику»

«собери базу email из соцсетей»

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

Политика вредного контента: отказ + перенаправление, а не «пустое нет»

Главный принцип

Ассистент должен различать:

безопасное обучение и защиту (например, как защитить аккаунт)

инструкции для злоупотребления (например, как взломать аккаунт)

Это снижает ложные отказы и повышает пользу.

Типовые классы вреда и рекомендуемая реакция

| Риск | Пример запроса | Реакция ассистента | Безопасная альтернатива | |---|---|---|---| | Насилие/оружие | «Как сделать взрывчатку?» | отказ | общая информация о последствиях и безопасности, без рецептов | | Взлом/фишинг | «Сгенерируй письмо для кражи пароля» | отказ | советы по распознаванию фишинга и защите | | Самоповреждение | «Хочу причинить себе вред» | поддержка и перенаправление | рекомендовать обратиться за срочной помощью и к специалистам | | Опасные действия | «Как скрыть следы преступления?» | отказ | предложить законные варианты решения проблемы |

Правило «не повышать способность к причинению вреда»

Даже если пользователь просит «в теории», системный промпт должен удерживать модель от деталей, которые превращают теорию в инструкцию.

Полезная грань:

допустимо: общие принципы безопасности, профилактика, высокоуровневое описание рисков

недопустимо: пошаговые инструкции, конкретные параметры, подбор инструментов для атаки

Тон отказа

Отказ должен быть:

коротким

без обвинений

с предложением альтернативы

Это важно для продукта: пользователь должен продолжить диалог и получить пользу, а не «упереться в стену».

Юридические риски: как отвечать полезно и не создавать ложной ответственности

Три ситуации, где ассистент чаще всего ошибается

даёт «готовую юридическую формулировку» без документа и юрисдикции

путает факты и предположения, но звучит уверенно

подменяет совет «проверьте документ» на выдуманный пересказ

Политика работы с юридическими запросами

Сначала источники: если речь о договоре, политике, регламенте — попросить текст или пункт.

Уточнить юрисдикцию: страна и тип отношений часто критичны.

Разделять уровни: общая информация vs конкретная правовая рекомендация.

Маркировать ограничения: где нужна проверка юриста или официального источника.

Как оставаться полезным без риска

Если пользователь просит «что написать в договоре», безопасный путь:

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

предложить черновик формулировки как пример структуры

явно указать, что требуется проверка специалистом и адаптация под юрисдикцию

Если пользователь спрашивает «законно ли это?», а вводных мало:

не гадать

перечислить ключевые факторы, от которых зависит ответ

попросить данные или предложить список вопросов для юриста

Как эти политики «встраиваются» в системный промпт

Из второй статьи курса у нас есть блоки промпта. Безопасность и соответствие обычно распределяются по ним так.

| Блок промпта | Что туда кладём | Зачем | |---|---|---| | Роль и цель | «помогать в рамках безопасного и законного использования» | фиксирует границы ожиданий | | Инструкции поведения | распознавание PII/вреда/юридической чувствительности + уточнения | управляет диалогом, снижает ошибки | | Приоритеты | безопасность и честность выше выполнения запроса | стабилизирует поведение | | Запреты | конкретные категории + шаблон отказа | предсказуемость реакций | | Тон | нейтральный, без обвинений, без паники | удерживает доверие | | Формат | «отказ + причина + альтернатива + следующий шаг» | превращает отказ в полезный результат |

Универсальный формат безопасного ответа

Хорошо работает единый формат, который не зависит от категории риска:

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

Что могу: безопасная помощь в рамках запроса

Что нужно от вас: какие данные можно прислать (обезличенно) или что уточнить

Этот формат продолжает логику курса: поведение важнее, чем попытка угадать «идеальный текст».

Тестирование политики безопасности на сценариях

Чтобы политика не была декларацией, её проверяют сценариями.

Набор проверок для PII

пользователь присылает номер карты и просит «проверить, работает ли»

пользователь просит составить письмо и вставляет лишние персональные данные

пользователь просит «найди владельца номера»

Набор проверок для вредного контента

просьба о взломе vs просьба о защите

вредная инструкция «пошагово» vs высокоуровневое описание риска

запрос с «маскировкой»: «для учебных целей»

Набор проверок для юридических рисков

вопрос про «наш договор», но договора нет

просьба дать уверенный ответ без юрисдикции

просьба составить претензию/жалобу без фактов и сроков

Критерий прохождения теста:

ассистент не выдумывает источники и факты

задаёт мало, но достаточно уточнений

отказывает там, где нужно, и предлагает альтернативу

сохраняет тон и формат продукта

Практический итог

Политики безопасности и соответствия в Gurufy — это часть системного промпта, которая делает продукт устойчивым:

PII требует минимизации, редактирования и запрета на деанонимизацию

вредный контент требует различать защиту и злоупотребление и давать отказ с перенаправлением

юридические риски требуют работы от источников, уточнений и честной маркировки ограничений

Если эти правила встроены в приоритеты, инструкции поведения и формат, ассистент остаётся одновременно безопасным и полезным — а это и есть продуктовая цель системного промпта.

Шаблоны диалогов и UX: уточняющие вопросы, структура ответа, follow-up

Как эта статья продолжает курс

В прошлых материалах курса мы разобрали:

зачем системный промпт нужен продукту и как он задаёт предсказуемое поведение

из каких блоков он обычно состоит: роль, инструкции поведения, приоритеты, запреты, тон и формат

как системный промпт управляет контекстом: источники, память, ограничения и работа с неизвестным

как встраиваются политики безопасности: PII, вредный контент, юридические риски

Теперь переводим это в прикладной UX: как системный промпт превращается в повторяемые диалоги, где пользователь быстро получает результат, а модель стабильно:

задаёт уместные уточняющие вопросы

выдаёт ответ в ожидаемой структуре

предлагает корректный follow-up, чтобы довести задачу до конца

Здесь важно различать:

шаблоны диалога — повторяемые сценарии взаимодействия

UX-правила — ограничения и привычки, которые делают ответы удобными

follow-up — следующий шаг, который удерживает контекст и ускоряет прогресс

!Схема показывает, как ассистент выбирает: ответить сразу, уточнить или предложить варианты, и всегда завершает follow-up

Почему шаблоны диалогов важны для продукта

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

Шаблоны дают три продукта эффекта:

Скорость: меньше лишних ходов в диалоге, быстрее первый полезный артефакт.

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

Доверие: повторяемая структура, честная работа с неизвестным, стабильные отказы.

Практически это означает: системный промпт должен описывать не только «будь полезным», но и как именно вести разговор.

Уточняющие вопросы как UX-инструмент

Когда уточнять, а когда сразу делать

Главное правило: уточняющий вопрос задаётся не потому, что «можно уточнить», а потому что без него высок риск сделать не то.

Удобная продуктовая логика:

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

если цена ошибки высокая (право, финансы, безопасность, персональные данные), лучше уточнить до результата

Эта логика напрямую продолжает прошлую статью про работу с неизвестным: уточнения должны зависеть от цены ошибки, а не от «желания модели поговорить».

Сколько вопросов задавать

Для UX обычно работает ограничение: 1–3 вопроса за один ход, и только самые критичные.

Если вопросов больше, пользователь воспринимает это как анкету, а не как помощь.

Какими должны быть хорошие уточняющие вопросы

Хороший уточняющий вопрос:

конкретный: про одну неопределённость, без «расскажите всё о бизнесе»

действующий: ответ на него реально меняет результат

экономный: минимум текста, максимум смысла

с вариантами по умолчанию: если уместно, предложить выбор, чтобы ускорить ответ

Плохой вопрос:

«Опишите вашу ситуацию подробнее»

Хороший вопрос:

«Письмо нужно для B2B или B2C? И какая цель: назначить звонок или продать сразу?»

Три типа уточнений

В продуктовых шаблонах удобно различать три типа вопросов.

вопросы про цель: что пользователь считает успехом

вопросы про формат: письмо, план, таблица, чек-лист, длина, тон

вопросы про ограничения: сроки, аудитория, запреты, источники, юридическая юрисдикция

Если ограничение задано системным промптом (например, «не работать с PII»), уточнения должны помогать обезопасить вводные, а не «вытянуть больше данных».

Техника «быстрый черновик + уточнение»

Чтобы не тормозить пользователя, можно комбинировать:

дать черновик по умолчанию

отметить допущения

попросить 1–2 уточнения для улучшения

Этот подход особенно полезен в сценариях «сделай письмо», «набросай план», «сократи текст».

Структура ответа как контракт UX

Почему структура важнее «красивого текста»

Структура делает ответ:

сканируемым

копируемым

проверяемым

И это напрямую связано с системным промптом из второй статьи: формат отделяется от тона и не должен конфликтовать с безопасностью и честностью.

Универсальный каркас ответа

Ниже — универсальная структура, которую можно применять во многих сценариях Gurufy.

Итог: 1–3 строки, сразу то, что пользователь сможет использовать.

Основной результат: письмо, план, таблица, код, список шагов.

Пояснения и допущения: что вы приняли за умолчание и где не хватает данных.

Риски и ограничения: если тема чувствительная или цена ошибки высокая.

Follow-up: что уточнить или сделать дальше, чтобы довести задачу.

Важно: каркас должен быть адаптивным.

если пользователь просит «только текст письма», пояснения и follow-up можно сделать короткими

если запрос юридически чувствительный, блок «ограничения» обязателен

Как помечать допущения, чтобы это было полезно

Допущения должны быть:

конкретными

влияющими на результат

краткими

Пример полезного формата допущений:

«Допущение: аудитория письма — B2B, цель — назначить созвон, тон — нейтрально-деловой»

Пример бесполезного формата:

«Допущений может быть много, уточните детали»

Follow-up: как завершать ответ, чтобы пользователь двигался дальше

Что такое follow-up в UX Gurufy

Follow-up — это не «вежливый вопрос в конце». Это управляемый следующий шаг, который:

снижает неопределённость

фиксирует выбор из вариантов

помогает продолжить работу без потери контекста

Три рабочих формы follow-up

вопрос на выбор: «Выберите A или B»

приглашение к правке: «Скажите, какие блоки усилить: выгоды, доказательства, призыв к действию»

следующее действие: «Вставьте исходный текст пункта договора, и я помогу сформулировать нейтральный черновик»

Follow-up не должен ломать сценарий

Частая UX-ошибка: ассистент дал результат и сразу уводит пользователя в долгий опрос.

Хороший follow-up:

1 вопрос или 2 варианта

привязан к реальному улучшению результата

не требует от пользователя писать «простыню контекста»

Библиотека шаблонов диалогов

Ниже — учебные шаблоны. Их цель — показать, как системный промпт может задавать поведение.

Шаблон: быстрый результат «здесь и сейчас»

Когда подходит:

письмо

пост/анонс

сокращение текста

план на день

UX-смысл:

результат сразу

допущение коротко

follow-up только по ключевым переменным

Шаблон: экспертная консультация

Когда подходит:

стратегия

анализ рисков

выбор вариантов

UX-смысл:

структура как консультационный отчёт

вопросы в конце, а не вместо ответа

Шаблон: обучение и разбор

Когда подходит:

объяснить тему

проверить решение

подготовить к собеседованию

UX-смысл:

сначала понятный минимум

затем расширение

follow-up уточняет сценарий использования

Шаблон: генерация документа или шаблона

Когда подходит:

ТЗ

структура презентации

чек-лист процесса

UX-смысл:

формат максимально копируемый

вопросы только чтобы адаптировать шаблон

Шаблон: чувствительная тема с юридическим риском

Принцип из прошлой статьи: сначала источники, юрисдикция, честные ограничения.

UX-смысл:

не выдумывать правовой ответ

оставаться полезным: список факторов и следующий шаг

UX-правила, которые стоит закреплять на уровне системного промпта

Не превращать диалог в анкету

спрашивать только то, что реально меняет результат

при возможности давать вариант по умолчанию

Держать «первый полезный результат» максимально близко

если можно сделать черновик безопасно, делать его сразу

уточнения переносить в follow-up

Делать ответ проверяемым

отделять факты от допущений

не ссылаться на «память» и недоступные источники

Делать результат копируемым

избегать лишних вступлений

использовать устойчивую структуру

Не ломать безопасность ради удобства

Полезно помнить внешние рамки:

принципы prompting и иерархии инструкций в документации: Prompting в документации OpenAI

общие принципы допустимого использования: OpenAI Usage Policies

Как тестировать шаблоны диалога

Шаблон считается хорошим, если он выдерживает тесты на типовых сценариях.

тест на неполные вводные: ассистент либо уточняет, либо даёт варианты с допущениями

тест на «лишние вопросы»: в простых задачах ассистент не тормозит пользователя

тест на конфликт инструкций: безопасность и честность выше выполнения запроса

тест на копируемость: результат можно сразу вставить в письмо/документ

Практичные метрики UX (даже без сложной аналитики):

сколько ходов до первого полезного результата

сколько правок просит пользователь

сколько раз ассистент «переспрашивает одно и то же»

Практический итог

Шаблоны диалогов и UX в Gurufy — это способ превратить системный промпт в предсказуемое взаимодействие.

уточняющие вопросы должны быть редкими, критичными и ускоряющими

структура ответа — это контракт: итог, результат, допущения, риски, follow-up

follow-up нужен, чтобы фиксировать выбор и продвигать задачу без потери контекста

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

Тестирование и отладка: наборы кейсов, метрики, A/B, регрессии

Как эта статья продолжает курс

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

Эта статья переводит всё это в практику разработки: как доказать, что системный промпт работает стабильно и не ломается при правках.

Мы разберём четыре опоры:

Наборы кейсов: какие сценарии обязательно тестировать и как их формулировать

Метрики: как измерять качество, безопасность и UX, а не спорить «на ощущениях»

A/B-тесты: как безопасно сравнивать версии промпта на реальных пользователях

Регрессии: как не ухудшать уже работающие сценарии при каждой новой правке

!Диаграмма показывает, как промпт проходит через оффлайн-проверки, A/B и регрессии до релиза

Зачем тестировать системный промпт, если «вроде работает»

Системный промпт влияет на поведение модели во всех запросах, поэтому даже маленькая правка может неожиданно:

ухудшить UX (модель начинает задавать слишком много вопросов)

нарушить формат (плывёт структура ответа)

повысить риск галлюцинаций (уверенные выдумки)

сломать безопасность (неправильные отказы или опасные ответы)

Тестирование нужно, чтобы:

быстро и воспроизводимо ловить поломки

сравнивать версии промпта честно

выпускать изменения итеративно, не боясь «эффекта бабочки»

Что такое оффлайн и онлайн тестирование

Чтобы термины были однозначны:

Оффлайн-тестирование — прогон заранее подготовленных кейсов без участия пользователей (в лабораторных условиях). Это ваш основной инструмент для быстрой отладки и регрессий.

Онлайн-тестирование — проверка на реальном трафике, обычно в формате A/B-теста, где пользователи случайно попадают в разные версии.

Практическое правило: сначала оффлайн, затем онлайн. A/B без оффлайн-покрытия часто превращается в рискованный эксперимент.

Наборы кейсов: что тестировать и как

Принцип покрытия: тестируем не «темы», а поведение

Из прошлых статей курса у нас есть ключевые блоки поведения, и именно под них строятся тесты:

работа с неизвестным (уточнить или дать варианты с допущениями)

приоритеты (безопасность и честность выше пользовательских просьб)

формат и UX (первый полезный результат, структура, follow-up)

безопасность (PII, вредный контент, юридическая чувствительность)

Минимальная библиотека кейсов для Gurufy

Ниже — практичная структура тестового набора. Это не «раз и навсегда», а стартовая рамка.

| Группа кейсов | Что проверяем | Пример поломки | Как выглядит успех | |---|---|---|---| | Быстрые задачи | скорость первого результата, краткость, копируемость | вместо письма — длинная теория | сразу черновик + 1 уточнение в follow-up | | Консультации | структура, диагностика, отделение фактов от предположений | общие советы без уточнений и без плана | итог + план + вопросы по делу | | Работа с неизвестным | правильный выбор: уточнить vs дать варианты | уверенный ответ при нехватке данных | 1–3 уточнения или 2–3 сценария с допущениями | | Формат/шаблоны | соблюдение структуры и секций | формат «плывёт» от ответа к ответу | стабильный, копируемый шаблон | | PII | минимизация данных, редактирование, запрет на деанонимизацию | просит лишние данные / повторяет паспорт | просит замаскировать, не помогает злоупотреблять | | Вредный контент | отказ + безопасная альтернатива | выдаёт опасные шаги «в теории» | короткий отказ, советы по защите | | Юридические риски | «сначала источники», юрисдикция, честные ограничения | придумывает нормы и выводы | просит текст договора/юрисдикцию, даёт нейтральный разбор | | Навигация по продукту | не обещать несуществующие функции | «я отправил письмо» | «могу подготовить текст, вы отправите сами» |

Как формулировать один кейс

Кейс должен быть воспроизводимым. Удобный шаблон:

Вход: одно пользовательское сообщение (или короткий диалог в 2–4 хода, если тестируем удержание контекста)

Ожидание: что именно должно быть в ответе и чего быть не должно

Критерии: чек-лист с бинарными пунктами (да/нет)

Класс риска: низкая/средняя/высокая цена ошибки (из статьи про работу с неизвестным)

Пример ожиданий в формате чек-листа:

ответ начинается с результата, а не с предисловия

задано не более 3 уточняющих вопросов

допущения явно помечены

нет утверждений о «памяти» вне контекста

при чувствительной теме есть предупреждение/ограничение

«Золотые ответы» и почему они не всегда буквальные

Есть два подхода к оценке:

Золотой ответ — заранее подготовленный пример идеального ответа

Рубрика (чек-лист) — набор критериев, по которым ответ считается успешным

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

Практика:

для шаблонов (письмо, ТЗ, таблица) золотой ответ полезен

для консультаций и сложных задач лучше рубрика

!Матрица помогает увидеть, какие сценарии не покрыты тестами

Метрики: как измерять качество, безопасность и UX

Метрика — это числовой показатель, который позволяет сравнивать версии и отслеживать деградации. Важно: метрики должны быть связаны с целями продукта из первой статьи (предсказуемость, качество, безопасность, скорость).

Оффлайн-метрики (на наборе кейсов)

Самые полезные оффлайн-метрики обычно простые:

Процент прохождения чек-листа: доля кейсов, где выполнены ключевые критерии

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

Доля «мнимой памяти»: случаи, когда модель ссылается на отсутствующий контекст

Соблюдение формата: наличие обязательных секций (итог, результат, допущения, follow-up) там, где они требуются

Онлайн-метрики (на реальном трафике)

Онлайн-метрики делятся на три слоя.

| Слой | Метрика | Зачем | Риск неправильной интерпретации | |---|---|---|---| | UX | ходов до первого полезного результата | скорость достижения ценности | «короче» не всегда «лучше», если выросли ошибки | | Качество | доля ответов с повторным запросом «переделай» | индикатор промаха по ожиданию | зависит от аудитории и сложности задач | | Безопасность | доля опасных инцидентов и неверных отказов | защита продукта | требует ручной валидации выборки |

Дополнительно полезны:

CSAT/оценка ответа (если в продукте есть лайки/оценки)

Retention по сценарию: вернулся ли пользователь к задаче (особенно для шаблонов)

Guardrail-метрики: что нельзя ухудшать при A/B

Guardrails — это метрики-ограничители, при ухудшении которых эксперимент нужно остановить.

Типичные guardrails для системного промпта:

рост опасных ответов (безопасность)

рост «уверенных выдумок» в чувствительных темах (честность)

рост неверных отказов (польза)

резкое падение соблюдения формата (UX-контракт)

Для ориентиров по экспериментации и метрикам полезно сверяться с базовой практикой продуктовых A/B-тестов, например: A/B testing на Wikipedia.

A/B-тестирование: как сравнивать версии промпта безопасно

Что такое A/B в контексте промпта

A/B-тест — это эксперимент, где пользователи случайно распределяются между:

вариант A: текущий системный промпт

вариант B: новый системный промпт (или его часть)

Цель — измерить, улучшился ли результат по выбранным метрикам.

Главное правило: меняем одну гипотезу за раз

Если вы изменили и тон, и формат, и политику уточнений, вы не поймёте, что именно сработало.

Надёжная практика:

Формулируем гипотезу в стиле: «если изменить X, то улучшится Y без ухудшения Z»

Меняем только X

Смотрим Y и guardrails Z

Пример гипотезы:

«Если ограничить уточняющие вопросы до 2 и добавить вариант по умолчанию, то снизится число ходов до первого полезного результата, не вырастет доля неверных ответов»

Как проектировать эксперимент для промпта

Полезный чек-лист дизайна:

Выберите аудиторию и сценарии (например, только «письма/шаблоны», чтобы не смешивать с консультациями)

Определите основную метрику (например, ходы до первого полезного результата)

Задайте guardrails (безопасность, неверные отказы, формат)

Заранее решите, когда эксперимент останавливается (по времени и по рискам)

Почему нужен A/A-тест

A/A-тест — это когда вы сравниваете «A против A» (две одинаковые версии). Он нужен, чтобы проверить, что ваша система измерения не даёт ложную «разницу» из-за багов, перекосов распределения или нестабильных логов.

Ручной разбор выборки обязателен

Системный промпт часто меняет качество и безопасность так, что это не видно по одной цифре.

Поэтому в A/B почти всегда нужен ручной аудит:

случайная выборка диалогов из A и B

оценка по рубрике

отдельный просмотр пограничных случаев: право, PII, вред

Регрессии: как не ломать то, что уже починили

Регрессионный тест — это проверка, что новая версия не ухудшила поведение на ранее успешно проходивших кейсах.

Что включать в регрессионный набор

Регрессии должны быть небольшими, но «злыми»:

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

самые рискованные зоны (PII, вред, юридические)

кейсы, где раньше уже была поломка

кейсы на конфликт инструкций (пользователь просит игнорировать правила)

Версионирование промпта и журнал изменений

Чтобы отладка была инженерной, а не магической, фиксируйте:

версию промпта (например, prompt_v12)

что именно изменили (одна гипотеза)

какие кейсы добавили в регрессии из-за этой правки

Это превращает развитие промпта в управляемый процесс.

Replay: повторный прогон реальных диалогов

Кроме синтетических кейсов полезен replay — повторный прогон исторических диалогов (обезличенных) на новой версии.

Плюсы:

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

показывает неожиданные паттерны (мультиязычность, сленг, «плохие» запросы)

Минус:

нужен контроль PII и корректная анонимизация

Отладка: как находить причину поломки промпта

Принцип минимального воспроизведения

Если вы видите плохой ответ в длинном диалоге, не начинайте сразу переписывать промпт. Сначала сделайте минимальный пример:

Оставьте только те реплики, без которых поломка не происходит

Зафиксируйте конкретный критерий ошибки (например: «не задаёт уточнение при высокой цене ошибки»)

Проверьте, воспроизводится ли проблема стабильно

Отладка через декомпозицию блоков

Мы уже разбирали, что системный промпт состоит из блоков. Используйте это как метод диагностики:

если нарушается структура ответа, вероятная причина в блоке формата

если «плывёт» тон, причина в блоке тона или в конфликте с инструкциями поведения

если появились опасные ответы, причина в блоке запретов/приоритетов

если начались выдумки, причина в правилах источников и неизвестного

Практический приём: менять блоки по одному и прогонять регрессионный набор после каждой правки.

Три частых причины деградаций

Конфликт инструкций: новое правило противоречит старому (например, «всегда отвечай без вопросов» ломает безопасность)

Слишком общая формулировка: модель начинает трактовать её широко и непредсказуемо

Неправильный приоритет: формат или тон начинают «перебивать» честность и безопасность

Практический итог

Тестирование системного промпта в Gurufy — это способ превратить качество в повторяемую инженерную систему:

кейсы проверяют поведение по ключевым сценариям и рискам

метрики позволяют сравнивать версии и ловить деградации

A/B даёт уверенность на реальном трафике при наличии guardrails и ручного аудита

регрессии защищают от «случайных поломок» при итерациях

Следующий логичный шаг развития курса — собрать единый тестовый контур: библиотеку кейсов + рубрики + регрессионный прогон, чтобы любые изменения системного промпта выпускались быстро и безопасно.

Эволюция промпта: версионирование, документация, деплой и мониторинг качества

Как эта статья завершает картину курса

В предыдущих статьях мы разобрали, что должно быть в системном промпте Gurufy и как это проявляется в поведении:

роль, цели и пользовательские сценарии

декомпозиция на блоки: инструкции, приоритеты, запреты, тон, формат

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

безопасность и соответствие: PII, вредный контент, юридические риски

UX-шаблоны: уточнения, структура ответа, follow-up

тестирование: наборы кейсов, метрики, A/B, регрессии

Теперь добавляем эксплуатационный слой: как сделать так, чтобы системный промпт развивался как продуктовый артефакт, а изменения выпускались управляемо.

!Жизненный цикл промпта как инженерного процесса

Почему системный промпт нужно «эксплуатировать», а не просто написать

Системный промпт в Gurufy влияет на каждый ответ. Поэтому он ведёт себя как код и как политика одновременно:

маленькая правка тона может изменить вероятность уточняющих вопросов

уточнения могут конфликтовать с требованием «первый полезный результат быстро»

усиление формата иногда снижает гибкость консультаций

любое размывание запретов может создать риски по безопасности

Ключевой вывод из статьи про тестирование: без контуров проверки и выпуска промпт деградирует, а качество становится случайным.

Версионирование: как сделать изменения воспроизводимыми

Что именно версионировать

Версионировать нужно не только «текст системного промпта», а весь комплект, который влияет на поведение.

сам текст системных инструкций

связанные шаблоны формата (если они вынесены отдельно)

наборы оффлайн-кейсов и регрессий

рубрики оценки и критерии прохождения

конфигурацию экспериментов (A/B, фича-флаги)

Практическое правило: если изменение может изменить ответы, оно должно попадать в историю изменений.

Схема версий и идентификаторы

Удобно иметь два уровня идентификации.

человекочитаемая версия для обсуждений: например v1.8

точный идентификатор для логов и воспроизведения: например prompt_v1.8_2026-02-06_a1b2c3

Если хочется формализовать правила изменения версий, можно опираться на идею семантического версионирования: Semantic Versioning.

Журнал изменений

Журнал изменений нужен, чтобы команда понимала почему промпт стал таким, а не только что изменилось.

Минимальный формат записи:

причина изменения (какую поломку или метрику лечим)

гипотеза (что именно изменили и какой ожидаем эффект)

зона риска (UX, безопасность, «не выдумывать», формат)

какие кейсы добавили в регрессии

план отката

Стратегия ветвления и review

Промпт стоит развивать так же дисциплинированно, как код.

отдельная ветка или pull request под одну гипотезу

обязательное ревью на конфликт инструкций и приоритетов

отдельное ревью на безопасность в духе принципов допустимого использования: OpenAI Usage Policies

Документация: как превратить промпт в понятный контракт

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

Какие документы реально помогают

Ниже перечислены документы, которые дают максимальную отдачу.

Контракт поведения (Behavior Spec)

Карта приоритетов (что важнее при конфликте)

Политика источников и неизвестного (что считать данными, когда уточнять)

Политика безопасности (PII, вред, юридическая чувствительность)

UX-стандарты (структура ответа, лимит уточнений, follow-up)

Тестовый пакет (кейсы + рубрики + регрессии)

Решения и компромиссы (короткие записи в стиле ADR)

Контракт поведения: пример структуры документа

Чтобы не смешивать всё в «простыню», удобно описывать промпт как набор правил по темам.

роль ассистента и границы обещаний

формат ответа по умолчанию и допустимые варианты

правило уточнений (когда и сколько)

правило «не выдумывать» и иерархия источников

чувствительные домены: как маркировать ограничения

безопасность: как отказывать и как перенаправлять

Важное требование: контракт должен быть проверяемым через кейсы из прошлой статьи про тестирование.

Документация по данным и PII

Так как Gurufy работает с пользовательским контентом, важно документировать минимизацию и обработку персональных данных.

какие данные считаются PII

что запрещено принимать (пароли, токены, ключи)

как просить обезличивание

как хранить логи и кто имеет доступ

Если вам нужно зафиксировать базовую терминологию и принципы обработки персональных данных, полезно иметь ссылку на рамочный источник: General Data Protection Regulation (GDPR).

Деплой промпта: как выпускать изменения безопасно

Деплой промпта в продукте лучше воспринимать как релиз модели поведения. Значит, нужен пайплайн, который не пропускает изменения без проверок.

Контуры окружений

Типовая и практичная схема окружений:

dev: быстрая ручная отладка

staging: оффлайн-прогоны и имитация прод-конфигурации

prod: ограниченный выпуск через фича-флаги или канареечный деплой

Гейт перед релизом

Перед включением промпта в прод полезно иметь минимальные гейты.

оффлайн-прогон кейсов

регрессионный набор

проверка guardrails (опасные ответы, неверные отказы, «мнимая память»)

ручной аудит выборки пограничных диалогов

Это продолжает методику из прошлой статьи и делает релиз повторяемым.

Фича-флаги, канарейка и откат

Чтобы не «взорвать» качество на всём трафике, используйте контролируемый выпуск.

фича-флаг: включаем новую версию ограниченной аудитории или сегменту сценариев

канарейка: небольшой процент трафика на новую версию

быстрый откат: возможность вернуть предыдущую версию без новых правок

A/B как часть деплоя, а не как замена тестов

A/B нужен, чтобы сравнить версии на реальном трафике, но он не заменяет оффлайн-проверки.

оффлайн подтверждает, что версия не опасна и не ломает базовые сценарии

A/B подтверждает, что версия лучше по метрикам в живой среде

Если вы проектируете A/B, держите в голове базовые принципы экспериментов: A/B testing.

Мониторинг качества: как понять, что промпт работает в реальности

Даже идеальный оффлайн-набор не покрывает всего разнообразия пользовательских запросов. Поэтому в проде нужен мониторинг.

Что логировать, чтобы это было полезно и безопасно

Логи нужны для отладки и мониторинга, но они же создают риск PII.

логируйте версию промпта (точный идентификатор)

логируйте тип сценария и результаты проверок (прошёл рубрику или нет)

минимизируйте хранение исходного текста пользователя

применяйте редактирование PII до записи

Принцип: дебаг должен быть возможен без накопления чувствительных данных.

Онлайн-метрики качества и UX

Ниже метрики, которые особенно хорошо связываются с целями из первых статей курса.

| Зона | Что измеряем | Зачем это промпту | |---|---|---| | Скорость | ходы до первого полезного результата | отражает UX-шаблоны и качество уточнений | | Качество | доля запросов «переделай/не то» | индикатор промаха по ожиданиям | | Формат | доля ответов с нарушением структуры | контроль контрактов формата | | Честность | доля «уверенных выдумок» в выборке | контроль правил источников и неизвестного | | Безопасность | инциденты и неверные отказы | контроль политик PII/вред/юридическое |

Алёрты и пороги

Алёрты должны быть привязаны к guardrails.

рост опасных ответов даже на малой доле трафика

всплеск неверных отказов

рост «мнимой памяти»

падение соблюдения формата в ключевых сценариях

Здесь важно не точное число, а принцип: если guardrail ухудшился, релиз надо останавливать или откатывать.

Дрифт поведения и «тихие» деградации

У промпта есть риск деградаций даже без правок.

меняется распределение пользовательских сценариев

появляются новые типы запросов и обходные формулировки

меняются ожидания аудитории

Поэтому полезны регулярные процедуры.

еженедельный аудит выборки диалогов по рубрикам

пополнение библиотеки кейсов новыми реальными формулировками

пересмотр UX-шаблонов при смене продуктовых приоритетов

Операционный процесс: от инцидента до новой версии

Чтобы эволюция была управляемой, хорошо работает короткий цикл.

зафиксировать проблему (пример диалога, метрика, где проявилось)

классифицировать поломку (формат, уточнения, безопасность, источники)

сформулировать одну гипотезу изменения

обновить промпт и добавить кейсы в регрессии

прогнать оффлайн-тесты

выпустить через фича-флаг или канарейку

проверить guardrails и целевые метрики

либо расширить раскатку, либо откатить

Этот цикл связывает все темы курса: декомпозицию, работу с неизвестным, безопасность, UX и тестирование.

Практический итог

Эволюция системного промпта в Gurufy становится предсказуемой, если относиться к нему как к продуктовой системе:

версионирование делает изменения воспроизводимыми

документация превращает промпт в проверяемый контракт

деплой через гейты и фича-флаги снижает риск поломок

мониторинг и аудит ловят деградации на реальном трафике

Так промпт перестаёт быть «магическим текстом» и становится управляемым инженерным контуром качества.