"⚪️ 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"