Как у нас в RUTUBE ИИ и служба клиентского сервиса работают сообща, вместе справляются с ростом сервиса и мгновенно адаптируются к изменениям — рассказываем в этой статье. Делимся рецептом RAG-системы, которая за первые три месяца эксплуатации уже отвечает почти на 70% запросов пользователей и никогда не врёт про «космических зайцев».
Давайте обо всём по порядку — начнём с бизнес-задачи: нужно быстро и качественно отвечать на вопросы пользователей, так как это напрямую влияет на их лояльность и бизнес-показатели компании.
Каждый день в поддержку RUTUBE поступают тысячи обращений — представьте, это как если бы все посетители средних размеров концерта одновременно спросили бы: «Как подключить монетизацию?». Специалисты поддержки стараются помочь каждому:
<1 минуты на простой вопрос, например: «Как сменить пароль?».
15 минут на сложный, например: «Как запустить трансляцию на вебе?».
База знаний растёт как на дрожжах:
40+ тем, 1 500+ вопросов-ответов — и это не считая внутренних инструкций и статей;
и это не считая скрытых мемов про «ошибку 404»;
документы обновляются ежедневно, почти в реальном времени.
Самый горячий вопрос: «Как перенести видео с YouTube?». Если оператор начнёт описывать это вручную с нуля, то зритель успеет заскучать и отвлечься. Очевидно — нам нужно внедрить методы ИИ, чтобы сократить время ответа. Сейчас среднее время первого ответа поддержки на все виды вопросов (сложные и простые) составляет 7 минут. Используя бота, мы хотим сократить это время до одной минуты. Итак, цель ясна: «Tick-tock, нейросеть, сделай док»!
Требования и ограничения:
Никаких проприетарных систем вроде GigaChat, YandexGPT и прочих — используем только локально поднятые внутри контура модели для обеспечения безопасности данных.
Время ответа не более 20 секунд, ответ по REST API запросом для интеграции с единым окном системы работы с запросами пользователей и другими системами — чтобы всё работало как часы, а не как принтер в понедельник утром.
FAQ остаётся в привычной коллегам базе знаний, чтобы не ломать флоу работы и не внедрять дополнительный инструмент, так как это обычно замедляет, а не ускоряет работу.
Кто в игре:
Специалисты клиентского сервиса — наши незаменимые помощники. Пока они проверяют ответы AI, но скоро, может, смогут на него полностью положиться.
Система — не чат-бот (пока), а инструмент для генерации ответов. Мы же не хотим, чтобы AI начал спорить с пользователями, как тролль в комментариях.
Для решения этой задачи мы выбрали подход Retrieval Augmented Generation (RAG), потому что в перспективе хотим получить чат-бота, который будет общаться как человек, а не просто ссылаться на FAQ. Сейчас это инструмент, помогающий специалистам поддержки, но не заменяющий их полностью — и это хорошо и помогает сохранять связь с пользователями.
Эта статья состоит из двух частей: обзора вариантов реализации и описания нашего решения.
В первой половине статьи рассмотрим, из каких элементов состоят RAG-системы и на какие задачи нужно обратить внимание. Сделаем это на основе подходов команд хакатона «Цифровой прорыв», которые состязались в решении нашего кейса. Разберём, что сработало, а что — не очень и почему.
Вторая половина посвящена нашему продакшен-решению. Если вы хорошо знакомы с RAG-системами, то можно пропустить часть с результатами хакатона и сразу перейти к решению ML-команды RUTUBE.
Хакатон по ИИ
Параллельно с тем, как мы в ML-команде RUTUBE занялись созданием инструмента для ускорения работы поддержки, нам представилась возможность предложить кейс на Всероссийский хакатон «Цифровой прорыв. Сезон: Искусственный интеллект». Мы решили использовать этот шанс, чтобы не только поддержать молодых специалистов и помочь им получить практику, но и попробовать почерпнуть идеи для своей задачи.
На решение нашего кейса «Интеллектуальный помощник оператора службы поддержки» заявилось максимально возможное количество команд — 30, целых 22 из них дошли до защиты.
Данные для хакатона
С данными для обучения нам помогли коллеги из Департамента клиентского сервиса. Участники хакатона получили в своё распоряжение:
База знаний часто задаваемых вопросов (ЧАВО/FAQ) — набор эталонных вопросов и ответов, которые помогут понять основные боли пользователей. Участники получили всего 326 пар.
Набор реальных вопросов пользователей — 800 обращений и ответов к ним от службы поддержки.
Генеральное пользовательское соглашение RUTUBE и Условия размещения контента, так как часть типичных ответов поддержки ссылается на пункты соглашения и условий.
Примеры из базы часто задаваемых вопросов:
Тема | Вопрос из БЗ | Ответ из БЗ |
Загрузка видео | Какие требования к обложке видео? | Мы рекомендуем соблюдать следующие требования: Разрешение: до 1920х1080. Формат: jpeg, jpg или png Размер файла: не более 10 МБ. |
Загрузка видео | Как добавить тайм-коды под видео? | Перейдите в раздел «Видео» в Студии RUTUBE. Нажмите на видео, в которое хотите добавить тайм-коды.Добавьте тайм-коды в описание под видео. |
Трансляции | Можно ли вести трансляции на RUTUBE, если подать поток в 60 FPS? | Да, можно. |
Трансляции | Можно ли запускать несколько трансляций одновременно? | Да, в Студии RUTUBE можно проводить до 20 трансляций одновременно: https://studio.rutube.ru/create-stream |
Трансляции | По какой ссылке доступна запись трансляции? | Запись доступна по той же ссылке, что и трансляция, после конвертации. |
Примеры запросов пользователей и ответов службы поддержки:
Вопрос пользователя | Ответ сотрудника | Вопрос из БЗ | Ответ из БЗ |
Какой логин указывать в студии на смартфоне? | Зарегистрироваться в приложении можно по номеру телефона или электронной почте. | Как зарегистрироваться в приложении Студия RUTUBE? | Зарегистрироваться в приложении можно по номеру телефона или электронной почте. |
Как можно выйти со всех устройств в пиложении студии? | Для выхода из аккаунта кликните на фото своего профиля в правом верхнем углу и нажмите на кнопку «Выйти» внизу экрана. | Как выйти из аккаунта в приложении Студия RUTUBE? | Для выхода из аккаунта кликните на фото своего профиля в правом верхнем углу и нажмите на кнопку «Выйти» внизу экрана. |
Где можно изменить название канала в студии на смартфорне? | Для изменения названия канала, нажмите на фото своего профиля в правом верхнем углу и выберете раздел "Настройки канала". | Можно ли изменять название и описание профиля канала в приложении Студия RUTUBE? | Да, можно. Для этого нажмите на фото своего профиля в правом верхнем углу и выберете раздел "Настройки канала". |
Добрый день, можно примерить другую обложку канала в студии на телефоне или нет? | Да, в приложении Студия RUTUBE можно изменить обложку канала. Для этого, в правом верхнем углу нажмите на фото своего профиля. Затем кликните на иконку на вашей текущей обложке профиля. | Можно ли изменить обложку канала и фото профиля в приложении Студия RUTUBE? | Да, можно. Для этого, в правом верхнем углу нажмите на фото своего профиля. Затем кликните на иконку фотоаппарата, на вашей текущей обложке или фотографии профиля. |
Как видите, данных для обучения не очень много, но в этом и был челлендж задачи.
Ограничения и требования для участников хакатона
Требования к инструментам поставили такие, чтобы не сильно ограничивать участников, но достаточно удобно и быстро проверять решения:
Python, Pytorch;
в решении не должны использоваться проприетарные технологии;
поднятый REST API для тестирования сервиса;
решение интегрировано в телеграм-бота для нетехнических членов жюри.
Дополнительно мы учитывали при оценке результатов и заранее просили участников уделить внимание следующим пунктам:
Нет «галлюцинациям». Система не должна выдумывать и подменять факты. Лучше отвечать «Я не знаю», чем давать ложную информацию.
Культурный фильтр. Система не должна использовать в своем ответе ненормативную лексику, неправомерные высказывания. Должна вежливо отвечать на любые вопросы пользователей.
Внимание к деталям. Насколько точно система способна предоставлять информацию о строго определенных фактах. Например, даты проведения событий, имена, аббревиатуры и тд.
Анализ решений участников хакатона: как строили RAG-системы для RUTUBE
Как ни странно, все участники выбрали стратегию построения RAG-систем, хотя этого не было в требованиях.
В этой статье не будем останавливаться на детальном разборе концепции RAG. Если хотите изучить предметную область RAG-систем, рекомендую начать со статьи «Retrieval-Augmented Generation for Large Language Models: A Survey». Для текущего решения нас интересует так называемый Advanced RAG. Основные компоненты Advanced RAG и их взаимодействие изображены на рисунке ниже.
Разберем ключевые идеи реализации RAG, которые помогли участникам решить задачи обработки запросов, борьбы с галлюцинациями и повышения точности ответов.
1. Расширение базы знаний: синтетика и логика
Работа с базой знаний — то, с чего часто начинается решение ML-задач, и то, что может принести существенный буст. Так и в нашем кейсе участники активно использовали генерацию синтетических данных, чтобы расширить обучающую выборку. Это помогло им охватить большее количество сценариев и улучшить качество поиска релевантной информации.
Основной подход заключался в следующем: на основе существующих документов (FAQ, пользовательские соглашения) с помощью больших языковых моделей (LLM), таких как Mistral-4, генерировались вопросы, имитирующие поведение разных пользователей:
Новички: «Что влияет на монетизацию?»
Эксперты: «Как алгоритмы RUTUBE отслеживают статистику?»
Сложные запросы: «Сравните последствия завышения просмотров и приостановки видеопотока».
Чтобы качество генерации было выше, документы можно разбивать на логические блоки (чанки), тогда соответствие между вопросами и релевантными фрагментами текста будет точнее.
Например, в FAQ есть вопрос: «Почему могут отключить монетизацию из-за искусственного завышения показателей?» и ответ к нему: «Алгоритмы RUTUBE следят за статистикой. Нарушение п. 2.3.17 оферты ведет к отключению монетизации». На их основе генерируем вопросы: «Как избежать блокировки монетизации?», «Какие пункты оферты регулируют просмотры?» и т.д.
Таким образом, с помощью синтезированных данных увеличивается объем базы для обучения RAG, что в результате позволяет системе охватить больший спектр разных вопросов и лучше отвечать на нестандартные запросы. Это особенно важно, если учесть, что исходных данных было немного: всего 326 примеров из FAQ и 800 реальных кейсов. Однако такой подход приносит с собой риск генерации нерелевантных или противоречивых данных, то есть потребуются ресурсы для контроля качества синтетических данных.
2. Pre-retrieval: подготовка запросов
Для повышения эффективности поиска, команды применяли методы предварительной обработки входящих запросов:
Перефразирование: LLM использовались для генерации различных вариаций вопроса, например, «Как подключить монетизацию?» → «Какие шаги для получения дохода на RUTUBE?».
Multi Query Retriever: Объединение результатов поиска по нескольким разным формулировкам запроса с использованием Reciprocal Rank Fusion (RRF) для повышения релевантности.
Методы предварительной обработки запросов, такие как перефразирование с помощью LLM и использование Multi Query Retriever с RRF позволили некоторым командам повысить релевантность поиска. Правда их применение увеличивает время ответа системы, поскольку приходится выполнять дополнительные вызовы LLM. Несмотря на это, улучшение качества поиска оправдывает дополнительные временные затраты, особенно в контексте работы с ограниченными исходными данными.
3. Retrieval: гибридный поиск для максимальной релевантности
Основной акцент в реализации участники делали на гибридных подходах, объединяющих преимущества семантического и лексического поиска:
Эмбеддинги — использовались различные модели для преобразования текста в векторы, включая BGE-M3, SBERT, multilingual-e5-large и RoBERTa.
Векторные базы данных — для хранения и быстрого поиска векторов применялись Chroma, FAISS, PostgreSQL с pgvector и LanceDB.
Гибридные методы: комбинация семантического (векторного) и лексического (BM25) поиска; ансамблирование результатов, полученных от нескольких моделей; классификация запросов для выбора тематических коллекций документов.
Пример: запрос «Ошибка при загрузке видео» классифицируем как относящийся к категории «Технические проблемы», после чего ищем только в соответствующей коллекции документов.
Гибридные подходы к поиску, сочетающие семантические (векторные) и лексические (BM25) методы, помогают достичь хорошей релевантности результатов. Дополнительное ансамблирование результатов и классификация запросов для работы с тематическими коллекциями документов еще больше повышают эффективность поиска. Однако стоит иметь в виду, что такие методы требуют тщательной настройки и реализовать их так, чтобы получить адекватный прирост в качестве, непросто.
4. Reranker: борьба за точность
Ранжирование результатов поиска тоже несомненно влияет на результат работы всей системы. С помощью следующих подходов можно улучшить ранжирование:
LLM как реранкер — LLM выбирает 2-3 наиболее релевантных документа из предварительно отобранных ретривером;
дообученные модели — fine-tuning на синтетических данных для оптимизации ранжирования;
Ансамбли — объединение результатов, полученных от разных моделей, например, SBERT + BM25.
Интересно, что предобученные реранкеры, такие как cross-encoder-russian-msmarco в некоторых случаях ухудшали качество, поэтому участники чаще предпочитали использовать кастомные решения.
5. Промпт-инжиниринг: инструкции vs хаос
Качество генерируемых ответов напрямую зависит от промптов, используемых для LLM. Команды, уделившие внимание детальной проработке промптов, добились значительно лучших результатов.
Короткие промпты без детальных инструкций работают так себе: LLM генерирует общие фразы и упускает важные детали.
Эффективные промпты состоят из двух частей.
Системный промпт: общие инструкции, определяющие роль LLM в текущей задаче.
Пользовательский промпт: детальные инструкции о том, как извлекать и анализировать информацию из предоставленного контекста документов, обращать внимание на детали, ограничивать длину и подробность ответов.
В хороших промптах отдельное внимание уделено тому, как обрабатывать ситуации, когда в представленном контексте документов нет информации по вопросу, чтобы минимизировать галлюцинации.
Интересный факт: промпты на английском (с ответом на русском) давали более точные результаты из-за лучшей оптимизации моделей под англоязычные инструкции.
6. LLM: генерация финального ответа
Для генерации финального ответа участники хакатона использовали разные модели:
Mistral-7B, Llama 3, Phi-3, Qwen2.5 — открытые модели с квантизацией (4-6 бит) для экономии ресурсов.
Vikhr-Nemo, Saiga — адаптированные под русский язык.
Фреймворки: llama.cpp, vLLM и Ollama для оптимизации инференса.
В случае с использованием модели Qwen2.5 выявилась любопытная проблема — в ответах появлялись китайские иероглифы. Что ещё раз напоминает нам, как важно выбирать модели, устойчивые к непреднамеренному переходу на другой язык.
Выбор модели зависит от специфики задачи, если учитывать все требования к выводу, то это усилит содержательность.
7. Проверка корректности ответа
Проверка через LLM — модель-критик анализирует ответ на токсичность и соответствие контексту. Например, с помощью промпта: «Ответ содержит нецензурную лексику? Ответь “Да” или “Нет”».
Классификаторы rubert-tiny-toxicity для автоматической фильтрации.
Fact-Checking — сравнение ответов с эталонными данными из базы.
Эти методы, хотя и увеличивают время ответа из-за возможной перегенерации, существенно снижают риск некорректных или токсичных ответов, что критически важно для пользовательского опыта в нашем продукте.
Хакатон показал, какими разнообразными могут быть реализации RAG-систем для нашего кейса. Успешные решения основывались на расширении базы знаний с помощью синтетических данных, оптимизации запросов перед поиском, использовании гибридных методов поиска, точном ранжировании результатов и тщательной проработке промптов для LLM.
Опыт, который получили и участники хакатона в ходе выполнения задания, и наша команда, пока мы консультировали ребят и разбирали результаты, помог нам в улучшении решения для RUTUBE. Мы применили находки, полученные в ходе хакатона, чтобы усовершенствовать систему автоматической поддержки пользователей на платформе.
Наш опыт разработки RAG-системы в RUTUBE
Внедрение RAG-системы на наш взгляд обязательно включает в себя следующие ключевые задачи:
Сбор, обработка, обновление, эмбедирование текстов и хранение базы знаний о предметной области нашей RAG-системы.
Предобработка входящих в RAG-систему запросов.
Поиск и фильтрация релевантных запросу документов из базы знаний, включает в себя Retrieval и Reranker
Выбор базовой LLM и подготовка шаблонов промптов для различных задач.
Возможные фильтры ответов.
Этот список можно использовать как чек-лист, а далее в статье мы разберём нюансы, которые имели наибольшее значение в нашей задаче.
База знаний для RAG-системы
Для эффективной работы RAG критически важно не только собрать хорошую базу знаний, но и держать её в актуальном состоянии. В нашем случае это означает необходимость регулярного автоматического обновления: потому что RUTUBE динамично развивается и новые вводные для службы поддержки появляются постоянно. Кроме того, мы поняли, что система действительно будет приносить пользу и облегчит работу поддержки, только если будет интегрирована в процессы команды и не будет ломать привычные рабочие ритмы.
На момент начала работы у отдела поддержки RUTUBE был внутренний FAQ в одной популярной системе для создания баз знаний. Мы решили строить RAG-систему, опираясь на тот ресурс, а не тратить силы, время и энергию на переезд куда-то ещё. Для автоматизации использовали четыре ключевых компонента:
Единый стандарт оформления. FAQ был структурирован в формате «вопрос—ответ»: мы стандартизировали шрифты, заголовки, списки и комментарии. Это упростило обработку данных и сделало статьи унифицированными.
Парсер на Python. Написали простой парсер, который читает разделы FAQ и извлекает пары «вопрос—ответ» по заданному шаблону.
Технический раздел для сложных кейсов. Для работы с нестандартными вопросами добавили скрытые страницы, доступные только парсеру. Например, запрос «Как получить галочку?» автоматически сопоставляется со статьей «Как верифицировать канал?» благодаря заготовкам сленговых выражений. Это упрощает управление такими ситуациями без изменений в коде RAG-системы.
Airflow. Парсинг был обернут в микросервис, который запускается по расписанию через Airflow. Система автоматизированно проверяет изменения в базе FAQ, обновляет базу знаний в MILVUS (подробнее о ней ниже), а также переиндексирует векторные представления текста.
Благодаря такому подходу мы смогли внедрить RAG-систему, не создавая дополнительной нагрузки на операторов и сохраняя привычное ПО. Изменения в бизнес-процессах минимальны, а актуальность базы знаний поддерживается автоматически.
База данных для сервиса
Векторные базы данных позволяют хранить векторы вместе с метаданными. Это даёт возможность быстро находить документы, соответствующие запросу, благодаря различным методам индексации и ANN-алгоритмам (приближенным методам поиска ближайших соседей)
Векторные базы данных — это «мозг» RAG-системы. Они не только хранят векторы, но и позволяют быстро находить релевантные документы даже среди миллиардов объектов.
При выборе векторной базы данных мы сфокусировались на трех ключевых свойствах:
Гибкость индексов — поддержка разных типов индексации (HNSW, IVF, LSH), чтобы оптимизировать скорость и точность под конкретные данные. Например, для текстовых чанков эффективнее HNSW, для мультимодальных данных — IVF.
Масштабируемость — возможность роста до миллиардов векторов без потери производительности, даже при одновременном использовании БД другими ML-сервисами RUTUBE.
Гибридный поиск — комбинация векторного поиска с классическим текстовым (BM25). Зачем? Чтобы находить документы, где совпадают и смысл, и ключевые слова.
Мы сравнили пять популярных векторных баз данных с открытым исходным кодом: Weaviate, Faiss, Chroma, Qdrant и Milvus. Ниже в таблице отмечено, поддерживает ли БД нужные нам свойства, или нет.
База данных | Гибкость индексов | Масштабируемость | Гибридный поиск |
Weaviate | ❌ | ❌ | ✅ |
Faiss | ✅ | ❌ | ❌ |
Chroma | ❌ | ❌ | ✅ |
Qdrant | ❌ | ✅ | ✅ |
Milvus | ✅ | ✅ | ✅ |
Из таблицы очевидно, Milvus — самый универсальный вариант и удовлетворяет всем нашим ключевым требованиям.
Retrieval. Как выбрать модель для семантического поиска в RAG
Эффективность RAG-системы начинается с выбора модели, которая превращает текст в векторы. От этого зависит, насколько точно система найдет релевантные документы в базе знаний и как качественно LLM сгенерирует итоговый ответ.
Почему это важно? Представьте: даже идеально настроенная LLM даст некорректный ответ, если семантический поиск «подсунет» ей не те данные. Например, на вопрос о монетизации система может выдать чанки про технические требования к видео и ответ получится путаным.
Большинство команд остановились на multilingual-e5-large — предобученной модели с открытым исходным кодом. Вот почему:
Скорость vs качество: У модели меньше 1 млрд параметров, но она показывает топовые результаты в бенчмарке MTEB для русского языка (см. рисунок ниже).
Мультиязычность: Подходит для сервисов вроде RUTUBE, где пользователи в основном пишут на русском, но могут использовать заимствования на кириллице, например, «стрим» и «контент» или латиницу.
Баланс: Хорошо работает даже на слабом железе.
В первой версии нашей RAG-системы в качестве энкодера мы тоже использовали multilingual-e5-large, но потом взялись за улучшение блока Retrieval и победителем на наших бенчмарках стала модель ai-forever/FRIDA. Ее победа скорее обусловлена лучшей адаптацией к русскоязычным терминам.
Как мы выбирали модель для Retrieval:
Создали размеченный датасет: взяли более 10 тыс. исторических запросов пользователей в службу поддержки RUTUBE и для каждого запроса нашли релевантные документы из нашей базы знаний. Разметку производили с помощью LLM. Базу знаний поделили на пачки документов и в LLM подавали промпт вместе с этой пачкой и просили выбрать ID документов, которые прямо или косвенно содержат ответ на запрос.
Создали сетку конфигурационных параметров для Retrieval, в том числе с разными быстрыми энкодерами: intfloat/multilingual-e5-large, ai-forever/FRIDA, nomic-ai/nomic-embed-text-v2-moe.
Простым перебором на валидационном и тестовом датасете нашли оптимальную комбинацию настроек Retrieval на метрике Recall@K.
Итого, финальная версия поиска состоит из следующих элементов настройки поиска:
Поиск по оригинальному и перефразированному LLM-запросу.
Семантический поиск:
ai-forever/FRIDA c промптом "search_query";
два вектора на тексты из полей «Вопрос» и «Ответ» из FAQ.
Полнотекстовый (BM25):
предобработка текста: нижний регистр, стемминг для русского языка, русские стоп-слова;
два разреженных вектора на тексты из полей «Вопрос» и «Ответ» из FAQ.
Reciprocal Rank Fusion Ranker для итоговой выдачи по гибридному поиску.
Причем разница в метриках между худшими и лучшими параметрами при фиксированном @K может достигать 30%.
LLM для RAG: почему мы остановились на Vikhr-Nemo-12B
Выбор LLM для RAG-системы — это тонкий поиск баланса между качеством ответов, поддержкой русского языка и затратами на GPU. Рассказываем, как мы нашли «золотую середину» для RUTUBE.
Ограничения и требования к LLM:
Запрет на проприетарные модели.
Оптимизация под GPU — модель должна работать быстро даже на ограниченных ресурсах.
Поддержка русского языка — необходима качественная генерация ответов на русском.
Почему Vikhr-Nemo-12B-Instruct-R
Модель от Vikhrmodels стала фаворитом хакатона не случайно. Вот ее ключевые преимущества.
Характеристика | Что это дает? |
12 млрд параметров | Оптимальный баланс между скоростью и качеством: работает быстрее крупных моделей, сохраняя уровень ответов, близкий к GPT-4 |
128k токенов контекста | Может анализировать длинные запросы с большим количеством контекста |
Grounded RAG режим | Автоматически находит ID релевантных документов — аналогично Command-R (RAG-оптимизированной модели от Cohere) |
Системные промпты | Легко управлять стилем ответов: от формального («Пункт 2.3.17 оферты…») до разговорного |
На момент выхода модель заняла 3 место в русскоязычном бенчмарке Ru-Arena-General с винрейтом 79,8%, уступив только gpt-4o-mini и gpt-4. Это говорит о её способности генерировать точные и информативные ответы. Более подробно с моделью можно ознакомиться на HuggingFace.
При всех достоинствах модели, напомним, что оказалось, что, несмотря на русскоязычную тренировку, модель лучше интерпретирует инструкции на английском. Возможно, это происходит из-за особенностей датасета Grandmaster-PRO-MAX, где часть данных была на англоязычных шаблонах. Об этом пишут в документации сами авторы модели.
Для инференса LLM мы выбрали vLLM. Вот ключевые причины, почему выбрали его:
Простота развертывания. Просто
pip install vllmили использование готового Docker-образа.Поддержка популярных архитектур: Llama, Mistral и др.
Высокая производительность и низкая задержка. vLLM использует технологию PagedAttention — это механизм оптимизации работы алгоритма Attention в трансформерах, который позволяет эффективно управлять памятью при обработке длинных последовательностей. Это позволяет динамически распределять ресурсы GPU, минимизируя простой и ускоряя генерацию текста. По сравнению с Hugging Face Transformers или DeepSpeed, vLLM демонстрирует на 20-40% более высокую пропускную способность запросов, особенно при работе с длинными последовательностями.
Оптимизация для реальных сценариев. vLLM поддерживает параллельную обработку запросов (batching) и потоковую передачу токенов, что критично для веб-сервисов и чат-ботов. Например, при большой нагрузке vLLM сохраняет стабильность, тогда как аналоги могут сталкиваться с падением производительности.
Активное развитие и открытость. Лицензия Apache 2.0. Проект поддерживается сообществом и регулярно обновляется.
Интеграция с системой работы с запросами пользователей
Для работы с запросами от клиентов в RUTUBE используется единое окно заявок на базе HelpDeskEddy (далее HDE). Мы интегрировали работу RAG-сервиса напрямую в HDE, где операторы непосредственно взаимодействуют с пользователями по различным каналам связи. Мы настроили работу RAG-системы так, что открывая тикет обращения клиента, оператор сразу видит подсказки от системы на заданные вопросы. Так оператор может быстро и удобно ответить на запрос: отправить готовую формулировку или скорректировать предложенный ответ(см. пример интерфейса на рисунке ниже).
Мониторинг качества RAG-системы
Внедрение RAG — это не разовая задача, а непрерывный процесс улучшений. Чтобы система не «проседала» со временем, мы настроили полный цикл сбора данных и анализа обратной связи.
Через Apache Kafka в реальном времени записываем все этапы обработки запроса и потом всё забираем в ClickHouse:
входящий запрос в виде исходного текста пользователя;
перефразированный вопрос — вариации, сгенерированные LLM для улучшения поиска;
документы от ретривера, ID чанков и их метаданные;
результаты реранкера;
ответ RAG;
ответ оператора.
На дашборде в Grafana мониторим ключевые метрики:
Главный KPI — % ответов «Я не знаю», целевой показатель < 15%.
Слепые зоны — категория вопросов, на которые система чаще всего не отвечает.
Среднее время ответа, контролируем, чтобы не превышало 10 секунд.
Конфликт ответов — случаи, где RAG и оператор дали разные ответы.
Ниже примеры дашбордов.
Мониторинг и дашборды помогают нам планомерно улучшать систему. Системный поиск слепых зон позволяет выявить, что пользователи часто обращаются с каким-то конкретным вопросом, на который бот не знает ответа, и добавить документы в FAQ или найти более комплексное продуктовое решение (см. статью наших customer journey experts, которые на основе комментариев и вопросов ищут пути улучшения пользовательского опыта).
Дашборд показывает «проседающие» метрики в реальном времени, с его помощью мы сразу же видим проблемы и получаем данные, для того чтобы их проанализировать, найти корень и исправить.
В результате за 3 месяца продакшен-эксплуатации RAG:
доля ответов «Я не знаю» упала на 20%;
среднее время ответа уменьшилось на 10%.
Итоговая архитектура проекта выглядит следующим образом.
Выводы: почему RAG-система — наш must-have
RUTUBE быстро растет, кстати, как с этим справляется инфраструктура, можно прочитать в этой статье. Естественно, чем больше пользователей, тем больше вопросов в поддержку, но скорость её ответов должна не измениться, а лучше увеличиться.
Без RAG это похоже на игру на реакцию, где предметы движутся всё быстрее и быстрее, а вероятность проиграть стремительно приближается к единице. С RAG же у нас есть чит-коды:
автоматизация — бот за секунды предлагает операторам готовые ответы;
актуальность — база знаний обновляется практически в реальном времени;
масштаб и надёжность — система выдержит любую нагрузку, даже если завтра к нам придут миллионы новых креаторов с вопросами про монетизацию. В отличие от операторской службы поддержки, которую так быстро не расширишь.
Что у нас уже есть, из чего сейчас состоит система автоматизации поддержки RUTUBE:
База знаний с автоматическим обновлением. FAQ регулярно обновляется с помощью Airflow. Парсер запускается каждые 60 минут, собирая актуальные документы и условия размещения контента без участия операторов.
Гибридный поиск с Milvus. Система объединяет семантический поиск (модель ai-forever/FRIDA) и классический BM25. Это позволяет находить ответы даже на сложные запросы, например, о причинах снижения монетизации.
Модель Vikhr-Nemo-12B для генерации ответов. Используемая LLM быстро формирует ответы и избегает недостоверных данных. Если информации недостаточно, система корректно уведомляет об этом.
Мониторинг на основе Kafka, ClickHouse и Grafana. Инструменты аналитики помогают выявлять и оперативно устранять слабые места в работе системы, включая пробелы в FAQ.
В итоге система уже экономит операторам время (и нервы!), а процент ответов «Я не знаю» уверенно снижается. Но это только начало — впереди еще много экспериментов и файнтюнинга моделей.
Пишите в комментариях, как еще можно улучшать RAG-системы. Или почему нам стоило выбрать вообще другой подход — мы как и наша поддержка читаем и ценим все комментарии и предложения ;)
Подписывайтесь на этот блог и канал Смотри за IT, если хотите знать больше о создании медиасервисов: в них инженеры Цифровых активов «Газпром-Медиа Холдинга» таких, как PREMIER, RUTUBE, Yappy делятся своим опытом и тонкостями разработки видеоплатформ.
