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

К сегодняшнему дню мои эксперименты наконец-то дали мне возможность начать работать с пайплайнами n8n. Таким образом сейчас имеем следующую картинку:

Поднято и работает:

1. llama.cpp + стэк моделей. Локально работают 27B + 35B A3B в 8-м кванте достаточно сильные ребята в паре для решения большинства задач.
2. LiteLLM - локальный роутер моделей + маршрутизатор запросов на openrouter. Решает ДОЛГИЕ задачи и задачи поиска по локальным данным, которые не загрузить в контекст сразу, плюс задача подготовки контекста для внешних моделей.
3. Observability стэк - Loki, Alloy, Prometheus, Tempo для оценки нагрузки на железо и того, что творится в логах, сколько реально выполняются запросы. Требует ещё доводки до состояния стояния. Сейчас позволяет отслеживать спаны только частично. Метрики с оборудования снимает хорошо.
4. n8n - Оркестратор агентных пайплайнов
5. onto-viz - сервер работы с графами знаний по RDF-онтологиям (доступен как MCP-сервер, навайбкожено при помощи Spec Driven Development) для подгрузки правил построения высказываний и контроля T-Box
6. Gitlab - как хранилище документов и пиналка хуков для n8n в ботах.
7. Hermes - Агент mcp-сервер, экспериментальная история для некоторых задач вызова "субагентов".

В процессе подъёма:

Ragflow :

- RAG насыщение векторной БД с метаданными на основании RDF из T-Box
- Обновление T-Box при расширенном насыщении векторной БД.
- Обогащение контекста агентных пайплайнов n8n RAG-данными из RAG-flow
- Обновление векторной БД по факту обновления данных в Gitlab как источнике истины по документам, с поддержкой версионирования, и управления конфигурацией данных.

Что будет в итоге:

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

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

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

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

===НАЧАЛО:Описание проблемной ситуации===
В процессе работы над любым проектом, объективно существует и можно выделить несколько измерений развития проекта по очевидности, и по скорости изменений. Чем меньше порядковый номер - тем выше скорость изменений в процессе. А чем больше номер - тем выше влияние изменений в соответствующей сфере на проект как 4Д-экстент =)

1. Изменения в артефактах поставки конечному потребителю. Неважно, что это такое, будь это чертёж, книжка, видео, софт или гайка. Это основная цепочка создания ценности. Пресловутый Value Chain.
2. Измения в описаниях артефактов поставляемых конечному потребителю. Это то, что мы привыкли называть "проектной документацией". Требования, архитектурные описания, тесты, документация и прочее. Это цепочка коммуникации между агентами, в системе разделения труда конекретной цепочки создания ценности. Суть - планирование и контроль качества конечного результата, включая планирование и контроль затрат. Это место появления классической Муды(Потерь) - разного рода.
3. Изменения в языке коммуникации ролевых агентов при организации деятельности в двух предыдущих цепочек. Это - цепочка корректировки того, КАК ИМЕННО мы говорим о конкретных Полезных действиях, Потерях и создаваемых Ценностях, Рисках. И то и то - можно отнести к категориям ресурсных Затрат.
4. Изменения в намерениях. Это изменения во ВНУТРЕННЕМ ЯЗЫКЕ каждого агента, которым он выражает то, что считает Потерями и Ценностью для себя.

Есть широко обсуждаемые виды затрат, считаемых потерями:

Муда 1. Потери в цепочке создания ценности.
Муда 2. Потери в работе над проектной документацией
Муда 3. Потери в переходах от коммуникации вокруг проектной документации к цепочке создания ценности.

Но, то что я не видел, чтобы обсуждалось - это:

Муда 4. Потери в согласовании языка межагентной коммуникации. Это потери ресурсов при создании создании Ubiquitous language. Получение согласованного Лексикона проекта.
Муда 5. Потери в доработке артефактов проекта под изменяющийся язык межагентной коммуникации. При каждом изменении Лексикона проекта необходимо отразить изменения в описательных артефактах, и как следствие в цепочке создания ценности.
Муда 6. Потери в выявлении Внутреннего языка агента в доступных для обсуждения концептах. (По-умному - экстракция интенсионала агента, я про интенсионалы говорил чуть выше)
Муда 7. Потери в контроле согласованности Внутреннего языка агента здесь и сейчас с Лексиконом проекта.

