⚪️ Retry/repair/fix циклы в модельных и агентных пайплайнах


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

Последние недели сильно "кашлял" инференс на клозедах ("model at capacity") - и много пайплайнов в разных системах сбоило. Пришлось реагировать. Провёл ревизию, настроил пайплайны с использованием ряда принципов, делюсь ими с вами.

▶️ Проблемы делю так:

1️⃣ Транспортные/провайдерские: это когда провайдер не отвечает, когда рвётся стрим ответа, когда "model at capacity" - это такие проблемы, когда можно просто повторить запрос; то есть делаем Retry;

Нестабильностью научила такому: повторы делаю с прогрессивной задержкой, первый через 10 секунд, второй - через 30 секунд, третий - через 60 секунд. Бюджет повторов 3 раза максимум, если ошибка после третьего, считаю что провайдер не дышит и роняю пайплайн. Если после любого повтора модель вернула успешный ответ, я сбрасываю счётчик повторов, и при следующей ошибке бюджет - опять 3 раза. Так удалось тянуть пайплайны если кодекс хоть как то дышал.

2️⃣ Есть провайдерские ошибки с лимитами (модель упёрлась в лимит подписки, кончились кредиты/деньги на аккаунте) и авторизацией (протухли логины/авторизации, были инвалидированы) - тогда нет смысла повторять запросы, сразу валим пайплайн. Важно не потерять причину, потому что часто при такой ошибке требуется вмешательство человека. В некоторых пайплайнах настроил ждать сброса лимитов, смотрим когда лимит сбросится, выжидаем и делаем retry.

3️⃣ Когда модель вернула некорректный ответ - не в структуре (схему дежить Structured Output), а логическая проблема в содержимом - неправильный идентификатор, некорректное значение.

Такое бывает у туповатых моделей типа Луны, если задача для них тяжёлая: много надо сопоставить, много вводных = путается.

Когда обнаружили логическую проблему, мы делаем Repair/Fix запрос. Тут берём специальный repair-промпт, который похож на первоначланьый, но содержит инструкции чтобы модель исправляла ошибку, и описание допущенной ошибки.

Также тут придумал такое: делать дауншифтинг задачи. Например, нужно было разобрать пачку данных из 50 элементов. В 2х допущена ошибка. В repair промпт берём только 2 косячных элемента, правильные элементы уже исключаем из задачи, и модель чинит только поломанное. Готовое и корректное убираем из контекста, повторно модели не показываем.

Если нужно было вернуть сложный объект, и была допущена ошибка с каким то блоком - просим перегенерировать только этот блок, без полной схемы. А уже в детерминированном коде после repair запроса патчим первоначальный объект чтобы получить полный и корректный итоговый ответ.

Что дает дауншифтинг? Модель может сфокусироваться на ошибочных элементах и ей проще починить допущенные проблемы. Скорее всего в первоначальной задаче модели не хватило ресурса внимания для подного и качественного решения, и снижение контекста и сложности задачи ей помогут. Если же дать первоначальный объём - легко получить ошибку в других 2-3 элементах, да и гонять повторно обработку уже обработанных данных - это такое себе решение.

4️⃣ Когда система оркестрирует агентную упряжку и сессия агента валится - тут расследуем причину падения. Если пресловутая "capacity" - то делаем по приципу похожему на модельный пайплайн, но в агентной версии. Те же 3 повтора, с прогрессирующей задержкой, но через промпт "continue". Если "не шмогла" - тогда валим пайплайн.

Аналогично для проблемы лимитов/авторизации в агентном пайплайне. Есть возможность подождать сброса - ждём (конечно, это про 5h лимит, недельные ждать пока необходимости не было).

❓ Вот такие подходы. Используете что то такое? Также делаете? Или какие то интересные находки на эту тему есть? Давайте обратную связь в комменты/чат ⬇️

🏞️ Картинка: Если кашляет — даём отдышаться. Если выдала квадратную шестерёнку — берём напильник

@deksden_notes