tgindex

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

описание

Ежедневная инженерная работа одного архитектора. Что бывает, происходит, и зачем.

← к каналу@itengfieldnotes
106
подписчиков
Охват к подписчикам
67,9%
ERR
Реакции к просмотрам
0,16%
3 на 24 постов
Пересылки к просмотрам
1,09%
20
Постов в день
0,0
всего 24

Где отзываются чаще

доля реакций к просмотрам
  • 25 июн.Заметки на полях. Буду продолжать развивать тему мультиагентной коммуникации в открытых средах. Несколько заметок будут с базой, а дальше - будем потихоньку углубляться. Начнём с простого. По-умолчанию можно считать, что мультиагентных системах (MAS) коммуникация является не «добавочной» функцией поверх некоторого фиксированного, заранее заданного поведения, а частью механизма выполнения целевой функции. Агенты координируют планы, уточняют имеющиеся данные, согласуют ожидания и проверяют интерпретации сообщений и выполняют множество других целенаправленных коммуникационных актов. Поэтому происходящие внутри MAS процессы необходимо рассматривать как с инженерной, прикладной, так и с теоретической точки зрения. Теоретическая точка зрения фокусируется на том, какие именно задачи необходимо решить, для того, чтобы получить решение прикладной задачи. Инженерная - на определении класса задачи и выделении известных решений, которые можно применить на практике. Коммуникация в любой системе всегда является областью неизбежных ресурсных затрат(потерь с точки зрения целевой функции) затрачиваемых на сопротивление "среды" коммуникации. С точки зрения ТРИЗ в идеальная функция коммуникации есть, а стоимость коммуникации равна нулю, или близка к нему. Примером "почти идеальной функции" является передача указателя в памяти внутри программного процесса. Это вычислительно стоит почти ноль, относительно целевой функции, вероятность ошибки близка к нулю, а функция коррекции относительно целевой функции программного процесса стоит так же крайне дёшево. Но в современных MAS агенты общаются в открытой разнородной среде, и такая среда обладает некоторым "сопротивлением" распространения содержания коммункации. Традиционно выделяют канал коммуникации, состоящий из Источника сигнала, Приёмника сигнала и Среды передачи сигнала, и содержание коммуникации. Т.е. практический смысл, некоторая интерпретация сигнала. Для любого сигнала базово выделяется алфавит, синтаксис и семантика. А если говорить про потери, то традиционно принято считать, что : Коммуникация возможна тогда и только тогда, когда гарантирована достаточно полная передача смысла. Мы можем потерять часть сигнала, и из-за этого ошибиться в его интерпретации. Но если мы полностью приняли сигнал, мы гарантировано можем его корректно обработать. Если это не так, то традиционно считается, что такая MAS не жизнеспособна. И до нынешних пор семантические потери в вычислительных (ИТ-системах) MAS было принято считать равными или близкими к нулю. Поскольку при согласованном протоколе общения на интерфейсе, любая пара агентов действуя согласно контракту ВСЕГДА сохраняет возможность корректно интерпретировать семантику на уровне заданных вычислительных правил. Т.е. коммуникация делилась на фазу установления, и фазу исполнения. В работе - фаза исполнения, переключение между интерфейсами - фаза установления. А контракты задаются внешними правилами. Однако с появлением генеративных моделей появился феномен галлюцинации. И при общении вычислительных агентов даже при заданном протоколе коммуникации с ненулевой вероятности в содержание коммуникации вносятся устойчивые искажения. Более того, явно есть попытка положиться на генеративные модели, как на модели самостоятельно выделяющие семантику, и выделяющие смысл внешнего запроса внутри. Для выполнения запроса на основании динамически выделяемого смысла в MAS необходимо контролировать чтобы смысл был "общим", для всего множества агентов. И каждая попытка «сделать смысл общим» расходует время, вычисления, пропускную способность, внимание (в человеко-ориентированных контурах проектирования), контекст БЯМ. А что что особенно важно для современных систем с применением БЯМ, расходуется достоверность контекста и расходуется стабильность коллективного состояния. #инженерное #аишечка #внимание1,45%
  • 17 маяЗаметки на инженерных полях. Разбираясь с 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-ов вполне себе внятная ниша, которая сожрёт тонны специалистов и не поморщится. Поскольку это про качество данных, а туда можно вливать почти бесконечно.1,35%
  • 12 маяЗаметки на полях. Инженерно-ИИшное. К сегодняшнему дню мои эксперименты наконец-то дали мне возможность начать работать с пайплайнами 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 - это достаточно общая задача. #аишечка #инженерия #образование1,35%
  • 10 июл.без подписи0,00%
  • 10 июл.без подписи0,00%
  • 10 июл.Заметки на полях. Продолжая тему применения больших языковых моделей в некоторых процессах. Вообще достаточно очевидно, что первостепенный представляет интерес в качестве объекта редактирования при работе с LLM-агентами тот контекст, который содержится в контекстном окне. И тут для нас было бы замечательно закрепить базу, что там вообще есть. Для начала вспомним любой курс по ЛЛМкам и там будет что-то вроде : Контекстное окно заполняется следующими элементами: - Системный промпт - Пользовательский промпт - История чата - Внешний контекст Однако, это в контексте единичной генерации. А в длительных цепочках рассуждений и больших диалогах? При простой последовательной генерации без дополнительных манипуляций контекстом - всё достаточно просто. На картинках я это разрисовал. Но достаточно ли это для хорошей генерации? Конечно нет, поскольку зная использованные типы данных, мы можем произвести несколько замечательных манипуляций с контекстом: 1. Удаление лишнего 2. Упорядочивание контекста по мере значимости типов данных 3. Редактирование отдельных элементов контекста Например мы можем проанализировать структуру вызовов инструментов, и оставить только данные высокой степени релевантности, нормализовать контекст онтологически в рамках целевого процесса и другие интересные вещи. Чем мы за этом платим: - Каждый вызов генератора - нужно парсить заново контекст. Возможно весь. И скорее всего мы потеряем возможность использовать контекстные чекпоинты большого размера (500+ токенов). Что мы в итоге получаем: - Уменьшаем влияние проблемы "Потерянной середины" - Экономим размер контекстного окна - Повышаем релевантность генерации Вроде бы элементарная база, но почему-то я ни разу не видел, чтобы её открыто обсуждали. А ведь кажется, что именно в этом и заключается Context engeneering. #аишечка #инженерия #внимание #архитектура0,00%
  • 1 июл.Заметки на исследовательском поле. Продолжаю копать в сторону того, что вообще происходит в мультиагентных системах. Накопал фундаментальные работы по мультиагентной коммуникации. Что интересное проявляется. Первое, фундаментальное: МАС - имеет общую цель и общую функцию. Если таковое выделить нельзя - это несколько систем. Альтернативой этой концепции выступает Гараедаги с его Multiminded systems, но вся его концепция держится на фундаментальном допущении, что произвольно взятое множество агентов можно договорить в принципе. Но тут вступает в силу сложность контекста и рушит предлагаемый им "алгоритм решения" до практически сильно ограниченно применимого. В отдельной компании с выделенным высшим арбитром - да, можно. В реальном мире открытых взаимодействий можно забить на эту концепцию. Мы никогда не знаем намерений создателя сервиса и его целевую функцию, а любой арбитраж разобьётся о пачку юрисдикций, и возможности силового решения сторонами своих задач. Второе фундаментальное: Вообще за агента можно принимать любую целенаправленную или наблюдаемо целенаправленную штуку. А основные вопросы которые стоят при проектировании МАС с участием штуки - это вопросы сравнительной стоимости следующих кусков деятельности: 1. Спроектировать достаточно полную структуру общения агентов в текущей среде, чтобы всё, что они делают совместно приводило к общему результату 2. Доработать инфраструктуру так, чтобы планируемая задача была решаема в рамках ограничений 3. Сделать так, чтобы цена синхронизации состояний в процессе была приемлема при попытке решить частную задачу Третье фундаментальное: В современных МАС у нас стакаются три типа агентов, люди, роботы, БЯМки. И если роботы с людьми ещё как-то работают вместе, запроектировав защиту от дурака, используя разные методы safety engeneering, то с добавлением сюда ещё и галлюцинирующих моделей применимоcть SE ограничивается только роботами. А сложность предсказания катастрофического сценария выходит за пределы возможностей предсказания какой-либо математикой. В том смысле, что стоимость предсказания катастрофы становится сопоставима со стоимостью устранения её последствий. Поэтому проектируя новые системы критически важно принять аксиому о неизбежности катастрофы. Я её формулирую так: Как бы хорошо ни была спроектирована мультиагентная система на достаточно длительном периоде существования она ОБЯЗАТЕЛЬНО станет частью катастрофического сценария, который невозможно как предсказать, так и предотвратить. Это прямое следствие закона Мёрфи, вроде бы очевидное, но нет. Пока мы верим в силу ИИ и в то, что "мы справимся". #инженерия #инженерное #рефлексия #архитектура0,00%
  • 25 июн.➡️➡️*продолжение* В связи с этим необходимо исследовать, каким образом можно разделить затраты на установление доверенной коммункиации, восполнение ресурса достоверности контекста, и стабилизацию колективного состояния между фазами "подготовки к коммуникации"(offline communcation phase) и "исполнения"(runtime communication phase). Плюс исследовать как данные затраты влияют на традиционные модели построения информационных систем, как меняется при этом функция эффективности, и какие прагматические выводы из этого можно сделать. Поэтому я тут начну публиковать заметки по систематическому анализу ресурсных потерь, возникающих как при установлении коммуникационного канала, так и в процессе самого коммуникационного акта в современных MAS. На данный момент у меня основная гипотеза - это закон сохранения стоимости коммуникации: ❗️ Любое архитектурное решение принятое при проектировании коммуникации способно только перераспределить затраты их между различными фазами и типами, но не способно исключить их в целом. —— ❗️Почему это актуально Несмотря на десятилетия исследований в области коммуникации MAS, отсутствует единый язык и формальный аппарат для сравнительного анализа ресурсных затрат различных архитектур. Существующие подходы, от формальных языков типа KQML/FIPA ACL до современных LLM-систем, оцениваются по разнородным метрикам. Это затрудняет понимание фундаментальных компромиссов и принципа перераспределения затрат между фазами setup и act. Литература фрагментирована на исследования отдельных парадигм, без общей таксономии, которая позволила бы системно сопоставить, например, стоимость разработки онтологии со стоимостью runtime-верификации семантики в системе с использованием БЯМ. Несколько глубоких исследований и попыток найти обобщающие материалы при помощи анализа сборников arXiv и других при помощи Elicit.ai - потерпели неудачу. ❓На какие вопросы нужно ответить как минимум 1️⃣ Какие классы ресурсных потерь возникают в коммуникации MAS и как их можно классифицировать по фазам (setup vs. act) и моменту вычисления (offline vs. online)? 2️⃣ Можно ли формализовать эти классы потерь в виде единой системы метрик, применимой к различным архитектурам (от ACL до LLM) и если да, то как? 3️⃣ Действительно ли существует ли «закон сохранения стоимости», согласно которому снижение затрат в одной фазе (например, снижение затрат на подготовку к коммуникции между LLM-агентами) неизбежно ведет к их росту в другой (например, act-phase затраты на митигацию галлюцинаций)? 4️⃣ Как эволюционировал профиль ресурсных потерь по мере перехода от символических архитектур коммуникаций к коммуникациям с использованием генеративного ИИ?0,00%
  • 23 июн.Заметки на полях. Давно не писал, но обнаружил тему, где стоит докинуть кеонтекста. Из того, что я сейчас наблюдаю в сфере построения мультиагентных систем, я не вижу ни одной отсылки к такой области как "Теория коммуникаций". Более того, проведя несколько запросов в Elicit стало понятно, что вопрос "Внутренней-Внешней" коммуникации в агентных системах вообще сейчас вне рассмотрения как инженерного, так и академического сообщества. Внятных работ в этой области вообще мало, и пока только на уровне лабораторных работ. В одной из последних работ для мультагентной системы задаётся в сути две проблемы. С одной стороны нужно решить КОГДА инициировать коммуникацию, а с другой стороны нужно определить ЧТО сделать предметом коммуникации. В ИИ-шных системах эта проблема особенно актуальна, поскольку мы можем в некотором роде считать, что БЯМ "знают всё" (т.е. могут относительно семантически корректно составить любое высказывание), с другой стороны мы точно можем сказать, что БЯМ не содержат знаний самих по себе. Т.к. они строят высказывания на основании некоторых вероятностных сходств. Но чтобы не упираться в онтологическую дискуссию о том, что такое знание, сюда не полезу. Пока сформулирую это так: БЯМ - может с некоторой вероятностью построить значимое высказывание в любой предметной области. Однако с практической точки зрения вопрос становится непраздным. Поскольку стоимость решения задачи в токенах напрямую зависит от того, сколько высказываний пришлось построить от первичного пользовательского ввода до прагматичного решения задачи. Поэтому вполне уместным кажется обратиться к устоявшимся предметным областям в вопросе организации коммуникаций. В указанной выше работе информация доступная агентам сразу делится на: Разделяемую, и частную. Более того, часть "внутренней информации" всегда может быть проигнорирована при принятии решения о необходимости коммуникации. Что порождает достаточно интересную часть задачи о проектировании мультиагентной системы. Если под "общей информацией" подразумевать некоторый тезаурус, то для снижения количества галлюцинаций имеет смысл копнуть в сторону контроля состояния этого тезауруса.0,00%
  • 9 июн.Заметки на полях. Аишное. Пару дней пробовал сделать следующую историю: 1. Взять pdf-ку с презентацией, распарсить её на чанки 2. Разметить чанки метаданными на основании кастомной онтологии 3. Засунуть в RAG чтобы оно там лежало 4. Сделать чатик с моделью использующей размеченные данные Упёрся в достаточно простую, казалось бы, вещь. PDF-это такая свалка форматов, что его распарсить - это отдельный адЪ. Некоторые виды PDF-ок ODL разбирает очень хорошо. Но как только дело касается презентаций выгруженных из фигмы, powerpoint и другого кастомного ... добра, сразу упираемся с ограничения тулов. В общем не рекомендую самодеятельность в этом плане, либо всё таки сводить PDF-ки к внятному стандартизированному формату для загрузки в RAG.0,00%
  • 6 июн.Заметка на полях. Сегодня потратил день на интеграцию парсера 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 #инженерное0,00%
  • 5 июн.Заметка про ИИшное и всякое 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-сервером, что как говорится поможет оптимизировать промпты и запросы. Но тут сразу вопрос к компьюту. Откуда его столько выкопать...0,00%