Настроить Сookie (куки) 🍪
Мы используем куки, чтобы вам было удобнее.
И чтобы маркетолог не грустил.
Настроить Сookie (куки) 🍪
Настройки (куки)
Cookies (куки) необходимые для корректной работы сайта нельзя отключить. Остальные вы можете настроить.
Обязательные Cookies (куки)
Без них никак 🙂
Эти cookie (куки) отвечают за базовую работу сайта. Они сохраняют ваши настройки, помогают войти в аккаунт и обеспечивают работу форм. Отключить их нельзя, а то сайт частично перестанет работать.
Аналитические Cookies (куки)
Disabled
Печеньки, которые помогают 🍪
Эти cookie (куки) собирают анонимную статистику о работе сайта. Благодаря им мы понимаем, что вам нравится, что можно улучшить и какие наши идеи действительно работают. В общем, делаем сайт удобнее с помощью данных.
Рекламные Cookies (куки)
Disabled
Чтобы реклама была интересной 🎯
Эти cookie (куки) помогают рекламным сервисам показывать вам объявления, которые хотя бы имеют отношение к вашим интересам. А еще следят, чтобы одна и та же реклама не преследовала вас до конца интернета. Ну, по крайней мере, стараются.
Обучить модель опираться в ответах только на информацию накопленной базы данных, а не искать дополнительные данные в сети.
Особенность проекта
Искусственный интеллект

ИИ-ассистент
для консультаций по 152-ФЗ

Задача

Автоматизировать процесс первичных консультаций по 152-ФЗ на базе искусственного интеллекта.
Заказчик работает в сфере консультирования по 152-ФЗ. Клиенты, операторы персональных данных, задают вопросы, на которые нельзя отвечать примерно: цена ошибки — штраф, иск от субъекта данных, потеря репутации. Мы собрали ИИ решение на базе RAG, где модель получает релевантные фрагменты из проверенной базы знаний и формирует ответ на их основе.

Наш заказчик

Задача

На старте мы получили сформированный набор основных требований к сервису:

  • принимать вопрос пользователя через API;
  • искать релевантные фрагменты в собственной базе знаний;
  • передавать найденный контекст в LLM;
  • возвращать ответ в чат;
  • учитывать тарифные ограничения;
  • хранить историю диалогов;
  • управлять базой знаний через админку;
  • сравнивать модели по качеству, скорости и стоимости.

До начала проекта функция «задать вопрос и получить автоматический ответ по базе знаний» как продукт не существовала. У заказчика была предметная база для консультантов в табличных форматах: структурированные вопросы, ответы, ссылки на источники и материалы по судебной практике. На эти данные опирались сотрудники при работе с клиентами. Нашей задачей стало преобразовать базу в рабочий ИИ-сервис.


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

Архитектура:
RAG поверх Yandex Cloud

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

Разработанное решение реализовано как контейнерное приложение. Сначала рассматривали Cloud Functions, но контейнер подошёл лучше, потому что он дал больше контроля над развёртыванием, зависимостями и работой микросервиса.

Схема обработки одного запроса:
  1. Пользователь отправляет вопрос в чат.
  2. Чат передаёт запрос в микросервис.
  3. Микросервис ищет похожие фрагменты в базе знаний через эмбеддинги (семантический поиск).
  4. Найденные фрагменты собираются в контекст.
  5. Языковая модель получает вопрос вместе с контекстом.
  6. Модель генерирует ответ, опираясь исключительно на переданные данные.
  7. Микросервис возвращает ответ в чат через API.
Закрытый контур RAG решает сразу две задачи: защищает чувствительные данные базы от внешних угроз и полностью исключает возможность для LLM обращаться к внешним источникам. В юридической предметной области это критичное условие, «галлюцинации» ИИ-модели здесь недопустимы.

Почему российская модель и почему Yandex

Заказчик изначально определил требование: вся инфраструктура должна находиться на территории России. Это отвечает требованиям регуляторов и позволяет не зависеть от иностранного ПО. Особенно важно было, чтобы данные не уходили за пределы страны и, к тому же, зарубежные модели не принимают российские карты и блокируют российские IP.

Для проекта была выбрана Yandex AI Studio и инфраструктура Yandex Cloud, а база знаний хранится в Yandex Object Storage. Не смотря на то, что архитектура Yandex Cloud существенно отличается от зарубежных платформ, с которыми наша команда работала ранее, мы взяли на себя риски работы с новым инструментом. При этом часть конфигурации системы разрабатывалась прямо по ходу проекта.

Работа с базой знаний

На старте заказчик передал базу из 260 кейсов в двух Excel-форматах:
  1. Вопрос - ответ - источник (данные на основе кейса заказчика или внешняя публикация).
  2. Судебная практика: код решения - дата - суть проблемы - пояснение.

Сервис конвертирует оба формата в единый внутренний JSON и помещает данные в Yandex Object Storage. При этом база кейсов может редактироваться и дополняться данными без привлечения сторонних разработчиков.

