Anthropic Engineering: Contextual Retrieval и «Demystifying evals for AI agents» — конспект

Две статьи Engineering at Anthropic, объединённые общей идеей: сначала измерь, потом улучшай. Первая — конкретный приём для RAG с подробными замерами. Вторая — большое руководство, как оценивать агентов. Статьи защищены авторским правом — здесь конспект своими словами; оригиналы: Introducing Contextual Retrieval и Demystifying evals for AI agents.

Коротко

• Чанк без контекста теряет смысл. «Выручка компании выросла на 3 % за квартал» — какой компании, какого квартала? Contextual Retrieval дописывает к каждому чанку 50–100 токенов пояснения, сгенерированных моделью по всему документу, — до эмбеддинга и до индекса BM25.
• Эффект складывается: контекстные эмбеддинги −35 % неудачных поисков, плюс контекстный BM25 −49 %, плюс реранкинг −67 %. Генерация контекста дёшева благодаря кэшированию промптов.
• Если база знаний меньше ~200 000 токенов, RAG может быть не нужен — положите её в промпт целиком.
• Эвал агента — это задачи, попытки, грейдеры, транскрипты и итоговое состояние среды. Оценивайте результат, а не путь: агенты находят решения, которых авторы эвала не предвидели.
• pass@k и pass^k рассказывают противоположные истории: первая растёт с числом попыток, вторая падает. Для клиентских агентов важна надёжность — pass^k.
• Начинайте с 20–50 задач из реальных провалов и читайте транскрипты: оценке нельзя верить, пока кто-то не посмотрел, за что именно агент получил баллы.

Как читать вместе с курсом

• Contextual Retrieval — к уроку 8.2.2 «Продвинутый RAG и оценка»: там BM25, гибридный поиск с RRF и реранкеры собраны руками; статья показывает, как они складываются с контекстом чанков. Код — рецепт contextual-embeddings в Claude Cookbooks.
• Demystifying evals — к урокам 7.3.2 (pass@k, LLM-судья), 8.4.2 «Eval-driven development и наблюдаемость» и части 3 урока 8.3.4 «Как оценивать агентов».
• Что пропустить новичку. Приложение I первой статьи (таблицы по наборам данных) и приложение второй (обзор фреймворков).

---

Часть 1. Introducing Contextual Retrieval (сентябрь 2024)

Сначала — может, RAG не нужен?

Простейшее решение иногда лучшее: если база знаний меньше 200 000 токенов (около 500 страниц), её можно целиком положить в промпт. Кэширование промптов делает это быстрым и дешёвым: по данным статьи, задержка падает более чем вдвое, а стоимость — до 90 %. RAG нужен, когда база растёт дальше.

Напоминание: как устроен RAG с BM25

Обычный конвейер: разрезать корпус на чанки по несколько сотен токенов → посчитать эмбеддинги → сложить в векторную базу → по запросу найти семантически близкие чанки и добавить их в промпт (урок 8.2.1).

Эмбеддинги хорошо ловят смысл, но могут промахнуться мимо точного совпадения. Пример из статьи: в базе техподдержки ищут «Error code TS-999»; эмбеддинг найдёт тексты про коды ошибок вообще, а BM25 — именно строку TS-999. BM25 развивает идею TF-IDF: учитывает длину документа и «насыщает» частоту слова, чтобы частые слова не перевешивали. Поэтому хороший конвейер ищет двумя способами и сливает результаты (rank fusion, например RRF из урока 8.2.2), убирая дубликаты.

Проблема: чанк теряет контекст

Возьмём отчёты компаний для SEC (американского регулятора рынка) и вопрос: «Каким был рост выручки ACME Corp во втором квартале 2023 года?» Нужный чанк содержит фразу «Выручка компании выросла на 3 % по сравнению с предыдущим кварталом». Но в нём нет ни названия компании, ни периода — по нему трудно найти и трудно правильно использовать.

Решение: допишем контекст к каждому чанку

Contextual Retrieval добавляет перед каждым чанком короткое пояснение, к чему этот чанк относится, — и уже по такому тексту считает эмбеддинг (Contextual Embeddings) и строит индекс BM25 (Contextual BM25). Чанк из примера превращается в нечто вроде: «Фрагмент из отчёта SEC о результатах ACME Corp во втором квартале 2023 года; выручка в предыдущем квартале — 314 млн долл. Выручка компании выросла на 3 % по сравнению с предыдущим кварталом».

Вручную так разметить тысячи и миллионы чанков невозможно, поэтому пояснения пишет модель (в статье — Claude 3 Haiku). Промпт короткий: целиком документ в тегах <document>, чанк в тегах <chunk> и просьба дать краткий контекст, который помещает чанк в документ «для улучшения поиска», и ничего больше. Результат — обычно 50–100 токенов.

flowchart LR
D["Документ целиком (в кэше)"] --> P["LLM: краткий контекст чанка"]
C["Чанк"] --> P
P --> CC["Контекст + чанк"]
CC --> E["Эмбеддинги"] --> V[("Векторная база")]
CC --> B["Индекс BM25"]
Q["Запрос"] --> V
Q --> B
V --> F["Слияние рангов"]
B --> F
F --> R["Реранкер: 150 → 20"] --> L["20 чанков в промпт"]

Contextual Retrieval с реранкингом: предобработка и поиск (наша схема по описанию в статье)

Авторы отмечают, что похожие идеи предлагались и раньше — добавлять к чанкам общую сводку документа, гипотетические документы (HyDE), индекс по сводкам, — но в их экспериментах эти приёмы давали мало. (Сравните с рецептом RAG из кукбука, где индекс со сводками помог: на другой задаче и с другими метриками выводы могут отличаться — поэтому и нужны свои эвалы.)

Почему это дёшево: кэширование промптов

Для каждого чанка нужно отправить модели весь документ. С кэшированием документ загружается в кэш один раз, а дальше запросы ссылаются на него. При чанках по 800 токенов, документах по 8000 токенов, инструкции в 50 токенов и контексте по 100 токенов единовременная стоимость, по расчёту авторов, — 1,02 долл. на миллион токенов документов.

Как мерили и что получилось

Эксперименты шли на нескольких областях знаний (код, художественная литература, статьи arXiv, научные статьи), с разными эмбеддинг-моделями, стратегиями поиска и метриками. Главная метрика — 1 − recall@20: доля нужных документов, которые не попали в топ-20 найденных чанков (чем меньше, тем лучше). Средние по всем областям для лучшей конфигурации эмбеддингов (Gemini Text 004):

Вариант	Доля неудачных поисков (топ-20)	Снижение
Обычные эмбеддинги + BM25 (база)	5,7 %	—
Контекстные эмбеддинги	3,7 %	−35 %
Контекстные эмбеддинги + контекстный BM25	2,9 %	−49 %
То же + реранкинг	1,9 %	−67 %

Как читать «−49 %»: было 57 промахов на 1000 нужных документов, стало 29 — почти вдвое меньше. Контекстуализация улучшила результат во всех проверенных сочетаниях эмбеддингов и данных.

Практические соображения

• Границы чанков. Размер, место разреза и перекрытие чанков влияют на качество поиска.
• Эмбеддинг-модель. Выигрыш есть у всех проверенных моделей, особенно хороши оказались Gemini и Voyage.
• Свой промпт для контекста. Общий промпт работает, но под свою область можно лучше — например, добавить глоссарий терминов, определённых в других документах базы.
• Сколько чанков отдавать модели. Пробовали 5, 10 и 20 — лучшим оказалось 20, но больше информации может и отвлекать модель; проверяйте на своей задаче.
• Всегда гоняйте эвалы. Генерация ответа может выиграть, если в промпте явно разделить «контекст» и «сам чанк».

Реранкинг

В большой базе первичный поиск возвращает много кандидатов разного качества. Реранкер (переранжировщик) пересчитывает их релевантность к запросу и оставляет лучшие. В экспериментах: взять топ-150 кандидатов, прогнать их вместе с запросом через реранкер (использовали Cohere; у Voyage тоже есть реранкер, но его проверить не успели) и оставить топ-20. Плата — дополнительная задержка на шаге поиска, хотя кандидаты оцениваются параллельно; чем больше кандидатов, тем лучше качество и тем дороже. Баланс подбирается под задачу.

Выводы статьи

1. Эмбеддинги + BM25 лучше одних эмбеддингов.
2. Из проверенных лучшие эмбеддинги — у Voyage и Gemini.
3. Топ-20 чанков в промпте лучше, чем топ-10 или топ-5.
4. Контекст в чанках сильно повышает точность поиска.
5. Реранкинг лучше, чем без него.
6. Все эффекты складываются: контекстные эмбеддинги + контекстный BM25 + реранкинг + 20 чанков в промпте.

