Мышление письмом по поводу курса "Методология систем AI"

ailev · 10.Июнь.2024 13:18:19

Прикладная методология на базе фундаментальной методологии.
Это продолжение поста “Как обсуждать функциональные архитектуры интеллектуальных систем”, Как обсуждать функциональные архитектуры интеллектуальных систем: ailev — LiveJournal с необработанными заметками из моих реплик в чат Gonzo_ML_chat (Telegram: Contact @gonzo_ML – чат при канале “gonzo-обзоры ML статей” с обзорами статей по методологии ANN и LLM, а также близким к этому темам, которые пишет Григорий Сапунов). Я хочу тут чуть конкретизировать, как же перейти к написанию учебного курса по методологии систем AI.

Курс “Методология систем AI” посвящён функциональным декомпозициям/синтезу систем AI. Почему методология? Потому что для неживых систем мы говорим “функции” (функции банкомата, функции телефона), и их не выбирают, а для агентов говорим “методы”, и их вроде как ангенты выбирают: методы/способы работы агентов. Но вот в объект-ориентированном программировании “методы” – это виды работ, которые можно делать с объектом. Подробней о методах рассказывается в свежепереписанном курсе “Системное мышление” (Aisystant, все ссылки на тексты курсов ведут на бесплатный доступ после регистрации) и сейчас переписываемом мной курсе “Методология” (Aisystant), онтику метода (кратенький рассказ о понятиях, которые раскрываются в курсе “Методология”) я публиковал у себя в блоге совсем недавно – О чём будет, и о чём не будет рассказано в курсе «Методология».: ailev — LiveJournal.

В AI-литературе “методы” относятся к видам работ, которые могут делать AI-системы, например, нейросети, но также и виды работ, которые могут делать инженеры AI-систем.

Скажем, “методы обучения без учителя”/“unsupervised learning” в статье википедии Обучение без учителя — Википедия – это “один из способов машинного обучения”. Способ – это полный синоним метода. То есть машинное обучение – это род метода, для рода можно специализировать (отношение специализации, род-вид) его виды – обучение без учителя, обучение с учителем, полуавтоматическое или частичное обучение (self-supervised learning). Проверяем: вот тут говорится, что это таки метод: Машинное обучение без учителя (Unsupervised Learning) | Cloud.ru, “Машинное обучение без учителя или неконтролируемое обучение (Unsupervised Learning) — метод машинного обучения (Machine Learning, ML), при котором модель обучается выявлять закономерности и скрытые взаимосвязи на наборах неразмеченных данных без контроля со стороны пользователя”. Метод или способ – это всегда метод или способ работы, он выполняется ролью агента-работника. Кто ж тут этот агент? Похоже, что обучение/learning (род) у машинного обучения (вид) – это метод работы модели. Если бы говорилось о том, что это метод работы инженера, то было бы не learning, а teaching: учить кого-то это teach, а учиться кому-то – это learn.

Дальше мы понимаем, что прикладная “методология” изучает методы работы каких-то систем, основываясь на фундаментальной методологии, и в самых разных инженерных проектах с ней работает роль “методолог” (гипотеза об этом была высказана в Методолог -- то, что не вошло из старого в современного архитектора и осталось в разработчике: ailev — LiveJournal). Роль методолога будет выделена теперь из роли разработчика во всех инженерных курсах – “Системная инженерия” (Aisystant), “Инженерия личности” (Aisystant, причём она по факту там уже есть, уж так получилось), “Системный менеджмент” (Aisystant). Все инженерные роли пользуются фундаментальной методологией (которая из курса “Методология”), например, архитекторы используют фундаментальную методологию, чтобы разбираться со своими проблемами – “что делать, когда непонятно, что делать, каким методом работать”, но кроме того, все инженерные роли пользуются прикладной методологией, то есть умеют выбрать нужные методы работы для живых и не очень живых агентов, включая те системы, которых и агентами-то не принято называть, например, методы работы двигателей внутреннего сгорания или методы работы ANN или какого-то их подкласса, например, трансформеров.