Любой из видов Муды растит Затраты. Я практически убеждён, что например аналитический паралич - это хрестоматийный пример ситуации когда Муды 4-7 видов столько, что на уровне перехода от коммуникации к деятельности любые конструктивные действия настолько низковероятны, что почти любые планы по созданию ценности будут в некоторый момент потом отнесены к Муде 3.

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

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

===КОНЕЦ:Описание проблемной ситуации===

Поэтому я пытаюсь построить цепочку, в которой есть явный протокол согласования в первую очередь языка проекта, который автоматизированно можно перенести на проектные артефакты, и тем самым немножко побороться с Мудой 4. Т.е. приблизиться к решению задачи выделения метамодели проектной деятельности в конкретном проекте, в независимости от того, что УЖЕ сделано, и какие артефакты существуют. Если их подать на вход некоторому "агенту", можно с достаточной уверенностью как минимум спрогнозировать коммуникационные конфликты на уровне "моя твоя нипанимат", и попробовать предложить некоторые варианты решений.

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

Завёл RAGFlow на реиндекс моего репозитория с образовательными материалами.

Пока получил такой результат:


1. Распознавание типов файлов идёт по расширениям. Шатал я их дом труба, если честно с таким подходом.
2. Запуск и дефолтная конфигурация - это не на полчаса. Это на денёк посидеть, изучить, подключить пару моделей и потом, может быть получится завести в тестовом кластере.
3. Достаточно странно разрабатывается, и видно, что валидационных тестов у ребят прям нехватает, когда в релиз пролезают штуки типа несоответствия валидации pydantic-ом схемы JSON запроса и типов поле БД куда эти данные вставляются. И всё это потому, что на минорной версии внезапно меняется схема БД, а валидаторы вызовов api от фронта к бэку допилить забыли.

Это кстати в огород "микросервисного подхода" камень, когда кто-то пытается выпускать ВЕСЬ сервис одной версией. Так вот, там не одна версия. А у каждого компонента своя. У Redis своя, у MySQL своя, у фронтенда - своя, у бэка своя, у python - своя и т.п.

Поэтому релиз как процесс должен совершенно точно включать полный цикл тестирования. И да, я понимаю, что пока v1.x.x не выпустили, можно официально творить любую дичь и говорить "У нас Semantic Version". Но это прям ... обман себя. Не надо так.

А пока мой маленький чёрный ящик пыхтит делая заготовку под Graph Retrival для студенческого бота по моей программе.

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

Короткие заметки:

1. Попробовал индексировать документы в сложном пайплайне - в итоге один документ на 300 чанков по 1024 токена на моём железе обрабатывался 8 часов. Правда с генерацией метаданных, графа знаний и выделением сущностей. Использовал Qwen3.6-35B-A3B-Q8_0 для индексирования. Документы поменьше - не сильно лучше.
2. Разработка пайплайнов для подготовки RAG-это прям работа. Причём неизведанное поле, на самом деле. Можно много наисследовать.
3. Модель Qwen3.6-27B-UD-Q8_K_XL от Unsloth я всё таки выгрузил из памяти. Нужно будет подобрать более лёгкую модель, на 7B типа Mistral или Qwen2.5-Instruct без ризонинга. На качество обработки при хороших промптах не сильно повлияет, а вот скорости добавит заметно.
4. Что радует, так это то, что исследовательскую работу вести достаточно приятно. От кишок сервисов до конца отойти не получается, потому, что LiteLLM, RagFlow и вот это всё - оно достаточно сырое и багованное, но в принципе уже можно ставить понятные эксперименты на реальных задачах.

Из забавного, любая парадигма внедрения ИИ сейчас скатывается к тому, насколько хорошо люди понимают, что именно они делают. Тут Гена Круглов писал про качество данных. Я с ним согласен и скажу так, в разрезе истории, с потерями ресурсов при коммуникации, про которые я вот выше рассуждал, данные - это кровь любой организации. Нужно раз и навсегда запомнить, что данные генерируются для получателя. Даже Карпатый сказал, что делегировать "намерение" и "понимание" не получится тут недавно.

