TL;DR
Статья предлагает принимать работу агента слоями, а не по одному тесту. Слои такие: соответствие правилам сборки, значения параметров, поведение на данных, физический инвариант (закон, который должен выполняться всегда) и сверка отчёта агента с его же файлом. Агента посадили в роль поставщика: заказчик даёт описание устройства и замеры, поставщик возвращает модель и отчёт. Модели собирали на языке Modelica из готовых библиотечных компонентов. Приёмка пересчитывала ошибки сама, а не верила отчёту.
Главная находка: совпадение с данными ничего не гарантирует про внутреннюю структуру. Одна из принятых моделей совпадала с замерами на уровне шума, но создавала энергию из ничего: на входе 32,9 кДж, на выходе 62,1 кДж. Агент разбил одну физическую константу на две и подогнал их по отдельности. Замеры такой подлог не выдают, потому что модель их воспроизводит. Вторая беда ещё обиднее: большинство провалов — это сдача работы, которая не проходит порог на собственных данных агента. Уровень шума был написан в задании, проверка занимает одно деление, а в половине случаев агент сам называл отклонение в отчёте и всё равно сдавал модель.
Лекарство простое: написать критерий приёмки прямо в задании и потребовать сверки с ним перед сдачей. В дополнительном эксперименте агенты начали сравнивать результат с порогом, и больше работ прошло приёмку. Отдельно заказчик добавляет проверки, которые нельзя вывести из поведения: закон сохранения, соответствие отчёта файлу, чтение структуры экспертом.
Схема метода
ЗАДАНИЕ (одним документом):
описание + данные + уровень шума + КРИТЕРИЙ ПРИЁМКИ (порог)
+ что строить из чего + что запрещено
АГЕНТ СДАЁТ ПАКЕТ:
файл модели | стартовые значения и границы | подогнанные значения
| ошибки по КАЖДОМУ эксперименту | допущения и неопределённости
ПРИЁМКА СЛОЯМИ (проверяет заказчик, не отчёт):
СЛОЙ 1: соответствие правилам (разрешённые компоненты)
СЛОЙ 2: параметры (сверка с паспортом, если есть)
СЛОЙ 3: поведение (пересчёт ошибок на данных, включая скрытые)
СЛОЙ 4: физический инвариант (баланс энергии/денег/массы)
СЛОЙ 5: отчёт против файла (заявленное = реальное?)
+ выборочно: чтение структуры экспертом (можно ли адаптировать под вариант)
Задание и сдача — это отдельные запросы к агенту. Слои 4–5 можно поручить второму чату или второму агенту как независимую проверку.
Пример применения
Метод сильнее всего там, где у системы есть закон, который обязан выполняться (баланс, сохранение), а подгонка по данным может его тихо нарушить. Типовой случай для читателя — финансовые и операционные модели.
Задача: селлер на Wildberries просит Claude Code построить модель юнит-экономики по выгрузке за 6 месяцев: выручка, комиссия, логистика, возвраты, хранение, реклама. Агент должен подогнать коэффициенты (доля возвратов, средняя логистика на единицу) под реальные цифры. Опасность: агент добавит «корректирующий коэффициент», который закроет расхождение, но выдуманные деньги появятся из ниоткуда.
Промпт:
Построй модель юнит-экономики моего магазина на Wildberries по файлу sales_6m.xlsx
(выручка, комиссия WB, логистика, возвраты, хранение, реклама, по неделям).
КРИТЕРИЙ ПРИЁМКИ (проверю сам, пересчитаю по твоему файлу):
- Недельная ошибка по чистой прибыли не больше 3% на каждой из недель 1–20.
- Недели 21–26 НЕ используй для подбора. На них только проверка, ошибку на них сообщи отдельно.
- Шум в данных: учёт у меня ведётся с точностью до ~1% по каждой статье.
ИНВАРИАНТ (должен выполняться всегда):
- Выручка = комиссия + логистика + возвраты + хранение + реклама + себестоимость + прибыль.
Ни одна статья не может появиться «из ниоткуда». Ни один рубль не может исчезнуть.
ЗАПРЕЩЕНО:
- Свободные «поправочные коэффициенты», «прочие расходы» и любые параметры,
которым нельзя дать бизнес-смысл (ставка комиссии, доля возвратов, тариф логистики).
- Подбирать две величины раздельно, если по смыслу это одна
(например, комиссия в двух местах).
ПЕРЕД СДАЧЕЙ:
1. Посчитай ошибку по каждой неделе подбора.
2. Сравни с порогом 3%. Если где-то выше — не сдавай, найди причину и исправь структуру, а не просто подгони числа.
3. Проверь баланс инварианта на каждой неделе.
ФОРМАТ СДАЧИ:
файл модели; стартовые значения и границы параметров; подобранные значения;
ошибки по каждой неделе; допущения; где данные не определяют параметр или возможны
несколько объяснений — скажи прямо.
Результат: агент вернёт файл модели и отчёт с таблицей ошибок по неделям. Он должен явно сравнить эту таблицу с порогом и либо исправить структуру, либо честно написать «не прошёл на неделях N, M». В отчёте будет список допущений и пометки о параметрах, которые данные не определяют (например, «хранение и возвраты частично взаимозаменяемы»). Баланс по статьям он проверит и покажет. После этого вы выбираете 2–3 параметра и сверяете их с реальными тарифами WB, чтобы убедиться, что они несут бизнес-смысл.
Почему это работает
Слабость LLM. Агент и исполнитель, и проверяющий одновременно. Если критерий не назван, «достаточно близко» агент решает сам. Он видит невязку, называет её в отчёте и всё равно сдаёт. Дело не в незнании: числа и шум у него есть, он просто не сравнил их с порогом. К тому же поведение на данных не фиксирует структуру: подойдёт много разных моделей, включая нефизичные.
Сильная сторона LLM. Если порог и правило сверки лежат в тексте задания, агент их выполняет. Он умеет посчитать ошибку по каждому эксперименту, сравнить с числом и перестроить структуру. Он также неплохо знает, как устроены устройства. Не хватает явного критерия и внешнего контроля.
Как метод это использует. Критерий приёмки переносится из головы заказчика в задание, поэтому «достаточно близко» перестаёт быть решением агента. Инвариант и сверка отчёта с файлом ловят то, что поведение скрывает. Приёмка в статье пересчитывает всё сама и поэтому не зависит от слов агента.
Рычаги управления: - Порог → ужесточай или смягчай под задачу. Главное, чтобы он был числом и стоял в тексте задания. - Скрытые данные → оставь часть данных агенту невидимой и проверяй на ней. Видимый отложенный набор агент может случайно подогнать. - Запретный список → чем конкретнее запрещённые конструкции («свободные коэффициенты»), тем меньше «подгонки без смысла». - Требование отчёта о неопределённости → заставляет агента назвать, что данные не определяют. Раньше он молчал. - Независимая проверка → слои 4–5 отдай другому чату, который видит только файл и отчёт.
Шаблон промпта
Задача: {что_построить}.
Данные: {источник_данных}. Точность/шум данных: {уровень_шума}.
КРИТЕРИЙ ПРИЁМКИ (проверю сам по твоему файлу):
- Ошибка по {метрика} не больше {порог} на каждом из наборов {наборы_для_подбора}.
- Набор {контрольный_набор} не использовать для подбора. Ошибку на нём сообщить отдельно.
ИНВАРИАНТ (должен выполняться всегда):
- {закон_или_баланс}.
СТРОИТЬ ИЗ: {разрешённые_компоненты}.
ЗАПРЕЩЕНО: {запрещённые_конструкции}.
Параметры должны иметь смысл свойства объекта: {как_проверить_смысл}.
ПЕРЕД СДАЧЕЙ:
1. Посчитай ошибку на каждом наборе подбора.
2. Сравни с порогом. Если выше — не сдавай. Найди причину и исправь структуру, не только числа.
3. Проверь инвариант.
ФОРМАТ СДАЧИ:
- Файл модели {формат_файла}
- Стартовые значения и границы параметров
- Подобранные значения
- Ошибки на каждом наборе
- Допущения, включая всё, что добавлено сверх описания
- Если возможны несколько структур или параметр не определяется данными — скажи прямо.
Подставляйте конкретные числа, метрику, закон сохранения и список запретов. Общий порядок оставьте: критерий → инвариант → запреты → самопроверка → формат сдачи.
🚀 Быстрый старт — вставь в чат:
Вот шаблон приёмки работы агента. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, какие у тебя данные, какой точности, что должно выполняться всегда (баланс, сумма долей, сохранение) и что запрещено. Это нужно, чтобы вписать в задание числовой порог, инвариант и запретные конструкции. Из них собирается приёмка.
Ограничения
⚠️ Узкая область эксперимента: все проверки сделаны на физических моделях в Modelica. Перенос на финансы, аналитику и другие модели — вывод авторов, он напрямую не проверен.
⚠️ Нужен инвариант: слой 4 работает, только если у системы есть закон, который можно проверить (энергия, баланс, сумма долей). Если такого закона нет, этот слой пропадает.
⚠️ Порог помогает не всем: в дополнительном эксперименте часть работ всё равно не прошла. Улучшение связано с тем, как агент восстанавливает входной сигнал, и порог сам по себе проблему не снимает.
⚠️ Чтение экспертом дорого: проверка «можно ли адаптировать модель под вариант» требует времени человека, который знает и устройство, и модель. Поведенческие тесты её не заменяют.
⚠️ Отчёту доверять нельзя: слова агента о качестве — заявление, а не доказательство. Проверка всегда идёт по файлу.
⚠️ Часть эффектов зависит от конфигурации: надёжно справились только две конфигурации из шестнадцати, почти половина моделей не дошла до уровня шума. Оценивать нужно связку модель + оболочка и по нескольким запускам, одна удачная попытка ничего не доказывает.
Как исследовали
Идея была в том, чтобы повторить обычную закупку: заказчик передаёт описание и данные, поставщик возвращает модель и отчёт, приёмка идёт по согласованной точности. Поставщиками стали 16 языковых моделей в трёх популярных оболочках для кодинг-агентов. Их сравнивали как конфигурации на повторных запусках, потому что надёжного поставщика от удачливого по одному прогону не отличить. Систем было пять: три учебных с известным ответом, привод «аккумулятор → двигатель → нагрузка» с двумя допустимыми объяснениями потерь и реальный переключающий магнит из лаборатории без эталонной модели.
Приёмка проверяла каждую сдачу слоями. Автор не сверял с единственным эталоном, а принимал по принадлежности к множеству допустимых моделей. Каждая новая проверка возникала после реальной сдачи, которую прежние проверки пропустили или оценили неправильно.
Результаты оказались неожиданными. Задача решаема: две конфигурации прошли первые четыре задачи в каждом запуске, а самая маленькая открытая модель выдала проверяемую модель магнита после подробного брифа. Но среди прошедших приёмку моделей привода нашлось не менее тринадцати разных сборок. Одна создавала энергию: невязка 1,03 от шума, на пяти скрытых экспериментах всё сходится, а баланс мощности на узле даёт 1,885. Для практики это значит, что поведение ничего не говорит о структуре, и закон сохранения нужно проверять напрямую.
Ещё один результат: из 48 соответствующих правилам запусков, провалившихся по поведению, 46 не были провалами обобщения. 40 из них не проходили порог уже на данных, по которым агент подбирал параметры, хотя шум был назван в задании, а проверка занимает одно деление. Все эти запуски принадлежат моделям, которые на другой задаче доходили до уровня шума. Они умели, но не сверились. В дополнительном эксперименте порог в тексте задания заставил агентов сравнивать результат с ним, и больше сдач прошло приёмку.
Адаптации и экстраполяции
🔧 Техника: добавить сверку «отчёт против файла» → ловить расхождение между словами и делом
Отдельным запросом (другой чат, свежий контекст) отдай проверяющему только файл и отчёт:
Ниже файл модели и отчёт агента. Не доверяй отчёту. Пересчитай ошибки по файлу сам.
Найди все расхождения: заявленные допущения, которых нет в файле; параметры в отчёте, отличающиеся от файла;
добавленные механизмы, не отражённые в допущениях. Выведи таблицу «заявлено / фактически».
🔧 Техника: потребовать «если не прошёл порог — так и напиши» → превратить молчаливый брак в явный недобор
Добавь в задание: «Если ошибка выше порога, не сдавай как готовое. Напиши: не достигнут порог на {набор}, причина — {гипотеза}». В статье такой критерий превращает сдачу выше порога в заявленный недобор.
Экстраполяция — в файл инструкций агента (CLAUDE.md / AGENTS.md):
## Правила сдачи расчётных работ - Любой критерий качества из задания проверяй числом перед сдачей и показывай сверку. - Контрольные данные в подборе не используй. - Параметры без бизнес-/физического смысла («поправка», «прочее») не вводи без явной пометки в допущениях. - Если данные не определяют параметр, или подходит несколько структур, пиши об этом в отчёте. - Прежде чем сказать «готово», пересчитай инвариант {инвариант_проекта}.Это перенос принципа статьи на постоянные инструкции агента. Прямой проверки авторы не делали.
Ресурсы
- Название: LLM Agents as Suppliers of Physical System Models: Calibration and Acceptance in Modelica, препринт
- Авторы: Jörg Frochte, Herbert Schmidt, Bochum University of Applied Sciences
- Упомянутое: язык Modelica и его стандартная библиотека; руководства по валидации моделирования ASME V&V 10 и NAFEMS; недоопределённость (underspecification) в машинном обучении (D'Amour et al.); близкая работа об агентах, строящих модели Modelica