Notes & Insights - evals

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

2026-10-08T00:00:00+00:00

Проблема безопасности памяти (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

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

2026-10-08T00:00:00+00:00

Локальные инструменты агентного кодинга (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

Как обучать и оценивать 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