Поэтому процитирую одно из своих любимых:

     -- ..."Мир есть Текст",  парень, -- все в точном соответствии  с твоими художественными  вкусами.  Ты-то  чем  недоволен?  -- деревянно  ухмыльнулся Грагер, нетвердою  рукой  разводя по стаканам очередную порцию не то текилы, не то еще какого-то самогонного пойла.
     -- Но ведь мы же с тобой писали другой Текст, совершенно другой!
     -- Что  значит --  другой? Текст, эстет ты  мой ненаглядный, существует лишь  во взаимодействии с  Читателем. Каждый человек пишет свою  собственную историю принцессы  Элендейл,  а уж чего там хотел сказать сам Альруфин -- не имеет  ровно  никакого  значения. Выходит,  мы  с  тобою  сочинили настоящий художественный  текст -- раз  читатели,  --  тут  резидент покрутил  пальцем где-то  в  районе уха,  так что не понять  было, кого  он имеет  в  виду  -- Королевский ли совет, или некие истинно  высшие Силы, -- сумели прочесть его таким вот непредсказуемым образом...

К. Еськов. Последний кольценосец

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

Заметки на инженерных полях. Разбираясь с RAG-системами.

Пилим потихоньку RAGFlow. Первые впечатления такие - достаточно объёмная система, быстро допиливается сообществом и вайбкодерами, активно развивается. Но я бы с ней в прод пока не шёл.

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

1. Требует достаточно бодрого, настроенного кластера MySQL. И надо иметь экспертизу по этой СУБД. Например понимать что делать с binary-log-ами, в какой момент, как настраивать репликацию, и почему тут пригодятся сверхбыстрые линки между инстансами.
2. Встроенные пайплайны наполнение БД жрут токены как не в себя. Просто миллионы токенов и тонно-километры. Нужно ОЧЕНЬ аккуратно обращаться с ними, и предельно ясно понимать как именно наполняется база данных
3. Построить Граф знаний одной кнопкой - круто, но строит фигню если исходники фигня. Загружаемая документация должна быть готова к тому, что по ней будут строить граф знаний. А ещё лучше, если этот граф можно будет снаружи грузить. Похоже, что здесь нужна реально сильная модель и миллиарды токенов чтобы получать вменяемый результат на более-менее адекватных объёмах данных (например пара сотен-тысящ-миллионов документов корпоративного RAG-а). Так что пока выглядит как игрушка
4. Есть несколько приятных встроенных фич, типа генерации ключевых слов, и типовых вопросов/ответов по чанкам.
5. Редактор пайплайнов встройки достаточно куц пока, весьма куц. На детском уровне относительно возможностей "написать свой код". Пока впечатление такое, что действительно проще делать N8n-пайплайны для наполнения векторной базы или писать свои модули.
6. Если хочется свой домашний RAG - то вполне крайне рекомендуется приобретение нескольких графических карт для запуска пайплайнов. Обычно документов много, они слабо структурированы, и придётся достаточно сложную обработку строить. Плюс параллелить запросы через какой-нибудь LiteLLM к 6-8 карточкам по 12-16 гигов, на каждой из которых крутится что-то вроде LLama 3 13B, Gemma 4 E4B, Qwen 2.5 Instruct 7B или подобных моделей. Критическая точка - это скорость памяти здесь. Модели можно использовать небольшие, тут надо распараллелить задачи знатно главное.
7. Админка у RAGFlow - это конечно фантастика. В принципе, если это ориентированное на суровый энтерпрайз решение, то понятно, что там только конфиги и голый API. Но это жутко неудобно для изучения возможностей.
8. Elastic Search, Minio, Redis под капотом - это конечно то ещё архитектурное решение. Поскольку Elastic - требует ещё одной суровой экспертизы, и непонятно как лицензируется, Minio - вообще снят с поддержки вендором как opensource решение + с 25.04.2026 репозиторий Minio на github - заморожен, а Redis - тот ещё оторва с лицензиями, да и Valkey от Linux foundation под BSD 3-Clause лицензией теперь вроде бы смотрится поживее.

Пока впечатления такие:

Официальный docker-compose конечно работает, но имеет кучу нюансов. Разорачивать - уже само по себе задача не тривиальной сложности. Настройка пайплайнов импорта - это вообще высший пилотаж на данный момент. Понимать как корректно маршрутизировать документы через пачку пайплайнов, чтобы RAG-выдача не была чушью - это совсем не тривиальная задача. Пока не вижу как её можно автоматизировать в принципе, поскольку для неё требуется то самое понимание предметной области и решаемых RAG-ом задач, о которой мы тут рассуждаем.

