Эксперимент, начавшийся как попытка автоматизировать ответы на тикеты, закончился созданием почти самостоятельного “сотрудника” службы поддержки. В статье рассказываю, как мы внедряли генеративную модель в техподдержку, как настраивали контекст, ловили баги. Много практики, немного самоиронии и код, который заставил 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» или начинает писать извинения в стихах. Но если честно, я давно не видел, чтобы инструмент так быстро адаптировался к культуре команды.
Если бы вы могли нанять ИИ-инженера в свою службу поддержки, сделали бы это?
Автор: etydovprek
