Резервные механизмы LLM нарушают работу конвейеров обработки данных агентами — я создал недостающий уровень восстановления.

Стандартная замена модели заставляет ваш производственный ИИ принимать поврежденные данные. Вот слой восстановления с нулевой зависимостью и учетом состояния, который я создал для сохранения целостности схемы во время переключения на резервный сервер.

Делиться

Вкратце:

Ограничения скорости LLM не просто приостанавливают работу ваших агентов. Они разрушают структуру данных, если вы меняете модели, не изменяя полезную нагрузку.

Базовый резервный маршрутизатор показывает на панели управления 100% завершенность, но снижает целостность схемы до 0%. Конвейер завершается, но результат оказывается некорректным.

Для исправления ошибки движок перехватывает её, перестраивает полезную нагрузку для резервной модели и сохраняет прогресс агента перед заменой. Приведённые ниже тесты производительности выполняются на стандартном Python 3.12 без каких-либо внешних зависимостей.

Момент, когда всё рухнуло

Я разрабатывал конвейер обработки данных для EmiTechLogic, состоящий из трех агентов: планировщика, исполнителя и валидатора, работающих последовательно и передающих структурированный JSON-вывод следующему. Конвейер отлично работал во время тестирования. Небольшие нагрузки, корректные ответы, никаких неожиданностей.

Затем я провел тестирование в реалистичных условиях.

Первый этап, Планировщик, завершился. Второй этап, Исполнитель, столкнулся с ограничением скорости в 429 запросов на полпути. Мой базовый цикл повторных попыток перехватил ошибку, переключился на резервную модель и продолжил работу. Конвейер сообщил о 100% завершении. Исключений не возникло. Ошибок в логах нет.

Но когда я проверил выходные данные, ключ достоверности отсутствовал. Поле результата представляло собой просто строку: «неполный — несоответствие схемы во время обмена». Валидатор получил структурно некорректные входные данные и не мог это определить. Конвейер завершился на бумаге, но данные оказались бесполезными.

Именно об этом и идет речь в данной статье. Не о самом 429 и не о цикле повторных попыток. Проблема в том, что происходит, когда вы передаете резервной модели неизмененную полезную нагрузку, отформатированную для совершенно другого движка.

Полная реализация доступна на GitHub: https://github.com/Emmimal/async-router-engine

Почему эту неудачу так трудно заметить

Стандартные панели мониторинга скрывают эту ошибку, поскольку отслеживают только завершение процесса. Они проверяют, вернул ли API код 200 и завершился ли поток корректно. Если скрипт завершается, панель мониторинга становится зеленой. Для многоагентных систем время безотказной работы — это неправильный показатель.

Важным показателем является целостность схемы. Конвейер, который незаметно завершается с поврежденными полями, часто хуже, чем полный сбой. Сбой требует немедленного исправления, в то время как незаметное повреждение данных проникает в вашу базу данных без предупреждения [1].

Эти агенты тесно связаны. Исполнитель ожидает точные JSON-ключи Планировщика, а Валидатор ожидает ключи Исполнительа. Когда замена модели нарушает структуру на втором шаге, этот шаг не выдает ошибку. Он просто передает некорректные данные дальше по цепочке, портя конечный результат где-то ниже по потоку, где вы не наблюдаете [2].

Ограничение скорости передачи данных — это не базовая проблема сетевой инфраструктуры. Это проблема целостности данных.

Анатомия скрытой аварии на трубопроводе

Механизм разрушения тихий, но разрушительный.

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

Когда базовый маршрутизатор перехватывает ошибку 429 и меняет идентификатор модели, он пересылает исходный запрос без изменений. Резервная модель получает конфигурацию, которую не может обработать. Сетевой запрос проходит успешно, потому что API технически вернул текст. Исключение не выбрасывается. Конвейер продолжает работу, но структура данных уже повреждена. Следующий агент получает просто необработанный текст или отсутствующие ключи вместо корректного JSON.

Вот схема распределения полезной нагрузки по трем уровням моей системы:

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

Создание уровня восстановления, который действительно понимает контекст.

Я разделил логику на четыре части. Каждая из них выполняет только одну задачу и ничего больше.