P.S.: Кажется построение RAG-ов вполне себе внятная ниша, которая сожрёт тонны специалистов и не поморщится. Поскольку это про качество данных, а туда можно вливать почти бесконечно.

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

Прокопал немного в сторону того, как будет примерно строиться RAG-система условно "нынешнего дня".
Как уже заметили ранее, просто так засунуть данные RAG - нельзя. Я пока изучаю тему, буду докидывать заметок на то, что мы вообще понимаем под "Качеством RAG".

Во первых к сути RAG ещё раз:

Если представлять RAG как функцию, то я вижу задачу RAG - как задачу получение структурированного контекста из следующих источников:

1. Модель предметной области деятельности решаемой задачи
2. Нормативные данные предметной области
3. Интерпретация входного Prompt-а на основании модели предметной области
4. Сенсорные данные
5. Интерпретация сенсорных данных на основании модели предметной области

Возможно, можно добавить что-то ещё, но это отдельный вопрос. Пока так.

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

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

Для начала зафиксируем модель оценки RAG-системы. Основные метрики данных которые получаем сформулировать не так просто. Во первых - эти данные не гомогенны. Нельзя сказать, что RAG - это NDCG@K+Recall+Precision. Это точно мало. Но поскольку на данный момент хорошо изучен семантический поиск - вся работа с развитием RAG-систем мне напоминает поиск ключей под фонарём, потому, что там светло.

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

1. Получить модель предметной области (МПО)
2. Получить нормативные данные предметной области
3. Интерпретировать исходный контекст (промпт в т.ч.) на основании МПО
4. Получить сенсорные данные
5. Интерпретировать сенсорные данные на основании МПО

На данный момент более-менее хорошо освоен только п.2. Это механизмы семантического поиска по данным. И как очевидно, релеватность, точность, полнота и прочее данных полученных в результате семантического поиска по данным зависит от качества исходных данных, от качества разметки данных, от качества механизмов получения, фильтрации и сортировки получаемых данных.

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

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

Поднял в МГТУ для нужд нашего подразделения кластер ALT Виртуализации. В принципе - PVE как PVE. В базе - версия 8.4, после установки вполне обновляется до PVE 9.1.4 из коробки.

Всё достаточно традиционно, для гипервизора. Из интересного, заявляют интеграцию с netbox ipam, но пока не сильно бодро работает, поскольку требует знать "какой там на самом деле netbox версии и откуда брали провайдера API". Со временем докручу себе это добро до состояния слабозатратной истории по времени.

Развернул там первую лабу для ИБшников, сидят пентестят в изолированных сетках себе там что-то. Радуются.

Если по значимым вехам:

1. ТЗ на закупку было сформировано год назад. Причём мы формировали его исходя из "нищебродского представления о том, что нам дадут". Дали то, что попросили. Даже удивительно.
2. Из приятного, мы просили в ТЗ только сервера, и хранилку. Поставщик попался грамотный, добрый и докинул всякого монтажного, вроде кабель-каналов, PDU-шек, колец, шины заземления, стяжки и вот это всё. Спасибо ему за это.
3. Серваки в базе неплохие ASUSы. Но в реестре =) При этом я настоятельно рекомендую всем сервера перед первым запуском вскрыть, посмотреть на сборку. Иногда братья-китайцы могу насобирать конечно...
4. Сборка-техприсоединение-финальный монтаж заняли дня 4, но растянуто по времени аж на 2 месяца. Б - Бббюрокррратия.

А, и ещё, если кому-то что-то очень надо - оно делается. Найти тех, кому очень надо - это сложно.

Ещё одно замечание:

Пока что ВУЗы тащат на студентах и профессуре. Спецов которые могут на полную вовлекаться в задачи там найти - это прям задача задач.

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

Заметка про ИИшное и всякое RAG-оподобное.

Начал активно тестить RAGFlow. Достаточно долго разбирался как оно устроено. Во первых могу сразу сказать, что продукта там нет. Есть некоторый набор тулов, которым можно попробовать что-то нашаманить. По крайней мере в комунити версии.

Как построил эксперимент:

Взял 42 статьи по инженерии требований разного рода, и дал сьесть RAGflow дефолтным пайплайном по формату Paper.

