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

Заметки на полях. Продолжая тему применения больших языковых моделей в некоторых процессах. Вообще достаточно очевидно, что первостепенный представляет интерес в качестве объекта редактирования при работе с LLM-агентами тот контекст, который содержится в контекстном окне. И тут для нас было бы замечательно закрепить базу, что там вообще есть. Для начала вспомним любой курс по ЛЛМкам и там будет что-то вроде : Контекстное окно заполняется следующими элементами: - Системный промпт - Пользовательский промпт - История чата - Внешний контекст Однако, это в контексте единичной генерации. А в длительных цепочках рассуждений и больших диалогах? При простой последовательной генерации без дополнительных манипуляций контекстом - всё достаточно просто. На картинках я это разрисовал. Но достаточно ли это для хорошей генерации? Конечно нет, поскольку зная использованные типы данных, мы можем произвести несколько замечательных манипуляций с контекстом: 1. Удаление лишнего 2. Упорядочивание контекста по мере значимости типов данных 3. Редактирование отдельных элементов контекста Например мы можем проанализировать структуру вызовов инструментов, и оставить только данные высокой степени релевантности, нормализовать контекст онтологически в рамках целевого процесса и другие интересные вещи. Чем мы за этом платим: - Каждый вызов генератора - нужно парсить заново контекст. Возможно весь. И скорее всего мы потеряем возможность использовать контекстные чекпоинты большого размера (500+ токенов). Что мы в итоге получаем: - Уменьшаем влияние проблемы "Потерянной середины" - Экономим размер контекстного окна - Повышаем релевантность генерации Вроде бы элементарная база, но почему-то я ни разу не видел, чтобы её открыто обсуждали. А ведь кажется, что именно в этом и заключается Context engeneering. #аишечка #инженерия #внимание #архитектура

Заметки на исследовательском поле. Продолжаю копать в сторону того, что вообще происходит в мультиагентных системах. Накопал фундаментальные работы по мультиагентной коммуникации. Что интересное проявляется. Первое, фундаментальное: МАС - имеет общую цель и общую функцию. Если таковое выделить нельзя - это несколько систем. Альтернативой этой концепции выступает Гараедаги с его Multiminded systems, но вся его концепция держится на фундаментальном допущении, что произвольно взятое множество агентов можно договорить в принципе. Но тут вступает в силу сложность контекста и рушит предлагаемый им "алгоритм решения" до практически сильно ограниченно применимого. В отдельной компании с выделенным высшим арбитром - да, можно. В реальном мире открытых взаимодействий можно забить на эту концепцию. Мы никогда не знаем намерений создателя сервиса и его целевую функцию, а любой арбитраж разобьётся о пачку юрисдикций, и возможности силового решения сторонами своих задач. Второе фундаментальное: Вообще за агента можно принимать любую целенаправленную или наблюдаемо целенаправленную штуку. А основные вопросы которые стоят при проектировании МАС с участием штуки - это вопросы сравнительной стоимости следующих кусков деятельности: 1. Спроектировать достаточно полную структуру общения агентов в текущей среде, чтобы всё, что они делают совместно приводило к общему результату 2. Доработать инфраструктуру так, чтобы планируемая задача была решаема в рамках ограничений 3. Сделать так, чтобы цена синхронизации состояний в процессе была приемлема при попытке решить частную задачу Третье фундаментальное: В современных МАС у нас стакаются три типа агентов, люди, роботы, БЯМки. И если роботы с людьми ещё как-то работают вместе, запроектировав защиту от дурака, используя разные методы safety engeneering, то с добавлением сюда ещё и галлюцинирующих моделей применимоcть SE ограничивается только роботами. А сложность предсказания катастрофического сценария выходит за пределы возможностей предсказания какой-либо математикой. В том смысле, что стоимость предсказания катастрофы становится сопоставима со стоимостью устранения её последствий. Поэтому проектируя новые системы критически важно принять аксиому о неизбежности катастрофы. Я её формулирую так: Как бы хорошо ни была спроектирована мультиагентная система на достаточно длительном периоде существования она ОБЯЗАТЕЛЬНО станет частью катастрофического сценария, который невозможно как предсказать, так и предотвратить. Это прямое следствие закона Мёрфи, вроде бы очевидное, но нет. Пока мы верим в силу ИИ и в то, что "мы справимся". #инженерия #инженерное #рефлексия #архитектура

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

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

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

