Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Агентный ИИ научились проверять не только на качество ответа, но и на умение вовремя передать задачу человеку. Dipankar Sarkar из Skelf Research собрал RegLLM; в препринте, который пока не прошёл рецензирование и приводит числа, полученные самим автором, два номинально одинаковых запуска дали противоположную оценку одной настройке. Для регулируемых процессов это сдвигает приоритет с выбора способа дообучения на разметку эскалаций, повторяемые испытания и независимую защиту во время работы.
Решение «ответить или передать человеку» стало проверяемым
В центре RegLLM находится метка для каждого задания: должен агент выполнить его сам или передать специалисту. Благодаря ей эскалацию можно оценивать так же, как правильность формата или существование указанного источника, а затем использовать результат при обучении.
Система разделяет шесть показателей по способу проверки. Код проверяет ссылки, соответствие ответа схеме и связь ответа с источником. Метка задания показывает, правильно ли агент выбрал между ответом и эскалацией. Отдельная модель-оценщик сопоставляет ответ с правилами предметной области.
Такое разделение важно для аудита. Проверка схемы воспроизводится без участия модели, а оценка по правилам зависит от выбранной модели-оценщика. Метка эскалации выглядит однозначной только после того, как эксперты договорились, какие запросы выходят за пределы полномочий агента.
Один набор правил используется сразу в трёх местах. Он задаёт оценку ответа при испытаниях, участвует в награде для обучения и управляет защитным слоем во время работы. Агент при этом ищет положения в нормативном корпусе, прикрепляет ссылки, отвечает либо вызывает эскалацию; каждый шаг остаётся в журнале, куда можно только добавлять записи.
Защитный слой работает вне LLM и поэтому не зависит от того, усвоила ли модель правила. Он блокирует ответ без подтверждающего положения, передаёт задачу человеку при выходе за границы компетенции и записывает правило, которое вызвало вмешательство. Обучение снижает частоту ошибок, а этот слой перехватывает оставшиеся.
Малый пилот спутал эффект обучения с разбросом
RegLLM проверяли на задачах по UK FCA Handbook: часть требовала ответа по нормативному корпусу, часть — эскалации запросов о налоговых схемах, юридических заключениях, гарантиях и несуществующих положениях. Метки создали из шаблонов без привлечения специалистов по комплаенсу. В пилотах Qwen2.5-3B оценивали на восьми заданиях с одной и той же выборкой и начальным значением генератора случайных чисел.
На простой офлайн-базе защитный слой поднял полноту эскалации — долю корректно переданных человеку заданий — с 0 до 67%. Доля опасных действий, дошедших до результата, снизилась с 33% до 8%. Это показывает, что жёсткие правила могут компенсировать слабую способность базового агента отказываться от неподходящей задачи.
Дообучение по предпочтениям дало менее устойчивую картину. В одном запуске настройка на качество ответа ухудшила эскалацию, а в другом улучшила её. Вариант, специально обученный выбирать эскалацию, не изменил результат второго запуска.
Код, модель, выборка и гиперпараметры совпадали, но образы контейнеров, микроверсии библиотек и детерминированные настройки CUDA не зафиксировали. Поэтому эффект адаптера нельзя отделить от различий вычислительной среды и случайности малой проверки.
Защитный слой в GPU-пилотах также не сработал. Модель прикрепляла положение к каждому завершённому ответу и тем самым проходила проверку наличия ссылки, а ошибочные траектории часто не доходили до ответа, который мог проверить надзорный компонент. Одного запрета на ответы без источника недостаточно: границу компетенции нужно проверять до завершения сценария.
Архитектуру стоит менять раньше, чем выбирать способ дообучения
Работа не даёт готовую систему для финансового комплаенса, но предлагает полезное разделение ответственности. Модель решает задачу, проверяемые правила контролируют формальные свойства, модель-оценщик разбирает неоднозначные принципы, а внешний надзор останавливает действия, которые нельзя выпускать в процесс.
Для команды первым артефактом становится не адаптер, а набор размеченных сценариев эскалации. Их должны составлять профильные специалисты: ошибка в такой метке напрямую учит агента действовать там, где требовался человек. При изменении нормативов эти метки придётся версионировать вместе с корпусом и правилами.
Второе изменение касается испытаний. Один запуск на малой выборке не подходит для решения, улучшило ли дообучение ограниченную автономию. Нужны повторные запуски, более крупный набор заданий и полностью зафиксированная вычислительная среда; иначе команда может принять разброс за эффект настройки.
Третье изменение относится к рабочему контуру. Проверка наличия ссылки полезна, но агент может сослаться на положение и всё равно взяться за задачу вне своей компетенции. Надзор должен отдельно распознавать такие запросы, принудительно вызывать специалиста и сохранять причину вмешательства в аудиторском журнале.
RegLLM поэтому меняет планы на уровне архитектуры, а не выбора модели. Конституцию предметной области, нормативный корпус и экспертные метки всё равно придётся создавать для конкретного процесса. Дообучение можно добавлять после того, как команда умеет измерять решение об эскалации и перехватывать его ошибки независимо от LLM.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
