Neural Architecture Search (NAS) для оптимальных нейросетей

Вручную спроектированные архитектуры — результат опыта и интуиции, но их перебор ограничен. Мы в TrueTech используем NAS (Neural Architecture Search) — алгоритмический поиск архитектурного пространства с оптимизацией под конкретную задачу, датасет и hardware target. Это не замена архитектурному мышлению, а способ найти конфигурации, до которых человек не дойдёт за разумное время. Используем методы DARTS, Once-for-All и predictor-based подхода — каждый для своих условий. Хотите проверить, принесёт ли NAS пользу вашему проекту? Свяжитесь — сделаем предварительную оценку за пару дней.

Почему наивный NAS убивает GPU-бюджет

Классический NAS в ранних реализациях (например, NASNet от Google) требовал до 500 GPU-дней на A100-эквиваленте. Каждая кандидатная архитектура обучалась с нуля до сходимости. При пространстве поиска в 10^10 конфигураций полный перебор невозможен. Современные подходы решают это через три принципиально разные идеи:

• One-shot NAS / Weight Sharing. Суперсеть включает все возможные подграфы, каждый кандидат — «путь» через неё с уже обученными весами. DARTS, SNAS, Single-Path NAS — время поиска падает с сотен GPU-дней до 1-4 дней (ускорение в 100 раз).
• Predictor-based NAS. Суррогатная модель предсказывает accuracy без полного обучения. 100-200 реальных оценок → предиктор для следующих миллионов кандидатов.
• Hardware-aware NAS. Оптимизация по accuracy и latency на конкретном устройстве. MNasNet, FBNet, Once-for-All строят Pareto-фронт (accuracy vs latency). Критично для edge deployment.

Как DARTS решает проблему скорости?

DARTS (Differentiable Architecture Search) — один из самых используемых one-shot методов. Вместо дискретного выбора операции (3×3 conv vs 5×5 conv vs skip) используются непрерывные веса α, оптимизируемые через gradient descent. Подробное описание — в оригинальной статье Liu et al., DARTS: Differentiable Architecture Search, arXiv:1806.09055.

import torch
import torch.nn as nn
from torch.nn import functional as F

class MixedOp(nn.Module):
    def __init__(self, C: int, stride: int):
        super().__init__()
        self._ops = nn.ModuleList()
        for primitive in PRIMITIVES:
            op = OPS[primitive](C, stride, affine=False)
            self._ops.append(op)

    def forward(self, x: torch.Tensor, weights: torch.Tensor) -> torch.Tensor:
        return sum(w * op(x) for w, op in zip(weights, self._ops))

class DARTSCell(nn.Module):
    def __init__(self, steps, multiplier, C_prev_prev, C_prev, C, reduction, reduction_prev):
        super().__init__()
        self._steps = steps
        self._multiplier = multiplier

    def forward(self, s0, s1, weights):
        states = [s0, s1]
        offset = 0
        for i in range(self._steps):
            s = sum(self._ops[offset + j](h, weights[offset + j]) for j, h in enumerate(states))
            offset += len(states)
            states.append(s)
        return torch.cat(states[-self._multiplier:], dim=1)

def train_darts_step(model, architect, optimizer_w, optimizer_alpha, train_queue, valid_queue, lr_w):
    for step, (input_train, target_train) in enumerate(train_queue):
        input_valid, target_valid = next(iter(valid_queue))
        architect.step(input_train, target_train, input_valid, target_valid, lr=lr_w, optimizer=optimizer_w, unrolled=False)
        optimizer_w.zero_grad()
        logits = model(input_train)
        loss = F.cross_entropy(logits, target_train)
        loss.backward()
        nn.utils.clip_grad_norm_(model.parameters(), max_norm=5.0)
        optimizer_w.step()

Главная инженерная сложность — двухуровневая оптимизация: веса сети w и архитектурные веса α чередуются. Однако в чистом DARTS возникает коллапс операций: skip-connection «побеждают» из-за нулевых параметров. Решения — DARTS+ (отсечение skip), P-DARTS (прогрессивная глубина), GDAS (Gumbel-softmax).

Что даёт hardware-aware NAS на практике?

