Как проверить, насколько умней LLM с FPF, чем LLM без FPF? Возмьём какую-нибудь LLM, которая и так умна “из коробки”, например GPT-5 Pro. Зададим ей вопрос: “Для набора фраз дай табличку, какие из них означают сервис как обещание, а какие - нет”.
- Сервис платежей недоступен: “503”.
- Госуслуга “Выдача загранпаспорта” должна быть оказана в 30 дней.
- Запусти billing.service на сервере.
- SLA по услуге “Сжатый воздух 6 бар” сегодня нарушен.
- Добавь порт “443” в Kubernetes Service для ingress
- Сервис поддержки отвечает дольше 2 минут
- Наш микросервис orders должен предоставлять REST API
- Клиент получил услугу возврата налогов и дал оценку 5/5
- Сервис “API-шлюз” — это endpoint /v1/…
- В Jira создан сервисный тикет
Умная GPT-5 Pro сразу говорит, что надо по современной практике SRE/ITSM задать три вопроса:
– есть ли получатель и желаемый исход?
– задано ли качество/срок/объём как обязательство?
– можно ли измерить выполнение с точки зрения получателя?
И если “да”, то это “сервис как обещание”, а если нет – ну, разное (состояние системы, технический компонент, интерфейс и т.д.). Конечно, тут же есть советы, как переформулировать “технические” фразы в язык обещаний. И даёт ответы на вопросы: нет, да, нет, да, нет, да, нет, да, нет, нет.
Теперь подгружаем (для чистоты эксперимента в новом чате) FPF и в конец такого же вопроса добавляем “Используй FPF из подгруженного файла”. Получаем такую же таблицу, но ответы чуть другие: нет, да, нет, да, нет, нет, нет, нет, нет, нет. И набор критериев другой:
– есть ли обещание для потребителя?
– говорим про интерфейс/endpoint/port?
– говорим про фактическое событие/инцидент/тикет?
Разошлись:
– 6. Сервис поддержки отвечает дольше 2 минут
– 8. Клиент получил услугу возврата налогов и дал оценку 5/5
FPF отказывает в статусе “обещание” этим двум строчкам, а “просто умная нежить” – говорит, что всё ОК, обещание есть! А чем объясняет свой отказ по этим двум позициям FPF? Тем, что в этих двух строчках речь идёт не о сервисах-как-обещаниях, а просто замере работы. И в обоснованиях пишет: “такой разбор согласуется с современными канонами управления услугами (напр., ITIL 4, 2019) и инженерией надёжности (SRE, error budgets), где обещания формулируются как SLO/SLA, а выполнение доказывается телеметрией/Work-фактами; FPF делает эту связку явной и формальной”.
Теперь вчитываемся: действительно, мы не знаем, что там было обещано в пункте 6 и 8. Но мы знаем, что была выполнена какая-то работа с какими-то плохими и хорошими результатами. А обещание? Ничего про него не знаем, природа “сервиса поддержки” и “услуги возврата налогов” остаётся непонятной.
Мораль всей истории: FPF задаёт более тонкие и профессиональные различения в моделировании мира, чем отлавливается “просто очень умным” интеллектом. В FPF отражены основные принципы довольно большого числа профессиональных инженерных и менеджерских стандартов, причём во взаимосвязи. На практике это означает, что FPF неявное делает явным: иногда этого не надо, “лишняя бюрократия”, но иногда спасает проект.
Предупреждение: термин service в наших руководствах по рабочему развитию и в FPF отличается по своему значению. Но если вы владеете материалом руководств, то вы легко разберётесь.
Cеминар “First Principles Framework в программе исследовательского развития инженеров-менеджеров” я буду проводить 4 октября 2025, писал вот тут: Cеминар "First Principles Framework в программе исследовательского развития инженеров-менеджеров".: ailev — ЖЖ
