Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Языковой агент научился добавлять себе новые вычислительные навыки без размеченных ответов и модели-оценщика. В препринте PayPal AI, который не рецензировали и где числа получили сами авторы, проверяющий шлюз отклонил все 138 ошибочных вариантов операторов. Для систем с точными расчётами это предлагает иной план: не доверять самооценке модели, а ограничить её проверяемым языком и принимать расширения только по исполнимым правилам.
Новый оператор проверяют через независимый код и законы сохранения
Агент отвечает на вопросы не текстом, а выражением на небольшом предметно-ориентированном языке (DSL). Выражение исполняет изолированный интерпретатор, который разрешает только зарегистрированные функции, запрещает произвольные вызовы и возвращает число. Поэтому итог зависит от проверяемого кода, а не от того, насколько убедительно модель объяснила расчёт.
Система работает в двух циклах. Во внутреннем цикле модель придумывает вопрос и выражение для ответа, а затем независимо пишет второе выражение, имея перед собой только вопрос. Ответ принимают, если оба варианта дают одинаковое значение на каждой проверочной записи и вычисляют новую величину.
Этот цикл находит новые сочетания уже доступных функций, но не расширяет возможности языка. Например, если в DSL есть только операции над всей таблицей, из них нельзя составить сумму по каждому покупателю. Повторяющиеся запросы такого рода внешний цикл считает пробелом и предлагает новый оператор.
Оператор пишут двумя независимыми способами. Реализации должны совпасть на проверочных данных, после чего результат проверяют через свойства уже доверенных функций. Для суммы по группам действует закон сохранения: суммы внутри групп после сложения должны дать общую сумму по таблице. Дополнительно проверяют количество групп, пустой ввод, повторяющиеся ключи и перестановку записей.
Прошедший шлюз оператор попадает в библиотеку, и внутренний цикл снова ищет вопросы, которые теперь можно выразить. Модель при этом остаётся замороженной: её не дообучают и не меняют веса. Растёт только словарь небольших функций, которые можно отдельно исполнить и проверить.
Такой допуск не равен математическому доказательству. Две реализации сравнивают на конечном наборе данных, а законы сохранения покрывают только сформулированные свойства. Шлюз даёт целевую проверку против известных классов ошибок, но общий дефект в двух реализациях может остаться незамеченным.
Проверяемый шлюз расширил набор точных вычислений
В непрерывном запуске на таблицах транзакций набор доступных типов вопросов вырос с 10 до 336. На BookSQL, где вопросы относятся к бухгалтерским записям, покрытие увеличилось более чем десятикратно, а на клиническом наборе EHRSQL — почти двадцатикратно. Для переноса между областями потребовалось адаптировать разбор схемы, но не сам механизм допуска.
Добавленные операторы не лежали без дела. Агент использовал их для сумм и количества по группам, фильтрации, пороговых вычислений и производных статистик. Контрольный запуск без добавления операторов продолжал комбинировать прежние функции, но не смог выразить вычисления, которым требовалась новая групповая операция.
Отдельный программный эталон подтвердил результаты для точных вычислительных типов. Систематическое расхождение возникло в вопросах о самом загруженном дне или часе: при равенстве счётчиков эталон выбирал вариант по денежному обороту, а DSL — первый встретившийся. Эта деталь показывает границу слова «точно»: код может исполняться без ошибки, но правила разрешения ничьей всё равно нужно задавать явно.
Проверки охватывали синтетические транзакции, BookSQL и клинические записи MIMIC-III. Во всех случаях агент работал с последовательностями табличных записей и вопросами, которые сводятся к точному программному вычислению. Перенос между несколькими семействами моделей сохранил строгость шлюза, однако способность написать проходящий проверку оператор зависела от того, насколько хорошо конкретная модель владела DSL.
Подход меняет архитектуру систем с проверяемыми расчётами
Работа меняет планы команд, которые строят агентов для бухгалтерии, платежей, аналитики или медицинских записей. Вместо большого набора размеченных вопросов можно заложить небольшой язык, доверенный интерпретатор, библиотеку операторов и предметные законы: баланс сходится, части дают целое, перестановка строк не меняет результат.
Это не замена обычному агенту для открытого поиска, написания текста или работы с произвольными инструментами. Метод требует узкой среды, где ответ имеет точную программную семантику, а для новой операции можно сформулировать проверяемое свойство. Возможность, которая выходит за пределы песочницы, агент сам не добавит без явного расширения доверенной основы.
В проектировании также придётся разделить пути генерации. Если один контекст подсказывает обе реализации, они легче повторят одну ошибку. Раздельные вызовы или разные семейства моделей снижают эту зависимость, но не превращают эмпирическую проверку в доказательство.
Практический вывод состоит не в том, что библиотеку можно бесконтрольно отдать модели. Работа показывает более узкую схему: агент предлагает расширение, а архитектура решает, какие свойства оно обязано сохранить. Такой контур позволяет автоматизировать поиск недостающих операций, не делая модель окончательным судьёй собственной корректности.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