Прикладная методология при этом использует два основных типа отношения, разъясняющиеся в курсе “Методология”:
– разложение метода (как в математике, “разложение в ряд”, хотя в английском это будет expansion, “расширение”). В каждом методе выявляем какие-то отдельные частные методы (слово “подметод” не говорим, ибо “под-” коварная приставка, может обозначать и часть-целое, и род-вид, и классификацию, она всё равно как “мета-”, каждый раз требует договорённости о том, что там имеется ввиду. По поводу “подметода” такой договорённости нет). Речь идёт о дроблении метода. В разложении обычно мы имеем какие-то “потоки” – функциональные/принципиальные кинематические, гидравлические, логистические (транспортные), даталогические (data flow, потоки данных) и прочие подобные “диаграммы”, хотя “диаграммы” тут в кавычках только потому, что это просто один из способов показать топологию “путей”. Разложение методов связано с понятием “пути” и “потока” как определяемого на основе единства пути (как функция определяется единством назначения, конструктив единством материального представления, размещение – единством удержания места). Все эти представления, конечно, связаны.
– выбора вида из рода в ходе набора методов в разложение, причём род задаёт сигнатуру метода (название основного поведения и предметов, меняющих своё состояние в ходе поведения метода), а вид определяется его разложением, которое тоже по факту может быть сокращено до сигнатуры.

Прикладная методология искусственных нейронных сетей (ANN)
Давайте поглядим, как это выглядит для ANN. В Gonzo-обзорах первый раз слово “метод” встречается 25 февраля 2019 в обзоре работы “AET vs. AED: Unsupervised Representation Learning by Auto-Encoding Transformations rather than Data” (Telegram: Contact @gonzo_ML), фраза “Дальше в работе рассматривают только параметрические преобразования. Это типа проще реализовывать, а также проще сравнивать с другими unsupervised методами”. Онтологически из фразы следует, что unsupervised learning::метод это род методов, в котором есть множество видов методов.

Если мы залезаем в саму статью, то там они называются то подходы, то архитектуры, то даже efforts как метонимия усилий команды, разработавшей метод, в фразах типа "Among the efforts on unsupervised learning methods, the most representative ones are Auto-Encoders and Generative Adversarial Nets (GANs) – но мы-то знаем, что это методы! и слово representative не имеет отношения к representation learning, хотя казалось бы, могло бы и иметь).

Помянутые методы называют вместе родом autoencoder data (AED) как выучивание распределения по данным, и вводят ещё один род: autoencoding transformations (AET), где могут быть ещё и виды: large variety of transformations can be easily incorporated into the AET formulation. Так, виды будут – параметрические преобразования::метод (Parameterized Transformations, как подвиды там пример – афинные и проективные), а ещё GAN и непараметрические. Преобразования – это transformations, в русском тексте обзора синонимизируются трансформации и преобразования. Вопрос, преобразования чего? Изображений, ибо текст 2019 года обсуждает главным образом распознавание изображений на тестах типа CIFAR-10.

Статья следует давней традиции: роды называют методом, а всё более мелкое в видах (из которых далее идёт выбор чего-то одного, как в “мебельных гарнитурах” выбраем какую-то определённую модель гарнитура) и разложениях (выбранный гарнитур содержит ряд разных предметов мебели, но они рассматриваются вместе – столы, стулья, шкафы) называются как бог на душу положит, и только иногда – методом. Скажем, в искусстве самое крупное деление картины – композиция (где там небо, где земля, где люди), помельче – содержание (что именно нарисовано, какие вообще там предметы в рамках композиции), самое мелкое (уровня мазка/штриха) – стиль. Вот так и тут – supervised learning консистентно называют “метод машинного обучения” (то есть вид “машинного обучения”::метод работы какой-то модели, познающей/learn какое-то статистическое распределение), а вот виды этого метода как рода и методы в разложениях этих видов – уж как придётся. Но мы-то знаем, что всё это методы! Поэтому наше мышление тут работает одинаковыми ходами. И этим ходам можно научить!

