Для работы использовался FPF версии на 2026-06-12.
LLM: Qwen 3.7-Plus
Зачем: эксперимент на тему универсальности фреймворка и применимости его к разным ситуациям (не только рабочим проектам).
Немного контекста (вот прям так как я описывал эту ситуацию (опыт не приятный, рекомендую в такие ситуации не попадать) в LLM):
“я хочу описать в терминах fpf системную схему ситуации: есть собака стаффорд, у него была обнаружена болезнь в результате которой он прошел операцию в вет клинике. ее выполняли хирурги. перед операцией проводилась сдача анализов а рамках подготовки к операции. операция была запланирована, согласована. назначена на дату. после этого операция была проведена. во время операции были непредвиденные осложнения и была сделана еще одна операция. были проведены дополнительные исследования между операциями и был консилиум врачей по выработке стратегии устранения последствий. после этого собаку хозяева забрали домой довезли до дома и дома собака проходит реабилитацию и ожидает результатов биопсии. хозяева проводят процедуры, дают таблетки по графику, обрабатывают швы, меняют трубки трахеостомы. закупают необходимые лекарства и спец еду для оперированных собак. собака постепенно восстанавливается и улучшается ее состояние, что подтверждается результатами анализа крови. вот для начала сформируй основные артефакты. еще добавь про оплату услуг клинике и про переливание плазмы, которую теперь хозяева должны компенсировать клинике через доставку плазмы в том же объеме. плазму необходимо найти в банке крови и купить и доставить в клинику.”
Далее немного обсудил с LLM детали ситуации и на выходе получил модель ситуации.
И тут напрашивается вопрос: ну хорошо, мы получили набор артефактов, которые взаимосвязаны. что мы можем с ними дальше делать? какая от них может быть получена польза?
Тут видно, что даже в бытовых ситуациях могут возникать моменты которые могут быть разложены на составные части и быть проясненными. Результат требует привыкания при чтении (или дополнительной адаптации для людей не знакомых с fpf).
Тем не менее он выглядит рабочим (заземленным).
Так же видно что FPF+ LLM это не “silver bullet” которая автоматически за вас все порешает и исправит (настолько хорошо, что мозги можно поставить на полку).
Она не снимает необходимости в знаниях (даже понимании) из предметной области. Не снимает необходимости думать. Не снимает необходимости понимать суть и смысл базовых концептов фреймворка.
Иначе LLM будет генерировать тонны контента, а проверить ее на адекватность вы ее не сможете.
Это эксперимент не содержал исходной цели (заранее предопределенной). это просто вариант на тему “а что если?”. просто путь (как у самурая).
Модель можно разложить по таблицам экселя (или иным табличным процессорам) для использования в работе. Примерно так я сейчас веду на работе проект по внедрению СЭД. но сегодня модель заявила что Альфы:
Важное методологическое уточнение: В спецификации FPF термин «Альфа» (из стандарта OMG Essence) отсутствует. FPF оперирует понятиями U.EntityOfConcern (сущность, представляющая интерес) и U.Holon (система с отслеживаемой динамикой состояний). То, что вы в своих корпоративных проектах (миграция, СЭД) называете «Альфами» (инфраструктура, процессы, договор), в FPF строго классифицируется как U.Holon (для систем) или U.Episteme (для документов/планов), чтобы избежать онтологического коллапса.
Здесь интерес в том, насколько полезные модели можно вытянуть из ситуации. Пока не понял сам для себя, можно ли такую ситуацию из жизни с натяжкой и потерями сопоставить с проектом в контексте корпорации. будет ли такое сравнение справедливым. или все-таки это принципиально разные контексты между которыми нет ничего общего.
Но тут опять же нет изначально цели что-то выяснить что скрыто или не очевидно изначально. ситуация (на мой взгляд) полностью прозрачна, отношения между мной как клиентом и клиникой как исполнителем достаточно прозрачны. не так формализованы как в границах корпорации и в границах отношений между разными корпорациями. но определяются действующим законодательством. как-то так. надеюсь, ответил.
на самом деле я так на это смотрю: есть много языков программирования, есть ассемблер, есть машинный код (аппататно-зависимый). Допустим (очевидно что это не совсем так, но пока в это опустим для простоты), что на любом языке программирования можно описать решение любой задачи. Но языков программирования именно потому так много (одна из причин), что на одних языках удобно писать эффективные решения одних классов задач (например MatLab/Octave - математические вычисления, LISP - символьные вычисления, Python - универсальный язык для широкого класса задач - стандарт в ML/DA, ну и т.д.). Но вне зависимости от того на каком языке вы пишете, он будет через цепочку абстракций сконвертирован в машинный код и исполнен на железе. И в теории можно любую задачу таким образом описать в машинном коде. но это может быть запредельно сложно с тз трудоемкости такого описания со стороны оператора (много кода набирать и описывать слои абстракций предметной области, когда нужные объекты могут быть уже готовыми к использованию в языке программирования).
так вот, мне было интересно, насколько будет полезной модель на выходе в конкретной бытовой ситуации. очевидно, что в описанной ситуации нет какой-то изначальной сложности на которой фреймворк раскрылся бы и ситуация заиграла бы новыми красками. но вдруг? )
да, просто играюсь, лишний раз взаимодействую с фреймворком, смотрю как он взаимодействует с данными.
в реальной рабочей ситуации фреймворк действительно сработал и помог разобраться. но там и исследовался сквозной производственный процесс с передачей данных из CAD->ERP ->MES для построения графика закупок с разделением по цехам и изделиям. там оно сработало.
Ага. Тут и да, и нет. FPF на то First principles, что задачу (а лучше даже проблему) есть возможность сформулировать на самом верху абстракций, на естественном языке. В этом же смысле, все языки программирования решают задачи, которые люди обычными словами описывают. И про классы задач я бы тоже поспорила, узко профильные языки есть, но все остальное распределение довольно мало зависит от “потому что вот это максимально удобно и правильно делать ровно вот этим инструментом”.
Я к тому что классы решаемых фреймворком задач довольно широкие и от предметной области мало зависят. Потому что “принятие решений” какую БД выбрать для реализации фичи M, какую клинику выбрать для лечения собаки, в какой вуз поступать подростку это всё класс задач - принятия решений. И его FPF вполне покрывает.
А “трудоемкость написания кода” она как будто не на вашей стороне. Тут есть уровень формальности описания, вот вам модель насыпала холонов, эпистем, оно вам надо? Если интересно, как системному программисту в регистрах процессора ковыряться, ковыряйтесь. Если не интересно, надо просить отвечать “по-человечески” на языке инженеров-менеджеров. И внутрисистемный сленг исчезнет…
Вообще автор обещает(ся) цикл семинаров про FPF, чтобы магия перестала быть магией. Ждём)
да, это близко к тому, что я (как сам для себя думаю) пробую решить - проследить и разобраться как LLM начинает мыслить в концептах FPF. и можно ли научиться самому даже в пределах базовых концептов натренироваться так же на лету парситиь из сырой речи (протокола) концепты. это же та же самая машинка типов с BORO-набором, но более продвинутая.
я прошу перевести на язык простых людей не знакомых с fpf, когда надо показать результат коллегам. помогает )
