Ранас Мукминов – Оркестрация ИИ-агентов. Claude Opus 4.7 (страница 37)
Граница между стадиями — это место, где артефакт сериализуется, передаётся и десериализуется следующим агентом. Качество конвейера определяется в первую очередь качеством этих границ, а не качеством агентов внутри стадий. Хорошая граница стадии обладает свойствами:
— Явный формат. Выход стадии имеет проверяемую структуру (схему), а не свободный текст «как получилось». Свободный текст на границе — главный источник дрейфа (см. ниже про семантический дрейф).
— Самодостаточность артефакта. То, что передаётся, должно содержать всё, что нужно следующей стадии, либо явную ссылку на внешнее состояние. Неявные предположения («следующий агент сам поймёт, что я имел в виду») на границе не выживают.
— Проверяемость на стыке. Между стадиями можно и нужно вставлять валидатор — детерминированную проверку, что артефакт соответствует контракту входа следующей стадии. Это не агент; это код. Валидатор на границе — самая дешёвая защита конвейера, и об этом ниже.
Когда граница оформлена как схема плюс валидатор, конвейер из недетерминированных агентов приобретает островки детерминизма между стадиями. Эти островки — то, что отличает инженерный конвейер от цепочки промптов, склеенной на удачу.
Иллюстративно граница между стадией плана и стадией черновика может быть оформлена как структура с обязательными полями, а не как абзац свободного текста:
# выход стадии "план", вход стадии "черновик" (иллюстративно)
task_id: T-001 # стабильный идентификатор исходной задачи
source_intent: "..." # ядро исходной постановки, протащенное насквозь
sections: # явная структура будущего артефакта
- id: s1
title: "..."
must_cover: ["...", "..."]
constraints: ["...", "..."]
open_questions: ["..."] # явно отмеченная неполнота, а не молчаливая достройка
Поле open_questions здесь принципиально: оно даёт стадии способ передать неопределённость явно, вместо того чтобы достроить её правдоподобно и тем самым запустить дрейф. Валидатор на границе проверяет наличие обязательных полей и ссылку на task_id; если стадия плана вернула свободный текст без структуры, валидатор отклоняет артефакт до того, как тот попадёт в дорогую стадию черновика. Дешёвая детерминированная проверка на границе перехватывает отказ раньше, чем за него заплачено генерацией следующей стадии.
Сколько работы помещать в одну стадию — отдельное проектное решение, лежащее между двумя крайностями. Крупнозернистый конвейер из немногих толстых стадий близок к одному агенту, делающему всё сам: мало границ, мало дрейфа, мало передач, но и мало специализации, и каждая стадия удерживает большой контекст. Мелкозернистый конвейер из многих тонких стадий доводит специализацию до предела, но платит за каждую границу латентностью передачи, точкой дрейфа и множителем в произведении надёжностей.
Практический ориентир — стадия должна соответствовать одному качественно отдельному преобразованию, которое имеет осмысленный самостоятельный контракт входа и выхода. Если две соседние стадии всё время передают друг другу почти один и тот же артефакт с минимальными изменениями, их граница не несёт смысла и её стоит убрать, слив стадии. Если же одна стадия делает два разнородных дела (например, и собирает факты, и оценивает их достоверность), её стоит разделить — но только если между этими делами можно провести проверяемую границу. Гранулярность подбирают так, чтобы каждая граница оправдывала свою стоимость отдельной проверяемой ценностью, а не существовала ради симметрии схемы.
Чистый линейный конвейер — частный случай. На практике встречаются три формы, и их свойства различаются принципиально.
Линейный конвейер — строгая последовательность без ветвлений и циклов. Его поведение предсказуемо, латентность — сумма латентностей стадий, отлаживается он проще всего. Это базовая форма, и начинать проектирование следует с неё.
Ветвящийся конвейер содержит стадию-маршрутизатор (см. главу 27), которая по содержимому артефакта направляет его в одну из нескольких веток (например, «юридический документ — в ветку с проверкой ссылок на нормы; технический — в ветку с проверкой кода»). Ветвление повышает специализацию, но превращает конвейер в граф и порождает вопрос: что делать, если маршрутизатор ошибся ветвью. Ошибка маршрутизации — это отказ, который проявляется поздно, на стадии, не приспособленной к данному входу.
Конвейер с обратной связью допускает возврат артефакта на предыдущую стадию: ревью отправляет черновик обратно на правку, и так до сходимости. Это уже не строго линейная топология, а цикл, и он наследует все проблемы циклов из главы 45 — прежде всего риск незавершения. Конвейер ревью-правка-ревью без жёсткого ограничения числа итераций склонен к livelock: ревьюер и редактор могут бесконечно обмениваться правками, каждая из которых формально улучшает артефакт, но сходимости нет (см. главу 66 о сходимости и расходимости). Любая обратная связь в конвейере обязана иметь счётчик итераций и предельное значение, по достижении которого артефакт принимается как есть либо эскалируется человеку.
Форма конвейера | Латентность | Предсказуемость | Главный риск
Линейный | Сумма стадий | Высокая | Узкое место и накопление дрейфа
Ветвящийся | Сумма стадий выбранной ветки | Средняя | Ошибка маршрутизации
С обратной связью | Переменная, зависит от числа циклов | Низкая | Незавершение, livelock
Конвейер часто путают с паттерном «оркестратор и воркеры», потому что оба разбивают задачу. Различие в природе разбиения и потому в типе масштабирования. Fan-out/fan-in разбивает задачу по данным: одна и та же операция применяется к независимым кускам, которые можно обрабатывать параллельно, поэтому добавление воркеров ускоряет работу (с поправкой на закон Амдала, см. главу 56). Конвейер разбивает задачу по фазам: разные операции применяются последовательно к одному потоку, поэтому добавление стадий не ускоряет обработку одного элемента — оно её замедляет, увеличивая длину цепочки и число передач.
Конвейер ускоряет не одну задачу, а поток задач: пока стадия 2 обрабатывает второй элемент, стадия 1 уже принимает третий. Это конвейерный параллелизм (pipelining), и он даёт выигрыш только при потоке однотипных задач, а не при единственной задаче. Из этого следует практическое правило: если задача единственная, конвейер не даёт выигрыша в скорости по сравнению с одним агентом, делающим те же фазы по очереди, — он даёт только выигрыш в специализации и изоляции стадий, оплаченный передачами контекста. Если задач поток — конвейер начинает окупаться за счёт параллельной загрузки стадий.
Узкое место (bottleneck) — стадия, ограничивающая пропускную способность всего конвейера. В конвейерной модели это не метафора, а точный закон: пропускная способность конвейера равна пропускной способности самой медленной стадии, сколь угодно быстрыми бы ни были остальные. Эта тема развёрнута на уровне всей системы в главе 57; здесь — её конвейерная специфика.
Если стадия исследования обрабатывает элемент за время порядка минуты, стадия плана — за десятки секунд, а стадия ревью — за две минуты, то поток задач через конвейер не может идти быстрее, чем одна задача в две минуты, — независимо от того, насколько быстры остальные стадии. Быстрые стадии простаивают в ожидании медленной либо накапливают перед ней очередь. Это означает, что оптимизация быстрых стадий не даёт ничего: ускорять имеет смысл только узкое место. Инженер, не измеривший латентность по стадиям, оптимизирует вслепую и почти всегда не ту стадию.
У агентных конвейеров узким местом обычно становится не самая «умная», а самая «многословная» стадия — та, что порождает больше всего токенов, потому что латентность модели в значительной степени определяется числом сгенерированных токенов. Стадия, пишущая длинный черновик, медленнее стадии, выносящей короткий вердикт, даже если вердикт требует «больше думать». Это смещает интуицию: узкое место конвейера предсказывается объёмом выхода стадии, а не её кажущейся сложностью.
Когда стадии не сбалансированы по пропускной способности, перед медленной стадией накапливается очередь незавершённой работы. В системе с ограниченной памятью эта очередь либо переполняет буфер, либо вынуждает применять обратное давление (backpressure) — сигнал быстрым стадиям притормозить. Без backpressure быстрая стадия исследования будет генерировать артефакты быстрее, чем стадия ревью успевает их потреблять, и система будет либо терять артефакты, либо неограниченно расти в памяти, либо — что хуже для агентов — копить незавершённые дорогостоящие промежуточные результаты, за которые уже заплачено токенами, но которые ещё не доведены до конца.
Для агентного конвейера накопление очереди имеет денежное измерение, которого нет у классических конвейеров: каждый артефакт в очереди — это уже потраченные токены. Очередь незавершённой работы перед узким местом — это замороженные деньги и одновременно риск: если конвейер придётся остановить, вся работа в очереди может пропасть, и её придётся переделывать. Поэтому ограничение объёма незавершённой работы (work-in-progress limit) — не только защита памяти, но и контроль стоимости.