Мысли по итогам недели 21 года 2026

cryptoemcee · 12.Март.2026 15:02:18

Почему я вообще решил прочитать избранные главы из книг по прикладным дисциплинам методов, которые сейчас применяю:

в данный момент я осваиваю новые для меня роли, в дополнение к прикладным ролям, в которых по отношению к железу/софту я выступал исключительно как пользователь среднего уровня компетенции: это роли архитектора экзокортекса, инженера, который его создаёт, системного администратора, инженера по безопасности;
в рамках этих ролей я выполняю множество прикладных методов, создавая их рабочие продукты. Я не понимаю толком этих методов, поэтому выполняю их, слепо подчиняясь рекомендациям LLM (которые рождаются в диалоге с ней благодаря тому, что в голову у меня загружены начальные знания по системному мышлению, в LLM загружены FPF, а ключевой задачей сейчас у меня является расчистка WIP за прошлые годы, а это колоссальный архитектурный долг по экзокортексу, без ликвидации которого бессмысленно пытаться выполнять задачи по методам инфометаболизма, коммуникации и тем более играть прикладные роли в проектах). Выполнение методов для меня выглядит как выполнение инструкций LLM;
методы я не понимаю потому, что я не знаком с прикладными дисциплинами, эти методы поддерживающими, и ограниченно знаком с инструментарием/технологиями, их поддерживающими;
поэтому я хочу ликвидировать этот пробел, познакомиться с прикладными дисциплинами прикладных методов, которые я выполняю с доступными мне технологиями, чтобы выполнять их осознанно и правильно, правильно играя роли и создавая рабочие продукты нужного качества, так как мне же во внешней роли с ними и работать.

Это похоже на методы саморазвития ученика: если ему нужно мастерство саморазвития для освоения прикладных знаний, он осваивает методы саморазвития и осознанно использует их в роли ученика для создания прикладного мастерства, которое использует далее в прикладных ролях. Сначала создаётся нужное мастерство как целевая система в роли ученика методами саморазвития в devtime, а потом оно эксплуатируется в нужной прикладной роли в runtime. Так же и с экзокортексом: сначала он создаётся в devtime в ролях архитектора, инженера, инженера по безопасности набором их методов (а эти роли могу играть только я), а потом мной же эксплуатируется в прикладных ролях и в роли системного администратора. Экзокортекс - это подсистема меня как деятеля, и создать её могу только я при помощи LLM, никто за меня это не сделает. Его можно рассматривать как часть моего тела/мозга, а поскольку конструктивно это железо/софт, а не нейронные связи, то аналогом методов саморазвития тут являются методы создания и поддержания работоспособности экзокортекса.
Если бы железа/софта не существовало в принципе, а роль экзокортекса играли бы, как в 19 веке, ручка, бумажка, книги и тексты, то методов саморазвития было бы достаточно (и то вряд ли). Поскольку мы имеем дело с подсистемой из железа/софта, нельзя обойтись без методов архитектора, инженера по оборудованию, сисадмина, инженера по безопасности, а для этого нужно знать их прикладные дисциплины. Список их названий и книг мне дала LLM. Это systems thinking, systems administration, cybersecurity, security engineering, cryptography, knowledge management, site reliability engineering.
Поскольку литература, рекомендованная по ним, огромна, её чтение целиком было бы ошибкой, которая мне уже известна по прошлому опыту, и от которой я ухожу. Она называется “избыточное потребление”, создание избыточных запасов. Поскольку в информационном метаболизме я устраняю эту ошибку и перехожу от модели just in case к модели just in time, то используется избранное чтение конкретных глав, соответствующее задачам создания конкретных инкрементов/производства точечных конкретных изменений в архитектуре/функции/конструкции моего экзокортекса.
Таким образом, прочитав эти главы и составив по ним заметки, я:

во-первых, запущу правильный информационный метаболизм;
во-вторых, я создам нужное мне прикладное знание в голове по прикладным дисциплинам своих новых методов новых ролей;
в-третьих, я буду 100% понимать, почему я внедряю инкремент Х по инструкции, написанной LLM, и почему она эту инструкцию вообще дала.
И у меня будет не сопротивление изменению (которое я сейчас ощущаю, даже понимая умом, для чего я всё это делаю, потому что нужно выполнять множество новых сложных действий, кажущихся избыточными и нагромождающими архитектуру, затрудняющими работу и вход-выход в контексты), а содействие ему как можно быстрее, так как будет понятно, зачем оно, какова его конечная цель.

Таким образом, к отобранной литературе по прикладным методам для воплощения моего экзокортекса я подхожу прагматически, ошибка избыточного потребления впрок не совершается. Избранные материалы в виде конкретных глав конкретных книг LLM отобрала и сгруппировала около контуров:

оптимизация взаимодействия человека и ИИ (ибо ИИ под моими запросами помогает мне вставать в нужные роли и выполнять их методы);
моделирование угроз (отсюда кибербезопасность для защиты моих активов от атак), криптографическая верификация (имеет место у меня в цифровой личности и криптоактивах);
систематизация знаний (создание графа знаний в Обсидиан, что я только осваиваю);
обеспечение катастрофоустойчивости (восстановление моих активов их бэкапов в случае отказа/потери узлов).
Очерёдность чтения при этом выстроена по принципу от методологии управления к технологическому воплощению и защите (каждая следующая книга опирается на понятийный аппарат предыдущей).