Заметки на полях. Аишное. Пару дней пробовал сделать следующую историю: 1. Взять pdf-ку с презентацией, распарсить её на чанки 2. Разметить чанки метаданными на основании кастомной онтологии 3. Засунуть в RAG чтобы оно там лежало 4. Сделать чатик с моделью использующей размеченные данные Упёрся в достаточно простую, казалось бы, вещь. PDF-это такая свалка форматов, что его распарсить - это отдельный адЪ. Некоторые виды PDF-ок ODL разбирает очень хорошо. Но как только дело касается презентаций выгруженных из фигмы, powerpoint и другого кастомного ... добра, сразу упираемся с ограничения тулов. В общем не рекомендую самодеятельность в этом плане, либо всё таки сводить PDF-ки к внятному стандартизированному формату для загрузки в RAG.

Заметка на полях. Сегодня потратил день на интеграцию парсера 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 #инженерное

Заметка про ИИшное и всякое 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-сервером, что как говорится поможет оптимизировать промпты и запросы. Но тут сразу вопрос к компьюту. Откуда его столько выкопать...

Заметки на полях. Инженерно-виртуальное. Поднял в МГТУ для нужд нашего подразделения кластер ALT Виртуализации. В принципе - PVE как PVE. В базе - версия 8.4, после установки вполне обновляется до PVE 9.1.4 из коробки. Всё достаточно традиционно, для гипервизора. Из интересного, заявляют интеграцию с netbox ipam, но пока не сильно бодро работает, поскольку требует знать "какой там на самом деле netbox версии и откуда брали провайдера API". Со временем докручу себе это добро до состояния слабозатратной истории по времени. Развернул там первую лабу для ИБшников, сидят пентестят в изолированных сетках себе там что-то. Радуются. Если по значимым вехам: 1. ТЗ на закупку было сформировано год назад. Причём мы формировали его исходя из "нищебродского представления о том, что нам дадут". Дали то, что попросили. Даже удивительно. 2. Из приятного, мы просили в ТЗ только сервера, и хранилку. Поставщик попался грамотный, добрый и докинул всякого монтажного, вроде кабель-каналов, PDU-шек, колец, шины заземления, стяжки и вот это всё. Спасибо ему за это. 3. Серваки в базе неплохие ASUSы. Но в реестре =) При этом я настоятельно рекомендую всем сервера перед первым запуском вскрыть, посмотреть на сборку. Иногда братья-китайцы могу насобирать конечно... 4. Сборка-техприсоединение-финальный монтаж заняли дня 4, но растянуто по времени аж на 2 месяца. Б - Бббюрокррратия. А, и ещё, если кому-то что-то очень надо - оно делается. Найти тех, кому очень надо - это сложно. Ещё одно замечание: Пока что ВУЗы тащат на студентах и профессуре. Спецов которые могут на полную вовлекаться в задачи там найти - это прям задача задач. #инженерия #образование #альтвиртуализация #цод

Заметки на полях. Инженерно-иишное. Прокопал немного в сторону того, как будет примерно строиться 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. Это механизмы семантического поиска по данным. И как очевидно, релеватность, точность, полнота и прочее данных полученных в результате семантического поиска по данным зависит от качества исходных данных, от качества разметки данных, от качества механизмов получения, фильтрации и сортировки получаемых данных. А что делать с Моделями предметной области - это вопрос. Сейчас туда пытаются копать, но такое ощущение, что не знают куда, поскольку онтологи вечно были сродни философам, которых вообще непонятно было куда приткнуть и как, что в итоге отразилось и на их популярности и на идеях часто напоминающих религиозные доктрины. Соответственно работа с онтологиями, т.е. представлениями предметных областей в структурированной форме сейчас дело маргинальное. А может стать вполне себе прибыльным, потому, что без онтологической поддержки семантический поиск строить конечно можно, но лично я не настолько богат.

Заметки на инженерных полях. Разбираясь с 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-ов. Короткие заметки: 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 и вот это всё - оно достаточно сырое и багованное, но в принципе уже можно ставить понятные эксперименты на реальных задачах. Из забавного, любая парадигма внедрения ИИ сейчас скатывается к тому, насколько хорошо люди понимают, что именно они делают. Тут Гена Круглов писал про качество данных. Я с ним согласен и скажу так, в разрезе истории, с потерями ресурсов при коммуникации, про которые я вот выше рассуждал, данные - это кровь любой организации. Нужно раз и навсегда запомнить, что данные генерируются для получателя. Даже Карпатый сказал, что делегировать "намерение" и "понимание" не получится тут недавно. Поэтому процитирую одно из своих любимых: -- ..."Мир есть Текст", парень, -- все в точном соответствии с твоими художественными вкусами. Ты-то чем недоволен? -- деревянно ухмыльнулся Грагер, нетвердою рукой разводя по стаканам очередную порцию не то текилы, не то еще какого-то самогонного пойла. -- Но ведь мы же с тобой писали другой Текст, совершенно другой! -- Что значит -- другой? Текст, эстет ты мой ненаглядный, существует лишь во взаимодействии с Читателем. Каждый человек пишет свою собственную историю принцессы Элендейл, а уж чего там хотел сказать сам Альруфин -- не имеет ровно никакого значения. Выходит, мы с тобою сочинили настоящий художественный текст -- раз читатели, -- тут резидент покрутил пальцем где-то в районе уха, так что не понять было, кого он имеет в виду -- Королевский ли совет, или некие истинно высшие Силы, -- сумели прочесть его таким вот непредсказуемым образом... К. Еськов. Последний кольценосец #аишечка #инженерное

Заметки на полях. Инженерное Сегодня подвёл свой Minisforum MS-S1 MAX в пределу производительности. Итак, что туда влезло, одновременно запущеное: 1. 4 модели. Embed+Rerank для поддержки RAG-индексации 2. LiteLLM - как маршрутизатор запросов и прокси к моделям 3. RAGFlow - Вроде как неплохой RAG-движок для разбора документации. Сейчас он у меня научные статьи мои крутит. 4. Модель Qwen3.5 27B Q8_0 5. Модель Qwen3.6 35B Q8_0 Для управления агентами на другой машине - N8N+onto-viz для подтягивания семантического корректора (скажем так). Что с загрузкой - завязано под самый свисток. Вполне возможно полный контекст Qwen3.5 27B (а его там ещё 262144 токена) не влезет... Но пока свистит, живёт, и пашет потихоньку. Оставлю на ночь парсить документы дальше. Думал всё заводить под K8s для простоты управления, но походу не надо так. Простой podman quadlet + systemd пока смотрится надёжнее.

Заметки на полях. Инженерно-иишное. Завёл RAGFlow на реиндекс моего репозитория с образовательными материалами. Пока получил такой результат: 1. Распознавание типов файлов идёт по расширениям. Шатал я их дом труба, если честно с таким подходом. 2. Запуск и дефолтная конфигурация - это не на полчаса. Это на денёк посидеть, изучить, подключить пару моделей и потом, может быть получится завести в тестовом кластере. 3. Достаточно странно разрабатывается, и видно, что валидационных тестов у ребят прям нехватает, когда в релиз пролезают штуки типа несоответствия валидации pydantic-ом схемы JSON запроса и типов поле БД куда эти данные вставляются. И всё это потому, что на минорной версии внезапно меняется схема БД, а валидаторы вызовов api от фронта к бэку допилить забыли. Это кстати в огород "микросервисного подхода" камень, когда кто-то пытается выпускать ВЕСЬ сервис одной версией. Так вот, там не одна версия. А у каждого компонента своя. У Redis своя, у MySQL своя, у фронтенда - своя, у бэка своя, у python - своя и т.п. Поэтому релиз как процесс должен совершенно точно включать полный цикл тестирования. И да, я понимаю, что пока v1.x.x не выпустили, можно официально творить любую дичь и говорить "У нас Semantic Version". Но это прям ... обман себя. Не надо так. А пока мой маленький чёрный ящик пыхтит делая заготовку под Graph Retrival для студенческого бота по моей программе.

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

Заметки на полях. Инженерно-ИИшное. К сегодняшнему дню мои эксперименты наконец-то дали мне возможность начать работать с пайплайнами 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 - это достаточно общая задача. #аишечка #инженерия #образование