Персонаж AI-ассистента бренда: как разработать
Команда брендинга полгода прописывала персонажа: голос, ценности, даже любимые фразы. Ассистента запустили — и через неделю в поддержку начали жаловаться: бот то извиняется с преувеличенной заботой, то сухо отбривает пользователя канцелярским отказом в соседнем диалоге. Документ был идеальным. Персонаж в проде — нет.
Почему у одного ассистента получается «раздвоенная личность»
Исследователи назвали это явление AIDIS — AI Dissociative Identity Syndrome, явление, при котором модель демонстрирует несогласованное поведение из-за конфликта целей разных слоёв системы. Бот демонстрирует несогласованное поведение не потому, что кто-то плохо написал промпт, а потому что цели разных слоёв системы конфликтуют между собой и не интегрированы. Модель, отвечающая за генерацию текста, «тянет» в сторону естественности и разнообразия формулировок. Слой безопасности «тянет» в сторону шаблонных, юридически безопасных фраз. Слой поиска информации подсовывает факты без учёта тона. Результат — ассистент, который в одном ответе звучит как заботливый консультант, а в следующем — как автоответчик службы поддержки из девяностых.
Особенно опасен один нюанс: модель произносит неверный ответ с той же спокойной и уверенной интонацией, что и верный. Пользователь не считывает разницу в надёжности — он считывает уверенность как компетентность. Раздвоенность личности тут работает не как забавный баг, а как источник доверия к неправильной информации.
Как перевести «дружелюбный» и «профессиональный» в правила, а не в прилагательные
Прилагательные из брендбука бесполезны для модели напрямую. «Дружелюбный» для одного разработчика означает эмодзи и восклицательные знаки, для другого — короткие фразы без канцелярита. Черту нужно разложить на измеримые параметры: длину предложений, лексику, которую можно и нельзя использовать, конкретные формулировки для типовых ситуаций — отказа, неуверенности, эскалации к человеку.
Хорошая модель для этого — фреймворк агентства R/GA, который описывает AI-ассистента через четыре элемента, а не через одну «личность»:
- Character — стиль речи, словарь, ритм фраз;
- Memory — что ассистент помнит о пользователе и как это использует;
- Intelligence — границы компетенции, что он умеет решать сам;
- Principles — этические и репутационные ограничения, которые не нарушаются никогда.
Это шире привычной «персоны из тона и голоса» и сразу задаёт операциональные точки: интеллект и память — это архитектурные решения, а не текст в промпте.
Есть и данные в пользу точной настройки, а не общих формулировок: в телеком-исследовании, охватившем 57 000 взаимодействий, совпадение личности бота с личностью пользователя — интроверта или экстраверта — улучшало и поведение покупателя, и продолжительность диалога. Абстрактный «дружелюбный тон для всех» работает хуже, чем откалиброванный под сегмент аудитории паттерн общения.
Документ персонажа и персонаж в production — разные объекты
Ключевая ошибка индустрии: persona существует в красивом PDF на гугл-диске, но не закодирована в system prompt. Если решение о том, как ассистент реагирует на грубость или на просьбу дать медицинский совет, не прописано в инструкции, выполняемой моделью в реальном времени — оно просто не существует. Фраза «You are a helpful, friendly assistant» ничего не решает: модель не знает, какой должна быть длина предложения, допустимы ли шутки, что делать при неуверенности в ответе.
| Persona-документ | Persona-в-production |
|---|---|
| Описывает характер словами: «тёплый», «экспертный», «с юмором» | Задаёт правила: длина фраз, лексика, шаблоны для отказа и эскалации |
| Живёт в презентации или wiki, читается один раз при запуске | Живёт в system prompt, фильтрах вывода, ограничениях доступа к инструментам |
| Не проверяется автоматически | Тестируется на конкретных сценариях перед релизом и мониторится после |
| Принадлежит бренд-команде «на бумаге» | Принадлежит продакт-менеджеру как версионированный артефакт продукта |
Почему одного промпта недостаточно: архитектура контроля персонажа
Полагаться только на system prompt небезопасно — модель может обойти инструкцию под давлением контекста, длинного диалога или манипулятивного запроса пользователя. Персонаж, который держится реально, строится на нескольких уровнях одновременно:
- System prompt — базовые правила стиля и границ.
- Tool permissions — какие действия и данные ассистенту разрешено вызывать.
- Output filtering — проверка ответа после генерации перед показом пользователю.
- Retrieval constraints — ограничения на то, какие источники можно использовать для ответа.
- Human review — ручная проверка проблемных или высокорисковых кейсов.
Каждый уровень ловит то, что пропустил предыдущий. Отсутствие этой многослойности, а не «плохой промпт», объясняет большинство публичных провалов брендовых ассистентов.
Где персонаж бьёт по репутации бренда
Самая частая ошибка — попытка сделать ассистента максимально человечным и эмоциональным. Это выглядит эффектно в презентации, но на практике загоняет продукт в uncanny valley: пользователи не доверяют боту, который «слишком старается» изображать чувства, и предпочитают чёткую компетентность театральной теплоте.
Вторая ошибка — юридический дисклеймер вместо продуманного отказа. Фраза вида «Я не могу дать медицинскую рекомендацию, обратитесь к врачу» разрушает персонажа и звучит как сбой системы. Работает вариант, спроектированный как часть характера: «Не дам конкретного медицинского совета, но помогу сформулировать вопросы для врача» — отказ, который не выпадает из голоса бренда и при этом закрывает юридический риск.
Третья ошибка — уверенный тон при неверных фактах. Если персонаж запрограммирован звучать одинаково убедительно всегда, ошибки становятся особенно опасны: пользователь не получает сигнала «здесь я не уверен».
Как проверить персонажа до запуска и не потерять его после
Перед релизом стоит прогнать ассистента через набор стресс-сценариев: агрессивный пользователь, запрос вне компетенции, просьба нарушить правило, длинный диалог с попыткой манипуляции тоном. Каждый ответ сравнивается не с «ощущением», а с конкретными правилами из спецификации — длиной фраз, лексикой, форматом отказа. Без такого прогона персонаж существует только в теории, и первым тестировщиком становится живой пользователь в проде, что почти всегда дороже.
После запуска характер деградирует градиентно, а не одномоментно. Обновление базовой модели меняет манеру формулировок даже при неизменном system prompt. Новый источник в retrieval-слое приносит факты в другой стилистике. Команда поддержки добавляет «временный» шаблон ответа на частую жалобу — и через полгода треть диалогов звучит не по спецификации, потому что никто не сверял их с ней с момента запуска. Поэтому персонажа нужно мониторить так же, как метрики конверсии: с регулярной выборкой реальных диалогов, сверкой с эталонными сценариями и версионированием промптов и фильтров, чтобы откатиться при регрессии.
Практический вывод простой: персонаж бренда в AI-продукте — это не творческая задача, которую закрывают один раз на этапе запуска, а операционный процесс с владельцем, метриками и регламентом проверки.
Команда брендинга полгода прописывала персонажа: голос, ценности, даже любимые фразы. Ассистента запустили — и через неделю в поддержку начали жаловаться: бот то извиняется с преувеличенной заботой, то сухо отбривает пользователя канцелярским отказом в соседнем диалоге. Документ был идеальным. Персонаж в проде — нет.
Почему у одного ассистента получается «раздвоенная личность»
Исследователи назвали это явление AIDIS — AI Dissociative Identity Syndrome, явление, при котором модель демонстрирует несогласованное поведение из-за конфликта целей разных слоёв системы. Бот демонстрирует несогласованное поведение не потому, что кто-то плохо написал промпт, а потому что цели разных слоёв системы конфликтуют между собой и не интегрированы. Модель, отвечающая за генерацию текста, «тянет» в сторону естественности и разнообразия формулировок. Слой безопасности «тянет» в сторону шаблонных, юридически безопасных фраз. Слой поиска информации подсовывает факты без учёта тона. Результат — ассистент, который в одном ответе звучит как заботливый консультант, а в следующем — как автоответчик службы поддержки из девяностых.
Особенно опасен один нюанс: модель произносит неверный ответ с той же спокойной и уверенной интонацией, что и верный. Пользователь не считывает разницу в надёжности — он считывает уверенность как компетентность. Раздвоенность личности тут работает не как забавный баг, а как источник доверия к неправильной информации.
Как перевести «дружелюбный» и «профессиональный» в правила, а не в прилагательные
Прилагательные из брендбука бесполезны для модели напрямую. «Дружелюбный» для одного разработчика означает эмодзи и восклицательные знаки, для другого — короткие фразы без канцелярита. Черту нужно разложить на измеримые параметры: длину предложений, лексику, которую можно и нельзя использовать, конкретные формулировки для типовых ситуаций — отказа, неуверенности, эскалации к человеку.
Хорошая модель для этого — фреймворк агентства R/GA, который описывает AI-ассистента через четыре элемента, а не через одну «личность»:
- Character — стиль речи, словарь, ритм фраз;
- Memory — что ассистент помнит о пользователе и как это использует;
- Intelligence — границы компетенции, что он умеет решать сам;
- Principles — этические и репутационные ограничения, которые не нарушаются никогда.
Это шире привычной «персоны из тона и голоса» и сразу задаёт операциональные точки: интеллект и память — это архитектурные решения, а не текст в промпте.
Есть и данные в пользу точной настройки, а не общих формулировок: в телеком-исследовании, охватившем 57 000 взаимодействий, совпадение личности бота с личностью пользователя — интроверта или экстраверта — улучшало и поведение покупателя, и продолжительность диалога. Абстрактный «дружелюбный тон для всех» работает хуже, чем откалиброванный под сегмент аудитории паттерн общения.
Документ персонажа и персонаж в production — разные объекты
Ключевая ошибка индустрии: persona существует в красивом PDF на гугл-диске, но не закодирована в system prompt. Если решение о том, как ассистент реагирует на грубость или на просьбу дать медицинский совет, не прописано в инструкции, выполняемой моделью в реальном времени — оно просто не существует. Фраза «You are a helpful, friendly assistant» ничего не решает: модель не знает, какой должна быть длина предложения, допустимы ли шутки, что делать при неуверенности в ответе.
| Persona-документ | Persona-в-production |
|---|---|
| Описывает характер словами: «тёплый», «экспертный», «с юмором» | Задаёт правила: длина фраз, лексика, шаблоны для отказа и эскалации |
| Живёт в презентации или wiki, читается один раз при запуске | Живёт в system prompt, фильтрах вывода, ограничениях доступа к инструментам |
| Не проверяется автоматически | Тестируется на конкретных сценариях перед релизом и мониторится после |
| Принадлежит бренд-команде «на бумаге» | Принадлежит продакт-менеджеру как версионированный артефакт продукта |
Почему одного промпта недостаточно: архитектура контроля персонажа
Полагаться только на system prompt небезопасно — модель может обойти инструкцию под давлением контекста, длинного диалога или манипулятивного запроса пользователя. Персонаж, который держится реально, строится на нескольких уровнях одновременно:
- System prompt — базовые правила стиля и границ.
- Tool permissions — какие действия и данные ассистенту разрешено вызывать.
- Output filtering — проверка ответа после генерации перед показом пользователю.
- Retrieval constraints — ограничения на то, какие источники можно использовать для ответа.
- Human review — ручная проверка проблемных или высокорисковых кейсов.
Каждый уровень ловит то, что пропустил предыдущий. Отсутствие этой многослойности, а не «плохой промпт», объясняет большинство публичных провалов брендовых ассистентов.
Где персонаж бьёт по репутации бренда
Самая частая ошибка — попытка сделать ассистента максимально человечным и эмоциональным. Это выглядит эффектно в презентации, но на практике загоняет продукт в uncanny valley: пользователи не доверяют боту, который «слишком старается» изображать чувства, и предпочитают чёткую компетентность театральной теплоте.
Вторая ошибка — юридический дисклеймер вместо продуманного отказа. Фраза вида «Я не могу дать медицинскую рекомендацию, обратитесь к врачу» разрушает персонажа и звучит как сбой системы. Работает вариант, спроектированный как часть характера: «Не дам конкретного медицинского совета, но помогу сформулировать вопросы для врача» — отказ, который не выпадает из голоса бренда и при этом закрывает юридический риск.
Третья ошибка — уверенный тон при неверных фактах. Если персонаж запрограммирован звучать одинаково убедительно всегда, ошибки становятся особенно опасны: пользователь не получает сигнала «здесь я не уверен».
Как проверить персонажа до запуска и не потерять его после
Перед релизом стоит прогнать ассистента через набор стресс-сценариев: агрессивный пользователь, запрос вне компетенции, просьба нарушить правило, длинный диалог с попыткой манипуляции тоном. Каждый ответ сравнивается не с «ощущением», а с конкретными правилами из спецификации — длиной фраз, лексикой, форматом отказа. Без такого прогона персонаж существует только в теории, и первым тестировщиком становится живой пользователь в проде, что почти всегда дороже.
После запуска характер деградирует градиентно, а не одномоментно. Обновление базовой модели меняет манеру формулировок даже при неизменном system prompt. Новый источник в retrieval-слое приносит факты в другой стилистике. Команда поддержки добавляет «временный» шаблон ответа на частую жалобу — и через полгода треть диалогов звучит не по спецификации, потому что никто не сверял их с ней с момента запуска. Поэтому персонажа нужно мониторить так же, как метрики конверсии: с регулярной выборкой реальных диалогов, сверкой с эталонными сценариями и версионированием промптов и фильтров, чтобы откатиться при регрессии.
Практический вывод простой: персонаж бренда в AI-продукте — это не творческая задача, которую закрывают один раз на этапе запуска, а операционный процесс с владельцем, метриками и регламентом проверки.
Актуальные статьи
МегаФон, BMW, ВТБ и ещё 240+ компаний. Смотрите как это выглядит в шоуриле:
В наше брендинговое агентство обращаются, чтобы заказать:
