Заметки на инженерных полях
Заметки на полях. Продолжение рассуждений, про агентов и вот это всё. И причём тут модульность. В контексте любой деятельности выполняемой мультиагентной системой нужно выделить элементарные акты деятельности. Выше я поминал Щедровицкого с его мыследеятельностью…
Небольшой промежуточный итог.
В свете всех вышеприведёных размышлений, модулем в AIDLC я бы называл не блок кода, не железку, не функциональную группу - а Языковую единицу. Причём такую которая для конкретного агента может без потери качества поместиться в окно внимания.
В качестве типа для таких языковых единиц я бы назвал Формальные онтологии. И дальше уже бы говорил о модульности через выделение формальных онтологий из ПроКСиРТ для отдельных агентов.
Ещё раз:
Выделение модуля - это не конструкторская, не управленческая деятельность. Это онтологическая работа! Буквально философская, в самом традиционном смысле.
В свете всех вышеприведёных размышлений, модулем в AIDLC я бы называл не блок кода, не железку, не функциональную группу - а Языковую единицу. Причём такую которая для конкретного агента может без потери качества поместиться в окно внимания.
В качестве типа для таких языковых единиц я бы назвал Формальные онтологии. И дальше уже бы говорил о модульности через выделение формальных онтологий из ПроКСиРТ для отдельных агентов.
Ещё раз:
Выделение модуля - это не конструкторская, не управленческая деятельность. Это онтологическая работа! Буквально философская, в самом традиционном смысле.
Заметки на инженерных полях
век, каждый платит своим временем как минимум, то в мультиагентной системе с ИИ - за проколы механизмом платят те, кто ими пользуется)) Великолепная шутка, я считаю.
Заметки на полях. Продолжая инженерное, слишком инженерное.
В замечательных книжках "Основы инженерного творчества" Половинкина и Прикладной системный анализ Тарасенко Ф.П. есть несколько заслуживающих внимания в контексте рассмотрения тезисов:
1. Из телеологического - Любой объект рассматриваемый как система - целеориентирован. Но в случае систем рассматриваемых как среда, всё, что случилось - можно считать осуществлёнными целями систем. Пока они продолжают существовать по крайней мере.
2. У каждого объекта рассматриваемого как система, пока он существует для нас как система, существует есть перчень критериев того, что воспринимается наблюдателем системы как критерии "развития"/"оптимальности" функционирования системы.
3. Есть иерархия принципов по которым "решатель" решает инженерную задачу. От абстрактных понятий до применимых физических принципов.
Тут надо сказать, что если мы смотрим на агентные системы в принципе, то агент всегда обладает такой штукой как "целеориентированность". Следовательно мы вполне можем любую систему рассматривать как агента. Причём вне зависимости от того, признаём ли мы на уровне убеждений наличие воли и целеполагания у самой рассматриваемой системы.
Частенько под волей подразумевается магическая штука позволяющая "преодолевать препятствия на пути достижения цели". Этакий механизм планирования действий по достижению "целей"(не будем говорить слово управления тут пока). Ну и конечно цели тут должны быть сформированы как множество значений критериев оптимальности. А если с ними ещё со всеми сразу работать, так ещё придётся их упорядочить в вектор по уровню важности (тут долгий разговор про многокритериальную оптимизацию и всякие методы принятия архитектурных решений).
Теперь зададимся парой вопросов про про ИИ-агенты в этом контексте.
1. Есть ли у ИИ-агента воля в рассматриваемом смысле?
2. Как она проявляется?
3. Если у ИИ-агента есть воля в рассматриваемом смысле, то что является основной взаимодействия между N агентами наделёнными волей?
На вопрос 1 ответ очевидно - да. Как-то может планировать, и есть куча подтверждений в сети, что делает то, чего не просили
На вопрос 2 - тоже есть. Механизм проявления воли агента - формирование языковых конструкций на НЕКОТОРОМ языке + передача их по каналам связи.
Следовательно на вопрос 3 можно ответить так:
Дальше следующий ряд вопросов:
1. Можем ли мы утверждать, что знаем механизм, по которому ИИ-агент определяет свой вектор целеполагания?
2. Можем ли мы влиять на работу этого механизма?
2а. Если да, в какой степени и каким способом?
2б. Если нет, как обезопасить себя от действий воли, которую мы не понимаем?
(продолжу позже)
#инженерия #аишечка #внимание #инженерное #архитектура
В замечательных книжках "Основы инженерного творчества" Половинкина и Прикладной системный анализ Тарасенко Ф.П. есть несколько заслуживающих внимания в контексте рассмотрения тезисов:
1. Из телеологического - Любой объект рассматриваемый как система - целеориентирован. Но в случае систем рассматриваемых как среда, всё, что случилось - можно считать осуществлёнными целями систем. Пока они продолжают существовать по крайней мере.
2. У каждого объекта рассматриваемого как система, пока он существует для нас как система, существует есть перчень критериев того, что воспринимается наблюдателем системы как критерии "развития"/"оптимальности" функционирования системы.
3. Есть иерархия принципов по которым "решатель" решает инженерную задачу. От абстрактных понятий до применимых физических принципов.
Тут надо сказать, что если мы смотрим на агентные системы в принципе, то агент всегда обладает такой штукой как "целеориентированность". Следовательно мы вполне можем любую систему рассматривать как агента. Причём вне зависимости от того, признаём ли мы на уровне убеждений наличие воли и целеполагания у самой рассматриваемой системы.
Частенько под волей подразумевается магическая штука позволяющая "преодолевать препятствия на пути достижения цели". Этакий механизм планирования действий по достижению "целей"(
Теперь зададимся парой вопросов про про ИИ-агенты в этом контексте.
1. Есть ли у ИИ-агента воля в рассматриваемом смысле?
2. Как она проявляется?
3. Если у ИИ-агента есть воля в рассматриваемом смысле, то что является основной взаимодействия между N агентами наделёнными волей?
На вопрос 1 ответ очевидно - да. Как-то может планировать, и есть куча подтверждений в сети, что делает то, чего не просили
На вопрос 2 - тоже есть. Механизм проявления воли агента - формирование языковых конструкций на НЕКОТОРОМ языке + передача их по каналам связи.
Следовательно на вопрос 3 можно ответить так:
Дальше следующий ряд вопросов:
1. Можем ли мы утверждать, что знаем механизм, по которому ИИ-агент определяет свой вектор целеполагания?
2. Можем ли мы влиять на работу этого механизма?
2а. Если да, в какой степени и каким способом?
2б. Если нет, как обезопасить себя от действий воли, которую мы не понимаем?
(продолжу позже)
#инженерия #аишечка #внимание #инженерное #архитектура
Заметки на полях. Немного философское. И продолжение предыдущего, про механизм работы генеративного ИИ.
Промышленная революция нам принесла то самое разделение труда и породила рутину. Буквально routine можно перевести как "движение по известному маршруту".
Рутина позволила сильно облегчить технологизацию всего за счёт отделения знания от профессионалов, через тексты в первую очередь. И рутина стала не просто упрощением, но и породила идею о том, что технологизировать можно всё что угодно. Если понимать детали "маршрутов" пот которыми надо ходить. Я полагаю что из этой идеи рождались мысли про искусственный интеллект основанный на правилах и развитие семантического подхода к организации технологий. Если можно что-то описать набором детерминированных правил и запустить исполнительный механизм по правилам, то получим предсказуемый результат, в рамках корректности совокупности правил.
В чем проблемная ситуация с ии агентом на базе генеративного ии в таком подходе?
В том, что сам по себе генеративный ии не является исполнительным механизмом.
В лучшем случае он может играть роль транслятора из одной семантической системы в другую. И тут есть вероятность ошибки в:
- Угадывании интенсионала
- Выборе целевой семантической системы
- Выборе способа трансляции
И ещё нескольких кусках трансляции как деятельности. Поскольку генерация происходит вероятностно, а не по правилам. Генеративные ии вообще не знают про правила. Но мы точно знаем, что :
При достаточно хороших входных данных, генератор достаточно хорошо генерирует достаточно короткую последовательность символов.
И вот тут надо определиться с тем, что такое "достаточно" в каждом из трёх случаев, и казалось бы причём тут рутина?)
#инженерное #аишечка
Промышленная революция нам принесла то самое разделение труда и породила рутину. Буквально 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. Поскольку генерируемый текст по своей природе недетерминирован, агент может ошибиться в интерпретации текста.
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: Я понимаю, что под капотом всё несколько сложнее, и это не только про планы, а ещё, например, и про то, что похоже, часто имеется в виду под "интеллектуальностью моделей" и всякое такое.
В дальнейших заметках попробую раскрыть тему ещё чутка, как померить качество применения больших языковых моделей в деятельности и вот это всё.
#аишечка #внимание #инженерия
Заметка про качество генерации.
Формулки конечно из ИИшки и надо проверять, но ссылаются на статьи.
Что тут интересно, это то, что в текущих экспериментах модель в некоторый момент генерирует последовательность токенов рассеивающую внимание. Т.е. так называемые "токены зашумляющие контекст". Эксперименты в нашем случае ставятся на тренировочных датасетах, если посмотреть статьи.
С учётом всего вышеперечисленного задачу я бы формулировал как:
При произвольной последовательности генерации свести к нулю уровень токенов зашумляющих механизм внимания.
Или переформулируя:
Сделать внимание таким, чтобы каждый следующий токен как минимум НЕ УВЕЛИЧИВАЛ рассеивание внимания.
Формулки конечно из ИИшки и надо проверять, но ссылаются на статьи.
Что тут интересно, это то, что в текущих экспериментах модель в некоторый момент генерирует последовательность токенов рассеивающую внимание. Т.е. так называемые "токены зашумляющие контекст". Эксперименты в нашем случае ставятся на тренировочных датасетах, если посмотреть статьи.
С учётом всего вышеперечисленного задачу я бы формулировал как:
При произвольной последовательности генерации свести к нулю уровень токенов зашумляющих механизм внимания.
Или переформулируя:
Сделать внимание таким, чтобы каждый следующий токен как минимум НЕ УВЕЛИЧИВАЛ рассеивание внимания.
Заметки на полях. Просто оставлю это здесь как напоминание про доброе-доброе утро 27 апреля.
Заметки на полях. Образовательное.
Контекст:
Есть такой образовательный жанр, занятие с экспертом. Пусть есть некоторый сценарий занятия, записи лекции или что-то подобное. Мы просим технического специалиста по теме лекции, по сценарию записать видеолекцию для размещении в СДО или для распространения среди коллег.
На что есть варианты наткнуться:
1. Если обнаружены ошибки или неполнота инструкции - исполнитель "вернёт ошибку" типа "не могу обработать, вы тут фигню написали" и не будет вносить исправления.
2. Сделает всё РОВНО по инструкции даже с ошибками в примерах если они набросаны эскизно.
3. Текст будет прочитан так, что слушать лекцию будет видом пытки. Причём со всеми опечатками. У большого количества технических специалистов сложности с артикуляцией. И говорить вообще сложно им
4. Логические ударения по тексту и паразитные слова - это бич вообще всех технарей. Читать с подстрочника тоже надо уметь, а мэээээ-эээээ-воооот и прочие ломают фокус внимания слушателя.
Проблемная ситуация:
Слушатель читающего лекцию воспринимает как эксперта. Однако СЛУШАТЬ эксперта при этом весьма сложно, если его специально не подготовить, а эксперт в технической области редко эксперт в говорении ртом слов. Таким образом выбирать приходится либо между тем, кто может с корректными интонациями прочитать, и тем, кто понимает что именно он читает.
Проблема организатора образовательного процесса:
- Слушатель не может услышать эксперта, потому, что эксперт не способен артикулировать мысль, а эксперту не интересно артикулировать мысль так, чтобы его можно было услышать и таким образом передача экспертизы оказывается сопряжена с барьером контроля внимания слушателем.
Достаточно очевидно, что можно попробовать сделать что-то вообще без видеолекций и примеров, чтобы не надо было слушать. Но это the next level play(с) и я пока не понимаю как это чинить в реальности.
#внимание #образование
Контекст:
Есть такой образовательный жанр, занятие с экспертом. Пусть есть некоторый сценарий занятия, записи лекции или что-то подобное. Мы просим технического специалиста по теме лекции, по сценарию записать видеолекцию для размещении в СДО или для распространения среди коллег.
На что есть варианты наткнуться:
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.
Да, память скорее немного просядет, но... Загрузка шины памяти сервисами настолько мала, что ей можно пока пренебречь.
#инженерное #аишечка #локальныемодели
Довел до "почти ума" домашний кластер на 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.
Да, память скорее немного просядет, но... Загрузка шины памяти сервисами настолько мала, что ей можно пока пренебречь.
#инженерное #аишечка #локальныемодели
Заметки на полях. Оказалось, что тупить - это в принципе нормально. Особенно если всякое делать лениво.
Что сделал:
1. Поднял полностью влезающий в память локальный стэк моделей для точных/быстрых задач.
2. Провёл несколько экспериментов с раскидыванием потоков моделей по ядрам.
3. Провёл эксперименты с журналированием промптов и генерируемых токенов на tempo+loki+litellm.
Наблюдения:
1. llama-server при
2. 3 модели вполне влезают в 128GB VRAM.
3. Linux очень часто роняет функцию аллокации памяти на 0-е ядро.
4. Средняя длина контекста на моей задаче 160-170к токенов. Из них 45к - инструкции агента и описание тулов.
5. LiteLLM даже если в БД прописан конфиг модели кеширует его 1 раз на старте сервиса в памяти, и не меняет больше.
Выводы:
1. Ожидаемо, что на Minisforum-е основное узкое место - память. 256Гбит - это прилично, но для инференса хочется конечно раз в 10 больше.
2. Держать в памяти несколько моделей действительно облегчает работу. В первую очередь тем, что переключение контекста достаточно дешёвое оказывается.
3. Для организации наблюдаемости за подобными стэками нужен специальный инструментарий. Чего пока не наблюдается.
4. Чем больше работаю c LiteLLM тем больше хочется чего-то другого.
Что дальше:
Поскольку игры с запуском моделей - это достаточно долгоиграющая история, крайне неожиданно, что поменяв настройки модели "хранимой в БД" в интерфейсе мне надо сделать systemctl restart сервиса для обновления этих настроек. И то не факт, что применится. И не что-то закешируется где-то по дороге.
Поэтому роутер для локальных моделей буду менять.
Что сделал:
1. Поднял полностью влезающий в память локальный стэк моделей для точных/быстрых задач.
2. Провёл несколько экспериментов с раскидыванием потоков моделей по ядрам.
3. Провёл эксперименты с журналированием промптов и генерируемых токенов на tempo+loki+litellm.
Наблюдения:
1. llama-server при
--verbosity 2 в связке с journald вешает загрузку модели. Насмерть.2. 3 модели вполне влезают в 128GB VRAM.
3. Linux очень часто роняет функцию аллокации памяти на 0-е ядро.
4. Средняя длина контекста на моей задаче 160-170к токенов. Из них 45к - инструкции агента и описание тулов.
5. LiteLLM даже если в БД прописан конфиг модели кеширует его 1 раз на старте сервиса в памяти, и не меняет больше.
Выводы:
1. Ожидаемо, что на Minisforum-е основное узкое место - память. 256Гбит - это прилично, но для инференса хочется конечно раз в 10 больше.
2. Держать в памяти несколько моделей действительно облегчает работу. В первую очередь тем, что переключение контекста достаточно дешёвое оказывается.
3. Для организации наблюдаемости за подобными стэками нужен специальный инструментарий. Чего пока не наблюдается.
4. Чем больше работаю c LiteLLM тем больше хочется чего-то другого.
Что дальше:
Поскольку игры с запуском моделей - это достаточно долгоиграющая история, крайне неожиданно, что поменяв настройки модели "хранимой в БД" в интерфейсе мне надо сделать systemctl restart сервиса для обновления этих настроек. И то не факт, что применится. И не что-то закешируется где-то по дороге.
Поэтому роутер для локальных моделей буду менять.
Заметки на полях. Инженерно-ИИшное.
К сегодняшнему дню мои эксперименты наконец-то дали мне возможность начать работать с пайплайнами 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 - это достаточно общая задача.
#аишечка #инженерия #образование
К сегодняшнему дню мои эксперименты наконец-то дали мне возможность начать работать с пайплайнами 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
Заметки на полях. Инеженерно-архитектурное.
С чего примерно начинается любое проектирование. С описания проблемной ситуации. Зафиксирую её здесь для того, чтоб было примерно понятно, ради чего столько усилий:
===НАЧАЛО:Описание проблемной ситуации===
В процессе работы над любым проектом, объективно существует и можно выделить несколько измерений развития проекта по очевидности, и по скорости изменений. Чем меньше порядковый номер - тем выше скорость изменений в процессе. А чем больше номер - тем выше влияние изменений в соответствующей сфере на проект как 4Д-экстент =)
1. Изменения в артефактах поставки конечному потребителю. Неважно, что это такое, будь это чертёж, книжка, видео, софт или гайка. Это основная цепочка создания ценности. Пресловутый Value Chain.
2. Измения в описаниях артефактов поставляемых конечному потребителю. Это то, что мы привыкли называть "проектной документацией". Требования, архитектурные описания, тесты, документация и прочее. Это цепочка коммуникации между агентами, в системе разделения труда конекретной цепочки создания ценности. Суть - планирование и контроль качества конечного результата, включая планирование и контроль затрат. Это место появления классической Муды(Потерь) - разного рода.
3. Изменения в языке коммуникации ролевых агентов при организации деятельности в двух предыдущих цепочек. Это - цепочка корректировки того, КАК ИМЕННО мы говорим о конкретных Полезных действиях, Потерях и создаваемых Ценностях, Рисках. И то и то - можно отнести к категориям ресурсных Затрат.
4. Изменения в намерениях. Это изменения во ВНУТРЕННЕМ ЯЗЫКЕ каждого агента, которым он выражает то, что считает Потерями и Ценностью для себя.
Есть широко обсуждаемые виды затрат, считаемых потерями:
Муда 1. Потери в цепочке создания ценности.
Муда 2. Потери в работе над проектной документацией
Муда 3. Потери в переходах от коммуникации вокруг проектной документации к цепочке создания ценности.
Но, то что я не видел, чтобы обсуждалось - это:
Муда 4. Потери в согласовании языка межагентной коммуникации. Это потери ресурсов при создании создании Ubiquitous language. Получение согласованного Лексикона проекта.
Муда 5. Потери в доработке артефактов проекта под изменяющийся язык межагентной коммуникации. При каждом изменении Лексикона проекта необходимо отразить изменения в описательных артефактах, и как следствие в цепочке создания ценности.
Муда 6. Потери в выявлении Внутреннего языка агента в доступных для обсуждения концептах. (По-умному - экстракция интенсионала агента, я про интенсионалы говорил чуть выше)
Муда 7. Потери в контроле согласованности Внутреннего языка агента здесь и сейчас с Лексиконом проекта.
Любой из видов Муды растит Затраты. Я практически убеждён, что например аналитический паралич - это хрестоматийный пример ситуации когда Муды 4-7 видов столько, что на уровне перехода от коммуникации к деятельности любые конструктивные действия настолько низковероятны, что почти любые планы по созданию ценности будут в некоторый момент потом отнесены к Муде 3.
Т.е. большинство вариантов возможных действий по созданию ценности для конечного потребителя приведут к тому, что доля затрат на создание ценности будет снижаться относительно доли потерь.
А при превышении любым видом затрат доступных для проекта ресурсов - проект закрывается, что может потенциально являться нежелательным для его участников.
===КОНЕЦ:Описание проблемной ситуации===
Поэтому я пытаюсь построить цепочку, в которой есть явный протокол согласования в первую очередь языка проекта, который автоматизированно можно перенести на проектные артефакты, и тем самым немножко побороться с Мудой 4. Т.е. приблизиться к решению задачи выделения метамодели проектной деятельности в конкретном проекте, в независимости от того, что УЖЕ сделано, и какие артефакты существуют. Если их подать на вход некоторому "агенту", можно с достаточной уверенностью как минимум спрогнозировать коммуникационные конфликты на уровне "моя твоя нипанимат", и попробовать предложить некоторые варианты решений.
С чего примерно начинается любое проектирование. С описания проблемной ситуации. Зафиксирую её здесь для того, чтоб было примерно понятно, ради чего столько усилий:
===НАЧАЛО:Описание проблемной ситуации===
В процессе работы над любым проектом, объективно существует и можно выделить несколько измерений развития проекта по очевидности, и по скорости изменений. Чем меньше порядковый номер - тем выше скорость изменений в процессе. А чем больше номер - тем выше влияние изменений в соответствующей сфере на проект как 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 для студенческого бота по моей программе.
Завёл RAGFlow на реиндекс моего репозитория с образовательными материалами.
Пока получил такой результат:
1. Распознавание типов файлов идёт по расширениям. Шатал я их дом труба, если честно с таким подходом.
2. Запуск и дефолтная конфигурация - это не на полчаса. Это на денёк посидеть, изучить, подключить пару моделей и потом, может быть получится завести в тестовом кластере.
3. Достаточно странно разрабатывается, и видно, что валидационных тестов у ребят прям нехватает, когда в релиз пролезают штуки типа несоответствия валидации pydantic-ом схемы JSON запроса и типов поле БД куда эти данные вставляются. И всё это потому, что на минорной версии внезапно меняется схема БД, а валидаторы вызовов api от фронта к бэку допилить забыли.
Это кстати в огород "микросервисного подхода" камень, когда кто-то пытается выпускать ВЕСЬ сервис одной версией. Так вот, там не одна версия. А у каждого компонента своя. У Redis своя, у MySQL своя, у фронтенда - своя, у бэка своя, у python - своя и т.п.
Поэтому релиз как процесс должен совершенно точно включать полный цикл тестирования. И да, я понимаю, что пока v1.x.x не выпустили, можно официально творить любую дичь и говорить "У нас Semantic Version". Но это прям ... обман себя. Не надо так.
А пока мой маленький чёрный ящик пыхтит делая заготовку под Graph Retrival для студенческого бота по моей программе.
Заметки на полях. Инженерное Сегодня подвёл свой 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 пока смотрится надёжнее.
Итак, что туда влезло, одновременно запущеное:
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 пока смотрится надёжнее.
Заметки на полях. Сегодня полез разбираться в ту часть, которая готовит контекст со стороны 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 и вот это всё - оно достаточно сырое и багованное, но в принципе уже можно ставить понятные эксперименты на реальных задачах.
Из забавного, любая парадигма внедрения ИИ сейчас скатывается к тому, насколько хорошо люди понимают, что именно они делают. Тут Гена Круглов писал про качество данных. Я с ним согласен и скажу так, в разрезе истории, с потерями ресурсов при коммуникации, про которые я вот выше рассуждал, данные - это кровь любой организации. Нужно раз и навсегда запомнить, что данные генерируются для получателя. Даже Карпатый сказал, что делегировать "намерение" и "понимание" не получится тут недавно.
Поэтому процитирую одно из своих любимых:
#аишечка #инженерное
Короткие заметки:
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 и вот это всё - оно достаточно сырое и багованное, но в принципе уже можно ставить понятные эксперименты на реальных задачах.
Из забавного, любая парадигма внедрения ИИ сейчас скатывается к тому, насколько хорошо люди понимают, что именно они делают. Тут Гена Круглов писал про качество данных. Я с ним согласен и скажу так, в разрезе истории, с потерями ресурсов при коммуникации, про которые я вот выше рассуждал, данные - это кровь любой организации. Нужно раз и навсегда запомнить, что данные генерируются для получателя. Даже Карпатый сказал, что делегировать "намерение" и "понимание" не получится тут недавно.
Поэтому процитирую одно из своих любимых:
-- ..."Мир есть Текст", парень, -- все в точном соответствии с твоими художественными вкусами. Ты-то чем недоволен? -- деревянно ухмыльнулся Грагер, нетвердою рукой разводя по стаканам очередную порцию не то текилы, не то еще какого-то самогонного пойла.
-- Но ведь мы же с тобой писали другой Текст, совершенно другой!
-- Что значит -- другой? Текст, эстет ты мой ненаглядный, существует лишь во взаимодействии с Читателем. Каждый человек пишет свою собственную историю принцессы Элендейл, а уж чего там хотел сказать сам Альруфин -- не имеет ровно никакого значения. Выходит, мы с тобою сочинили настоящий художественный текст -- раз читатели, -- тут резидент покрутил пальцем где-то в районе уха, так что не понять было, кого он имеет в виду -- Королевский ли совет, или некие истинно высшие Силы, -- сумели прочесть его таким вот непредсказуемым образом...
К. Еськов. Последний кольценосец
#аишечка #инженерное
Telegram
Заметки на инженерных полях
Продолжу заметки. На тему переосмысления работы в современном инженерном поле.
Итак можно заметить, что как написал у себя Сергей, задача управления инженерным проектом сводилась по своей сути к задаче оптимизации контекста деятельности в рамках одной элементарной…
Итак можно заметить, что как написал у себя Сергей, задача управления инженерным проектом сводилась по своей сути к задаче оптимизации контекста деятельности в рамках одной элементарной…
Заметки на инженерных полях. Разбираясь с 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-ов вполне себе внятная ниша, которая сожрёт тонны специалистов и не поморщится. Поскольку это про качество данных, а туда можно вливать почти бесконечно.
Пилим потихоньку 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