Как мы сделали ИИ для внутренней документации и сэкономили клиенту более 800 000р в месяц

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

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

Проведя анализ и пообщавшись с клиентом, мы подобрали оптимальное решение, которое помогло сэкономить значительную часть ресурсов и удовлетворило потребности клиента Мы разработали систему на основе искусственного интеллекта, которая отвечает на запросы работников по базе данных (БД), состоящей из документов компании. При этом, мы сделали упор на возможность добавления данных в БД, что сделало систему более гибкой.

Для многих не секрет, что языковые модели (LLM - Large Language Models) способны решать широкий спектр задач, и в последнее время эффективно прогрессируют.

В основе спроектированного нами решения лежит именно такой вид нейросетей. В этой части мы кратко пройдемся по основным особенностям архитектуры и дадим общее представление о разработанной системе максимально простым языком. Если интересно узнать более подробно о работе системы - welcome to комментарии, на все с радостью ответим)

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

Технология, которую мы использовали называется RAG (Retrieval-Augmented Generation). Глобально работа системы состоит из двух этапов:

На этом этапе происходит форматирование данных, преобразование их в так называемые embedding’и и заполнение ими векторной базы данных.

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

Одним из них было то, что далеко не все документы были в правильном формате. Для работы системы необходимо вытащить текст и изображения из файлов, что становится проблемой, когда файлы представляют собой сканы документов. Мы решали эту задачу, используя алгоритмы OCR (Optical Character Recognition)

После работы с документами текст и изображения преобразовываются в вектора или embedding’и. Эти векторные представления делятся на равные части и добавляются в специальную векторную базу данных, откуда после будут вытаскиваться наиболее релевантные ответы на запросы пользователя.

Сформированная база данных располагается на серверах клиента. Однако это не единственное возможное решение, БД также может находится и в облаке, но по запросу заказчика мы развернули ее локально.

Вот мы и дошли до момента, где в игру вступает та самая LLM (Large Language Model). Здесь модель необходима для формирования репрезентативного ответа из набора чисел. Ниже вы можете увидеть схему, иллюстрирующую работу этого этапа.

Прежде чем данные поступят в модель они проходят проверку на сходство с запросом пользователя. Запрос так же преобразуется в embedding, а затем сравнивается с embedding’ами в базе данных, выбираются топ подходящих ответов и передаются в LLM.

Дальше идет “магия” искусственного интеллекта и мы получаем ответ в виде текста с указанием ссылок на первоисточник. Немного prompt engineering’а (настройка LLM при помощи текстовых запросов, prompt’ов) и все готово.

Мы уже говорили о том, что база данных была развернута на серверах клиента. Но для чего?

В нашей задаче было необходимо отсутствие утечек данных и работа системы in house, в контуре компании клиента. Нам было важно соблюсти это условие и поэтому мы также установили модель на серверах клиента, заранее обговорив необходимые ресурсы для запуска.

Мы могли бы использовать открытые решения в виде API (Application Programming Interface) крупных моделей, например, OpenAI, но тогда данные клиента были бы не защищены.

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

Проводя исследование мы выяснили, какие затраты компания клиента несет в связи с неэффективной работой с внутренней документацией.

По нашим данным, в среднем один работник тратил 2 часа на поиск информации в день, при средней часовой оплате труда в 700р (со всеми налогами). Принимая среднее количество рабочих дней в месяц как 21, а количество работников пользующихся системой за 30, получаем следующие вычисления:

Итого: более 800 000р. в месяц, мы довольны результатом! (очень грубые вычисления, но тем не менее)

В этой статье мы описали один из случаев, когда ИИ может быть полезен в реальных задачах и приносить реальные результаты. Раскрыли тонкости работы системы на основе LLM (Large Languge Model) и разобрали технический принцип работы RAG (Retrieval-Augmented Generation).

Надеемся, читать про данный кейс вам было интересно! Ждем вашу обратную связь в комментариях)

Вскоре мы разберем еще несколько наших проектов и покажем результаты их работы!