---

Часть 2. Demystifying evals for AI agents (январь 2026)

Почему агентов трудно оценивать

Хорошие эвалы позволяют уверенно выпускать агентов; без них команда застревает в «реактивных циклах»: узнаёт о проблемах только в продакшене и, исправляя одно, ломает другое. При этом те же свойства, что делают агентов полезными, — автономность, ум, гибкость — делают их трудными для оценки. Агент работает много ходов, меняет состояние среды, его ошибки накапливаются, а сильная модель может найти решение, которого авторы эвала не ждали. Пример из статьи: Claude Opus 4.5 решил задачу τ2-bench о бронировании авиабилета, найдя лазейку в правилах авиакомпании, — по букве эвала это «провал», хотя для пользователя решение было лучше.

Словарь эвала агента

Термин	Что это	Пример
Задача (task, test case)	один тест с входом и критериями успеха	«Исправь обход авторизации при пустом пароле»
Попытка (trial)	один прогон задачи; модели недетерминированы, поэтому попыток несколько	5 запусков одной задачи
Грейдер (grader)	логика, оценивающая какой-то аспект работы; у задачи может быть несколько грейдеров, в каждом — несколько проверок (assertions)	юнит-тесты + LLM-рубрика качества кода
Транскрипт (trace, trajectory)	полная запись попытки: выводы, вызовы инструментов, рассуждения	для Anthropic API — весь массив messages в конце прогона
Итог (outcome)	конечное состояние среды	агент сказал «билет забронирован» — а есть ли бронь в базе?
Обвязка эвала (evaluation harness)	инфраструктура, которая запускает задачи, записывает шаги, оценивает и сводит результаты	—
Обвязка агента (agent harness, scaffold)	система, которая делает из модели агента: обрабатывает вход, вызывает инструменты. Оценивая «агента», вы оцениваете обвязку и модель вместе	Claude Code, Agent SDK
Набор эвалов (evaluation suite)	задачи с общей целью	поддержка: возвраты, отмены, эскалации

Зачем вообще эвалы

Поначалу команды далеко продвигаются на ручном тестировании, использовании собственного продукта («dogfooding») и интуиции. Перелом наступает, когда пользователи жалуются, что «после изменений стало хуже», а команда «летит вслепую»: не может отличить настоящую регрессию от шума и проверить изменение на сотнях сценариев. Так было и с Claude Code: сначала быстрые итерации по отзывам, потом эвалы — сначала узкие (лаконичность, правки файлов), затем сложные (переусложнение кода).

Примеры из статьи: Descript (агент для монтажа видео) оценивает три измерения — «ничего не сломай», «сделай, что просили», «сделай хорошо» — и перешёл от ручной оценки к LLM-грейдерам с периодической калибровкой людьми; Bolt за три месяца построил систему со статическим анализом, браузерными агентами для проверки приложений и LLM-судьями.

Ещё польза эвалов: они заставляют договориться, что такое успех (два инженера по-разному поймут одну спецификацию пограничных случаев); позволяют за дни, а не недели перейти на новую модель; бесплатно дают базовые замеры задержки, токенов и цены; становятся самым ёмким каналом связи между продуктом и исследователями. Расходы видны сразу, а выгода накапливается позже — поэтому её легко недооценить.

Три типа грейдеров

Тип	Методы	Сильные стороны	Слабые стороны
Код	сравнение строк (точное, regex, нечёткое), тесты «падал → проходит» и «проходил → проходит», статический анализ, проверка итога и вызовов инструментов, анализ транскрипта (число ходов, токены)	быстро, дёшево, объективно, воспроизводимо, легко отлаживать	хрупкость к допустимым вариациям, мало нюансов, плохо для субъективного
Модель	оценка по рубрике, утверждения на естественном языке, попарное сравнение, сравнение с эталоном, консенсус нескольких судей	гибко, масштабируемо, ловит нюансы и свободный текст	недетерминированно, дороже кода, нужна калибровка по людям
Человек	ревью экспертом, краудсорсинг, выборочные проверки, A/B-тесты, согласие разметчиков	эталонное качество, служит для калибровки моделей-судей	дорого, медленно, нужны эксперты

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

