Heterogeneous Graph Transformers: как семантика связей в графах переворачивает прогнозирование спроса

Классические модели спроса устарели. Они не видят контекст

Представьте, что вы прогнозируете продажи зонтов. Обычная модель видит: дождь → спрос растет. Графовая модель типа GraphSAGE видит: магазин А продает зонты, соседний магазин Б тоже продает зонты → можно учиться на их данных.

Но HGT видит больше. Магазин А продает зонты и резиновые сапоги. Магазин Б продает зонты и плащи. Покупатель в магазине А берет зонт, но не берет сапоги. Покупатель в магазине Б берет зонт и плащ. Это разные семантические связи: "комплементарный товар" и "альтернативный товар". HGT их различает. GraphSAGE — нет.

Разница в точности прогноза достигает 15-20%. В логистике это миллионы рублей экономии на складах.

GraphSAGE vs HGT: в чем принципиальная разница?

GraphSAGE учится на однородных графах. Все узлы — одинаковые сущности (например, только магазины). Все ребра — одинаковые связи (например, "находится рядом").

Реальный мир не такой. В supply-chain есть:

• Узлы разных типов: SKU (товар), магазин, склад, поставщик, категория товара
• Ребра разных типов: "продается в", "поставляется со склада", "входит в категорию", "является заменой для"

HGT (Heterogeneous Graph Transformer) создан для этого. У него:

1. Типизированное внимание — механизм внимания учитывает типы узлов и ребер
2. Мета-пути — можно задать семантические шаблоны типа "товар → категория → товар" (похожие товары)
3. Временные срезы — граф эволюционирует во времени (новые связи, изменяющиеся веса)

Да, HGT медленнее. Но точность важнее. Особенно когда речь идет о прогнозах для 10 000+ SKU.

Архитектура данных: как построить гетерогенный граф из ваших CSV

Допустим, у вас есть:

1. Таблица продаж (sku_id, store_id, date, quantity)
2. Таблица товаров (sku_id, category_id, supplier_id, price)
3. Таблица магазинов (store_id, region, size)
4. Таблица замен (sku_id, substitute_sku_id) — ручные правила ассортиментщиков

1 Определяем типы узлов и ребер

Узлы (node types):

node_types = {
    'sku': 0,      # товар
    'store': 1,    # магазин
    'category': 2, # категория
    'supplier': 3  # поставщик
}

Ребра (edge types):

edge_types = {
    ('sku', 'sold_in', 'store'): 0,      # товар продается в магазине
    ('store', 'sells', 'sku'): 1,        # магазин продает товар
    ('sku', 'belongs_to', 'category'): 2, # товар в категории
    ('category', 'contains', 'sku'): 3,   # категория содержит товар
    ('sku', 'supplied_by', 'supplier'): 4, # товар поставляется поставщиком
    ('supplier', 'supplies', 'sku'): 5,   # поставщик поставляет товар
    ('sku', 'substitutes', 'sku'): 6      # товар заменяет другой товар
}

2 Строим временные срезы графа

Граф меняется ежедневно. Новые товары, изменения цен, сезонность. Делаем снимки графа на каждую неделю:

import torch
from torch_geometric.data import HeteroData
import pandas as pd

# Для каждой недели создаем свой граф
graphs = {}
for week in range(num_weeks):
    data = HeteroData()
    
    # Узлы товаров с признаками
    sku_features = torch.tensor(sku_df[['price', 'weight', 'volume']].values, dtype=torch.float)
    data['sku'].x = sku_features
    data['sku'].node_id = torch.arange(len(sku_df))
    
    # Узлы магазинов
    store_features = torch.tensor(store_df[['size', 'region_code']].values, dtype=torch.float)
    data['store'].x = store_features
    
    # Ребра продаж с весами (количество продаж за неделю)
    week_sales = sales_df[sales_df['week'] == week]
    edge_index_sku_to_store = torch.tensor([
        week_sales['sku_idx'].values,
        week_sales['store_idx'].values
    ], dtype=torch.long)
    edge_attr_sales = torch.tensor(week_sales['quantity'].values, dtype=torch.float).view(-1, 1)
    
    data['sku', 'sold_in', 'store'].edge_index = edge_index_sku_to_store
    data['sku', 'sold_in', 'store'].edge_attr = edge_attr_sales
    
    # Ребра замен товаров (статические)
    data['sku', 'substitutes', 'sku'].edge_index = substitute_edges
    
    graphs[week] = data

Реализация HGT на PyTorch Geometric 2.5.0

PyG обновил API для гетерогенных графов. Старые туториалы 2023 года уже не работают. Вот актуальный код на 2026:

import torch
import torch.nn.functional as F
from torch_geometric.nn import HGTConv, Linear
from torch_geometric.data import HeteroData

