GPT-помощник для службы поддержки: как сделать без галлюцинаций

Галлюцинация в контексте поддержки - это когда AI-ассистент уверенно говорит клиенту то, чего нет: несуществующий тариф, неверные условия возврата, выдуманные сроки. Это хуже, чем «не знаю» - потому что клиент верит и потом злится.

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

Почему GPT галлюцинирует и когда это критично

Большая языковая модель не «знает» ваши данные. Она генерирует наиболее вероятный следующий токен на основе всего, что видела при обучении. Когда вопрос выходит за пределы её знаний - она не говорит «не знаю», а генерирует правдоподобный ответ.

Для творческих задач это полезное свойство. Для поддержки - источник рисков.

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

Когда галлюцинация критична: точные условия сервиса (цены, сроки, ограничения), юридически значимые утверждения, инструкции по действиям с финансовыми последствиями.

Хороший AI-помощник для поддержки знает разницу и ведёт себя по-разному в каждом случае.

Архитектура: RAG как основа

RAG (Retrieval-Augmented Generation) - подход, при котором модель не полагается на обученные знания, а получает релевантный контекст из базы знаний перед генерацией ответа.

Схема работы:

Вопрос клиента
       |
       v
[Поиск по базе знаний] --> [Релевантные фрагменты]
       |
       v
[LLM + контекст + системный промпт]
       |
       v
[Ответ с цитатой источника]

Вместо «придумай ответ про условия возврата» - «вот выдержка из документа об условиях возврата, ответь на вопрос клиента, используя только эту информацию».

Компоненты системы

1. База знаний. Документы, которые содержат правильные ответы: FAQ, регламенты, описание услуг, условия договора, инструкции по использованию продукта. Хранятся как структурированный текст или Markdown.

2. Векторное хранилище. Каждый фрагмент документа конвертируется в числовой вектор (embedding) и сохраняется в векторной БД (Chroma, Weaviate, pgvector). При поиске вопрос клиента тоже конвертируется в вектор, находятся ближайшие фрагменты по семантическому смыслу.

3. Языковая модель. GPT-4o, Claude 3.5 Sonnet или аналог. Получает: вопрос клиента + найденные фрагменты + системный промпт с инструкциями.

4. Системный промпт с ограничениями. Это ключевая часть. Промпт должен явно говорить модели, что делать когда информации нет.

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

Плохой системный промпт:

Ты помощник службы поддержки компании X. Помогай клиентам.

Хороший системный промпт:

Ты помощник службы поддержки компании X.

ПРАВИЛА:
1. Отвечай только на основе предоставленных фрагментов документации.
2. Если в документации нет ответа на вопрос - скажи прямо:
   "Этого я не нашёл в документации. Переключу вас на оператора."
   НЕ придумывай ответ.
3. Не давай обещаний, которых нет в документации.
4. При неуверенности в точности цифры (цена, срок) - всегда добавляй
   "уточните актуальные условия у оператора".
5. Цитируй источник: [из документа "Название документа"].

ТОН: вежливый, конкретный, без лишних слов.

Ключевой элемент - явное разрешение говорить «не знаю» и инструкция что делать в этом случае.

Fallback: когда и как передавать оператору

Передача оператору должна происходить по четырём триггерам.

Триггер 1. Информации нет в базе знаний

Когда поиск возвращает результаты с низкой релевантностью (score ниже порога) или ни одного результата - система не должна пытаться ответить «из головы». Вместо этого:

if max_similarity_score < THRESHOLD:
    return escalate_to_operator(
        reason="no_knowledge",
        message="Этот вопрос требует уточнения у специалиста"
    )

Порог подбирается эмпирически. Начальная точка: 0.7 для cosine similarity.

Триггер 2. Ключевые слова высокого риска

Независимо от уверенности модели, некоторые темы должны идти к человеку:

• Жалобы и конфликтные ситуации
• Запросы о возвратах на крупные суммы
• Юридические вопросы и претензии
• Технические инциденты («у меня не работает», «потерял данные»)

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

Триггер 3. Несколько неудачных попыток

Если клиент трижды переформулировал вопрос или написал «не понимаю», «не то» - автоматически эскалируем:

if user_frustration_signals >= 2:
    return escalate_to_operator(
        reason="repeated_misunderstanding",
        message="Переключаю на оператора - он разберётся точнее"
    )

Триггер 4. Явная просьба клиента

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

Эвалюация: как мерить качество ответов

Запустить RAG-систему - половина работы. Вторая половина - понять, насколько хорошо она работает и что улучшать.

Метрики для оценки