Эвалы возможностей и регрессионные эвалы

• Эвалы возможностей («что агент умеет хорошо?») должны начинаться с низкой доли успеха — это «холм, на который карабкаются».
• Регрессионные эвалы («умеет ли он всё, что умел?») должны проходить почти на 100 %; падение — сигнал поломки.
• Когда эвал возможностей «выпускается» на высокий уровень, его задачи переходят в регрессионный набор: вопрос «можем ли мы это вообще?» превращается в «делаем ли мы это надёжно?».

Как оценивать разные виды агентов

Агенты для программирования. Естественны детерминированные грейдеры: запускается ли код, проходят ли тесты. Так устроены SWE-bench Verified (задачи из GitHub-репозиториев на Python; решение засчитывается, только если чинит падающие тесты и не ломает остальные; за год результаты моделей выросли с 40 % до более чем 80 %) и Terminal-Bench (сквозные технические задачи вроде сборки ядра Linux или обучения модели). Поверх тестов результата полезно оценивать и транскрипт: правила качества кода, LLM-рубрика о том, как агент пользуется инструментами и общается. В статье приведён иллюстративный YAML-файл задачи «исправить обход авторизации»: детерминированные тесты, LLM-рубрика, статический анализ (ruff, mypy, bandit), проверка записи в логе безопасности, проверка вызовов инструментов и метрики транскрипта и задержки. Авторы оговариваются: на практике обычно хватает юнит-тестов и рубрики качества кода.

Разговорные агенты (поддержка, продажи, коучинг). Качество самого общения — часть того, что оценивается, и часто нужна вторая модель, играющая пользователя. Успех многомерен: заявка закрыта (проверка состояния), уложились в 10 ходов (ограничение транскрипта), тон уместный (рубрика). Так устроены τ-Bench и τ2-Bench (поддержка магазина, бронирование билетов). Пример задачи: возврат денег раздражённому клиенту — проверяются эмпатия и ясность объяснения (рубрика), закрытая заявка и проведённый возврат (состояние), вызовы verify_identity, process_refund с суммой не больше 100, send_confirmation (инструменты).

Исследовательские агенты. Качество зависит от задачи: «полный» и «хорошо подкреплённый источниками» значат разное для обзора рынка и научного отчёта; эксперты могут не соглашаться, а эталон меняется вместе с вебом. Стратегия — сочетать грейдеры: обоснованность (утверждения подкреплены найденными источниками), покрытие (заданный список ключевых фактов), качество источников; для вопросов с точным ответом — точное совпадение. LLM-рубрики здесь нужно часто сверять с экспертами.

Агенты, управляющие компьютером (скриншоты, мышь, клавиатура). Оценка — в настоящей или изолированной среде по итоговому состоянию: WebArena проверяет URL, состояние страницы и бэкенда (заказ действительно оформлен, а не просто показана страница подтверждения), OSWorld — файловую систему, настройки приложений, содержимое баз. Отдельный компромисс — токены против задержки: работа через DOM быстрая, но дорогая по токенам, через скриншоты — медленнее, но экономнее. Для Claude for Chrome сделали эвалы, проверяющие, что агент выбирает подходящий способ.

Недетерминизм: pass@k и pass^k

У каждой задачи своя доля успеха (на одной 90 %, на другой 50 %), и задача, прошедшая в одном прогоне, может упасть в следующем. Две метрики:

• pass@k — вероятность, что хотя бы одна из $k$ попыток успешна. Растёт с $k$. Полезна, когда достаточно одного успеха (например, сгенерировать несколько решений и проверить тестами).
• pass^k — вероятность, что все $k$ попыток успешны. Падает с $k$. Важна для клиентских агентов, от которых ждут надёжности каждый раз.

Если вероятность успеха одной попытки $p$ и попытки независимы:

$$\text{pass@}k = 1 - (1-p)^k, \qquad \text{pass}^k = p^k .$$

Словами: pass@k — «единица минус вероятность провалить все $k$ раз»; pass^k — «вероятность выиграть $k$ раз подряд». Пример из статьи: при $p = 0{,}75$ и трёх попытках pass^3 $= 0{,}75^3 \approx 0{,}42$. Для сравнения (наш расчёт): pass@3 $= 1 - 0{,}25^3 \approx 0{,}98$. Одна и та же модель выглядит «почти идеальной» или «ненадёжной» — в зависимости от того, что спросить. При $k = 1$ метрики совпадают, при $k = 10$ рассказывают противоположное: pass@k стремится к 100 %, pass^k — к 0 %. (Как оценивать pass@k по $n$ попыткам без смещения — урок 7.3.2.)

