Notes & Insights

Автоматическая миграция C/C++ на Rust: 3-этапный пайплайн Google, Gemini 4 Argon и дифференциальный фаззинг

Alexei Savin — Thu, 08 Oct 2026 00:00:00 +0000

Проблема безопасности памяти (Memory Safety) в системном программировании давно перешла из теоретических дискуссий в категорию критических инфраструктурных рисков. По данным многолетних отчетов безопасности Google и Microsoft, около 70% всех критических уязвимостей нулевого дня (Zero-Day CVE) в масштабных кодовых базах на C и C++ (таких как Chromium, ядра ОС, медиадекодеры и сетевые стеки) вызваны ошибками работы с памятью: Use-After-Free, Out-of-Bounds Write, Double Free и Data Races.

Переписывание сотен миллионов строк унаследованного C/C++ кода вручную силами инженеров требует десятилетий и сопряжено с колоссальными затратами. Инженерные команды Google перешли к индустриальному решению задачи: автоматизированному конвейеру миграции на базе специализированных AI-агентов (Gemini 4 Argon), строгой верификации через дифференциальный фаззинг и компиляторной оптимизации.

В этой статье разобран 3-этапный пайплайн миграции Google, физика работы дифференциального фаззинга, специфика генерации безопасных FFI-границ и реальные результаты переноса критических проектов (giflib, libgav1 и микроядра Zircon).

1. Архитектура 3-этапного конвейера миграции

Главный барьер при автоматической генерации системного кода нейросетями — риск внесения скрытых семантических расхождений и тонких регрессий, которые не ловятся обычными юнит-тестами.

Чтобы исключить галлюцинации и гарантировать 100% эквивалентность логики, в Google реализовали замкнутый контур с автоматической обратной связью:

flowchart TD
    A["Legacy C/C++ Codebase"] --> B["1. Трансляция кода - Gemini 4 Argon"]
    B --> C["2. Выделение FFI и Safe Wrappers"]
    C --> D["Сборка Shared Objects - lib_legacy.so vs lib_rust.so"]
    D --> E["3. Дифференциальный фаззинг - LibAFL / AFL++"]
    E --> F{"Обнаружены дельты в поведении?"}
    F -->|Да: расхождение вывода или краш| G["Генерация контрпримера и отчета"]
    G --> B
    F -->|Нет: миллиарды итераций пройдены| H["Верифицированный Rust Crate"]
    H --> I["Интеграция в Production"]

Этап 1: Семантическая трансляция C/C++ в Rust

Модель не просто переводит синтаксис строчка в строчку. Ее задача — выделить логические структуры данных, определить границы владения объектами и транслировать императивный процедурный код в идиоматический Rust с минимально необходимым объемом unsafe-блоков. При этом сохраняется полная совместимость с внешним C-ABI: экспортируемые сигнатуры функций и структуры данных сохраняют исходный layout.

Этап 2: Изоляция FFI и генерация Safe Wrappers

Любой переносимый модуль должен бесшовно встраиваться в существующую экосистему без необходимости перекомпиляции зависимых сервисов. На границе FFI генерируется безопасный фасад:

Сырые указатели (*mut T, *const T) оборачиваются в Option<NonNull<T>>.
Проверяются инварианты выравнивания и валидности переданных буферов.
Жизненный цикл ресурсов инкапсулируется через типаж Drop (RAII), исключая утечки памяти.

Этап 3: Дифференциальный фаззинг с обратной связью

Оригинальная C-библиотека и сгенерированная Rust-библиотека компилируются как взаимозаменяемые динамические библиотеки (.so). Специализированный фаззер генерирует миллионы мутированных входных потоков байтов, подавая их параллельно в обе реализации. Если поведение Rust-модуля расходится с C хотя бы на 1 бит (или одна из версий завершается паникой/крашем), формируется минимизированный контрпример, который отправляется в контекст AI-агента для локализации бага.

2. Сравнение подходов: Ручная миграция vs AI-фаззинг контур

Ниже приведено структурное сравнение ключевых характеристик различных подходов к обеспечению memory safety в production:

Параметр	Ручной перенос на Rust	Статический анализ C/C++	Конвейер Google (AI + Фаззинг)
Скорость миграции	100–300 строк/день на инженера	Мгновенно (без миграции)	10 000+ строк/день на агентный кластер
Гарантии Memory Safety	Высокие (после ревью)	Низкие (много false negatives)	Абсолютные на уровне `rustc`
Семантическая точность	Человеческий фактор	Не применимо	Проверена миллиардами фаззинг-мутаций
Сохранение C-ABI	Трудоемко вручную	Сохраняется C-код	Автоматическая генерация `#[no_mangle]`
Устранение Legacy 0-day	Редко	Частично	Выявляются попутно в процессе фаззинга

3. Инженерия безопасных FFI-границ и управление ресурсами

Рассмотрим конкретный пример: трансляция низкоуровневого буфера данных с ручным управлением памятью в C в безопасную абстракцию на Rust с сохранением ABI.

Исходный C-код (Legacy-интерфейс с рисками UAF)

#include <stdlib.h>
#include <stdint.h>
#include <string.h>

typedef struct {
    uint8_t* data;
    size_t size;
    size_t capacity;
} ByteBuffer;

ByteBuffer* byte_buffer_create(size_t initial_capacity) {
    ByteBuffer* buf = (ByteBuffer*)malloc(sizeof(ByteBuffer));
    if (!buf) return NULL;
    buf->data = (uint8_t*)malloc(initial_capacity);
    if (!buf->data) {
        free(buf);
        return NULL;
    }
    buf->size = 0;
    buf->capacity = initial_capacity;
    return buf;
}