Once-for-All (MIT) — суперсеть, из которой без дообучения извлекаются подсети под любой hardware constraint:

from ofa.model_zoo import ofa_net
o fa_network = ofa_net('ofa_mbv3_d234_e346_k357_w1.0', pretrained=True)
from ofa.nas.efficiency_predictor import Latency_MBV3_MeasuredNet
efficiency_predictor = Latency_MBV3_MeasuredNet('note10', ofa_network)
from ofa.nas.search_algorithm.evolution_finder import EvolutionFinder
finder = EvolutionFinder(efficiency_constraint=25, efficiency_predictor=efficiency_predictor, accuracy_predictor=accuracy_predictor, population_size=100, max_time_budget=500)
best_valids, best_info = finder.run_evolution_search()

В реальном проекте: NAS под MobileNetV3-space для классификации производственного брака (640×480, 12 классов) на NVIDIA Jetson Nano. Ручная MobileNetV3-Large: 28.4ms, accuracy 91.3%. OFA-поиск за 6 часов: 22.1ms, accuracy 92.7% — без единого ручного изменения. При этом DARTS быстрее эволюционного поиска в 100 раз, но даёт менее точные предсказания latency на нестандартном железе.

Что входит в работу над NAS?

Когда NAS оправдан?

NAS не нужен для стандартных задач с данными < 50k примеров — возьмите предобученную ResNet-50. Он оправдан при:

• кастомных hardware-ограничениях (Jetson, Coral, ASIC),
• нетипичных входных данных (гиперспектр, лидары, медицинские снимки),
• необходимости кардинально уменьшить модель без потери качества.

Мы специализируемся на оптимизации нейросетей более 5 лет, реализовали 15+ проектов с автоматическим поиском архитектуры. Получите консультацию — оценим, какие методы NAS сработают для вашей задачи.

AutoML: AutoGluon, FLAML, Vertex AI AutoML и когда это работает

Когда бизнес хочет быстро получить модель, мы предлагаем внедрение AutoML платформ. Это не кнопка «сделай мне AI», а автоматизация перебора гиперпараметров и выбора алгоритма. Разница критическая: без качественных данных и правильной постановки задачи даже лучшая платформа выдаст мусор. Но для конкретных задач AutoML экономит недели ручных итераций.

AutoML автоматизирует выбор модели и настройку гиперпараметров. На структурированных табличных данных современные системы конкурируют с ручным ML-инжинирингом. Например, на kaggle-соревнованиях AutoGluon без какой-либо настройки попадает в топ-10% на многих датасетах. Причина: он строит ансамбль из LightGBM, XGBoost, CatBoost, нейросетей и RF со stacking — такой ансамбль часто превосходит одиночную лучшую модель на 5–10% по метрике.

Хорошие кандидаты для AutoML платформ:

• Стандартная бинарная/мультиклассовая классификация или регрессия на табличных данных
• Задачи без жёстких ограничений на latency (< 50 мс) или размер модели (< 10 MB)
• MVP или baseline перед ручной оптимизацией
• Команды без глубокой ML-экспертизы, которым нужен рабочий прототип за 1–2 недели

Плохие кандидаты: кастомный loss, специфические архитектуры, real-time inference с жёсткими ограничениями, domain-специфические задачи (медицинская визуализация, NLP на редком языке).

Почему AutoGluon — лучший выбор для табличных данных?

AutoGluon-Tabular — самый сильный AutoML для таблиц по большинству бенчмарков. Ключевая особенность — многоуровневый стекинг. Модели первого слоя (LightGBM, XGBoost, CatBoost, FastAI tabular, KNN) → их предсказания как фичи → модели второго слоя. Это настраивается через num_stack_levels=2.

from autogluon.tabular import TabularPredictor

predictor = TabularPredictor(
    label='target',
    eval_metric='roc_auc',
    path='./ag_models'
).fit(
    train_data,
    time_limit=3600,  # 1 час
    presets='best_quality',  # vs 'medium_quality', 'high_quality'
)

Preset best_quality включает стекинг и ансамбли, занимает максимум памяти и времени. medium_quality — баланс скорость/качество, подходит для >1M строк. optimize_for_deployment — убирает тяжёлые ансамбли, ускоряет inference.

