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

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

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

Предыстория

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

Наши курсы занимают две площадки: теория лежит на платформе для онлайн-обучения крупного EdTech-провайдера, а практика параллельно проходит в личном кабинете (ЛК) уже нашего облака. Связаться с нами слушатели могут по-разному: написать на почту, в чат на учебной платформе и чат с облачной поддержкой в ЛК. Соответственно, вопрос «В каком уроке говорили про…?» или «Как подключиться к виртуальной машине?» они могут задать там, где им удобно.

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

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

Могли бы собирать гигантские списки FAQ, но в вопросах в личном кабинете облака не скажешь, куда придет сертификат по окончании курса, и наоборот. И по опыту это не работает, FAQ никто не читает. Проще даже самый типовой вопрос задать оператору в чате или поисковику.

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

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

Остался один вариант — самим сделать AI-помощника, который будет брать информацию из нашей базы знаний и давать точный и релевантный ответ, и интегрировать его в платформу обучения. Самим, потому что готовых решений рынок пока не предлагает. Разве что только Evahelp.ai, но это SaaS-сервис с фиксированной архитектурой, а нам был нужен кастомный вариант, который будет работать внутри корпоративной инфраструктуры. 

В ЛК облака уже есть свой AI-помощник, но его база знаний — документация по облачным сервисам. Так что на вопрос «как запустить виртуальную машину» он ответит и даже сам ее создаст, а вот по курсам не подскажет от слова совсем.

Архитектура AI-помощника в онлайн-обучении

Под капотом нашего AI-помощника лежит несколько сущностей: облачное S3-хранилище, эмбеддер Qwen3-Embedding-0.6B, реранкер Qwen3-Reranker-0.6B, полнотекстовый поиск OpenSearch, векторная база данных Qdrant, оркестратор Prefect, генерирующая LLM GigaChat-2-Max. Мы тестировали разные модели, но именно эта связка эмбеддера и реранкера показала себя лучше всех в нашем baseline. А использование OpenSearch и поиск по эмбеддингам дает гибридный вариант и, как следствие, более высокое качество ответов генеративной модели.

Чтобы помощник не терялся в технической терминологии, а также для лучшей работы поиска, мы прикрутили к OpenSearch словарь синонимов. Сам pipeline многим уже известен: сначала запрос пользователя прогоняется через эмбеддер, чтобы по получившемуся вектору найти ближайшие эмбеддинги, а параллельно с этим происходит полнотекстовый поиск по алгоритму ВМ25. Выдача дедуплицируется и подается в реранкер для лучшего ранжирования чанков. В итоге получаем выдачу Top-К.

Мы выбрали подход RAG, чтобы помощник отвечал по определенному контексту, извлекая данные из загруженной базы, в которой есть вся информация по курсам. Например, пользователь спрашивает: «В каком модуле курса Cloud.ru Evolution Fundamentals рассказывают про группы безопасности?». Если помощник работает не с RAG, он сгенерирует рандомный ответ. А с RAG он сходит в базу и даст точный ориентир.

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

Сервис индексации каждый день берет данные из хранилища, нарезает их на чанки и кладет в векторную базу данных Qdrant, прогнав их перед этим через эмбеддер. Так мы обеспечиваем актуальность ответов. Когда пользователь задает вопрос помощнику, реранкер подает выдачу Тop-К в генеративную модель, которая уже отвечает пользователю. Эта финальная модель может быть любой, у нас это GigaChat-2-Max.

После запуска AI-помощника мы включили в его архитектуру модуль GuardRails, чтобы он фильтровал запросы и повысил безопасность всей системы. Он отсекает попытки промпт-инъекций и запросов, нацеленных на поломку RAG.

Проверка ответов помощника с Ragas

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

Можно, конечно, нанять сотню асессоров, которые разметят тексты и сравнят их side by side, но у нас такой возможности не было. Поэтому мы подключили автоматическую разметку и оценивание — Ragas, а потом я и моя коллега-методист проверяли ответы модели.

Поскольку помощник построен на RAG, мы можем в любой момент обновить системный промпт, например, «называй оператора методистом», а если не устраивает скорость ответа — поменять модели эмбеддера и реранкера.

Несколько ошибок, которые мы обнаружили на этапе ручкой проверки:

• помощник не учитывал процесс или сбивался с него: говорил, что позовет оператора, хотя у нас методисты и они технически не могут подключиться в окно AI-помощника;

• модель галлюцинировала и отвечала тем, чего нет в содержании курсов;

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

Мы избавились от этих ошибок таким образом. Во-первых, применили few-shot learning для системного промпта. Во-вторых, помогла связка моделей эмбеддера Qwen3-Embedding-0.6B и реранкера Qwen3-Reranker-0.6B. С самого начала эмбеддер и реранкер были multilingual-e5-large, а потом — bge. В итоге лучший результат показывает связка именно Qwen3.

Дотюнивание помощника через разные виды запросов

Чтобы помощник корректно реагировал на разные типы пользовательских вопросов, мы протестировали его на двух видах запросов — single-hop и multi-hop. Каждый из них разделили еще на specific, то есть вопросы на конкретные темы, и abstract, общие вопросы.

