lytdybr
Резидентура стартовала, там 32 человека со всей планеты, в первые же несколько дней я для них выложил руководство D1 объёмом побольше “Войны и мира”, и даже выкладывал его несколько раз – демонстрировал release early, release often. Сегодня там собирались уже малые группы, это координировала Юлия Чайковская, а я продолжал дорабатывать D1 и чинить библиотеку FPF. В воскресенье встречаемся и будем работать с системной мантрой, осваивать один и тот же метод мышления в приложении к самым разным системам, самым разным проектам. Текста в чат резидентуры я написал огромное количество и даже выпустил ещё несколько версий руководства по материалам моих рассказов в первый день – там уже не 40, а 65 страниц текста (в том числе и добавочки с явными пометками: “вам это полезно, но в материалах первой встречи этого не было”). Основные стартовые переживания закончились, теперь четыре месяца будет более-менее равномерная работа.
После воскресного поста (Резидентура, прожигатели токенов, мои продукты, не мои DPFs, синтез дисциплины "управление") продолжил разбираться с тем, как не очень живые методологи умудряются написать много правильного текста, но так и не объяснить предмет. В FPF Core появились новые паттерны C.39.QR — возвращение полученных результатов к исходному вопросу (ибо при ответе на вопрос часто забывается, о чём там спрашивали – а надо проверять, антипаттерн тут – поведение политиков, которые на прямой вопрос несут ахинею, но в этой ахинее ответа на вопрос не обнаруживается, C.39.QR такое отловит), и C.39.WA — построение объяснения целого предмета вместо удовлетворения объяснением какого-то отрывка (для бюрократов: “объяснили работу карбюратора, значит, работа автомобиля с ДВС объяснена”). Это продолжение уже описанной в прошлом посте починки редукционизма, но теперь направлено на получение паттернов с изложением общих методов (в библиотеке FPF с этим оказались проблемы). Эти общие методы нужны ведь не только при написании очередного DPF по широкой предметной области. Можно добросовестно ответить на все маленькие вопросы, на которые разбили большой общий вопрос, а ответа на большой так и не получить – по пути агент потеряет внимание и закончит не сборкой из кусочков общего ответа, а отладкой всех кусочков без их сборки. Скажем, можно подробно разобрать пример, но оставить читателю работу по самостоятельному изобретению общего метода, для которого сделан пример – ибо пример будет, но то, чего это пример, будет отсутствовать (да, в библиотеке FPF такого оказалось много, перегиб с “объяснением на примерах”, когда только примеры и объяснены). Пример должен делать общий метод понятнее, а не тихонько подменять его собой. Особенно весело, когда объяснение получается про насос, а обещали объяснить инженерию вообще: насос-то уже все поняли, значит и инженерию поняли (но про инженерию ни слова, только про насос)! С этими паттернами много починок: там и сама библиотека FPF, и новое руководство D1.
Заодно ремонт добрался до того, что именно мы считаем знанием, его описанием и представлением. Вокруг эпистемы накопилась путаница, которая потом воспроизводится в самых разных местах библиотеки. Например, спецификацию насоса перенесли в другой файл – знание о насосе от этого не изменилось. А если в прежнем файле поменяли допустимое давление или условие, при котором оно допустимо, содержание уже другое – но что это за тип “содержание”, чем отличается от “описания”? Стартовало это разбирательство дня три назад, но Юрий Торопчин подлил масла в огонь своими вопросами (с Telegram: View @modelcollect). Там плотный такой клубок проблем: удержание типов, согласование онтик, онтологическая работа вместо лексической, ходы на концептуальный и методологический синтез (ибо там много предметных областей – от онтологии до нотационной инженерии, от архитектурных описаний до системного мышления с обобщением на холоны эпистем). По итогам будут обновления библиотеки FPF, затем правки в D1, рекомендации для правок R1-R4. Стоит починить вроде бы маленькое различение или наоборот, слияние (вроде “эпистемы” и “описания”, которые уже несколько раз чинились, но выяснилось, что не до конца) – и обнаруживается, сколько всего на него опиралось, это полдня уже всё длится.
Отдельно доработал представленность мышления письмом в библиотеке FPF, ибо оно там хорошо было представлено, а потом как-то потерялось. В C.2.4 теперь прямо написано, как получать содержание по ходу его записи: взять ещё смутное наблюдение или прежнюю формулировку с “ощущениями” (тот самый “дребезг”), попробовать выразить утверждение, вопрос или план хоть как-то образно, буквально “увидеть” что-то пропущенное и назвать, сопоставить с исходным материалом и переписать уже внятным текстом (C.2.4 - Articulation Explicitness — How Explicit Is an Episteme’s Meaning for Its Use? | fpf.tools). Запись помогает обнаружить, что именно мы ещё не поняли. При этом ясность формулировки, её обоснованность и закрытие вопроса, на который эта формулировка должна давать ответ, – разные характеристики. Иногда после хорошей записи вариантов становится больше: мы просто не замечали альтернативы, а в ходе записи заметили, тем самым прихватили принятие решений. AI-агентам тут особенно хочется поскорее выдать гладкий “безальтернативный” окончательный ответ, после которого уже непонятно, куда делись исходные сомнения и были ли там варианты. Пришлось сформулировать то, как культурно делать записи, которые помогают думать, а не только помогают презентовать готовые результаты мышления. Недописанная мысль может быть полезным промежуточным результатом, заполненная карточка ещё не делает мысль додуманной, вот это надо чётко понимать и людям, и AI-агентам.
Сегодня дошли и до измерений: в C.16 усилено объяснение того, как вообще построить связь между показанием прибора и тем, что хотим узнать (C.16 - Measurement & Metrics Characterization (MM‑CHR) | fpf.tools). Скажем, датчик может нагреваться от самого прибора, тогда лишний знак после запятой в его показании этого не исправит – вот эту связь реальности и описания реальности надо всё время удерживать в разговоре об измерениях. Иногда полезнее поменять физическое устройство измерения, чем усложнять расчёт поправки. Дальше уже можно получать значения с неопределённостью, сравнивать результаты измерений, решать, что делать по итогам замеров. И тут же пришлось уточнить сами понятия характеристик, шкал, пространств характеристик: число в таблице, значение характеристики предмета и вывод по этому числу должны сохранять свои разные смыслы при переходе между методами. Это пригодится и для физических измерений, и для всех наших оценок мастерства, качества паттернов или архитектуры (архитектурных характеристик), а также для оценки достигнутых результатов в ходе циклов улучшений (циклов управления, я склонен считать все эти циклы Деминга, Бойда и прочие вариантами архитектур управления).
В Management DPF Suite появился GOALS — Goal Construction and Regulation Principles Framework – Goal Construction and Regulation Principles Framework | fpf.tools, девять паттернов про целеполагание, включая профиль OKR, но там ещё и личные профессиональные цели, и поручения AI-агентам (те же goals в Codex App как пример). Цель связывается с основаниями её выбора, свидетельствами достижения, обязательствами перед другими участниками и средствами, которые придётся делить для достижения не только “целевой цели”, но и всех остальных имеющихся целей. Отсюда получается общая архитектура целеполагания, это не сводится к описанию очередных советов по заполнению табличек Objective и Key Results в OKR. Три команды могут иметь по отдельности прекрасные цели, которые будут требовать одного и того же специалиста на одно и то же время – и никакое качество формулировок целей лишних часов ему не добавит, вот это надо разруливать при целеполагании. Одна и та же работа может давать результат заказчику и одновременно служить практикой повышения квалификации сотрудника — пока AI не начал выполнять за сотрудника как раз то действие, которому тот должен был научиться, и тут опять надо разбираться с тем, какие цели тут важнее. В GOALS это соединено с C.43 как общей архитектурой управления: по ходу работы пересматриваем нужную связь — способ действия, прогноз, критерий достижения или само обязательство, а не просто обновляем процент выполнения заведомо недостижимой “жирной волосатой цели”, записанной по всем правилам OKR.
Ещё в составе этого Management DPF Suite вышел Human Resource Management Principles Framework (Human Resource Management Principles Framework | fpf.tools), пока пять крупных паттернов. В прошлом посте я рассказывал о разработках коллег вокруг HR, а тут в резидентуре у нас оказался HR-директор крупной IT-компании, поэтому пришлось резко ускориться. Это классический HR, “кадры” – ибо многие другие методы работы с сотрудниками компании разбираются в других DPFs. В HRM попали оценка и отбор людей, вознаграждение и продвижение, возможность влиять на кадровые решения и оспаривать их, продолжение участия в работе и переходы между работами. Общий предмет здесь — устройство отношений, через которые люди участвуют в работе организации. Поэтому отдельные кадровые решения надо собирать вместе: отбирать человека под одну работу, поручать и оплачивать другую, а затем требовать результатов третьей работы — довольно эффективный способ получить совсем не тот результат, на который рассчитывали. Линейный руководитель при этом будет считать, что он делает всё как надо, “обстоятельства меняются” – но тот же HR-директор как минимум может ему оппонировать: интересы линейного менеджмента не объявляются единственными ролевыми интересами, которые надо учитывать. У сотрудников есть собственные траектории развития (планируемые или де-факто сложившиеся), могут оказаться другие возможности и ограничения, дающие им стимулы и основания соглашаться или не соглашаться с разными то ли “предложениями”, то ли “поручениями” (то, что вы считаете поручением, кто-то может воспринимать как предложение, и наоборот – предложения принимают с благодарностью, за них готовы и приплатить, поручения имеют трудовое продолжение, а труд обычно имеет отрицательную полезность, платить надо за него – вот HR должны это как-то учитывать). С этим связаны HCD (Human Capability Development), менеджмент сообществ и организационные изменения, а также корпоративная и личная культура развития.
Ещё добавили профессиональные архироли (визионер, архитектор, разработчик, инженер платформы и т.д.) в справочники Engineering и Management DPF Suites и в Human Capability Development DPF. В моих руководствах R5-R8 давно были архироли, но в библиотеке FPF они были недопредставлены. Тут два вопроса: какую систему мы создаём или меняем (инженерия, менеджмент, обучение? в какую предметную область по природе нашей системы мы попали?) и какие методы работы применяем в этой предметной области (скажем, для организации – собственно организовываем или занимаемся операционным управлением?). Архитектура насоса, архитектура обслуживающей его организации и устройство подготовки диагноста у медиков могут требовать похожих рассуждений о целом и частях, о ролях и методах, но предметные знания и получаемые результаты у них разные. Визионеры, архитекторы, проектировщики, инженеры платформы и инженеры эксплуатации отвечают за разные вопросы о создании и использовании целевых систем, их ответы взаимно ограничивают друг друга. Сегодня можно сдвигать работу этих ролей с людей на AI-агентов, но вопросы разделения труда между ролями от этого не исчезают. Должность можно переименовать за пять минут, а недостающую профессиональную работу всё равно кому-то придётся выполнить – и надо обсуждать методы, роли, исполнителей ролей и их capabilities, конфликты интересов. Вот это прописано чётче – и заодно отражено в D1.
В справочнике по всей библиотеке (FPF/FPF-LIBRARY-REFERENCE.md at main · ailev/FPF · GitHub) появились развёрнутые объяснения совместной профессиональной культуры людей и AI, в том числе понятие “помощь” (скажем, принципал-агентское отношение как помощь агента принципалу). Это оказалось большим разнообразием предметов. «Помочь человеку» может означать выполнить за него недостающую работу, научить его выполнять её, дать время и инструменты, договориться об условиях участия или вместе разработать способ, которого пока вообще нет. Получится разная помощь, с разной работой помощника и разными дальнейшими возможностями получателя. Отсюда можно обсуждать и наставника, и офис развития, и центр компетенций или совершенства (excellence). Следующий шаг: как методы работы становятся общими для людей и AI, передаются новым участникам и продолжают работать после смены инструмента (перехода к новому вендору, “поменялись только кнопочки” – с рояля перешли на скрипку) или перезапуска агента (“мы тут поставили локальную нейросеть, пользуйтесь”). Канон у людей и AI-агентов может быть общий (та же библиотека FPF), но механизм освоения — разный. Теперь это связано в одно объяснение: от конкретного эпизода помощи до воспроизводства и изменения профессиональной культуры. Просто раздать всем ссылку на 35 МБ текста библиотеки FPF было бы, конечно, дешевле. На 30 октября в библиотеке уже 49 файлов и 927 паттернов, считая Core и DPFs. Но AI-агент это всё примет и начнёт работать, а человек – нет, я ожидаю где-то полтора года на приобретение мастерства (четырёх месяцев D1 тут явно недостаточно, причём перед этим ведь четыре месяца R1-R4, но беглости ведь всё равно не будет – банально “всего очень много”, чудес не бывает, таблетки “мастерства управления вертолётом” для людей бывают только в голливудских блокбастерах).
Эту работу сразу применил к Мастерской инженеров-менеджеров: собрана и несколько раз уже переработана корпоративная стратегия по помощи в освоении методов и распространению культуры бесконечного развития. В ней соединены общая подготовка сотрудников (грубо говоря, чтобы умели хотя бы читать-писать), подготовка людей, которые будут помогать развитию других, устройство работы офиса развития в других компаниях, наши резидентуры, поддержка сообщества инженеров-менеджеров в Мастерской и включение персональных и корпоративных AI как teammates, а не только assistants. Офис здесь должен делать помощь реально доступной в других компаниях: кому-то нужен наставник, кому-то предметный специалист, кому-то решение руководителя о времени и полномочиях, а кому-то разработка недостающего метода – и это для развития. Общую подготовку, профессиональную помощь в каких-то методах, изменение организации работы нельзя заменить друг другом, но там ведь ещё и надо учитывать – это всё про развитие, или просто добавляем новый метод в коллекцию, а развития при этом нет. Под эту идею бесконечного развития (open-endedness) сделаны библиотека FPF как канон культуры развития, наши руководства, B2B-предложение компании (и переговоры уже пошли, в середине ноября первый старт проекта создания офиса). Это программа работ, большинство из которых уже идут, это не очередная “концепция стратегии” с призывами “надо развивать культуру, и это культура развития”. Стратегические материалы МИМ продолжают жить в mim-strategy (GitHub - MimEcoSys/mim-strategy: Стратегия развития МИМ · GitHub), они открыты.
Отдельно пришлось заняться авторским голосом (tone of voice) в текстах. Агенту говоришь «пиши моим голосом», а он вставляет пару «я» и «мы», после чего продолжает вещать канцеляритом и добавлять оговорки (в литературе описано, что Astra 6 очень осторожна в речи, вставляет множество оговорок, поэтому текст становится нечитаемым – это не является абсолютным свидетельством, не подразумевает совсем уж нечитаемости, не говорит о стремлении обидеть Astra 6, не намекает на… ну, вы поняли). В DPF по нарративизации в NSTD.4 теперь развёрнут общий метод работы с голосом: брать настоящие авторские фрагменты и восстанавливать по ним стиль, а затем сравнивать написанные тексты с этими фрагментами (скажем, для меня можно брать какие-то посты блога https://ailev.ru или фрагменты выложенных там же руководств – они там разными “голосами” написаны). Это используется прежде всего в LPF учебных продуктов. В этом же LPF продолжил борьбу с бессодержательными предостережениями и ритуальными пояснениями очевидного: если фраза не помогает понять мысль или сделать следующий ход, её надо выкосить.
Ещё один результат — более содержательный ремонт самого ремонта. Когда агент в третий раз повторяет ошибку, очень хочется дописать в инструкцию «никогда больше так не делай» и вернуться к своим делам. Проверено: этого мало. В новом C.39.WI развёрнут разбор “повторной ошибки” – ошибки, которая пережила уже какое-то исправление и выжила: восстановить, что там происходило, пройти по тому, как поняли задание, что именно там выполняли и проверяли, найти участки текста с причинами соскальзывания в ошибку, изменить то, что позволяет воспроизводить ошибку, пересмотреть, что там связано с этим исправлением (где ещё надо что поправить). Скажем, если в тексте был ошибочный критерий проверки ошибки, то им воспользуются и автор, и проверяющий, и даже ещё один проверяющий с тем же критерием особенно не поможет. Поэтому C.39.WI копает причины, а не запреты или критерии, а потом паттерн LPF.REPAIR в нашем LPF применяет его в работе. Долгое время это было только в LPF, но вот теперь руки дошли – и это поднято до уровня паттерна: не только исправить ошибку, но исправить все подобного сорта ошибки, кроме того, найти причину и исправить её (чем-то похоже на работу по циклу Деминга: если идёт брак, то исправлять причину брака, а не просто сортировать на “попал в допуск” и “не попал в допуск”).
Из более приземлённого — восстановили нормальное пополнение архива ЖЖ на ailev.ru (Лабораторный журнал — поиск по записям Анатолия Левенчука). Свежий пост был виден в браузере, а сборщик застревал на TLS-handshake; узкий режим совместимости TLS 1.2 для его обращений к ЖЖ восстановил экспорт без отключения проверки сертификатов. Затем поймали другую неприятность: publisher проверял состояние сервера ровно в те несколько секунд, когда плановое обслуживание держало общую блокировку. Сделали ограниченное ожидание, проверили, выложили исправление на сервер и завершили публикацию. Сегодня, 30 октября, пришлось разбирать уже другую задержку: на VPS резко менялось время ответа диска даже при небольшой нагрузке, агент написал тикет провайдеру сервера. Там не так мало: в публичном архиве сейчас 7000 постов и 66 429 комментариев, но ещё и мои книжки, и доступ как полнотекстовый, так и по MCP.
И ещё прикинул образовательное содержание всех 403 паттернов FPF Core по частям A–G в редакции на 28 октября, сделал таблицу и столбчатую диаграмму. Вопрос был сильный: при каком хорошем соответствующем образовании человек должен уже сам знать проблему, способ решения и его существенные ограничения, не заглядывая в паттерн? Около 61% паттернов попали в бакалаврские ориентиры, 35,5% — в магистерские, остальные — в школьные и переходные к аспирантуре; последних совсем чуть-чуть. К методологии вопросы: оценки AI-агента субъективные, это не замеры, знания ведь разбросаны по разным специальностям, один диплом всю совокупность не покрывает. Но дальше интереснее. Если сейчас эти способы собираются у человека из нескольких образований и работы, почему не преподавать их связно с самого начала? Написал отдельный разбор FPF и DPF как основания школьной и вузовской программы, а не курса «поверх» уже полученного образования. Для меня перспектива тут — раньше учить связному мышлению и способности осваивать новое, раньше запускать бесконечное развитие. И дальше я положил это на дальнюю полку в самый пыльный угол своего SSD: к образованию в школьном и студенческом возрасте интерес у меня давно есть, но руки в ближайшее время точно не дойдут.
Последний промпт, который я дал своему агенту перед публикацией этого поста: “Запланируй ещё кампанию, где смотрятся всяческие менеджерские циклы вроде POOGI, цикла Бойда, цикла Деминга-Шухарта, наш цикл улучшений и т.д. как упрощённые варианты наших архитектур управления (одноуровневые, но всё же это циклы управления – как в нашем концептуальном и методологическом синтезе управления). Это добавочка к проведённому концептуальному и методологическому синтезу, показывает универсальность подхода. Получается, что эти “менеджерские” (management) циклы именно управленческие (то есть control-циклы, а не management-циклы), просто варианты более универсальной архитектуры систем управления. Это надо проверить и явно отразить в библиотеке FPF, в том числе и для SoTA вариантов всех подобных циклов” – и кампания K18 была запланирована и даже уже в какой-то мере выполнена.
Ещё небольшой диалог с Максимом Осовским в LinkedIn (https://lnkd.in/p/e9JRfCqy), который защищает схемы и диаграммы и жалуется на огромный объём текста (а не картинок) в FPF: целое, мол, не видно сразу. Но у него самого статья об этом – 36 страниц и только одна диаграмма ([2610.32869] From Deliberately Constructed Systemic Representations of the World of Activity to Dialogue: A Five-Level Communication Architecture for Strong Language-Based ASI). И смысл этой диаграммы он раскрывает текстом: без объяснения понятий, отношений и способов работы с ними картинка понимания не даёт. Компактность схемы оплачена подготовкой читателя, эти знания и навыки никуда не исчезли – просто в картинке их не видно. Текстовое изложение методов не делает сами методы только “текстовыми”. Мой пойнт в том, что в FPF проблемы презентации-репрезентации уже в существенной мере решены, включая операционную интерпретацию (NOT.3 - Give Expressions an Operative Interpretation | fpf.tools) и нотационную инженерию (NOT.7 - Redesign a Notation around the Reader’s Difficult Operations | fpf.tools), но ещё есть и программа исследований.
