Циклы улучшения (OODA, POOGI, PDCA и даже Ralph loop) "в одном флаконе" -- уже в FPF

ailev · 01.Июнь.2026 17:59:28

Разные циклы улучшений отличаются шкалами, а сам цикл примерно один и тот же
Самые разные циклы улучшений (в менеджменте и инженерии их тьма) очень похожи, но чем именно отличаются — сходу непонятно. Теперь понятно: это многошкальные оценки объектов и по разным шкалам идут похожие циклы, отличия главным образом в шкалах, при этом есть и шкалы для оценки качества прохождения самого цикла (скажем, у Бойда этот ход на “сам цикл крутим быстрее” — это же мета-высказывание). Опять же, в этих циклах иногда момент выдачи рекомендаций вставляется, а иногда – нет. И обычно не обсуждаются роли. Хотя в руководствах я прописываю паттерн разделения ролей в цикле Бойда – “авианосец Клемансо”, где разные исполнители ролей делали замеры “где враг” и “что атакуем”, ибо там скрытый конфликт интересов, в итоге команда смотрит не на то, где враг, а на то, куда можно достать оружием. Reviewer и executor должны всё-таки работать с разными интересами, разными контекстами. В таких циклах всегда есть “замеры”, “принятие решений”, “исполнение” – но хотя бы отделить замеры от всего остального, уже полезно. И подсказки решений со стороны reviewer “исходя из замеров”, а не исходя из предпочтений разработчика, у него же “я не приму это правильное решение, ибо душой прикипел к тому неправильному, которое я принял вчера и многое на его основе уже сделал”. Собственно, в инженерии так и делается: независимое review, которое говорит, что и как надо исправить (и делается опытнейшими разработчиками, которые в состоянии обнаружить невидимые неопытным разработчикам ошибки).

Теперь можно идти в FPF и говорить: “вот тут у нас цикл улучшений. Скажи, что поправить, что усилить, о чём забыли сказать”. Этого должно быть достаточно, даже имени паттерна (их там несколько) не надо знать.

Если мы говорим «улучшить», надо сначала назвать, что именно улучшается, по какой схеме оценки мы поймём «стало лучше», сколько стоят попытки улучшения и когда надо остановиться.

Без этого будет не улучшение, а “закрытие замечаний” без понимания, что там улучшилось, кроме закрытых замечаний. Закрыли все замечания – значит, вроде бы улучшили, но понимания, что там улучшилось (действительно ли закрытие замечаний повлияло на качество) нет, поэтому и улучшений может после закрытия всех замечаний не оказаться. Агент (живой или не очень) сделал ещё десять попыток “улучшений” – значит вроде бы должно стать лучше? Насколько? Можно отдавать пользователям или ещё нет? Текст (кода, статьи, поста в блог, аналитического отчёта) стал длиннее и аккуратнее – значит вроде бы качество выросло, но так ли это? Может быть, длина была за счёт воды, а аккуратность в тех местах, где и так не было ошибок? Нет, улучшение надо проверять повторной оценкой качества уже изменённой версии объекта по тем же шкалам, ради которых улучшение вообще запускалось. И ещё предлагать эти улучшения, чтобы они затрагивали именно эти шкалы – помня при этом про закон Гудхарта (он про “одно лечим, другое калечим”).

Кампания добавила в FPF общий метод для циклов улучшения «всего чего угодно»: системы, эпистемы, рабочего процесса – всего, что хотите улучшить. Но этот “общий метод улучшения” (конечно, SoTA, у нас все паттерны с SoTA-echoing) не говорит сам по себе, что такое «хорошо». Он требует подключить оценочную схему для конкретного типа объекта.

Один способ крутить цикл, разные цели улучшений, разные шкалы оценки
Чтобы говорить про “улучшения”, надо иметь какую-то их онтологию. Поэтому разбираемся с тремя вопросами:

как понимаем “улучшение”. На каждом проходе мы уточняем для reviewer, что будет оцениваться (Entity-of-Concern: цикл-то про что угодно, но это “что угодно” надо конкретизировать, причём concern/интерес тут “улучшение”), ради какого использования этого “что угодно”, какой минимальный уровень годится для использования (“на четвёрочку” или всё-таки “на пятёрочку”? MVP или “лучше конкурентов на Парето-фронте”?), что нельзя ухудшить (Гудхарт – вот тут), какой результат цикла улучшений мы хотим получить. Это всё будет отличать, например, дешёвый проход «есть ли блокирующие дефекты для MVP-использования табуретки» от прохода вроде «поднять уже годный текст докладной записки до исключительно сильного уровня». Это разные вопросы про разные сущности для улучшения, и они дают разные ответы. Вот это надо формулировать индивидуально для каждого проекта, а как это делать – в паттерне E.22 - Improvement-Oriented Quality-Read Question Framing (грубо говоря, как делать оценку на одном витке цикла улучшений).
набор шкал пространства характеристик для оценки. Он отвечает на вопрос «что значит лучше именно для этой интересующей сущности». Для паттерна это, например, узнаваемая рабочая ситуация, первый полезный ход для читателя, точные границы применения, связь с текущей практикой, отсутствие лишней тяжести и так далее. Для записи проектного решения это другое, и тоже множество шкал: принято ли решение или только разговоры разговариваем, рассматривались ли альтернативы или был “выбор из одного”, понятно ли, что делать дальше, остались ли спорные места или места с мутным выражением того, что же там решили. Тоже множество шкал. В этом-то и фишка, что цикл общего вида работает не над одной характеристикой (вроде POOGI, улучшающего throughput, или OODA, уменьшающего время кручения цикла, или PDCA, уменьшающего число дефектов на миллион вплоть до 3.2 – шесть сигма). Тут сразу задаётся многомерная характеризация, анти-Гудхарт, работа с Парето-фронтом и доминируемостью решений. Недоминируемые решения – лучше! Улучшения – как раз про это, выигрыш в конкуренции. Как делать набор шкал – в A.19.ECS - Evaluation CharacteristicSpace Construction.
организация собственно цикла улучшения. В этом цикле происходит улучшение (на первом ходу: вообще появление, ибо “что-то” уже лучше, чем “ничего”) интересующей сущности каким-то исполнителем (executor), затем оценщик (reviewer) производит оценку по выбранному набору шкал и смотрит, что стало лучше и что стало хуже, делает предложения на тему, чтобы стало лучше. И он же считает ожидаемую стоимость ещё одного прохода по циклу и принимает решение: остановиться, сузить цель, продолжить, сменить метод или отложить работу до лучших времён – сообразуясь с тем, что мы понимаем под “улучшением” и каковы критерии остановки цикла. Всё это описывается паттерном E.23 - Quality Improvement Loop Method.

Если эти вопросы не обсудить отдельно, то разовая проверка начинает притворяться прохождением какого-то цикла улучшений (“вот тут у тебя ошибка, и вот тут ошибка – возврат, переделай всё, оно же полностью сырое” – тебе возвращают не “переделанное всё”, а точно исправленное только то, что было в двух замечаниях, “заменил два слова, что ты указал”). Исполнитель может сам придумывать шкалы качества и следовать закону Гудхарта (голова болит? Этой шкалы достаточно: отрубаем голову, голова не болит, система улучшена – проверяйте, голова точно не болит!). Оценка вдруг превращается вместо инженерной работы в административную переписку по найденным замечаниям (“мы ничего не доделали – всё равно посылаем, пусть пишут замечания, а потом исправим ровно замечания и так будем тянуть время вечно. Всё равно не знаем, что делать – да и делать по уму лень”). И ещё ответ на замечание и “учёт предложенных улучшений” могут даже оценщиком восприниматься как улучшение качества, хотя честная оценка может и не подняться по итогам реакции на замечания или учёта предложения.

Конечно, в применении цикла улучшений есть много нюансов. Например, связь с BLP (bitter lesson preference, учёт цены универсальности): когда надо крутить общий агентный многошкальный цикл, а когда дешевле взять специализированный цикл по одной шкале или стандартному малому набору хорошо понятных шкал (те самые POOGI, OODA, PDCA или даже Ralph loop – тысячи их).

Специализация универсального цикла для улучшений паттернов, DRR и FPF в целом
Паттерны E.22, A.19.ECS и E.23 помогают всем проектам, но мне они помогают в разработке самого FPF. Сначала я добавил E.8.ECSPF - Evaluation CharacteristicSpace FPF Pattern Publication Form, это про оформление выбранного набора шкал в форме паттернов. По этому шаблону я сделал три паттерна, наборы характеристик в них готовил по A.19.ECS:

E.21 - FPF Pattern-Quality Evaluation CharacteristicSpace, для паттернов.
E.9.DA - DRR Decision-Adequacy Evaluation CharacteristicSpace, для DRR (design rationale record – запись о принятых проектных решениях по разработке группы паттернов).
E.2.DA - FPF Pillar-Adequacy Evaluation CharacteristicSpace, для FPF в целом.

Когда вы будете готовить SPF (second principle framework для вашей предметной области), то вы себе сделаете шкалы для оценки улучшаемых в цикле объектов по A.19.ECS, а оформите их в формате паттернов по E.8.ECSPF.

Так что у меня качество паттернов, DRR и FPF в целом теперь определяется не “на глазок, интуитивно”, а оценкой по набору шкал, причём набор этот разный для каждого типа интересующей сущности. Никаких оценок одной цифрой или даже одним набором шкал “качество в целом”.

Главная ловушка любого улучшения – начать мерить то, что удобно, а не то, что важно. Если мы улучшаем стул, атомную станцию, DRR и паттерн по одной и той же удобной для замеров таблице шкал, замеры будут правильными, но бесполезными. Если мы улучшаем текст по количеству закрытых замечаний, можно улучшить отчётность и ухудшить текст – показатель будет правильно измеряться, но будет врать про качество. Если мы улучшаем паттерн по числу источников для SoTA-echoing, можно получить библиографию по методу вместо описания метода решения проблемы, которой посвящён паттерн. А как надо? Надо проверять: правда ли, что паттерн опирается на SoTA решения (для этого надо и собрать литературу, и показать, что это не “попса на слуху”, а реально SoTA, а затем ещё и оценить – текст паттерна соответствует этой SoTA или не соответствует). Но это ведь важная характеристика! Поэтому её замеряем.

Вопрос A.19.ECS – назначение пространства характеристик. Какой тип (kind) интересующего объекта для какого использования в каком контексте/проекте мы оцениваем и по каким шкалам? Какие контрастные примеры для “лучше-хуже”, чтобы построить шкалу? Надо показать хотя бы три случая: заведомо хороший объект оцениваемого типа, плохой объект этого же типа и какой-то объект другого типа, который вообще нельзя честно оценивать по этим шкалам (чтобы не было смешных оценок с перепутанными типами вроде “стул – это плохая атомная станция, DRR – это плохой паттерн”).

Какой-то локальный для проекта список проверки не будет становиться паттерном FPF, но это первый кандидат на паттерн SPF или даже TPF – вот его вы уже сможете сделать с опорой на правила из E.22. Там обязательно будет: сначала рабочая ситуация и первый простой ход на её описание, только потом шкалы и таблицы, а не наоборот “вот шкалы-таблицы оценки, опиши нашу ситуацию”.

