Как тренироваться FPF с использованием LLM + FPF

Описываю мой способ прокачиваться с использованием LLM + FPF.

Цель - освоить использование концептов в рабочих ситуациях. Прошить машинку типов набором концептов заложенных в фреймворк.
На данном этапе речь идет о концептах раздела A: A.0, A.1, A.2, A15 + немного из B.1

Вместе с LLM определили план прохождения материалов. Способ освоения - через сгенерированные задачи в разных контекстах. Разнообразные бытовые ситуации, чтобы не отвлекаться на сам контекст а сфокусироваться на самих концептах.
Освоение концептов в контексте ИТ с микро сервисами или описаниями сложных интеграций осложняет освоение и затормаживает.

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

Таким образом LLM составил программу из задач на разные бытовые ситуации, с шагом усложнения в +1%.

После каждой задачи происходит разбор и работа над ошибками.

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

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

Тут же я нахожу новые приемы в описании графов. Таким образом происходит пропитка.
Для ультразамедления и углубления пропитки начал использовать ручку и бумагу:

После того как появляется намек на интуицию в работе с графами, запрашиваю повышение сложности и снова в работу:

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

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

3 лайка

Вот мы с LLM дошли до низкоуровневой проблемы моего непонимания концепции bypass-ветки, join-ов веток, и того, что ускользало от моего понимания при решении задач на порядок шагов Г_work в которых есть условные ветки.
и я ему высказываю, что совсем он меня запутал с этими обходами:

и мы начинаем совместно искать объяснение которое объясняет этот момент.

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

и таким образом, маленькими кусочками дополняется моя внутренняя модель мира, отвечающая за решение задач на концепты FPF.

1 лайк

Еще улучшение, если совсем со временем не очень

Заметил за собой накопление усталости от выполнения упражнений.
нам нужен новый план:

“План выглядит надежным как швейцарские часы” (с)

И тут мне интересно, насколько сильна вера в чудеса. Чтобы выучить иностранный язык вроде английского или испанского, надо потратить 700 часов. Это при том, что ничего не надо понимать, просто говорить о понятном мире на иностранном языке. А вот FPF за сколько часов можно освоить? И какой успех будет у “микросессий”? Это обучение-развлечение, или пахота по паре часов в день? Тогда язык при паре часов в день без отвлечений можно выучить за год. А тут какой прогноз? 10 лет? 20 лет? Не забудется ли через месяц то, что было таким образом “пройдено мимо” в начале месяца? Кривые забывания ведь никто не отменял.

Добрый вечер,
Не знаю. Надо, наверное определить что мы понимаем под “освоить”.
Я для себя принимаю, что руками расписывать концепты FPF даже на уровне Core, даже для небольшой ситуации - вряд ли кто-то будет. Это уже будет делать машина. Но проверить ее возможно, если разобраться как эти концепты между собой взаимодействуют и сочетаются.

выделяю на эти занятия от 1 часа в день (минимум), бывает что и до 2-х доходит (зависит от остатков внимания). Эти занятия идут отдельно от рабочих проектов, к которым приложен FPF. Там тоже может набежать до 2-3 часов при обновлении артефактов проекта. И именно для того чтобы понимать что мне нагенерировала машина (а главное почему именно так она нагенерировала) я пошел в это изучение.
Дробление возникло от того, что в каких-то моментах я понимаю, что не понимаю каких-то более низких принципов, или мне мешают понять уже накопленные знания (графы DAG оказываются не интуитивными (для меня по крайней мере)).

Это же зависит от количества реколлов. Сейчас я сосредоточился на базовых концептах FPF. Расширенные не трогаю.
От этих занятий пока наблюдаю пользу, так теперь в рабочих проектах более осознанно добавляю или меняю артефакты, чтобы модель лучше отражала реальность.

С графами вам же для causal inference надо – вот навскидку объяснение (можно и от FPF получать, но длинный текст специально для этого составленный может быть легче в понимании): Causal Inference: DAG / Хабр