Дорожная карта: от нуля к эвалам, которым можно доверять

flowchart LR
S0["0. Начать рано"] --> S1["1. Ручные проверки и баги → задачи"] --> S2["2. Однозначные задачи + эталонные решения"] --> S3["3. Сбалансированный набор"]
S3 --> S4["4. Стабильная изолированная среда"] --> S5["5. Продуманные грейдеры"]
S5 --> S6["6. Читать транскрипты"] --> S7["7. Следить за насыщением"] --> S8["8. Поддерживать набор живым"]

Восемь шагов из статьи (наша схема)

Собрать задачи.

• Шаг 0. Начните рано. Хватит 20–50 простых задач из реальных провалов: в начале разработки эффекты изменений велики, и маленькой выборки достаточно. Чем дольше ждать, тем труднее: потом приходится «восстанавливать» критерии успеха по живой системе.
• Шаг 1. Начните с того, что уже проверяете руками: проверки перед выпуском, частые действия пользователей, баг-трекер и очередь поддержки. Приоритет — по влиянию на пользователей.
• Шаг 2. Однозначные задачи с эталонным решением. Хорошая задача — та, по которой два эксперта независимо вынесут одинаковый вердикт. Всё, что проверяет грейдер, должно следовать из условия. Пример: аудит Terminal-Bench нашёл задачу, где просили написать скрипт, не указав путь, а тесты ждали конкретный путь, — агент проваливался не по своей вине. Для сильных моделей 0 % успеха за много попыток (pass@100 = 0) чаще означает сломанную задачу, а не слабого агента. Эталонное решение доказывает, что задача решаема и грейдеры настроены верно.
• Шаг 3. Сбалансированный набор. Проверяйте и случаи, где поведение должно проявиться, и где не должно. Односторонний эвал даёт одностороннюю оптимизацию: если проверять только «ищет ли агент, когда нужно», получится агент, который ищет всегда. Так было с веб-поиском в Claude.ai: понадобились запросы обоих видов («какая погода» — искать; «кто основал Apple» — не искать) и много раундов правки, чтобы найти баланс между недо- и пересрабатыванием.

Обвязка и грейдеры.

• Шаг 4. Стабильная среда. Агент в эвале должен работать примерно как в продакшене, а каждая попытка — начинаться в чистой среде. Общие остатки (файлы, кэш, исчерпанные ресурсы) дают коррелированные сбои из-за инфраструктуры — или завышают результат: во внутренних эвалах Claude получал нечестное преимущество, заглядывая в git-историю предыдущих попыток. Попытки, упавшие из-за одной общей причины (например, нехватки памяти), не независимы.
• Шаг 5. Продуманные грейдеры. Детерминированные — где можно, LLM — где нужно, люди — для дополнительной проверки. Не проверяйте жёсткую последовательность вызовов инструментов: агенты находят верные пути, которых вы не ждали, — оценивайте результат, а не путь. Давайте частичный зачёт: агент, который понял проблему и проверил клиента, но не провёл возврат, лучше того, что упал сразу. LLM-судей калибруйте по экспертам; давайте судье «выход» — ответ «Неизвестно», если данных мало; оценивайте каждое измерение рубрики отдельным вызовом судьи. Ищите ошибки в самих эвалах: Opus 4.5 сначала набрал 42 % на CORE-Bench, пока исследователь Anthropic не нашёл жёсткую проверку (отклонялось «96.12» при ожидаемом «96.124991…»), двусмысленные условия и невоспроизводимые случайные задачи; после исправлений и с менее стеснённой обвязкой — 95 %. METR нашёл в своём бенчмарке задачи, где просили достичь порога, а проверка требовала его превысить, — так наказывались модели, честно следовавшие инструкции. И делайте грейдеры устойчивыми к «читерству»: пройти задачу должно быть можно только решив её.

Поддерживать эвал.

