От слов к делу: Практические кейсы применения NLP в Ингосстрахе

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

Именно с ними работают математики, которых, чтобы было веселее, в страховании называют сложно выговариваемыми словами «актуарии» и «андеррайтеры».

Но (сюрприз!) для полноценной работы страховой компании нужен большой штат сотрудников, которые общаются не только формулами, но и при помощи великого и могучего русского языка. А значит есть поле для автоматизации процессов работы средствами NLP. Именно про это данная статья.

Мы рассмотрим варианты решения типовых задач в страховании и не только.

Кейс №1. Вопросно-ответные системы на основе RAG (Retrieval Augmented Generation).

Задача: Уменьшить загрузку операторов, давать быстрые и точные ответы внешним и внутренним пользователям по консультационным вопросам.

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

RAG (Retrieval Augmented Generation) — это метод, при котором по запросу пользователя мы сначала ищем релевантную информацию во внутренней базе знаний, а потом просим LLM сгенерировать ответ на основе найденной информации.

Как реализовать?

Мы можем использовать такие инструменты как LangChain или LLamaIndex для удобной интеграции больших языковых моделей в приложения, а также ChromaDB, Faiss или Pinecone в качестве векторного хранилища базы знаний.

Подготовка:

• Собираем внутреннюю базу знаний от заказчиков
  Это может быть wiki, либо FAQ, главное, чтобы в материалах была исчерпывающая актуальная непротиворечивая информация, при этом не было дублирования.
  Существует большое количество лоадеров, которые поддерживают разнообразные форматы данных, такие как txt, md, pdf, docx и др. Такие файлы можно использовать для базы знаний.
  LLM хорошо работают с текстом, но проблемы возникают, если в базе знаний присутствуют изображения и таблицы. Часто в качестве изображений используются скриншоты с выделенными деталями интерфейса и другая информация. Есть мультимодальные модели, но на данный момент по нашим наблюдениям они довольно слабо справляются с задачей консультаций по изображениям. Поэтому лучше переводить изображение в текстовые описания, либо при загрузке в базу знаний заменять изображения на ссылки, а при выводе ответа пользователю заменять данные ссылки на изображения, но гарантировать 100% результат при таком подходе нельзя (LLM могут не вернуть ссылку, либо изменить её). Если требуется работать с таблицами, то по нашим наблюдениям лучше всего использовать представление таблицы Markdown (именно на нём обучаются большинство языковых моделей), но также есть большой риск, что модель не сможет извлечь информацию из правильной ячейки, особенно если таблица большая, либо необходимая информация находится в разных ячейках на большом расстоянии друг от друга.

• Индексируем базу знаний

  • Загружаем информацию из документов (например, при помощи langchain_community.document_loaders).

  • Разделяем текст на блоки (можно использовать langchain_text_splitters, но у нас используется собственная разработка, которая разбивает текст на смысловые блоки по разделам и подразделам).

  • Строим эмбеддинги для текстов. Для этого нужно воспользоваться отдельной моделью, важно, чтобы она поддерживала русский язык (например, можно использовать открытую модель multilingual-e5-large, либо решения от компаний, предоставляющих LLM по API).

  • Строим векторную базу знаний при помощи ChromaDB, Faiss или Pinecone.

Использование:

• Строим эмбеддинги для запроса пользователя, ищем релевантную информацию в базе знаний. Обычно используют косинусную близость векторов, можно задать пороговое значение, по которому определятся степень уверенности.
  Пример:
  db = Chroma(persist_directory=PERSIST_DIRECTORY, embedding_function=embeddings, client_settings=CHROMA_SETTINGS)
retriever = db.as_retriever(search_type="similarity_score_threshold", search_kwargs={"score_threshold": 0.75})

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

• Подаём на вход большой языковой модели.

