Опубликовано: 15.09.2026 | Источник: CNews (новости)

Генеративный ИИ в дипломе: от рекламного пилота к измеримому внедрению

Свежая новость с CNews от 24 марта 2026 года ломает привычную картину: до полноценного внедрения доходят лишь 7–10% пилотов с большими языковыми моделями, чат-ботами и ИИ-агентами, запущенных крупными технологическими компаниями в 2025 году. Остальные проекты либо застыли на стадии эксперимента, либо переписываются, либо закрываются. Причина, которую называют аналитики, звучит обидно просто — запускали громкие инициативы ради рекламного эффекта, а не рабочие решения.

Для выпускника ИТ-направления это не повод разочароваться в теме, а наоборот — готовый исследовательский полигон. Отрасль переходит от стадии «попробуем LLM везде» к стадии «докажем, что решение работает и стоит своих денег». Именно такой переход и есть предмет грамотной ВКР: не «сделаю чат-бота», а «спроектирую и обосную архитектуру, которая проходит проверку эксплуатацией». Ниже — как разложить это на главы, метрики и схемы так, чтобы работа защищалась на цифрах, а не на презентации.

Что именно произошло и почему это ваша тема

Цифра 7–10% — это не провал технологии, а провал методологии внедрения. Компании умеют быстро собрать демо на API внешней модели, но не умеют ответить на три вопроса: сколько стоит один ответ в рублях, что будет при деградации качества и кто отвечает за галлюцинации модели в продакшене. В дипломной работе эту разницу удобно превратить в исследовательскую проблему — «критерии перехода ИИ-пилота в промышленную эксплуатацию».

Ключевое преимущество такой постановки: у вас есть свежая эмпирическая база (данные за 2025–2026 годы), есть измеримый разрыв между ожиданием и результатом, и есть понятный заказчик результата — отдел, который боится вкладываться в ИИ-проект без методики оценки рисков.

Четыре темы ВКР, которые вырастают из этой новости

Тема 1. Методика оценки готовности ИИ-пилота к промышленной эксплуатации

• Актуальность: 90% пилотов не доходят до внедрения — значит, нужен формализованный чек готовности (production readiness), а не интуиция руководителя.
• Цель: разработать набор критериев и расчётную модель, по которой пилот получает статус «готов / не готов / требует доработки».
• Задачи: проанализировать причины остановки проектов; выделить группы критериев (качество, стоимость, надёжность, правовые риски); построить модель скоринга; проверить её на 2–3 сценариях.
• Структура: Глава 1 — анализ рынка и причин провалов пилотов; Глава 2 — проектирование модели критериев и оценочного листа; Глава 3 — расчёты на кейсах и экономическая интерпретация.

Тема 2. Архитектура RAG-сервиса для внутренней базы знаний предприятия

• Актуальность: именно «поиск по документам» чаще всего запускают как громкий пилот и первым же закрывают — из-за отсутствия контроля качества ответов.
• Цель: спроектировать сервис с контуром оценки достоверности и ограничением на источники.
• Задачи: сравнить векторные хранилища; спроектировать схему индексации и обновления документов; описать алгоритм отказа от ответа при низкой релевантности; заложить метрики наблюдаемости.
• Структура: Глава 1 — теория поиска и векторного представления текста; Глава 2 — компонентная и развёртываемая архитектура; Глава 3 — нагрузочные испытания и расчёт стоимости владения.

Тема 3. Контур мониторинга деградации качества языковой модели

• Актуальность: пилот закрывают не тогда, когда модель «плохая», а тогда, когда никто не замечает, что она стала хуже после смены версии или промпта.
• Цель: построить систему контроля качества, которая фиксирует падение метрик автоматически.
• Задачи: определить метрики качества ответов; реализовать сбор трассировок и обратной связи; настроить пороги оповещений; описать процедуру отката версии промпта.
• Структура: Глава 1 — обзор практик наблюдаемости; Глава 2 — архитектура контура сбора телеметрии; Глава 3 — эксперименты и расчёт эффекта от раннего обнаружения деградации.

Тема 4 (краткий вариант). Сравнение экономики облачной и локальной модели

Компактная работа на стыке архитектуры и экономики: расчёт порога, при котором собственная модель на своём оборудовании становится дешевле внешнего API, с учётом стоимости простоя и загрузки специалистов.

