Видео (2 часа 26 минут) моего вебинара "Образование для образованных в 2025), где я рассказывал главным образом про эволюцию и AI и что в этой связи надо делать с образованием (ситуация, когда ничему прикладному учиться невыгодно – быстро поменяется, а ещё это возьмёт на себя AI и сделает быстрее и лучше. Остаётся поддерживать какие-то фундаментальные навыки. Но какие?! Которые не учат в школе, не учат в вузе):
– в телеграме: Telegram: Contact @ailev_blog (и аудио, Telegram: Contact @ailev_blog)
– в ютьюбе https://www.youtube.com/watch?v=bOc2srOnD2s,
– ВКонтакте — Вебинар “Образование для образованных в 2025” — Video | VK
Слайды — Образование для образованных в 2025.pptx — Яндекс Диск
Продолжаем следить за крутым переломом в методах создания AI систем, наиболее интересно об этом сейчас пишет Andrei Karpathy, вот его текст про примат RL по сравнению с RLHF (суть в том, что RL это trial-and-error learning, заставляет искать крутые ходы, типа “хода 37” от AlphaGo, а RLHF это imitation learning, заставляет имитировать тот потолок полёта мысли, который есть у людей, и часто это даже не лучшие люди): x.com. Основная фишка тут в том, что RL тоже можно учить, в какой-то момент ты учишься делать более радикальные догадки о том, что надо бы попробовать, догадываешься, насколько надо вернуться назад после ошибки и т.д. Сегодня он докручивает эту же мысль на примере задач из учебника: x.com. 1. Текст из учебника – это pretraining, знакомишься с идеями. 2. Дальше идут примеры решений, supervised finetuning. 3. А вот дальше RL, обучение с подкреплением – идут задачи с ответами, и тебе надо делать уж что можешь, чтобы попасть в правильный ответ. Вот он говорит, что для LLM надо “писать учебники” с этими тремя видами данных. We’ve subjected LLMs to a ton of 1 and 2, but 3 is a nascent, emerging frontier. When we’re creating datasets for LLMs, it’s no different from writing textbooks for them, with these 3 types of data. They have to read, and they have to practice. Вот-вот, про мокрые нейросетки я думаю то же самое. Картинка из его поста.
Провёл некоторое количество игр “Барышня-мадам” по правилам из Тренировка "Вы пойдёте к топ-менеджеру?" или "Барышня-мадам".: ailev — LiveJournal, причём часть из них в режиме зум-сессии, часть – прямо в чатах поддержки (закрытых). Это мне напомнило вывод группы “Аттик”, занимавшихся изучением императивного программирования: есть некоторое минимальное мыслительное ядро, в которое входит понятие программы, команды/шага программы, программиста, компьютера как выполнителя программы и совсем чуть-чуть разного другого. И дети детсада должны потратить на практическую работу с решением задач по этому ядру 16 часов, а взрослые – 8 часов, ибо они много дисциплинированней и не отвлекаются любой летящей мимо птичкой. То есть по-грубому нейросетка выучивается ядру программирования сосредоточением на действиях в предметной области за 8-16 часов, и это по факту не зависит от возраста. А если этих упражнений не делать, если налёт часов у взрослых меньше 8 часов, а у детей меньше 16 часов, то дальше проходить курсы любого программирования не получается. В самом начале должна быть вот эта тренировка. Похоже, эта “барышня-мадам” или “вы пойдёте к топ-менеджеру” на удержание собранности в части очень небольшого числа понятий тоже как-то должна тренироваться, для взрослых людей после вуза это годе-то часа четыре – с преподом или LLM (когда она научится тоже быть собранной на типах, пока это не так) без разницы. Главное – это дрессура нейросетки, надо вывести её на рефлексию, научить хватать за язык, саму себя: как и в “барышне-мадам” правила вроде просты, но не удерживаются – и надо бить их на элементарные операции и тренировать по отдельности и вместе, в разных контекстах. Дотянуться мыслью до системы в момент эксплуатации в её окружении – это какое-то титаническое усилие, ошибок там масса.В курсе “Системное мышление” они перечисляются, хотя без тренировки с преподом это оказывается бесполезным – вы можете прочесть список ошибок, которые находит компилятор, но пока вы не сделаете их штук сто-двести сами, вы не будете заранее думать, что там за синтаксис у вашего языка программирования, а каждый раз будете удивляться, “что это я сделал не так? почему опять? я же прав, у меня всё корректно, всё по правилам!”. Радует только, что после тренировки все говорят “есть о чём подумать”, проект сразу начинает играть новыми красками, за две минуты можно рассказать, в чём его суть. Изменения же каждутся неважными. Скажем, органический растворитель или органическая основа электролита – растворитель указывает на время создания, электролит – на время использования, при этом ожидания от “растворителя вообще” другие, нежели от “основы электролита”. Или полиэтиленовый вкладыш в морской контейнер (время создания, назначение непонятно) по сравнению с полиэтиленовым гига-пакетом для перевозки жидкости в контейнере (время использования, назначение понятно). Проблема в том, что сдвиг рассуждения на время использования, а названия с конструктивного на функциональное идёт каждый раз с зубовным скрежетом, не хватает тренировки, хотя всё это абсолютно понятно, как правила игры “барышня-мадам”. Правила понятны, играть нелегко, внимания не хватает, ибо это внимание ещё не перешло на “автомат”. Наши оценки – где-то четыре часа тренировки, одного раза “попробовать” не хватает, чтобы прочувствовать. Я думаю, что проведу в феврале серию таких коротких тренировок. Ответ на вопрос “что вы делаете в вашем проекте”, ничего больше.
В чате моего канала в телеграме очередной приступ психологии (аж с позавчера до сегодня, никак всё не уймётся), много туда писал, удавливал это дело, прописывал мотивацию своей борьбы с психологией, это с Telegram: Contact @ailev_blog_discussion, и там вопрос был про “иррациональную (эмоциональную) часть мозга”. Дальше перещёлкнулось на “эмоциональную часть мозга”, “локализацию эмоциональной части мозга в лимбической системе и роль амигдалы” и осмысленность этого рассуждения в управлении эмоциями. У меня там ну очень много написано, надо потом не забыть перенести часть этого материала в “Инженерию личности”. Последняя там у меня реплика (Telegram: Contact @ailev_blog_discussion): “Я не буду комментировать продолжающийся мета-флуд про психологию (включая обсуждение того, что флуд про психологию нельзя остановить — хотя это продолжение того же флуда про психологию). Невозможно удержаться, я понимаю. Тема такая. Этот вирус надо удавливать, не пускать в свои границы. А свой мозг контролировать — что это вдруг он так возбуждается на психологические темы, корчит из себя психолога-любителя, знатока психологов-любителей, наблюдателей за знатоками психологов-любителей, экспертов по ситуациям, интересным всем предыдущим ролям и вообще с удовольствием подхватывающим все эти философские и психотерапевтические рассуждения. Я предлагаю на эту тему беседовать с моделями o1, R1, Gemini Thinking. А этот чат пожалеть”.
У Fields и Levin вышла очередная работа, “Thoughts and thinkers: On the complementarity between objects and processes”, https://www.sciencedirect.com/science/article/pii/S1571064525000089#br1470. Там всё как обычно, ничего вроде нового. Собственно, современная инженерия примерно так всё и считает – всё на свете динамично, ничего фиксированного и статичного нет, интересы у всех разные, картины мира разные, объекты нельзя рассматривать вне связи с их поведением, а поведение вне связи с объектами. Поэтому вроде как можно смело считать, что в инженерии и менеджменте это всё давно учтено, разве что в статье приводится математический формализм и хитрая терминология вместо чего-то понятного. Дальше я сделал трюк: скормил это нейросетке R1 (https://chat.deepseek.com/ – sign in на какой-нибудь американский почтовый адрес, gmail.ru сойдёт, в Россию не регистрирует, перед нажатием кнопочки sign in запросить на указанную почту код, потом взять из письма этот код). Вопрос был такой: “что там нового для инженерии и менеджмента, если знать, что в agile уже всё давно динамично, а ещё есть evolutionary architecture, которая как раз учитывает предстоящие изменения”. Ну, и мелочи, которые сводились к тому, что “не надо повторять общеизвестное в agile, но надо изложить не в терминах академической статьи, а в терминах, понятных менеджерам и инженерам”. Интересными оказались несколько нетривиальных замечаний, которые хорошо бьются с нашим опытом в учебных группах. Наверное, нам надо на эти темы добавить объяснений, добавить тренировку:
— встать в позицию другой роли – это по факту получить не новый набор фич для своего объекта, это получить новую реальность с новыми объектами, и вопрос совпадения со старой реальностью сразу проблематичен. Это не “чайник тёплый” и “чайник розовый” для одного чайника, который находим в жизни, и в проекте надо ещё договориться, что речь идёт о чайнике и зачем вообще нам понадобилось рассматривать чайник, как он связан с целевой системой. Там вообще обычно будет не чайник и про чай разговора не будет, и все связи с объектами другие и объекты другие – и заземления не будет, его надо будет искать специально. Очень трудно скакнуть в чужую реальность, там увидишь не другие фичи знакомых объектов, а вообще другой мир, другие объекты в других отношениях. Мы учим сразу заземлять на объекты материального мира, чтобы договориться и про другие интересы других ролей (и то, что у тебя самого интересы, а не “общий взгляд системного мыслителя”). Но вот эта тренировка выхода в eXperience другого – она нужна, встать в позицию другой роли, увидеть вообще другой мир, а не новое свойство знакомого тебе объекта.
— все агенты (роли) стремятся не столько что-то сделать, сколько удержать свою идентичность в предсказанном из своей картины мира будущем, в этом главный интерес. И меняться надо для того, чтобы не разрушиться, удержать эту идентичность, изменить предсказание неудачи. Вот это тоже неочевидно: гнуться, чтобы не сломаться. Ибо понимается как “не менять ничего, стоять до последнего, в стабильности счастье, авось рассосётся” вместо “адаптироваться, чтобы выжить, отслеживать динамику, то есть предсказывать, чтобы стратегировать, планировать и действовать – а не просто наблюдать”. Мы это “предсказание неразрушения” особо не отличаем от просто “предсказания будущего”. А это основное: про “предсказание того, что там с идентичностью” как императив. Это вроде как точней разговоров “изменения, новое воспринимается как потенциально опасное”. Если давать новую конфету, то она не воспринимается как опасность. Современный фреймворк active inference чётко даёт набор концептов: волнует соблюдение предсказания, уменьшение байесовского сюрприза, расширение границы, увеличение контроля. Это не абстрактное “всё новое пугает”.
– отдельный вопрос про умение перенестись во времени: там два хода – надо перенестись в чужую голову с другой картиной мира (переход через портал в мир), а там перенестись в другое время (ибо речь идёт обычно о предсказаниях). Даже если решить первую проблему (да, у архитектора целевой системы другая картина мира, у меня как операционного менеджера тоже другая), то явно заставлять делать предсказания – и ещё указывать, по какой модели/теории – это совсем другое. Регулярно ведь встречается “мне для проекта надо 4 миллиона рублей – но я не знаю ещё, что у нас будет за система, она ж ещё осенью будет – а что надо 4 миллиона рублей я и сам не знаю откуда взял, ведь про систему я ещё ничего не знаю” (и это только один перенос во времени, для своей роли. А уж “заплатят ли за систему люди, когда она будет готова – и за что они готовы заплатить, что для них будет наша система”, так это вообще задачка-неберучка). То, что design – это предсказание, равно как предсказание – это design, это надо обсуждать отдельно. Работа со временем и умение перенести себя в другое время – это должно тренироваться. То есть “представь целевую систему в момент эксплуатации, какая там польза, как называется?” это 1. “портал в мозг того, кто эксплуатирует” и 2. “машина времени в будущее, предсказание”. Одновременно почему-то не берётся. Перенос идёт сначала по линии времени, затем упирается в момент продажи – и тут у большинства студентов линия времени останавливается, “не моё дело”. Ибо там надо ещё и другие интересы обсуждать.
– ещё один интересный момент в статье касается вреда обсуждения памяти как набора записей. Основная идея – это то, что кладёшь в память одну информацию, а потом меняется ситуация – и вынимаешь другую. Память не “объективна”, это не “записи” – там важна интерпретация. Выглядит как-то очень умозрительно, но это же очень часто обсуждаемый вопрос в бизнесе, например, вот – “Почему я никогда не использую теги” (2009), Почему я не использую теги: ailev — LiveJournal. Суть в том, что теги и ключевые слова периода запоминания не совпадут с тегами и ключевыми словами периода вспоминания. Поэтому мы не можем привязаться при запоминании к ситуации вспоминания, вспоминание пойдёт ассоциативное (да, можно тут и про распределённые представления поговорить, много о чём поговорить. Там в посте по ссылке много примеров, а затем интересное завершение – “Экстремально позднее связывание(extreme late binding), как сказали бы программисты, хотя и специфически понимаемое и на совсем-совсем другом материале”). Это всё связано с понятие типа – ибо кладёшь в память вроде одни типы, а достаёшь вроде как другие. Понятно, что тут будут дикие холивары про то, “как надо” – весь спор про статический контроль типов хорош для одной версии, но что там про extremely late, про включение в рассуждение эволюционного масштаба времени, эволюции программы? Что там с evolvability? В любом случае: память это не “что положил, то достал” – нет, она всегда оказывается связана с интерпретацией того, что было извлечено.
– отдельно можно пообсуждать “пересказ текущих эвристик какой-то предметной области языком какой-то абстрактной теории” и наоборот – “пересказ выводов из какой-то абстрактной теории понятным самодокументируемым для спецов какой-то предметной области текстом”. Поскольку речь идёт о понятизации, то есть подборе слов для каких-то мест в пространстве значений, можно пробовать использовать LLM. Это оказывается крайне эффективно. Скажем, для онтологического дребезга недавно нашли ontological buzz как англоязычный эквивалент. Ясно, что этого ни в каких словарях нет. Вот для статьи Fields и Levin перевод с птичьего на понятный бизнесу и инженерии язык – это оказалось интересно. Я планирую попытать нейросетки по поводу проектов вроде Rozetta stone от Baez и evo-devo-thermodynamics-deeplearning проект Ванчурина со товарищи. Там хорошие таблички, но не хватает ещё одной колонки: “инженеры и менеджеры” (а также “учителя” и прочие возможные архироли). А зачем тогда все эти статьи? Ну, “простые слова” начинают соответствовать математическим объектам, ибо там же везде математический формализм. Мы стараемся брать не любые фреймворки как “наши концептуализации”, а которые стоят на математическом формализме. При этом мы вольны выбирать для математических объектов в их физическом употреблении удобные нам имена, а не оригинальные из птичьего языка теории – ибо тамошний птичий язык возникал исторически. Это чуток напоминает ту самую “память”, куда кладёшь в одной ситуации (хранение академической традиции какого-то предмета, все эти “минимумы свободной энергии”. И я немедленно потратил несколько часов на беседы с o1 про active inference – что там новенького для инженерии и менеджмента и как это можно было бы назвать. o1 – очень умный собеседник, весьма эрудированный, старается отвечать на вопросы, но “выношу я с завода швейных машинок детали, но как ни собираю, получается только станковый пулемёт”. Active inference, даже переведённый на язык менеджемента и инженерии, оказывается аналитическим фреймворком. Вся “творческость” приговаривается к “обучению”, “предсказанию”, “измерениям” – и это всё вроде понятно, но вот про творческую часть порождения стратегии, затем планирования, затем выполнения действий там нет ничего, но o1 легко добавляет, если попросить, наваливая это всё на порождающую модель, без детализации. Но есть зато всё про то, как оценивать результат: смотреть на то, как мы ошибаемся в предсказаниях, причём смотреть по Байесу. И всё это одновременно, едино одномоментно на всех уровнях и во всех частях всех систем – архитекторам, которым надо это резать на части, а теория наоборот, говорит про “единство и одновременность”, чешут затылок: чем это всё помогает? Итоговые формулировки после перевода птичьего языка на общепринятый оказываются неотличимыми от того, что говорится сегодня во всех учебниках: всё быстро меняется, вы должны непрерывно всё отслеживать, для чего у вас должны быть хорошие информационные системы, далее должны непрерывно менять себя и мир – и вот тут небольшая невязка с языком, ибо по теории надо минимизировать разрыв между предсказанием и измерением, но любой менеджер задаст вопросы про то, где там не предсказание, а наоборот – проектирование, чтобы предсказывать belief в то, попадаем ли мы туда. И всё опять по кругу, o1 тут не слишком хороший помощник.