Ключевым параметром при использовании генеративных моделей является температура, в наших задачах её лучше выставлять низкой (например, t=0.1), поскольку нужны чёткие ответы на вопросы, а не фантазии.
Нужно задать системный промпт, в котором детально описать роль и другие аспекты вывода информации (постараться заставить модель отвечать аккуратно, ведь пользователи могут её провоцировать).
Также нужно решить вопрос с тем, как именно встраивать данное решение в систему. Как в чат-боте будет определён переход на данную ветку диалога? Нужно реализовать классификатор сообщений, либо явно вызвать опцию через кнопку в интерфейсе. Кроме того, нужно определить, что делать в случае отсутствия информации в базе знаний по запросу пользователя, и при вводе нескольких однотипных запросов, когда пользователь так и не смог получить необходимый ответ (скорее всего потребуется вызов оператора).

Какую LLM выбрать?

Если в диалоге может быть использована конфиденциальная информация, то используем языковую модель, которую можно развернуть локально (служба безопасности запретит передавать информацию по API стороннему сервису, если есть риск передачи персональных данных)

Из плюсов:
+ можно дообучать под себя
+ всё находится в вашем внутреннем контуре

Из минусов:
- придётся закупать дорогой сервер с видеокартой
- качество генерация как правило хуже

Примеры открытых LLM для работы на русском языке:

Скрытый текст

Модель	Технические параметры	Описание	Плюсы и Минусы
Vikhr-Nemo-12B-Instruct-R-21-09-24   Владелец: Vikhrmodels   Ссылка	Размер: 12.2b параметров Контекст: 128к токенов   Ресурсы для запуска: 25 Гб VRAM (видеокарта A100 или H100 на 40 Гб) Есть квантизированные версии, которые можно уместить в GeForce RTX 4090, но с небольшой потерей качества	Основана на архитектуре Nemo от Mistral, модель дообучена на русском языке с использованием передовых технологий файнтюнинга, показывает высокие результаты на бенчмарках. Также имеет особенность, что отдельно обучалась для системы RAG, то есть генерации ответов, основанных на локальной Базе знаний (что мы и используем в данной задаче)	+ Натренирована на русском датасете + Большой контекст (128к токенов) + Дообучена для RAG + Open Source + Есть квантизированные версии - Часто галлюционирует, нужно подбирать хороший промпт
RuadaptQwen2.5   Владелец: МГУ   Ссылка	Размеры: 3b, 7b, 32b параметров Контекст: 128к токенов   Ресурсы для запуска: Для 32b нужна видеокарта с 80 Гб VRAM (видеокарта A100 или H100 на 80 Гб)	Новая модель от НИВЦ МГУ, адаптированная на русский язык модель Qwen 2.5, показывает очень высокие результаты на русскоязычных бенчмарках. У модели очень хороший токенизатор для русского языка (в оригинальных моделях часто один кириллический символ может кодироваться несколькими токенами, в результате чего вмещается меньше информации и падает скорость работы модели)	+ Натренирована на русском датасете + Большой контекст (128к токенов) + Отличные результаты на бенчмарках + Open Source + Есть квантизированные версии
saiga_nemo_12b   Владелец: Илья Гусев   Ссылка	Размер: 12.2b  параметров Контекст: 128к токенов   Ресурсы для запуска: 25 Гб VRAM (видеокарта A100 или H100 на 40 Гб) Есть квантизированные версии, которые можно уместить в GeForce RTX 4090, но с небольшой потерей качества	Основана на архитектуре Nemo от Mistral, модель дообучена на русском языке. Показывает высокие места среди открытых моделей на бенчмарках.	+ Натренирована на русском датасете + Большой контекст (128к токенов) + Open Source + Есть квантизированные версии   - В редких случаях придумывает несуществующие слова, либо зацикливается (повторяет один и тот же токен)
T-lite-instruct-0.1   Владелец: Т-банк   Ссылка	Размер: 8b параметров Контекст: 8к токенов   Ресурсы для запуска: 17 Гб VRAM (видеокарта GeForce RTX 4090)	Модель от Т-банка, которую они выложили в открытый доступ. Позиционирует себя как модель для решения бизнес-задач.	+ Натренирована на русском языке + Open Source   - Немного уступает конкурентам в качестве - Довольно маленький контекст
Qwen 2.5   Владелец: Alibaba   Ссылка	Размеры: 0.5B, 1.5B, 3B, 7B, 14B, 32B, и 72B Контекст: 128к токенов   Ресурсы для запуска: Для 32b нужна видеокарта с 80 Гб VRAM (видеокарта A100 или H100 на 80 Гб)	Поддерживает 29 языков, включая русский. Показывает довольно высокие результаты на различных бенчмарках. Можно скачать и использовать, но по лицензии коммерческое использование разрешено, если продуктом пользуются менее 100 миллионов активных пользователей в месяц.	+ Есть различные размеры и квантизированные версии + Большой контекст (128к токенов) + Хорошо работает с таблицами   - Не обучалась на русском языке
gemma-2   Владелец: Google   Ссылка	Размеры: 2b, 9b, 27b Контекст: 8к токенов   Ресурсы для запуска: Самая большая модель запустится только на 80 Гб VRAM (видеокарта A100 или H100 на 80 Гб)	"Cемейство легких современных открытых моделей, созданных на основе тех же исследований и технологий, которые использовались при создании моделей Gemini." Не обучалась отдельно на русском языке (обучалась сразу на многих, но доля русского датасета наверняка не очень большая), но показывает высокие результаты на русскоязычных бенчмарках. Есть проблема с лицензией, модели можно качать и использовать только для разработчиков и исследователей, но нельзя для коммерческих целей.	+ Высокие результаты на бенчмарках + Есть различные размеры и квантизированные версии   - Не обучалась на русском языке - Проблемы с лицензией - Немного уступает конкурентам в качестве на русском языке - Довольно маленький контекст
Llama 3.2   Владелец: Meta   Ссылка	Размеры: 1b, 3b, 11b, 90b Контекст: 128к токенов   Ресурсы для запуска: Версия 11b требует 22Гб VRAM (минимум: видеокарта GeForce RTX 4090, рекомендовано: A100)	Мультимодальная Open Source модель, может принимать на вход не только текст, но и изображения. Уступает конкурентам по качеству. Не обучена специально на русском языке.	+ Мультимодальная + Open Source + Большой контекст (128к токенов)   - Проигрывает конкурентам по качеству
Cotype   Владелец: МТС   Ссылка (платная версия)   Ссылка (маленькая версия 1.5b в открытом доступе)	Размер: 32b   Ресурсы для запуска: Видеокарта с 80 Гб VRAM (видеокарта A100 или H100 на 80 Гб)	Это платное решение, но его можно использовать полностью изолированно во внутреннем контуре. Есть бесплатный тестовый период. Позиционируется как enterpise решение для бизнеса. К сожалению, на бенчмарках нет замеров данной модели, нельзя объективно оценить качество данного решения, но в некоторых компаниях считают эту модель лучше конкурентов (особенно в задачах суммаризации). Недавно выкатили в общий доступ cotype-nano, но она всего на 1,5b параметров.	+ Можно использовать у себя в контуре + Обучена на русском языке   - Платное решение - Нет объективной оценки качества

