Что платформа делает, когда результат шага не годится

Что самокоррекцией не считается

Границу между самокоррекцией и отказоустойчивостью проводим сразу, иначе при сравнении платформ один и тот же механизм легко засчитать дважды. К отказоустойчивости мы относим такие случаи:

• Повтор того же вызова после сетевой ошибки (с нарастающей паузой).
• Переключение на резервное развертывание той же LLM, когда ее поставщик не отвечает.
• Откат уже сделанных действий, когда задача не дошла до конца.

Все это в платформе есть. Платформа в этих случаях повторяет то же самое или отменяет сделанное. По-другому она не пробует.

Механизмы, которыми платформа меняет подход

Список механизмов закрыт.

Последняя строка отличает агентский шаг от обычного. У обычного шага обращения к системе заказчика отказ системы заканчивает попытку. Платформа повторяет шаг новой попыткой в объявленных пределах, а когда попытки кончились, задача уходит контролеру. У агентского шага отказ инструмента становится наблюдением. LLM видит, что инструмент не ответил, и решает, что делать на следующем проходе.

Как устроена проверка качества

Проверку выполняет модель-оценщик. Это отдельная LLM, которой платформа показывает результат шага и определение метрики из справочника метрик качества платформы (например, отвечает ли текст на исходный вопрос). Задание исходного шага она не видит. Метрика и порог объявлены в описании задачи. Если оценка результата ниже порога, шаг уходит в ремонт с разбором от модели-оценщика, а на повторе меняется вариант задания и, если объявлено, класс LLM. Число ремонтов ограничено сверху настройкой установки, а описание задачи может это число только уменьшить.

Пример с нашего стенда. В маршруте ответа на отзыв покупателя проверяется, отвечает ли текст на сам отзыв. Ответ, который прошел все фильтры вывода, но написан мимо отзыва, до этой проверки платформа исправить не могла. На стенде такой ответ либо уходил в публикацию, либо к редактору. Теперь платформа ремонтирует его сама (с переходом на более сильный класс LLM), а редактор получает его только если ремонт не помог.

Порог и число ремонтов в тексте мы не называем, потому что это параметры правил соответствия конкретного технического решения. Статистики срабатываний на реальных запросах заказчика у нас нет, потому что нет и самих таких запросов, об этом ниже.

Границы проверки качества

Проверка качества ограничена так:

1. Модель-оценщик не заменяет правила соответствия. Фильтры вывода и проверка того, что ответ опирается только на документы, найденные поиском по документам (RAG), работают до нее и остаются на месте. Детерминированный контроль (правила с однозначным результатом, без LLM) мы LLM не доверяем.
2. Метрики безопасности (утечка персональных данных, обход точки подтверждения) модели-оценщику недоступны. Их считают детерминированные проверки платформы. Описание задачи, которое привязывает модель-оценщика к такой метрике, отвергает и проверка при установке, и платформа во время прогона.
3. Проверяются только метрики, вычислимые на одном результате. Средние по набору результатов в прогон не переносятся, потому что на одном случае они не определены.
4. В быстрых маршрутах, где человек ждет ответа на экране, проверка качества запрещена. Она стоит времени, а время ответа там и есть критерий приемки.
5. Проверка исполняется только там, где объявлена. Правила «проверять все» не существует.

Что происходит, если недоступна сама модель-оценщик

Поведение платформы зависит от того, есть ли дальше по маршруту человек, то есть точка подтверждения:

• Если дальше стоит точка подтверждения, платформа пропускает проверку и пишет в журнал прогона отдельную строку о том, что проверка качества не выполнялась и почему. Сама точка подтверждения на этом прогоне переходит в ручной режим. Даже если правило автопропуска, объявленное в описании задачи, пропустило бы результат без участия человека, результат без проверки увидит контролер и решит, что с ним делать.
• Если дальше по маршруту человека нет, шаг завершается ошибкой, и задача уходит в точку передачи. Результат без проверки в систему заказчика не записывается.

Пример с нашего стенда. Мы запустили десять задач ответа на отзыв покупателя с намеренно отключенной моделью-оценщиком. Девять дошли до проверки, и у каждой из девяти в журнале стоит строка о пропуске с причиной, вердиктов модели-оценщика нет ни одного. Все девять остановились на точке подтверждения в ручном режиме и ждали решения контролера, публикации без его решения не было. Десятая задача до проверки не дошла, потому что ее черновик остановил фильтр вывода, и она ушла в точку передачи.

Так было не с первого раза. Первая проба на стенде показала, что точка подтверждения применяла к непроверенному результату правило автопропуска, и восемь ответов из десяти прошли без участия человека. Мы изменили платформу так, чтобы пропущенная проверка переводила точку подтверждения в ручной режим, и повторили пробу.

Что происходит, если фильтр вывода заблокировал ответ

Если фильтр вывода заблокировал ответ LLM, шаг завершается ошибкой, задача уходит в точку передачи, и ни публикации, ни записи в систему заказчика не происходит. Результат, у которого фильтр вывода не пройден, в систему заказчика без решения человека не записывается.

Что из проверок и ремонтов видно снаружи установки

Каждый ремонт записывается в журнал прогона отдельной строкой, наравне с проходами агентского шага, вместе с вердиктом модели-оценщика до и после ремонта. Мы записываем ремонты по отдельности, чтобы слова «платформа сама починила результат» можно было проверить по журналу.

Расход на проверки и ремонты считается вместе с остальными вызовами LLM и виден в биллинге установки (учете потребления) отдельными строками. Самокоррекция стоит денег, и эту стоимость заказчик видит.

На какой стадии проверки и ремонт сегодня

Проверка качества и ремонт построены и проверены на нашем стенде. На стенде записан прогон ответа на отзыв, в котором модель-оценщик отклонила первый ответ, платформа отремонтировала его с переходом на другой класс LLM, и второй ответ порог прошел. Эту запись мы показываем на встрече. В записи на карточке наполнения карточек товаров у шага черновика стоит отметка ремонта после проверки модели-оценщика. Класс модели, взятой при ремонте, в записи не показан. Проверка качества сегодня объявлена в одном маршруте каталога, в ответе на отзыв покупателя, у остальных маршрутов работают только фильтры вывода и проверки формы. Границы из списка выше проверены отказом, то есть на описаниях задач, которые их нарушают. Поведение платформы при недоступной модели-оценщике проверено на стенде в сентябре 2026 года десятью прогонами одной задачи для ветки с контролером дальше по маршруту. Ветка без контролера на стенде не прогонялась. Замера на реальных запросах заказчика у нас нет, потому что первое внедрение впереди. Как только замер появится, долю ремонтов мы опубликуем.

Где посмотреть проверки на записанном запуске

На карточках технических решений витрины видно, куда уходит задача при отказе шага, например на карточке технического решения наполнение карточек товаров. Там же стоят две записи того, как прошел маршрут ответа на отзыв (единственный с объявленной проверкой качества). В записи видны шаги, обращения к системам площадки, отметки проверок и отметка на точке подтверждения. Схемы этого маршрута на витрине пока нет. Соседние страницы раздела разбирают агентский цикл, объявление маршрута, память платформы и границы ее самостоятельности.