Метод
Библиотека workloads
Фиксированные версионируемые нагрузки с замороженными корпусами, хэшами и acceptance-проверками. Результат квалификации имеет смысл только относительно конкретной ревизии workload — материальное изменение создаёт новую ревизию, а не тихий апдейт.
Все v1-workloads — черновики: поля идентичности определены, но корпуса и acceptance-наборы ещё не заморожены. Черновые workloads не используются для публичных headline-заявлений.
- interactive-assistant-v1 Черновик
Отзывчив ли одиночный стриминговый чат на этой системе?
Клиентский TTFT, межтокенная задержка, e2e при concurrency 1/2/4; гейты формата, языка и повторов; baseline без кэша; 3 повтора.
- team-serving-v1 Черновик
Какой поток запросов система держит в рамках заявленного SLO?
Развёртка по concurrency (closed-loop) плюс open-loop по замороженному трейсу; goodput vs throughput; отказы остаются в знаменателе; результат — operating envelope.
- long-context-v1 Черновик
Какова глубина полезного контекста на системе — а не настраиваемого?
Лестница 8K/32K/64K/128K; задачи класса RULER плюс подмножество в духе LongBench с контролями answerable/unanswerable; различает configured / loadable / completed / quality-preserving / recommended.
- structured-agent-v1 Черновик
Надёжен ли JSON/function calling под реалистичным агентным трафиком?
Вызовы класса BFCL, включая relevance rejection, параллельные и исполняемые вызовы, детекцию циклов; детерминированная песочница; парсинг ≠ успех задачи.
- endurance-30m-v1 Черновик
Переживает ли предварительно квалифицированная рабочая точка 30 минут постоянной нагрузки?
Временные ряды: throughput, TTFT, рост памяти, температуры и троттлинг на одной рабочей точке; критерии pass фиксируются заранее; универсального pass нет.
- rag-pipeline-ru-v0 Внутренний
Где именно русскоязычный RAG-пайплайн теряет качество, покомпонентно?
Покомпонентная оценка: OCR CER/WER → F1 границ сплиттера → Recall@k/nDCG → дельта реранкера → support/abstention/citations генерации. Внутренний до прохождения 6 release-гейтов.