Опубликовано: 22.10.2026 | Источник: TechCrunch

```html

Доверие к ИИ в дипломе: архитектура объяснимости и метрики прозрачности для ВКР

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

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

Тема 1. Сервис оценки достоверности ответов LLM с трассировкой и журналом решений

Актуальность: статья прямо говорит о падении доверия при росте внедрения — значит, нужен слой контроля поверх модели.

Цель: спроектировать сервис-надстройку, который логирует запросы, ответы, источники и уверенность модели, а затем агрегирует их в отчёт о качестве.

• проанализировать существующие подходы к оценке ответов (LLM-as-a-judge, эталонные наборы, ручная разметка);
• спроектировать схему трассировки запросов через OpenTelemetry и разметку спанов;
• реализовать дашборд метрик и алерты на деградацию;
• провести нагрузочное тестирование и оценить накладные расходы.

Структура: гл. 1 — обзор подходов к доверию и объяснимости ИИ (NIST AI RMF, ГОСТ Р 59276-2020); гл. 2 — архитектура (C4-диаграммы, очереди, хранилище трасс); гл. 3 — протокол испытаний, метрики, расчёт ресурсов.

Тема 2. Модуль объяснимости прогнозов для рекомендательной системы

Актуальность: требование прозрачности из опроса переводится в конкретную техническую задачу — показать пользователю причину рекомендации.

Цель: разработать модуль генерации объяснений (SHAP-значения, правила, текстовые пояснения) и встроить его в существующий пайплайн.

• сравнить SHAP, LIME и суррогатные деревья по скорости и устойчивости;
• спроектировать асинхронный расчёт объяснений, чтобы не блокировать выдачу;
• оценить качество объяснений по метрикам полноты и стабильности;
• оценить прирост задержки и стоимость вычислений.

Структура: гл. 1 — теория объяснимости и стандарты качества (ISO/IEC 25010 в части функциональной пригодности); гл. 2 — проектирование интеграции; гл. 3 — эксперименты, графики, экономика.

Тема 3. MLOps-контур с контролем дрейфа модели и политикой человеческого подтверждения

Актуальность: низкое доверие — это в том числе страх, что модель тихо «поедет» и никто не заметит. Ответ — мониторинг дрейфа и human-in-the-loop.

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

• описать версионирование данных и моделей (DVC, MLflow);
• настроить контроль дрейфа входных данных и предсказаний;
• реализовать gate-проверки в пайплайне развертывания;
• рассчитать RTO/RPO для сервиса инференса.

Структура: гл. 1 — обзор MLOps-практик и требований к воспроизводимости; гл. 2 — схема пайплайна и развертывание в Kubernetes; гл. 3 — сценарии отказов, тесты, экономическое обоснование.

Аналитическая глава: как обосновать стек под задачу доверия

Первая глава — не «обзор литературы ради галочки». Постройте её вокруг критериев выбора, привязанных к тезису статьи: если пользователи не доверяют результату, значит, архитектура должна давать наблюдаемость и возможность перепроверки.

Практический приём: таблица сравнения решений по 5–6 критериям с весами. Комиссия любит такие таблицы, потому что выбор стека становится воспроизводимым, а не «мне понравилось».

Ссылку на статью TechCrunch используйте как обоснование весов: рост внедрения при падении доверия означает, что критерии наблюдаемости и соответствия требованиям нельзя занижать. Это и есть «актуальность» в нормальном, читаемом виде — без фразы «в современном мире».

Проектная часть: что рисовать и как описывать интеграцию

Схемы, без которых защита провалится

• Контекстная диаграмма (C4, уровень 1) — кто пользователи, какие внешние сервисы, где границы ответственности.
• Диаграмма компонентов — слой API, слой оркестрации запросов к модели, слой проверки и логирования, хранилище трасс.
• Диаграмма последовательности для сценария «запрос → генерация → валидация → ответ с пояснением».
• Схема данных — что именно вы храните о каждом запросе (это же ваш аргумент в пользу прозрачности).

Оформляйте по нотации UML или C4, но главное — единообразие и подписи на русском. Если рисовали в draw.io, приложите исходник в приложение: на защите часто просят открыть диаграмму и «покрутить».

Интеграция без лишней связанности

Типовой каркас: клиент → API-шлюз → сервис оркестрации → (модель, база знаний, сервис политик) → сервис логирования → ответ. Очередь (Kafka или RabbitMQ) между оркестратором и логированием снимает проблему блокировки при пиках — и даёт вам отличный материал для главы про тестирование.

POST /v1/answer
{
  "query": "...",
  "trace_id": "9f2c...",
  "require_explanation": true
}
→ 200 OK
{
  "answer": "...",
  "sources": [{"id": "doc-42", "score": 0.87}],
  "confidence": "medium",
  "trace_id": "9f2c..."
}

Обратите внимание: поле confidence — не украшение, а элемент доверия. Объясните в тексте, как оно вычисляется и почему выбрано именно такое представление.

Тестирование и метрики: где студенты теряют баллы

Раздел «Тестирование» — самое слабое место в ВКР по ИИ. Модель «работает» — не аргумент. Нужны числа.

Отдельно посчитайте, во что обходится «доверие» в ресурсах: сколько миллисекунд добавляет расчёт объяснений и сколько стоит хранение трасс за месяц. Такой расчёт превращает гуманитарный тезис из статьи в инженерное решение — и это ровно то, что хотят увидеть на защите.

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

• обосновывать выбор архитектуры через измеримые критерии, а не через «популярность»;
• строить наблюдаемость: трассировка, метрики, журналы, алерты;
• считать эксплуатационные затраты и задержки, защищать компромиссы;
• оформлять техническую документацию по ГОСТ 34.602-89 и пояснительную записку без «воды».

Обязательно ли обучать свою модель?

Нет. Для темы про доверие и прозрачность часто полезнее аккуратно обёрнуть готовую модель слоем валидации, логирования и объяснений. Обоснуйте отказ от обучения — это тоже результат. Но обязательно опишите, как именно вы контролируете качество чужой модели.

Как измерить «доверие пользователей» в дипломе?

Через прокси-метрики: доля ответов с источниками, доля запросов, где пользователь запросил пояснение, число повторных уточнений, результаты короткого опроса по шкале Лайкерта. Не пытайтесь измерять доверие «напрямую» — комиссия не поверит.

Где брать данные и можно ли использовать открытые датасеты?

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

Нужен ли работающий прототип?

Требования вузов различаются, но наличие работающего прототипа почти всегда плюс: он даёт вам скриншоты, метрики и демонстрацию на защите. Минимально жизнеспособный вариант — API + дашборд + прогон тестов — собирается за пару недель.

Источник: As more Americans adopt AI tools, fewer say they can trust the results (опубликовано 2026-03-30)

```