Single-hop — запрос, ответ на который мы можем найти, например, за один поход в RAG или из одного конкретного источника.

Multi-hop — запрос, при котором генерирующая модель ходит в RAG два раза: с начала с одной формулировкой ответа, потом с другой. Затем она миксует ответы и выдает финальный вариант.

Разберем на примерах:

«Как CNews Analytics говорит о выручке AI-сервисов Cloud.ru?» — это single-hop запрос, и он specific query, потому что в нем указан конкретный источник и конкретный облачный провайдер. Можем сходить один раз в RAG и получить ответ.

«Как облачные технологии могут помочь в бизнесе?» — тоже single-hop, но уже abstract query. Про какой бизнес речь, какие облачные технологии? Достаточно один раз сходить в RAG и сгенерировать хороший ответ.

«Что такое виртуальная машина и как к ней подключиться?» — multi-hop specific запрос. В нем есть конкретные сущности: виртуальная машина и как к ней подключиться. Мы можем отдельно поискать в базе знаний, что такое виртуальная машина, и отдельно, как к ней подключиться. Но правильно будет два раза сходить в RAG и совместить ответы.

Граф знаний в связке с Ragas: автоматическая проверка ответов

Я дам не очень точное, но пользовательское описание. Можно сказать, что Ragas симулирует работу живых асессоров: он сам формирует вопросы и автоматически оценивает ответы модели. А граф знаний — это структура, где данные (темы, понятия, документы) представлены как узлы, а связи между ними отражают контекст и отношения. Используя граф, Ragas может генерировать более осмысленные, «человеческие» вопросы и оценивать ответы модели не просто по совпадению текста, а по тому, насколько логично модель прошла по цепочке знаний. Это повышает точность и «интеллектуальность» автооценки.

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

Внутри графа знаний три модели:

• generator-LLM генерит ответ,

• critical-LLM оценивает, что нагенерила generator-LLM,

• judge-LLM работает уже для финального оценивания того, что сгенерировала generator-LLM.

Мы выбираем одну ноду и на ее основе генерируем запрос. А по соседним нодам смотрим наш контекст и примерный эталонный ответ, по которому мы можем измерить ответ. Все происходит автоматически: под капотом у Ragas куча своих промптов и походов в LLM, каждый из которых отвечает за свою часть.  

Метрики, на которые ориентируется Ragas

Метрики для retrieval — оцениваем то, что выдает RAG:

• context precision показывает, много ли шума в переданном контексте, есть ли в нем куски текста, которые могут увести модель не туда; 

• context recall говорит о том, что мы передаем действительно релевантный контекст. Нет ли такого, что на этапе поиска мы упустили какую-то важную информацию, которая содержит в себе что-то важное, а LLM просто не увидит это и сгенерирует что-то от себя. По сути, это обычный precision recall, как в задаче какой-нибудь классификации.

Метрики для generation — оцениваем то, что выдает генеративная LLM:

• faithfulness — достоверность, то есть насколько модель правильно использует переданный контекст. LLM не детерминированная штука, она может добавлять что-то от себя;

• answer relevancy — насколько ответ модели релевантен вопросу. Тут уже мы больше смотрим на тот запрос, с которым к нам пришел пользователь, и уже сравниваем. Действительно LLM отвечает на него, а не просто делает какую-то, например, суммаризацию по тем чанкам, которые мы получили. 

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

Нюансы, которые стоит учитывать

• На всех этапах проверки ответов стоит использовать метод adapt для адаптации метрик, генерации графа знаний, формирования вопросов и «персон», иначе говоря, симулированных ролей, которые Ragas (или LLM-судьи) используют при генерации и проверке ответов.

• Лучше использовать сегментатор, который рассчитан на русский язык, понимает русскую пунктуацию и грамматику, иначе модели будут работать с искаженным контекстом. Можно выбрать из этих: razdel, nltk punkt_ru, deeppavlov tokenizer.

• Стоит добавить в датасет ассесорские разметки — это улучшит качество последующей автооценки.

• Тестировать вызов нужных function tools лучше отдельно.

• Переписывать вопросы можно не отдельным запросом в LLM, а с few-shot learning, адаптируя их к узкодоменной области.

• Расписывать function calling в pydantic-модели надо подробно, используя тот же few-shot learning.

• Можно использовать несколько вызовов подряд за один вопрос в случае multi-hop запросов.

• В description tool надо обязательно указывать LLM, как нужно переписывать запрос. Понятно, что в документации это все немножко не так выглядит. Поэтому можно ей прям дать парочку few-shot примеров. Еще важно указать, что multi-hop запросы нужно разбивать на несколько.

• Важно правильно и досконально описывать fusionlearning (объединение контекстов или результатов) даже при описании вашей функции по идентичной модели.

Что в итоге

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

• 57% обучающихся ответили, что AI-агент быстро давал ответ и так помог им пройти курс;

• Customer Satisfaction Index (CSI) вырос незначительно, всего на 6%;

• а вот важная метрика Completion Rate (COR) выросла в полтора раза. И это при том, что мы не внедряли помощника в этап тестирования, ассессмента или оценки. Он есть только на этапе ознакомления с видео, текстами, лонгридами и так далее.

А вы уже делали AI-помощника, на чем строили его архитектуру?