Как же выглядит разложение метода? Когда вы смотрите на диаграммы “архитектуры нейросети”, то это оно и есть: “принципиальная схема”/“функциональная диаграмма”, по которой текут данные примерно так же, как электрическая принципиальная схема показывает потоки электрического тока, а гидравлическая схема показывает потоки жидкости. И с этим никаких затруднений обычно не бывает. Но бывают затруднения с методами в их родо-видовых отношениях, ибо по большому счёту родо-видовые отношения задаются произвольно, а спор о том, как мы определяем род и вид – это спор о терминах, онтологический спор, который непродуктивен. Но делать нечего, работаем с ламаркианскими классификаторами, как биологи работали со своими классификаторами до той поры, когда разобрались в генетике. Мы вынуждены будем разбираться в меметике AI-систем, ибо речь идёт о техно-эволюции со smart mutations.

Пробегаем Gonzo-обзоры до 30 апреля 2024 (Telegram: Contact @gonzo_ML), там свежий обзор PEFT (Parameter-Efficient Fine-Tuning) алгоритмов для LLM. Смотрим на то, как употреблено слово “алгоритм” – ах, это те же методы! Как проверить? Берём картинку из статьи ([2403.14608] Parameter-Efficient Fine-Tuning for Large Models: A Comprehensive Survey) и видим типичную ламаркианскую классификацию родов-видов именно методов, причём картинка названа именно классификаторски, “таксономией”, аж на пять уровней:

Но если мы поглядим на то, что же такое PEFT даже не в самой статье, а просто аннотации, то увидим, что слово “метод” употребляется не как объект первого класса, а как что-то литературно-художественное, что тоже требует синонимизации, для пущей выразительности, термином авторы это не считают: один раз это род разных видов “процессов” (но из курса “Методология” мы знаем, что “процесс” – это тоже синоним “метода”), а вот в другой раз – это род алгоритмов. Как это читать? А так и читать: алгоритм/теория/объяснение описывает метод (а чтобы не было сомнений, что теория и алгоритм – это одно и то же, то можно вспомнить про соответствие Curry-Howard – императивные и логические программы суть одно и то же, математические доказательства – это программы). Метод – это то, что делают в жизни нейросетки, проявляя “мастерство выполнения метода”, а алгоритм – это то, что было взято для реализации этого мастерства для программирования вычислителя, проявляющего затем метод.

Зачем нам нужен курс прикладной методологии систем AI?
Сложно разбираться со всеми этими “методами” и “алгоритмами”? Да, поначалу сложно, поэтому-то и делаем курс. Чем поможет курс? А вот чем:
– методологии становится можно учить не “на примерах”, а путём объяснений. Курс “методология” как раз про это. Метод становится объектом первого класса, методы можно затем описывать, сравнивать, распознавать, придумывать новые методы.
– можно по поводу методов для синтеза (как в “логическом синтезе” для логических цепей и “синтезе программ” в софте) и для декомпозиции (в инженерии – “разузловка”, “функциональная декомпозиция”) использовать общее инженерное мышление. Не надо специально учить, как думать о методах машинного обучения или методах инженерии систем AI. Точно так же думать, как о методах проектирования унитазов или методах инженерных обоснований в аэрокосмической промышленности. В 1968 году была парочка конференций NATO: что это такое, “написание компьютерных программ”? Как этому учить – как исследователей, как инженеров? Пришли к выводу: учить, как инженеров (при этом инженеров, заметим, хорошо так учат высшей математике, у них же инженерные расчёты, как же без этого!). Появилась специальность software engineering и software engineer. Как учить тех людей, кто проектирует нейросетки, проектирует LLM (обученные нейросетки), проектирует AI-агентов (там кроме обученных LLM есть много чего ещё)? Тоже “инженеры”, и мышлению этих инженеров надо учить инженерному, и умение что-то исследовать входит в состав инженерного мастерства.
– работа прикладного методолога – это половинка “старой архитектуры”, а “старая архитектура” – это то, что делалось “самыми опытными разработчиками”. Новая архитектура – это главным образом про модульный синтез, работа с конструкцией на предмет успешности системы в части архитектурных характеристик. А вот функциональный синтез остался “самым опытным разработчикам”, ибо это ж работа на предмет успешности в части пользовательских характеристик – и потом эта функциональная декомпозиция/синтез вписывается в заданные архитектором ограничения в части модулей и их связности. Вот эта работа “самого опытного разработчика” – это и есть работа методолога (подробней – Методолог -- то, что не вошло из старого в современного архитектора и осталось в разработчике: ailev — LiveJournal). Если понимаешь, в чём суть методологической работы, то можно учить ей так же, как и любой другой инженерной специальности, не надо ждать, пока станешь “самым опытным разработчиком” и паттерны этой работы как-то пропишутся в мозгу сами. Заметим, что ровно такой же путь проделало и понимание архитектуры – где-то с 2017 года появились многочисленные книги, рассказывающие о том, что же именно делает архитектор в модульном синтезе. А до этого? До этого работа архитектора шла больше “по наитию”, то есть по принципу “делай архитектуру хорошо, не делай архитектуру плохо”. А старое понимание архитектуры? Ну, Ральф Джонсон: “архитектура – это всё важное, чем бы оно ни было”. Вот и учитесь “видеть важное, не важное не видеть”. Всё поменялось с архитектурой, теперь всё стремительно меняется с методологией.

Три шага для начала работ над курсом “Методология систем AI”
С курсом “Методология систем AI” нужно сделать три вещи (не считая того, что мне нужно переписать курс методологии, а разработчикам курсов нужно таки пройти наш набор курсов – ибо там же и архитектуру надо знать, и много чего ещё):

Для начала собрать вордовый файл, где прямо под заголовками первого уровня собраны разборы функциональных архитектур разных сеточек. Это нужно для того, чтобы вытащить язык разговора — все эти “блоки”, “вставки”, “памяти” и т.д. Вообще-то это хорошая работа для какой-нибудь InstructLLM, но мне кажется, что пока человек с этим проще справится. Я вполне готов почитать эти тексты глазиками и вытащить какие-то паттерны, например, паттерны употребления слова “метод” и “алгоритм” в текущем тексте были вытащены из статьи 2019 года. Моя главная гипотеза в том, что паттерны методологии систем AI в Gonzo-обзорах ML статей есть в количестве, хотя главным образом для ANN и LLM, но просто ещё более высокие уровни не настолько развиты сейчас, чтобы о них выходило много работ. Эти паттерны нужно только вытащить — и суть курса в том, чтобы студент научился проводить такие разборы самостоятельно, а в пределе — научился делать smart mutations для функциональных архитектур систем AI, по которым потом было бы интересно писать обзоры. Грубо говоря, сначала учим читать (то есть понимать) функциональные архитектуры из самых разных текстов, диаграмм, кодов, а потом ещё и объясняем, как интересно писать (то есть разрабатывать) эти архитектуры. Слово “функциональная архитектура” тут просто исторически сложившийся термин, который немного запутывает: это разговор не про конструктивные блоки, а про функциональные блоки.
Предложить какой-то вариант SoTA представления для архитектур на базе уже проведённых Gonzo-обзоров. Тут, конечно, большое желание применить какой-то формальный язык, но не факт. Просто давать обычным языком, как в обзорах – но по сути, там не просто “обычный язык”, а некоторый “псевдокод имени Гриши Сапунова” (и тексты на этом псевдокоде приходят читать сейчас 16 тысяч человек, ибо тексты на этом псевдокоде оказываются едва ли не интереснее, чем тексты самих статей – в частности, они помещают уникальные результаты каждой статьи в общий ряд функциональных архитектур так, как этого не могут выразить сами авторы статей, о чём вот только сегодня было замечание в Telegram, и там же пожелание научить авторов статей на тему (функциональной) архитектуры писать так, чтобы за ними не надо было переписывать их текст в обзоре. Все эти варианты представлений “а теперь мы покажем вам, как это выглядит на питоне” — не факт, что надо. Тем более что Карпаты показывает сейчас с большим успехом, “как это выглядит на си”. Но “простые архитектурные диаграммы” тут тоже не подойдут, к каждой диаграмме ведь нужно приписать огромное количество текста, что в ней нарисовано (это часто забывается! диаграммы того же трансформера совершенно непонятны без пространных объяснений, что там нарисовано). Плюс всё одно надо иметь средства выражать таксономии методов. То, что в этом тексте приведено картинкой, много проще делать аутлайном: все эти MindMaps с деревьями оказались быстропроходящей модой (всё, никто их не рисует! А как модно-то было!), зато книжки и даже статьи с многоуровневыми оглавлениями продолжают делать, и ведь это полностью эквивалентные формы! Вот и Gonzo-обзоры – это тексты на некотором “controlled русском” для псевдокода функциональных архитектурных описаний.
Надо сделать оглавление курса, чтобы было с чего начать. Это оглавление может быть устроено примерно так же, как у меня устроен “Интеллект-стек”, где первый раздел посвящён описанию сигнатуры мышления: есть интеллект, он работает с проблемами, занимаясь стратегированием (выработкой policy, как говорят в AI), планированием, исполнением планов (причём это 4E интеллект, то есть embodied, extended, embedded и enactive, ну или это можно представить как реализующий active inference интеллект), но затем идёт разложение методов интеллекта – результат разложения представлен как объяснительный “интеллект-стек” SoTA методов мышления: понятизации, собранности, семантики, математики, физики, теории понятий, онтологии, алгоритмики, логики, рациональности, познания/исследований, эстетики, этики, риторики, методологии, системной инженерии. Для каждого метода мышления интеллект-стека говорится о том, зачем он нужен, какое его место в мышлении, а также приводится краткая характеристика его современного (SoTA) состояния.

Для курса “Методология систем AI” по большому счёту тоже можно выдать интеллект-стек, только в его “программно-аппаратной” с innate priors как методы ещё не окультуренного “научного и инженерного”, а ещё “вычислительного общеагентского” мышления. “Интеллект-стек” из моего курса с его чисто “программной” с inductive bias как методы мышления частью получает продолжение в аппаратуру – и в этой аппаратуре уже “классический” стек, а не “объяснительный” как в интеллект-стеке. Объяснительный – это идея, что на базе понятий нижележащих в условном стеке теорий/алгоритмов/объяснений методов можно как-то объяснять более высоколежащие в стеке понятия. Условно говоря, при понятизации можно ещё не рассматривать этику как метод работы совести, а вот при работе совести понятизацию уже хорошо бы рассмотреть – это условное изображение стека мышления, вытянутого из графа теорий/алгоритмов в какое-то подобие стека. А вот условное представление программно-аппаратной части полного интеллект-стека в виде стека – это более классическое функционально-платформенное представление.

Вот пример оглавления, просто “из головы” в порядке бреда письмом:

1. Понятие о методологии систем AI
— отсылки к материалам по прикладной методологии
— характеристики систем AI, для которых тут приведена методология
— принятая иерархия разложения метода (сообщества гетерогенных агентов; рои агентов; когнитивные архитектуры агентов; программы с LLM и их обвязкой CoT, PoT, Toolformers; собственно LLM, включая MoE и dense, строительные блоки для LLM; отдельно ветка с GOFAI, отдельно архитектуры нейросимволических вычислений)
— основные функциональные характеристики на каждом уровне (чего хотели бы добиться)
— связь методологии и архитектуры (связь функциональных характеристик с архитектурными — и вроде как все эти harmlessness оказываются архитектурными, а не функциональными)
2. Обзор по приведённым уровням иерархии, из них в GONZO-обзорах главным образом были “собственно LLM”, состоящие из “блоков LLM”, а до обвязки дело не дошло, society of minds тоже по факту не обсуждалось. Поэтому начинаем отсюда (раздел), а потом смотрим, что можно сделать. Но в этом пункте получается штук шесть-семь разделов. Фишка в том, что все они рассказываются в одном общем методологическом языке, но вот предметы там разные — где-то внизу функции активации, а где-то вверху — вполне автономные коммуницирующие агенты.
3. Стык с архитектурой в её новом понимании, что требует отдельного пояснения. Во-первых, архитектура – это про нарезку на модули, которая делается “в общем виде”, вне особой зависимости от функций (на некотором уровне генерализации, все эти “архитектурные паттерны” и “архитектурные стили”), но всё-таки в зависимости от функции – по получившимся модулям проектировщики таки должны разложить предлагаемую методологами функциональность. То есть в этом разделе разбирается, как именно результаты работы методолога (с него – функциональная декомпозиция/синтез) и архитектора (с него – модульный синтез/декомпозиция) сплетаются в работе проектировщика/designer, который и создаёт концепцию системы как взаимоувязку основных системных представлений/аспектов, прежде всего функционального и конструктивного.

Так что работа роли методолога – это поддержка работы проектировщика в плане имеющихся в его распоряжении функций, так же, как и работа архитектора оказывается поддержкой в плане передачи проектировщику от архитектора верхнеуровневой структуры модулей и выбранных уже для него интерфейсов, и надо как-то эту “тесную связь” в создании концепции системы прописывать и в курсах для методологов, и в курсах для архитекторов, и в курсах для проектировщиков.

Новое разделение труда в инженерии: различаем архитектора, методолога, проектировщика/designer
Увы, в курсах для архитекторов метод работы разработчиков описывается в целом, без выделения специфической методологической части и части проектирования. Да и в курсе для проектировщиков/designers не так много говорится про разделение инженерного труда разработчиков. Поэтому нам придётся в курсе для разработчиков (а это обычно обзорные курсы инженерии) показать, как увязаны работы всех этих трёх ролей, как устроено разделение инженерного труда. И ещё дополнительно прописать это разделение труда, как оно видится методологам – в курсе методологии (и фундаментальном, и в прикладных курсах для отдельных дисциплин, например, в курсе методологии систем AI).

Каждый отдельный модуль из крупной нарезки на модули архитекторами проектировщики всё одно будут потом реализовывать как “подсистему, реализованную конструктивом”, то есть разрабатывать “концепцию системы”, и это будет ещё и многоуровнево (самолёт-двигатель-топливный насос, или АI-агент-LLM-многоголовое внимание – это всё равно, инженерное рассмотрение тут общее, в этом и фишка). Вот доклад одного из главных архитекторов крупной (единорог) компании, который так и изображает эту проблему в заголовке: “как из одного архитектора вырастить 100+ архитекторов”, это ровно про такую ситуацию, когда в разработке микросервиса надо определить его функцию и предложить конструкцию, и как-то это оформить так, чтобы не поплыла архитектура в её новом значении: верхнеуровневая нарезка на модули и какие-то способы их коммуникации, оптимизирующие зависимости – https://www.youtube.com/watch?v=JlXeQxAkDf0. Если выделить роль методолога, владеющего методами работы предметной области и работу проектировщиков, которые задействуют результаты методологической и архитектурной работы для разработки и реализации концепции системы – этот доклад смотрелся бы совсем по-другому, но речь идёт о докладе трёхлетней уже давности, сейчас всё могло бы быть рассказано по-другому.

Предлагаемое прикладным методологом функционально-платформенное описание методов предметной области (функциональное разложение/синтез с возможностями альтернативного выбора видов из родов) должно быть как-то сочетано проектировщиком с реальным конструктивно-платформенным представлением, то есть архитектурным в его новом значении: нарезка на конструктивы в каком-то фреймворке. Тут тоже есть парочка идей, которые можно было бы отразить в курсе в третьем его разделе.

Так, мы можем использовать для этого классический фреймворк Wim Gielingh из работы “A Theory for The Modelling of Complex and Dynamic Systems” (тут), он был использован в семействах стандартов STEP, ISO 15926 и далее BIM. Фреймворк от Gielingh важен тем, что различает generalization hierarchy (иерархия сигнатур), specification hierarchy (выбор вида из рода) и installation hierarchy – уже выбранное и инсталлированное. В частности, он вводит понятия functional unit (наш функциональный объект) и technical solution (наш конструктивный объект) и показывает “старую архитектуру” в ходе её эволюции, то есть создания и развития: каким образом происходит совместный функциональный синтез и модульный/конструктивный синтез (если смотреть снизу вверх, ну, или их декомпозиция, это если смотреть сверху вниз). Вот предложенная нотация концепции системы для определения системных уровней с учётом отношений род-вид и выбора вида:

А вот шесть иерархий, служащих предметами рассмотрения – верхний ряд это “воображаемый проект” в его общем/генерализованном виде, а нижний ряд – это с конкретными расчётными функциями и моделями конструктивов:

В случае нейросеток речь в плане конструктивов идёт, конечно, про используемые проектировщиком фреймворки – все эти PyTorch и TensorFlow. И тут тоже может быть несколько разных соображений:
– проектировщик пользуется фреймворком, который реализовал знание архитектора о методологии – то есть то, что в основе проектирования лежит явная функциональная модель. И тут есть парочка ходов: первый ход на фреймворки функциональных описаний, отмоделированные для разных оптимизаций, где в явном виде приходится учитывать теорему о бесплатных обедах – нет универсального метода, есть сотни и сотни методов оптимизации, хорошо работающих для каких-то частных случаев, и методов, которые хорошо работают для частных случаев этих частных случаев. Итоговый метод должен позволять бесшовно скомпилировать полную программу. Методолог с архитектором делают “библиотеку всего”, а проектировщик в каждый конкретный момент, зная, что там за частный случай, который случился у клиента, реализует нужную функцию в рамках предложенного архитектурного решения. Это реализовано, например, в Julia, где для такого пришлось даже подхакать компилятор – и отмоделировано на тех же оптимизациях и физическом моделировании (вот тут более-менее развёрнутое описание с разными ссылками, включая ходы на работу с концепцией системы для AI-агентов, “Стратегии/практики/стили/методы/алгоритмы эволюции” – Стратегии/практики/стили/методы/алгоритмы эволюции: ailev — LiveJournal, тот же ход, что у Gielingh: видов методов в родах методов до чёртиков, надо уметь выбирать, а затем делать эффективный синтез из выбранного).
– текущая работа Karpathy, который несколько миллионов строк PyTorch заменяет для одного частного случая на примерно 1000 строк на Си (x.com, x.com, x.com, x.com, x.com, x.com и базовая работа Horace He Making Deep Learning go Brrrr From First Principles). Это очень близко к идеям Алана Кея про “компьютерная революция ещё не началась”, я писал об этом ещё в 2007, Опять ссылки. The Computer Revolution Hasn't Happened Yet: ailev — LiveJournal, и там в конце ещё The Accretion Model of Theory Formation Дугласа Лената. Всё это про то, что если слишком переструктурировать код, то вся производительность уйдёт в вызовы модулей, работающих с крохотными функциями: чуть ли не сотня вызовов, просто чтобы добраться до какой-нибудь операции “плюс для двух чисел” в недрах какого-то PyTorch (это и было обнаружено Horace He в его работе, это и хочет преодолеть Karpathy). У архитекторов корпоративного софта это, конечно, давно известно: “если вы разделите какой-то микросервис на два микросервиса, вы прихватите связь между ними по сети и иногда и 200 миллисекунд на это, сделаете пять раз – прихватите секунду на ответ системы из ниоткуда, из вашего архитектурного старания. Не мельчите!”).

Кто виноват – это понятно, а делать-то что?
Как это всё может быть оформлено? Наши курсы – это вордовые файлы с двумя уровнями подзаголовков (делать их можно, конечно, отнюдь не только в Ворде, .docx это только формат экспорта, его принимает наш Aisystant). То есть берём оглавление, чешем затылок – и пишем.

Я, конечно, далёк от мысли, что напишу такое сам. Например, Григорий Сапунов – он же самый настоящий методолог систем AI, хотя специализировался главным образом на уровнях ANN и LLM, но рост стека вверх – это дело наживное, если понимаешь, что именно там растёт. А я буду подтаскивать методологию методологии, а также пытаться в явном виде отмоделировать его язык рассказа – псевдокод для описания функциональной структуры “с выборами” для систем AI.