ChatGPT API в helpdesk: собрали прототип за неделю - делимся архитектурой

В начале января мы писали, что один из приоритетов H1 - пилоты LLM в helpdesk. Тогда это было запланировано и немного абстрактно. Неделю назад OpenAI открыл API-доступ к GPT-3.5-turbo - той самой модели, которая стоит за ChatGPT, - и один из клиентов немедленно написал: «Ну и когда уже пилот?». Развернуться пришлось быстро.

Сейчас у нас работающий прототип. Не продакшн, не даже MVP - именно прототип, чтобы понять, что модель вообще умеет делать в реальном helpdesk-сценарии.

Зачем именно API, а не web-интерфейс

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

GPT-3.5-turbo это chat-completion модель: ей передаётся массив сообщений с ролями (system, user, assistant), она возвращает следующее сообщение. Токен стоит $0.002 за 1K - по сравнению с GPT-4, который ещё в закрытом доступе, это на порядок дешевле.

Архитектура прототипа

Стек намеренно минимальный - Python, официальный openai SDK, никаких оркестрационных фреймворков. Хотелось понять, что умеет сама модель, без лишних слоёв.

Поток обработки тикета:

тикет (текст + тема) 
  -> нормализация (убрать подписи, цитаты, форматирование)
  -> поиск по базе знаний (BM25 по индексу статей)
  -> сборка промпта (system + найденные статьи + текст тикета)
  -> GPT-3.5-turbo (chat completion)
  -> черновик ответа -> инженер на проверку

База знаний у клиента - внутренняя вики в Confluence. Мы выгрузили статьи в плоский текст, построили простой BM25-индекс на rank_bm25. Семантический поиск не закладывали - ключевые слова работают достаточно хорошо для технической документации, где терминология устойчивая.

Промпт устроен так: system-сообщение описывает роль (инженер поддержки конкретного продукта), контекст (найденные 2-3 статьи из базы знаний), инструкцию (предложи решение на основе документации, если не знаешь - скажи об этом прямо). Дальше - пользовательское сообщение с текстом тикета. Ответ - черновик для инженера, не готовый ответ клиенту.

Это принципиально: GPT не отвечает клиентам напрямую. Черновик видит инженер, правит, отправляет сам. Именно так клиент и хотел - снять рутину, не убрать человека из цепочки.

Что работает хорошо

Классификация типа проблемы. Модель уверенно разбирает, что перед ней - вопрос по настройке, баг, запрос на доступ или просьба объяснить. Для helpdesk с несколькими очередями это сразу даёт маршрутизацию без правил. Точность на тестовой выборке из 50 реальных тикетов - хорошая, ошибки в основном на пограничных случаях.

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

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

Что работает плохо

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

Чувствительность к качеству базы знаний. BM25 выдаёт то, что есть. Если статья устаревшая или написана плохо - GPT воспроизводит эту плохую статью в ответе, только чище и увереннее. Модель не знает, что документация устарела.

Длинный контекст дорожает. Если тащить в промпт три объёмные статьи, стоимость запроса растёт. У GPT-3.5-turbo лимит 4096 токенов на весь контекст включая ответ - при больших статьях это ощутимое ограничение.

Первые наблюдения за неделю

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

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

По стоимости API при текущем объёме тикетов клиента это несколько долларов в месяц. Даже если добавить сюда время на интеграцию - экономика выглядит разумно, если экономия инженерного времени реальная. Пока это гипотеза, не факт.

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