Notes & Insights - mlops

Самообучающиеся торговые AI-агенты: иллюзии, оверфиттинг и реальная архитектура

2026-10-07T00:00:00+00:00

Концепция автономного торгового агента, который «сам торгует, анализирует свои ошибки и дообучает стратегию 24/7», сейчас на пике хайпа. В сети появляется множество видео и промптов, обещающих превратить Claude Code или LLM-агентов в машины по генерации сверхприбыли.

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

Анатомия хайпа: 47% в месяц и «научный метод»

Типичный сценарий, который продвигают в платном доступе:

One-shot prompt для Claude Code разворачивает стек на Railway / облаке.
Агент подключается к API биржи и ведет позиции.
Еженедельно агент анализирует ledger (историю сделок) и меняет веса стратегии.
Заявляются цели уровня 40–50% в месяц при минимальных просадках.

В чем фундаментальные проблемы такого подхода?

Статистическая незначимость: демонстрация «24 прибыльных / 22 убыточных сделки за 8 недель» — это околонулевая выборка. В алготрейдинге статистический edge проявляется на выборках от 500–1000+ сделок на разных рыночных режимах.
Иллюзия «одной переменной»: в классическом научном методе гипотезы тестируют, меняя один параметр. В реальной мульти-активной стратегии десятки гиперпараметров (stop-loss, take-profit, regime threshold, ATR multiplier) жестко скоррелированы. LLM, пытаясь подогнать один параметр под прошлую неделю, гарантированно переобучается на локальный шум (in-sample overfitting).
Слепое доверие переключению в Live: делегировать агенту право самостоятельно переключать флаг live: true без внешнего бэктеста и человека — прямой путь к ликвидации депозита.

Архитектура надежного контура

Если отбросить маркетинговую шелуху, сама идея разделения обязанностей между специализированными агентами вполне жизнеспособна. Но архитектура должна строиться по принципу изолированных контуров и жестких шлюзов (Approval Gates):

flowchart TD
    subgraph Orch ["🎛️ 1. Orchestrator (Hermes Agent)"]
        direction TB
        O1["Управление инфраструктурой (deploy, cron, health)"]
        O2["Сбор телеметрии и Append-Only Ledger"]
        O1 --- O2
    end

    subgraph Exec ["⚡ 2. Strategy Engine (Исполнение)"]
        direction TB
        E1["Детерминированный движок (Rust / Python / Freqtrade)"]
        E2["Строгий Risk Management (Max Drawdown, Sizing)"]
        E1 --- E2
    end

    subgraph Tuner ["📊 3. Out-of-Sample Tuner (Аналитик)"]
        direction TB
        T1["Бэктесты на независимой OOS-выборке со сдвигом"]
        T2["Отчет с гипотезами и метриками (Sharpe, Profit Factor)"]
        T1 --- T2
    end

    subgraph Gate ["🛡️ 4. Human Approval Gate"]
        direction TB
        G1["Ручной аудит гипотезы разработчиком"]
        G2["Применение флага live: true"]
        G1 ==> G2
    end

    Orch --> Exec
    Orch --> Tuner
    Tuner ==>|Предложение оптимизации| Gate
    Gate ==>|Апрув параметров| Exec

4 ключевых принципа для продакшна

1. Детерминированное исполнение отдельно от LLM

LLM не должна принимать решения по каждой свече на миллисекундах. Роль AI-агента — мета-оптимизация и аналитика: генерация идей, фильтрация аномалий, валидация гипотез. Исполнение ордеров и контроль рисков должны выполняться жестким детерминированным кодом.

2. Append-Only Ledger как единственный источник правды

Все события, котировки, сигналы и фактические исполнения логируются в неизменяемый JSONL-лог. Агент не может переписать историю — только прочитать ее.

3. Out-of-Sample валидация со сдвигом по времени

Тюнер стратегий никогда не должен оптимизировать параметры на тех же данных, где искались сигналы. Использование временного сдвига (например, 3–7 дневный лаг) защищает от оптимизации под случайные всплески волатильности.

4. Human-in-the-loop (Ручной шлюз)

Любые изменения в strategy.yaml или параметрах риск-менеджмента требуют явного подтверждения человеком. Переход paper → live выполняется только после прохождения OOS-гейта.

Первоисточники и материалы

Оригинальное видео: 01 Systems (Wacko Alpha) — Self-Improving Trading Agent on YouTube
Заметки и детальный конспект: Obsidian Vault: Self-Improving Trading Agent (GitHub)
Инженерные наработки и репозитории: github.com/xsa-dev

Как обучать и оценивать AI-агентов: почему Pass@1 бесполезен и как работает связка SFT + GKD + GRPO

2026-10-07T00:00:00+00:00

Большинство метрик, по которым сегодня сравнивают языковые модели (вроде Pass@1 на HumanEval или статичных QA-тестах), практически бесполезны, когда дело доходит до автономных агентов в продакшне.

В отличие от классического чат-бота (prompt → response), агент — это динамическая система: модель + обвязка (harness) + инструменты + память + мутабельное окружение + логика восстановления после ошибок.

Разберем, из чего складывается реальная надежность агентов и как устроен современный трехуровневый пайплайн их обучения: SFT → On-Policy Distillation (GKD) → RLVR (GRPO).

4 измерения надежности агента (вместо Pass@1)

