Оценка стоимости технологий будущего: как интегрировать прогнозы по термоядерной энергетике в ВКР по Data/ML-инженерии
В апреле 2026 года MIT Technology Review опубликовала статью «Will fusion power get cheap? Don’t count on it», в которой исследователи из ETH Zurich и других центров показали, что опытный опыт (experience rate) термоядерных реакторов может составлять всего 2–8% — то есть не быстрее, чем у атомной энергетики, но значительно медленнее, чем у солнечной или аккумуляторной техники. Это не просто «прогноз», а практический сигнал: если вы проектируете систему оценки TCO для энергетических решений, вы должны учитывать не только текущие технологии, но и их кривую обучения — особенно когда речь идёт о «технологиях на стадии прототипа».
Это важно для выпускников ИТ: даже если вы не работаете напрямую с ядерной физикой, в вашей дипломной работе могут возникнуть задачи, где требуется анализировать стоимость внедрения новых технологий — от прогнозирования цен на ИИ-инфраструктуру до моделирования затрат на облачные решения. Статья — отличный пример того, как научно обоснованный подход к метрикам (например, experience rate) может быть адаптирован под любую предметную область, где есть «неизвестное будущее».
Темы ВКР: три варианта для Data/ML-инженера
| Тема | Актуальность (по статье) | Цель | Задачи | Структура |
|---|---|---|---|---|
| Прогнозирование стоимости ИИ-инфраструктуры через метрику experience rate | Статья показывает, что при отсутствии масштабного производства цена может снижаться медленнее, чем ожидается. Для ML-систем это критично: обучение моделей требует значительных вычислительных ресурсов, и их стоимость зависит от кривой обучения. | Создать модель оценки TCO для ML-инфраструктуры с учётом experience rate и её влияния на долгосрочную эффективность. | 1. Анализ существующих кривых обучения (solar, batteries, fission). 2. Построение гипотетической кривой для ИИ-инфраструктуры. 3. Оценка влияния на ROI и TCO. 4. Разработка методики валидации прогнозов. |
Глава 1 — Теоретические основы: ISO/IEC 25010, метрики качества, TCO. Глава 2 — Проектирование: выбор стека (Kubernetes + Prometheus), сценарии нагрузки. Глава 3 — Тестирование: сравнение с реальными данными (например, AWS pricing history). |
| Моделирование инвестиций в «неразвернутые» технологии: на примере термоядерной энергетики | Статья использует интервью с экспертами и оценку трёх параметров: размер, сложность, необходимость кастомизации. Это — классический подход к оценке «технической зрелости». | Разработать методологию оценки инвестиционной привлекательности новых технологий на основе анализа их «технической зрелости». | 1. Классификация технологий по уровню зрелости (TRL). 2. Формализация параметров: unit size, design complexity, customization. 3. Построение матрицы оценки. 4. Применение к реальным проектам (например, AI in healthcare). |
Глава 1 — Методология: PMBOK 7, C4-модели, UML. Глава 2 — Архитектура системы оценки. Глава 3 — Валидация на примере 2–3 проектов. |
| Контроль бюджета в условиях неопределённости: применение метрики experience rate в DevOps-процессах | Статья подчёркивает, что «мы ещё не построили это», поэтому предсказания основаны на аналогиях. Это вызывает риск перерасхода бюджета. | Разработать механизм контроля бюджета в CI/CD-пайплайнах с учётом неопределённости. | 1. Анализ ошибок в прогнозировании затрат (например, в Kubernetes-кластерах). 2. Введение корректирующего коэффициента на основе experience rate. 3. Интеграция с OpenTelemetry для мониторинга фактических расходов. 4. Автоматизация отчётов по TCO. |
Глава 1 — Обзор нормативов: ГОСТ 34.19, ISO/IEC 25010. Глава 2 — Реализация: скрипты на Python, конфигурации Terraform. Глава 3 — Тестирование: сценарии с различной степенью неопределённости. |
Как использовать материал статьи в главах диплома
Глава 1 — Теоретическая база: от experience rate к TCO
Во всех трёх темах ключевой элемент — experience rate. В статье он определяется как процент снижения цены при удвоении мощности. Это не просто цифра — это метрика, которую можно использовать для оценки будущей стоимости любого капитального проекта.
Пример реализации в Python:
def experience_rate_to_tco(base_cost, t, exp_rate=0.05):
"""Расчёт TCO по экспоненциальному закону"""
return base_cost * (1 - exp_rate) ** (np.log2(t / 1)) # t — количество установленных единиц
# Пример: 1 млрд $ за первый реактор, 5% experience rate
print(experience_rate_to_tco(1e9, 100)) # ~300 млн $
Этот код можно включить в раздел «Методика расчёта TCO» и использовать для сравнения с реальными данными (например, из AWS Pricing Calculator или данных по строительству АЭС).
Глава 2 — Проектирование: как построить модель оценки
Для моделирования «технической зрелости» используйте C4-диаграммы (Level 1–3) для визуализации компонентов. Например, в теме про инвестиции в «неразвернутые» технологии:
- Уровень 1:
[System] Fusion Power Plant → [Container] Control System - Уровень 2:
[Container] Control System → [Component] Plasma Confinement Module - Уровень 3:
[Component] Plasma Confinement Module → [Service] Magnetic Field Controller
На каждом уровне добавьте метки: [complexity: high], [customization: medium], [unit_size: large]. Эти метки затем используются в формуле:
score = (complexity + customization + unit_size) * 0.33
Такая модель позволяет автоматически рассчитать «коэффициент риска» и внести его в бюджетное планирование.
Глава 3 — Тестирование: валидация прогнозов
Все три темы требуют проверки на реальных данных. Например, в теме про ИИ-инфраструктуру:
- Соберите данные по ценам на GPU-кластеры за 2020–2025 гг. (AWS, GCP, Azure).
- Постройте кривую обучения и сравните с гипотетической кривой по experience rate = 0.06.
- Вычислите RMSE и R² — если R² < 0.6, значит, модель не подходит.
Если вы используете OpenTelemetry, соберите метрики по времени выполнения задач и количеству использованных ресурсов — они помогут уточнить модель.
Чему вы научитесь
- Проектировать отказоустойчивые схемы оценки TCO с учётом неопределённости.
- Настраивать CI/CD-пайплайны с валидацией по метрикам (например, experience rate).
- Формализовать параметры «технической зрелости» и интегрировать их в процесс принятия решений.
- Оформлять ТЗ и технические требования по ГОСТ 34.19 и ISO/IEC 25010.
- Рассчитывать и визуализировать TCO с помощью Python и OpenTelemetry.
- Неверная интерпретация experience rate. Некоторые думают, что 2% — это «быстро», но на самом деле это хуже, чем у фиссии. Важно сравнивать с другими технологиями, а не с нулём.
- Игнорирование фактора «не построено ещё». В статье чётко говорится: «We haven’t built the thing yet». Это значит, что любое предсказание должно содержать доверительный интервал и сценарии «что если».
- Отсутствие обратной связи в модели. Без мониторинга (например, через OpenTelemetry) невозможно корректировать прогнозы. Модель без валидации — просто красивый слайд.
FAQ: частые вопросы студентов
Как выбрать стек для реализации модели?
Для TCO-модели — Python + Pandas + Plotly. Для визуализации архитектуры — C4-диаграммы в Mermaid.js или Lucidchart. Для мониторинга — OpenTelemetry + Prometheus. Не надо «перегружать» стек: главное — чтобы всё работало и было легко объяснить на защите.
Где взять реальные данные для валидации?
Для ИИ-инфраструктуры — AWS Pricing Calculator, Google Cloud Pricing Calculator, Kaggle (данные по GPU-времени). Для энергетики — IEA, IAEA, NREL. Важно указать источник в приложении и сделать ссылку на таблицу с датами.
Как оформить диаграммы и схемы по ГОСТ?
Все диаграммы должны иметь номер и название. Например: «Рисунок 2.1 — C4-модель системы управления термоядерным реактором». В приложении — список всех схем с датами и версиями. Убедитесь, что шрифт — Times New Roman, размер — 12 pt, отступы — 1,5.
Как считать эффективность модели?
Используйте RMSE, MAE, R². Добавьте метрику «relative error»: |predicted - actual| / actual. Если она > 20%, модель требует доработки. В отчёте обязательно покажите, как меняется ошибка при изменении experience rate.
Чек-лист: что проверить перед сдачей
- Ссылки на источники — все в формате автор (год) и ссылка.
- Соответствие задач выводам — каждая задача должна быть связана с конкретным результатом.
- Схемы и диаграммы — все имеют номер, название, соответствуют ГОСТ.
- Метрики — указаны формулы, приведены примеры расчётов, включены в таблицы.
- ГОСТ 34.19 — в приложении есть список стандартов, использованных в работе.
- Уникальность — проверено через Plagiarism Checker (например, Turnitin).
- Приложения — включают скриншоты, листинги, таблицы с данными.
Источник: Will fusion power get cheap? Don’t count on it. (опубликовано 2026-04-23)