Но это да, для понимания FPF хорошо бы понимать какие-то более низкоуровневые идеи, которые в нём только используются. Довольно много этих идей в наших руководствах. Там как раз объяснения.

Но ваш эксперимент интересен. Посмотрим, что из него получится.

да, не буду утверждать, за всех, но у меня непонимание чего-то низкоуровневого (оно то по своей сути на самом деле вовсе и не сложное, просто надо немного набить руку об него) ломается понимание концепта в целом. есть части которые очевидны, а есть какой-то кусок, который требует бОльшего внимания. Вот те же самые описания Loss в мостах. они очень не интуитивные и требуют внимания для начала чтобы уловить саму суть потерь при переходе. возможно есть таланты, которые сразу ее ловят. или это я туповат :sweat_smile: и мне приходится такие вопросы брутфорсить (пару сотен простых задач и решение таких вопросов будет на автомате).

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

А потом я решил спросить машину " а не творю ли я какую-то дичь" со всеми этими упражнениями ?

и выдала машина свой ответ с “много букв и таблиц”. Выглядит убедительно.
Но самая суть была в этой таблице:

и вот тут про разделение обязанностей:

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

Тут мы снова натыкаемся на доменные знания и знания (больше понимания) того как машина начинает размышлять под действием fpf.

Надо так же иметь в виду принцип, что когда “ты вглядываешься в пустоту, пустота вглядывается в тебя”. Проявляется это в том, что чем больше ты трогаешь руками fpf тем больше это воздействует на тебя самого, оказывая влияние на то как вы начинаете думать про окружающий мир.
Даже тупое перепечатывание правильных ответов машины на задачи (ака работа над ошибками) через мышечную память вбивается в голову. такое может быть расценено как дополнительная допропитка в случаях когда внимание уже заканчивается.

Такие инсайты по состоянию на сегодня (2026-06-18).

2 лайка

Я бы внёс три поправки.

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

Вторая: таблица “что остаётся за человеком” немного другая: это “что надо освоить, чтобы совместно мыслить”. Там надо добавить “EntityOfConcern и вся цепочка сущностей публикации и публикационных форм, включая MVPK + BoundedContext/проект” как первую строку. До U.Method vs U.Work есть ещё более ранний вопрос: “о чём вообще утверждение?” Это объект проекта? описание объекта? публикация? carrier? evidence source? gate result? decision? в чём вообще проект, где его границы? Если это не установлено и не сообщено агенту (для этого надо осознать, что это надо сообщить!), все последующие таблицы будут красивыми, но мимо. FPF прямо формулирует первую практическую ориентацию: входить надо не по порядку глав, а по тому, что вы реально пытаетесь решить, опубликовать или стабилизировать: что там за проект как контекст и какая в нём проблема. Или хотя бы спросить об этом AI-агента, чтобы было общее с ним понимание происходящего.

Третья: “производное” не значит “простое”. Например, Part G, SoTA packs, NQD, граф структуры преобразований (бывший граф трансдукций, его уже нет) и GateFit производны от базовых различений, но сами по себе сложны. Правильнее сказать: “их можно осваивать позже, когда разберёмся с азами”.

Вообще, я с похожими проблемами написал вчера пост: lytdybr: ailev — ЖЖ

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

Да, его прочтение и натолкнуло на мысль задать такой вопрос LLM-ке.

вызвало такую ассоциацию:
есть Python как язык (который заявляется как хороший statrter для широкого круга заинтересованных лиц). в нем можно работать на уровне стандартной библиотеки (как база, знание синтаксиса языка и подмножества встроенных операторов языка + базовые знания по циклам, ветвлениям, логике), считать уравнения на уровне арифметики и простой логики. и этого будет хватать за глаза для текущих задач и потребностей.
можно начать идти в numpy и более сложные вычисления (низкоуровневые операции, битовые маски, сдвиги, работа с памятью).
можно пойти в разработку новых абстракций языка.
можно начать заниматься оптимизацией вычислений по скорости или памяти и проч. есть где разгуляться. выбор за конечным пользователем и его желание / способности в это погружаться с понятной целью.
или язык С.
там тоже можно оставаться на уровне математики и стандартной библиотека, а можно занырнуть в область арифметики указателей для оптимизации всего что можно оптимизировать и весело стрелять себе в ноги.

