Генеративный ИИ как штатный инженер техподдержки: настройка, внедрение, реальные ошибки

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

Когда инженером становится нейросеть

Мы решили дать генеративному ИИ не просто роль помощника, а полноценное место в нашей команде поддержки. Не бот, не ассистент, а инженер, которому поступают тикеты, который общается с пользователями, пишет SQL-запросы, читает логи и даже создаёт баг-репорты. Звучит как шутка, но через неделю пилота стало понятно: это не шутка.
Система, построенная на модели с контекстом в 32k токенов, принимала тикеты через internal API. Первое, что удивило — она сама просила уточнений. Например, при запросе «не работает отчёт по продажам» бот ответил: «Какая конкретно метрика не отображается и за какой период?» — и это не было шаблоном.
Но реальность быстро напомнила, что ИИ — не человек. Он не умеет сомневаться. Если его уверенность ложная, последствия могут быть очень человеческими: неправильный SQL-патч в проде, случайный откат миграций или утечка логов. С этим мы и столкнулись в первые дни.

Настройка контекста и контроль уверенности

Чтобы нейросеть могла действительно «думать» как инженер, ей нужен контекст — не только текст тикета, но и история инцидентов, структура базы, список релизов.
Мы сделали слой обёртки, который собирает контекст на лету. Пример кода на Python:

def build_context(ticket_id): ticket = get_ticket_text(ticket_id) recent_tickets = get_recent_tickets(ticket.user_id, limit=5) db_schema = get_db_schema(‘production’) recent_commits = get_recent_commits(‘main’, limit=3) context = f»Ticket:n{ticket}nnSimilar issues:n{recent_tickets}nnDB schema:n{db_schema}nnRecent commits:n{recent_commits}» return context

Контекст отправляется в LLM-модель вместе с тикетом.
Но главная проблема — уверенность ответа. Мы встроили метрику уверенности на основе внутреннего temperature-скора: если модель слишком «уверена» в ответе на недостаточных данных, она получает отрицательную обратную связь.
Был случай, когда ИИ уверенно «решил» проблему с отчётом, изменив схему таблицы, что в итоге сломало дашборд для 800 пользователей. После этого мы добавили слой симуляции: каждый SQL-запрос сначала исполняется в тестовой БД с shadow-данными.

Обучение на внутренних тикетах и ловушки данных

Нам казалось логичным обучить модель на истории тикетов — около 60 000 обращений за два года. Но оказалось, что в них слишком много неструктурированных эмоций и внутренних мемов. Пример из реального тикета: «опять умер кафка-кластер, кто ж его знал» — ИИ интерпретировал как факт, а не сарказм, и начал приоритизировать Kafka-ошибки даже там, где их не было.
Чтобы очистить датасет, мы применили простейший фильтр на Python:

import re def clean_ticket(text): if «¯\_(ツ)_/¯» in text or «лол» in text.lower(): return «» text = re.sub(r’s+’, ‘ ‘, text) return text.strip()

Дальше — fine-tuning с помощью собственного инструмента, который добавляет инструкцию «не делай выводы без данных». Результат — модель перестала «угадывать», но стала задавать больше уточняющих вопросов. Пользователи даже начали шутить, что «бот стал подозрительно умным и вежливым».

Реальные ошибки, которые нас спасли

Самая поучительная ошибка произошла, когда ИИ получил два одинаковых тикета с разными ID. Он решил, что один — дубликат, и автоматически закрыл оба. Потребовалось два дня, чтобы понять, что закрыт был тикет клиента с SLA-1.
Мы ввели простую, но эффективную защиту — audit trail, который хранит весь reasoning модели.

def audit_log(request, response, score): with open(«audit_log.txt», «a») as f: f.write(f»n[{datetime.now()}]nREQ: {request}nRESP: {response}nCONF: {score}n{‘-‘*50}n»)

Теперь каждое решение ИИ можно проверить, как если бы это был инженер, оставивший запись в Jira.
Показательно: количество критичных ошибок упало на 73% после введения аудита.
Но осталась тонкая грань — ответственность. Кто виноват, если ошибка произошла? Модель? Архитектор? Команда поддержки? Ответ неочевиден. В нашем случае мы относимся к ИИ как к члену команды — у него есть свои метрики, свои «ошибки» и даже внутренний KPI (да, звучит странно, но это работает).

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

Через полгода ИИ-инженер стал не просто обрабатывать тикеты, но и учить новых сотрудников. Мы добавили функцию контекстного пояснения: когда человек спрашивает «почему бот так ответил», система достаёт кусок reasoning и объясняет логику принятого решения.
Это неожиданно превратило проект поддержки в образовательную платформу.
Но главный эффект — снижение когнитивной нагрузки. Раньше инженеры по 6 часов подряд отвечали на похожие тикеты. Теперь они фокусируются на сложных задачах, а ИИ берёт рутину.

Конечно, не всё идеально. Иногда он всё ещё отвечает «в духе техподдержки Windows 98» или начинает писать извинения в стихах. Но если честно, я давно не видел, чтобы инструмент так быстро адаптировался к культуре команды.

Если бы вы могли нанять ИИ-инженера в свою службу поддержки, сделали бы это?

Источник: habr.com