Типичный подводный камень: AutoGluon обучает десятки моделей и сохраняет все на диск — от 2 до 10 GB на серьёзных задачах. При деплое выгружайте только финальную модель через predictor.clone_for_deployment(). С памятью тоже осторожно: при num_stack_levels=2 на 500k строк возможен OOM на машинах с <32 GB RAM. Решение: ag_args_fit={'num_cpus': 4, 'num_gpus': 0} и excluded_model_types=['NeuralNetFastAI'].

Как FLAML экономит ресурсы и время?

FLAML (Fast and Lightweight AutoML) от Microsoft ориентирован на минимальный бюджет вычислений при хорошем качестве. Использует cost-frugal search: сначала пробует дешёвые конфигурации, постепенно переходя к дорогим. Это даёт выигрыш по времени до 2 раз по сравнению с AutoGluon на одинаковом бюджете, хотя итоговое качество может быть на 3–5% ниже.

from flaml import AutoML
automl = AutoML()
automl.fit(X_train, y_train, task="classification", time_budget=120, metric="roc_auc")

Хорошо подходит для ограниченного вычислительного бюджета, задач с требованием time_budget < 60 сек, интеграции в CI/CD пайплайн. FLAML также поддерживает fine-tuning LLM через flaml.autogen — автоматический подбор промптов для GPT/Claude.

Когда выбирать Vertex AI AutoML?

Google Vertex AI AutoML — правильный managed сервис, когда:

• Нет своей ML-инфраструктуры
• Нужна интеграция с BigQuery, Cloud Storage, Dataflow
• Задача — Computer Vision или NLP (не только таблицы)
• Требуется managed inference endpoint без DevOps

Стоимость обучения табличной модели — $1.375/час за node. Для 100k строк и 50 признаков обычно 2–4 часа обучения. Inference: $0.05–0.10 за 1k предсказаний. Для высоконагруженных задач self-hosted AutoGluon выгоднее. Ограничения: меньше контроля над архитектурой, экспорт модели только в TF SavedModel или TFLite, без ONNX. Зато managed feature store, автоматический мониторинг дрейфа и MLOps из коробки.

Сравнение основных AutoML платформ

Что входит в работу по внедрению AutoML?

Мы предоставляем полный цикл: от быстрого бенчмарка до production-системы с мониторингом. В deliverables входят:

• EDA и подготовка данных (feature engineering, обработка пропусков, кодирование)
• Обучение и сравнение 3+ AutoML конфигураций с фиксацией метрик
• Выбор лучшей модели и её экспорт (ONNX, TF SavedModel, TorchScript)
• Развёртывание inference endpoint (Docker, Kubernetes, serverless)
• Документация model card и инструкция по переобучению
• Обучение вашей команды работе с платформой (2 часа)

Гарантируем: baseline за 5 рабочих дней, production-решение за 2–4 недели в зависимости от сложности.

Процесс работы и сроки

1. Аналитика (1–2 дня) — сбор требований, EDA, определение метрики качества.
2. Бенчмарк (2–3 дня) — запуск AutoGluon medium_quality, FLAML, Vertex AI. Фиксация baseline.
3. Оптимизация (3–5 дней) — feature engineering, ручная настройка гиперпараметров, стекинг.
4. Тест и валидация (2–3 дня) — оценка на отложенной выборке, проверка дрейфа, A/B тест.
5. Деплой (2–4 дня) — контейнеризация, CI/CD, метрики мониторинга.

Сроки: MVP — от 1 недели. Полноценная production-система с автопереобучением — от 3 недель.

Почему стоит доверить внедрение нам?

У нас за плечами 5 лет опыта и более 20 успешных проектов по внедрению AutoML платформ в ритейле, финтехе и логистике. Сертифицированные инженеры по AWS Machine Learning и Google Cloud Professional Data Engineer. Мы не просто запускаем код — мы обучаем вашу команду и гарантируем, что модель будет стабильно работать в production.

Получите консультацию по AutoML для вашей задачи — оставьте заявку. Или закажите бесплатный бенчмарк: мы проанализируем ваши данные и скажем, сколько времени и денег сэкономит AutoML.