Первое осознание: не все неудачи одинаковы.

Базовый маршрутизатор рассматривает каждую ошибку API как триггер для замены или повторной попытки. Эта логика мгновенно дает сбой при переполнении контекста или проблемах с выставлением счетов.

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

Детектор обрабатывает это, анализируя исходную строку ошибки и сопоставляя ее со списками заданных шаблонов. Вместо общего сообщения о сбое он возвращает типизированное ThrottleEvent содержащее понятный код причины и временную задержку, привязанную к конкретной ошибке:

Детектор отслеживает временные окна провайдеров, используя time.monotonic() для затухания времени ожидания. Он следит за оставшимся временем задержки и контролирует скорость запросов в течение скользящего 60-секундного окна. Каждая попытка маршрутизации сначала вызывает is_throttled() . Если провайдер находится в режиме задержки, маршрутизатор полностью пропускает его.

Нормализация полезной нагрузки: как предотвратить повреждение схемы.

Регистрация модели и метод adapt_payload() разделяют Стратегию B и Стратегию A.

В реестре хранится ModelProfile для каждого движка. Этот профиль явно определяет возможности целевой системы, включая поддержку командной строки, флаги режима JSON, структуры схемы и конкретные шаблоны форматирования.

При смене целевого объекта маршрутизатор вызывает adapt_payload() для нового целевого объекта. Адаптер создает совершенно новый словарь запросов вместо пересылки старого. Если в резервной модели отсутствует специальное поле для системных подсказок, адаптер внедряет эти инструкции непосредственно в первое сообщение пользователя. Он применяет ключ response_format или структурные схемы только в том случае, если целевая модель поддерживает их изначально.

Вот преобразование полезной нагрузки при переходе с модели_a на модель_c:

Три строки в adapt_payload() , которые проверяют supports_system_prompt перед тем, как решить, куда внедрять системное содержимое, в бенчмарке представляют собой разницу между 0% и 100% целостности схемы.

Поддержание работоспособности конвейера при свопе

Функция сохранения состояния предотвращает потерю контекста при переключении между задачами в процессе их выполнения.

Когда исполнитель получает ошибку 429 и маршрутизатор переключается между моделями, резервный механизм запускается с нуля. Он видит историю необработанных сообщений, но не знает, выполнялся ли уже планировщик, в каком этапе последовательности выполнения он находится и какую схему ему нужно вернуть.

Функция сохранения состояния решает эту проблему, создавая снимок всего контекста выполнения в момент срабатывания события ограничения скорости, непосредственно перед заменой. Она регистрирует историю сообщений, системную подсказку, индексы шагов, существующие частичные выходные данные и целевую схему.

После обмена данными build_resume_message() преобразует этот снимок в структурированный текстовый блок и добавляет его в массив сообщений. Резервная модель получает контекст напрямую:

 [RESUME] Task 'pipeline_run_3' interrupted at step 2/3 (Execute planned steps). Previous model: model_a. Progress: 67% complete. Partial output so far: { "planner": { "result": "Pipeline step completed with full structured analysis.", "confidence": 0.94, "metadata": {"tokens_used": 312, "model_tier": "primary"} } } Continue from where the previous model stopped. Required output schema: {"type": "object", "required": ["result", "confidence"]}

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

Маршрутизатор

Маршрутизатор координирует работу детектора, реестра и средства сохранения состояния. Все это работает внутри цикла с ограниченным количеством повторных попыток, выполняя эти шаги в указанном порядке при каждой попытке:

Здесь наиболее важны два параметра конфигурации.

max_swaps ограничивает количество переключений моделей в рамках одного вызова. Без этого ограничения, постоянное ограничение скорости запросов у разных провайдеров будет зацикливаться бесконечно, пока не закончится значение max_retries .

swap_delay_seconds добавляет крошечную паузу в 0,05 секунды перед переходом к новой модели. Это окно достаточно мало, чтобы не ухудшить задержку, но достаточно велико, чтобы не перегружать провайдера, который и так испытывает трудности. Параметр max_swaps cap и swap_delay_seconds pause реализуют облегченную версию шаблонов ограничения и регулирования, описанных Нигардом [3].

Трехагентный конвейер

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

Оркестратор хранит общий список сообщений и словарь partial_output на всех трех этапах. При смене этапа в середине процесса, хранитель состояния упаковывает оба элемента в сообщение возобновления. Вместо получения только текущего диалога, резервная модель получает полный контекст того, что весь конвейер создал к этому моменту.

В моих старых резервных системах замена обрабатывалась только на уровне модели и полностью игнорировалась конвейером. Резервная модель получала новый ID, но понятия не имела, где она находится в последовательности. Функция сохранения состояния устраняет это несоответствие.

Эталон

Для точной воспроизводимости я провел три сценария по десять запусков в каждом, используя seed=42. Имитация поставщика заставляет model_a каждый раз устанавливать ограничение скорости на первом шаге, что приводит к срабатыванию резервной логики.

NO_ROUTER — это базовый вариант без какой-либо логики резервного копирования. Когда model_a ограничивает скорость выполнения, конвейер прерывает выполнение. Имитация возвращает ошибку 503 для любых вторичных вызовов модели. Вот что происходит, когда вы просто оборачиваете вызов API в простой блок try/except, регистрируете ошибку и сдаетесь.

STRATEGY_A — это базовая маршрутизация. Маршрутизатор перехватывает ошибку 429 и заменяет идентификатор модели, но пересылает тот же самый полезный груз, ничего не меняя. Имитирующий провайдер возвращает некорректный ответ с отсутствующими ключами и строкой ошибки схемы. Это соответствует поведению реальной резервной модели, когда ей передается несовместимый формат запроса, и она пытается угадать правильный путь.

STRATEGY_B — это данная система. Маршрутизатор перехватывает 429.
делает снимок состояния выполнения, нормализует полезную нагрузку для
Механизм резервного копирования внедряет контекст возобновления и продолжает работу.

Данный эталонный тест позволяет независимо изолировать сбои адаптации полезной нагрузки.
из-за различий в задержке, ценах или качестве модели, специфичных для каждого поставщика услуг.
Стратегии А и В отличаются только нормализацией полезной нагрузки и
Логика сохранения состояния. Использование детерминированного MockProvider позволяет
Прямое причинно-следственное сравнение этих стратегий восстановления без учета изменчивости, обусловленной условиями сети или различиями в возможностях моделей. Реальные API будут демонстрировать разные задержки и выходные данные, но структурный сбой, измеряемый здесь — пересылка несовместимых данных при замене моделей — остается тем же.

Целостность схемы оценивалась как процент запусков, в которых конечный результат работы агента соответствовал ожидаемой схеме JSON, включая все обязательные поля и правильные структурные типы.

 BENCHMARK RESULTS seed=42 | 10 runs per scenario | throttle_at_step=1 Latency = simulated (seeded, deterministic, OS-independent) ═══════════════════════════════════════════════════════════════════════════ Metric NO_ROUTER STRATEGY_A STRATEGY_B ───────────────────────────────────────────────────────────────────── Completion Rate 0.0% 100.0% 100.0% Schema Integrity Rate 100.0% 0.0% 100.0% State Preserved Rate N/A 100.0% 100.0% Provider Swap Rate 100.0% 100.0% 100.0% Avg Simulated Latency (ms) 57.50 77.12 77.12 Avg Steps Completed 0.00 3.00 3.00 ───────────────────────────────────────────────────────────────────── Completion improvement: +100.0% (NO_ROUTER -> STRATEGY_B) Schema integrity improvement: +100.0% (STRATEGY_A -> STRATEGY_B)

Стратегии A и B выполняют одинаковое количество вызовов API. Результаты бенчмарка показывают одинаковую задержку имитируемого провайдера, поскольку заданный MockProvider моделирует только время ответа API. Дополнительная задержка обмена в 50 мс, настроенная в RouterConfig является явными операционными накладными расходами, вносимыми стратегией B во время событий переключения на резервный сервер.