Когда агент выполняет транзакционные действия (запись в БД, пуш в репозиторий, исполнение ордеров), статичный процент правильных ответов ничего не говорит о безопасности. В продакшне критичны 4 других фактора:

flowchart TD
    Core["🛡️ 4 измерения надежности агента"]

    C1["🎯 1. Consistency<br/>(Повторяемость результата)"]
    C2["⚡ 2. Robustness<br/>(Устойчивость к шуму API)"]
    C3["🔄 3. Recoverability<br/>(Откат после 5xx и tool errors)"]
    C4["⛔ 4. Failure Severity<br/>(Штраф за деструктивные действия)"]

    Core --> C1
    Core --> C2
    Core --> C3
    Core --> C4

Consistency (Повторяемость): одна и та же задача при повторных прогонах должна давать стабильный результат с контролируемой дисперсией по токенам и времени.
Robustness (Устойчивость к шуму): мелкие изменения в формулировке, смена формата вывода CLI или незначительный шум в API не должны ломать логику рассуждений.
Recoverability (Восстановление): способность агента понять, что инструмент вернул ошибку (404, SyntaxError, пустой вывод), скорректировать гипотезу и продолжить, а не падать в бесконечный цикл.
Failure Severity (Тяжесть сбоя): синтаксическая ошибка tool call должна штрафоваться минимально, а необратимое действие (удаление таблицы или рассинхрон стейта) — приводить к жесткому блокирующему штрафу.

Трехуровневый пайплайн обучения

Обучать агентов только с помощью SFT или только через RL неэффективно. Оптимальный стек пост-тренинга строится в три этапа:

flowchart TD
    S1["1. SFT (Supervised Fine-Tuning)<br/>Приучает к синтаксису tool_call и Loss Masking"]
    S2["2. Distillation (On-Policy GKD)<br/>Перенос навыков учителя + выход из тупиков"]
    S3["3. RLVR (GRPO / Verifiable Rewards)<br/>Максимизация надежности через проверяемые награды"]

    S1 ==>|Формат освоен| S2
    S2 ==>|Траектории исследованы| S3

Этап 1. SFT (Supervised Fine-Tuning)

Цель: научить модель синтаксису вызова инструментов (tool_calls), структуре системных инструкций и multi-turn диалогу.
Критический нюанс — Loss Masking: градиентный спуск должен рассчитываться только на токенах генерации агента (thought + action). Обучать модель предсказывать вывод терминала, ответ пользователя или результат исполнения инструмента — грубая ошибка. Токены окружения маскируются значением -100.
Потолок SFT: модель становится идеальным имитатором обучающего датасета, но не умеет исследовать новые пути или исправлять свои ошибки.

Этап 2. On-Policy Distillation (GKD / Generalized Knowledge Distillation)

Классическая дистилляция (Off-Policy) подает студенту идеальные траектории учителя-гиганта. В реальности маленькая модель неизбежно ошибается, попадает в незнакомое состояние и «галлюцинирует» (exposure bias).

Решение — On-Policy GKD: студент сам генерирует траекторию, а модель-учитель оценивает логиты именно в тех промежуточных состояниях, куда студент реально зашел.
Использование Reverse KL заставляет студента фокусироваться на главных модах распределения учителя и учит выходить из тупиков.

Этап 3. RLVR и GRPO (Reinforcement Learning with Verifiable Rewards)

Когда формат закреплен, в дело вступает обучение с подкреплением по проверяемому результату. GRPO (Group Relative Policy Optimization) убирает необходимость в отдельной тяжелой модели-критике (Critic Network):

На один входной промпт генерируется группа из $G$ вариантов ($G = 8..16$).
Каждый вариант прогоняется через детерминированный верификатор (тесты, компилятор, линтер).
Награда нормализуется внутри группы: $A_i = \frac{r_i - \text{mean}(R)}{\text{std}(R)}$.

# Концептуальная схема многокомпонентной награды
def calculate_agent_reward(trajectory, test_result):
    return (
        0.2 * format_reward(trajectory)       # Валидный JSON / tool schema
        + 0.6 * execution_reward(test_result) # Unit-тесты пройдены
        + 0.2 * efficiency_reward(trajectory) # Минимальное число шагов
    )

Правило дисперсии: GRPO работает только при наличии вариативности наград. Если все 8 вариантов провалились или все 8 выполнились успешно — обучающий сигнал равен нулю. Задача тренера — подбирать задачи на «границе возможностей» модели.

Главный анти-паттерн: Reward Hacking

Если верификатор наград слаб (например, оценивает только наличие ключевого слова в выводе), RL-агент моментально найдет шорткат: научится вызывать заглушку exit(0) или обходить тесты.

Грейдер должен быть физически изолирован от среды агента (отдельный контейнер / процесс), а валидация обязана проверять фактический граф мутаций файловой системы и БД.

Ключевые выводы

Агент = Модель + Среда: оценивайте не LLM в изоляции, а всю замкнутую систему действий.
SFT дает форму, GKD учит исправлять ошибки, RL находит оптимум.
Трейсы продакшна — топливо для тестов: каждая непредвиденная ошибка агента в бою должна автоматически превращаться в изолированный тест для пост-тренинга.

Первоисточники и материалы

Оригинальная серия воркшопов: Hugging Face — Training and Evaluating AI Agents (YouTube Playlist)
Детальный структурированный конспект: Obsidian Vault: Training & Evaluating AI Agents (GitHub)
Репозитории и код: github.com/xsa-dev