Faithfulness (верность источнику): ответ содержит только то, что есть в найденных фрагментах. Измеряется автоматически: берём ответ и фрагменты, просим LLM оценить, есть ли в ответе утверждения, которых нет в фрагментах.

Answer Relevance (релевантность ответа): ответ отвечает на заданный вопрос. Оценивается: насколько хорошо из ответа можно восстановить исходный вопрос.

Context Precision (точность контекста): найденные фрагменты действительно релевантны вопросу. Если поиск возвращает мусор - модель не сможет ответить правильно, даже если генерация идеальна.

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

Целевые значения из практики:

• Faithfulness: выше 0.85
• Answer Relevance: выше 0.80
• Escalation Rate: 15-30% в зависимости от сложности домена

Инструменты для эвалюации

RAGAS - open source библиотека для автоматической оценки RAG-систем. Считает метрики faithfulness, answer relevance, context precision. Запускается на датасете вопрос-ответ.

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy

result = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy]
)

Ручная проверка выборки: раз в неделю просматриваем 20-30 реальных диалогов. Ищем галлюцинации, неуместные эскалации, повторяющиеся «не знаю» на вопросы, которые должны быть в базе знаний.

Поддержание актуальности базы знаний

RAG работает только если база знаний актуальна. Это организационная, а не техническая задача.

Процесс обновления:

• Назначьте ответственного за базу знаний (обычно это product owner или руководитель поддержки)
• При изменении условий сервиса, цен, регламентов - обновление базы знаний идёт параллельно с обновлением публичных документов
• Добавляйте новые FAQ на основе реальных вопросов: если оператор ответил на один и тот же вопрос трижды за неделю - это сигнал добавить в базу

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

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

Типовые ошибки при реализации

Ошибка 1. Слишком большие чанки документов

Если разбивать документы на слишком большие фрагменты, поиск возвращает много нерелевантного текста. Оптимальный размер чанка: 200-500 токенов с перекрытием 20-30%.

Ошибка 2. Один промпт на все типы вопросов

Вопрос «как пользоваться функцией X» требует другого тона и глубины ответа, чем «у меня не работает Y». Используйте классификатор намерений для выбора шаблона промпта.

Ошибка 3. Игнорировать историю диалога

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

Ошибка 4. Не обновлять базу знаний

База, написанная при запуске и не обновлявшаяся - источник устаревших ответов. Через полгода это хуже, чем отсутствие базы знаний.

Ошибка 5. Нет мониторинга в продакшне

Без мониторинга вы не знаете, как система ведёт себя на реальных вопросах. Логируйте каждый диалог, меряйте метрики качества на живом трафике, настройте алерт на аномальный рост escalation rate.

Стек для MVP

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

Хранение и поиск:

• pgvector (если уже есть PostgreSQL) или Chroma (если нет БД)
• OpenAI text-embedding-3-small для векторизации

Языковая модель:

• gpt-4o-mini для большинства запросов (дешевле, быстрее)
• gpt-4o для сложных случаев или при низкой уверенности

Оркестрация:

• LangChain или LlamaIndex - готовые компоненты для RAG
• Или собственная реализация для полного контроля

Мониторинг:

• Логи в PostgreSQL или ClickHouse
• RAGAS для периодической эвалюации
• Алерт при escalation rate выше порога

MVP можно собрать за 2-4 недели разработки, если база знаний уже структурирована.

Примерная стоимость операции

Для ориентира: система на gpt-4o-mini с RAG на 500 000 входящих токенов в месяц стоит около 150-300 рублей в месяц на модель. Основная стоимость - разработка и поддержка системы, а не сам LLM.

При объёме 5 000 диалогов в месяц и средней длине диалога 1 000 токенов - это 5 миллионов входящих токенов. При текущих ценах OpenAI - около 750-1 500 рублей в месяц. Сравните с зарплатой одного оператора поддержки.

Следующие шаги

Если вы рассматриваете AI-ассистент для поддержки, начните с вопроса: что должна уметь система в первые 30 дней? Не «автоматизировать всю поддержку», а «ответить на 30 самых частых вопросов без участия оператора».

Это задача на 2-4 недели. Остальное - итерации.

Подробнее о нашем подходе к внедрению AI-ассистентов - на странице /services/ai-assistant/.

Если нужна именно база знаний с семантическим поиском - читайте про /services/rag-knowledge-base/.

Про гибридную модель где AI работает вместе с операторами - в статье «Бот или живой оператор? Когда что выбрать в 2026».

---

Готовы внедрить?

Расскажите, какие вопросы получает ваша поддержка чаще всего - оценим, что можно автоматизировать с RAG и что нужно оставить операторам.

Обсудить AI-ассистент для поддержки