Если нет конфиденциальной информации, то можно использовать проприетарные LLM по API

Из плюсов:
+ дешёвые генерации в сравнении с покупкой собственного сервера
+ как правило лучше качество, модели постоянно улучшаются

Из минусов:
- меньше возможностей для кастомизации
- внешний сервис на стороне

Примеры проприетарных LLM для работы на русском языке:

Скрытый текст

Модель	Технические параметры	Описание	Плюсы и Минусы
ChatGpt (gpt-4o)   Владелец: OpenAI   Ссылка	Контекст: 128к токенов	Лидер. На данный момент вне конкуренции, в том числе на русском языке. Работает только по API, в РФ официальное использование и оплата запрещены.	+ Лучшая модель + Большой контекст (128к токенов) - Не доступна в РФ
Claude 3.5 sonnet   Владелец: Anthropic   Ссылка	Контекст: 200к токенов	На ряду с ChatGPT один из лидеров, также высокое качество на русском языке, опережает open source модели. Работает только по API, в РФ официальное использование и оплата запрещены.	+ Высокие результаты на бенчмарках + Большой контекст (200к токенов) - Не доступна в РФ
YandexGPT Владелец: Яндекс   Ссылка	Контекст: до 32к токенов	Отличная модель среди доступных по API официально в РФ. Находится в процессе постоянного дообучения и улучшения. Есть удобная опция дообучения модели при помощи prompt-tuning прямо на сайте Yandex, можно получить собственную версию модели (нужно несколько сотен пар промпт-ответ).	+ Доступна в РФ + Обучена на русском языке + Возможность дообучения на собственном датасете
GigaChat   Владелец: Сбер   Ссылка	Контекст: 32к токенов	Немного уступает конкурентам, но также находится в процессе дообучения и улучшения, появляются новые версии.	+ Доступна в РФ + Обучена на русском языке - Проигрывает конкурентам по качеству

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