В качестве индексирующей модели использовал Квант Qwen3.6 A3B 35B Q8_0 от Triago
В качестве модели эмбеддингов: Квант Qwen3 Embeddings 4B Q8_0 от DevQasar
Реранкер: Квант Qwen3 Rerank 4B Q8_0 от DevQasar

Сделал чат внутри RAGFlow и попробовал с ним "поговорить" используя разные модели.

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

1. Была пара неприятных багов на версии 0.25.4 (дождался выхода 0.25.6 вроде пофиксилось)
2. Дефолтный пайплайн на моём Halo Strix крутился 4 суток. На 42 статьи.
3. Даже если поиск что-то возвращает, модели могут достаточно сильно лажать в интерпретации. Вот пример когда на один и тот же запрос две модели построили разный retrieval и совершенно по-разному отреагировали.

В общем как и ожидалось, наивное использование инструментов, и RAG в т.ч. - прожигание денег и времени.

RAGFlow сразу предлагает интегрироваться с LangFuse-сервером, что как говорится поможет оптимизировать промпты и запросы. Но тут сразу вопрос к компьюту. Откуда его столько выкопать...

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

Сегодня потратил день на интеграцию парсера PDF-ок OpenDataLoader в свой RAGFlow.

1. RAGFlow - это достаточно упоротые парни. И контракты там пишут... с изюминкой. Не очень понятно как и на что они надеялись и на что объявляя совместимость с решением ODL, но обёртку парсер пришлось сделать самому.
2. Сборку контейнера ODL сделал под свой HaloStrix. Парсит конечно сверхбыстро. pdf-ку на 150 страниц за 2 секунды переварил.
3. Пайплайны RAGFlow - это что-то с чем-то. Встроенные работают... как-то. Например запросто можно получить чанк на 8500 токенов на пайплайне Paper.
4. Некоторую часть работы скинул на openrouter с gpt4-120b:free. Вполне себе тащит, да, не быстро, но работает.

Проверил чатик с RAG-ом по статьям на нескольких моделях. Впечатления такие:

Qwen3.6-35B-A3B - самая галлюцинирующая, но галлюцинирует ОЧЕНЬ похоже на правду. Типичный ответ: Я тут ничего не нашёл, но вот то, что знаю.
Gemma-E4B - работает вполне нормально и адекватно
gpt4-120b:free - самый тупой. И ищет плохо, и рассуждает неочень.

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

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

Пару дней пробовал сделать следующую историю:

1. Взять pdf-ку с презентацией, распарсить её на чанки
2. Разметить чанки метаданными на основании кастомной онтологии
3. Засунуть в RAG чтобы оно там лежало
4. Сделать чатик с моделью использующей размеченные данные

Упёрся в достаточно простую, казалось бы, вещь. PDF-это такая свалка форматов, что его распарсить - это отдельный адЪ. Некоторые виды PDF-ок ODL разбирает очень хорошо. Но как только дело касается презентаций выгруженных из фигмы, powerpoint и другого кастомного ... добра, сразу упираемся с ограничения тулов.

В общем не рекомендую самодеятельность в этом плане, либо всё таки сводить PDF-ки к внятному стандартизированному формату для загрузки в RAG.

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

Давно не писал, но обнаружил тему, где стоит докинуть кеонтекста.

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

В одной из последних работ для мультагентной системы задаётся в сути две проблемы. С одной стороны нужно решить КОГДА инициировать коммуникацию, а с другой стороны нужно определить ЧТО сделать предметом коммуникации. В ИИ-шных системах эта проблема особенно актуальна, поскольку мы можем в некотором роде считать, что БЯМ "знают всё" (т.е. могут относительно семантически корректно составить любое высказывание), с другой стороны мы точно можем сказать, что БЯМ не содержат знаний самих по себе. Т.к. они строят высказывания на основании некоторых вероятностных сходств. Но чтобы не упираться в онтологическую дискуссию о том, что такое знание, сюда не полезу. Пока сформулирую это так:

БЯМ - может с некоторой вероятностью построить значимое высказывание в любой предметной области.

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

В указанной выше работе информация доступная агентам сразу делится на: Разделяемую, и частную. Более того, часть "внутренней информации" всегда может быть проигнорирована при принятии решения о необходимости коммуникации. Что порождает достаточно интересную часть задачи о проектировании мультиагентной системы.

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

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

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

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

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

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

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