Аналитическая глава: не перечень фреймворков, а обоснование выбора

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

Опирайтесь на признанные рамки качества: ISO/IEC 25010 даёт модель характеристик (функциональная полнота, производительность, надёжность, сопровождаемость), а ГОСТ 34.602-89 — структуру технического задания. Это сразу снимает вопрос комиссии «а почему именно эти критерии».

Проектная часть: схемы и алгоритмы, которые ждут в главе 2

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

• компонентная схема сервиса с выделенным шлюзом запросов, хранилищем эмбеддингов и модулем оценки качества;
• диаграмма последовательности для одного запроса пользователя — от авторизации до записи метрики;
• схема развёртывания в контейнерной среде с указанием точек сбора телеметрии;
• алгоритм принятия решения «ответить / отказаться / отправить человеку».

Оформляйте схемы по ГОСТ 19.701-90, а не в свободном стиле — это дешёвый способ добавить работе веса.

Пример конфигурации контура наблюдаемости

service:
  name: rag-assistant
  slo:
    p95_latency_ms: 2500
    answer_faithfulness: 0.85
    cost_per_1k_requests_rub: 40
telemetry:
  traces: otlp://collector:4317
  attributes:
    - llm.model
    - llm.prompt_version
    - llm.tokens_in
    - llm.tokens_out
    - retrieval.top_k
alerts:
  - metric: answer_faithfulness
    condition: "< 0.7 за 30 минут"
    action: rollback_prompt_version

Такой фрагмент в приложении к диплому показывает, что вы понимаете: качество ИИ-сервиса — это не только модель, но и сбор данных о её поведении.

Глава о тестировании: чем доказать, что ваш пилот не попал в те 90%

Метрики делятся на три слоя, и путать их нельзя.

• Качество ответа: доля фактически верных ответов на подготовленном наборе вопросов, доля отказов при отсутствии данных, устойчивость к переформулировке запроса.
• Производительность и стоимость: время ответа на 95-м процентиле, число запросов в секунду, средняя стоимость тысячи запросов, расход токенов на один диалог.
• Надёжность эксплуатации: доступность сервиса, время восстановления после сбоя (RTO), допустимая точка потери данных (RPO), поведение при недоступности внешнего поставщика модели.

Отдельно опишите методику набора тестовых вопросов: 50–100 пар «вопрос — эталонный ответ», собранных вручную по вашей предметной области. Это снимает типичную претензию «где вы взяли данные для оценки».

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

Что проверить перед сдачей

Чему вы научитесь на такой работе

Первое — переводить размытое «внедрить ИИ» в архитектурные решения с явными компонентами и зонами ответственности. Второе — обосновывать стек через критерии, а не через популярность. Третье — строить систему метрик, включая экономические показатели и показатели надёжности. Четвёртое — оформлять техническую документацию так, чтобы её приняли без переписывания. Пятое, и самое ценное на собеседовании, — умение объяснить, почему большинство похожих проектов останавливается на этапе пилота и что именно вы сделали иначе.

Частые вопросы

Насколько сложно реализовать такую систему студенту в одиночку?

Базовый вариант RAG-сервиса с внешней моделью и локальным хранилищем документов собирается за 2–3 недели, если не изобретать собственный слой обработки текста. Основное время уйдёт не на код, а на подготовку тестовых вопросов и расчёт метрик.

Обязательно ли писать работающий код для ВКР?

Требования вузов различаются. Для инженерных направлений прототип почти всегда обязателен, для аналитических иногда достаточно модели и расчётов. Уточните это на кафедре до выбора темы — от ответа зависит вся структура главы 2.

Как оформить диаграммы, если я не умею рисовать по стандартам?

Используйте нотацию UML для поведения системы и схемы компонентов для структуры, а затем приведите оформление к требованиям ГОСТ 19.701-90: рамка, шрифт, расшифровка обозначений. Инструменты вроде draw.io или PlantUML экономят время, но проверьте, что экспорт даёт читаемый векторный формат.

Где брать данные для оценки качества ответов?

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

Источник: Российский бизнес массово сворачивает ИТ-проекты по внедрению генеративного ИИ (опубликовано 2026-03-24)