Основные бенчмарки:

Скрытый текст

Бенчмарк	Описание	Ссылка
LLM Арена	Суть состоит в том, что пользователи выбирают из двух вариантов генераций разными моделями какой ответ лучше, так составляется рейтинг. Плюсы в том, что это реальные оценки пользователей, сервисом пользуется много людей, поэтому оценок много. Минусы в том, что оценки остаются субъективными, при этом мы не можем понять качество моделей в узкоспециализированных категориях (модель, которая лучше всех пишет стихи, может хуже всех программировать).	https://llmarena.ru/
RuArenaHard	Автоматическая оценка моделей на русском языке. Использует систему ELO рангов, то есть как LLM Арена из пункта 1, отличие состоит в том, что оценивает не реальный человек, а другая сильная LLM (GPT-4), а сам бенчмарк состоит из 50 тем по 10 вопросов в каждой на русском языке. Минусы в том, что оценка языковой моделью может быть хуже, чем человеком, остаётся проблема получения оценки в узкоспециализированных областях.	https://huggingface.co/spaces/Vikhrmodels/arenahardlb
MERA	Бенчмарк с большим количеством задач по разным направлениям на русском языке. Минус в том, что большое количество моделей не представлено в данном рейтинге (таких как vikhr, saiga, t-lite). Также проблема классических бенчмарков состоит в том, что новые базовые модели заранее подготовлены к ним (специально обучаются под них и показывают высокие результаты), хотя это может не отражать качество реальных генераций instruct моделей.	https://mera.a-ai.ru/ru/leaderboard

С какими проблемами столкнулись?

• В первую очередь столкнулись с суровой и беспощадной службой безопасности. Идеальный мир безопасников – отсутствие каких-либо проектов в принципе. Несмотря на то, что наш модуль должен был встроиться в чат-бот и отвечать только на общие консультационные вопросы, у службы безопасности возник вопрос, а что мешает пользователю ввести свои персональные данные, даже если мы этого не просим? Вдруг ему захочется спросить:

  «Подскажите, как оформить КАСКО? Кстати, меня зовут Иванов Иван Иванович, вот мой номер паспорта и фотографии кредитной карточки с двух сторон. Приятно познакомиться!»

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

• Также столкнулись с проблемой оценки решения, стандартные бенчмарки не подходили. Конечно, классно, если чат-бот может примерить на себя роль эльфа и поиграть с тобой в D&D, а также сгенерировать поздравление бабушке с юбилеем, но мы всё-таки ожидаем от системы решения обращений, поэтому циферки на общих бенчмарках не так интересны. Мы посчитали, что лучше всего составить датасет тестовых вопросов (например, из истории техподдержки), потом специалисты смогут оценить качество данных ответов. Если нет возможности привлечения специалистов, то оценку ответов можно поручить какой-то сильной модели (например, ChatGPT).

  Если у вас есть эталонные ответы, то можно использовать метрики BLEU или ROUGE (есть и более современные референсные нейросетевые MetricX XXL и COMET). Проблема таких замеров состоит в том, что модель может ответить правильно по существу, но используя совершенно другие слова, а может ответить неправильно, хотя почти все слова будут как в эталоне.