class DemandHGT(torch.nn.Module):
    def __init__(
        self,
        hidden_channels: int = 128,
        num_heads: int = 8,
        num_layers: int = 3,
        metadata: tuple = None,
        node_types: list = None
    ):
        super().__init__()
        
        self.node_types = node_types
        self.lin_dict = torch.nn.ModuleDict()
        
        # Проекция признаков для каждого типа узлов в общее пространство
        for node_type in node_types:
            self.lin_dict[node_type] = Linear(-1, hidden_channels)
        
        # Стек HGT слоев
        self.convs = torch.nn.ModuleList()
        for _ in range(num_layers):
            conv = HGTConv(
                hidden_channels, hidden_channels, metadata,
                num_heads, group='sum'
            )
            self.convs.append(conv)
        
        # Прогнозирующий слой для товаров (прогноз спроса на 7 дней вперед)
        self.demand_predictor = torch.nn.Sequential(
            Linear(hidden_channels, hidden_channels // 2),
            torch.nn.ReLU(),
            Linear(hidden_channels // 2, 7)  # 7 дней прогноза
        )
    
    def forward(self, x_dict, edge_index_dict, edge_attr_dict=None):
        # Проекция признаков
        x_dict = {
            node_type: self.lin_dict[node_type](x)
            for node_type, x in x_dict.items()
        }
        
        # Проход через HGT слои
        for conv in self.convs:
            x_dict = conv(x_dict, edge_index_dict, edge_attr_dict)
        
        # Берем эмбеддинги только товаров для прогноза
        sku_embeddings = x_dict['sku']
        
        # Прогноз спроса
        demand_pred = self.demand_predictor(sku_embeddings)
        
        return demand_pred, x_dict

Обучение с временными срезами: как не забыть прошлое

Самая сложная часть — обучение на последовательности графов. Просто склеить все недели в один большой граф нельзя: теряется временная динамика.

Правильный подход — рекуррентная обработка:

class TemporalHGT(torch.nn.Module):
    def __init__(self, hgt_model, hidden_size):
        super().__init__()
        self.hgt = hgt_model
        self.gru = torch.nn.GRU(hidden_size, hidden_size, batch_first=True)
        
    def forward(self, graph_sequence):
        """
        graph_sequence: список HeteroData объектов за последовательные недели
        """
        batch_embeddings = []
        
        # Получаем эмбеддинги для каждого временного среза
        for graph in graph_sequence:
            _, embeddings = self.hgt(
                graph.x_dict,
                graph.edge_index_dict,
                graph.edge_attr_dict
            )
            # Берем эмбеддинги товаров
            sku_embeds = embeddings['sku']
            batch_embeddings.append(sku_embeds)
        
        # (sequence_length, batch_size, hidden_size) -> (batch_size, sequence_length, hidden_size)
        embeddings_seq = torch.stack(batch_embeddings).transpose(0, 1)
        
        # Обрабатываем временную последовательность через GRU
        gru_out, _ = self.gru(embeddings_seq)
        
        # Берем последний скрытый state для прогноза
        last_hidden = gru_out[:, -1, :]
        
        # Прогноз на следующую неделю (7 дней)
        forecast = self.hgt.demand_predictor(last_hidden)
        
        return forecast

Почему HGT обходит GraphSAGE в реальных задачах

Вернемся к примеру с зонтами и плащами. GraphSAGE видит граф:

• Узел "зонт" связан с узлом "магазин А"
• Узел "зонт" связан с узлом "магазин Б"
• Узел "плащ" связан с узлом "магазин Б"

HGT видит:

• "зонт" → (sold_in) → "магазин А" с весом 50 продаж
• "зонт" → (sold_in) → "магазин Б" с весом 30 продаж
• "плащ" → (sold_in) → "магазин Б" с весом 20 продаж
• "зонт" → (substitutes) → "плащ" (в дождливую погоду)
• "зонт" → (belongs_to) → "категория: дождевики"
• "плащ" → (belongs_to) → "категория: дождевики"

Когда в прогнозе наступает дождливая неделя, HGT:

1. Усиливает внимание на ребрах типа "substitutes" между зонтами и плащами
2. Учитывает, что в магазине Б продажи зонтов и плащей коррелируют
3. Через мета-путь "зонт → категория → плащ" находит все товары из той же категории

GraphSAGE просто усреднит эмбеддинги соседей. Без семантики. Без понимания, что "магазин Б продает плащи" важнее для прогноза зонтов в дождь, чем "магазин А не продает плащи".

Типичные ошибки при внедрении HGT

Интерпретируемость: что именно модель выучила?

Черный ящик из 3 миллионов параметров бесполезен для бизнеса. Нужно понимать, на какие связи модель смотрит.

В HGT есть встроенная интерпретируемость — матрицы внимания. Для каждой пары (узел, сосед) можно посмотреть score внимания:

# Получаем матрицы внимания из последнего слоя HGT
with torch.no_grad():
    _, attention_dict = model.hgt.convs[-1].get_attention_scores(
        x_dict, edge_index_dict
    )

# Для товара sku_id=42 смотрим, на какие магазины он "обращает внимание"
sku_id = 42
store_attention = attention_dict[('sku', 'sold_in', 'store')]
# Матрица размера (num_heads, num_edges)

# Находим ребра, где источник — наш товар
edge_mask = edge_index_dict[('sku', 'sold_in', 'store')][0] == sku_id
relevant_attention = store_attention[:, edge_mask]

# Усредняем по головам внимания
avg_attention = relevant_attention.mean(dim=0)
print(f"Товар {sku_id} больше всего внимания уделяет магазинам:")
for i, attn_score in enumerate(avg_attention.topk(5).indices):
    store_idx = edge_index_dict[('sku', 'sold_in', 'store')][1, edge_mask][attn_score]
    print(f"  Магазин {store_idx.item()}: внимание {avg_attention[attn_score].item():.3f}")

Оказывается, модель учится смотреть не на ближайшие магазины, а на магазины с похожим профилем покупателей. Даже если они в другом городе.

Производительность: как ускорить обучение в 3 раза

HGT жрет память. Каждый тип связи — своя матрица внимания. Для 10 типов ребер и 8 голов внимания — уже 80 матриц.

Трюки для production:

1. Кластеризация узлов — обучаем отдельные HGT для разных категорий товаров (бытовая химия, электроника, продукты)
2. Сэмплирование соседей — берем не всех соседей, а топ-20 по весу связи
3. Mixed Precision — fp16 ускоряет обучение на современных GPU на 40-60%
4. Градиентный checkpointing — жертвуем временем вычислений ради памяти

# Пример с mixed precision и gradient checkpointing
from torch.cuda.amp import autocast, GradScaler
scaler = GradScaler()

for epoch in range(num_epochs):
    optimizer.zero_grad()
    
    # Mixed precision forward
    with autocast():
        predictions, _ = model(data)
        loss = loss_fn(predictions, targets)
    
    # Backward с scaling градиентов
    scaler.scale(loss).backward()
    scaler.step(optimizer)
    scaler.update()
    
    # Gradient checkpointing для HGT слоев
    # В PyG 2.5.0 есть встроенная поддержка
    model.hgt.convs = torch.nn.ModuleList(
        torch.utils.checkpoint.checkpoint(conv) 
        for conv in model.hgt.convs
    )

С чем комбинировать HGT для максимальной точности?

Чистый HGT — хорошо. HGT + дополнительные сигналы — лучше.

Рекомендую pipeline:

1. HGT — улавливает структурные зависимости между товарами, магазинами, категориями
2. Временной ряд по каждому SKU — классические методы (Prophet, ARIMA) или нейросетевые (LSTM, Transformer). Я использую библиотеку Etna — в статье "Прогнозирование 200+ временных рядов с библиотекой Etna" есть готовый пайплайн
3. Внешние факторы — погода, праздники, экономические индикаторы. Но будьте осторожны с Google Trends — часто требуется серьезная нормализация, о чем я писал в "Google Trends лжет: как нормализация данных убивает ваши ML-модели"

Финальный прогноз — взвешенная сумма трех моделей. Веса подбираем на валидации.

Что дальше? Будущее гетерогенных графов

На 2026 год тренды такие:

• HGT + Large Language Models — описание товаров (текст) эмбеддим через модель типа GPT-5 или ее open-source аналоги, добавляем как node features
• Динамическое изменение архитектуры — модель сама решает, какие типы связей важны в данный момент, а какие можно игнорировать
• Федеративное обучение — обучаем одну HGT на данных нескольких ритейлеров без обмена сырыми данными
• Квантование — 8-битные веса для инференса на edge-устройствах (в магазинах)

Самый перспективный вектор — сочетание графовых моделей с retrieval-подходом. Вместо того чтобы учиться на всем графе, модель ищет похожие паттерны в истории. Об этом я подробно писал в "Retrieval для временных рядов: как поиск похожих паттернов улучшает прогнозы".

Попробуйте начать с простого: возьмите 100 товаров, постройте граф с 3 типами узлов (товар, магазин, категория) и 4 типами ребер. Сравните GraphSAGE и HGT. Разница будет заметна сразу.

А когда масштабируетесь до тысяч SKU — арендуйте GPU с умом. Цены сильно прыгают. Я писал трекер цен на облачные GPU, который помогает не переплачивать.

Главное — не бойтесь сложности. HGT требует больше кода, чем линейная регрессия. Но и результат другой. В supply-chain, где 1% точности — это тысячи сэкономленных палетомест на складе, игра определенно стоит свеч.