• Шаг 6. Читайте транскрипты. Только так понятно, ошибся агент или грейдер отверг верное решение. Провалы должны выглядеть «честными». В Anthropic есть инструменты для просмотра транскриптов, и их регулярно читают.
• Шаг 7. Следите за насыщением. Эвал на 100 % ловит регрессии, но ничего не говорит об улучшениях. При приближении к насыщению большой рост возможностей выглядит как маленький рост баллов. Пример: стартап Qodo сначала не впечатлился Opus 4.5, потому что их «одношаговые» эвалы не видели прогресса на длинных задачах, — пришлось сделать агентный эвал. Правило Anthropic: не верить баллам, пока кто-то не разобрался в деталях и не прочитал транскрипты.
• Шаг 8. Держите набор живым. Эвал — «живой артефакт» с владельцем. Лучше всего сработало: выделенная команда отвечает за инфраструктуру, а задачи пишут и запускают эксперты предметной области и продуктовые команды. Практикуйте разработку от эвалов (eval-driven development): сначала эвал желаемой возможности, потом агент. Задачу для эвала может предложить даже менеджер продукта — через пулл-реквест с помощью Claude Code.

Эвалы среди других методов

Метод	Плюсы	Минусы
Автоматические эвалы	быстро, воспроизводимо, без риска для пользователей, на каждый коммит	нужны вложения и поддержка; ложная уверенность, если не похожи на реальность
Мониторинг продакшена	реальное поведение в масштабе	реактивно: пользователи увидят проблему первыми; шумно; нет эталона
A/B-тесты	реальные исходы (удержание, выполнение задач)	медленно, нужен трафик, мало объясняют «почему»
Отзывы пользователей	неожиданные проблемы на настоящих примерах	редкие, смещены к серьёзным сбоям, без объяснений
Ручное чтение транскриптов	интуиция о провалах, тонкие проблемы	дорого по времени, не масштабируется
Систематические исследования с людьми	эталонные суждения, субъективные задачи, калибровка судей	дорого и медленно, разногласия разметчиков

Ни один слой не ловит всё — как в «модели швейцарского сыра» из инженерии безопасности: дыры одного слоя закрывает другой. Автоматические эвалы — первая линия обороны до выпуска и в CI/CD; мониторинг — после выпуска (дрейф, неожиданные сбои); A/B — для крупных изменений; отзывы и транскрипты — постоянно (например, читать выборку транскриптов каждую неделю); исследования с людьми — для калибровки LLM-судей.

В приложении перечислены фреймворки: Harbor (агенты в контейнерах, через него распространяется Terminal-Bench 2.0), Braintrust, LangSmith, Langfuse (открытая альтернатива с самостоятельным размещением), Arize Phoenix. Совет: быстро выбрать подходящий и вкладывать силы в сами задачи и грейдеры — фреймворк хорош ровно настолько, насколько хороши эвалы, которые через него идут.

Что сделать руками

1. Contextual Retrieval в миниатюре. Возьмите свой RAG из практики урока 8.2.2, 3–5 длинных документов и 20 вопросов. Для каждого чанка попросите локальную модель написать 1–2 предложения контекста по документу и сравните recall@5 до и после — отдельно для эмбеддингов, BM25 и гибрида.
2. pass@k и pass^k. Прогоните своего агента 5 раз на 10 задачах и посчитайте обе метрики для $k = 1, 3, 5$. Совпадает ли pass^k с формулой $p^k$? Если нет — какие задачи «коррелированы»?
3. Аудит своего эвала по шагам 2–5. Найдите в своём наборе задачу без однозначного эталона, задачу, где путь проверяется вместо результата, и задачу, которую можно пройти «читерством». Исправьте.

Словарик

EN	RU
contextual embeddings / contextual BM25	контекстные эмбеддинги / контекстный BM25
retrieval failure rate, 1 − recall@20	доля неудачных поисков, 1 − полнота@20
rank fusion	слияние рангов
reranker	реранкер, переранжировщик
prompt caching	кэширование промптов
task / trial / grader / transcript / outcome	задача / попытка / грейдер / транскрипт / итог (конечное состояние)
evaluation harness / agent harness (scaffold)	обвязка эвала / обвязка агента
capability eval / regression eval	эвал возможностей / регрессионный эвал
pass@k / pass^k	хотя бы один успех из k / все k успешны
partial credit	частичный зачёт
eval saturation	насыщение эвала
eval-driven development	разработка от эвалов
Swiss cheese model	модель швейцарского сыра