В марте 2026 года команда SberAI, MWS AI (МТС Web Services) и ряд российских университетов представили первую методологию оценки ИИ-ассистентов именно на русском языке — не перевод западных наборов, а самостоятельный корпус заданий с отечественной спецификой: падежи, канцелярит в запросах, реалии законодательства, смешение языков в одном промпте. Почему это важно вам, а не только корпорациям? Потому что защита ВКР по ML/LLM перестала быть про «я дообучил модель». Комиссия спрашивает: а как вы измерили, что стало лучше? Если вы не можете показать протокол прогона, набор метрик и разметку, ваша работа — демо, а не исследование. Ниже — как встроить этот кейс в диплом так, чтобы третья глава стала самой сильной частью защиты.
Да. Оценивайте то, что доступно: открытые модели (Qwen, Mistral, YandexGPT API, GigaChat API), собственный RAG-ассистент или даже офлайн-конфигурацию на локальном сервере с GPU. Ценность ВКР — в методологии сравнения, а не в логотипе модели. Зафиксируйте версии, температуру, дату прогона — воспроизводимость важнее «крутизны» объекта.
Три законных пути: (1) публичные наборы — ruMMLU, RussianSuperGLUE, MERA, ru-адаптации SQuAD; (2) собственный домен-специфичный корпус: 100–300 запросов, размеченных вручную по рубрикам, плюс раздел «сложные случаи»; (3) синтетика от сильной модели с обязательной ручной валидацией выборки (не менее 20%) и коэффициентом согласия разметчиков. Третий путь чаще всего и даёт научную новизну — при условии прозрачного описания.
Не одна и не пять «на всякий случай». Минимально защищаемая связка: формальные метрики (Exact Match, ROUGE-L или BERTScore-ru) + оценка человеком по рубрике (релевантность, фактичность, полнота) + операционные метрики (latency p95, стоимость 1000 запросов). Плюс обязательный компонент — доля галлюцинаций и отказов. Каждая метрика должна отвечать на вопрос «какое решение по архитектуре она обосновывает».
По ГОСТ 19.301-79 «Программа и методика испытаний» — если объект оформляется как программа для ЭВМ. Для систем в целом используйте ГОСТ 34.601-90 в части стадий. Качество закладывайте по ISO/IEC 25010: функциональная полнота, точность, производительность, удобство — ровно те характеристики, которые вы измеряете. Таблица «характеристика → метрика → способ измерения → критерий приёмки» закрывает 90% замечаний.
Тема 1. Методология сравнительной оценки русскоязычных ИИ-ассистентов.
Актуальность: статья CNEWS показывает, что индустрия только формирует русскоязычный стандарт оценки — значит, ваш вклад в методологию востребован.
Цель: построить воспроизводимый стенд оценки и сравнить 3–4 ассистента.
Задачи: обзор метрик и бенчмарков; сбор доменного набора запросов; реализация прогона и логирования; расчёт согласия разметчиков; формулировка рекомендаций по выбору модели.
Структура: Гл. 1 — анализ подходов и стандартов качества; Гл. 2 — архитектура стенда и структура датасета; Гл. 3 — эксперименты, метрики, выводы.
Тема 2. RAG-ассистент по нормативной базе с оценкой фактичности ответов.
Актуальность: именно прикладные ассистенты (юрист, делопроизводитель, инженер) страдают от галлюцинаций, а методика из статьи даёт язык, на котором это обсуждать.
Цель: снизить долю недостоверных ответов при сохранении полноты.
Задачи: спроектировать конвейер извлечения и ранжирования; собрать эталонные вопрос-ответ пары; замерить faithfulness и coverage до/после; оценить стоимость токенов.
Структура: Гл. 1 — теория RAG и метрики достоверности; Гл. 2 — проектирование индекса и промптов; Гл. 3 — A/B-эксперимент и экономика решения.
Тема 3. Согласованность автоматической оценки (LLM-as-a-judge) с человеческой разметкой.
Актуальность: корпоративные методологии всё чаще используют модель-судью, но на русском языке калибровка почти не описана.
Цель: определить, при каких рубриках и настройках судья воспроизводит оценки экспертов.
Задачи: разработать рубрику; провести двойную слепую разметку; рассчитать каппу Коэна и корреляции; выявить систематические смещения (длина ответа, порядок вариантов).
Структура: Гл. 1 — обзор human evaluation; Гл. 2 — протокол разметки; Гл. 3 — статистика согласия и границы применимости судьи.
Не ограничивайтесь фразой «существуют различные подходы». Постройте таблицу сопоставления: зарубежные бенчмарки (MMLU, HELM) против русскоязычных (MERA, ruMMLU, новый набор из статьи). Столбцы: язык, тип заданий, способ разметки, метрика агрегации, ограничения. Затем — абзац о том, чего не хватает для вашего домена. Это и есть постановка задачи. Диаграмму здесь уместно сделать в нотации C4 уровня «контекст»: пользователь → ассистент → подсистема оценки → хранилище артефактов.
Разложите систему на четыре слоя: набор данных, слой инференса, слой метрик, слой хранения и отчётности. Для каждого — обоснование выбора инструмента. MLflow закрывает трекинг прогонов и артефактов, DVC — версионирование датасетов (важно: комиссия любит вопрос «а данные у вас какой версии?»), OpenTelemetry с GenAI-конвенциями даёт трейсы по каждому запросу, если ассистент развёрнут как сервис. Схему развёртывания нарисуйте в UML component diagram — этого достаточно, BPMN здесь лишний.
Опишите протокол до начала прогона: температура 0, фиксированные версии моделей, три повторности на запрос (для оценки дисперсии), слепая разметка. Ниже — сводка метрик и их смысл.
| Метрика | Что показывает | Когда применять | Инструмент |
|---|---|---|---|
| Exact Match / F1 | Совпадение с эталоном | Извлечение фактов, короткие ответы | собственный скрипт |
| ROUGE-L, chrF | Лексическое перекрытие | Суммаризация, генерация | evaluate (HF), sacrebleu |
| BERTScore-ru | Семантическая близость | Перефразированные эталоны | ruBERT-based модель |
| Faithfulness, Answer Relevance | Опора на контекст, релевантность | RAG-ассистенты | RAGAS-подобный пайплайн |
| Win-rate (попарно) | Предпочтение человеком | Финальное сравнение версий | слепая разметка + Брэдли–Терри |
| Каппа Коэна | Согласие разметчиков | Валидация рубрики | statsmodels, sklearn |
| Latency p50/p95, cost/1k токенов | Пригодность к внедрению | Обоснование архитектуры | OpenTelemetry, MLflow |
# eval_config.yaml — воспроизводимый прогон бенчмарка
run_name: ru_assistant_v1
dataset:
path: data/ru_domain_bench_v1.jsonl
fields: [prompt, reference, task_type, difficulty]
split: { dev: 0.1, test: 0.9 }
models:
- id: assistant-a
endpoint: http://llm-gw/v1/chat/completions
temperature: 0.0
repeats: 3
- id: assistant-b
endpoint: http://llm-gw/v1/chat/completions
temperature: 0.0
metrics:
lexical: [exact_match, rouge_l, chrf]
semantic: [bertscore_ru, embedding_cosine]
judge: { model: judge-7b, rubric: data/rubric_ru.md, scale: "1..5" }
ops: [latency_p50, latency_p95, tokens_in, tokens_out, cost_rub]
logging:
tracker: mlflow
artifact_store: s3://thesis/artifacts
telemetry: opentelemetryТакой конфиг удобно вынести в приложение к ВКР: он доказывает, что эксперимент воспроизводим, а не «получен один раз в блокноте».
1. Оценивать «на глаз» по 5 примерам. Комиссия задаст вопрос о статистике — и защита посыпется. Материал статьи прямо намекает: методология предполагает корпус и рубрику, а не единичные наблюдения. Минимум — 100 запросов на класс задач и три повторности.
2. Подменять оценку качества оценкой модели-судьи без валидации. LLM-as-a-judge удобен, но у него есть смещения: завышает длинные ответы, чувствителен к порядку вариантов. Без расчёта согласия с человеком такая метрика не защищаема.
3. Игнорировать операционные метрики. Ассистент с лучшим ROUGE, но с p95 в 12 секунд и ценой 40 рублей за запрос в продакшн не пойдёт. Сравнивайте по Парето: качество против задержки и стоимости.
Если до защиты осталось не так много времени, а стенд оценки, разметка и третья глава ещё не собраны — есть смысл обсудить это со специалистом. Мы выделяем до 120 часов на работу по вашей теме, консультация по структуре и метрикам — бесплатная, и она одинаково полезна и тем, кто пишет сам, и тем, кто хочет заказать ВКР под ключ. Помогаем с любой темой, включая LLM-оценку и RAG-ассистенты.
Источник: Исследователи разработали новую методологию оценки работы ИИ-ассистентов на русском языке (опубликовано 2026-03-25)