Управление ИИ в ВКР: контур контроля, метрики и понятная защита

Мартовская статья на ComNews «Я тебя породил, я тебя и приручу» точно подмечает: ИИ перестал быть демо-слайдами и «робкими экспериментами». Он входит в контуры реальных систем — а значит, комиссии больше не воспримут диплом про «нейросеть ради нейросети». Им нужно видеть, как вы управляете моделью, ограничиваете её действия и измеряете результат. Это не усложнение. Это готовый каркас для ВКР, где спокойно уживаются архитектура, стандарты и практические расчёты. Ниже покажу, как написать ВКР без воды, используя тренд на «приручение» искусственного интеллекта.

Три темы ВКР, которые вырастут из статьи

1. Контур контроля для ИИ-сервиса на базе Kubernetes

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

Цель: спроектировать контур контроля для ИИ-сервиса, обеспечивающий валидацию входных и выходных данных, журналирование решений и алертинг.

Задачи:

• провести анализ рисков при внедрении ИИ в прикладную систему;
• выбрать компоненты контура контроля (валидатор, верификатор, трейсер, алерт-менеджер);
• развернуть ИИ-сервис в Kubernetes с политиками ограничения ресурсов;
• провести нагрузочное тестирование и оценить время реакции контура.

Структура: Глава 1 — анализ предметной области и сравнение подходов; Глава 2 — архитектура и описание схемы контура; Глава 3 — тестирование и оценка эффективности.

2. Оценка качества ИИ-системы по ISO/IEC 25010 для аттестации

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

Цель: разработать модель метрик качества для ИИ-сервиса на основе ISO/IEC 25010 и адаптировать её под требования вуза.

Задачи:

• изучить стандарты ISO/IEC 25010, ГОСТ 34.602-89, а также рекомендации по тестированию ИИ;
• выделить показатели качества: функциональность, производительность, надёжность, безопасность;
• спроектировать методику сбора метрик;
• провести экспериментальную оценку на реальном или синтетическом наборе данных.

Структура: Глава 1 — стандарты и сравнительная таблица; Глава 2 — модель качества; Глава 3 — эксперимент и экономическое обоснование.

3. CI/CD-пайплайн и мониторинг ML-моделей в промышленной среде

Актуальность: статья показывает, что ИИ «набрал обороты» — вместе с ними растёт потребность в MLOps. Модель должна автоматически переобучаться, проходить валидацию и разворачиваться без остановки сервиса.

Цель: разработать CI/CD-пайплайн для автоматизации поставки моделей ИИ.

Задачи:

• исследовать этапы жизненного цикла ML-модели;
• настроить пайплайн сборки, тестирования и деплоя;
• интегрировать OpenTelemetry для трассировки запросов к модели;
• оценить сокращение времени выкатки и количество ошибок.

Структура: Глава 1 — обзор инструментов; Глава 2 — проектирование архитектуры; Глава 3 — эксперименты и оценка метрик.

Аналитическая глава: сравниваем решения и обосновываем стек

Недостаточно написать «мы использовали Kubernetes, потому что он популярный». В аналитической главе нужно сравнить минимум три варианта и показать, почему вы выбрали именно этот. Таблица — идеальный способ сделать раздел наглядным.

Статья даёт удобный аргумент: ИИ перешёл из песочницы в прод. Значит, в дипломе нужно обосновывать стек не «модностью», а требованиями к отказоустойчивости и наблюдаемости.

Проектная часть: схема контура управления и интеграция

Представьте простую схему: входные данные → валидатор → ИИ-модель → верификатор → журнал решений → алерт-менеджер. Такая схема легко становится основой второй главы диплома. В работе её можно оформить в нотации UML или C4-model. Для каждого блока пропишите назначение, входные и выходные данные, протоколы обмена.

Не забудьте про техническое задание. Оформление ТЗ по ГОСТ 34.602-89 — это часто обязательное требование вуза, и здесь статья помогает подчеркнуть контроль и ограничения. Опишите функциональные и нефункциональные требования к ИИ-сервису, а затем покажите, как они влияют на архитектуру.

Пример фрагмента конфигурации для сбора метрик через OpenTelemetry:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch:
    timeout: 1s

exporters:
  logging:
    verbosity: detailed

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [logging]

В дипломе этот код превращается в описание «сбора трассировок для анализа решений модели».

Тестирование и метрики: RTO/RPO, нагрузка, дрейф моделей

Многие студенты ограничиваются фразой «система протестирована». Так делать нельзя. Для защиты нужны числа. Минимальный набор метрик, который перекрывает почти любые требования вуза:

Нагрузочное тестирование удобно проводить с помощью JMeter или Locust. Если диплом посвящён ИИ, добавьте проверку дрейфа: как меняется метрика качества модели через неделю после переобучения. Это сразу поднимает работу выше среднего уровня.

Чему вы научитесь

• Обоснованно выбирать архитектуру и фреймворки для ИИ-решений.
• Строить контур контроля: валидация, верификация, алертинг.
• Работать с Kubernetes и OpenTelemetry на уровне описания и первичной настройки.
• Оформлять техническую документацию с учётом ГОСТ 34.602-89 и ISO/IEC 25010.
• Собирать метрики и превращать их в таблицы для защитной речи.

Типичные ошибки студентов

FAQ: частые вопросы перед защитой

Чек-лист «Что проверить перед сдачей»

Источник: Я тебя породил, я тебя и приручу. Попытка подчинить искусственный интеллект естественному (опубликовано 2026-03-22)