Мы разработали умную базу знаний, применив LLM и RAG подход

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

Привет, это Илья Долгополов, CEO «Технократии». Мы цифровизируем бизнес и разрабатываем ИТ-системы, а также развиваем компетенции в области искусственного интеллекта. В этом тексте расскажу, как мы сделали co-pilot ассистента, который отвечает на вопросы сотрудников. Поехали!

Мы в Технократии любим заморачиваться на процессах. А процессы всегда идут рука об руку с регламентами, гайдлайнами и сводами правил, которые должны давать ответы сотрудникам, когда у них появляются вопросы.

Но по нашему опыту, чем больше и опытнее становится компания, тем больше становится процессов, которые тянут за собой увеличение количества документальной базы. А еще добавьте сюда фактор размещения информации. Она может храниться в нескольких источниках — корпоративный Confluence, сайт компании, HRM-система и десятки других мест, где хранятся данные о процессах.

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

Эти факторы становятся «бутылочным горлышком» в процессах и утяжеляют адаптацию новых сотрудников и усложняют жизнь текущим членам команды. Очевидно, что проблему нужно решать. Но как?

Но дьявол кроется в мелочах. И если для решения нашей задачи использовать исключительно LLM, то могут возникнуть проблемы. Самая главная — LLM ничего не знает о регламентах Технократии, потому что они хранятся в нашем внутреннем контуре.

Из проблемы незнания вытекает другая — из-за того, что LLM не знает, как ответить на вопрос, начинает выдумывать информацию на ходу и периодически отвечать околесицу, которая не соответствует реальности. Это называется галлюцинирование.

Решение этой проблемы кажется очевидным — дайте модели больше данных.

Да, можно было бы дообучить модель на наших данных, но для адаптации LLM (не говоря уже о полной тренировке) потребовались бы сотни тысяч токенов, много времени, терпения и затрат на GPU-вычисления.

Но дата-сайентисты и ML-инженеры придумали решение этой проблемы и придумали надстройку над LLM, которая называется RAG.

Термин LLM у всех на слуху, и он расшифровывается как Large Language Model, что на русском языке звучит как «Большая Языковая Модель». Самые известные коммерческие модели сейчас — ChatGPT от OpenAI, GigaChat от Сбера и YandexGPT от Яндекса.

Главная задача LLM — генерировать человекоподобные ответы на запросы пользователей. Они могут это делать, потому что их обучают на петабайтах данных, а затем дообучают при помощи инструкций, чтобы ответ был максимально приближен к запросу пользователя.

Звучит очень классно, и LLM действительно работают на общих задачах. Но для решения описанной задачи LLM в чистом виде не смог бы давать правильные ответы. Если спросить у условного ChatGPT «Что такое Технократия», то мы бы получили ответ про форму правления и устройства общества. Что, в общем-то, правильно, но не решает нашу задачу.

И все дело в контексте — LLM не знает, что речь идет о компании «Технократия» из Казани, которая занимается цифровизацией бизнеса. И этот контекст нужно дать языковой модели.

И четыре абзаца спустя мы добираемся до темы из заголовка — методе RAG, что расшифровывается как Retrieval Augmented Generation.

Это подход к работе с большими языковыми моделями, при котором пользователь формулирует свой вопрос, а система автоматически добавляет дополнительный контекст из внешних источников в запрос. Таким образом, языковая модель получает более широкий и точный контекст для обработки и формирования ответа.

Чтобы было понятно, давайте вернемся к нашей задаче:

В итоге, если к LLM добавить RAG-систему, то на вопрос о Технократии наш ассистент будет отвечать не про форму правления, а про ИТ-компанию из Казани.

Мы верхнеуровнево поняли что такое RAG-модель. Теперь можно разобраться, как все это работает:

На всякий случай вот схема для более доступного понимания:

В общих чертах RAG-модель работает как-то так. Конечно, мы сознательно упрощали описание, и под капотом происходит много всего интересного, но это информация для отдельной статьи.

От описания теории и постановки задачи можно переходить к практическому описанию разработки MVP. На старте разработки у нас было представление, что мы хотим получить в итоге — ИИ-ассистент в виде чат-бота, который бы отвечал на вопросы о компании и корпоративных процессах.

Верхнеуровнево такой продукт состоит из двух частей: клиентская часть, с помощью которой пользователь задает вопросы и получает ответы, и серверная часть, внутри которой крутится связка LLM+RAG, которая отвечает на вопросы.

Кто входил в команду проекта:

Любой проект всегда должен начинаться со сбора бизнес-требований от клиента. Так как в нашем случае заказчиками были мы сами, то мы описали требования стейкхолдера — чат-бот в виде web-приложения, который должен отвечать на вопросы, связанные с процессами компании. Всё, как у коллег из OpenAI, только с акцентом на базу знаний Технократии.

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

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

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

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

В это время бизнес-аналитик собирал и структурировал необходимую информацию о компании. Источниками данных для него стали:

Итогом этой работы стал документ объемом в 500+ страниц текста и изображений, который был передан инженерам для настройки RAG-системы.

На этом этапе подключились специалисты по работе с искусственным интеллектом. Полученный от бизнес-аналитика документ нужно было разбить на смысловые части, превратить в числа, по сути, векторизировать (этим, кстати, занимается другая нейросеть) и сложить в векторную базу данных. Грубо говоря, на этом этапе и произошла первичная настройка RAG.

После этого этапа нужно было «подружить» RAG и LLM. В качестве LLM могут выступать как облачные модели вроде ChatGPT и GigaChat, или локальные решения вроде Mistral или LLaMA. На этом можно говорить, что бэкенд продукта был готов.

Теперь, чтобы ассистент мог полноценно работать, осталось только соединить фронтенд с бэкендом и захостить всё это на сервере. Чтобы продукт работал с минимальными задержками, в идеале нужен сервер с видеокартой (GPU), но нам для первичного тестирования хватило обычного CPU-сервера.

Альфа-версия продукта готова. Можно переходить к тестированию и донастройке ассистента.

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

На этом этапе мы поняли, что:

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

Собственно, на этом моменте завершилась разработка MVP нашего ассистента, которым сейчас пользуются сотрудники «Технократии». Всего на разработку и тестирование у команды ушло две недели.

Чтобы нагляднее продемонстрировать возможности ассистента, мы подготовили несколько скринкастов с типовыми запросами. Всего мы выделили три доменные зоны знаний: корпоративные процессы, экспертиза в профильных областях и информация о кейсах. Ниже примеры запросов из всех трех доменных зон.

Это только небольшая часть примеров того, как ассистент может отвечать на пользовательские запросы. Сервис функционирует считанные недели, и команда машинного обучения активно занимается улучшением ответов нейросети.

В этом кейсе мы показали, как бизнес может обуздать бюрократию для оптимизации процессов. Но онбординг и ответы на вопросы сотрудников — только малая толика возможностей нейросетей. Вот несколько вариантов того, как можно применять LLM и RAG-системы.

Техподдержка клиентов

Внедрение ИИ-ассистента в службу технической поддержки может позволить сократить время на обработку запросов клиентов, потому что нейросеть будет обращаться к базе знаний и отвечать на вопросы легкой и средней сложности. Если ИИ-ассистент не сможет сходу ответить на вопрос, то тогда он переведет клиента на профильного специалиста.

Такой подход может увеличить количество успешно закрытых клиентских заявок, улучшить качество ответов и сократить время реагирования.

Оптимизация работы отдела продаж

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

Анализ больших неструктурированных данных

LLM и RAG-системы умеют работать с большими данными, которые слабо поддаются структуризации, вроде электронных писем, отзывов пользователей, финансовых данных. Нейросети могут обрабатывать такие данные и помогать пользователям с построением аналитических дашбордов и генерацией выводов.

Усиление ИТ-разработки

Кажется, что это первая на очереди область, к которой можно и нужно применять LLM. Ключевыми вариантами видятся:

- работа с legacy-кодом, которого у крупных компаний за десятилетия разработки накапливается неприлично много.

- автоматическая генерация документации при написании кода. Важный процесс, которому уделено непростительно мало внимания.

- рефакторинг кода и код-ревью с целью поиска ошибок и устранения слабых мест в коде.

- co-pilot ассистенты, которые могут быть интегрированы в IDE-среду и помогать программисту писать код.

Юридический помощник

Анализ юридических документов — использование LLM для автоматической обработки и подготовки юридических документов. Это позволяет сократить время на обработку и повысить точность работы.

Автоматическая генерация договоров — создание договоров с использованием LLM.

Юридический ассистент — предоставление консультаций и ответов на правовые вопросы. Ассистент помогает подготовить документацию и даёт рекомендации по правовым вопросам.

Перечислять и фантазировать на тему «А куда еще можно применить LLM и RAG системы» можно очень долго. А мне пора заканчивать этот непростительно большой текст.

Если у вас есть вопросы о кейсе, то задавайте их в комментариях, или пишите в бот, если стеснятесь быть публичным. За искусственным интеллектом будущее, а чтобы быть в курсе будущего подписывайтесь на «Голос Технократии».