int byte_buffer_append(ByteBuffer* buf, const uint8_t* src, size_t len) {
    if (!buf || !src) return -1;
    if (buf->size + len > buf->capacity) {
        size_t new_cap = (buf->capacity * 2 > buf->size + len) ? buf->capacity * 2 : buf->size + len;
        uint8_t* new_data = (uint8_t*)realloc(buf->data, new_cap);
        if (!new_data) return -1;
        buf->data = new_data;
        buf->capacity = new_cap;
    }
    memcpy(buf->data + buf->size, src, len);
    buf->size += len;
    return 0;
}

void byte_buffer_free(ByteBuffer* buf) {
    if (buf) {
        if (buf->data) free(buf->data);
        free(buf);
    }
}

Сгенерированный Rust-модуль с безопасной инкапсуляцией и C-ABI

use std::ptr::NonNull;
use std::slice;

#[repr(C)]
pub struct ByteBufferFFI {
    data: *mut u8,
    size: usize,
    capacity: usize,
}

// Внутренняя безопасная структура с авто-освобождением через RAII
pub struct SafeByteBuffer {
    inner: Vec<u8>,
}

impl SafeByteBuffer {
    pub fn with_capacity(cap: usize) -> Self {
        Self {
            inner: Vec::with_capacity(cap),
        }
    }

    pub fn append(&mut self, src: &[u8]) -> Result<(), ()> {
        self.inner.extend_from_slice(src);
        Ok(())
    }
}

#[no_mangle]
pub unsafe extern "C" fn byte_buffer_create(initial_capacity: usize) -> *mut ByteBufferFFI {
    let mut vec = Vec::with_capacity(initial_capacity);
    let raw_ptr = vec.as_mut_ptr();
    let cap = vec.capacity();
    std::mem::forget(vec);

    let boxed = Box::new(ByteBufferFFI {
        data: raw_ptr,
        size: 0,
        capacity: cap,
    });
    Box::into_raw(boxed)
}

#[no_mangle]
pub unsafe extern "C" fn byte_buffer_append(
    buf: *mut ByteBufferFFI,
    src: *const u8,
    len: usize,
) -> i32 {
    if buf.is_null() || src.is_null() {
        return -1;
    }

    let buf_ref = &mut *buf;
    let input_slice = slice::from_raw_parts(src, len);

    // Восстанавливаем Vec для безопасного реаллоцирования
    let mut vec = Vec::from_raw_parts(buf_ref.data, buf_ref.size, buf_ref.capacity);
    vec.extend_from_slice(input_slice);

    // Обновляем FFI-структуру
    buf_ref.data = vec.as_mut_ptr();
    buf_ref.size = vec.len();
    buf_ref.capacity = vec.capacity();
    std::mem::forget(vec);

    0
}

#[no_mangle]
pub unsafe extern "C" fn byte_buffer_free(buf: *mut ByteBufferFFI) {
    if !buf.is_null() {
        let boxed = Box::from_raw(buf);
        if !boxed.data.is_null() {
            let _ = Vec::from_raw_parts(boxed.data, boxed.size, boxed.capacity);
        }
    }
}

Благодаря #[repr(C)] и #[no_mangle] скомпилированная Rust-библиотека подменяет оригинальный .so файл без перекомпиляции зависимых C/C++ приложений.

4. Математическая модель дифференциального фаззинга

При дифференциальном фаззинге проверяется гипотеза о тождественности функций $f_{\text{C}}(x)$ и $f_{\text{Rust}}(x)$ на всем пространстве допустимых и недопустимых входных данных $x \in \mathcal{X}$.

Пусть в кодовой базе существует скрытый дефект с вероятностью проявления $p_k$ на одной итерации случайной мутации входного вектора. При независимой генерации $N$ тест-кейсов вероятность обнаружения расхождения $P_{\text{detect}}$ выражается как:

$$P_{\text{detect}}(N) = 1 - \prod_{k=1}^{M} \left(1 - p_k\right)^{N_k}$$

Где:

$M$ — число потенциальных пограничных состояний в графе потока управления (CFG);
$N_k$ — количество сгенерированных мутаций, покрывающих ветвь $k$;
$p_k$ — вероятность расхождения семантики при исполнении ветви $k$.

В конвейере Google фаззер использует покрытие кода (Coverage-Guided Differential Fuzzing). Когда мутатор находит вход $x^*$, приводящий к:

$$\Delta(x^) = \left| f_{\text{C}}(x^) - f_{\text{Rust}}(x^) \right| > 0 \quad \lor \quad \text{Status}_{\text{C}}(x^) \neq \text{Status}_{\text{Rust}}(x^*)$$

Контрпример немедленно сохраняется в виде минимального байтового среза (minimization corpus) и передается в prompt-контекст агента Gemini 4 Argon с трассировкой стека вызовов.

5. Результаты реальных кейсов: giflib, libgav1 и Zircon

Практическая апробация 3-этапного пайплайна в инфраструктуре Google показала неожиданные эффекты не только в области надежности, но и в производительности.

Результаты миграции ключевых проектов

Проект	Объем / Архитектура	Результат миграции на Rust
giflib	~3 000 строк C	100% ABI-совместимость. Попутно обнаружена и закрыта Zero-Day уязвимость `CVE-2026-26740` (out-of-bounds heap write) в оригинальном C-коде.
libgav1 (AV1 декодер)	32 000 строк C + Hand-written SIMD	Полный отказ от ассемблерных вставок в пользу Safe Rust. Ускорение декодирования в 2.7 раза.
Fuchsia Zircon Kernel	800 000+ строк C/C++	Модульная миграция подсистем ядра ОС без деградации IPC-латентности.

Почему Safe Rust в libgav1 обогнал 32k строк ручного SIMD?

