Я не отказываюсь от MCP, как такового, наоборот в статье я и выделяю эти два уровня (4 и 5) взаимодействия.
Для меня это не замена одного на другое, а скорее как разный уровень под разный тип контроля и задачи.
Если нужна гибкость и возможность подключать разные инструменты через единый стандарт, то MCP действительно очень удобен и можно остаться на уровне 4.
Если же нужно ограничить выбор модели для конечного пользователя (выбор flow, MCP и тп) то удобнее спрятать это под капотом и отдать одного агента, как в уровне 5.
Поэтому тут важнее задать вопрос — кто выступает оркестратором и какая конечная цель
А с минусом 5 уровня полностью согласен, когда внутри слишком много флоу и развилок, то вариант с mcp выглядит куда приятнее для масштабирования
Как и говорил выше - тут все зависит от самой модели, которую решите использовать (там есть полезные ссылки на калькуляторы). Сами же инструменты не сильно требовательные
Хочу сразу уточнить, что я в статье в основном пишу не про мультиагентность, как таковую, а про агентность как оркестрацию инструментов и про то какие задачи можно закрыть на каждом из описанных уровней Во многих реальных сценариях действительно достаточно остановиться на 2–3 уровне.
Да, согласен, что хайпа вокруг агентов сейчас больше, чем практической пользы, и «алгоритмизуемое — скриптом» полностью поддерживаю. Поэтому в самой статья я прописываю, что критичное делается кодом, а уже LLM остается неким слоем оркестрации и для оформления результата (запустить шаги, протащить параметры, собрать результаты и выдать их в понятной форме).
Из реальной практики, как аналитика, могу рассказать за такой практический кейс, как работа с ролевой моделью (матрицы доступов). Что делается: найти выгрузки, прогнать большие xlsx анализатором, подсветить ошибки/опечатки, предложить исправления строго по правилам, а на выходе получить дельту и дальше, если ок, то сформировать задачу в Jira и подготовить текст с SQL по заложенному шаблону (с валидацией) для уже дальнейщей вставики в письмо.
Да, это можно сделать руками или отдельными скриптами. Да и саму связку сделать уже не так сложно, но тут болшая ценность сделать такой флоу воспроизводимым, когда один вход, одинаковые шаги и одинаковый результат + его можно запускать регулярно и разными людьми, тогда и снижаются ручные ошибки и время на рутину
2 - тут MongoDB используется именно для Librechat, а уже sqllite используется для Langflow (для хранения флоу и тп)
3 - да, верный момент, папки должны лежать рядом с docker-compose.yml. Я показал это в структуре проекта в начале, но действительно лучше отдельной строкой
А это уже интересный подход! Вот теперь интересно посмотреть в сравнении, насколько точность падает от ускорения? Думаю, что в сложных участках разница будет существенна
Отличный подход, спасибо, что поделились своим опытом!) 👍
Для борьбы с галюцинациями стараюсь выставлять 0 температуру.
А с большими аудио пока выхода не нашёл другого варианта, кроме как нарезка на сегменты. Правда, у меня такие длинные записи попадаются нечасто, поэтому это не критично.
По поводу WhisperCPP, интересно посмотреть, спасибо!
Да, с телеграм ботом идея рабочая, особенно если нужна мобильность, но тогда теряется приватность (всё равно в цепочке передачи). И верно подметили с ограничениями по объёму
Про local bot api тоже согласен, оперативки он ест прилично. Вариант с внешним загрузчиком выглядит, как разумный компромисс, если данные не сверхсекретные. Я так понимаю, что тут важно где именно хостится этот загрузчик и как долго там хранятся файлы
Но тут уже каждый подбирает под свои приоритеты: либо удобство, либо полная автономия и приватность
Каждый подбирает под свои задачи и железо, можно сказать, надо найти золотую середину между скоростью и качеством. Главное, чтобы результат устраивал 🙌
@distract
Спасибо за обратную связь!
Я не отказываюсь от MCP, как такового, наоборот в статье я и выделяю эти два уровня (4 и 5) взаимодействия.
Для меня это не замена одного на другое, а скорее как разный уровень под разный тип контроля и задачи.
Если нужна гибкость и возможность подключать разные инструменты через единый стандарт, то MCP действительно очень удобен и можно остаться на уровне 4.
Если же нужно ограничить выбор модели для конечного пользователя (выбор flow, MCP и тп) то удобнее спрятать это под капотом и отдать одного агента, как в уровне 5.
Поэтому тут важнее задать вопрос — кто выступает оркестратором и какая конечная цель
А с минусом 5 уровня полностью согласен, когда внутри слишком много флоу и развилок, то вариант с mcp выглядит куда приятнее для масштабирования
Спасибо за обратную.связь!
Как и говорил выше - тут все зависит от самой модели, которую решите использовать (там есть полезные ссылки на калькуляторы). Сами же инструменты не сильно требовательные
Минимум для такой сборки - это 16 ГБ RAM
Спасибо, рад, что статья понравилась)
Да, именно Ollama не обязателен, тут можно использовать любой другой, в том числе напрямую llama.cpp
Спасибо, что поделились мнением!
Хочу сразу уточнить, что я в статье в основном пишу не про мультиагентность, как таковую, а про агентность как оркестрацию инструментов и про то какие задачи можно закрыть на каждом из описанных уровней
Во многих реальных сценариях действительно достаточно остановиться на 2–3 уровне.
Да, согласен, что хайпа вокруг агентов сейчас больше, чем практической пользы, и «алгоритмизуемое — скриптом» полностью поддерживаю. Поэтому в самой статья я прописываю, что критичное делается кодом, а уже LLM остается неким слоем оркестрации и для оформления результата (запустить шаги, протащить параметры, собрать результаты и выдать их в понятной форме).
Из реальной практики, как аналитика, могу рассказать за такой практический кейс, как работа с ролевой моделью (матрицы доступов). Что делается: найти выгрузки, прогнать большие xlsx анализатором, подсветить ошибки/опечатки, предложить исправления строго по правилам, а на выходе получить дельту и дальше, если ок, то сформировать задачу в Jira и подготовить текст с SQL по заложенному шаблону (с валидацией) для уже дальнейщей вставики в письмо.
Да, это можно сделать руками или отдельными скриптами. Да и саму связку сделать уже не так сложно, но тут болшая ценность сделать такой флоу воспроизводимым, когда один вход, одинаковые шаги и одинаковый результат + его можно запускать регулярно и разными людьми, тогда и снижаются ручные ошибки и время на рутину
Спасибо!
Да, можно пробовать, тут вся тяжесть определяется выбранной моделью. LibreChat и Langflow сами по себе относительно лёгкие.
Есть удобные калькуляторы, чтобы прикинуть, какая модель влезет в ресурсы:
https://apxml.com/tools/vram-calculatorhttps://github.com/TechNavii/LLM-Memory-CalculatorДля ноута без дискретной видеокарты и если брать модель уровня Llama 3.2 3B, то обычно достаточно 16 ГБ RAM.
Спасибо за обратную связь)
Спасибо большое)
1 - да, хороший поинт, думаю, это стоит добавить)
2 - тут MongoDB используется именно для Librechat, а уже sqllite используется для Langflow (для хранения флоу и тп)
3 - да, верный момент, папки должны лежать рядом с docker-compose.yml. Я показал это в структуре проекта в начале, но действительно лучше отдельной строкой
А это уже интересный подход!
Вот теперь интересно посмотреть в сравнении, насколько точность падает от ускорения? Думаю, что в сложных участках разница будет существенна
Спасибо, что поделились! 🔥
Надо будет обязательно попробовать!)
Отличный подход, спасибо, что поделились своим опытом!) 👍
Для борьбы с галюцинациями стараюсь выставлять 0 температуру.
А с большими аудио пока выхода не нашёл другого варианта, кроме как нарезка на сегменты. Правда, у меня такие длинные записи попадаются нечасто, поэтому это не критично.
По поводу WhisperCPP, интересно посмотреть, спасибо!
Спасибо, рад, что статья понравилась!) 🙌
Спасибо за сайт, возьму на заметку 🙌
Сейчас посмотрел, действительно, у меня Gemma 27B Q4_K_M работает не через GPU, а полностью на CPU
@pavelshaТак что написал неточно: 12 ГБ видеопамяти действительно недостаточно, даже для квантизованной версии
@Akr0nСпасибо за уточнение!
Если речь о полноценном виде, то нет
Использую квантизированную версию - Q4_K_M
💯Как раз у себя описал, как можно сделатьДобрый день, Вадим! Я живой системный аналитик, как и вы, но, возможно, мы в целом все в матрице, кто знает...
Да, с телеграм ботом идея рабочая, особенно если нужна мобильность, но тогда теряется приватность (всё равно в цепочке передачи). И верно подметили с ограничениями по объёму
Про local bot api тоже согласен, оперативки он ест прилично. Вариант с внешним загрузчиком выглядит, как разумный компромисс, если данные не сверхсекретные. Я так понимаю, что тут важно где именно хостится этот загрузчик и как долго там хранятся файлы
Но тут уже каждый подбирает под свои приоритеты: либо удобство, либо полная автономия и приватность
Круто, хороший вариант!)
Каждый подбирает под свои задачи и железо, можно сказать, надо найти золотую середину между скоростью и качеством. Главное, чтобы результат устраивал 🙌
С русским языком хорошо справляется)
Да, я вот тут описал свой опыт https://habr.com/ru/companies/alfa/articles/909498/
Отличная работа! 🙌
Было интересно почитать, редко встретишь такой подробный и одновременно доступный разбор под капотом библиотеки.
Было бы еще круто в будущем увидеть продолжение, например, сравнение Robolectric с другими подходами к UI‑тестам)
Спасибо за статью - сохранил в избранное!