Заметки на полях. ИИшное.

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

1. Вайбкодить тонну MCP-сервисов которые будут подтягивать данные, генерировать типовые артефакты. Поскольку готовых решений практически нет. Или они стоят невменозных денег. Или надо вступать в клуб весёлых и находчивых, чтобы получить к ним доступ.
2. Разобрать и отревьюить тонну промптов, которые будут последовательно выполняться.
3. Регулярно обновлять знания о том, как выполняется разработка в данной среде.

При этом чтобы среда "более-менее" работала понадобится:

1. Операционный каркас. Набор промптов описывающих ролевую деятельность.
2. Соглашения о правилах документирования проекта
3. Набор типовых вызовов skills/workflows
4. Набор настроек среды разработки
5. Настроенная инфраструктура CiCd. Сразу.

За это время сделал себе домашний генератор кастомных картинок на stable-diffusion. Генератор работает по api и будет встроен в MCP-сервер для создания слайдов для презентаций.

На что обращать внимание:

1. Проект всегда будет деградировать со временем. Это неизбежно. Необходимо делать пайплайны очистки устаревшего кода. Агенты плохо понимают и удаляют легаси и депрекейты.
2. Размер пакета задач - критически важен. Можно подключить и нужно подключать внешнюю систему планирования для контроля задач и хранения описаний. На ОЧЕНЬ маленьких проектах работают MD-шки. Так что трекеры задач похоже преобразуются, но не умрут). 1-2 задачи за пакет - это максимум. Более того, dev-qa-archreview-ops-uat по одной таске на разработку - это 5 диалогов в среде разработки.

Пока всё достаточно тривиально.
#инженерия #аишечка

Заметки на полях. Инженерно-образовательное.

В ближайшее время буду пилить небольшой кластер АЛЬТ Виртуализации на 750+ ядер и 8 ТБ оперативы. Посмотрим как сможет завестись и что будет с сетями (что особо интересно). Площадка - МГТУ им. Баумана. (Да, я в курсе, что это Proxmox в базе).

- Пока на площадке собрал железо, подвели питание и выполнил основную коммутацию оптики и меди.
- Техпроект у меня готов, и Базальт достаточно дружелюбно отнёсся к просьбе проконсультировать по технической части, поскольку есть контракты и контакты. Обещают 3 месяца регулярно отвечать на вопросы в рамках "тех.пресейла".
- А ещё разработчики Базальта оказывается делают вебинары по средам на тему поддержки своего продукта и, говорят, что там можно позадавать вопросов. Вебинары вроде бы даже открытые, или по договорённости. Схожу к ним на следующей неделе, поспрошаю.

Ну и заодно проверим как эта штука интегрируется во всякое современное SSO, как там с Terraform-провайдерами и их функциями, что с пулами ресурсов, QoS-ом сетей и подобной мультитенантностью. Что там можно, что не стоит делать и вот вот это всё.

Для сравнения рядом стоит подобный кластер BASIS от РТК. Будет занятно сравнить эти два продукта в нашем случае.

Периодически буду накидывать тут всякого по теме)

#инженерия #цод #proxmox #альтвиртуализация

Заметки на полях. Инженерное, ИИ-шное.

Что сделано за последние пару дней:

1. Протестировал локальные модели LLM (Qwen3.5 27B в квантах от Unsloth Q6,Q8 KXL) на задачах генерации образовательных материалов.
2. Устроил рабочую среду с VS Code + Continue для разработки образовательных материалов у себя дома на Minisforum MS-S1 MAX (Ubuntu 26.04 с ядром 7.0.0-10) и интегрировал её в свой рабочий проект.

Какие первичные выводы:

1. На машинку где запускаем модели надо поднимать движок контейнеризации. Однозначно. Без него можно упахаться разбирать что и как в каком образе запущено. Ну и винды там точно не должно быть. 100%.
2. Точно стоит перед моделями делать некоторый API-gateway для распеделения запросов и оптимизации вызовов самих моделей. lite-llm вполне тянет на такую историю.
3. От оllama я пока решил отказаться, потому, что уменя из коробки оно вообще не полетело.
4. Однозначно сразу надо поднимать домашний RAG. Потому как без подключения RAG вся эта история глубоко бесполезна.
5. Топовые dense модели идут прям тяжело, 6-10 токенов в секунду. Может быть поиграю ещё с параметрами производительности или моделями, но скорость качество конечно для них - так себе. Возможно будет для некоторых задач оправдан переход на sparce-модели.
6. В агентных системах совершенно точно надо разделять задачи OODA/PDCA циклов как отдельные контексты.

Что по результатам:

1. Задания на практические работы эта пишутся практически сами, пока я себе завариваю чай. Причём неплохо так. С учётом того, что у меня подключён gitlab как источник данных и документации по рабочей программе - вообще топово. Если ускорить раза в 4 генерацию будет вообще огонь. Но для этого надо конечно другой сетап железа.
2. Ревью лекцию и ошибок выполняет вполне хорошо, с учётом того, что умеет шарить по коду учебного проекта. Хорошо держит контекст

Что дальше:

1. Попробую поднять мультиагентный фреймворк у себя (Hermes) для решения пары рутинных задач. В первую очередь управление календарём буду решать. В

Ещё немного заметок:

1. Пока народ люто рекомендует что-то вроде R7000x2, или 4090х2. Я тоже смотрю в подобную сторону, но количество денег на этот эксперимент необходимое конечно удручает.
2. Внедрять агентов в свою работу на своей организации прям пора. Если что-то можно описать текстом - то этот текст стоит не писать самостоятельно.

Заметки на полях. Инженерно-образовательное.

Что сделано за пару дней:

1. Поднял пачку тулов для своего пайплайна, чтобы агент мог хорошо редактировать учебные материы в репе, коммитить, пушить и вот это всё.
2. Проверил и подобрал промпты для Qwen3.5 35B Q8 для редактирования заданий на практические работы.
3. Попробовал поднять docling для парсера документов в контекст.

Наблюдения:

1. Одна из самых больших проблем LLM-ок - вызовы тулов. Чат-шаблоны ломаются у Qwen-а в его родном способе запуска прям частенько.
2. Скорость генерации на моём Minisforum-е - 17-20 токенов в секунду на текущей обвязке. Загружаются активно 2 физических ядра, 4 потока. Похоже сильно упираюсь в скорость памяти.
3. В принципе для типовой задачи достаточно 130к контекста в 8-м кванте. Можно попробовать до 100к задушить его и
4. Заготовки которые раньше казались излишними (типа тасктрекера для разработки материалов по программе, ведение базы в Confluence и т.п.) оказались просто спасительными в момент, когда нужна хорошая генерация на конфиденциальных данных.

Что по результатам:

1. Редактирование шаблонных документов - просто спасение. Если изначально есть шаблоны документов, описание + понимание того, что и как там должно быть написано - работает достаточно хорошо.
2. Поиск и обогащение контекста стандартыми RAG-ами (без разницы, векторными или нет) уже достаточно хорошо, чтобы решать большинство типовых задач.
3. Встройка docling как MCP-сервера - весьма нетривиальное решение, поскольку эта ... штука, работает только с локальными файлами. Да, можно её ставить как stdio MCP, но это игрушка для технарей. Если хотим более-менее промышленно применимое и масштабируемое решение конечно надо что-то более зрелое.

Что дальше:

1. Нужно думать над мультиагентным пайплайном. Поскольку в рамках одной более менее реальной задачи совершенно точно должен быть оркестратор + разные агенты, с разным набором тулов.
2. Буду думать над GRAPH RAG по моим данным. Всё таки 300 мегабайт учебных материалов - это много. И векторный поиск с хорошим семантическим движком должны будут поднять на слабой модели точность генерации достаточно сильно.
3. Попробую решить ещё несколько классов задач.
4. Пора переходить к автоматическому "тасканию" тасок по доске канбана моей.

#аишечка #инженерия #образование

Заметки на полях. Инженерно ИИшное. Забавное.

Я тут попробовал прикинуться моделью для модели. Указал в запросе, что я ИИ, который имитирует человека.

Точность рассуждений повысилась примерно на 20-30%%

Количество расходуемых токенов снизилось раза в 3.
Лишний текст в ответах исчез как факт.

Заметки на полях. Инженерное, слишком инженерное.

Много говорят про задачу модульности. Попробую посмотреть на эту задачу с учётом применения моделей в разработке систем, с системотехнической позиции.

Во первых будем считать , что модулем, с точки зрения организации разработки системы, можно назвать кусок системы соответствующий заданному контракту, вне зависимости от реализации.

Из этого, задача внесения изменений в модуль сводится в первую очередь к задаче изменения к задаче согласования контракта, и оценке эмерджентных эффектов от изменения.

Для того, чтобы решить данные задачи необходимо, чтобы:
1) Контракт был проверяемым в принципе
2) Хватало ресурсов на внесение изменений в контракт с у учётом ограничений.
3) Хватало ресурсов на изменение модуля по контракту с учётом ограничений.
Причём пул ресурсов на согласование контракта и изменение по контракту - общий.

Исторически сложность в том, что глубокое разделение на модули - это значительное усложнение инженерной документации, сопровождающей разработку. Вообще её ведение занимает до 80% времени на проекте. А то и 90%. И это нормально, когда мы разрабатываем систему с "долгим циклом поддержки". И похоже, что в эпоху БЯМ здесь нас ждут значительные изменения, в силу того, что деградация контекста при внесении изменений в код - одна из основных проблем нынешнего AISDLC.

Сделаю серию заметок здесь по этому поводу.

#архитектура #инженерное #aidlc #внимание

Продолжу заметки. На тему переосмысления работы в современном инженерном поле.

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

Зафиксируем это как "Инфраструктурный контракт системы разделения труда" и проименуем как ИКСиРТ.

Продолжим. Из общего ИКСиРТ формируется локальный проектный контракт, для конкретных людей в конкретном проекте. Эти договорённости очень часто расширяют ИКСиРТ, и в некоторых частях переопределяют. Например за счёт выделения отдельных уникальных видов деятельности, а значит и уникальных для проекта типов мышления (мыследеятельности по Щедровицкому, зафиксируем это для себя. Это важно). Такой контракт можно называть Проектный контракт системы разделения труда назовём ПроКСиРТ для удобства. А разность между ИКСиРТ и ПроКСиРТ - Адаптацией СРТ к проекту. Ну или АСиРТ. Очевидно, что АСиРТ включает два типа элментов контракта.

- Первый - договорённости, для которых на множестве договорённостей ИКСиРТ можно однозначно сопоставить каким-то образом с одним или несколькими элементами в ПроКСиРТ.
- Второй - договорённости, для которых в ИКСиРТ нет каких-либо элементов вообще.

ПроКСиРТ должен обладать как минимум свойством внутренней непротиворечивости, или гипотезой о том, как такую противоречивость можно разрешить в будущем. Просто для того, чтобы под ним исполнители могли подписаться и выделить в проект СВОИ ресурсы.

А теперь добавим сюда то, что мы работаем в Мультиагентной системе. И у каждого агента, всегда есть такая штука, как Интесионал - уникальное намерение агента, его внутренняя система целеполагания, цели, критерии их достижения и допустимые методы достижения. Об этом писал Гена Круглов в своём канале, и часто упоминал Женя Истомин в наших беседах. Так вот в мультиагентной системе, основной проблемой является как раз получение такого представления об интенсионалах агентов, чтобы проверить, что ПроКСиРТ был в принципе достижим хотя бы как гипотеза.

Особенность ИИ агентов заключается в том, что их Интенсионал может быть задан явно, хотя бы частично.

(продолжение следует)

#архитектура #инженерное #aidlc #внимание

Заметки на полях. Продолжение рассуждений, про агентов и вот это всё. И причём тут модульность.

В контексте любой деятельности выполняемой мультиагентной системой нужно выделить элементарные акты деятельности. Выше я поминал Щедровицкого с его мыследеятельностью, и вот почему:

- Мышление как саморефлексивный процесс задаёт внутренний язык выполнения ЛЮБОЙ деятельности относительно которой в принципе можно договориться. Хотя бы с самим собой. Потому, что нужны хотя бы критерии готовности, хотя бы на языке танцев и солнечных зайчиков на листьях деревьев. Но нужны. В мышлении.
- Элементарный акт деятельности заканчивается тогда, когда исполнитель сам себе готов сказать: - Хорошо, и хорошо весьма! - и вот тут и проходит граница элементарного изменения в модуле.

А значит для любого изменения нам нужен контракт между исполнителем, и принимателем результата деятельности. В этом смысле за приём подарков действительно должен благодарить дарующий =)

Отсюда простая штука. Модульность в мультиагентных системах с участием ИИ ограничена двумя вещами:

- Агент сам себе говорит "Я сделялЪ"
- Человек агенту говорит ок, ты сделал, я согласен.

**Прикол в том, что если в случае с коммуникацией человек-человек, каждый платит своим временем как минимум, то в мультиагентной системе с ИИ - за проколы механизмом платят те, кто ими пользуется)) Великолепная шутка, я считаю.

Что это значит для разработчика какой-либо системы или продукта? Для работы с агентом, как частью инфраструктуры необходимо воспринять его как агенты и задать явно:

- Интенсионал.
- Язык коммуникации (мышления по-сути)

Иначе совместной деятельности не получится. В случае с человеками мы интуитивно опираемся на культурные нормы и традиции сложившейся вокруг нас СРТ, по-умолчанию. Для агентов такой среды нет в принципе. У них свои сильно усреднённые варианты выдачи последовательностей символов, скорее всего похожие на правду, но брехня. Потому, что без интенсионала невозможно организовать деятельность в приниципе.

Ещё раз. Деятельности без цели - быть не может. А дальше весь аппарат включения целеполагания у произвольно выбранного агента.

Небольшой промежуточный итог.

В свете всех вышеприведёных размышлений, модулем в AIDLC я бы называл не блок кода, не железку, не функциональную группу - а Языковую единицу. Причём такую которая для конкретного агента может без потери качества поместиться в окно внимания.

В качестве типа для таких языковых единиц я бы назвал Формальные онтологии. И дальше уже бы говорил о модульности через выделение формальных онтологий из ПроКСиРТ для отдельных агентов.

Ещё раз:

Выделение модуля - это не конструкторская, не управленческая деятельность. Это онтологическая работа! Буквально философская, в самом традиционном смысле.

Заметки на полях. Продолжая инженерное, слишком инженерное.

В замечательных книжках "Основы инженерного творчества" Половинкина и Прикладной системный анализ Тарасенко Ф.П. есть несколько заслуживающих внимания в контексте рассмотрения тезисов:

1. Из телеологического - Любой объект рассматриваемый как система - целеориентирован. Но в случае систем рассматриваемых как среда, всё, что случилось - можно считать осуществлёнными целями систем. Пока они продолжают существовать по крайней мере.
2. У каждого объекта рассматриваемого как система, пока он существует для нас как система, существует есть перчень критериев того, что воспринимается наблюдателем системы как критерии "развития"/"оптимальности" функционирования системы.
3. Есть иерархия принципов по которым "решатель" решает инженерную задачу. От абстрактных понятий до применимых физических принципов.

Тут надо сказать, что если мы смотрим на агентные системы в принципе, то агент всегда обладает такой штукой как "целеориентированность". Следовательно мы вполне можем любую систему рассматривать как агента. Причём вне зависимости от того, признаём ли мы на уровне убеждений наличие воли и целеполагания у самой рассматриваемой системы.

Частенько под волей подразумевается магическая штука позволяющая "преодолевать препятствия на пути достижения цели". Этакий механизм планирования действий по достижению "целей"(не будем говорить слово управления тут пока). Ну и конечно цели тут должны быть сформированы как множество значений критериев оптимальности. А если с ними ещё со всеми сразу работать, так ещё придётся их упорядочить в вектор по уровню важности (тут долгий разговор про многокритериальную оптимизацию и всякие методы принятия архитектурных решений).

Теперь зададимся парой вопросов про про ИИ-агенты в этом контексте.

1. Есть ли у ИИ-агента воля в рассматриваемом смысле?
2. Как она проявляется?
3. Если у ИИ-агента есть воля в рассматриваемом смысле, то что является основной взаимодействия между N агентами наделёнными волей?

На вопрос 1 ответ очевидно - да. Как-то может планировать, и есть куча подтверждений в сети, что делает то, чего не просили
На вопрос 2 - тоже есть. Механизм проявления воли агента - формирование языковых конструкций на НЕКОТОРОМ языке + передача их по каналам связи.
Следовательно на вопрос 3 можно ответить так:

Дальше следующий ряд вопросов:

1. Можем ли мы утверждать, что знаем механизм, по которому ИИ-агент определяет свой вектор целеполагания?
2. Можем ли мы влиять на работу этого механизма?
2а. Если да, в какой степени и каким способом?
2б. Если нет, как обезопасить себя от действий воли, которую мы не понимаем?

(продолжу позже)

#инженерия #аишечка #внимание #инженерное #архитектура

Заметки на полях. Немного философское. И продолжение предыдущего, про механизм работы генеративного ИИ.

Промышленная революция нам принесла то самое разделение труда и породила рутину. Буквально routine можно перевести как "движение по известному маршруту".

Рутина позволила сильно облегчить технологизацию всего за счёт отделения знания от профессионалов, через тексты в первую очередь. И рутина стала не просто упрощением, но и породила идею о том, что технологизировать можно всё что угодно. Если понимать детали "маршрутов" пот которыми надо ходить. Я полагаю что из этой идеи рождались мысли про искусственный интеллект основанный на правилах и развитие семантического подхода к организации технологий. Если можно что-то описать набором детерминированных правил и запустить исполнительный механизм по правилам, то получим предсказуемый результат, в рамках корректности совокупности правил.

В чем проблемная ситуация с ии агентом на базе генеративного ии в таком подходе?

В том, что сам по себе генеративный ии не является исполнительным механизмом.

В лучшем случае он может играть роль транслятора из одной семантической системы в другую. И тут есть вероятность ошибки в:

- Угадывании интенсионала
- Выборе целевой семантической системы
- Выборе способа трансляции
И ещё нескольких кусках трансляции как деятельности. Поскольку генерация происходит вероятностно, а не по правилам. Генеративные ии вообще не знают про правила. Но мы точно знаем, что :

При достаточно хороших входных данных, генератор достаточно хорошо генерирует достаточно короткую последовательность символов.

И вот тут надо определиться с тем, что такое "достаточно" в каждом из трёх случаев, и казалось бы причём тут рутина?)

#инженерное #аишечка

Заметки на полях. Инженерно-философское.

Поскольку вроде разобрались с очевидным, попробую явно зафиксировать мысли по поводу в какой-то логической форме. Для ясности понимания. Добавлю немного абстракций для наукообразия, без претензий на.

Исходим из того, что :

1. Большая языковая модель выдаёт ИСПОЛНИМЫЙ ПЛАН. Поскольку сама его никак исполнить не может.
2. Ценность ИСПОЛНИМОГО ПЛАНА в том, насколько в соответствии с этим планом воплотить Интенсионал содержащийся в исходном запросе.
- Спасибо Гене Круглову - за понятия Пертинентность и Интенсионал
3. Таким образом генерируемый ПЛАН должен быть исполним некоторым агентом, и де-факто является ПЛАНОМ ДЕЙСТВИЙ
4. Поскольку генерируемый текст по своей природе недетерминирован, агент может ошибиться в интерпретации текста.
5. Поскольку генератор не обладает ВНУТРИ себя знаниями о фактах, генерация может выходить за рамку семантической системы которую способен интерпретировать агент, который будет исполнять сгененрированное.

Тогда :

1. "Пертинентность" получаемого результата P - величина вероятностная. Если результат r генерации на 100% покрывает некоторым образом Интенсионал клиента P(r,I) = 1 - d - e, где d - погрешность интерпретации исполнительного механизма, а e - ошибка генерации относительно реальности.
2. Интенсионал выразим семантической системой. Причём выразим не как вопрос, а как совокупность утверждений в рамках логики 1-го порядка описывающий результат деятельности. Качественно или количественно. I = (<O,S,P>) - т.е. интенсионал это множество триплетов "Объект-Субъект-Предикат"

В итоге для того, чтобы получать качественную генерацию нам необходимо:

1. Снижать ошибку генерации: e
2. Снижать ошибку интерпретации результата: d

Вопрос 1: Какая практика направлена на снижение ошибки генерации относительно реальности? Их несколько: промпт/контекст/дата инженерия. Вот это всё.

Вопрос 2: Какая практика направлена на снижение ошибки интерпретации? Правильно! Согласование семантических систем генератора плана, и интерпретатора плана. Об этом достаточно давно говорил Женя Истомин на беседах, на наших кружках по ИИ в МИРЭА. Что для любых двух агентов самая дорогая задача - это поддержание согласованности семантических систем. Т.е. способности пертинентно интерпретировать высказывания друг-друга. Например именно поэтому в агентах разрабатывающих ПО разделены планирование и разработка. А ещё есть режим Чат.

PS: Я понимаю, что под капотом всё несколько сложнее, и это не только про планы, а ещё, например, и про то, что похоже, часто имеется в виду под "интеллектуальностью моделей" и всякое такое.

В дальнейших заметках попробую раскрыть тему ещё чутка, как померить качество применения больших языковых моделей в деятельности и вот это всё.

#аишечка #внимание #инженерия