Один из главных мифов системной разработки гласит: «Ручные SIMD-интринсики на C всегда быстрее безопасного кода». Кейс libgav1 опроверг это на практике.

Причина кроется в алиасинге указателей (Pointer Aliasing). В языке C компилятор вынужден консервативно предполагать, что любые два указателя одного типа (uint8_t* a, uint8_t* b) могут указывать на перекрывающиеся области памяти (если не указано ключевое слово restrict, которое разработчики часто забывают). Это блокирует автоматическую векторизацию циклов компилятором LLVM.

В Rust модель владения гарантирует:

Ссылка &mut T является строго уникальной (no-alias invariant гарантирован на уровне семантики языка).
Ссылки &T гарантированно неизменяемы (immutable).

Получив чистый Rust-код без алиасинга, оптимизатор LLVM смог провести агрессивную векторизацию для инструкций AVX2 и AVX-512, выстроив конвейер вычислений эффективнее, чем 32 000 строк устаревшего ручного ассемблерного кода, написанного под специфические микроархитектуры прошлых поколений.

6. Чек-лист внедрения AI-миграции в инженерный контур

Для команд, планирующих перевод критических C/C++ библиотек на Rust:

Изолируйте C-ABI заголовок: Сформируйте чистый заголовочный файл .h со всеми экспортируемыми функциями и типами данных.
Сгенерируйте Rust FFI через bindgen / AI: Обеспечьте точное соответствие структур с аннотацией #[repr(C)].
Разверните дифференциальный фаззер (LibAFL): Напишите harness, принимающий входной буфер const uint8_t* data, size_t size и вызывающий обе библиотеки.
Задайте порог останова фаззинга: Минимум $10^8$ итераций без единого расхождения вывода и без утечек памяти (проверяется через ASan/Valgrind).
Замените .so в staging-окружении: Проведите нагрузочное и регрессионное тестирование зависимых сервисов.

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

Автономная миграция стала индустриальным стандартом: AI-агенты в связке со строгими компиляторными верификаторами и дифференциальным фаззингом способны переносить миллионы строк системного кода, устраняя 70% фундаментальных уязвимостей безопасности памяти.
Фаззинг — единственный надежный судья: Любой сгенерированный LLM системный код требует дифференциального тестирования против оригинала на миллиардах мутированных входных векторов.
Safe Rust не уступает в скорости: Строгие гарантии уникальности ссылок (&mut) в Rust дают компилятору LLVM свободу векторизации, превосходящую ручной legacy-ассемблер.

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

Оригинальное видео/статья: Let’s Get Rusty — Google Uses AI to Migrate C/C++ to Rust
Заметки и детальный конспект: Obsidian Vault (GitHub)
Инженерные наработки: github.com/xsa-dev

Order Flow, Footprint и CVD в алготрейдинге: физика ликвидности и чтение микроструктуры рынка

Alexei Savin — Thu, 08 Oct 2026 00:00:00 +0000

Большинство розничных трейдеров и начинающих квант-разработчиков смотрят на рынок через призму свечей (OHLCV) и производных индикаторов (RSI, MACD, скользящие средние). Главная проблема такого подхода — запаздывание и потеря информации.

Свеча фиксирует только финальный результат интервала времени, скрывая главное: какие объемы, по каким ценам и с какой агрессией проторговывались внутри бара.

Order Flow (поток ордеров) — это фундаментальная физика биржи. Это регистрация реального взаимодействия между покупателями и продавцами в режиме реального времени.

Разберем, как устроена биржевая ликвидность, как читать кластерный график (Footprint), интерпретировать накопленную дельту (CVD) и формализовать эти сигналы в алгоритмических стратегиях.

1. Физика рынка: Market vs Limit ордера в биржевом стакане (DOM)

Рыночная цена не движется сама по себе — ее двигает исключительно дисбаланс между агрессивными и пассивными заявками в Depth of Market (DOM):

Сторона стакана	Ценовой уровень	Доступный объем	Роль участника
🔴 ASK (Sell Limit)	`$65,010`	`12.5 BTC`	Пассивный продавец
🔴 ASK (Sell Limit)	`$65,005`	`8.0 BTC`	Пассивный продавец
🔴 ASK (Sell Limit)	`$65,000`	`4.2 BTC`	Best Ask (ближайшая ликвидность)
⚡ SPREAD	—	—	Market BUY выкупает ликвидность Ask
🟢 BID (Buy Limit)	`$64,995`	`5.1 BTC`	Best Bid (ближайшая поддержка)
🟢 BID (Buy Limit)	`$64,990`	`10.0 BTC`	Пассивный покупатель
🟢 BID (Buy Limit)	`$64,985`	`15.4 BTC`	Пассивный покупатель

Ключевые аксиомы микроструктуры:

Limit Orders (Пассивные): добавляют ликвидность в стакан. Они формируют уровни поддержки/сопротивления и ждут, пока в них исполнятся другие участники.
Market Orders (Агрессивные): забирают ликвидность из стакана. Только рыночные ордера двигают цену, «выедая» лимитные заявки на противоположной стороне.
Deep vs Shallow Market: на глубоком рынке крупный рыночный ордер сдвинет цену незначительно; на тонком (неликвидном) рынке даже средний объем пробьет несколько ценовых уровней (проскальзывание / slippage).

2. Volume Footprint: кластерный рентген свечи

Footprint разбивает каждую свечу на ценовые уровни и показывает объем сделок, совершенных по цене Bid (агрессивные продажи) и по цене Ask (агрессивные покупки):

