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

Архітектури, спроектовані вручну, — результат досвіду та інтуїції, але їх перебір обмежений. Ми в TrueTech використовуємо автоматичний пошук архітектури нейронних мереж (NAS) — алгоритмічний пошук архітектурного простору з оптимізацією під конкретну задачу, датасет та 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 дозволяє заощадити до 40% витрат на розробку. Отримайте консультацію — оцінимо, які методи NAS спрацюють для вашої задачі.

AutoML: AutoGluon, FLAML, Vertex AI AutoML і коли це працює

Коли бізнес хоче швидко отримати модель, ми пропонуємо впровадження AutoML платформ. Це не кнопка «зроби мені AI», а автоматизація перебору гіперпараметрів і вибору алгоритму. Різниця критична: без якісних даних і правильної постановки задачі навіть найкраща платформа видасть сміття. Але для конкретних задач AutoML економить тижні ручних ітерацій.

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

Як AutoML може прискорити створення моделей?

Хороші кандидати для 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'].

Порівняння preset-конфігурацій AutoGluon

Як 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

Вартість навчання обчислюється погодинно за використання нод. Для 100k рядків і 50 ознак зазвичай 2–4 години навчання. Для високонавантажених задач 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 тижні залежно від складності. Типова економія бюджету клієнта — до 40% порівняно з ручною розробкою. Оцініть потенційну економію для вашого проєкту — зв'яжіться з нами.

Процес роботи та терміни

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.