Я раньше к стартам новых потоков по рабочему развитию часто разрабатывал новые версии руководств, но примерно год вместо новых версий руководств выходили новые версии FPF (что тоже хорошо).
И вот к старту R5 по системному развитию я решил предпринять эксперимент – выпустил шесть руководств (R5-R10) с новым текстом и отдал их узкому кругу посмотреть: “какое из худших решений менее худшее?” – это классическая формулировка trade-off, заведомо исключающая всякие “оптимальные варианты”, ибо оптимум в эволюции недостижим, выбираем из плохих решений наименее плохие. А “лучшего из плохих” – нет такой формулировки, никаких “лучших” в жизни не бывает, увы.
Trade-off был такой:
– старые шесть текстов руководств с хорошо отлаженным русскоязычным текстом, но с онтологией ролей и методов, которая отличается от менее плохого варианта из англоязычного FPF;
– новые шесть текстов руководств, которые были сделаны в абсолютно agile режиме с case management (остался case file на 97K знаков, с которым можно работать дальше). В них дикое количество проблем, но зато онтология ролей и методов, совместимая с FPF. И ещё ожидание, что этой онтологии научить будет проще, ибо она сама проще и естественней.
Вердикт: проблем в новом тексте столько, что проще оставить старый текст. Результатами эксперимента считать не новые тексты руководств, а lessons learned.
По опыту на ручную переписку каждого руководства я бы отвёл месяц (двадцать страниц в день, двадцать дней в месяц максимум – 400 страниц в итоге), шесть руководств – полгода работы, но на самом деле побольше. В нынешних условиях вообще не вариант. Поэтому берём Codex App и сажаем за работу двух агентов: GuideMaker и GuideReviewer. Они за десять минут из вордовых файлов сделали файлы .md, сделали типовой формат заголовков, тут всё прошло прекрасно.
Так что было потрачено 33 часа GuideMaker и 22 часа работы GuideReviewer, а всего проект шёл 107 часов – чуть больше четырёх дней (ибо шли через мои паузы для других работ и перерывов на ночь).
Обнаруженные проблемы имеют самую разную природу. Так, в новой онтологии алгебра ролей, онтологически всё красиво и просто. У нас система в роли в контексте/проекте. Если это агент – то это система в агентской роли, у неё набор агентских характеристик. Если это человек – система в роли человека, у неё набор человечьих характеристик. Тут всплывает та самая “проблема человека”, становится понятно, что для того, чтобы загнать какую-то систему в роль, нужно понимать характеристики роли – что там характеризует агента, что характеризует человека.
Мы тут же вываливаемся в огромный онтологический пласт описаний (descriptions), которые всегда view из viewpoint, которые доступны через публикацию в каких-то публикационных формах. Характеризация – просто одно из описаний. И это надо объяснить. Этих объяснений пока в руководствах нет. Агенты их написали, но читать их нельзя: они на птичьем языке FPF, который “калька с английского” – и там вместо “специализации” сплошь и рядом profile и поэтому в русском тексте будет “профиль” (ибо агенты считают, что русскоязычные инженеры говорят про онтологию не как онтологи, а как инженеры – поэтому и слова выбирают из инженерного ряда синонимов, но вы ещё должны догадаться, что инженерным аналогом specialization является profile!). Там ещё много подобных неожиданностей в текстах объяснений, но поправить их представляется невозможным: я неаккуратно сказал, что “где в руководствах что-то из новой онтологии не было введено, там надо разъяснить” – и объяснения появились в самых неожиданных местах, по всему тексту. “Вы этого хотели – вот вам!” — найти эти вставки невозможно, разве что только натыкаться время от времени при сплошном чтении.
И кроме profile там и другие вставки, например: «Это будем называть ролевым профилем внимания. Ролевой профиль внимания — учебная форма характеризации роли: он не заменяет полное описание роли, но помогает быстро увидеть, какие характеристики нельзя потерять» – слово “учебная” тут относится к рабочему процессу, синоним “задаёт”. Агенты часто пишут: “надо исправить вот этот термин, чтобы он не учил исполнителя плохому” (то есть не задавал плохой вариант, причём он же ещё и будет запомнен – “выучен”). В русском же бытовом языке это отсылка к учебному процессу, которого тут впомине нет. И дальше “У агентных проектных ролей часть этого профиля превращается в предметы интереса и интересы. Предмет интереса — важная характеристика. Предпочтение — желаемое направление или диапазон этой характеристики, которое удерживает система в агентной роли в данном контексте.” – понять трудно, ибо это ж “профиль внимания”, то есть что роль удерживает во внимании из всего, что вообще возможно удержать. Грубо говоря, “карточка внимания”, и в этой карточке – предметы интереса и интересы. Но вдруг ты понимаешь, что кусок текста стал длинным и плохопрожёвываемым – и это уже вторая засада.
Эта вторая засада – это сама алгебра ролей, ибо она легко понимается, но вот в коммуникации надо принимать какие-то решения по шаблонизации. В FPF прямо говорится, что систему-в-роли надо называть по роли: система в агентской роли – это агент. Но вот в руководстве многие из “агентов” честно были раскрыты до “систем в агентской роли”, а к роли добавлен контекст как “проектная роль”, то есть вместо “агент” вы будете читать “система в проектной агентной роли” или “система в агентной роли в данном контексте”. Всё, внимание потеряно – расплылось на низкоуровневом языке.
Я помню, какие огромные проблемы были в проекте ISO 15926: чтобы выразить что-то типа “температура детали 20°C”, требовалось 17 триплов, а чтобы выразить их компактно, надо было иметь шаблон, упаковывающий эти 17 триплов и только их. И много лет шаблоны были в будущем, “вот когда-нибудь кто-нибудь их разработает”. Похоже, эта проблема слишком низкоуровневого языка в полной мере проявилась и с алгеброй ролей. Если вы обсуждаете агента – всё хорошо. Если инженера – всё хорошо. Но затем вам надо обсудить что-то типа мастерства агента, а там хитрый ход на то, что это часть системы, которая умеет что-то делать по методу. Но это обычно про агента, и тут начинаются проблемы – у человека это часть организма, часть мозга (конструктивные объекты, легко с частями-целыми), которой мы атрибутируем это мастерство. У не-человека это вычислитель, у робота – сам робот. Нюансы, ибо мастерство мышления – только мозг или вычислитель и какие-то “устройства ввода-вывода”, а если мастерство переноски грузов – то это часть или организма, или робота. И тут все эти “и/или” хороши в алгебре, а в тексте это дикое нагромождение терминов через логические операторы. Нужны соглашения, как всё такое писать компактно, “шаблонизировать” коммуникацию.
В онтологии FPF мастер – это исполнитель роли, мастерство – роль, степень мастерства – характеристика системы-мастера (а не мастерства! это ж характеристика системы, исполняющей роль, а не самой роли). А дальше мы должны обсуждать агента-инженера-мастера. Это алгебра ролей, можно написать и инженера-агента-мастера, но о таких шаблонах надо договориться и вписать объяснение. AI-агентам сегодня трудно справиться с языком и одновременно удерживать типы и шаблонизацию. Эксперимент провалился именно из-за сочетания плохого владения AI-агентами русским инженерным языком, непонимания того, как объяснить попроще на хорошем языке, отсутствия заранее оговорённой шаблонизации разговора о низкоуровневой онтологии и контринтуитивности в использовании привычных слов (всё-таки новая онтология), требующей постоянных разъяснений и повторений.
С другой стороны, в эволюции нет неудач, есть “получены ценные данные”. Так, из моих замечаний по ходу диалога с агентами был набран текст design rationale record почти на 100K знаков, где много интересностей. Скажем, там обсуждается, что нельзя тащить из английского “носить роль”, ибо там с ролью происходит bearing, и “носитель роли” – role bearer. Роль там как кепка на человеке, её носят. А у нас не “носят кепку”, а “человек в кепке”, вообще другой язык, роль-как-маска – всегда “в маске”, а “носить маску” звучит полным канцеляритом, “Вася в роли Принца Гамлета” против “Вася несёт роль Принца Гамлета”, как “несёт свой крест”. Этот текст можно смотреть и думать, что делать дальше. По идее, если вы скажете “возьми вот этот DRR и выполни над исходными текстами пошагово вот эти преобразования с вот этими ограничениями”, то вы сможете воспроизвести вот этот неудачный-удачный (неудачный в смысле использования результатов, удачный – в смысле набора опыта, lessons learned) мой эксперимент. Вот этот текст: Авторизация, но вот итоговые тексты руководств пока доступны только интересующимся мастерам, “чтобы не учить резидентов неправильному”.
Что сказали мастера:
- для учебных групп этот текст выпускать нельзя, проблемы с языком изложения и объяснениями (и заодно из-за кривости языка ещё и онтологические проблемы: в семантике онтология и лексика тесно связаны, крив язык – крива онтология, и наоборот. “Агентность — это роль и измеряемая характеристика системы в контексте”: чутка перепутаны агент и агентность, “два существительных рядом про одно и то же”).
- ход с ролями более чем удачный, в новых текстах, например, “целевая система проекта” — это роль системы в контексте проекта, и сразу проще объяснять. И даже с алгеброй ролей проще – но если “рядом с текстом руководства”, устно от наставника. Ну, или прямо от FPF с расспросами и уточнениями.
- прекратить эксперименты по переписке руководств, все силы отдавать на FPF, а для выпуска руководств подождать выхода новых поколений AI-агентов с новыми LLM, что-нибудь вроде GPT-6 (уже скоро!) с новым Codex App, где агенты смогут штатно передавать сообщения друг другу в разные контексты (но над одной папкой общей памяти). С каждой новой моделью ведь с языком становится лучше.
ОК, так и сделаю. С перепиской руководств слегка приторможу, а через пару недель выпущу уже все паттерны FPF по архитектурной работе, а в конце июня проведу семинар “Архитектура в FPF”. Задача с FPF пока та же, что поначалу была в руководствах: методика обучения потом, вначале методология – собрать всё важное под одной обложкой. Вот уже год собираю в FPF всё важное. И тогда в июле – опять вернусь к вопросу: как учить собранным в FPF SoTA фундаментальным методам мышления? Раньше был рабочий ответ: “просто попросите AI-агента научить FPF”. После того как я провёл этот эксперимент с перепиской руководств, я бы не был так оптимистичен. Попросить AI-агента научить FPF можно, но вот справится ли он с русским языком, чтобы научить?! С английским ещё может получиться, но я тоже теперь сомневаюсь. Не с этим поколением LLM и AI-агентов.