Уровень цены	Bid (Market Sell)	Ask (Market Buy)	Delta ($\Delta$)	Рыночная структура
$65,020	`12`	`85`	`+73`	🟢 Stacked Buying Imbalance
$65,015	`5`	`42`	`+37`	🟢 Stacked Buying Imbalance
$65,010	`18`	`90`	`+72`	🟢 Агрессор пробивает уровень
$65,005	`50`	`48`	`-2`	Нейтральный баланс
$65,000	`120`	`110`	`-10`	🔵 Point of Control (POC / макс. объем)

Что дает Footprint:

Delta ($\Delta$): разница между покупками по Ask и продажами по Bid на конкретной цене: $$\Delta = \text{Volume}_{\text{Ask}} - \text{Volume}_{\text{Bid}}$$
Stacked Imbalance (Стек дисбалансов): ситуация, когда 3 и более ценовых уровня подряд показывают многократный перевес покупателей или продавцов (обычно от 300% до 400%). Это маркер сильного импульса.

3. Два ключевых паттерна: Absorption vs Initiation

При анализе Footprint алгоритм ищет два фундаментальных состояния рынка:

flowchart TD
    subgraph P1 ["🛡️ Паттерн 1: Absorption (Поглощение лимитным игроком)"]
        direction TB
        A1["Агрессивные Market SELL (Delta резко отрицательная)"]
        A2["Крупный Buy Limit на дне свечи впитывает весь объем"]
        A3["Итог: Гигантский объем на дне, но цена НЕ падает"]
        A4["🟢 Сигнал: Бычий разворот (Bullish Reversal)"]
        A1 --> A2 --> A3 --> A4
    end

    subgraph P2 ["⚡ Паттерн 2: Initiation (Инициация импульса)"]
        direction TB
        B1["Агрессивные Market BUY легко выносят тонкий стакан Ask"]
        B2["Свеча закрывается на максимуме с устойчивой дельтой"]
        B3["🟢 Сигнал: Истинный пробой и продолжение тренда"]
        B1 --> B2 --> B3
    end

4. CVD (Cumulative Volume Delta) и дивергенции

CVD (накопленная дельта объема) суммирует дельту всех совершенных сделок с начала сессии или расчетного окна:

$$\text{CVD}_t = \sum_{i=1}^{t} \Delta_i = \sum_{i=1}^{t} (\text{Vol}_{\text{Ask}, i} - \text{Vol}_{\text{Bid}, i})$$

Дивергенции CVD как индикатор истощения:

Медвежья дивергенция (Bearish Absorption): цена обновляет локальный максимум (Higher High), но CVD формирует более низкий максимум (Lower High) или резко падает. Это означает, что рост идет на тонком рынке без поддержки реальных покупок.
Бычья дивергенция (Bullish Absorption): цена обновляет минимум (Lower Low), а CVD растет (Higher Low). Агрессивные продажи упираются в скрытые лимитные заявки крупного покупателя.

5. Volume Profile: POC, Value Area, HVN и LVN

В то время как классический объем привязан к времени (Volume per Bar), Volume Profile группирует объем по горизонтальным ценовым уровням (Volume at Price):

Ценовой уровень	Профиль объема	Тип зоны	Структура ликвидности
$65,030	`█`	LVN	Зона быстрого пролета (тонкая ликвидность)
$65,020	`██████`	VA	Value Area (торговля в балансе)
$65,010	`████████████████████`	POC / HVN	Point of Control (максимальное принятие цены)
$65,000	`██████████`	VA	Value Area (торговля в балансе)
$64,990	`█`	LVN	Зона отторжения цены

Анатомия ключевых зон Volume Profile:

В зависимости от концентрации объема алгоритм делит горизонтальный профиль на четыре базовых узла ликвидности:

Уровень	Описание	Торговый смысл
POC (Point of Control)	Ценовой уровень с максимальным объемом за период.	Служит «магнитом» для цены и сильным уровнем ретеста.
Value Area (VA)	Диапазон цен, в котором прошло ~70% всего объема.	Торговля внутри VA = баланс; выход за границы VA = направленный импульс.
HVN (High Volume Node)	Узлы высокой плотности объема.	Зоны консолидации и принятия справедливой цены.
LVN (Low Volume Node)	Узлы низкой плотности объема.	Уровни неликвидности, которые цена проскакивает с высокой скоростью.

6. Алгоритмическая реализация: расчет Delta и CVD на Python

Для количественных бэктестов и торговых ботов поток тиков (Trade Prints / Time & Sales) агрегируется по тиковым флагам (is_buyer_maker):

import pandas as pd
import numpy as np

def calculate_order_flow_metrics(trades_df: pd.DataFrame) -> pd.DataFrame:
    """
    Расчет дельты и CVD по потоку тиковых сделок биржи.
    trades_df содержит: ['timestamp', 'price', 'quantity', 'is_buyer_maker']
    """
    # Если сделка совершена по инициативе покупателя (buyer is taker), это покупка по Ask
    # Если is_buyer_maker == True, значит покупатель выставил лимит, а продавец ударил по рынку (Sell)
    trades_df['is_buy'] = ~trades_df['is_buyer_maker']
    
    trades_df['buy_vol'] = np.where(trades_df['is_buy'], trades_df['quantity'], 0.0)
    trades_df['sell_vol'] = np.where(~trades_df['is_buy'], trades_df['quantity'], 0.0)
    trades_df['delta'] = trades_df['buy_vol'] - trades_df['sell_vol']
    
    # Расчет кумулятивной дельты (CVD)
    trades_df['cvd'] = trades_df['delta'].cumsum()
    
    # Агрегация по 1-минутным барам
    bars = trades_df.resample('1min', on='timestamp').agg({
        'price': ['first', 'max', 'min', 'last'],
        'quantity': 'sum',
        'buy_vol': 'sum',
        'sell_vol': 'sum',
        'delta': 'sum',
        'cvd': 'last'
    })
    
    return bars

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