Посмотрите на целостность схемы в Стратегии А: 0,0%. Каждый запуск завершился. Каждый запуск вернул некорректные данные. Конвейер выполнил все три шага, и оркестратор зарегистрировал успех, но конечный результат оказался совершенно непригодным. Если ваши панели мониторинга отслеживают только показатели завершения, эта ошибка совершенно незаметна.

Стратегия B добавляет задержку обмена в 50 мс при каждом событии переключения на резервный сервер ( swap_delay_seconds=0.05 в RouterConfig ). Эта настраиваемая пауза предотвращает перегрузку уже загруженного провайдера перед переключением на резервный сервер. В бенчмарке смоделированная задержка для стратегий A и B одинакова, поскольку обе выполняют одинаковое количество вызовов API. Накладные расходы связаны исключительно с задержкой обмена, а не со снимком состояния, перестройкой полезной нагрузки или внедрением возобновления. В производственной среде задержка в 50 мс обычно незначительна по сравнению с сквозными задержками LLM, которые часто варьируются от нескольких сотен миллисекунд до нескольких секунд. Это обязательный компромисс.

Сохранение состояния неприменимо к NO_ROUTER, поскольку выполнение завершается до того, как произойдет восстановление.

Честные дизайнерские решения

Адаптер полезной нагрузки основан исключительно на правилах, а не на обучении . Каждый ModelProfile пишется вручную. Если вы хотите добавить новую модель, вы вручную определяете ее возможности, шаблоны и схемы.

Такая конструкция является преднамеренной. Настройка на основе правил на 100% поддается аудиту. Вы можете прочитать профиль и точно узнать, какие преобразования произойдут. Обученный адаптер создает непрозрачный черный ящик именно тогда, когда вам больше всего нужна прозрачность во время резервного режима в реальном времени.

Поле для сообщения о возобновлении работы тоже не является структурированным. Это просто обычный текст. build_resume_message() просто вставляет необработанную строку в обычное сообщение пользователя.

Если модель поддерживает системные запросы, внедрение контекста туда было бы более удобным. Но текущая настройка работает на всех трех уровнях моделей, включая model_c, которая вообще не поддерживает системные запросы. Совместимость победила над элегантностью.

Использование фиктивного поставщика позволяет контролировать эксперимент. Реальные API вносят задержку в сеть, затраты на выставление счетов и временные переменные, что делает результаты сравнительного анализа непредсказуемыми.

Неудача стратегии А носит исключительно структурный характер. Она возникает из-за того, что полезные нагрузки не нормализованы, а не из-за случайного сбоя по времени. Имитационный пример четко изолирует этот недостаток и обеспечивает полную воспроизводимость теста.

Тест производительности выполняется с параметром max_retries=4. Значение по умолчанию, равное 3, является консервативным для конфигурации с двумя провайдерами — увеличьте его, если ваш реестр имеет более трех уровней. Ограничение существует для предотвращения чрезмерного роста затрат на действительно недоступных провайдеров.

Что это значит для того, как вы будете создавать агентские системы?

Вы не можете делегировать обработку ограничений скорости универсальной библиотеке повторных попыток. Универсальные библиотеки перехватывают исключения и повторяют попытку. Они не понимают контракты полезной нагрузки между уровнями моделей, не делают снимки состояния агента и не могут нормализовать системные запросы для поставщиков, которые не поддерживают выделенное системное поле. Если ваша логика резервного копирования сводится к простому перехвату исключения, замене идентификатора модели и повторной попытке, вы используете Стратегию А. Ваши панели мониторинга будут показывать высокий процент завершения, но целостность схемы может быть нулевой, и вы этого не заметите.

Решение начинается с классификации ошибок. Ошибка 429, исчерпание квоты, переполнение контекста и таймаут поставщика — это четыре разные проблемы, требующие четырех разных ответов. Одинаковый подход к ним приводит к бесконечным повторным попыткам устранения неполадок, которые повторная попытка никогда не исправит.

Нормализация полезной нагрузки — вот где стратегия А дает сбой. Запрос приходится перестраивать с нуля для целевой модели, а не пересылать без изменений. Единственная проверка supports_system_prompt перед принятием решения о том, куда внедрять системное содержимое, — это вся разница между 0% и 100% целостностью схемы в бенчмарке. Это всего лишь одно условие. Оно ничего не стоит.

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