Оглавление и индекс каждой книги просканированы. Читаем целевую главу методом систематического медленного чтения с созданием образовательных заметок, создаём “вечнозелёную” заметку в Обсидиан и, если полученные знания требуют немедленного внедрения, инкремент в экзокортексе. Книги читаются последовательно, параллельное чтение запрещено. Для освоения книг суммарно инвестировать 100 часов, по 4 часа в день, итого это до 4-х недель.
Завершился курс Усанова “Русская матрица”. В папке заметок транспортной шины лежит заметка с тридцатью ссылками на лекции и семинары общим объёмом до 90 часов контента. При методе speed listening с составлением образовательных заметок (которые дальше тоже нужно перерабатывать и отгружать) это до 45 часов чистого прослушивания, а ещё на создание заметок накинуть треть, итого до 60 часов чистого инвестированного времени, которое можно вписать в три недели. Поскольку у меня сейчас в приоритете экзокортекс и прикладные методы, переработку материалов курса “Русская матрица” надо делать после завершения переработки литературы по прикладным дисциплинам методов экзокортекса и до нового курса Усанова в сентябре (ориентировочно июнь-июль после встречи по Институту Хайека). И хотелось бы уже внедрить все инкременты в экзокортекс до этого, хотя есть ощущение, что это будет делаться в течение года.
На 21-й неделе прочитал и составил образовательные заметки по:

главам из Jacobson;
главам из Kossiakoff;
всему Lanham (оказалось, читается быстро);
главам Anderson + весь плейлист лекций прослушан, в принципе, можно сразу читать книгу.
Evergreen заметки не составлялись, в этом ошибка.

Образовательные заметки по Jacobson, The Essentials of Modern Software Engineering:

книга не учит одному конкретному методу работы, она учит тому, как создать свой метод работы (way of working). Essensе - не метод, а способ создания методов. Это метод-агностик фреймворк, позволяющий измерять прогресс в воплощении задуманного;
методы в нём состоят из практик (some kinds of mini-methods). Идея книги - “освободить” практики из “тюрем” методов и создавать свой метод уникальной комбинацией практик. В мире больше 100 тыс. методов, но всего несколько сотен практик;
существует ядро/kernel - то общее, что разделяют между собой все методы и практики. На нём и нужен фокус. Метод - это композиция из практик на основе ядра;
метод слишком большой, чтобы быть созданным одним человеком без заимствования практик у других;
ключевыми элементами любой попытки создания системы являются альфы, которых у Якобсона семь. У А. Левенчука их восемь - восьмая альфа это работы системы. Метод - функциональное описание работы, сама работа - конструктивное. Метод задаёт роли. Если любая система - это система создания, то есть метод её работы, есть её работа, и есть её архитектура. Если это предприятие, то это way of working, work, team. Если это целевая система, то это функция/поведение как методологическая действительность (может обсуждаться, даже когда система не работает), само поведение как операционная действительность (может обсуждаться только во время работы системы), архитектура (которая обеспечивает нужное функциональное поведеине). Можно назвать way of working описанием системы, team воплощением системы, work операционной работой системы, выдаваемой в мир всегда по методу;
в любом предприятии есть три области: клиентов/надсистемы, решения/целевой системы, организации/системы создания;
в надсистеме альфы - возможности и стейкхолдеры; в целевой системе альфы - описание системы и её воплощение (А. Левенчук добавил “работы системы”); в системе создания альфы - метод, команда, работы. Поскольку любая система - это система создания, а любая система создания является целевой для её собственной системы создания, альфы системы создания и целевой системы должны совпадать, даже если они называются по-разному. Way of working/system definition, team/system realization, work/work;
возможность: нужно время, чтобы понять, действительно ли увиденная возможность отвечает реальной потребности, за решение которой готовы платить; увидеть иные решения, за которые люди уже платят; нужно терпение, так как требуется время, чтобы выгоды нового решения стали очевидны потенциальным клиентам;
стейкхолдеры/проектные роли: нужно понять, кто они и какие у них concerns; убедиться, что они представлены/вовлечены в проект; убедиться, что они удовлетворены решением. Потребности стейкхолдеров постоянно эволюционируют, поэтому решение тоже должно эволюционировать (но предложение идёт впереди спроса всегда);
описание системы/требования (что, как ожидается внешними ролями, система должна делать). Требования служат посредником между возможностью (предпринимательской, по удовлетворению реальных потребностей внешних ролей) и воплощением системы в мире. Нужно: отслеживать, что требования увязаны с возможностью; организовывать требования бесконфликтно; проверять тестируемость требований, то есть как убедиться, что решение удовлетворяет требованию недвусмысленно; использовать требования для создания системы, прогресс в котором измеряется тем, насколько система удовлетворяет существующие требования;
воплощение системы (в физическом мире). Собственно, цель проекта по её созданию. Система - ролевой/функциональный объект, который выполняет требуемое поведение/выдаёт функцию в надсистеме в режиме эксплуатации, в результате чего надсистема функционирует исправно, потребности внешних ролей удовлетворяются, то есть предпринимательская возможность реализуется на наших глазах, все довольны, деньги за систему платятся. Работа системы создания не завершена, пока целевая система не работает успешно в реальной надсистеме, в поле/в боевой обстановке, где выполняемая ею функция видна, и видна её ценность (которая становится очевидна, когда системы нет и её функции тоже). Воплощение системы в физическом мире должно исправно работать, входя в состав надсистемы (у которой может не быть принятого в культуре названия - не называть же агента с экзокортексом “киборг” по сравнению с агентом без экзокортекса, или вводить уровни киборговости);
команда системы создания: должна быть сформирована из достаточного количества агентов для начала работ; члены команды должны обладать нужным мастерством; работать в сотрудничестве для достижения целей команды - реализации возможности удовлетворить потребности стейкхолдеров; постоянно адаптироваться к изменяющимся внешним условиям;
работы: должны выполняться быстро и качественно; предполагает подготовку, коммуникацию в процессе, контроль рисков и прогресса, движение к закрытию. Focus on getting the right things done;
метод. По поводу него у команды должно быть согласие, но метод может меняться (с новым согласием всех с изменением, иначе не будет сотрудничества). Даже в малой команде есть необходимость достичь согласия в foundationals/principles, из которых следуют конкретные практики и инструменты. Метод обязан быть адаптирован к контексту команды и эволюционировать, так как меняются внешние условия. Метод должен включать фундамент в виде ключевых практик и инструментов, использоваться всеми членами команды и улучшаться, если нужно. Стандарт OMG Essense как раз способствует достижению согласия в команде по поводу метода;
альфа (элемент, нужный для отслеживания здоровья и прогресса). Наиважнейшие объекты внимания в любом проекте, неосязаемый элемент, состояние которого нужно отслеживать для понимания прогресса, и собственно, продвигать их прогресс, создавая рабочие продукты, чтобы проект был успешен. Не имея альф, нельзя оценить здоровье и прогресс проекта. Альфа имеет состояния, которые оцениваются по контрольным вопросам. Альфа - не рабочий продукт, но она описывается/понимается через рабочий продукт, который с данной альфой ассоциируется. Состояния альф определяются через инкременты; производство инкрементов и есть продвижение альф по состояниям. Нельзя перепрыгнуть от текущего состояния к желаемому - к нему можно только перейти, последовательно производя все нужные инкременты. В желании избежать этой последовательности, нудной, скучной и требующей времени, и кроется природа мифа о “волшебной таблетке”, скатерти-самобранке и прочих вещах из нашей культуры, которые якобы позволяют быстро и без усилий перескочить одним махом в состояние рая, до этого лёжа на печи и ничего не делая;
рабочий продукт. Осязаемый элемент, который создаётся исполнителем практики. Всегда соответствует какой-то альфе. Является доказательством некоторого состояния альфы (если альфа находится в некотором состоянии, то обязан быть рабочий продукт, его подтверждающий; если его нет, то заявление о том, что альфа находится в состоянии Х, ложно);
работа/activity. То, что делает исполнитель по конкретному методу, в результате чего создаётся рабочий продукт;
мастерство/компетенция. Способность/Умение/квалификация, нужные для выполнения конкретной работы. Уровень мастерства прямо влияет на качество рабочего продукта данного метода и время его создания (мастер создаёт рабочие продукты быстрее и лучше, чем его ученик; но мастерство растёт по квадрату компетенций, и тоже медленно, так что нужно учиться замечать его прогресс; плюс мастерство же в конкретном методе, поэтому важно владеть описанием метода и точно выполнять его, а для этого необходимо владеть дисциплиной и технологией/инструментарием метода; методу также надо обучиться, и метод обучения методу Х сам является отдельным методом - методикой; поэтому в проекте обучения всегда есть методолог- чему учить, какому методу Х, и методист - “как учить методу Х, каким методом У”; рабочим продуктом метода Х является его рабочий продукт; рабочим продуктом методики У является мастерство в методе Х, выражающееся в способности создавать рабочие продукты метода Х). В МИМ степени “Объяснение”, “Умение”, “Навык”, “Мастерство”. У Якобсона Assists, Applies, Masters, Adapts, Innovates;
альфа имеет состояние. Рабочий продукт описывает альфу. Альфа организует рабочие продукты. Рабочий продукт подтверждает состояние альфы. Пространство работ нацелено на продвижение альфы по состояниям. Пространство работ организует работы. Работы создают/обновляют рабочие продукты. Результатом работ является состояние альфы. Состояние альфы прогрессирует от производства работ. Пространство работ задействует мастерство. Работа требует мастерства. Есть ещё паттерн: решения для типовых проблем (пример паттерна - роль).

Образовательные заметки по Kossiakoff, Systems Engineering Principles and Practice:

cутью архитектуры является структурирование. Это может означать создание функциональной формы, создание порядка из хаоса, или превращение частично сформированных заказчиком идей в работоспособную концептуальную модель. Ключевыми техниками является балансирование потребностей, выбор интерфейсов и поиск компромиссов между экстремумами. Архитектура - это предварительный дизайн системы;
типы архитектуры: функциональная (какие функции/действия должны обязательно выполняться внутри системы, чтобы она выполняла свою миссию), физическая (какие функциональные части системы должны выполнять эти функции), аллоцированная (сопоставление функциональной и физической, дабы убедиться, что на каждую внутреннюю функцию есть свой физический компонент-подсистема). Идеальная алллокация - когда одна функция выполняется одним компонентом. Ни одна функция не должна быть забыта (иначе функция всей системы не будет выполняться), и ни один компонент не должен быть лишним, нефункциональным (это затраты ресурсов лишние). На практике компоненты многофункциональны, но это повышает риск отказа, чем больше функций на одном компоненте, тем больше риск его отказа в этой функции. Можно и наоборот: дублирование выполнения одной и той же функции множеством компонентов для надёжности. Цель аллокационной архитектуры - убедиться, что каждый компонент задействован правильно для выполнения своей функции;
роль системного архитектора заключается в поддержании связей между стейкхолдерами и инженерной командой для интерпретации видения системы стейкхолдерами и перевода этого видения в узнаваемую форму для дизайнеров, которые будут разрабатывать систему. Это требует умения видеть проблему с разных точек зрения, чтобы добросовестно выполнить первоначальное видение системы;
системная архитектура содержит три общих взгляда на систему: операционный (как система представляется с точки зрения пользователя), логический (с точки зрения менеджера или клиента), физический (как система представляется с точки зрения разработчиков и дизайнеров);
метод системной инженерии состоит из четырёх основных шагов: requirements analysis, functional definition, physical definition, design validation;
процесс разработки софта состоит по аналогии из: analysis, design (architectural, procedural etc.,), coding and unit test (implementation), test (including integration and system test);
я точно могу и должен описать требования/requirements к системе, вытекающие из моих потребностей/needs как деятеля, чтобы провести функциональный анализ (соответствие функции, выполняемой системой, требованиям - traceability to requirements). Я же тут внешняя роль (заказчик экзокортекса) и внутреняя роль (инженер);
мои потребности/needs как деятеля группируются около: защиты веб2 и веб3 активов (ADMIN); управления когнитивным и временным ресурсом (SYS) - нужно входить в чёткий контекст и удерживаться в нём, минимизируя автоматические переключения; информационного метаболизма и производства контента (ACQ, SYN, PROD); коммуникации (COMM); выполнения прикладных методов в ролях в рабочих проектах (STBY); управления архитектурой и оргразвитием (META);
далее идут requirements к экзокортексу как системе, functional definition (какие функции в нём должны выполняться для выполнения миссии), physical definition (какими элементами конструкции они должны выполняться), design;
хорошо, что есть предшественник - baseline железо+софт, и не надо изобретать иной концепт;
инженерия софта выделяется отдельно от системной инженерии, тем не менее, они в конвергенции. Системная инженерия должна включать software engineering как дисциплину отдельную. Абстрактная природа софта (его нельзя пощупать, хотя физически он воплощён) отличает его от других систем;
софт определяется как состоящий из трёх компонентов: инструкции (код - разный синтаксис и языки), данные (хранятся и изменяются инструкциями-кодом), документация (описывает работу и использование софта);
софт может быть категоризирован на: системный (предоставляет сервис другому софту - операционные системы), встроенный (предоставляет сервисы/функции внутри больших систем - софт как классическая подсистема), приложения (предоставляют сервисы самостоятельно), которые взаимодействуют с первыми двумя типами софта. Можно выделить четыре дополнительных категории: engineering/scientific, product-line, web-based, AI;
системы, которые используют софт, делятся на: системы с встроенным софтом (используется для контроля поведения железных компонентов), компьютеры и сети, полностью управляемые софтом, обеспечивающим весь функционал системы (тут критически важны человеко-машинные интерфейсы - интернет есть пример такой системы); системы для обработки данных (большого масштаба для решения сложных вычислительных задач);
главные отличия софта от железа для инженера: состоит не из физических частей, а из модулей и объектов; интерфейсы менее видимы, часто в глубине, многочисленны, так как границ физически не видно; неограниченная функциональность и объём; изменение относительно легко, но рисково; выходит из строя внезапно; состоит не из атомов, а из битов;
методы разработки софта по видам жизненного цикла: линейный (waterfall), инкрементальный, эволюционный (spiral), agile (полагается на вовлечение пользователей/клиентов);
типы безопасности: анализ критических функций; анализ критических интерфейсов; доступ к системе; физическая безопасность системы; безопасность данных; операционная безопасность (чтобы снаружи не узнали об уязвимостях системы);
The NIST Cybersecurity Framework: определить критические узлы в системе (identify), требующие защиты (все активы организации/агента); защитить их доступными методами и технологиями (protect); мониторить и вовремя обнаруживать действия злоумышленников (detect); если система атакована, оборонять её (respond); если система повреждена в результате атаки, восстановить её до приемлемого состояния, в котором она продолжает выполнять критически важные функции (recover). Всё это вместе - govern;
Govern включает: контекст организации, стратегия риск-менеджмента, роли и ответственность с полномочиями, политика, oversight, риск-менеджмент цепочки поставок. Identify включает: управление активами, оценку рисков и улучшение. Protect включает: identity management, authentication, access control, awareness and training, data security, platform security - hardware, software, services, resilience of technology infrastructure. Detect включает: постоянный мониторинг, анализ аномалий и индикаторов событий-атак. Respond включает: incident management, analysis, mitigation, communication, reporting. Recover включает: выполнение плана восстановления, коммуникация в ходе восстановления.

Образовательные заметки по Lanham, AI Agents in Action:

агент и LLM - это разное. Агент и ассистент - синонимы. Автономные агенты принимают решения сами и этим сильно отличаются от неавтономных;
четыре типа взаимодействия агента-человека с LLM: напрямую, нет агента-ассистента, прямой вопрос-ответ с LLM; агент-ассистент прокси, ставит задачу LLM по факту принятой задачи от человека (например, по генерации картинки); агент-ассистент выполняет действия от имени человека с получением его согласия на характер действия; автономный агент, принимающий решения от имени человека и действующий для их выполнения, для чего составляет план (и тут возникают вопросы этики и безопасности). Во всех случаях интеракция человека - с LLM. Моя роль в будущем должна быть именно “постановщик задач для автономного агента”, а не просто пользователь чат-бота. Важно: агент-человек, агент/ассистент-ИИ, LLM - три разные сущности тут. Прокси-агент, агент-ассистент и автономный агент - три случая наличия агентов;
для сложных задач вводятся профили/персоны агентов. Каждый профиль/персона под специфическую задачу с набором инструментов и знаний (роль в СМ, с чётким прикладным методом, дисциплиной и инструментариями). Мультиагентная система - набор профилей агентов, или набор ролей/команда в СМ, которые вместе выполняют задачу. Тут всё предельно понятно. Таких конфигураций агентов может быть бесконечное множество. Мультиагентные системы могут работать автономно или с обратной связью от человека;
пять основных компонентов простого агента: профиль/персона, действия и инструменты (метод), объяснение/reasoning и оценка, память и знания (расширяют контекст агента для решения специфической задачи), планирование и обратная связь (позволяют агенту обучаться и улучшать выполнение задачи);
персона и профиль: персона - полный аналог роли и демографии, пол, возраст, бэкграунд; профиль шире и описывает агента как систему; их можно создавать руками, а можно лучше с помощью LLM или данных;
действия и инструменты: цели (выполнение задачи, исследование, коммуникация), пространство и влияние (как действия влияют на завершение задачи, окружение агента, внутренние состояния и его знания), методы генерации (ручной, вызов из памяти, следование плану - усиливают наши возможности влиять на поведение агента и его обучение). Любое действие влияет на поведение агента и его обучение, у действия есть последствия;
память и знания: структурное разнообразие (объединённый подход и гибридный, дающие гибкость в хранении информации), источники данных для памяти (документы, базы данных, эмбеддинги), семантическое подобие (извлечение информации). Агенты используют их для оптимизации контекста и минимизирования использования токенов;
рассуждения/объяснения и оценка: цепочка/дерево рассуждений, базис для саморефлексии в процессе выполнения задачи;
планирование и обратная связь: планирование без обратной связи (принимают решения независимо, автономные агенты), планирование и изменение планов с обратной связью от окружающей среды и человека, а также других агентов;
автономные агенты требуют доверия, которое невозможно без понимания, как они работают. По этой причине, многие ИИ-решения не автономны. Степень автономности можно регулировать, тут на свой страх и риск: от полностью неавтономных до полностью автономных, как работники, которым мы доверяем;
ИИ-агенты - это сдвиг парадигмы того, как мы работаем с LLM. Собственно, с LLM можно работать напрямую (первый случай из четырёх), а можно через ИИ-агента с разной степенью автономности. Это также меняет подход к тому, как пишется код и хранятся данные. Интерфейсы в этих делах становятся на натуральном языке, на котором мы взаимодействуем с ИИ-агентом, а он уже на нужных языках взаимодействует с приложениями, другими агентами, базами данных. Если раньше нам надо было изучать эти языки и взаимодействовать с каждым компонентом через свой интерфейс, то теперь задача человека сводится к взаимодействию с ИИ-агентом на обычном языке. Это сдвиг того, как мы подходим ко всему, от поиска информации до разработки ПО и доступа к данным. Агенты меняют парадигму взаимодействия человека с ПО и данными, меняют интерфейсы, делая их на натуральном языке. Если ранее человеку нужно было взаимодействовать с ПО и базами данных на специальных языках через специальные интерфейсы (и всё это надо было изучать), то теперь он будет взаимодействовать с ИИ-агентом на натуральном языке, ставя ему задачи, а он уже (с разной степенью автономности) будет взаимодействовать с ПО и базами данных на их языках;
нужно различать одиночных агентов, мультиагентные системы и автономных агентов;
говоря про LLM, надо выделять: данные, на которых модель тренируют (чудовищное количество данных определённого типа - текст, картинки, видео); архитектура (генеративная/предсказательная, контекст, лимит токенов, число параметров или размер модели); для каких конкретно задач/юзкейсов тренируется модель и метод тренировки; fine-tuning (точная настройка, улучшение данных или тренировки для повышения качества результата - reinforced learning with human feedback);
есть разные стратегии промпт-инжиниринга (набор техник, позволяющих создавать более эффективные промпты для улучшения ответов LLM). Промпт - это содержание сообщения, используемое в запросе для получения лучшего результата в ответе. Типы стратегий: писать чёткую инструкцию; использовать ссылки на тексты; использовать внешние инструменты; дробить сложные задачи на более простые подзадачи; давать модели время на обдумывание; систематическое тестирование изменений;
написание чёткой инструкции означает быть конкретным и осторожным относительно того, что спрашивается. Просьба выполнить задачу для LLM ничем в этом смысле не отличается от такой же просьбы в адрес человека. В общем случае, чем больше информации и релевантного задаче контекста вы можете дать/определить/конкретизировать в запросе, тем лучше ответ. Возможные тактики стратегии написания чётких инструкций: детальный запрос; назначение роли, из которой отвечать; использование разграничителей; конкретизирование шагов; предоставление примеров ответов; ограничение длины ответа;
выбор оптимальной LLM для ваших конкретных потребностей (для разворачивания агентов или сети из них): пригодность/поведение модели в данном наборе задач; размер модели (количество параметров); тип модели (для каких юзкейсов она предназначена); тип контента, на котором тренировали модель; метод обучения и точной настройки модели; размер окна контекста в токенах (памяти); скорость ответов модели; стоимость использования модели (определяет выбор между запустить свою или использовать коммерческую);
GPT - generative pretrained transformers. Модели на основе генеративных отличаются от предиктивных/классифицирующих. LLM - это набор данных, архитектуры и обучения для использования в конкретных юзкейсах (точная настройка). Опенсорсные LLM являются альтернативой коммерческим и могут хоститься локально (что требует набора навыков). LLM могут использоваться для создания/питания агентов и ассистентов, от простых чатботов до полностью способных автономных работников;
если у человека есть глубокие знания в некоторой области/теме, хорошей идеей может быть создать на их основе ИИ-ассистента публичного, с помощью которого другие люди могут самостоятельно обучиться в этой области знаний. Это SoTA-метод маркетинга;
создание функционального ИИ-ассистента требует итераций в дизайне промптов, определение чёткой персоны, установления правил, и удостоверения, что то, что выдаёт ассистент на выходе, соответствует ожиданиям пользователя;
прокси-агент в мультиагентной конструкции - это агент, с которым коммуницирует человек, и который коммуницирует с остальными агентами. С агентами пользователь может выбирать, взаимодействовать ли с сервисом через его веб-сайт, чат с ИИ или через агента;
действия и инструменты - это строительные блоки, которые усиливают агентов и ассистентов. Без доступа к инструментам агенты остаются бесфункциональными чатботами. Они могут быть семантическими (на основе промпта) и нативными (на основе кода);
память и знания используются LLM для добавления релевантного контекста и дополнительной информации к промпту. Промпты могут быть дополнены чем угодно, от информации о документе до предыдущих задач и диалогов и другой относящейся к делу информации. Знание не рассматривается как память (это разные сущности), а скорее как дополнение к промпту из существующих документов. Обращение к знанию и памяти осуществляется следующими тактиками промпт-инжиниринга: использование внешних инструментов, предложение ссылок на тексты;
механизм извлечения информации, известный как RAG (retrieval augmented generation), стал стандартом получения дополнительного контекста для промпта, усиления промпта контекстом из внешних документов, из которого векторизацией/эмбеддингами извлекается релевантный контент. Механизм, поддерживающий RAG и память/знания, один и тот же;
прежде чем может быть сформирован запрос в отношении документа, он должен быть загружен, превращён в chunks, встроен в векторы и сохранён в векторной базе данных. Таким образом документ как бы индексируется LLM, после чего в отношении него можно генерировать запрос юзером. Запрос тоже проходит стадию эмбеддинга и помещается в векторную базу, где используется для поиска в ней того, что дополняет контекст (вот тут появляется augmented). Такой же механизм используется при обращении к памяти;
семантическое представление - это локальное (в словах), распределённое - в эмбеддингах и векторной базе. Суть нейросети в том, что она хранит знания в распределённом представлении и превращает в локальное, и обратно. Две нейросети, человеческая и машинная, могут между собой общаться только так, а не иначе (нельзя общаться в распределённом представлении, там нет семиотизации, языка, семантики и синтаксиса);
сначала векторизация документа, затем хранение его в векторной базе данных. Эмбеддинг - это метод векторизации, который лучше сохраняет семантическое значение документа. Огромная размерность вектора и обеспечивает то, что он ухватывает эту семантическую связь. Векторизация/эмбеддинги - и есть механика превращения локального семантического представления в распределённое в нейросети. Близость векторов означает семантическое подобие. Когда документ прошёл стадию эмбеддинга, это превращает текст в вектор большой размерности. Таким образом, текст может быть векторизован в эмбеддинги и помещён в векторную базу данных. Эмбеддинг превращает кусочки текста (чанки) в векторы. То есть векторизации предшествует дробление. Вот тут аналог создания заметок при чтении - читая текст, мы дробим его, превращая в заметки. Но только при таком подходе можно писать заметку по каждому предложению - мы же этого не делаем (но если бы делали, то эффективность процесса извлечения знаний из текста и помещения их в свою нейросеть была бы выше);
RAG похож на индексацию документа и позволяет раздробить его на части, чтобы обращаться затем к релевантной запросу части документа, а не ко всему целиком, что снижает время выполнения запроса;
токенизация - это процесс разборки текста на токены. Термин “токен” означает элемент текста, который может быть от целого слова до отдельного символа, это зависит от контекста. Токенизация документа позволяет избавиться от нерелевантных элементов (лишних пробелов, например);
память в контексте ИИ часто описывается в тех же терминах, как и когнитивная память человека. Вторым важным компонентом памяти ИИ является компьютерная память. Память ИИ делится на сенсорную, краткосрочную и долгосрочную. Сенсорная удерживает текст или картинки для быстрого ответа (примерно так, как мы помним, что делали полминуты назад - визуальная, аудиальная, осязательная). Краткосрочная память работает на удержание контекста текущего обсуждения, как и мы удерживаем в памяти, о чём были недавние или текущие диалоги (входы, контекст) для немедленного анализа и генераци ответа (conversational memory, RAG). Объём этой памяти ограничен, так как срок действия/актуальность таких диалогов ограничена. Долгосрочная память удерживает важные факты для всего жизненного цикла агента, как и для человека (как мы помним важные факты от рождения и много лет назад, на которые опираемся в ежедневном самоощущении). Делится на эксплицитную/осознанность и имплицитную/процедурную/подсознательную (сюда для агентов входят действия и инструменты). Эксплицитная делится на эпизодическую (события в жизни) и семантическую (факты, концепты);
существует сжатие/компрессия памяти и знания у ИИ, механизм которой работает похоже на то, как наша память помнит существенное, сжимая и опуская неважные несущественные детали, помнить которые нет необходимости, качество ответов от их забывания не страдает. В ИИ для сжатия используется кластеризация сходной информации;
слово system в начале диалога устанавливает системный промпт (например, ставит в роль; после слова пробел в одну строку);
профиль агента - это набор промптов/сообщений, которые так или иначе характеризуют/описывают агента: персона даёт агенту атрибуты, правила и личность; действия и инструменты устанавливаются в промпте; память и знания есть промпты, используемые для экстракции знаний; оценка и аргументация добавляются в промпты; планирование и обратная связь. Профиль агента состоит из ряда промптов-компонентов, которые могут вызывать соответствующие функции как: действия/инструменты, память/знания, оценку/аргументацию, планирование/обратную связь. Для оценки качества промптов-компонентов используется метод промпт-флоу. Системный промпт-инжиниринг есть итеративный процесс оценки промпта и профиля агента. Профиль агента и промпт-инжиниринг во многом похожи. Автор определяет профиль агента как комбинацию элементов промпт-инжиниринга, которые направляют и помогают агенту в его задаче;
chat completion - дословно “завершение чата, завершение запроса”. Смысл - завершить запрос ответом, получить ясность. Ответ - это же завершение запроса. LLM наподобие Chat GPT были натренированы именно на эту задачу. Они не были тренированы на аргументацию, планирование или размышление;
direct solution prompting - основной метод использования промптов, направляющих LLM к решению конкретных задач, подчёркивающий значимость прямых вопросов и ответов. Few-shot prompting - снабжение LLM несколькими примерами, могущими содержать новый или невидимый сразу контент, задействующий возможность модели приспосабливаться к незнакомым паттернам. Zero-shot prompting - демонстрирует, как LLM может решать задачи на основе натренированного, без внешних примеров, подчёркивая их способность применять существующие знания в новом контексте. Chain of thought prompting - проводит LLM через пошаговый процесс рассуждения, иллюстрирующий то, как добиться от модели детальной аргументации. Prompt chaining - разбирает проблему на серию промптов, надстроенных один над другим, показывающий, как структурировать сложные процессы решения проблем в управляемые шаги для LLM. Self-consistency - техника, которая генерирует несколько решений проблемы и позволяет выбрать наиболее последовательный ответ через процесс оценки, подчёркивающий важность последовательности для получения надёжных результатов. Tree of thoughts prompting - комбинирует самооценку и prompt chaining для создания всесторонней стратегии решения комплексных задач, позволяющая систематически исследовать множество путей поиска решений;
агенты и ассистенты, которые не умеют планировать и могут выполнять лишь простые инструкции, не более чем просто чатботы.

Опять есть ощущение накопления WIP. Если я продолжу дальше читать книги по плану, то мои образовательные заметки по ранее прочитанным книгам “протухнут”, я просто не вспомню, почему я их составил. Их нельзя накапливать.
Пришло понимание, что я всегда пытался ускорить процесс, выполняя его неправильно, с несоблюдением метода/без метода/упрощением метода, не столь важно, то есть накапливая технический долг. Вместо того, чтобы методично делать правильно, перерабатывая wip в готовую продукцию, я оставляю wip недопереработанным и нагромождаю на него новый, что даёт иллюзию скорости, но wip растёт и качественных готовых продуктов не появляется (заметок в графе, инкрементов в экзокортексе, изменения спецификаций методов). И эта ситуация у меня 20 лет продолжается, а список прочитанной литературы (количество книг) является метрикой тщеславия. И вот сейчас я, зная, что толком не разобрался, как работает у меня контур инфометаболизма (имея четыре заметки и две картинки в папке ai logs транспортной шины), то есть не понимая толком методы в контекстах acq, syn, prod, я пытаюсь использовать это недостаточное понимание (что равносильно отсуствию квалификации или плохо работающему оборудованию) для производства рабочих продуктов методов метаболизма, пытаясь освоить корпус литературы по прикладным методам экзокортекса. То есть “не понимая метод работы, пытаться работать” - результатом будет накопление брака, wip, проделанная зря работа. Мне надо отгрузить накопившиеся заметки/логи, чего я избегаю (так как это надо напрягаться и заставить себя разобраться, а мозг не хочет), разобраться в контуре инфометаболизма, понять методы и рабочие продукты, и с этим пониманием уже работать по переработке литературы. Остановил чтение Андерсона, решил попробовать разгрузить таки заметки по инфометаболизму до конца недели, чтобы избавиться от wip и подготовить почву для завершения производства по прочитанным книгам Якобсона, Ланхама, Косякова. Точно так же я раньше остановил освоение руководств МИМ, так как понял, какой wip плодится этим на уже созданном в предыдущие годы.
Запланировать на 22-й неделе миграцию публикаций (только тексты, файлы презентаций не нужно) из архива в Обсидиан в статусе read-only для достижения состояния, чтобы любой мой прошлый текст был доступен быстро в Обсидиан, чтобы можно было ссылаться в текущих документах на прошлые тексты, чтобы экзокортекс охватывал в едином месте всю историю моего интеллектуального производства, которая в нём уже и так зафиксирована, но сейчас разрозненна. После миграции из архива в Дропбоксе их убрать для соблюдения принципа отсутствия дублирования информации в экзокортексе. Перенёс файлы предварительно в Обсидиан, уточнил YAML frontmatter, исправил ошибку папки COMM на PROD (в которой сразу и лежали в архиве). Убрал в наименованиях папок экзокортекса ссылки на другие “облака”.
Разорвал связь Zoom c SSO Google, сделал нормальный пароль и двухфакторку (отметил качественный скачок в понимании её смысла: она стала естественным и понятным шагом, который интуитивно ищешь уже, сталкиваясь со веб2 аккаунтом: “Так, а где тут второй фактор? ага, ТОТР, понятно, не sota”, отсутствие второго фактора выглядит странно), сохранил бэкграунды в приложении, сделал резервную копию в Гугл диске (как раз хватит до конца года; потом приложение будет удалено, и файлы снова понадобятся - кстати, обрезать их не нужно, зум сам прекрасно обрезает под размеры фона). Пришло уведомление об удалении аккаунта на Патреон. На неделе вспомнил про аккаунт Chat GPT и удалил его со всей историей чатов, как ранее и Canva. На аккаунте Гугла больше нет third party apps. Сделал тейкаут двух аккаунтов Гугл, основного и бренд, на котором Ютуб-канал.
Разобрался со всеми веб3-адресами, которые ранее выпали из обзора (парадоксально, но - в погоне за мелким крупного будто не замечаешь, хотя оно перед глазами лежит). Теперь информация по всем криптоактивам восстановлена и размещена в правильных местах с разграничением ролей и доступов (где нужен только просмотр - там только просмотр без доступа к приватным ключам; ведь это же логично с точки зрения кибербезопасности - заходить в кошелёк для просмотра своих балансов неверно; балансы надо смотреть через эксплореры, тогда непонятно со стороны, чьи балансы ты смотришь, свои или вообще; в кошелёк же надо заходить только в контексте выполнения финансовых операций в контуре fin-ops-admin и только для выполнения транзакций; поэтому кошельки не должны стоять на смартфоне, облегчая вхождение в этот контекст кликаньем на приложение, как вход в мессенджер; доступ в них должен быть исключительно аппаратным и когнитивно затратным, тогда ты будешь заходить в кошелёк осознанно только в контексте fin-ops в роли казначея). Тем более что эксплорер показывает активы 100% точно, кошелёк же может не показывать мелкие активы, NFT, так как сам тянет о них информацию из внешних сервисов; то есть кошелёк более худший инструмент для просмотра активов, нежели эксплорер).
Провёл инвентаризацию всех своих блокчейн-доменов (их оказался десяток), завёл на них ссылки в профиле браузера для удобства быстрого просмотра (могут использоваться в будущем как платёжные шлюзы, личные веб-страницы или почтовые ящики; пока являются цифровым имуществом с нулевой стоимостью обслуживания). Создал карточки с паролями на заведённые аккаунты в etherscan, polygonscan, arbiscan. Уже полсотни записей в менеджере паролей. Некоторые записи нужно перенести из категории login в другую, чтобы не путаться. Но тогда теряется иконка сайта, что неудобно.
Почистил менеджер паролей, перенёс заметку по удалению веб2 аккаунтов из него в Обсидиан. Надо привыкать, что это единый источник истины. Документы с описанием рефакторинга экзокортекса неверно хранились в папке SYS, переложил их в папку META, поскольку они касаются инструментов, поддерживающих мои текущие методы (которые развиваются), а не эксплуатации готового инструментария.
Желание перескочить на иную работу, выполняемую тем более с нарушением метода (в моём случае это чтение без заметок и под PROD) вызвано саботажем мозга и попыткой избавиться от скучной работы с медленным дофамином - именно “быстрый дофамин” тут драйвер. Ведь мозг не перескакивает со сложной скучной работы, требующей напряжения, на другую, такую же скучную сложную работу - нет, он перескакивает именно на ту, которая кажется легче и веселее, или где дофамин быстрее, или когнитивная стоимость входа ниже (легкость получения дофамина и частота повторения).
При коннекте криптокошелька с сайтом через кнопку Connect Wallet происходит передача идентификатора блокчейна и информации о конкретных адресах из кошелька децентрализованному приложению. В целях безопасности необходимо различать два фундаментальных действия - передачу информации о конкретных адресах в конкретном блокчейне приложению, и подписание транзакции (коннект не может сопровождаться подписанием). Нужно внимательно отслеживать, не подменяется ли коннект выдачей аппрува на распоряжение токенами (у меня так было, транзакции аппрува видны в эксплорере, аппрувы отзываемы) или подписанием транзакции на отправку активов. Векторы атаки строятся как раз на этом:

сайт подменяет запрос на подключение запросом на подписание. Защита - использование кошельков с синтаксическим анализом транзакций, отказ от “слепого подписания”;
сайт связывает адрес кошелька с ip-адресом, куки и фингерпринтом браузера (деанонимизация). Защита - использование VPN, изоляция профилей браузера;
атаки нa фронтенд (подмена адресов получателей прямо в момент подписания). Защита - верификация параметров транзакции исключительно на экране аппаратного кошелька;
модификация интерфейса так, что кнопка Connect Wallet физически вызывает подписание транзакции с отправкой всех активов злоумышленнику. Защита - контроль типа запроса в окне кошелька: он не должен требовать газа или подписи транзакции.
В моей архитектуре экзокортекса запрещено использование кошельков типа браузерных расширений и приложений на смартфоне.

На один день биологический организм внезапно выключился с температурой выше 38-ми, которая была сбита и на следующий день исчезла. С чем это было связано, непонятно, но сразу вспомнилось, что у меня есть контекст для включения отдыха, но он не относится к внезапному отказу биологического субстрата. Видно, это было вызвано какими-то причинами, или организму потребовался внезапный отдых (хотя отдыхаю достаточно). Пока фиксирую как факт. Зато вес оказался на отметке 70 кг, как и была поставлена цель.
Таким образом, накопленный технический долг и wip по методам информационного метаболизма выявлен и оказался критичен для продолжения работ по рефакторингу экзокортекса. Поэтому на 22-й неделе года буду заниматься его закрытием, а именно:

миграция текстов прошлых публикаций из архива в граф;
переработка заметок по инфометаболизму с окончательным разбирательством, как работают мои методы в контекстах ACQ, SYN, PROD с учётом двух систем мозга DMN/TPN, двух тактов синтеза и аналогии с обучением LLM при использовании LLM в качестве со-процессора в ходе инфометаболизма (две спецификации, две картинки, четыре файла логов чатов с ИИ);
переработка образовательных заметок по прочитанным трём книгам в evergreen/граф знаний/инкременты экзокортекса.