lytdybr

Жить в сингулярности -- это очень интересно, ибо чудеса происходят, а ты их банально не замечаешь. Скажем, уважаемый Педро Домингос пишет, что IQ на ватт у людей 5, а у AI -- 0.000001. Boris Power (руководитель прикладных исследований в OpenAI) ему отвечает, что всё уже не так: у людей и впрямь так, а у AI это сейчас 7-40 (!!). Ему пишут, верит ли он, что в 2027 году AI будет в решении задач более эффективен на ватт, чем человек, а он отвечает -- "я думаю, что уже" -- https://x.com/BorisMPower/status/2099448498110214537. И там ему в комментах ещё пишут, что это у мозга 20W надо для работы, но ещё надо кормить тело, а ещё много энергии требуется для дома, отдыха, транспорта и т.д. Конечно, там в комментах всякое написано, вроде "так AI ошибается", на что ответ "так и мозг ошибается". Можно, конечно, цепляться к формулировкам: "для инженерного вывода нужны джоули на сопоставимо выполненную задачу, качество результата и одинаково выбранные границы затрат", но про джоули в прессу не попадёт, а вот IQ на ватт -- попадает, чем Педро Домингос и попытался воспользоваться, но ой, мамочки, опоздал со своим замечанием. Всё-таки современные микросхемы -- это самые что ни на есть нанотехнологии, размеры структур в несколько атомов (даже если это тысячи атомов), вполне сравнимо с мозгом. Экспоненты ровно так и работают: ничего, ничего, ничего, а потом вдруг -- ой, мамочки. Ещё мне очень нравится работа про S1 Канемана и построенную на её основе Jev, там упор на параллельное получение структурированных ответов (очень близко по идее к тому, что обсуждают в диффузионных архитектурах, но реализовано совсем по-другому) -- https://typesafe.ai/blog/introducing-system-one-models-and-jev. 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 -- https://x.com/justALEXWORTEGA/status/2102012184758780065. Вот тут https://t.me/lovedeathtransformers/11068 про positional bias у этой Jev -- а ведь это нормальное человеческое свойство, и объясняется это хорошо квантовоподобными моделями, любимый пример Андрея Хренникова со товарищи, и не только его одного (вот апрель 2026, https://arxiv.org/abs/2604.08604, 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, https://arxiv.org/abs/2309.03882. В чате в комментах к реплике говорят, что 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 уже есть, пользуйтесь -- https://github.com/ailev/FPF/. Это, конечно, не конец всей истории. С 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). А если учесть многоуровневость методов, то после удешевления отдельной интеллектуальной операции где-нибудь в середине стека методов может стать выгодным другой метод работы целиком. Например, дорогой пересчёт плана всех работ заставляет пересматривать его редко, собирать изменения в большие пакеты и терпеть расхождение с происходящим в проекте. Если получение необходимых данных о реальной ситуации (скажем, видеосъемка стройки и распознавание происходящего) и последующий пересчёт плана подешевели, можно пересматривать план чаще, в пределе -- генерировать план on the fly. Меняется периодичность управления, размер проектируемых пакетов работы и требования к координации: меняется вообще способ работы, инженерный процесс. При дешёвом распознавании AI-агент сможет находить больше настоящих проблем, чем организация способна исправить. Причём перегрузить её могут вполне правильные рекомендации. У нас такое время от времени уже встречалось: после прохождения наших программ развития топ-менеджеры задавали работникам такое количество работ по изменению методов их работы, что организация банально останавливала выпуск продуктов и 100% времени не работала на клиента, а работала на перестройку себя самой. Поэтому надо уточнять, что именно мы будем докручивать в экосистеме FPF, чтобы лекарство не стало болезнью. AI-агенту с FPF нужно будет оценивать стоимость доведения предложенного изменения до полезного результата: обсуждение, обучение, переделку работы, переключение внимания и вытесненные переделками задачи. Скажем, в ситуации с несколькими значениями «готово», если расхождение мешает ближайшей приёмке (влияет на throughput), его полезно устранить сейчас. Если участники благополучно различают эти значения в своих ситуациях (достаточно умны!) и решения не расходятся, унификация всей документации с этим "готово" может ничего не улучшить -- просто будет сделана лишняя работа. Существенный показатель роста discoverability -- сколько прежде невыполнимой (в том числе из-за чрезмерной дороговизны) полезной работы стало выполнимо при том же бюджете и в то же время (ибо время -- деньги). Число найденных паттернов, число обнаруженных недостатков тут только косвенные характеристики успеха. Здесь прямо пригодны принципы C.11.DUA: цена совета включает работу его получателя. Скажем, пример со стройкой, где стало можно планировать "на лету": AI-агент постоянно пересчитывает продолжения и заранее видит, при каких условиях стоит перейти к другому плану. Исполнители тем временем спокойно работают. Дешёвые вычисления позволяют лучше выбирать момент вмешательства и величину изменения: переход к другому плану будет учитывать и стоимость самого перехода, переучивания исполнителей. Но если сами исполнители -- AI-агенты (даже на стройке, например, строительные роботы), то стоимость их перестройки тоже может стать малой величиной, и это опять-таки повлияет на то, как будет устроен общий процесс работы, включая организационные усилия, включая усилия операционного управления. Сейчас это звучит фантастикой, но сами AI-агенты сегодняшнего уровня буквально год назад казались фантастикой. А сейчас -- ой, мамочки. Тут огромное поле для идей. AI-агент сейчас преимущественно обнаруживает затруднения нынешней работы. Но ведь есть варианты, которые раньше отвергли по теперь исчезнувшей причине, это абсолютно невидимые затруднения. Например, индивидуальное перепланирование каждого заказа было слишком дорогим, поэтому выбрали недельные пакеты. Существующая работа может идти совершенно штатно, затруднений никто не замечает -- их нет! Но хороший AI-агент с FPF+DPF и нацеленностью на discoverability (какие-нибудь discoverability tools, те же агенты с паттернами для discoverability -- просто расширение FPF и DPF в эту сторону) находит возможность даже там, где текущая работа исправна. С теми же "недельными пакетами" прежнее основание выбора уже исчезло, перепланирование вдруг стало дешёвым ("никогда этого не было, и вот опять!"), затруднение таки есть там, где его нет! Тогда discoverability tools должны брать текущие решения, восстанавливать причины отказа от альтернатив и проверять, какие из этих причин ещё действуют. Уже сохранённые архитектурные решения тем самым становятся материалом для поиска возможностей, для подъёма discoverability. С другой стороны, если дёшево породить альтернативы -- то надо просто их породить, а не возвращаться к тому, что уже давно проехали. Ну, и discoverability надо будет переопределять существенно: сегодня это одно, а завтра будет совсем другое -- внезапно, ой, мамочки. Но ценность общего языка FPF+DPFs проявится при встрече нескольких независимо полученных решений, ибо нужно же ещё и удерживать коллективное внимание и удерживать коллективную работу, а не работу только одного агента или одного человека. Один агент (живой или не очень) предложил метод, другой этот метод задействует, третий через месяц пересматривает решение после изменения условий. Им нужно восстановить, что предполагалось, что сохраняется при замене метода, а ещё им надо как-то договориться с этим опосредованным описаниями методов полилогом (то есть ориентируясь в документации проекта, а не разговаривая друг с другом). Тогда потенциальное преимущество FPF — уменьшение стоимости продолжения и пересогласования работы при смене моделей, исполнителей и методов. Самостоятельно сгенерированный паттерн можно обсуждать и включать в уже идущую работу, а агенты будут общаться и лично, и опосредованно "через документацию" в рамках одной картины мира, картины проекта. Это уже работает. Так, если вы поменяли одну LLM на другую (работая с ними на API), то сразу заметите разницу в ответах. Если вы работаете с разными LLM в рамках одного harness и используете FPF+DPF, то все модели будут для вас вести себя похожим образом. Это наши инженеры-менеджеры уже наблюдают -- просто заменяют одни модели на другие в меру доступности бюджетов, затем радуются стабильности и лёгкости такого перехода. В любом случае, программа выпуска начальных DPF Suites как MVP -- выполнена. Так что я перехожу к подготовке моей осенне-зимней (с 18 октября, закончится в начале февраля 2027 -- будет идти четыре месяца) резидентуры, как я и планировал, то есть реально занимаюсь организацией общения AI и людей в ходе AI-native инженерии и менеджмента. Уже сделал пяток программ и вариантов их оценки по дюжине шкал, потом обобщил их все, проверил итог по разным критериям, получил оценку итога по всем 12 шкалам, довёл до пятёрочек в цикле улучшений, отразил этот полуручной процесс в паттернах Learning Products LPF, затем сгенерировал усиленное предложение -- и отдал на рассмотрение в методсовет. Завтра на встрече методсовета обсудим. Название пока "AI-native инженерия и менеджмент из первых принципов", а там уж как наша служба продвижения это уточнит. [FPFknots в источнике]