LLM-агент на IT-хелпдеске: первый месяц в проде

Примерно три месяца назад мы запустили LLM-агента на внутреннем IT-хелпдеске у одного из клиентов - производственная компания, около 600 пользователей, три первой линии поддержки и непрерывный поток однотипных тикетов. Месяц работы в проде дал достаточно материала, чтобы написать по-честному - без победных реляций и без нытья о «незрелости технологии».

Как это устроено

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

В качестве модели использовали GigaChat API - требование клиента по локализации данных, не наш выбор и не наша реклама. Работает.

Что агент закрыл сам

Первая линия - это в основном три типа обращений: «не могу войти», «не работает принтер / VPN / почта», «как это сделать в [корпоративной системе]». По нашим подсчётам, около 40% тикетов первого месяца агент обработал без участия человека - пользователь получил ответ, отметил тикет решённым, вопрос закрыт.

Лучше всего агент справляется с инструктивными запросами: пошаговые инструкции по настройке VPN, объяснение как подключить принтер, как заполнить заявку в HR-системе. Там у него прямой доступ к актуальным статьям базы знаний и он не импровизирует - просто воспроизводит с адаптацией под вопрос. Качество ответов в этой категории - лучше среднего ответа от первой линии, потому что первая линия иногда ленится открывать Confluence и пишет по памяти.

Где агент ошибался

Честный раздел, потому что ошибки были и они показательные.

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

Второе - излишняя уверенность в устаревших данных. База знаний не обновлялась с момента индексации. Агент отвечал про старый адрес внутреннего портала, который сменился две недели назад. Пользователь следовал инструкции и получал 404. Это не баг агента - это баг процесса поддержки базы знаний, но агент его усилил, потому что отвечал с полной уверенностью.

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

Как настраивали guardrails

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

• Порог уверенности на закрытие. Агент закрывает тикет самостоятельно только если нашёл один явный источник и косинусное расстояние выше порога. Если источников несколько с близкими весами - эскалирует. Это срезало категорию галлюцинаций на стыке.
• Плашка с датой источника. В каждом ответе агент теперь показывает дату последнего обновления статьи, из которой взял ответ. «Инструкция актуальна на 15 ноября 2024» - пользователь видит и может усомниться. Простой, почти глупый механизм, но снял половину жалоб на устаревшие данные.
• Структурированный черновик эскалации. При передаче тикету инженеру агент теперь формирует блок: что спросил пользователь, какие статьи нашёл, почему счёл недостаточными, что рекомендует уточнить. Инженеры это оценили - время обработки эскалированных тикетов сократилось ощутимо.

Что из этого следует

Месяц - это мало для выводов, но кое-что уже понятно.

Агент хорошо работает как первая линия на хорошо задокументированных областях. Там, где документации нет или она дырявая - агент проблему не решает, а маскирует и усиливает. Это не аргумент «не внедряй», это аргумент «сначала разберись с базой знаний».

Guardrails не проектируются заранее в полном объёме - они вырастают из конкретных ошибок конкретного агента в конкретном контексте. Архитектурные соображения про безопасность и надёжность хороши на бумаге, но реальные фильтры появляются, когда смотришь на логи и видишь, как именно он ошибается.

Клиент доволен - не потому что агент идеален, а потому что первая линия теперь реально занимается сложными случаями, а не объясняет в пятый раз, как подключить VPN. Это само по себе не маленький результат.

Продолжаем. По итогам трёх месяцев - напишем предметнее с цифрами.