существует базовый уровень, владения которым достаточно для 80% задач и ситуаций. а остальное - требует дополнительных усилий, с пониманием того “зачем?” и что вложения усилий как минимум не утянут в сильные минуса и игра будет стоить свеч.

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

получается, что это работает в 2 стороны - ИИ дообучается на конкретном агенте и его мокрой нейронке, и мокрая нейронка агента так же дообучается на ИИ.

отсюда получается, что работа со сложными штуками/абстракциями/концепциями донастраивает и меняет структуру связей в мозге агента. если ИИ будет постить агенту котиков и мемасы, то соответственно мозг заточится под котиков и мемасы.
Если работать с FPF то соответственно будет формироваться блок отвечающий за FPF. Далее надо будет работать над задачей стыковки “яблок из задачи и яблок из жизни” - приземлять и корректно размечать объекты в проектах и ситуациях, чтобы оптимально решать задачи (по аналогии с программированием = матрицы можно перебирать с помощью вложенных циклов “for”, а можно использовать специальные операции с матрицами ( n-мерными массивами) на базе векторизации. разница в эффективности заметная. но цикл “for” для понимания и использования требует меньше ресурсов, чем специальные операции с многомерными массивами).

Если вы уже разобрались с “яблоками из жизни и яблоками из задачи” – то этого уровня эпистемологии вам вполне уже будет хватать для работы с AI+FPF. Понимание этой байки (и вообще знание этой байки) – это уже бездонная пропасть, отделяющая вас от “простых людей с улицы”. Но там, конечно, и дальше есть много чего для понимания, развитие бесконечно.

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

  • самом содержании проекта,
  • на концептах FPF
  • на артефактах которые получаются на выходе
  • следить за тем, не получилась ли бесполезная (а местами и вредная) шляпа, с которой что-то надо делать по ходу проекта
  • выполнять преобразования артефактов по мере появления понимания и осознания что артефакт требует корректировки и модернизации (уточнение, разделение, добавление нового, вывод из оборота старого, объединение)
  • корректно провести все эти операции (везде все отразить, чтобы все со всем билось)
  • все эти операции корректно отразить в журналах проекта
  • и это еще не дошел до того, как это аккуратно объяснить коллегам (до этого правда пока не дошло, но если у меня это сложно проходит, то скорее всего коллеги быстро соскочут с этой темы не дождавшись первых эффектов от перехода на такой формат работы)

у меня проект по внедрению СЭДа. в нем получилось порядка 20 контекстов, 20+ альф (кстати, новые FPF уже ругаются на альфы как концепт), 20+ ролей. там еще по мелочи, реестры, справочники, матрицы + порядка 10+ инструкций по тому как этим хозяйством пользоваться. наработка ежедневных, еженедельных и ежемесячных ритуалов требует так же дисциплины и внимания.
тут еще сама парадигма управления проекта требует переключения с варианта project+gant на системную схему.

со стороны я себя вижу так:

вот сегодня ко мне пришло понимание что есть в проекте реестр рисков (который был сгенерирован ранее) и с ним надо тоже производить операции. сгенерировал пошаговую инструкцию и пойду тренироваться. Такое озарение возникло после того как стало чуть привычнее выполнять операции с более базовыми артефактами проекта.

и еще начал пробовать читать мосты между артефактами. пробовать думать что это означает в проекте и как это может выглядеть в жизни.