• Ещё одна проблема состояла в том, что у пользователя могла быть длинная история сообщений, которая могла понадобиться при ответе на запрос, но при этом не влезала к контекст большой языковой модели. Есть определённая категория пользователей, которые просто обожают пообщаться с техподдержкой и выразить нам свою благодарность (сарказм). В качестве самого простого решения можно обрезать историю до допустимой длины, но лучше использовать суммаризацию переписки с пользователем. Самым лучшим способом является подход, используемый в BlenderBot, когда бот вычленяет основные факты в процессе переписки и сохраняет их, добавляя в контекст запроса.

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

Ещё нужно иметь ввиду, что не смотря на заявленные огромные окна контекстов в некоторых LLM, эффективный контекст моделей обычно порядка 20к токенов, дальше него модель может терять информацию. Так что обычно соревнование LLM, у кого длиннее… контекст, это просто хайп.

Как оценить качество решения после внедрения?

На A/B тесте оценки достаточно индивидуальны (в зависимости от задачи), можно использовать следующие онлайн-метрики:

• Процент лайков/дизлайков ответу

  • Расширенная обратная связь по ответам

• Процент диалогов без участия человека

  • Процент диалогов завершившихся на Вопросно-ответной системе

• Собрать статистику о том, сколько часов в день операторы тратят на ответы на вопросы, сколько вопросов они отвечают в среднем за сессию, сколько времени занимает обработка одного вопроса и т.д. Затем сравнить эти показатели с теми же данными после внедрения QA системы.

• Процент вопросов, повторяющихся подряд от одного пользователя

• Замерить время пользователя, которое он тратит при переключении между меню до перевода на оператора

• Замерить сколько раз пользователь возвращается на шаг назад (это определяет, что пользователь не смог найти нужного ответа).

Кейс №2. Кодогенерация.

Задача: Ускорить время работы программистов, избавить от рутинных задач.

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

Как реализовать?

От нас требовалось, чтобы система работала как подсказки через расширение для IDE (альтернатива copilot) + как чат через web интерфейс.

Есть специальные плагины для VSCode и PyCharm. Например, llm-vscode от Huggingface.

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

Маршрутизацию лучше всего реализовать при помощи fastAPI. В качестве хранилища сообщений можно использовать Redis, его просто настроить. Если нужна надежная высоконагруженная система, то можно использовать Kafka, но имейте ввиду, что над его настройкой придётся попотеть. Для обработки очереди запросов можно использовать celery_batches, в нём есть возможность задать интервал и максимальное количество запросов, по истечение заданного периода или сбора необходимого количества запросов мы подаём их батчем на инференс модели. Также у нас принято разворачивать образы в docker контейнерах.

Если требуется web интерфейс, чтобы использовать модель в качестве чата, то проще всего реализовать его на gradio.

Какую модель выбрать?

Ранее предпочтительным вариантом среди open source решений была модель DeepSeekCoder-V2, но недавно вышла модель Qwen2.5-Coder, которая на основных бенчмарках показывает лучшее качество. По нашему мнению Qwen сейчас выглядит предпочтительнее.

Локальные модели кодогенерации:

Скрытый текст

Модель	Владелец	Технические параметры	Ссылки
Qwen2.5-Coder	Qwen	Размеры: 0.5b, 1.5b, 3b, 7b, 14b, 32b параметров	https://huggingface.co/Qwen/Qwen2.5-Coder-32B-Instruct
DeepSeekCoder-V2	DeepSeek	Размеры: 16b, 236b параметров	https://huggingface.co/deepseek-ai/DeepSeek-Coder-V2-Lite-Instruct
Codestral	Mistral	Размер: 22b	https://huggingface.co/mistralai/Codestral-22B-v0.1
OpenCodeInterpreter-DS	Multimodal Art Projection	Размеры: 1.3b, 6.7b, 33b параметров	https://huggingface.co/m-a-p/OpenCodeInterpreter-DS-33B
Artigenz-Coder-DS	Artigenz	Размер: 6.7b	https://huggingface.co/Artigenz/Artigenz-Coder-DS-6.7B

Есть также проприетарные модели кодогенерации, которые можно использовать по API, либо через extension для IDE от компании, которой принадлежит модель.

Качество моделей можно проверить на специализированных бенчмарках для оценки навыков программирования.

Основные бенчмарки:

