У любой системы на LLM (больших языковых моделях) бывают негодные ответы. Разница между системами в том, что происходит дальше. Одна останавливается и зовет человека. Другая сначала пробует исправить негодный ответ сама и делает это в пределах, объявленных в описании задачи.
Самокоррекцией мы называем только такое поведение платформы, при котором она меняет подход к задаче после результата, не прошедшего проверку, без участия человека и в пределах объявленных бюджетов (числа ремонтов и времени шага). Отличие самокоррекции от повтора после сбоя в словах «меняет подход». Термины (шаг, попытка, проход, ремонт, модель-оценщик, фильтры вывода, точка передачи, контролер, класс LLM) определены на обзорной странице.
Что самокоррекцией не считается
Границу между самокоррекцией и отказоустойчивостью проводим сразу, иначе при сравнении платформ один и тот же механизм легко засчитать дважды. К отказоустойчивости мы относим такие случаи:
- Повтор того же вызова после сетевой ошибки (с нарастающей паузой).
- Переключение на резервное развертывание той же LLM, когда ее поставщик не отвечает.
- Откат уже сделанных действий, когда задача не дошла до конца.
Все это в платформе есть. Платформа в этих случаях повторяет то же самое или отменяет сделанное. По-другому она не пробует.
Механизмы, которыми платформа меняет подход
Список механизмов закрыт.
| Механизм | Что распознает | Что меняет |
|---|---|---|
| Ремонт формы ответа | Ответ не соответствует объявленной форме результата | Повторный вызов LLM с перечнем нарушений. В перечень попадают только адреса полей и коды ошибок, без значений |
| Ремонт содержания | Оценка результата у модели-оценщика ниже порога | Повторный вызов с разбором от модели-оценщика |
| Смена подхода на повторе | Прошлый ремонт не помог | Другой вариант задания для LLM (варианты объявлены в техническом решении) и, если объявлено, другой класс LLM |
| Коррекция прохода | Инструмент внутри агентского шага отказал или вернул результат, который не подходит под ожидаемую форму | Отказ инструмента становится исходом прохода, и цикл продолжается по своим правилам выхода |
Последняя строка отличает агентский шаг от обычного. У обычного шага обращения к системе заказчика отказ системы заканчивает попытку. Платформа повторяет шаг новой попыткой в объявленных пределах, а когда попытки кончились, задача уходит контролеру. У агентского шага отказ инструмента становится наблюдением. LLM видит, что инструмент не ответил, и решает, что делать на следующем проходе.
Как устроена проверка качества
Проверку выполняет модель-оценщик. Это отдельная LLM, которой платформа показывает результат шага и определение метрики из справочника метрик качества платформы (например, отвечает ли текст на исходный вопрос). Задание исходного шага она не видит. Метрика и порог объявлены в описании задачи. Если оценка результата ниже порога, шаг уходит в ремонт с разбором от модели-оценщика, а на повторе меняется вариант задания и, если объявлено, класс LLM. Число ремонтов ограничено сверху настройкой установки, а описание задачи может это число только уменьшить.
Пример с нашего стенда. В маршруте ответа на отзыв покупателя проверяется, отвечает ли текст на сам отзыв. Ответ, который прошел все фильтры вывода, но написан мимо отзыва, до этой проверки платформа исправить не могла. На стенде такой ответ либо уходил в публикацию, либо к редактору. Теперь платформа ремонтирует его сама (с переходом на более сильный класс LLM), а редактор получает его только если ремонт не помог.
Порог и число ремонтов в тексте мы не называем, потому что это параметры правил соответствия конкретного технического решения. Статистики срабатываний на реальных запросах заказчика у нас нет, потому что нет и самих таких запросов, об этом ниже.
Границы проверки качества
Проверка качества ограничена так:
- Модель-оценщик не заменяет правила соответствия. Фильтры вывода и проверка того, что ответ опирается только на документы, найденные поиском по документам (RAG), работают до нее и остаются на месте. Детерминированный контроль (правила с однозначным результатом, без LLM) мы LLM не доверяем.
- Метрики безопасности (утечка персональных данных, обход точки подтверждения) модели-оценщику недоступны. Их считают детерминированные проверки платформы. Описание задачи, которое привязывает модель-оценщика к такой метрике, отвергает и проверка при установке, и платформа во время прогона.
- Проверяются только метрики, вычислимые на одном результате. Средние по набору результатов в прогон не переносятся, потому что на одном случае они не определены.
- В быстрых маршрутах, где человек ждет ответа на экране, проверка качества запрещена. Она стоит времени, а время ответа там и есть критерий приемки.
- Проверка исполняется только там, где объявлена. Правила «проверять все» не существует.
Что происходит, если недоступна сама модель-оценщик
Поведение платформы зависит от того, есть ли дальше по маршруту человек, то есть точка подтверждения:
- Если дальше стоит точка подтверждения, платформа пропускает проверку и пишет в журнал прогона отдельную строку о том, что проверка качества не выполнялась и почему. Сама точка подтверждения на этом прогоне переходит в ручной режим. Даже если правило автопропуска, объявленное в описании задачи, пропустило бы результат без участия человека, результат без проверки увидит контролер и решит, что с ним делать.
- Если дальше по маршруту человека нет, шаг завершается ошибкой, и задача уходит в точку передачи. Результат без проверки в систему заказчика не записывается.
Пример с нашего стенда. Мы запустили десять задач ответа на отзыв покупателя с намеренно отключенной моделью-оценщиком. Девять дошли до проверки, и у каждой из девяти в журнале стоит строка о пропуске с причиной, вердиктов модели-оценщика нет ни одного. Все девять остановились на точке подтверждения в ручном режиме и ждали решения контролера, публикации без его решения не было. Десятая задача до проверки не дошла, потому что ее черновик остановил фильтр вывода, и она ушла в точку передачи.
Так было не с первого раза. Первая проба на стенде показала, что точка подтверждения применяла к непроверенному результату правило автопропуска, и восемь ответов из десяти прошли без участия человека. Мы изменили платформу так, чтобы пропущенная проверка переводила точку подтверждения в ручной режим, и повторили пробу.
Что происходит, если фильтр вывода заблокировал ответ
Если фильтр вывода заблокировал ответ LLM, шаг завершается ошибкой, задача уходит в точку передачи, и ни публикации, ни записи в систему заказчика не происходит. Результат, у которого фильтр вывода не пройден, в систему заказчика без решения человека не записывается.
Что из проверок и ремонтов видно снаружи установки
Каждый ремонт записывается в журнал прогона отдельной строкой, наравне с проходами агентского шага, вместе с вердиктом модели-оценщика до и после ремонта. Мы записываем ремонты по отдельности, чтобы слова «платформа сама починила результат» можно было проверить по журналу.
Расход на проверки и ремонты считается вместе с остальными вызовами LLM и виден в биллинге установки (учете потребления) отдельными строками. Самокоррекция стоит денег, и эту стоимость заказчик видит.
На какой стадии проверки и ремонт сегодня
Проверка качества и ремонт построены и проверены на нашем стенде. На стенде записан прогон ответа на отзыв, в котором модель-оценщик отклонила первый ответ, платформа отремонтировала его с переходом на другой класс LLM, и второй ответ порог прошел. Эту запись мы показываем на встрече. Проверка качества сегодня объявлена в одном маршруте каталога, в ответе на отзыв покупателя, у остальных маршрутов работают только фильтры вывода и проверки формы. Границы из списка выше проверены отказом, то есть на описаниях задач, которые их нарушают. Поведение платформы при недоступной модели-оценщике проверено на стенде в сентябре 2026 года десятью прогонами одной задачи для ветки с контролером дальше по маршруту. Ветка без контролера на стенде не прогонялась. Замера на реальных запросах заказчика у нас нет, потому что первое внедрение впереди. Как только замер появится, долю ремонтов мы опубликуем.
Где посмотреть проверки на записанном запуске
На карточках технических решений витрины видно, куда уходит задача при отказе шага, например на карточке технического решения наполнение карточек товаров. Схемы маршрута ответа на отзыв, единственного с объявленной проверкой качества, на витрине пока нет, и запись его прогона с ремонтом мы показываем на встрече. Соседние страницы раздела разбирают агентский цикл, объявление маршрута, память платформы и границы ее самостоятельности.