Цену двигают только агрессивные заявки: рыночные покупки бьют по лимитным продажам (Ask), рыночные продажи — по лимитным покупкам (Bid).
Footprint дает опережающий сигнал: паттерны Absorption (поглощение) на ключевых уровнях позволяют заходить в позиции до того, как индикаторы успеют отреагировать.
CVD выявляет манипуляции и истощение: расхождение между движением цены и накопленной дельтой защищает от ложных пробоев.
Volume Profile очерчивает карту боя: POC и границы Value Area (VA) служат математически обоснованными таргетами для фиксации прибыли и выставления защитных стоп-приказов.

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

Автор курса и видеоматериал: Mind Math Money — MASTER Order Flow Trading (Complete Guide)
Детальный конспект и cheat-sheet в базе знаний: Obsidian Vault: Order Flow Course Notes (GitHub)
Количественные репозитории: github.com/xsa-dev

Алгоритмический трейдинг на Polymarket: архитектура снайпера 5-минутных бинарных рынков через CLOB API

Alexei Savin — Thu, 08 Oct 2026 00:00:00 +0000

Рынки предсказаний (Prediction Markets, в частности Polymarket) переживают экспоненциальный рост объема торгов. В отличие от традиционных спотовых или фьючерсных рынков, здесь торгуются бинарные контракты (Binary Outcome Shares), цена которых колеблется в диапазоне от $0.00 до $1.00 и отражает вероятность наступления события:

$$P(\text{Event}) \in [0, 1]$$

С появлением ультракоротких 5-минутных рынков на криптовалюты (BTC, ETH, SOL, XRP «Будет ли цена выше $X в 14:05?») открылось окно возможностей для алгоритмического арбитража и снайпинга за счет временного лага между спотовыми/деривативными биржами и стаканом предсказаний.

Разберем архитектуру торгового бота Strike Sniper (исследованного Moon Dev), особенности работы с Polymarket CLOB API и ключевые риски высокочастотного исполнения.

1. Топология архитектуры: Cross-Exchange Price Discovery

Снайпинг предсказательных рынков строится на сопоставлении двух источников данных:

flowchart TD
    subgraph S1 ["⚡ 1. Быстрый источник (Hyperliquid L2 WebSocket)"]
        direction TB
        H1["Real-time спот/перп котировки (BTC, ETH, SOL)"]
        H2["Мгновенная регистрация импульса цены"]
        H1 --> H2
    end

    S1 ==>|Референсная цена P_ref| S2

    subgraph S2 ["🎯 2. Стратегический движок (Strike Sniper Logic)"]
        direction TB
        G1["Polymarket Gamma API: Strike Price K"]
        G2["Сравнение: P_ref > K + Spread_safe?"]
        G3["Расчет размера позиции (Share Sizing)"]
        G1 --> G2
        G2 -->|Да, вероятность YES растет| G3
    end

    S2 ==>|Taker Order Intent - EIP-712| S3

    subgraph S3 ["🛡️ 3. Исполнение (Polymarket CLOB API)"]
        direction TB
        C1["Central Limit Order Book (L2 стакан)"]
        C2["Лимитные / Taker заявки на YES / NO"]
        C3["Event Logger + Circuit Breaker (Daily Stop-Loss)"]
        C1 --> C2 --> C3
    end

2. Механика биржи: Central Limit Order Book (CLOB)

Polymarket использует не классический AMM (как Uniswap), а полноценную биржевую книгу лимитных ордеров (CLOB — Central Limit Order Book) с поддержкой EIP-712 подписей:

YES / NO токены: каждый исход представлен ERC-1155 токеном. Покупка YES по цене $0.65 означает выплату $1.00 в случае победы (прибыль $0.35) или $0.00 в случае проигрыша (убыток $0.65).
Taker vs Maker: снайпер чаще всего выступает как Taker — выкупает ликвидность из стакана Ask, когда референсная цена на Hyperliquid уже ушла выше страйка, но лимитные заявки на Polymarket еще не успели переставиться.
Расчет количества долей (Shares): $$\text{Shares} = \frac{\text{Budget}}{\text{Best Ask Price}}$$

3. Количественный контур на Python

Пример архитектуры ядра снайпера для опроса цен и отправки ордера:

import time
import requests
from dataclasses import dataclass

@dataclass
class MarketTarget:
    symbol: str
    strike_price: float
    token_id: str
    end_time: int

class PolymarketStrikeSniper:
    def __init__(self, clob_client, hyperliquid_feed):
        self.client = clob_client
        self.feed = hyperliquid_feed
        self.daily_pnl = 0.0
        self.max_daily_loss = -50.0  # Circuit Breaker: -$50 в день
        
    def evaluate_market(self, target: MarketTarget, budget_usd: float = 5.0):
        # 1. Защита капитала (Circuit Breaker)
        if self.daily_pnl <= self.max_daily_loss:
            print("[ALERT] Daily Stop-Loss достигнут. Торги остановлены.")
            return

        # 2. Получение быстрой цены с деривативной биржи
        ref_price = self.feed.get_latest_mid_price(target.symbol)
        
        # 3. Получение лучшего аска в стакане Polymarket CLOB
        orderbook = self.client.get_order_book(target.token_id)
        best_ask = float(orderbook['asks'][0]['price'])
        
        # 4. Логика арбитражного входа: цена уверенно выше страйка, но контракт дешев
        price_buffer = target.strike_price * 0.0015  # 0.15% буфер запаса
        if ref_price > (target.strike_price + price_buffer) and best_ask < 0.85:
            shares = int(budget_usd / best_ask)
            if shares > 0:
                print(f"[EXECUTE] BUY {shares} shares @ ${best_ask:.2f} (Ref: ${ref_price:.2f} > Strike: ${target.strike_price:.2f})")
                # Отправка taker-ордера через подпись EIP-712
                self.client.create_and_post_order(
                    token_id=target.token_id,
                    price=best_ask,
                    size=shares,
                    side="BUY"
                )

