22 февраля 2025 стартует курс “Рациональная работа”, первый курс в программе “Организационное развитие” (Программа "Организационное развитие", 2024-2025 учебный год: ailev — LiveJournal и немного по-другому в Программа "Организационное развитие" на пороге 2025: ailev — LiveJournal). Курс ведут два преподавателя (Прапион Медведева и Анна Лубенченко), курс идёт 12 недель, занимает примерно 120 часов (чтение учебника, выполнение заданий, встречи с преподавателями), это режим “хобби”, по 10 часов в неделю, по два часа в день на пятидневке. 22 февраля — установочная встреча, 25 февраля – первая тренировка, 24 мая — двадцатая тренировка, занятия с преподавателем вторникам с 18:00 и по субботам с 11:30 (GMT+3), примерно по полтора часа каждое. Курс идёт по свежеобновлённой программе, в которой сочетаются начальное знакомство с операционным менеджментом (“работа”), а также необходимым для работы рациональным принятием решений, в том числе моделированием ситуаций с необходимой собранностью (“рациональная”). Это методология lean/элегантной работы, когда не делаются лишние работы. Курс этот – обязательный пререквизит к “Системному мышлению”, ибо как раз на этом курсе включается на нужном уровне собранности “машинка типов”, необходимая для прохождения материала системного мышления, а также даются начальные знания по различению работы и метода работы. Учебных проектов в курсе нет, всё делается прямо на материалах рабочих проектов – поэтому результаты будут не только “в голове”, но и в проекте. Регистрация на курс – Первый семестр программы "Организационное развитие". Основная трудность – реально выделить 120 часов, ибо это как в качалке: нет часов занятий – нет результатов. Основные причины срыва – “недооценил необходимость выделения времени”. При этом освоение материалов курса высвобождает больше времени, чем берёт на себя курс, ибо в курсе есть материалы по операционному менеджменту и собранности.
Потратил не меньше полного дня на разговоры в русскоязычном чате Julia. Вот что понял:
– в Julia хотели решать проблему двух языков: “писать быстро, как на Python, выполнять быстро, как на C”. Эта задача была решена для ситуации “олимпиадного/научного программирования”: у вас есть задачка на 500 строк хитрого кода, который надо как-то покрутить-повертеть перед тем, как этот код заработает.
– в реальной ситуации это приводит к тому, что компиляция автоматизирована и код таки выполняется быстро. А вот с “писать быстро, как на Python” не задалось: для увеличения скорости написания используются сейчас IDE с copilot, а у Julia такого не случилось. Почему? Потому как традиционно для экспериментов использовались реактивные ноутбуки вроде Jupyter (и Ju там как раз от Julia), а для олимпиадного/научного программирования такого хватает, хотя иногда сейчас используют Pluto. IDE используют относительно мало.
– засада в copilot: в реактивных ноутбуках copilot может взять довольно маленький контекст, ибо там его надо применять “сбоку”. А в IDE типа Cursor всё интегрировано. В итоге с notebook использование AI “нормально, помогает!”, а с IDE, где copilot получает большой контекст – “вау! всё летит!”. Типовая история выглядит так (заодно там небольшая реклама той самой “Рациональной работы” из предыдущего абзаца, приводятся причинные диаграммы, которые строят в курсе): Как я освоил новый метод работы - анализ табличных данных с программированием на русском - #3 от пользователя mikhail-dobynde (и этот же текст на Хабре – Как я освоил анализ табличных данных с программированием на русском / Хабр).
– итог печальный: писать без IDE с copilot получается не так быстро как на Python, только выполнять быстро, как на С. При этом быстрое выполнение в проектах на других языках нужно обычно только для маленького кусочка кода. То есть вся затея с решением проблемы двух языков и удалась, и не удалась: если у людей в других сообществах было три минуты свободного времени, они его тратили или на докрутку своих алгоритмов, или на инструментарий. А в сообществе Julia на инструментарий не тратили, докручивали алгоритмы. Поэтому проблема двух языков оказалась нерешённой в части инструментария: когда пришло Software 3.0, оно же vibe-coding (с лёгкого языка Karpathy), то есть “программу пишем на естественном языке, а LLM как компилятор это перегоняет в язык программирования”, то если у тебя есть инструментарий такого перегона – будешь писать быстро, если нет (а у Julia хорошего инструментария, то есть использующего большой контекст, пока нет), будешь писать медленно.
– на что же настроено сообщество Julia, если так игнорирует проблемы инструментария? Ибо если не решается проблема двух языков, а сообщество существенно выросло, то в чём там оказалось конкурентное преимущество? Оно оказалось таки в решении expression problem (пополняемости програмы новыми типами данных и новыми процедурами без переписки всего кода): это крайне важно для организации разных “солверов”. Согласно теореме о бесплатном обеде, невозможно сделать один общий универсальный алгоритм, эффективный для всех частных случаев какой-то задачи. Так что приходится разными алгоритмами решать самые разные частные случаи – и какая-нибудь “оптимизация” превращается в кошмар выбора из пары сотен алгоритмов, каждый из которых эффективно решает один частный случай, но неэффективно – все остальные, а частные случаи задаются DSL. Вот пакеты типа JuMP (https://jump.dev/, оптимизация) или дифференцируемого программирования и имитационного моделирования (SciML: Open Source Software for Scientific Machine Learning with Julia · Overview of Julia's SciML, включая решение дифференциальных уравнений и суррогаты для аппроксимации, включая нейросуррогаты – Function Approximation · Overview of Julia's SciML) и развиваются, и круче их ничего на планете нет. Они как раз эксплуатируют такую постановку задачи: каждый “частный случай” это олимпиадное/научное программирование, требует огромного счёта, случаев много (полнота имеет значение!) и требуется язык для их описания. А инструментарий? Хватает реактивного ноутбука!
– Поэтому можно ожидать, что для олимпиадного/научного программирования в Julia ситуация с инструментарием вряд ли поменяется в ближайшее время. А потом поменяется: с естественного языка можно будет компилировать куда-нибудь прямо в оптимальный код для машинного исполнения чуть ли не прямо через LLM, прямо в уровень LLVM – и заделы там уже есть, например, LLM оптимизирующий компилятор Meta, [2407.02524] Meta Large Language Model Compiler: Foundation Models of Compiler Optimization, LLM Compiler - a facebook Collection. В мире языков программирования и компиляторов тоже всё стремительно меняется, компиляторные оптимизации стремительно уходят из мокрых нейронных сеток в нейронные сетки нежити. Сюда же можно отнести оптимизацию вычислительных ядер для GPU (три поста с Telegram: Contact @seeallochnaya).
В принципе, эта теорема о бесплатном обеде (в экономике у неё есть дальний родственник: теория сравнительных преимуществ) даёт шанс на задействование самых разных физических вычислителей – прежде всего речь идёт о символьных вычислителях и нейронных. Уже очевидно, что интерфейсный модуль к вычислителю от человека будет LLM – ибо там общение идёт на привычном и удобном для человека “общем” для всех классов задач языке, естественном. И даже MLLM, ибо можно добавить изображения, аудио и даже видео. То есть получается фреймворк из MLLM, в котором где-то внутри вызываются программы-ускорители/инструменты (ускорители они в терминологии CYC, ибо как раз та самая “теорема о бесплатном обеде” говорит об эффективности, сиречь, скорости для каждого “частного случая”, вот эта архитектура в [2308.04445] Getting from Generative AI to Trustworthy AI: What LLMs might learn from Cyc, где говорится, что “универсальный алгоритм” пришлось удалить – он не справлялся никогда, зависал на бесконечной комбинаторике). Вызов логики может быть разными способами:
– классические reasoning/thinking модели, где генерируются токены “промежуточных рассуждений” – R1, o3, Gemini 2.0 Flash thinking, Grok 3 reasoning и т.д.
– попытка вынуть логическое рассуждение CoT и перенаправить их в логический ризонер, [2409.12183] To CoT or not to CoT? Chain-of-thought helps mainly on math and symbolic reasoning (и получить тот же результат, что и при обычных reasoning моделях). Это развитие линии Toolformer, [2302.04761] Toolformer: Language Models Can Teach Themselves to Use Tools, где сетка изучала, для какой задачи лучшё дёрнуть какой API – это ровно как в CYC пытались такое сделать на основе логических движков, “ускорители/инструменты” на API, только в CYC не было “познания” этих API инструментов, счёт которых шёл на тысячи. А в Toolformer этих tools были единицы штук, только для proof of concept.
Эмулирование логических рассуждений в нейросетках может идти в естественном языке (это как раз делают все современные reasoning/thinking модели – R1, o3, Gemini 2.0 Flash thinking и т.д.), а естественный язык разбирать на токены. Каждый токен представляет собой проекцию в язык некоторого места в многомерном пространстве смыслов, latent space. И если проводить рассуждения “в токенах”, то квантование этого латентного пространства происходит в терминах токенов – где токен есть, туда и отквантовали. Где токена нет, рассуждение туда бы хотело пойти, но не пойдёт – будет отквантовано к ближайшему токену (который может быть не очень ближайшим). Поэтому надо как-то избавляться от дискретности токенов и уходить в дискретность представления латентного пространства – она существенно менее “дискретна” (даже если там 1.58bits на вес модели, точки этого латентного пространства могут быть представлены со много лучшим разрешением, нежели с привязкой к токенам). Так что уходим от токенов во всё латентное:
– сразу, это byte latent trasformers, Byte Latent Transformer: Patches Scale Better Than Tokens | Research - AI at Meta
– налаживаем диалог между несколькими сетками без токенов: DroidSpeak, [2411.02820] DroidSpeak: KV Cache Sharing for Cross-LLM Communication and Multi-LLM Serving
– уводим reasoning в latent space, это coconut, Coconut by Meta AI: Redefining LLM reasoning in continuous latent spaces, и дальше целый ручеёк работ, например, [2502.05171] Scaling up Test-Time Compute with Latent Reasoning: A Recurrent Depth Approach (и комментарии x.com, изучаем, как в латентном пространстве идут логические операции – плохо идут, там возникают “орбитальные” алгоритмы для простейших сложений, дико неэффективно, вот тут тоже это показывают – вместо сложений идёт тригонометрия, [2502.00873] Language Models Use Trigonometry to Do Addition). Вот тут в архитектуре робота между двумя его нейросетками передача идёт тоже lantent vector – Helix: A Vision-Language-Action Model for Generalist Humanoid Control
– в reasoning заставляем чётче логически рассуждать, но вместо вывода на внешние инструменты-солверы держим это рассуждение прямо “в уме”, а для “чётче рассуждать” учим сетку логическим рассуждениям, поначалу просто скормив ей много кода из интернетов (это нашли уже давно, но существенного прироста reasoning это не даёт), а затем обучая логически программировать, например, на Прологе – это тоже сильно продвигает (Use Prolog to improve LLM's reasoning - Shchegrikovich LLM и [2410.11900] FLARE: Faithful Logic-Aided Reasoning and Exploration), и вот “FLARE: Faithful Logic-Aided Reasoning and Exploration”, [2410.11900] FLARE: Faithful Logic-Aided Reasoning and Exploration, где задачу готовят “как для внешнего солвера логики”, а затем решают таки внутри сетки.
– переход с авторегрессионных моделей на другие типы, где рассуждать проще. Скажем, диффузионные модели уже представлялись как реализующие эволюционный алгоритм (Diffusion Models are Evolutionary Algorithms – тут хороший обзор), но вот появился вариант LLM на диффузионных моделях, [2502.09992] Large Language Diffusion Models, LLaDA, которая переплёвывает аналогичные по размеру LLaMA. И там, конечно, тоже вполне можно поощрять reasoning внутри модели в latent space.
Одна из весёлых техник выключения людей из активной дискуссии в ходе так называемых “мероприятий активного типа” (в просторечье это – игры, организационно-деятельностные или даже просто деловые) заключается в переводе людей из аптайм-транса (когда внимание направлено на окружение, как в драке) в даунтайм-транс (когда внимание направлено внутрь себя, интроспекция). Если вам надо выключить кого-то из активной дискуссии, просто спросите его про то, что там внутри него – неважно, что. Это может быть “какое платье носила ваша бабушка, когда вы её видели в последний раз” (реальный был вопрос во время демонстрации ухода в транс! Это делал Ян Ардуй, когда приезжал в Россию) до “а что ты вот прямо сейчас делаешь?” (традиционный вопрос СМД-методологов на их мероприятиях, “ход на рефлексию”, только рефлексия – это обсуждение прошлого, а тут вопрос про “прямо сейчас”, это интроспекция, а не рефлексия). Дальше человек уходит в себя, у вас есть время общаться с остальными участниками дискуссии – иногда это всего секунды три, но эти три секунды вас никто не будет перебивать, активный и неглупый человек в даунтайм трансе! В принципе, легко сбить дискуссию, если из аптайм транса отслеживания содержания уходить на обсуждение вопросов, связанных с личностями присутствующих (ходы, обычные для интернет-дискуссий, где вместо обсуждения идей обсуждают выдвигающих эти идеи людей). А поскольку содержание уже побоку, то разговор сразу становится философским – и не то, чтобы обсуждалась эпистемология (что было бы нормально: способ договориться, что там с теориями, стоящими за содержанием разговора), а просто трёп и отвлечение, художественный поиск смысла жизни в этих ваших интернетах. Картинка про это, про философов и даунтайм транс.
