Промпт "распиши P2W из E.TGA в FPF для моей ситуации: <текст ситуации>"

ailev · 03.Декабрь.2025 15:23:56

Цепочка “от принципов к работе” (P2W) из FPF
U.SubstrateFormalization (чисто математический субстрат; types/effect-signatures/effect-rows/inference; NoEffectRealizationInSubstrateFormalization)
→ U.OntologyAuthoring (выделение объектов в мире выбор математических объектов из математического субстрата моделирования этих объектов)
→ U.CHRAuthoring (выбор характеристик, которыми можно описать объекты выбранной онтологии, но без собственно измерений)
→ U.PrincipleFraming (первые принципы + Measurement‑CHR binding; без законов применения)
→ U.MechanismRealization (Mechanism.Intension: CombinatorAlgebra, LawSet, AdmissibilityConditions, Γ_timeRule, Γ_planeRule, TransportRef)
→ U.ContextNormalization (UNM) (CG‑Spec, ComparatorSet, TransportRegistry(Φ); normalize‑then‑compare; method‑independent)
→ U.SelectionAndBinding (set‑returning) (кандидаты + локальная привязка; lawful orders; ParetoOnly)
→ U.WorkPlanning (planning) (осуществимость, расписания, EvidenceHooks)
→ U.WorkEnactment (enactment) (Bind values in WorkEnactment; фактические результаты/учёт/телеметрия)
→ U.EvaluatingAndRefreshing (G.11) (edition, slice‑scoped refresh, QD‑архивы, обратная связь)

Где цикл в потоке? Между U.SelectionAndBinding ↔ U.WorkPlanning (TAMP/MPC – task and motion planning, model-predictive control).
Где «прихват параметров среды»? В U.ContextNormalization (UNM) до цикла;
Где появляются значения запуска? Только в WorkEnactment.
Что поддерживает проверяемость? CSLC‑законность сравнения; точные операции на U.Transfer (ConstrainTo/CalibrateTo/CiteEvidence/AttributeTo).

Для чего такое надо? Чтобы сориентироваться, что вообще происходит, о чём надо подумать. Это что-то вроде чеклиста, “примитивный граф трансдукций”, от которого можно отталкиваться в работе. Получить такое просто: подгрузить FPF (GitHub - ailev/FPF: First Principle Framework) и дать промпт “распиши P2W из E.TGA в FPF для моей ситуации: <текст ситуации>”. И что с этим потом делать? Смотреть на то, что не пришло в голову, призывают же “thinking out of the box” – вот это оно и есть.

Где тут первые принципы? Идите к началу цепочки и задавайте вопрос: а если поменять что-то в этом начале цепочки (скажем, если не думали вообще о теории, а теперь вдруг подумали! не думали об онтологии, а теперь подумали!), как это отразится на том, что вы сейчас делаете? Не появилось новых идей?

В слайдах семинара 7 декабря (попадать туда по вот этой ссылке: Telegram: Join Group Chat) я дам пример 1 – промышленный манипулятор, собирающий детали на конвейере (нет, не end-to-end нейроконтроллер, а old school подход). Тут дам ещё парочку. Это просто абстрактные примеры, много от них ждать нельзя, но общую идею можно понять.

Пример 2. Автоскейлинг микросервисов в облачной системе
У нас распределённая система микросервисов, надо автоматически масштабировать реплики под нагрузку, не перегружая базу и не плодя лишние ресурсы.

U.SubstrateFormalization (математика)

теория очередей (M/M/k, более сложные сети);
марковские процессы, стационарные распределения;
контроль нагрузок и SLA (вероятностные гарантии, tail latency);
вариационная формулировка EM / RL (если автонастройка).

U.OntologyAuthoring (онтология)

сущности: сервисы, инстансы, запросы, очереди, базы, кэш;
отношения: «кто кого вызывает», «кто чьим bottleneck».

U.CHRAuthoring (характеристики)

для сервисов: RPS, latency percentiles, error rate;
для инстансов: CPU, RAM, I/O, warmup-time;
для SLA: P99 latency ≤ X, error rate ≤ Y.

U.PrincipleFraming (принципы и законы на их основе, и что замеряем в мире для их удовлетворения)

из теории очередей: стабильность (λ < μ·k), формулы связей между RPS и latency;
принцип управления: минимизировать cost = ресурсы + штрафы за SLA-нарушения;
CHR↔measurement (latency ↔ замеры из трейсов / Prometheus, load ↔ CPU+RPS, violations ↔ события алёртов).

U.MechanismRealization (сам механизм автоскейлинга, семейство методов, из которого будем выбирать конкретный метод):