Скрытый текст

Бенчмарк	Описание	Ссылка
HumanEval и EvalPlus	Оригинальный бенчмарк состоит из 164 задач по программированию на языке Python. EvalPlus содержит больше задач. Для оценки используется метрика pass@k, которая считает задачу решенной, если хотя бы одна из k генераций модели будет верной (pass@1 означает, что задача решается с первой генерации). Минусы данных бенчмарков в том, что задачи в них только на Python, и весь спектр реальных задач программирования всё равно не охватывается.	https://evalplus.github.io/leaderboard.html
MBPP и MBPP+	Оригинальный бенчмарк состоит из 1000 вопросов по программированию на Python, собранных с помощью краудсорсинга. Эти задачи начального уровня сосредоточены на фундаментальных навыках программирования. Минусы также в том, что оценивается только язык Python, и они не полностью отражают сложности и вызовы реальных приложений	https://evalplus.github.io/leaderboard.html
Aider	Бенчмарк оценивает насколько хорошо LLM разбираются в редактировании кода. Состоит из 133 упражнений, в которых исходный код Python файлов изменяется, а модель просят следовать системным подсказкам для исправления и дописывания кода. Минус в том, что оценивается только язык Python.	https://aider.chat/docs/leaderboards/
MultiPL-E	В нём задачки из HumanEval и MBPP переведены на 22 языка программирования.	https://huggingface.co/spaces/bigcode/bigcode-models-leaderboard
McEval	16 000 тестовых примеров для 40 различных языков программирования	https://mceval.github.io/leaderboard.html
LiveCodeBench	Фокусируется на более широких возможностях, связанных с кодом, таких как самовосстановление, выполнение кода и прогнозирование результатов тестирования, помимо простой генерации кода. Содержит более 300 задач.	https://livecodebench.github.io/leaderboard.html

Какой фидбек получили от пользователей после запуска?

Кейсы, в которых модель лучше всего применима:

• продвинутый автокомплит (однострочные подсказки)

• генерация шаблонного кода

• генерация юнит-тестов

• генерация кода по описанию на естественном языке (работает в том числе с русским)

• объяснение кода

• документирование кода

• дополнительно:

  • построение простых диаграмм по коду (mermaid)

  • построение регулярных выражений

  • формирование json/xml

  • ответы на прочие вопросы, связанные с разработкой, но не требующие генерации кода

Кейсы, в которых модель менее применима:

• генерация нетривиального кода, когда составление правильного промпта по времени сопоставимо с написанием кода без использования модели

• генерация большого объема кода для одного промпта

• генерация кода по некачественному контексту (читай bad коду)

С какими проблемами столкнулись?

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

• Скорость инференса (появления подсказанного кода) достигала нескольких секунд. Казалось бы, можно отдохнуть и подумать о прекрасном, но программистам-пользователям не очень нравилось ждать в IDE, пока сгенерируется новое дополнение кода.

  Мы запускали модель генерации кода при помощи vllm. Для ускорения инференса можно также попробовать такие инструменты как ONNXи TensorRT.
  Нужно понимать, что у нас идёт цепочка:

  плагин пользователя → запрос на сервер → обработка очереди → инференс модели → возврат результатов в IDE

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

Кейс №3. Речевая аналитика.

Задача: Перевести звонки операторов из аудио формата в текстовый, проанализировать диалог по определённым критериям, суммаризировать.

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

Как реализовать?

Для транскрибации аудио на русском языке есть множество платных решений от таких компаний как Яндекс, Сбер, МТС и т.д.

Также есть open-source модели для локального развёртывания, пример:

На зашумлённых данных (а именно такими являются звонки в своём подавляющем большинстве) среди open-source моделей выделяется GigaAM, она показывает наилучшее качество на русском языке.

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

