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

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

Исходим из того, что :

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

Тогда :

1. "Пертинентность" получаемого результата P - величина вероятностная. Если результат r генерации на 100% покрывает некоторым образом Интенсионал клиента P(r,I) = 1 - d - e, где d - погрешность интерпретации исполнительного механизма, а e - ошибка генерации относительно реальности.
2. Интенсионал выразим семантической системой. Причём выразим не как вопрос, а как совокупность утверждений в рамках логики 1-го порядка описывающий результат деятельности. Качественно или количественно. I = (<O,S,P>) - т.е. интенсионал это множество триплетов "Объект-Субъект-Предикат"

В итоге для того, чтобы получать качественную генерацию нам необходимо:

1. Снижать ошибку генерации: e
2. Снижать ошибку интерпретации результата: d

Вопрос 1: Какая практика направлена на снижение ошибки генерации относительно реальности? Их несколько: промпт/контекст/дата инженерия. Вот это всё.

Вопрос 2: Какая практика направлена на снижение ошибки интерпретации? Правильно! Согласование семантических систем генератора плана, и интерпретатора плана. Об этом достаточно давно говорил Женя Истомин на беседах, на наших кружках по ИИ в МИРЭА. Что для любых двух агентов самая дорогая задача - это поддержание согласованности семантических систем. Т.е. способности пертинентно интерпретировать высказывания друг-друга. Например именно поэтому в агентах разрабатывающих ПО разделены планирование и разработка. А ещё есть режим Чат.

PS: Я понимаю, что под капотом всё несколько сложнее, и это не только про планы, а ещё, например, и про то, что похоже, часто имеется в виду под "интеллектуальностью моделей" и всякое такое.

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

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

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

Контекст:

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

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

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

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

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

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

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

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

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

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

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

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

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


Наблюдения:

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

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

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

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

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

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

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

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

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

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

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

Ragflow :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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