CombinatorAlgebra: измерять → прогнозировать → решать задачу автоскейла → отправлять команду в оркестратор;
LawSet: конкретные законы принятия решений (HPA-подобный алгоритм, RL-агент, MPC на очередях);
AdmissibilityConditions (не превышать лимиты кластера, не масштабировать в моменты deploy’ев, учитывать холодный старт;
Γ_timeRule: период переоценки (например, каждые 30 секунд), горизонты предсказаний;
Γ_planeRule: пространства измерений (нормализованный load, лог-метрики и т.п.);
TransportRef: как доставлять решения в Kubernetes/орchestrator.

U.ContextNormalization (UNM)

собирает метрики из разных источников (Prometheus, logs, tracing),
приводит их к единому виду (единицы времени, единицы нагрузки, сглаживание/агрегация по окнам;
проверяет freshness: если метрики старые/дырявые → выдаёт FreshnessRequest на перезапуск агента метрик, проверку конфигурации сбора.
регистрирует транспорты и калибровки, например, пересчёт load в units, которые использует конкретный механизм (ML-модель, плато-триггеры и т.п.).

U.SelectionAndBinding cелектор метода по итогам замеров в реальном контексте:

на вход: множество возможных конфигураций (число реплик, лимиты ресурсов, разные схемы троттлинга);
ComparatorSet: Pareto по {SLA violation risk, cost, robustness};
на выход: множество допустимых конфигураций (set-returning), никакого скалярного “вот это бери” (ибо ресурсы ещё непонятны).

8) U.WorkPlanning – планирование:

выбирает конфигурацию/набор конфигураций для ближайшего горизонта;
учитывает окна deployment’ов, maintenance, политики безопасности;
проверяет, нет ли конфликтов с другими задачами (другие управляющие петли, ручные операции админов);
расставляет EvidenceHooks: какие метрики/trace-спаны логировать, какие события хранить для последующей оценки.

Цикл Selection↔Planning:

если план неосуществим (конфликт с деплоем, нехватка ресурсов, политики безопасности),
возвращаемся к SelectionAndBinding за альтернативным набором кандидатов.

U.WorkEnactment – вот только тут актуальная работа:

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

U.EvaluatingAndRefreshing – это ещё не вся история, надо отследить результат и поправиться:

сравнение ожидаемых SLA с фактическими;
анализ: сколько раз сработали алёрты, сколько стоили ресурсы, были ли ситуации over/under-provisioning;
обновление версий (editions): возможно, корректировка ComparatorSet (более жёсткие критерии), refresh ML-модели/параметров HPA, запись кейсов и результатов в QD-архив (Quality-Diversity по стратегиям автоскейла).

Пример 3. Управление дозировкой лекарств в терапевтическом отделении
Система поддержки принятия решений подбирает схему дозирования для пациента (например, антибиотик или антикоагулянт), учитывая множество факторов и ограничений.

U.SubstrateFormalization (выбор математики, я когда-то на кафедре клинической фармакологии помогал программировать такие модели на тогда ещё более чем современных СМ-4):

диффур/ODE-модели фармакокинетики/фармакодинамики (PK/PD);
вероятностное моделирование (байесовские модели параметров пациента);
оптимальное управление/контроль под риском (cost = эффективность + побочные эффекты).

U.OntologyAuthoring – формулируем онтологию, с чем работаем:

пациент, орган/система, заболевание, лекарство, курс лечения;
параметры пациента: возраст, вес, функции органов, другие лекарства;
события: доза, приём, измерения (анализы крови, давления и т.д.).

U.CHRAuthoring – характеризация, что должны отслеживать:

концентрация препарата в плазме,
биомаркеры эффективности (например, снижение температуры, маркеры воспаления),
показатели токсичности и побочек,
риск осложнений (вероятности неблагоприятных событий).

U.PrincipleFraming – принципы и законы предметной области, а также что для них замерять в реальности:

законы PK/PD: всасывание, распределение, метаболизм, выведение;
клинические принципы: «эффективная концентрация должна быть в таком-то диапазоне», «суммарный риск побочек не должен превышать X»;
CHR↔measurement: концентрация ↔ результаты лабораторных тестов, эффективность ↔ динамика клинических показателей, токсичность ↔ специфические анализы.

U.MechanismRealization – вот тут семейство возможных схем лечения:

CombinatorAlgebra: модель PK/PD → модель риска → оптимизатор доз (MPC/RL/heuristics);
LawSet: конкретная диффур-модель, уравнения для риска;
AdmissibilityConditions: дозы не выходят за пределы, не конфликтуют с другими лекарствами, учитывают ограничения клиники (формы препарата, частота измерений);
Γ_timeRule: шаги пересмотра (каждый день/каждый анализ), горизонты (курс на 7–14 дней);
Γ_planeRule: units концентраций, доз, временных интервалов;
TransportRef: как забирать данные из LIS/EMR (laboratory information system, electronic medical record) как возвращать рекомендации в медкарты.

U.ContextNormalization (UNM)

забирает данные пациента, анализы, сопутствующие диагнозы;
нормализует: единицы анализов (разные лаборатории дают в разных единицах), временные шкалы (время приёма, время забора анализа);
проверяет актуальность: если анализы старые/неполные → FreshnessRequest: назначить новые анализы;
TransportRegistry(Φ): хранит способы перевода разных форматов/единиц, учёт качества данных (ошибки, пропуски).

U.SelectionAndBinding – селектор схем лечения:

на вход: множество вариантов схем: разные дозы, интервал, длительность, комбинации лекарств;
ComparatorSet: Pareto по {эффективность, риск побочек, нагрузка на пациента/систему, стоимость};
на выход: множество допустимых схем (возможно, 2–3 варианта с разными акцентами: более агрессивная vs более щадящая).

U.WorkPlanning – планирование терапии:

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

Цикл Selection↔Planning:

если в WorkPlanning выясняется, что некоторые схемы нереализуемы (нет препарата, нет мощности лаборатории, конфликт с другими процедурами),
возвращаемся к SelectionAndBinding за другими вариантами.

U.WorkEnactment – вот тут реальное лечение:

пациент получает конкретные дозы в конкретные моменты;
проводятся реальные анализы и наблюдения;
регистрируются фактические данные: приёмы, пропуски, побочные эффекты, результаты анализов и клинической оценки.

U.EvaluatingAndRefreshing – оценка и обновление:

сопоставляем прогнозы PK/PD и риск-модели с фактическими концентрациями и динамикой состояния;
корректируем схему: возможно, меняем дозу/интервал, возможно, меняем препарат;
обновляем edition’ы: уточняются параметры модели для данного пациента, пополняется QD-архив: какие схемы у каких кластеров пациентов работали лучше;
цикл продолжается до окончания курса.