Ну вот если вы хотите прямо в проект идти, то вам нужны паттерны для вашей предметной области проекта – SPF. Для этого вам ещё надо быть методологом, понимать, как пишутся паттерны. Скажем, для проблемы документооборота вам надо понимать, что есть forces, которые двигают итоговое решение в разные стороны: одна сторона в сторону ответа на вопрос “кто виноват” (и тогда СЭД будет грубо говоря “под начальником канцелярии”, в службе документооборота, “кто виноват” всегда однозначно понятно в любой момент), а другая – ответ на вопрос “кто что кому поручил и что делается сейчас” (и тогда СЭД будет “под начальником инженерной службы”, а “кто виноват” решается “содержательным рассмотрением”, ибо акцент на простоте процедур). Это известная развилка: в одну сторону реально СЭД классический и системы документооборота, в другую – issue trackers. Но по сути дела это же одно и то же! Но на разных уровнях “представления документов в судебные инстанции”. И вот тут нужна библиотека типовых решений предметной области case management (а папка “Дело №___” называется case file), которую можно трактовать и как “выдача поручений и контроль исполнения”. Всё, генерируем пачку SoTA паттернов как реализацию SPF, делаем из них проектные регламенты, дальше работаем по этим регламентам. То есть надо “знать FPF настолько, чтобы уметь пополнять”.

Извините что влезаю без спросу (впрочем в МИМ это вроде как не порицается).
В своё время начиная один проект по внедрению новой системы (сейчас её наверное можно назвать BPM) наткнулся вот на эту статью. Несмотря на размер, прочёл несколько раз.
Было бы интересно сейчас сделать её разбор с помощью FPF, с другой стороны она ценна именно как описание реального опыта (тот самый case), а разложить всё происходившее по полочкам можно и своим естественным интеллектом (тем более и автор это почти целиком сделал). Закон Гудхарта там тоже в яркой форме продемонстрирован)

P.S. Прочтение комментария об SPF вдруг привело меня сейчас к открытию, что SPF и онтология предметной области - это разные вещи.
Сейчас это кажется очевидным, однако последние полгода я почему-то был уверен что это одно и то же.
Учиться и учиться ещё…

да, я давно эту статью видел, и кажется даже читал (порядка 3000 лет назад).
История интересная, она про то как техническими средствами пробовали починить социальную проблему.
Как я понял эту историю - была сделана ставка на то, что за счет программы мы наладим дисциплину, но работу с конечными пользователями нормально никто не проводил (а по идее должны были бы проводить какие-нибудь внутренние коммуникации или кадры). т.е. техническое внедрение программы должно было быть поддержано морально. тут классическая проблема - не учли интересов подмножества заинтересованных сторон. и получили то что получили.
я такое наблюдаю частенько когда делается ставка на новое решение - “сейчас купим, установим, и заживем”. правда, на этапе внедрения в компании может случиться 2 полных обновления руководства. но это такие мелочи :melting_face: а когда внедрение завершается уже некому работать на этом решении. бывает… :nerd_face:

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

что касается самой статьи - надо несколько проектов провалить или завести в кризис, а потом вывести (по возможности) чтобы полноценно научиться внедрять системы )).

1 лайк

Ну вот практически все описанные вами моменты разобраны в руководствах, скажем про “осторожней с программами, обычно у вас в придачу наладка работы коллектива её пользователей, и она часто не оговорена, но весьма ресурсозатратна”, а ещё системная инженерия с её CI/CD, а ещё системный менеджмент с прямыми советами про софт и реализацию каких-то методов работы. И ещё у вас словарь, который поощряет плохие практики (например, не сбор гипотез о том, как всё должно работать, а сбор требований – вроде это “просто лексика”, но нетъ!).

Конечно, SPF – это паттерны, то есть предложение решения проблем при попадании в проблемную ситуацию. А онтология – там проблем нет, там “вот такие у вас в мире сущности”. Маленькая часть SPF, там U-kinds и онтики тоже есть, но ведь не только они!

1 лайк