4. Подводные камни и риски 5-минутного снайпинга

Высокая частота рынка создает серьезные скрытые издержки:

Turnover Drag (Частотный риск): 4 актива каждые 5 минут генерируют до 48 торговых циклов в час. Без строгого математического преимущества (Edge) серия из 3–4 убытков подряд быстро сжигает депозит.
Задержка разрешения рынка (Settlement Latency): оракул (UMA / Chainlink) разрешает исход по фиксированному снепшоту цены. Разница в источниках цен (Binance vs Coinbase vs Hyperliquid) может привести к тому, что локальный индикатор показал победу, а оракул зафиксировал проигрыш.
Slippage и глубина стакана: на 5-минутных контрактах ликвидность ограничена сотнями долларов. Попытка зайти крупным объемом мгновенно сдвигает цену до невыгодных $0.95+.

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

Бинарные рынки — это вероятность, а не направление: расчет строится вокруг вероятности $P > \text{Ask Price}$ с поправкой на дисконт риска.
Кросс-рыночный арбитраж: скорость получения спотовых/перп тиков (Hyperliquid L2) является главным конкурентным преимуществом.
Обязательный Circuit Breaker: алгоритмический лимит дневного убытка (max_daily_loss) критически необходим для защиты от непредвиденных сбоев оракулов или задержек сети.

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

Автор исследования и демонстрация бота: Moon Dev — Fable 5 Made Me a 5 Min Polymarket Trading Bot
Детальный конспект в базе знаний: Obsidian Vault: Polymarket Strike Sniper Notes (GitHub)
Количественные репозитории: github.com/xsa-dev

Self-Improving AI Software Factory: архитектура распределенной фабрики кода на базе LLM-агентов

Alexei Savin — Thu, 08 Oct 2026 00:00:00 +0000

Локальные инструменты агентного кодинга (Codex, Claude Code, Aider, OpenDevin) совершили революцию в индивидуальной разработке. Однако при попытке масштабировать этот подход на уровень команды или автоматизированного пайплайна инженеры неизбежно упираются в системный тупик:

Локальный хаос промптов и конфигураций: у каждого разработчика свои настройки контекста, разные версии моделей и несогласованные правила форматирования.
Отсутствие воспроизводимости: невозможно точно оценить, улучшило ли очередное изменение в системном промпте качество кодогенерации или сломало граничные кейсы.
Неэффективная трата токенов: использование мощных LLM для механических задач (проверка синтаксиса, парсинг логов, поиск файлов) вместо детерминированных скриптов.

Решением становится переход от локальных CLI-утилит к AI Software Factory — централизованной распределенной системе оркестрации агентных воркеров с замкнутым контуром самообучения (Self-Improving Feedback Loop).

Разберем архитектуру такой фабрики (на примере системы Machinist, исследованной Оуэйном Льюисом).

1. Архитектура фабрики: Control Plane и Worker Pool

В основе промышленной фабрики кода лежит строгое разделение между уровнем управления (Control Plane) и изолированными вычислительными узлами (Worker Pool):

flowchart TD
    subgraph Triggers ["⚡ Входной поток задач (Triggers)"]
        T1["Webhooks / CI / Jira / CLI"]
    end

    Triggers -->|Новый тикет / запрос| CP

    subgraph CP ["🎛️ CONTROL PLANE (Machinist)"]
        direction TB
        DB[("Task Queue & Global State<br/>(SQLite / WAL)")]
        Catalog["Prompts & Skills Catalog"]
        Dashboard["Web Dashboard & Traces"]
        SSHGate["SSH Tunnel Gateway"]
    end

    CP ==>|🔒 Dispatches jobs over SSH tunnel| WP

    subgraph WP ["☁️ WORKER POOL (Hetzner / Cloud VMs)"]
        direction TB
        Foreman["👑 1. Foreman Agent<br/>(Планирование и декомпозиция)"]
        SubAgents["🤖 2. Sub-Agents Swarm<br/>(Claude Coder / Codex / PyTest)"]
        Audit["🛡️ 3. Audit Agent + Deterministic Evals<br/>(mypy, pytest, 3-Agent Review)"]

        Foreman -->|Делегирование подзадач| SubAgents
        SubAgents -->|Код, патчи и артефакты| Audit
    end

Преимущества такой топологии:

Изоляция окружения: агенты выполняют сборку, запуск тестов и системные команды на недорогих облачных серверах (например, Hetzner Cloud VM с 16–32 GB RAM), не засоряя локальную машину разработчика.
Очередь задач с лимитом параллелизма: Control Plane контролирует лимиты API (max_concurrent_jobs) и защищает от исчерпания рейтов LLM-провайдеров.

2. Иерархия агентных ролей: Foreman → Sub-agents → Audit

Монолитный агент, пытающийся одновременно планировать архитектуру, писать код, ставить зависимости и проверять тесты, быстро теряет фокус из-за раздувания контекстного окна (Context Rotting).

В фабрике реализовано четкое разделение ответственности:

Роль	Зона ответственности	Инструменты
Foreman (Прораб)	Принимает высокоуровневый тикет, исследует кодовую базу, формирует план и распределяет подзадачи.	`search_files`, `read_file`, `delegate_task`
Sub-Agent (Кодер)	Выполняет строго одну изолированную задачу в конкретном модуле (написание функции, рефакторинг, фикс бага).	`patch`, `write_file`, `terminal`
Audit Agent (Аудитор)	Проверяет соответствие критериям приемки, соответствие стилю и отсутствие побочных регрессий.	`pytest`, `cargo test`, `git diff`

3. Детерминированные Evals вместо лишних LLM-вызовов

Одна из главных ошибок при проектировании AI-фабрик — попытка решать все задачи через промпты нейросетей.

Золотое правило: если задачу можно надежно и дешево решить регулярным выражением, статическим анализатором или bash-скриптом — не отправляйте ее в LLM.

# Пример детерминированного гейта качества без участия нейросети
import subprocess
import sys

def verify_code_artifact(repo_path: str) -> bool:
    # 1. Синтаксический анализ и типы
    typecheck = subprocess.run(["mypy", repo_path], capture_output=True)
    if typecheck.returncode != 0:
        print(f"[FAIL] Typecheck errors:\n{typecheck.stdout.decode()}")
        return False
        
    # 2. Модульные тесты
    tests = subprocess.run(["pytest", "-q", f"{repo_path}/tests"], capture_output=True)
    if tests.returncode != 0:
        print(f"[FAIL] Unit tests broken:\n{tests.stdout.decode()}")
        return False

    return True

if __name__ == "__main__":
    if not verify_code_artifact("."):
        sys.exit(1)

Детерминированные скрипты дают 100% стабильный результат, выполняются за миллисекунды и экономят тысячи долларов на API-токенах.

4. Self-Improving Feedback Loop: обучение на трейсах

Почему фабрика называется самообучающейся?

Агентная фабрика не просто исполняет задачи, она непрерывно накапливает базу знаний об ошибках:

flowchart TD
    Fail["❌ Неудачный запуск / Broken Build"] --> Trace["📋 Трейс выполнения: логи + контекст"]

    subgraph RootCause ["🔍 Автоматический анализ узкого места"]
        direction TB
        P1["Неточная инструкция в системном промпте?"]
        P2["Недостаточный контекст из документации?"]
        P3["Сбойный вспомогательный скрипт?"]
    end

    Trace --> RootCause

    subgraph KnowledgeUpdate ["🚀 Обновление фабрики (Feedback Loop)"]
        direction TB
        K1["1. Обновление каталога Skills & Prompts"]
        K2["2. Создание нового синтетического Eval-теста"]
        K1 <--> K2
    end

    RootCause ==> KnowledgeUpdate
    KnowledgeUpdate -.->|Внедрение в воркеры| Fail

Когда один агент находит решение сложной проблемы или совершает ошибку, исправление вносится в централизованный репозиторий промптов и скиллов. В следующий раз все воркеры фабрики автоматически получают обновленную базу знаний.

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

Централизация побеждает локальный хаос: единый Control Plane с версионированием промптов и очереди задач обеспечивает воспроизводимость.
Разделение труда (Foreman / Sub-agents / Audit): узкоспециализированные агенты с компактным контекстом работают надежнее и дешевле монолитов.
Детерминизм во главе угла: используйте классические линтеры, компиляторы и тесты вместо LLM-судей везде, где это возможно.
Контур обратной связи (Evals Loop): каждый упавший трейс превращается в синтетический тест для предотвращения будущих регрессий.

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

Оригинальное видео и автор: Owain Lewis — I Built A Self-Improving AI Software Factory
Детальный структурированный конспект: Obsidian Vault: Owain Lewis Software Factory (GitHub)
Инженерные наработки: github.com/xsa-dev

Обо мне

Alexei Savin — Wed, 07 Oct 2026 00:00:00 +0000

Привет! Я занимаюсь разработкой систем, автоматизацией, алгоритмическим трейдингом и AI-агентами.

Стек и фокус

Языки: Rust, Python, Go, TypeScript
Области: Высоконагруженные бэкенды, MLOps, торговые системы, автономные агенты
Инфраструктура: Linux, Docker, Tailscale, CI/CD

Контакты

GitHub: github.com/xsa-dev
Telegram: @AlphaPipeline
X / Twitter: @alxy_dev

Запуск блога на Zola

Alexei Savin — Wed, 07 Oct 2026 00:00:00 +0000

Этот блог построен на базе Zola — быстрого статического генератора сайтов на Rust.

Преимущества Zola

Один бинарник: Никаких node_modules, Ruby gems или Python venv.
Высокая производительность: Сборка сотен страниц занимает доли секунды.
Шаблонизатор Tera: Мощный синтаксис, вдохновленный Jinja2 / Liquid.
Встроенная подсветка синтаксиса: Быстрая подсветка кода без клиентского JS.

Пример кода на Rust

fn main() {
    println!("Hello, Zola!");
}

Поддержка цитат и разметки

Простота — необходимое условие надежности. — Edsger W. Dijkstra

Блог поддерживает автоматическую генерацию RSS/Atom фидов, теги и адаптивную темную тему.

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

Официальная документация Zola: getzola.org
Репозиторий блога и темы: xsa-dev/xsa-dev.github.io (GitHub)
Инженерные наработки: github.com/xsa-dev

Reinforcement Learning в алготрейдинге: архитектура памяти состояний, Q-learning и стационарные признаки

Alexei Savin — Wed, 07 Oct 2026 00:00:00 +0000

Большинство попыток применить классическое машинное обучение (Supervised Learning) к финансовым рынкам разбиваются об одну фундаментальную проблему — нестационарность временных рядов. Рыночный режим меняется, скользящие средние смещаются, а обученная на исторических ценах «монолитная» нейросеть начинает генерировать ложные сигналы.

