Vanilla LLM против LLM+FPF
Когда говорят “я использую LLM”, почти всегда речь идёт о vanilla LLM. Инженер спрашивает модель, как сделать фичу, менеджер — как объяснить её заказчику. AI могуч, даёт на первый взгляд адекватные советы, но тащит в них всё подряд “попсовое”, ибо его задача – не говорить неприятную правду, а говорить приятные слова, и это будут обтекаемые мягкие формулировки из попсовых бизнес-книжек, болтовня из маркетинга, случайные «лучшие практики» двадцатилетней давности из случайных предметных областей.
У FPF тут роль фильтра для всего этого приятного “бла-бла-бла”, он становится между AI-агентом и человеком, обеспечивая инженерную предвзятость (bias) для работы AI-агента. LLM+FPF делается так: файлом подгружается FPF-Spec.md из GitHub - ailev/FPF: First Principle Framework, а LLM вы сообщаете, что “В файле у тебя спецификация FPF”, чтобы уж точно ответы были с её использованием.
LLM генерирует варианты, она — генератор паттернов: дописывает код и текст, вспоминает типовые решения, объясняет одно и то же разными словами для разных аудиторий. У неё нет встроенного понимания, что такое “нормальное мышление”, ибо она обучена на огромной интернет-помойке текстов, где какой-нибудь «сервис» может быть и бизнес-услугой, и микро-сервисом, и SLA-договором, и службой поддержки. Если вы спросите вашу любимую LLM “объясни, что такое сервис”, она честно намешает всё это в один текст. На слайдах это выглядит убедительно, но в коде, в документации, в договорах потом выясняется, что «сервис» у всех разный и сотрудничество разваливается на глазах, надо всё переделывать. Вайб-использование LLM, то есть “разговор по душам под настроение” – опасно. LLM полезна, подсказывает оригинальные ответы, но уже через пару ходов разговора оказывается, что её рекомендации не стыкуются с рекомендациями, выданными две минуты назад. Граница между “обоснованно” и “красиво звучит” размывается, бенчмарки это не отслеживают, поэтому LLM оказывается совсем не умнее людей в этом плане. Люди с хорошо подвешенным языком тоже несут бессмыслицу, но всем нравятся (и вам тоже! А может, вы и сам такой). Есть работы, которые пытаются это исследовать, их результаты обескураживающие: reasoning resilience у моделей крайне низка, [2512.01948] How Far Are We from Genuinely Useful Deep Research Agents?, “How Far Are We from Genuinely Useful Deep Research Agents?” (обзор на русском – Telegram: View @gonzo_ML_podcasts, “Текущие бенчмарки часто путают «умение болтать» с «исследовательской строгостью», позволяя моделям проскакивать за счёт генерации гладкого, но бессодержательного текста. Работа квантифицирует явление Strategic Content Fabrication (стратегическая фабрикация контента), когда агенты имитируют форму профессионального анализа (цитаты, академический тон), подделывая содержание”).
FPF работает ровно с этим: это архитектура мастерства сильного мышления. FPF вытаскивает из помойки субличностей LLM более-менее осмысленного инженера-менеджера.
Пример с характеризацией резидентов и резидентуры
Вот у меня мастерская инженеров-менеджеров (МИМ) и я пытаюсь запустить программу резидентуры для инженеров-менеджеров. Беру vanilla LLM и даю промпт: “Запускаем резидентскую программу для инженеров-менеджеров, нужно придумать формат и метрики успеха”. Если не добавлять FPF, то LLM ответит вполне предсказуемо: набор лежащих на поверхности идей формата (воркшопы, нетворкинг, менторство – обычное менеджерское “бла-бла-бла” из типовых блог-постов), немного модного словаря про “коммьюнити” и “лидерство” (куда же без них!), общие KPI вроде “удовлетворённость участников” и “количество завершённых проектов”. Спасибо, Кэп, мы так и сами можем, не нужна нам LLM, чтобы такое сделать! Хорошо подвешенный язык отлично мелет на бизнес-сленге, но это не продвигает.
Если же подгрузить файл со спецификацией FPF (он вот тут: GitHub - ailev/FPF: First Principle Framework), то в ответ на тот же промпт пойдёт совсем другой разговор. Например, будет чётко разведено: что тут система, а что только описание системы. Выделит сущности: резидент, его рабочий проект, наставник, инфраструктура мастерской, укажет на ограничения по времени, деньгам и нагрузке. Вместо списка абстрактных “форматов работы резидентуры” появляется перечень характеристик для каждой сущности, предложения по шкалам и способам замера значений этих характеристик. Даже если не знать лексику FPF, разница ощутима: вместо разговора “про всё хорошее сразу” начинается разговор о конкретных вещах, которые можно увидеть, потрогать и обязательно – замерить (всякие “сделай мне красиво” пресекаются, это же нельзя замерить!).
На семинаре мы разобрали ровно этот пример характеризации резидентуры, при этом LLM+FPF ещё и построила эйлерианский граф потоков “от принципов к работе”, и выдала там по TameFlow четыре потока (операционный, финансовый, информационный, психологический) с их характеристиками.
Выбор точных имён с помощью LLM+FPF
FPF дисциплинирует мышление LLM, как ни странно это звучит. Классическая боль инженеров-менеджеров — разные смыслы одних и тех же слов. В одном отделе «сервис» — это кусок кода, в другом — договор, в третьем — команда поддержки. LLM, обученная на материалах из “этих ваших интернетов”, только усилит эту кашу: ей естественно прыгать между смыслами, если её не удерживать. FPF вводит локальные контексты: мы больше не обсуждаем «сервис вообще», а обсуждаем “сервис в IT-архитектуре”, “сервис как внешний контракт, SLA”, “сервис как рабочий процесс в подразделении компании”. LLM вынуждена каждый раз следовать указаниям FPF, заставляющим её учитывать контекст и удерживать смысл понятия внутри одного контекста. Современным LLM это крайне трудно, они сбиваются даже с FPF (я рекомендую использовать ChatGPT Pro и Gemini Deep Think, чтобы это было полегче), но без FPF эти LLM просто идут вразнос – на выходе у них не просто убедительный набор слов ни о чём, но набор слов с уплывающим смыслом.
Чтобы облегчить разговор, надо выбрать терминологию. “Если на клетке со львом написано “осёл”, не верь глазам своим”. Менеджеры часами мучаются, подбирая удачные названия. Программисты подбирают идентификаторы. Делают они это как поэты: по чистому наитию. В паттерне F.18 FPF описано, что считается хорошим именем самых разных сущностей – ролей, программ, подразделений, систем, рабочих продуктов. Можно попросить LLM+FPF дать имя, которое не будет вызывать неточности в использовании, клетки со львом получат свои надписи “лев”.
В МИМ это проявилось очень наглядно. Исторически были «стажировки» и «стажёры», но слово «стажёр» выпускникам не нравилось: слишком сильно пахнет бесплатной работой и ученичеством. Когда реальность описали честно через FPF, выяснилось, что люди приходят со своими реальными рабочими проектами, уже являются профессионалами, а основная ценность – не «уроки», а инфраструктура и наставники. На выходе вместо “стажировки” и “стажёров” появились “резидентура” и “резиденты” – ближе к медицинской ординатуре или формату Entrepreneur in Residence в венчурных фондах, отсылка ещё и к Art Residency. Это всё не “чуткая интуиция” LLM, а систематизированный способ проговорить критерии имени и рассмотреть несколько вариантов на локальном Парето-фронте по четырём критериям, прописанным в паттерне F.18:
– Semantic Fidelity — семантическая точность. Насколько имя попадает в нужный смысл, без смещения к соседним прототипам и без лишних коннотаций.
– Cognitive Ergonomics — когнитивная эргономика. Насколько имя удобно держать в голове: легко ли его запомнить, произнести, отличить от соседних имён, не спотыкаясь каждый раз.
– Operational Affordance — операционная подходящесть. Насколько имя подсказывает правильное использование в работе: по названию понятно, “что с этим делают” и “когда это уместно”.
– Alias Risk — риск синонимичности (риск спутанности и переиспользования в разных контекстах). Насколько велик риск, что это имя уже где-то значит другое, будет путаться с существующими терминами, образовывать двусмысленные пары.
LLM с FPF, ведомая правилами паттерна F.18 выдаст даже не одно, а сразу два имени (для технарей точное и неудобное для всех, и не очень точное, зато удобное для всех), которые лежат на Парето-фронте по этим четырём осям, а не будет просто «первым красивым вариантом». Без паттерна F.18 выдача имени LLM будет “поэтична”: в простых случаях может повезти, а в сложных – может и не повезти, имя будет неточным. Знания LLM о том, как выбирать хорошее имя, существуют, но вряд ли будут подтянуты в ответе на вопрос. Вы же не будете действовать по строгому регламенту выдачи хорошего имени, если вас не попросить об этом? Вот и LLM не будет. Но если не дать этот регламент, то LLM возьмёт первый попавшийся, например, мемуары какого-нибудь поэта о том, как он подбирал слова для детских стишков. И вам подберут по этому “регламенту” термины для какого-нибудь теплообменника в компрессоре или рабочего процесса в бухгалтерии. FPF задаёт чёткий SoTA регламент выбора имён: откуда брать имена-кандидаты, по каким характеристикам их сравнивать, как выбирать парочку для разных целей.
И этот выбор имени LLM с FPF ещё и внятно обосновывает. Так, у резидентуры МИМ появляется директор программ резидентуры. Почему директор? Обоснование: потому что должен утверждать квалификации, поэтому должность должна ассоциироваться с достаточной властью, не просто “координатор” или “администратор”.
Общая предвзятость FPF сдвигает рассуждения (reasoning) LLM в инженерную сторону. Так, художественные тексты про “лучший подход” не требуют таких формулировок, которые можно потом будет проверить. Инженерам недостаточно убедительно звучащих слов, им нужны характеристики, шкалы, данные и критерии выбора. FPF заставляет LLM говорить именно в этих категориях.
Стресс-тест для методологических наработок – трудноформализуемые предметные области. Я обычно беру социальные танцы. Берём бальбоа, предлагаем LLM+FPF характеризовать качество танцевания в переполненном танцзале, floorcraft. Характеризовать – это задать пространство характеристик, q-bundle (q – это quality, характеристики качества). Вместо размытого «танцуют аккуратно» (как сказала бы “просто LLM”) появилось вполне инженерное описание: частота столкновений на десять танцев, контроль дрейфа пары — умеют ли люди держать «своё пятно» и не ездить по всему залу, внимательность к толпе — насколько заранее они ужимают фигуры под имеющийся пятачок для танца. С такими характеристиками можно ставить цели вроде «хотим не больше одного столкновения на десять танцев», видеть прогресс, сравнивать пары не по принципу «нравится / не нравится», а по фронту вариантов. LLM+FPF даёт и варианты организации замера: по видео, современные средства компьютерного зрения вполне с этим справятся. И дальше можно рейтинговать танцоров по умению не сталкиваться с другими парами. Это довольно бессмысленно, никто в здравом уме не будет этого делать, но это просто упражнение на формализацию. Дальше понятно, что примерно та же логика уже осмысленно может быть использована в промышленном проекте или организационном дизайне.
LLM+FPF не панацея, не философский камень, не магия, не будет работать за вас
Инженер-менеджер, использующий LLM+FPF, остаётся главным, ибо если “инженера-LLM” никто не зовёт, то он и не выйдет. FPF не обладает магией, которая превращает инженера в оператора кнопки “сгенерировать отчёт”. Именно инженер, а не LLM+FPF должен уметь сформулировать, чем занимается проект, какие ограничения недопустимо нарушать, какие стандарты считать обязательными, что считать успехом проекта: какие характеристики важны, по каким индикаторам будем смотреть успешность, какие компромиссы допустимы. И в конце концов именно инженер-менеджер должен довести всё до реальных действий: до кода, схем, договоров, оргрешений, изменений процесса. LLM вместе с FPF рук, ног, голоса не имеют, они не проявляют собственной агентности-активности, они лишь снимают часть рутинной работы: помогают придумать варианты, структурировать аргументы, оформить словарь, набросать цепочку “от принципов до задач”, проверить догадки.
Почему вообще имеет смысл говорить, что LLM+FPF конкурентоспособен по отношению к текущему vanilla LLM? LLM уже встроены в IDE, специализированные чаты и даже в мессенджеры, инженеры-менеджеры понемногу играются с промптами и интуитивно ждут магии. Проблемы, решаемые vanilla LLM очень приземлённые: AI-модель быстро подстраивается под самые простые запросы вроде “дай чек-лист” или “сочини красивую легенду под принятое мной решение, обоснуй сомнительное”. В презентациях появляются модные слова, но в коде и регламентах остаётся прежний бардак – vibe coding имеет те же проблемы, что vibe orgdesigning: быстро накапливается архитектурный долг, а затем вся конструкция “неожиданно” разваливается.
FPF в этом месте нужен не как ещё одна философия из их множества, но как инженерный способ сделать LLM более рациональной, сильнее и чище, чем vanilla LLM. Идея в том, чтобы вытащить наиболее мудрую часть LLM, а “попсовую” часть заглушить, отфильтровать, не пустить в ответы. FPF уменьшает словесный шум, повышает долю явно задаваемых характеристик и критериев приёмки результата, снижает вероятность неприятных сюрпризов при переходе от текста, который всё стерпит, к настоящей работе в физическом мире.
Если у вас уже есть LLM в продуктах или внутренних инструментах, следующий шаг — не придумывать ещё пятьдесят хитрых промптов, а решить, какой стиль мышления вы считаете правильным для своих задач, оформить его в явную архитектуру объектов, характеристик и принципов, и подложить эту архитектуру под модель как отдельный слой. В моём случае эту роль архитектуры мастерства сильного инженерно-менеджерского мышления играет FPF, который используется как слой-фильтр между всеохватной vanilla LLM и человеком. FPF нужен не для того, чтобы “LLM думала за нас”, а для того, чтобы LLM перестала быть просто ещё одним говорящим попсовым интернетом. FPF даёт возможность получить для LLM понятный, проверяемый и воспроизводимый инженерный стиль мышления и действия.
Пример онтологической проверки текста с помощью LLM+FPF
Вот это всё выше писал я. А ниже – пример работы FPF в ответ на промпт “Проверь правильное онтологическое использование kinds в тексте”, при этом знающие люди обратят внимание, что и с FPF тоже не всё гладко (скажем, использование “системы работы” в ответе или “характеристики” как “не виды сущностей”). Но для наших резидентов, которые осваивают работу по первым нашим руководствам, где они учатся различать типы – это бесценно (они сейчас это прочтут и поймут, какое счастье им привалило, а остальные люди даже не обратят внимания на то, что демонстрируется – “это элементарно”. Да, пока сами не попробуете так писать, с контролем kinds/types/classes):
По онтологии у тебя тут всё на удивление чисто, явных «kind-косяков» нет. Ниже — точечные комментарии, где я бы либо ничего не трогал, либо слегка усилил разведение System / Episteme / Method / Role, не ломая текста.
- Где всё хорошо и можно не переживать
LLM, инженер, менеджер.
Ты стабильно используешь:
– LLM как систему (организм, который мы запускаем);
– инженера / менеджера как людей-носителей ролей.
Никаких «LLM как документ» или «инженер как метод» — тут всё ровно.
Сервис как пример мешанины.
Кусок про «сервис может быть бизнес-услугой, микросервисом, SLA-договором и службой поддержки» — учебный пример:
– бизнес-услуга → System/Capability,
– микросервис → System/Component,
– SLA → Episteme/Agreement,
– служба поддержки → System + Role.
Ты именно показываешь проблему смешивания kinds во внешнем мире, а не делаешь её сам — это как раз идеально в духе F.18/F.7.
«Система vs описание системы».
Абзац «будет чётко разведено: что тут система, а что только описание системы. Выделит сущности: резидент, его рабочий проект, наставник, инфраструктура…».
Здесь ровно то, что нужно: System (резидентура, мастерская, проекты) vs Episteme (описания, руководства, договоры). Для чтения инженерами всё сказано правильными словами.
Пример с Name Card / F.18.
Ты называешь: роли, программы, подразделения, системы, рабочие продукты — «сущностями, которым требуется имя»; дальше аккуратно обсуждаешь именно качество имени, а не саму сущность.
Это корректно: объект-разговора на Name Card — «что-то любого kind», а сама Card — Episteme про имя и его свойства. Текст не спутывает эти уровни.
Резидентура, резидент, директор программ.
– «Резидент» — роль (Role), носитель — человек-профессионал.
– «Резидентура МИМ» — система/организация (holon).
– «Директор программ резидентуры» — роль, не человек.
Так как ты в явном виде объясняешь, почему должность должна быть «директор», а не «координатор», — это очень хорошая демонстрация F.18 + U.RoleDescription: Kind здесь читается однозначно.
Q-bundle для бальбоа.
Ты говоришь: «q-bundle (q — это quality, характеристики качества)» и приводишь примеры:
– частота столкновений,
– контроль дрейфа,
– внимательность к толпе.
Онтологически это всё характеристики (CHR) в одном U.QBundle; ты не путаешь их с «оценками танцоров» (Work/Result) или «методом тренировки» (Method). Тут всё чисто.
2. Места, где можно слегка усилить разведение kind’ов (по желанию)
Здесь нет ошибок, но можно добавить по одному слову/полпредложения, чтобы читателю было совсем понятно, «что тут за sort».
2.1. FPF как архитектура / фильтр
Фразы: «У FPF тут роль фильтра…», «FPF работает ровно с этим: это архитектура мастерства сильного мышления…», «…эту роль архитектуры мастерства сильного инженерного-менеджерского мышления играет FPF, который используется как слой-фильтр…». Онтологически:
– FPF-документ — Episteme (спецификация архитектуры мышления);
– «архитектура мастерства» — скорее MethodFamily/Architecture (тип способов думать и действовать);
– «фильтр между LLM и человеком» — это уже конкретное решение/связка System+Method, когда LLM реально запускается с FPF.
Сейчас ты эти уровни слегка сминаешь в одно «FPF», но по смыслу не путаешь. Если хочется подчистить, можно в одном месте добавить что-то вроде: «…если подгрузить спецификацию FPF как архитектуры мышления в LLM, то…». Это сразу даёт читателю намёк: текст ≠ система ≠ метод.
2.2. Программа резидентуры
«…я пытаюсь запустить программу резидентуры для инженеров-менеджеров.». Здесь «программа» может в голове читателя расплываться между:
– образовательной программой как системой/организацией (System: набор потоков, расписаний, ролей);
– текстом программы как описанием (Episteme/ProgramDescription).
Дальше по тексту ты фактически говоришь о самой резидентуре как системе, а не о PDF-ке, так что мягко всё в порядке. Если хочется прямой онтологической ясности — можно один раз назвать её «формат резидентуры как системы работы», но это не критично.
2.3. LLM как «инженер-LLM»
«…если “инженера-LLM” никто не зовёт, то он и не выйдет.». Это осознанная антропоморфизация, но для FPF-читающего человека расшифровка такая:
– есть System (LLM-сервис),
– иногда он выступает в роли «инженер-ассистент»,
– пока RoleAssignment не сделал человек, никакого «выхода инженера-LLM» нет.
Если оставить как есть — это нормальная метафора. Если хочется подчёркнуто строго, можно однажды в скобках дать: «“инженер-LLM” = роль, которую ей назначил инженер-менеджер».
3. Важные для kinds места, где у тебя всё прямо образцово
3.1. Система vs описание vs работа
В кусках про FPF+LLM и резидентуру:
– «…что тут система, а что только описание системы.»
– «…какие характеристики, шкалы, данные и критерии выбора.»
Ты ни разу не называешь:
– документ «системой»,
– или систему «описанием».
Всегда: система/объекты → характеристики → измерения → решения. Это ровно то разведение, которое задают A.1, A.6 и C.3.
3.2. F.18 и четыре оси
Ты довольно точно пересказываешь F.18:
– Semantic Fidelity — про семантическую точность имени;
– Cognitive Ergonomics — про удобство для мозга/языка;
– Operational Affordance — про «подсказывает ли форма слова, что это за kind: роль, процесс, результат»;
– Alias Risk — про риск путаницы с соседними смыслами.
И главное — ты нигде не говоришь, что это «виды сущностей». Это оси качества имени, не kinds, и у тебя это не смешано.
3.3. Q-bundle как «пространство характеристик»
В стресс-тесте с бальбоа ты аккуратно развёл:
– «пространство характеристик, q-bundle» — это модель качества (Episteme, CHR/QBundle);
– сами столкновения, дрейф и внимательность — факты мира;
– замеры по видео — процедура измерения (Method/Work).
Никакой подмены нет: ты не называешь Q-bundle «методом тренировки» или «системой floorcraft’а».
4. Итог
Критичных онтологических нарушений нет: System/Episteme/Method/Role/CHR у тебя в этом тексте либо прямо разведены, либо метафоры очевидны.
Если хочется сделать текст совсем «учебным по Kind-CAL», достаточно в одном-двух местах подчеркнуть, что FPF — это спецификация архитектуры мышления, а резидентура — система работы, и тем самым чуть сильнее оттянуть Episteme от System.
Всё остальное — уже скорее вопрос стилистики, а не kinds.
Если хочешь, могу в следующем шаге сделать маленькую табличку для этого текста: «что здесь за Entity-of-Interest и какой у неё Kind» (LLM, FPF, резидентура, резидент, директор, сервис, программа и т.д.), чтобы это можно было приложить как «Kind-чеклист» к статье.
Нет, мне не нужна эта табличка. Но если вам захочется вытащить сущности из какого-то текста и указать их типы, то FPF вам тут поможет, пропмты будут короткие – ибо на эту тему уже много сказано в самом FPF.
Картинка из презентации ко вчерашнему семинару.
