Шаблонный промпт вида «Ты — вежливый оператор поддержки, помоги клиенту» живёт ровно до первого сложного обращения. Дальше модель начинает пересказывать вопрос, извиняться и выдавать общие фразы. Проблема не в модели, а в том, что промпт написан как реплика, а не как рабочий регламент.

Почему шаблоны перестают работать

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

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

Что заменить шаблон

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

Роль и границы. Кто отвечает, что входит в его компетенцию, что категорически запрещено (обещать сроки, называть цены вне прайса, давать юридические гарантии).

Контекст. Данные клиента и заказа из CRM или 1С: тариф, статус обращения, история, тип договора. Модель должна опираться на факты, а не на общие знания.

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

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

Практические шаги

Начните с корпуса реальных диалогов — 300–500 обращений из Helpdesk, почты и мессенджеров за последние месяцы. Из них собирается таксономия на 15–30 сценариев: именно она показывает, где один промпт нужен, а где пять.

Далее — эталонные ответы на каждый сценарий, согласованные с руководителем поддержки. Это одновременно и обучающий материал, и тестовый набор: при любом изменении промпта прогоняйте его целиком и сравнивайте с эталоном по фактам, а не по стилю.

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

Российская специфика

В большинстве проектов переписка содержит персональные данные, поэтому модели разворачивают на своих серверах — локальные LLM или приватный контур. Промпт в такой схеме дополняется RAG-поиском по внутренней базе знаний: инструкциям, регламентам, договорам, номенклатуре в 1С.

Отдельная задача — интеграции. Ответ должен собираться из актуальных данных Битрикс24, amoCRM, 1С:УТ или самописной учётной системы, иначе модель снова начнёт угадывать. Хорошо работает связка: промпт задаёт логику, RAG даёт факты, API — статусы и действия.

Что убивает качество

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

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

Как мы можем помочь

Мы настраиваем промпты и RAG-контуры для поддержки на приватных моделях, подключаем их к 1С и CRM, собираем тестовые наборы и метрики качества. Начинаем с аудита ваших обращений и пилота на одном сценарии. Обсудить проект