Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
ИИ-агенты стали чаще создавать инженерные артефакты, которые одновременно проходят все формальные проверки. В препринте University of Washington и партнёров, который не прошёл рецензирование и основан на замерах самих авторов, контракт RAC поднял долю корректных результатов на задачах с печатными платами с 74,0% до 90,9%. Для продуктовой архитектуры это аргумент не в пользу очередной смены модели, а в пользу новой границы между моделью и инженерными инструментами.
Агент выбирает отношения, инструмент вычисляет последствия
Обычный инженерный агент часто выполняет две разные работы. Сначала он понимает требование: например, конденсатор должен находиться рядом с обслуживаемой микросхемой. Затем сам рассчитывает координаты, зазоры и трассы, хотя эти величины можно получить механически.
RAC разделяет эти обязанности. Агент видит точное состояние проекта, но в действии указывает отношения между именованными объектами: разместить компонент рядом с другим, выровнять группу, избежать области, согласовать длины трасс или назначить операции в определённом порядке. Координаты и временные метки в его ответ не входят.
Специализированный решатель принимает весь набор отношений сразу и строит конкретный артефакт. Совместная обработка здесь существенна: последовательное выполнение команд может исправить одно ограничение и одновременно нарушить другое. Для печатной платы перемещение компонента влияет на зазоры, доступность трасс и близость связанных элементов.
Полученный результат проверяет отдельный модуль, который не доверяет внутренним отметкам решателя. Он заново проверяет правила проектирования и отношения, выбранные агентом. Если результат не проходит проверку, агент получает не общий сигнал об ошибке, а конфликтующие ограничения, величину нарушения и допустимые способы исправления.
Такой цикл сохраняет за моделью инженерный выбор, но не заставляет её воспроизводить вычисления, для которых уже существуют детерминированные алгоритмы. Переобучать модель для этого не требуется: RAC задаёт контракт действий, наблюдений, проверки и обратной связи.
Разрыв проявился и в геометрии, и в расписаниях
На наборе из 98 задач с печатными платами проверяли размещение, трассировку, их сочетание и ремонт существующего проекта. RAC показал лучший результат с каждой выбранной моделью. Доступ к Python не спас прямую генерацию координат, а выбор среди готовых геометрических вариантов уступил действиям через отношения.
Эффект сохранился при смене агентной среды. Разные среды заметно меняли расход токенов, но RAC в каждой из них чаще проходил проверки и требовал меньше токенов, чем прямое управление координатами. Значит, выигрыш связан не только с конкретной обвязкой или подсказкой модели.
В производственных расписаниях агент задавал приоритеты и отношения между операциями, а решатель вычислял время их начала. Доля расписаний, которые прошли независимую проверку и уложились в порог качества, выросла с 59,6% при передаче действий через код до 96,3% при прямой передаче отношений. Обоим вариантам был доступен один и тот же планировщик, поэтому сравнение выделяет именно формат действий.
Когда RAC меняет архитектуру продукта
Работа меняет планы команды, если агент сейчас выдаёт значения, которые можно однозначно вычислить из его смыслового решения: координаты, временные метки, пути, зазоры или аппаратно-зависимые параметры. В таком продукте стоит проектировать не более подробный запрос к модели, а предметную схему отношений и инструмент, который превращает их в готовый результат.
Минимальная архитектура включает авторитетное представление текущего состояния, ограниченный набор смысловых действий, воспроизводимый решатель, независимую проверку и структурированные сведения для ремонта. Особенно важно не давать агенту обходить эту границу и подставлять конкретные величины там, где их способен вывести инструмент.
Масштаб проверки задаёт границы вывода. Сравнение охватило девять моделей, производственные расписания из 30 публичных задач и 141 задачу для четырёх микроконтроллеров. Это несколько разных инженерных областей, но не доказательство того, что тот же контракт автоматически сработает в любой системе с инструментами.
RAC применим только там, где команда может построить решатель и независимый проверяющий модуль. Требования также должны сводиться к проверяемым условиям: расплывчатое пожелание без формального критерия контракт обработать не сможет. Поэтому основная стоимость переходит из настройки подсказок в разработку предметных инструментов и полноту проверок.
Практический вывод узкий: если механические последствия уже умеет считать обычный алгоритм, их не следует поручать LLM. Модель полезнее на границе, где нужно понять требование и выбрать отношения между объектами; всё, что однозначно следует из этого выбора, надёжнее вычислять и проверять отдельно.
Источники
Иллюстрация: рисунок из статьи «RAC: A Relational Agent Contract for Constraint-Governed Engineering Tasks», Kaiyuan Zheng, Fengqing Jiang, Yichen Feng и др., CC BY 4.0
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