• Ключевые слова и фразы

  Если нет разметки по словам, но диалоги разделены на классы (например, успешная/неуспешная продажа или положительная/отрицательная оценка клиента), то мы можем попробовать вычленить ключевые слова и фразы, которые определяют классы. Проще всего сделать это при помощи TF-IDF.
  Этот метод вычисляет частоту употребления каждого слова в документе относительно общего количества документов из коллекции, в которых встречалось данное слово. То есть слова, которые встречается в большинстве документов, будут иметь низкие показатели, а уникальные слова, встречающиеся много раз в малом количестве документов, будут иметь высокую ценность для них. Можно разбить на n-граммы и искать ключевые словосочетания.

• Эмоциональное состояние

  Есть готовые модели по определению Sentiment analysis, которые по тексту, либо аудио могут определять тональность и эмоциональную окраску того или иного участка диалога. Если есть разметка, то можно обучить своё решение (например, для текста можно использовать BERT).

• Заданные критерии

  Заказчик может сам определить критерии, по которым хочет оценить диалоги. Для этого потребуется разметка с его стороны. Это может быть как классификация диалога/предложения, так и выделение отдельных слов, то есть задача NER.

  После этого можно натренировать классификаторы. Можно использовать Word2Vec и FastText, если нужно простое и быстрое решение, при этом мало размеченных данных. Можно также в качестве классификатора использовать LLM, но это большой и дорогой инструмент. Если есть много разметки, то лучше использовать BERT.

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

• использование слов вежливости

• приветствие, представление себя и компании

• корректное завершение разговора

• проявление эмпатии

• количество слов-паразитов

• уточнение ФИО

• корректное предоставление информации о продукте

• соблюдение сценария разговора

• отработка возражений

• выявление потребностей

• согласие клиента

и др.

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

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

Также может потребоваться суммаризация — краткое изложение диалога.

Если нужно простое и быстрое решение, то можно использовать TextRank. Если есть возможность, то можно опять-таки использовать большую языковую модель.

Какой фидбэк получили от заказчика?

• Речевая модель, которая используется для распознавания достаточно точно транскрибирует диалоги. Ошибок распознавания почти нет.

• Модель определения содержания разговора и заполнения чек-листа контроля качества работает точно. Совпадение между прослушкой человеком и речевой аналитикой - 85..90%

Кейс №4. Задачи классификации.

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

На что нужно обратить внимание?

• Количество классов

• Баланс классов

• Длина текста

• Количество размеченных данных

Как реализовать?

А) Если разметки мало, а тексты короткие и простые.

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

Этапы:

1. Предобработка

2. Формирование эмбеддингов

3. Модель классификации

Классическая предобработка текста заключается в:

• преобразовании текста в нижний регистр

• удалении стоп-слов

• удалении знаков пунктуации, чисел (если не нужно удалять, то часто пишут их прописью)

• лемматизации/стемминге слов

• иногда может потребоваться удалять также какие-то шаблонные фразы при помощи регулярных выражений

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

Далее приступаем к формированию эмбеддингов при помощи:

• TfidfVectorizer и CountVectorizer

• Navec

• Word2Vec

• FastText

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

И наконец обучаем модель классификации. Их великое множество:

• LogisticRegression

• SGDClassifier

• LGBMClassifier

• Svm

• RandomForestClassifier

• GradientBoostingClassifier

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

Б) Если есть возможность получить много размеченных данных, а тексты большие по объёму.

Можно использовать более сложные инструменты:

• LSTM

• ELMo

• BERT (и его модификации RoBERTa, DeBERTa, ALBERT, DistilBERT, TinyBERT и др.)

В таких задачах лучше всего показывают себя трансформеры Bert. Его особенностью является построение контекстно-зависимых эмбеддингов. То есть мы проходим окном (в классической версии Bert 512 токенов) и учитываем данный контекст. Это отличает его от моделей из предыдущей части, например, в word2vec эмбеддинги для каждого слова формируются только в процессе обучения, усредняются по всем контекстам и фиксируются.

Также при использовании BERT необязательно производить препроцессинг.

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

Смотрим на количество экземпляров в классах. Если есть классы с совсем маленьким количеством, то их придётся убрать из классификации. Можно просто убрать их из выборки, а на инференсе смотреть на степень уверенности модели при классификации, можно создать отдельный «мусорный класс» и положить в него все экземпляры маленьких классов.