Я в своих семинарах по FPF неоднократно говорил о характеризации целевых систем, характеризации описаний и прочих характеризациях интересующих сущностей (https://events.system-school.ru/). Эта характеризация могла использоваться потом для разных целей, но A.19.ECS как раз рассказывает, как её делать для ситуации, когда вы собираетесь крутить цикл улучшений.

Как это изменило методы разработки FPF
Оценка reviewer идёт теперь у меня при разработке паттернов с типовым промптом “пошагово по каждой шкале, пиши оценку мне в чат после каждого шага” (если не писать в чат, то внимание агента теряется и оценка будет неточной, “в общем и целом”), а задачу кручения цикла для паттернов и DRR я ставлю сейчас как “дотягиваем до пятёрочки” (это не “рабочее качество”, а “исключительное качество, прямо-таки образец”).

Конечно, можно крутить цикл улучшений и для трёх наборов шкал пространства характеристик для оценки качества DRR, паттернов и FPF в целом. Этим “улучшением цикла улучшений” тоже планирую заняться (на этом пути ещё и решение проблем “тупика развития” с maturity ladder, когда “у нас все пятёрочки, интересующая сущность уже зрелая, переходим к стагнации”), но пока получаю пользу уже от первой версии этих шкал.

Крутить цикл для DRR и групп паттернов – уже кручу, результаты радуют. Но ещё были прописаны шкалы улучшения FPF – это тоже ведь вполне понятная инженерная задача. Но крутить цикл для FPF в целом – надо быть очень богатым человеком, чтобы купить огромное число токенов. Так что E.2.DA – паттерн “на вырост”, для понимания.

Я сделал какое-то сравнение довольно трудоёмкой работы с внешним review – и обнаружил, что за один цикл внутреннее многошкальное review модели GPT-5.5 xhigh не цепляет примерно 20% замеченного внешней Pro-моделью. Но мне много легче прогнать несколько таких проходов. Один из проходов шёл 8 часов непрерывной работы агента, я плохо представляю, чтобы мог добиться такого от Pro-модели. Поэтому я принял решение сейчас отказаться от внешних review и перейти на прохождение цикла улучшений – с критерием остановки “все пятёрочки”. Нет, это не исправляет содержательных ошибок: если вы ошиблись с тем, что должен делать паттерн (например, задали кривую онтологию, или онтологию в DRR задали правильно, но она почему-то не перенеслась в сам паттерн), то он будет шикарен по всем шкалам – оформит оценку “на все пятёрочки” по всем 18 шкалам. Чудес не бывает, ибо нет шкалы “сделал всё правильно”. Содержание как таковое, увы, нельзя оценить по шкале. Но вот онтологическую чистоту – можно! Разве что онтологически безупречно будет оформлена какая-то чушь. Повторюсь: чудес не бывает.

Пример набора шкал для оценки: интересующая сущность – паттерн
Вот пример набора шкал для оценки паттернов. Сначала он был предложен “из общих соображений”, затем туда попали шкалы, по которым удобно отслеживать частые ошибки, затем там была проведена “ортогонализация” (какие-то шкалы объединили, какие-то, наоборот, подробили – чтобы получить более точные оценки по независимым шкалам). Сам набор характеристик находится в “#### E.21:4.3a - Coordinate value evidence test” – над UX паттернов ещё работать и работать, пока в этой “схеме улучшений” работает подход “сказать всё нужное потенциально важное в одном тексте”, а не “сказать сначала главное, а всё остальное убрать в приложения”. Как с этим будем бороться? Добавим соответствующие характеристики UX для паттерна, а затем пустим долгий цикл реструктурирования (потом, когда-нибудь, когда модели будут умнее, а токены дешевле). Пока же вот текущий набор характеристик (оценки ставятся по тому, насколько замеряемое свойство выражено в тексте – отсутствует (0), только названо (1), выражено частично (2), выражено достаточно (3), выражено хорошо (4) или выражено на образцовом уровне (5). Текущий подход – вытягиваем всё “на пятёрочку”, при этом executor всегда сам ставит “пятёрочку” там, где reviewer обычно ставит 4 или даже 3 и даёт замечание, что и как поправить, чтобы стало лучше. Необходимость независимой оценки, что в случае AI-агентов означает оценки в разных контекстах, видна сразу):
Характеристики самого паттерна:

узнаваемость рабочей ситуации и границ применения: читатель паттерна быстро понимает, его ли это случай и где паттерн применять не надо.
понятность действий: после первого простого хода видно, что делать дальше, причём это видно подробно и с нюансами в решении, а не в чеклисте для короткой проверки.
понятность завершения применения паттерна: видно, когда работа по паттерну закончена, когда надо в ходе работы сузить цель и какими паттернами надо воспользоваться для решения оставшихся вопросов.
стабильность интересующей сущности в паттерне: паттерн не дрейфует между александрианским паттерном, записью решения проблемы в произвольной форме, описанием метода работы, обзором литературы, просто каким-то рабочим документом.
точность выражения смысла терминов: имена объектов паттерна помогают удержать типы, отношения и силу утверждений, а не просто красиво звучат (семантическое именование).
правильное соседство с другими паттернами: паттерн не присваивает себе решение проблем соседних паттернов. Это крайне важно для архитектуры FPF, ибо тут риск “двух источников правды” (ну, или риск неполного изложения решения, если не догадался посмотреть во много заранее непонятных мест FPF).
разделение интересующей сущности, её описания и публикации описания: не путаются сама интересующая сущность, её описание (эпистема), а также публикации с их разными формами (разные варианты пересказов и переводов на разные языки, форматирование в файлы, разделы, карточки, записи).
первичность интересующей сущности (а не описания этой сущности) и первого хода читателя: читатель сначала видит, с каким объектом работать и что делать, а не тонет в аппарате уточнений и перечнях возможных ошибок описаний.
точность выражения инженерного обоснования: понятно, какие утверждения чем поддержаны, где граница предмета текущего паттерна и где предмет решений других паттернов-соседей.
практический выигрыш от применения паттерна: применение паттерна реально что-то меняет (действие, решение, что-то ремонтирует), в паттерне также говорится о том, что выигрыш может быть в том, что делать ничего не надо (изменение в том, что будет посоветован явный отказ от применения текущего паттерна, а возможно, и переход к соседнему паттерну).
доступность первого применения: первый полезный ход не слишком дорогой, а заполнение тяжёлых таблиц, карточек, предоставление самых разных свидетельств появляются только там, где они действительно нужны (бюрократия и тяжёлый процесс всегда в наличии, но они честно появляются только после того, как есть уверенность в их необходимости. Если “мне только спросить” – обычно ничего заполнять не потребуется).
локальность ремонта паттерна, если это будет нужно: исправление в паттерне будет затрагивать минимальный нужный фрагмент и не ломать без нужды имена, связи и всё остальное (это про архитектуру самого паттерна).
покрытие примерами и антипримерами: хорошие примеры, варианты промахов в применении, антипримеры соответствуют широте заявленного применения паттерна.
связь с SoTA и исследованиями: источники не декоративны, а реально меняют решение, чеклист проверки применения решения, границы применимости, дают пример.
применимость матаппарата и сравнений: шкалы, баллы, пороги, сравнения и модели имеют понятную основу и не притворяются, что они точнее, чем они есть (скажем, если есть матаппарат, то он что-то улучшает, а не “просто есть”).
целостность паттерна и внешних текстов для его обнаружения (например, строк оглавления, резюме и т.д.): оглавление, карточки, краткие пересказы, подсказки для поиска и другие внешние представления ведут к тому же смыслу, а не создают второй паттерн рядом с какими-то искажениями от сжатия информации.
здоровье корпуса паттернов: локальное улучшение в оцениваемом паттерне не плодит какую-то путаницу в других паттернах.
дисциплина вариантов и обновлений: можно ли держать несколько недоминируемых вариантов, можно ли при обновлении смотреть только на обновлённый кусочек.
особые ограничения и самоприменение: если в паттерне есть безопасность, этика, обязательные ограничения или рекурсия, они явно ограничены и не превращают оценку качества в самосертификацию с итогом “всё хорошо по определению”.

Мета-характеристики оценки по этим шкалам, наследуемые из E.22, A.19.ECS, E.23:

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

И промпты, и паттерны я не пишу, чтобы крутить цикл. У меня это записано в harness и документах процесса. Я пишу reviewer: выполняй цикл улучшений для того или сего, критерий чаще всего – “вытягивай на пятёрочку”. А он уже сам всё оценивает и формулирует handoff для executor. Executor берёт этот handoff и закрывает указанные в нём ошибки, учитывает предложения по улучшениям. Далее я говорю reviewer – “проверяй, executor закончил”. И всё продолжается, пока reviewer не говорит “вопросов больше нет, идём дальше”. Это упрощённая схема, конечно, ибо у reviewer вопросы кончаются после трёх-четырёх циклов, а у меня вопросы возникают по мере понимания происходящего. Я внимательно читаю “рассуждения” executor в чате, в которых хорошо видно, как executor читит, выполняя предписания reviewer, а потом ещё и говорю reviewer, что ещё надо проверять, кроме обычной проверки “по шкалам” – и цикл ощутимо затягивается.

Брать, как обычно: в GitHub - ailev/FPF: First Principles Framework (FPF): Pattern language and core specification for admissible action in problematic engineering, research, and mixed human/AI work. · GitHub (любители MCP могут попробовать использовать https://fpf.sh/ – там немного отстаёт по времени от GitHub версии, но паттерны цикла улучшений там уже есть).