Через админ-панель сотрудники компании самостоятельно могут:
  • загрузить новый Excel-файл и конвертировать его через опцию «дополнить» или «перезаписать»;
  • добавить, отредактировать или удалить отдельный кейс в базе;
  • обновить базу при изменении законодательства или появлении новой практики без участия разработчика.

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

Интерфейс:
просто, но максимально информативно

Для взаимодействия с разработанной системой, мы добавили простые и понятные страницы админ-панели.

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

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

Добавлен поиск по ID пользователя, чтобы точечно просматривать историю взаимодействия с системой. Есть данные по теме запроса, дате и времени обращения и количество сообщений в диалоге. Это помогает анализировать реальные сценарии использования продукта и наиболее частые темы обращений пользователей.
Оценка качества, скорости и стоимости моделей.

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

Выбор LLM модели через цифры

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

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

Принцип работы модуля оценки:
  1. Команда готовит тестовый набор пар «вопрос - ожидаемый ответ».
  2. Модель прогоняет весь набор через каждую из подключённых моделей.
  3. Ответы сравниваются с эталонными автоматически (по метрике совпадения) и вручную через интерфейс оценщика.
  4. По каждой модели вычисляются три ключевых показателя: процент точности ответов, среднее время отклика, стоимость одного запроса.
По итогу тестового прогона на главном экране отображаются ключевые показатели:
  • точность ответа модели отображает долю успешно пройденных запросов пользователя;
  • релевантность RAG показывает соответствие контекста запросу, где 0 - идеальное значение;
  • стоимость обработки исходя из цены токенов LLM;
  • задержка в ответе - это время с момента обращения до выдачи готового ответа.
Каждый запуск сохраняется в истории, чтобы сравнивать разные конфигурации системы и выбирать оптимальное сочетание качества, стоимости и скорости ответа. Отдельный блок помогает формировать набор тестовых кейсов. Можно задать пользовательский вопрос и ожидаемый ответ или критерий успешного результата. Это помогает проводить регрессионное тестирование LLM-моделей (например, после их обновления или пополнения базы знаний) и повторно проверять не ухудшилось ли качество ответов при том же наборе кейсов.

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

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

Управление тарифными лимитами

Мы разработали отдельный модуль, который помогает управлять тарифными планами, лимитами использования нейросетей и доступом пользователей.
Доступная администратору функциональность:
  • управление тарифными планами;
  • создание и изменение тарифных планов;
  • настройка ограничений для каждого тарифа;
  • быстрый поиск пользователя и изменение его тарифа без обращения к базе данных;
  • контроль текущих расходов лимитов и статусы доступа.

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

Работа с современными языковыми моделями (LLM) оплачивается по количеству обработанных токенов или запросов, поэтому для корпоративных AI-сервисов обычно вводятся ограничения по использованию. Лимиты позволяют контролировать расходы, защищают систему от злоупотреблений и обеспечивают справедливое распределение вычислительных ресурсов между пользователями. Многие API также имеют ограничения по скорости запросов, поэтому управление дневными и месячными нормами помогает контролировать работу системы.
Для каждого пользователя заводится карточка, которой администратор может управлять из личного кабинета. Ему доступна информация о текущем тарифе, статусе доступа, количестве использованных запросов и остаток доступного лимита. В пару кликов он может изменить тариф, при этом новые ограничения начинают действовать автоматически без привлечения разработчиков или других дополнительных настроек системы.

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

Особенность решения: точность ответов без «фантазий» ИИ модели

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

Разработчики CosySoft создали закрытый контур, который не только защищает чувствительные данные базы от внешних угроз, но и не позволяет LLM-модели получать данные из других источников, кроме накопленных данных компании.

Сложности

Три момента, где работа заняла больше времени, чем мы планировали.
  1. Развёртывание на Yandex Cloud. У нас был большой опыт с зарубежными платформами, но Yandex Cloud организован иначе, поэтому часть настроек конфигурации разбирали по ходу работ.
  2. Промпт-инжиниринг. Это единственная задача, которая ушла за пределы запланированного спринта и мы потратили на нее 2 недели вместо одной. Без качественного промпта модель отвечала формально верно, но не точно под задачу пользователя, пришлось уточнять контекст промта, чтобы модель лучше понимала какие данные искать в базе.
  3. UX страницы оценки моделей. Было сложно сделать инструмент, которым было бы удобно пользоваться человеку без технического бэкграунда. Концепция тестов LLM-моделей была понятна всем, но нам нужно было сделать удобным запуск системы оценки, а после оформить итоговые метрики в понятный любому пользователю интерфейс. Потребовались дополнительные встречи, чтобы система стала удобной.

Что вошло в итоговое решение
ИИ-ассистента

Команда разработала:
  • backend-микросервис ответов на вопросы;
  • API для интеграции с пользовательским чатом;
  • механизм тарифных лимитов;
  • хранение истории диалогов и контекст для последующих вопросов;
  • админку для управления базой знаний;
  • загрузку и нормализацию Excel-файлов;
  • RAG-контур с семантическим поиском;
  • экран тестирования моделей и промптов;
  • оценку качества, скорости и стоимости ответов;
  • инструменты просмотра статистики и прошлых диалогов.

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

Результат

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