Если количество элементов в классах сильно отличается друг от друга, то можно использовать balanced-loss + oversampling или аугментацию текстов для редких классов (на практике маловероятно, что получим ощутимый прирост в качестве).

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

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

Если у нас модель переобучается (overfitting), то есть loss на тренировочных данных падает, а на валидационных – нет, то самыми действенными методами борьбы будут:

• Регляризация
  Увеличиваем значение weight_decay для optimizer

• Dropout
  Увеличиваем dropout в модели перед тренировкой

• Early Stopping
  Остановка обучения, когда модель начинает переобучаться

 Ну и конечно же добавление новых данных =)

В качестве метрики мы обычно используем классическую F1 меру.

Если у нас нет обучающих данных в наличии или имеется всего несколько примеров, то и тут нам могут на помощь прийти LLM, которые также можно использовать для классификации как хороший baseline. Можно использовать few-shot режим, чтобы показать модели несколько примеров, а также чётко описать задачу и формат выходных данных. Но нужно понимать, что всегда есть риск галлюцинаций и неправильного вывода модели.

Какие результаты?

Моделей классификации у нас сразу несколько, по ним достаточно высокие метрики, заказчики довольны качеством.

Наиболее интересные проекты:

• Классификации обращений по их описанию.
  F1 мера достигает 0.78. Использовали Bert модели. Сложность проекта в том, что изначально было около 1000 различных классов.

• Определение кода болезни по жалобам, анамнезу и осмотру.
  F1 мера достигает 0.76. Использовали Bert модели. Сложность проекта в том, что присутствуют диагнозы разных болезней по почти идентичным описаниям.

• Автоматическое заполнение услуг ДМС.
  Суть проекта в том, что компании предоставляют список услуг, а мы со своей стороны пытаемся определить, что именно из них мы можем предоставить в рамках программы ДМС + указать комментарии. Особенность проекта состоит в том, что названия короткие и часто повторяются, в такой задаче overfitting это нормально, так как не нужна обобщающая способность. Сложность проекта состоит в том, что формулировки одних и тех же услуг могут отличаться у разных компаний. Изначально мы даже хотели просто составить словарь и искать услуги по частичному совпадению наименований, но такой подход на тестовой выборке показал F1 меру всего около 0.5, связка FastText + RandomForestClassifier дала 0.97 (да, мы тоже в шоке).

Обычно раз в несколько месяцев мы получаем дополнительную разметку, при помощи которой переобучаем модели и сравниваем качество старой и новой версий. В некоторых проектах мы заполняем значения, в которых модель уверена (выдаёт скор выше заданного порога), а если не уверена – подсвечиваем ячейку с ответом модели, чтобы её мог перепроверить сотрудник, на полученных данных модель также переобучается.

В планах – автоматизировать такой pipeline через Airflow, чтобы дообучать модели и сравнивать их качество через определённые промежутки времени в автоматическом режиме. На данный момент у нас кустарный ручной способ (к своему стыду мы даже не записываем результаты экспериментов в MLFLow, а храним на сервере в текстовых файлах).

Кейс №5 (бонусный). Генерация изображений по текстовому описанию.

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

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

Как реализовать?

Проще всего web интерфейс сделать на gradio, либо воспользоваться готовыми, такими как fooocus и automatic1111.

Передовыми моделями, которые можно развернуть локально, сейчас являются Flux или Stable Diffusion 3.5.

Если в компании уже есть набор изображений в определённом стиле, и мы хотим сгенерировать в нём новые картинки, то можно попробовать обучить собственный адаптер Lora для выбранной модели генерации изображений. Для этого потребуется датасет из нескольких десятков изображений и детальное описание того, что на них находится (для данной задачи можно использовать готовые генеративные модели, которые умеют составлять текстовое описание по изображению, например, ChatGPT).

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

Какой фидбэк от пользователей?

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

Запрос: «на прохожего кидается злая собака»

Выше я описал те задачи, которые мы решаем в Ингосстрахе командой NLP прямо сейчас.

Поделитесь, пожалуйста, в комментариях, какие задачи вам кажутся наиболее перспективными для NLP и LLM в российском финтехе?