Последний элемент — это сообщение о возобновлении. Резервная модель запускается с нуля. Когда я тестировал это без сообщения о возобновлении, model_b подхватила историю сообщений и попыталась повторно выполнить шаг планировщика вместо того, чтобы продолжить с Executor. У нее не было возможности узнать, где она остановилась. Конвейер завершился, результат был неверным, и ничто не указывало на ошибку. Явное внедрение контекста возобновления — единственный способ сообщить резервной модели, что уже произошло и что ей еще нужно произвести.

Чего не хватает и что будет дальше?

Меньше всего меня устраивает StatePreserver. Снимки состояния хранятся в памяти и исчезают в момент сбоя процесса, а это значит, что перезапуск приводит к потере всего. Я хочу заменить словарь на бэкенд SQLite — интерфейс останется прежним, но состояние сохранится. Выбор модели сейчас слишком жёсткий. Реестр выбирает следующую модель в порядке приоритета, и на этом всё. На самом деле мне нужно, чтобы он определял, какой резервный вариант имеет наилучшую историю проверки целостности схемы для данной схемы, и направлял запрос туда — метод stats() уже собирает достаточно данных для этого вызова. И фиктивный провайдер нужно убрать. Подключение реального клиента Anthropic или OpenAI — это изменение одной функции, но я ещё этого не сделал, потому что бенчмарк должен оставаться контролируемым и воспроизводимым.

Закрытие

Я создал это, потому что мой конвейер обработки данных незаметно давал сбой. Ошибки 429 и перестановки моделей были видны, а показатели завершения выглядели корректно. Однако оставалось незамеченным, что каждый ответ резервной модели содержал пустое поле достоверности и строку результата «незавершено». Валидатор обрабатывал поврежденные данные всякий раз, когда основная модель замедляла работу. Во время нагрузочного тестирования это происходило большую часть времени.

Данный код не требует никаких внешних зависимостей и использует только стандартную библиотеку ( asyncio , dataclasses , enum , hashlib , json , random , time ):

• Детектор ограничения скорости : ~160 строк
• Адаптер полезной нагрузки: единственный метод в реестре моделей.
• Сохранение состояния: ~140 строк (включая конструктор сообщений для возобновления)

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

Главный вывод

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

Перед заменой сделайте снимок состояния, адаптируйте полезную нагрузку перед отправкой и явно укажите резервной модели, куда она попала.

Полный код: https://github.com/Emmimal/async-router-engine

Ссылки

[1] Sculley, D., Holt, G., Golovin, D., Davydov, E., Phillips, T., Ebner, D., Chaudhary, V., Young, M., Crespo, J.-F., & Dennison, D. (2015). Скрытый технический долг в системах машинного обучения. Достижения в системах обработки нейронной информации, 28. https://papers.nips.cc/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html

[2] Anthropic. (2024, 19 декабря). Создание эффективных агентов. https://www.anthropic.com/engineering/building-effective-agents

[3] Нюгард, М.Т. (2018). Выпустите это!: Разработка и развертывание готового к производству программного обеспечения (2-е изд.). Pragmatic Bookshelf. [Схемы автоматических выключателей и перегородок]

Раскрытие информации

Весь код в этой статье написан мной и является оригинальной работой, разработанной и протестированной на Python 3.12 (Windows 11, только для ЦП). Результаты бенчмарка получены в ходе реальных запусков benchmarks/benchmark.py с использованием MockProvider с seed=42 и полностью воспроизводятся при запуске файла на стандартной установке Python без необходимости установки каких-либо пакетов. Показатели задержки отражают детерминированную смоделированную задержку, накопленную с помощью заданного начального значения фиктивного поставщика, а не измерение по реальному времени, что гарантирует идентичные результаты на всех машинах и при всех запусках. MockProvider детерминированно имитирует поведение поставщика: в бенчмарке не выполняются реальные вызовы API LLM. У меня нет финансовых связей ни с одним инструментом, библиотекой или компанией, упомянутыми в этой статье.

Эммимал П. Александр. Посмотреть все работы Эммимал П. Александра.

Источник: towardsdatascience.com