[…]
Ещё мне очень нравится работа про S1 Канемана и построенную на её основе Jev, там упор на параллельное получение структурированных ответов (очень близко по идее к тому, что обсуждают в диффузионных архитектурах, но реализовано совсем по-другому) – Introducing System One Models & Jev - TypeSafe AI Blog. Jev is off the charts – owning the Pareto frontier for almost 2 orders of magnitude. Они там пишут: “193.6x Faster, 444.6x Cheaper” – https://typesafe.ai/. We built a new class of models, System One Models, to be natively used by machines. We’re building with a new architecture, a new sampler, and a new training algorithm: Reinforcement Learning for Calibrated Decisions (RLCD). Там в команде https://www.linkedin.com/in/diogomda/ – co-inventor of ChatGPT, GPT4, RLHF, and InstructGPT. Он просто не пошёл эксплуатировать то, что он уже нарыл, а продолжил рыть дальше. Кстати, уже есть openjev – alex nikolic в X: «https://t.co/N6A2n3J55S HUGE thx for @akhaliq for domain and all likes, now openjev is: - 0.8b qwen - image-video-text train for input, audio coming - calibrated with RLCD - sglang support (5x faster then jev by @typesafe lol) 4b and 35b coming later this week» / X.
Вот тут Telegram: View @lovedeathtransformers про positional bias у этой Jev – а ведь это нормальное человеческое свойство, и объясняется это хорошо квантовоподобными моделями, любимый пример Андрея Хренникова со товарищи, и не только его одного (вот апрель 2026, [2604.08604] Quantum-like Cognition in Process Theories: An Analysis, Quantum-like Cognition in Process Theories: An Analysis). В FPF это предусмотрено, кластер C.26.x, quantum-like modeling lens. Замер меняет состояние, поэтому порядок предъявления меняет оценки вероятностей – это у людей давно было замечено. Скажем, просят оценить вероятность победы каких-то кандидатов на выборах, так вот эти вероятности сильно зависят от порядка предъявления кандидатов, хотя “рационально” вроде бы причинной связи между порядком опроса и этой вероятностью нет. Байесовские расчёты воспроизвести этот эффект не могут, квантовоподобный расчёт – воспроизводит (хотя в общем случае неудача байесовских расчётов не означает автоматически, что нужно идти именно к квантовоподобным расчётам, опций-то моделирования заведомо много). Спецы по машинному обучению, похоже, вообще не знают про такой человеческий эффект, они это традиционно изучают не как эффект, а как “дефект нейросетей”, скажем, вот работа 2023 года, Large Language Models Are Not Robust Multiple Choice Selectors, [2309.03882] Large Language Models Are Not Robust Multiple Choice Selectors. В чате в комментах к реплике говорят, что Jev прямо-таки непригодная сетка, если такое делает, “дефектная” – а ведь это, наоборот, свидетельствует о том, что “думает как люди, даёт те же эффекты”. Ничего, это короткий период в истории человечества, что спецы по ML заново изобретают эту квантовоподобность, заново изобретают азы менеджмента, заново изобретают всё на свете – и пытаются сделать не “как у людей”, а “лучше, чем у людей”. Дальше будет “углубление разделения труда” (как с профессией “вебмастер”, которая просуществовала пару лет), потом пойдут межотраслевые переливы не только капитала, но и знаний. Я сам тут бегу впереди паровоза, активно в этом участвую.
Следующее, что я сделал с FPF, – это докрутил многоуровневость методов. Если вы делаете замер, то это вы делаете ещё и какое-то испытание, а испытание – это часть приёмки системы, а приёмка – часть инженерного процесса. Танцор напрягает мышцы, но это часть поворота, который – часть фигуры танца, которая – часть перформанса на вечеринке, и это часть вечеринки, которая – часть практикования танцевальной культуры в целом. Вот эти “стеки” одномоментности задействования методов важны. Вы можете поручить работнику сделать запись о результатах обслуживания, но тут выясняется, что “умение писать” и “знание языка” тут важны, а работник – иностранец, и он умеет записывать результаты обслуживания, но не умеет писать на нужном языке и вообще не знает того языка, на котором нужно писать. И вот эта многоуровневость методов, их холоничность – она сейчас проведена через весь FPF и прописана более чётко в FPF.
А дальше поправлен операционный менеджмент, там в полной мере на базе математики, мат. моделирования и методологии представлен материал factory physics – про то, как считать поток преобразований через ограниченные ресурсы производства. И чётче проведены границы между организационным развитием и операционным менеджментом. И выпущено 17 паттернов Corporate Governance DPF. Ещё прошёл аудит всего Engineering DPF Suite, много чего было поправлено по мелочи. Прошёл выпуск embodied rhythmics: до ритмики уже как-то руки дошли, при этом нотационная инженерия у нас уже есть, так что с нотациями ритмики тоже разобрались. Это довольно сильный стресс-тест на универсальность всей экосистемы FPF. И тем самым объявленная мной программа выпуска Engineering DPF Suite и Foundational DPF Suite вместе с апдейтом FPF для них закончилась: MVP уже есть, пользуйтесь – GitHub - ailev/FPF: First Principles Framework (FPF): AI-native pattern languages for systems engineering, research and management. Shared human-AI reasoning for architecture decisions, evidence, trade-offs and method engineering. FPF Core and domain frameworks (DPFs). · GitHub. Это, конечно, не конец всей истории. С MVP история, наоборот, только начинается – но не история проекта (что делают разработчики, как они развиваются), а история продукта (чем можно пользоваться, то есть как развивается продукт).
Итого на сейчас в экосистеме FPF мной выпущено:
- Engineering Suite — 20 DPF, 8.5M знаков, 333 паттерна
- Foundational Thinking Suite — 5 DPF, 1.7M знаков, 65 паттернов
- DPF нарративизации — 0.3M знаков, 8 паттернов
- FPF Core — 14.8M знаков, 346 паттернов.
- ещё references и readme на 0.25M
Общий итог на сегодня: 25.6M знаков, 752 паттерна
Дальше основное направление работ не столько в пополнении паттернами или даже отладке имеющегося корпуса (хотя это всё тоже важно), сколько в discoverability. Предположим, у вас в проекте есть затруднение, способ решения которого уже есть в одном из 752 паттернов или даже в нескольких паттернах, увязанных какой-то длинной мантрой. При этом вы или формулируете это затруднение какими-то словами, которые никак не отражены в текущих текстах экосистемы FPF, или (что даже более вероятно) вообще не знаете, что у вас там какое-то затруднение (скажем, вы не знаете, что делить на ноль нельзя – поэтому не считаете это затруднением, но почему-то в ваших арифметических проектах время от времени в загадочные моменты всё вдруг накрывается медным тазом, элементарная операция деления не срабатывает, отладить её не получается). Дальше вопрос: что надо сделать, чтобы вы нашли нужные паттерны? И даже наоборот: что надо сделать, чтобы паттерны нашли затыки в ваших проектах и “самопредложились”? Понятно, что это не сами паттерны будут “самопредлагаться”, а какой-то агент будет задействовать какие-то методы discoverability этих паттернов. Но эти методы надо написать, инструментарий применения сделать, агента как-то организовать. Это сейчас ключевое для развития FPF. Скажем, у Jev заранее задаётся допустимая структура ответа. Но её ведь надо сначала как-то получить!
В какой-то мере FPF тут похож на Jev в этом смысле: по мере удешевления отдельных решений (или “спросить у Jev”, или “спросить у справочника языка паттернов” – это дёшево, Jev назван именно в честь Джевонса, https://en.wikipedia.org/wiki/Jevons_paradox: авторы связывают снижение стоимости запроса к нейросети с расширением применения) всё большую долю работы составляет выбор того, о чём вообще спросить и как использовать её ответ. Уже распознанную ситуацию можно проверять дешёвым специализированным средством. Но когда доступные объяснения не подходят, требуется сформулировать затруднение и только потом уже найти или даже построить способ работы с ним. Для второго случая выбор из заранее подготовленного меню недостаточен, но усиление “общего AI” может дать тоже очень дешёвый способ – ровно тот же, каким FPF строил сейчас свои паттерны. FPF потратил много месяцев работы AI-моделей, чтобы быть созданным. Через год может оказаться, что “vanilla AI-агент” построит нужный паттерн или даже длинную мантру с отсылками к нескольким паттернам on the fly. Собственно, сам FPF такое даже поощряет, в нём самом есть уже паттерны, рассказывающие, как это делать. И тогда акцент меняется с “вот вам решения конкретных ваших проблем” на “вот вам общий язык паттернов, которым можно обсуждать вашу работу со всемогущим AI-агентом”. Акцент всего проекта экосистемы FPF сдвигается с “решения проблем” на “общий язык с вашим AI-агентом”, в котором можно обсуждать текущие проблемные ситуации и их решения. Например, агент замечает в доступной переписке несколько несовместимых значений «готово». Это повод выяснить, какое решение из-за этого расходится между участниками. Следующее действие может оказаться уточнением критерия приёмки, согласованием границ работы или исправлением самого описания ситуации. Здесь FPF помогает поставить вопрос и обосновать продолжение – но будет ли принята эта помощь, зависит от того, поймут ли люди важность проблемы восстановления точности языка в проектных документах.
Чтобы у AI-агентов был шанс что-то улучшить, люди должны достаточно знать, чтобы разглядеть этот предлагаемый агентами шанс. Ну, или всё будет так быстро, как в кодировании: у менеджеров и инженеров будет как у кодеров сейчас – или ты жмёшь кнопку “принять” 100500 раз в день, полностью не понимая происходящего (ибо и некогда, и слишком сложно для понимания), или тебя обходят конкуренты, которые доверяют AI-агентам и не вникают в происходящее. Если препятствием для эффективной работы является внимание и понятливость человека, то человека просто отодвинут в сторонку. В любом случае, пока занимаемся discoverability: найти, где и что изменить, чтобы вся работа стала выполнимой. Найденный паттерн полезен именно через такое проектное изменение: чтобы вся работа стала выполнимой, здесь напрямую работают идеи из B.1.5.EW (Recover How Constituent Actions Enact Encompassing Work) и B.1.5.RS (Replace a Constituent Method in Its Encompassing Uses). А если учесть многоуровневость методов, то после удешевления отдельной интеллектуальной операции где-нибудь в середине стека методов может стать выгодным другой метод работы целиком. Например, дорогой пересчёт плана всех работ заставляет пересматривать его редко, собирать изменения в большие пакеты и терпеть расхождение с происходящим в проекте …
[…]