Как агент-консультант по 1С:УНФ прошёл путь от RAG-прототипа до продакшна

Служба поддержки компании Айтон, которая более двадцати лет внедряет 1С:УНФ («Управление нашей фирмой»), принимает вопрос примерно раз в пять секунд — около 6 тысяч в день и порядка 100 тысяч в месяц. Все они попадают в единую очередь без приоритизации: простой вопрос ждёт за сложным многошаговым кейсом одинаково долго. Клиент с тривиальным запросом может получить ответ через несколько дней. При этом 40–50% вопросов повторяются: разные клиенты спрашивают одно и то же.

Параллельно существует структурная проблема с персоналом. Чтобы консультант мог уверенно закрывать большинство обращений, ему нужно около шести месяцев погружения в продукт. Значительная часть специалистов после этого уходит в другие направления — и цикл обучения запускается с нуля. Айтон внутри называет это «фабрикой консультантов»: постоянные вложения в людей без накопления институциональной памяти.

Именно с этой двойной проблемой — очередью и текучкой — к команде LLMStart.ru обратился Айтон. ИИ-инженер Сергей Смирнов описывает подход, который лёг в основу проекта: архитектура не предшествует измерениям, а следует за ними. Там, где данные говорили «достаточно простого RAG», команда оставалась на простом RAG. Там, где показывали, что прямой цепочки уже мало, — двигались к агенту.

RAG (Retrieval-Augmented Generation) — это подход, при котором языковая модель перед генерацией ответа получает релевантные фрагменты из базы знаний. Это стандартная отправная точка для корпоративных ИИ-ассистентов: модель не «знает» продукт наизусть, но умеет искать нужное в документации и формулировать ответ. Агент — следующий уровень: система, которая может задавать уточняющие вопросы, работать с историей диалога, обрабатывать изображения и принимать решения о следующем шаге.

Проект разбили на два этапа. Первый — проверка центральной гипотезы: даёт ли связка «языковая модель + поиск по базе знаний» ответы, достаточные для использования консультантами. Из прототипа намеренно исключили историю диалога, обработку скриншотов и крайние случаи — всё, что понадобится позже, но не влияет на ответ на главный вопрос. Второй этап — развитие до полноценного агента с выходом на прямой канал для клиентов.

До первой строчки кода команда провела масштабный анализ данных. На входе — два источника: несколько десятков тысяч сообщений из Telegram-поддержки и около 500 документов базы знаний. Из диалогов прогнали через анализ около 25 000 сообщений. Скользящим окном они свернулись в 618 контекстных окон, из которых извлекли 1 985 черновых пар «вопрос — ответ». После фильтрации — только стандартный функционал 1С:УНФ, без клиентских кастомизаций — осталось 972 пары, то есть 49% от извлечённого. Эти пары не стали датасетом для оценки бота: они дали понимание того, как пользователи реально формулируют запросы и в каком стиле отвечают консультанты.

Валидационный датасет собрали отдельно. Поскольку на этапе прототипа выделять экспертов для ручной разметки было нецелесообразно, пары синтезировали с опорой на реальные диалоги: модель генерировала вопросы не произвольно, а в стилистике живых обращений в поддержку, а эталонные ответы брались из официальной методической базы. Получилось 110 пар, стратифицированных по 20 темам — по 3–5 вопросов на каждую. Именно по этому датасету автоматически измерялось качество на каждом шаге, а мониторинг каждого запроса был включён с первого дня.

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