Ранас Мукминов – Оркестрация ИИ-агентов. Claude Opus 4.7 (страница 42)

Один источник знания кладёт на доску ошибочный или испорченный вклад. Поскольку доска — общее основание для всех, ошибка немедленно становится входом для других источников, которые строят на ней свои выводы. Ошибка не остаётся локальной, как при сбое одного воркера в fan-out, а распространяется по доске и усиливается, превращаясь в каскад (см. главу 67). Это частный, но особенно острый случай отравления общей памяти (см. главу 53), а в присутствии недоверенного входа — ещё и вектор атаки: prompt injection, попавший на доску, через неё достигает всех источников знания (см. главу 86). Локализация требует, чтобы вклады несли происхождение (какой источник, на основании каких записей породил данную запись) — тогда испорченную ветвь можно отследить и снять, не разрушая остальную доску.

Доска накапливает все промежуточные гипотезы, версии и вклады. Без дисциплины удаления она растёт, и наступает двойная деградация: во-первых, стоимость каждого чтения растёт, потому что источнику знания, построенному на языковой модели, нужно поместить релевантную часть доски в контекст, а контекст конечен и дорог; во-вторых, доска переполняется устаревшими и отвергнутыми гипотезами, среди которых труднее найти актуальное состояние. Это смыкается с компрессией и дистилляцией контекста в рое (см. главу 52): blackboard требует явной политики, какие записи сохранять, какие сворачивать в сжатое представление, а какие удалять как отработанные. Доска без политики жизненного цикла записей нежизнеспособна на сколько-нибудь длинной задаче.

Развязка blackboard неполна. Источники знания не связаны друг с другом напрямую, но все связаны со схемой доски. Изменение схемы — переименование поля, смена формата записи, новый обязательный атрибут — потенциально ломает каждый источник, который эту запись читает или пишет. Связанность не исчезла, она сместилась в одну центральную точку и стала менее очевидной, а потому более коварной: при адресном контракте видно, кто на кого завязан, а при общей доске зависимость от схемы неявна и обнаруживается только когда меняешь схему и что-то ломается далеко в стороне. Дисциплина здесь — версионирование схемы доски и совместимость (связь с главой 22): схема — это публичный контракт всей топологии, и относиться к ней нужно строже, чем к контракту отдельного агента.

Поскольку порядок активации выводится из состояния доски, а не задан топологией, восстановить постфактум, почему система пришла к данному результату, труднее, чем в конвейере. В конвейере путь артефакта линеен и читается по стадиям. В blackboard итог — продукт недетерминированной последовательности активаций, зависевшей от того, что и в каком порядке оказывалось на доске. Это прямо усложняет наблюдаемость (см. часть XI): трассировка (см. главу 77) и реконструкция сессии (см. главу 81) для blackboard требуют логировать не только вклады, но и решения контроля — какие источники были применимы, какой выбран и почему. Без этого журнала ретроспективный разбор инцидента (см. главу 82) превращается в гадание по конечному состоянию доски.

Сводная таблица режимов отказа:

Failure mode | Где зарождается | Чем грозит | Базовая защита

Гонка записи (lost update) | параллельная запись на участок | потеря вкладов | single-writer на участок, версии записей

Livelock доски | взаимное переписывание | расход бюджета без прогресса | монотонная мера прогресса, лимит циклов

Отравление доски | ошибочный или враждебный вклад | каскад ошибок по всем источникам | происхождение записей, изоляция ветвей

Рост доски | накопление без удаления | рост стоимости чтения, шум | политика жизненного цикла записей

Связанность через схему | изменение схемы доски | поломка многих источников сразу | версионирование схемы как контракта

Непрозрачность | недетерминизм активаций | нечитаемый ретроспективный разбор | журнал решений контроля

Две инженерные конструкции делают blackboard из идеи работающей системой: контракт доступа к доске и условие завершения. Обе часто проектируют в последнюю очередь, и обе при этом определяют, будет ли система корректной и конечной.

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

Важно, чтобы контракт включал явный запрет на запись вне своей области. Источник, которому разрешено читать всю доску, но писать только на отведённый ему участок, не может ни затереть чужой вклад, ни отравить чужой уровень. Это применение принципа least privilege (см. главу 88) к разделяемому состоянию: права на чтение и права на запись разводятся, и запись сужается до минимально необходимого. Доска, на которой любой источник может писать куда угодно, не имеет защитных границ вовсе и держится только на добросовестности источников — недопустимое допущение для недетерминированных и потенциально скомпрометированных узлов.

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

— условие успеха: на уровне решения собран полный непротиворечивый итог, прошедший проверку критика;

— условие тупика: ни один источник не применим, а решение не достигнуто (доска застряла в неполном состоянии — это надо распознать, а не зависнуть в ожидании);

— условие бюджета: исчерпан лимит циклов, времени или токенов — жёсткий предохранитель против неограниченной работы;

— условие отсутствия прогресса: монотонная мера прогресса не растёт заданное число циклов, что отлавливает livelock доски раньше, чем исчерпается бюджет.

Условие отсутствия прогресса заслуживает выделения, потому что без него blackboard склонен к самому дорогому виду отказа — длительной продуктивной на вид работе без сходимости. Мера прогресса должна быть дешёвой для вычисления и монотонной по построению: например, число слотов решения, переведённых в финальное состояние и более не подлежащих пересмотру. Если такую меру не удаётся определить для задачи, это сильный сигнал, что задача плохо ложится на blackboard и её стоит переразложить под более регулярную топологию (см. главу 31).

Завершение по тупику требует, чтобы система умела отличать «работа закончена неуспешно» от «ни один источник сейчас не применим, но станет применим после внешнего события». В чисто внутреннем blackboard этого различия нет: если никто не применим, система в тупике. Но как только доска принимает асинхронные внешние вклады (см. главу 24), отсутствие применимых источников может быть временным, и условие тупика приходится снабжать тайм-аутом ожидания, после которого временная пауза признаётся настоящим тупиком. Это возвращает в blackboard всю проблематику тайм-аутов из распределённых систем (см. главу 70).

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

Чтение доски стоит токенов и ограничено контекстом. Детерминированный источник знания читает доску почти бесплатно. Агент-на-модели должен поместить релевантную часть доски в свой контекст, и это и расход, и предел: вся доска в контекст не помещается. Поэтому критичен слой выборки — что именно из доски подать агенту, чтобы он принял решение по своей подзадаче. Этот слой сам становится инженерной задачей и сам может ошибаться, отдавая агенту нерелевантный или неполный срез доски.

Применимость источника — нечёткая. В классическом blackboard предусловие источника — формальный предикат, который контроль проверяет точно. Для агента «применим ли я к текущей доске» — часто суждение, выносимое моделью, то есть недетерминированное и небесплатное. Это размывает контроль: он опирается на оценки применимости, которые сами могут быть неверны. На практике предусловия активации стоит делать максимально формальными (например, наличие записи определённого типа в определённом состоянии), оставляя модели только содержательную часть работы, а не решение о собственной активации.

Вклад правдоподобен, но не обязательно верен. Агент кладёт на доску результат, который выглядит уместно и согласованно с остальной доской, но может быть ошибочен. Поскольку доска — общее основание, такой вклад с высокой вероятностью будет принят другими источниками как данность. Это усиливает риск отравления доски по сравнению с детерминированными источниками: там испорченный вклад обычно нарушает формальный инвариант и ловится, здесь он формально корректен и проходит. Отсюда — необходимость верификации вкладов перед фиксацией, будь то отдельный источник-критик (связь с критиком и ревьюером — см. главы 19 и 65) или проверка инвариантов доски при каждой записи.