Привет, Habr! Меня зовут Александр Сулейкин, архитектор Big Data решений, к. т. н. и CEO ИТ‑компании «ДЮК Технологии». Совместно с нашим экспертом по внедрению LLM, Анатолием Лапковым, мы подготовили статью по теме внедрения умного помощника в крупной некоммерческой организации. Под капотом — базовая модель от Сбера GigaChat, однако вся обвязка и подход к решению задачи — наши собственные. И это то, о чем пойдет речь в статье.
Исходная проблема
Одна из главных проблем использования LLM — это галлюцинации, которые появляются в результате неверного трактования моделью тех или иных запросов. Одна из основных причин — это разбиение исходного текста на чанки, которое, зачастую, делается с ошибками или неточностями в силу разных причин. По данной теме и детальнее про процесс разбиения на чанки и особенности процесса можно почитать, например, в этой статье. Здесь лишь отметим, что процесс на данный момент сложно управляем, когда требуется повысить точность поиска наиболее релевантных векторов в векторной базе.
В последних трендах для разбиения на чанки стали использовать те же LLM — подробнее о методах разбиения текста на чанки можно найти, например, тут.
Однако, несмотря на все текущие достижения по теме нарезки чанков, проблема качества поиска информации в них все еще остается. Многие области знаний, в том числе и помощники технической поддержки пользователей для любой сферы — требуют более качественных и точных ответов модели.
Про умных помощников
Несмотря на относительную новизну тематики и технологий, генеративный ИИ набирает все большую популярность, и постепенно находится все больше и больше реальных успешных внедрений LLM в промышленных задачах. Одна из таких «типовых» задач, которая видится одной из наиболее перспективных для решения LLM — это умный помощник техподдержки, цифровой сотрудник, который сможет не только понимать и отвечать на вопросы пользователей, но и полностью автоматически заводить заявки в учетных системах и сервис‑десках, поддерживать базовый диалог с клиентом, обогащать свою базу знаний, а также постепенно дообучаться.
Задача автоматизации процессов техподдержки, регламентов ответов на типовые вопросы может быть достаточно неплохо шаблонизирована, по крайней мере в рамках одной и той же предметной области. Многие задачи являются по‑настоящему типовыми, и потенциал развития «умных» ассистентов / сотрудников тех. поддержки для LLM довольно неплохой. Причем речь может идти об очень серьезном уровне развития LLM для решения подобного рода задач уже в ближайшем будущем, особенно с учетом стремительного развития как базовых моделей (OpenAI, YandexGPT, GigaChat и др.), так и новых методов, решений, фреймворков, подходов и техник применения больших базовых моделей для решения узкоспециализированных задач бизнеса.
Подход на основе «Карты знаний»
«Карта знаний» — это RAG, в котором мы, разработчики, строго контролируем информацию, используемую для формирования ответа на запрос. Такой контроль достигается за счёт применения двух техник:
Выявление классов запросов и разработки классификатора запросов.
Извлечение и структурирование данных из исходной документации.
Например, если мы разрабатываем бота для технической поддержки какого‑либо сервиса, одним из классов запроса может быть регистрация в сервисе, такие как «Как получить учётную запись?», «Как зарегистрироваться в системе?» и т. п.
Для ответа не запросы данного класса, нам нужна та часть документации, которая описывает процесс регистрации.
Мы разрабатываем модуль, который с помощью LLM извлекает инструкцию из документации заказчика и сохраняем эту инструкцию в удобной и доступной форме, например в БД.
После этого разрабатываем классификатор запросов, в котором с помощью LLM определяем класс поступившего запроса, и если класс запроса относится к классу регистрации в системе, то простым и однозначным алгоритмом извлекаем подготовленную ранее инструкцию и передаём её LLM для формирования ответа.
В итоге мы получаем систему, в которой исключены галлюцинации.
Система даёт ответы только на те вопросы, по которым у неё есть информация. Более того, в отличие от RAG, построенных на векторных базах данных, для формирования ответа LLM подаётся точная и однозначная информация.
Побочным эффектом такого подхода является наличие чётких границ полномочий системы, и в случае поступления запроса, выходящего за такие границы, система однозначно об этом просигнализирует — будет использована заглушка, переключение на оператора. Поэтому данный подход применим лишь для случаев, когда есть понятный ограниченный список тем, где точность ответов очень важна и высоки имиджевые потери в случае неверных ответов помощника.
Также данный подход позволяет интегрировать систему с CRM, ERP, сервис‑десками и др. Если при обработке запроса мы точно знаем, о чём этот запрос (его класс), то мы знаем как на него подготовить ответ. Например, при запросе «Какой статус моей заявки?» (для упрощения условимся, что у пользователя может быть только одна заявка в один момент времени), мы можем подключиться к CRM, получить статус заявки и сформировать точный ответ. В этом случае, для данного класса запросов мы не разрабатываем экстрактор, но разрабатываем коннектор к учётной системе (или берем готовый доступный) и извлекаем данные для ответа «на ходу».
Case Study: как мы внедряли умного помощника на базе «Карты знаний» области поддержки пользователей и модели GigaChat
Описание задачи
Задача ставилась максимально просто — обработать обращения клиентов к техподдержку.
Ограничения проекта
В проекте было несколько ограничений, которые сильно влияли как на архитектуру решения, так и на некоторые концептуальные аспекты реализации:
Пожелание заказчика, чтобы базовая модель была отечественной и не использовать Open‑Source модели. Выбор, по сути, делался между YandexGPT и GigaChat.
Очень короткий срок реализации проекта — 1 месяц. Разработку делали в режиме нонстоп, при этом большая часть реальных документов (вопросов‑ответов пользователей за несколько лет эксплуатации тех. поддержки) поступило за неделю до сдачи проекта.
Несколько тематик, которые строго запрещалось освещать: обработка вопросов про политику, а также в регламентах значились новые регионы РФ (с которыми GigaChat ну очень плохо работал, по крайней мере — версия с цензурой)
Важна была качественная отработка запросов, вопрос имиджевых рисков стоял достаточно высоко. Требовалось в случае малейшей неуверенности в ответе — перенаправлять запрос на оператора
Проблемы реализации
Ключевой проблемой проекта оказались сроки предоставления информации заказчиком.
Пока заказчик готовил данные, мы разработали каркас системы. Подготовили инфраструктуру и методологию для тестирования помощника.
Как только заказчик предоставил данные, мы распределили классы запросов по разработчикам и работая параллельно, быстро научили бота работать в службе технической поддержки заказчика.
Другая проблема — это ответы GigaChat по‑разному на одни и те же вопросы, сложности с отключением цензуры и проблемы ответов на определенные темы (например, военно‑политические).
Архитектура
Общая схема архитектуры решения на основе реализованного нами подхода выглядит следующим образом:
Архитектура выглядит достаточно просто, основные трудозатраты уходят, помимо разработки каркаса проекта, на обработку каждой темы. Однако такой подход позволяет максимально точно обрабатывать входящие запросы, классифицировать и находить релевантные куски структурированного текста в базе знаний.
Процесс экстракции и индексирования текста из входящих документов — отдельный процесс, который делается независимо. Для него в данном проекте использовалась модель ChatGPT от OpenAI ввиду сжатых сроков внедрения, однако в планах экстрактор также переводить на использование GigaChat (здесь ожидаем много интересного!) и реализацию интерфейса для загрузки новых документов и переиндексацию (панель администратора).
Результаты
В результате мы получили бота, который отвечает на самые частые запросы с точностью больше 90%. Бот имеет строгие рамки полномочий и в случае поступления запроса, на который бот не должен отвечать, передаёт запрос сотруднику технической поддержки. Полученный бот не способен что‑либо придумать от себя и всегда работает строго по заложенным в него инструкциям.
Что дальше?
Дальше планируем совершенствовать наше решение — уже есть наработки по фреймворку «Умного поиска» по документации с русифицированным интерфейсом системы. Планируем подход на основе «Карты знаний» встроить туда, а в остальных случаях, когда ничего не нашлось и «Карта знаний» по тематике еще не сформирована — будет использоваться стандартный подход на векторах из коробки системы (лучше, чем ничего). Так, работаем в сторону гибридного поиска. Пока этот вариант нам видится наиболее оптимальным на данном этапе, однако прогнозируем совершенствование и автоматизацию подхода «Карта знаний» со временем, по крайней мере — для конкретной области знаний.
Будем рады предоставить данную систему в пилотное использование — пишите в ЛС, кому интересно.
Общая схема развития помощника на основе «Карты знаний» нам представляется следующим образом:
