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

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

Точность рассуждений повысилась примерно на 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: Я понимаю, что под капотом всё несколько сложнее, и это не только про планы, а ещё, например, и про то, что похоже, часто имеется в виду под "интеллектуальностью моделей" и всякое такое.

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

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

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

Контекст:

Есть такой образовательный жанр, занятие с экспертом. Пусть есть некоторый сценарий занятия, записи лекции или что-то подобное. Мы просим технического специалиста по теме лекции, по сценарию записать видеолекцию для размещении в СДО или для распространения среди коллег.

На что есть варианты наткнуться:

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

Проблемная ситуация:

Слушатель читающего лекцию воспринимает как эксперта. Однако СЛУШАТЬ эксперта при этом весьма сложно, если его специально не подготовить, а эксперт в технической области редко эксперт в говорении ртом слов. Таким образом выбирать приходится либо между тем, кто может с корректными интонациями прочитать, и тем, кто понимает что именно он читает.

Проблема организатора образовательного процесса:

- Слушатель не может услышать эксперта, потому, что эксперт не способен артикулировать мысль, а эксперту не интересно артикулировать мысль так, чтобы его можно было услышать и таким образом передача экспертизы оказывается сопряжена с барьером контроля внимания слушателем.

Достаточно очевидно, что можно попробовать сделать что-то вообще без видеолекций и примеров, чтобы не надо было слушать. Но это the next level play(с) и я пока не понимаю как это чинить в реальности.

#внимание #образование

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

Довел до "почти ума" домашний кластер на minisforum.ms-s1.max.

4 модели в памяти на llama.cpp:
- qwen3-embedding-4b-q8
- qwen3-reranker-4b-q8
- qwen3.6 35b a3b q8_0
- qwen3.5 27b q8kxl

Прокси в виде LiteLLM с маршрутизатором запросов
Мониторинг PLG+Alloy+Podman+Tempo exporter. Журнал запросов, промптов и метрики производительности.


Наблюдения:

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

Средняя загрузка памяти 80-82%
CPU - 3-4%
GPU - 100%(что логично)

По дороге ставил эксперименты на маленьких задачках. В принципе не быстро, но решает. И достойно.

В планах сделать его анонимайзером и роутером запросов от локальных агентов. Сюда же, на эти же 140 ватт(!!!) влезет ещё и n8n и RAGFlow.

Да, память скорее немного просядет, но... Загрузка шины памяти сервисами настолько мала, что ей можно пока пренебречь.

#инженерное #аишечка #локальныемодели