Коммуникация возможна тогда и только тогда, когда гарантирована достаточно полная передача смысла.

Мы можем потерять часть сигнала, и из-за этого ошибиться в его интерпретации. Но если мы полностью приняли сигнал, мы гарантировано можем его корректно обработать. Если это не так, то традиционно считается, что такая MAS не жизнеспособна.
И до нынешних пор семантические потери в вычислительных (ИТ-системах) MAS было принято считать равными или близкими к нулю. Поскольку при согласованном протоколе общения на интерфейсе, любая пара агентов действуя согласно контракту ВСЕГДА сохраняет возможность корректно интерпретировать семантику на уровне заданных вычислительных правил. Т.е. коммуникация делилась на фазу установления, и фазу исполнения. В работе - фаза исполнения, переключение между интерфейсами - фаза установления. А контракты задаются внешними правилами.

Однако с появлением генеративных моделей появился феномен галлюцинации. И при общении вычислительных агентов даже при заданном протоколе коммуникации с ненулевой вероятности в содержание коммуникации вносятся устойчивые искажения.
Более того, явно есть попытка положиться на генеративные модели, как на модели самостоятельно выделяющие семантику, и выделяющие смысл внешнего запроса внутри. Для выполнения запроса на основании динамически выделяемого смысла в MAS необходимо контролировать чтобы смысл был "общим", для всего множества агентов. И каждая попытка «сделать смысл общим» расходует время, вычисления, пропускную способность, внимание (в человеко-ориентированных контурах проектирования), контекст БЯМ. А что что особенно важно для современных систем с применением БЯМ, расходуется достоверность контекста и расходуется стабильность коллективного состояния.

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

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

Накопал фундаментальные работы по мультиагентной коммуникации. Что интересное проявляется.

Первое, фундаментальное:

МАС - имеет общую цель и общую функцию. Если таковое выделить нельзя - это несколько систем.

Альтернативой этой концепции выступает Гараедаги с его Multiminded systems, но вся его концепция держится на фундаментальном допущении, что произвольно взятое множество агентов можно договорить в принципе. Но тут вступает в силу сложность контекста и рушит предлагаемый им "алгоритм решения" до практически сильно ограниченно применимого. В отдельной компании с выделенным высшим арбитром - да, можно. В реальном мире открытых взаимодействий можно забить на эту концепцию. Мы никогда не знаем намерений создателя сервиса и его целевую функцию, а любой арбитраж разобьётся о пачку юрисдикций, и возможности силового решения сторонами своих задач.

Второе фундаментальное:

Вообще за агента можно принимать любую целенаправленную или наблюдаемо целенаправленную штуку. А основные вопросы которые стоят при проектировании МАС с участием штуки - это вопросы сравнительной стоимости следующих кусков деятельности:

1. Спроектировать достаточно полную структуру общения агентов в текущей среде, чтобы всё, что они делают совместно приводило к общему результату
2. Доработать инфраструктуру так, чтобы планируемая задача была решаема в рамках ограничений
3. Сделать так, чтобы цена синхронизации состояний в процессе была приемлема при попытке решить частную задачу

Третье фундаментальное:

В современных МАС у нас стакаются три типа агентов, люди, роботы, БЯМки. И если роботы с людьми ещё как-то работают вместе, запроектировав защиту от дурака, используя разные методы safety engeneering, то с добавлением сюда ещё и галлюцинирующих моделей применимоcть SE ограничивается только роботами. А сложность предсказания катастрофического сценария выходит за пределы возможностей предсказания какой-либо математикой. В том смысле, что стоимость предсказания катастрофы становится сопоставима со стоимостью устранения её последствий.

Поэтому проектируя новые системы критически важно принять аксиому о неизбежности катастрофы. Я её формулирую так:

Как бы хорошо ни была спроектирована мультиагентная система на достаточно длительном периоде существования она ОБЯЗАТЕЛЬНО станет частью катастрофического сценария, который невозможно как предсказать, так и предотвратить.

Это прямое следствие закона Мёрфи, вроде бы очевидное, но нет. Пока мы верим в силу ИИ и в то, что "мы справимся".

#инженерия #инженерное #рефлексия #архитектура