Вместо монолитных «черных ящиков» в количественном трейдинге все чаще применяются иерархические системы обучения с подкреплением (Reinforcement Learning) на основе дискретной памяти состояний и стационарных признаков.

Разберем архитектуру такого контура: от квантования рыночного опыта в «нейроны памяти» до взвешенного ансамблевого голосования (Collective Mind).

1. Иерархическая архитектура: от нейрона к ансамблю

Вместо одной сложной модели строится трехуровневая модульная иерархия:

flowchart TD
    CM["🧠 Collective Mind (Совет агентов)<br/>Взвешенное динамическое голосование"]

    A1["📈 Агент 1: Trend Following<br/>(Свои веса & Q)"]
    A2["🔄 Агент 2: Mean Reversion<br/>(Свои веса & Q)"]
    A3["⚡ Агент 3: Volatility Breakout<br/>(Свои веса & Q)"]

    CM -->|Агрегация весов P_win| A1
    CM -->|Агрегация весов P_win| A2
    CM -->|Агрегация весов P_win| A3

    DB[("💾 База нейронов памяти (Q-Table)<br/>Квантованные инварианты опыта z_t")]

    A1 -->|Чтение / Запись опыта| DB
    A2 -->|Чтение / Запись опыта| DB
    A3 -->|Чтение / Запись опыта| DB

Нейрон памяти (Memory Neuron): элементарная единица опыта. Хранит квантованный ключ рыночной ситуации, предпринятое действие ($a \in {\text{Buy}, \text{Sell}, \text{Hold}}$), текущую $Q$-оценку, счетчик посещений и возраст записи.
Специализированный агент: независимый модуль логики со своим фокусом (краткосрочный импульс, спред, фильтр волатильности).
Collective Mind (Коллективный разум): управляющий контур, объединяющий решения агентов через взвешенное голосование, где вес каждого агента динамически пропорционален его исторической точности ($P_{\text{win}}$).

2. Стационарные признаки: инвариантность к уровню цен

Сырые цены закрытия и абсолютные индикаторы нестационарны. Если обучить модель на Bitcoin по $30,000, при цене $90,000 ее веса потеряют физический смысл.

Решение — переход к стационарным z-score инвариантам:

$$z_t = \frac{p_t - \mu_{\text{SMA}(k)}}{\sigma_{\text{StdDev}(k)}}$$

Вектор состояния описывает не «где находится цена», а «форму и аномалию движения» относительно локальной волатильности. Далее непрерывные значения квантуются в дискретные интервалы (бины). Например:

$z_{\text{RSI}} \in {\text{Oversold}, \text{Neutral}, \text{Overbought}}$
$z_{\text{Spread}} \in {\text{Tight}, \text{Normal}, \text{Wide}}$

Благодаря квантованию пространство состояний сжимается с бесконечности до сотен тысяч обозримых ситуаций, которые накапливают статистический опыт.

3. Математика Q-Learning и балансировка редких классов

Обновление оценок ценности действия строится по уравнению Беллмана:

$$Q(s, a) \leftarrow Q(s, a) + \alpha \cdot \left[ r + \gamma \cdot \max_{a’} Q(s’, a’) - Q(s, a) \right]$$

где:

$\alpha$ — скорость обучения (learning rate);
$\gamma$ — фактор дисконтирования будущих наград;
$r$ — немедленная рыночная награда (PnL с поправкой на проскальзывание и комиссию).

# Концептуальная логика обновления нейрона памяти
class MemoryNeuron:
    def __init__(self, state_key, action):
        self.state_key = state_key
        self.action = action
        self.q_value = 0.0
        self.visits = 0
        self.last_seen = 0

    def update(self, reward, next_max_q, alpha=0.1, gamma=0.95):
        # Балансировка: редкие состояния обновляются с повышенным весом
        effective_alpha = alpha / (1.0 + 0.01 * self.visits)
        td_target = reward + gamma * next_max_q
        self.q_value += effective_alpha * (td_target - self.q_value)
        self.visits += 1

Борьба с дисбалансом классов: на рынке 70%+ времени идет боковик. Без балансировки редкие ситуации разворота тренда просто не успеют набрать статистику. Взвешивание через счетчик посещений позволяет системе адекватно оценивать редкие критические режимы.

4. Pruning памяти и адаптивный Exploration

Чтобы база нейронов памяти не раздувалась, применяются два механизма:

Pruning (Отсечение): нейроны с околонулевыми счетчиками посещений за длительный период или стабильно отрицательным $Q$ удаляются, освобождая память и очищая стратегию от устаревших аномалий.
Эволюционный $\varepsilon$-Greedy: в спокойные периоды система эксплуатирует накопленный опыт ($\varepsilon \to 0$), а при резких скачках волатильности (режим сменился) уровень исследования повышается.

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

Квантование + z-score превращают нестационарные рыночные котировки в долговечные признаки.
Иерархия (Память → Агенты → Совет) защищает от сбоев отдельных стратегий за счет взвешенного ансамбля.
Детерминированный Q-learning на понятных состояниях прозрачнее и устойчивее к оверфиттингу, чем глубокие черные ящики.

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

Автор исследования: Yevgeniy Koshtenko (MQL5 / MetaTrader 5 Research)
Заметки и детальный конспект статьи: Obsidian Vault: RL System AlgoTrading (GitHub)
Количественные репозитории: github.com/xsa-dev

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

Alexei Savin — Wed, 07 Oct 2026 00:00:00 +0000

Концепция автономного торгового агента, который «сам торгует, анализирует свои ошибки и дообучает стратегию 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

Alexei Savin — Wed, 07 Oct 2026 00:00:00 +0000

Большинство метрик, по которым сегодня сравнивают языковые модели (вроде 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