Comments 41
Если коротко — главная мысль статьи была не про “ещё одного AI-агента”.
Сейчас индустрия в основном идёт через scale: больше моделей, больше GPU, больше orchestration. А мне стало интересно обратное направление, можно ли получить более полезную и предсказуемую систему не за счёт роста мощности, а за счёт архитектуры.
Отсюда и появился deterministic-first подход: пусть LLM делает то, где он реально хорош (classification/fallback), а всё остальное остаётся простой и проверяемой системой.
И было приятно увидеть в комментариях людей, которые тоже пришли к похожим выводам в своих проектах :)
Сейчас вся AI-индустрия движется в сторону...
по-моему нет какого-то монолитного движения. Есть облачные агенты для трудоёмких задач. Для агентов уровня "подай-принеси", в противовес, создаются инструменты для разработки своих решений.
Вот, к примеру, свежая статья про свежий, относительно лёгкий, агентский фреймфорк https://devblogs.microsoft.com/dotnet/durable-workflows-in-microsoft-agent-framework/ (я на этом https://github.com/microsoft/agent-framework делал своего "ассистента" для pRI 3b с той же sqlite и телеграммом для интерфейса - работает шустро и стабильно).
Понять бы только, почему все это не завернуть на хелсчеки и не рестартить юнитом. Вместо того чтобы быть обслуживающим персоналом для своей железки. Бонусом отпадает потребность в llm
А что за прикол с английскими словами в тексте? Это не какие-то термины, не названия, а просто отдельные слова и понятия на английском.
Это модель, подготовившая статью, плохо знает русский? Или специально сделано?
ИИ контент (пускай так вот обработанный) уже… надоел)) Мне вот тоже непонятно, имея Docker/Systemd почему вообще что-то нужно постоянно перезагружать? Я ничего у себя нигде не перезагружаю и все работает. Иногда текстом состояние в телеграм - это наверно удобнее чем Grafana, когда не у компа или в поездке, но в остальном непонятно зачем это всё
Согласен. Начал читать статью и не понял прикладного смысла этой системы. Почему докер упал и его нужно перезагрузить вручную? Почему посыпались ошибки чего-то там, но автор просто их поставил в игнор? Может не такие уж и важные эти уведомления и нет смысла в магазине на них отвлекаться. Кажется, здесь вместо того, чтобы настроить нормально сервера и системы, автор делает автоматизацию (ради автоматизации).
По стилю похоже на одну из последних ChatGPT. Он тоже в строгом режиме пишет сухую инфу, опуская контекст. Ну и списки. Бооольше списков!
ChatGPT русский хорошо знает, это такой-то китаец, спасибо что без иероглифов :)
опуская контекст
Просто ии тоже не понял зачем все это нужно :)
Русский-то хорошо знает, но англицизмами любит всё усеивать, есть такое, подтверждаю.
ИИ пишет статью о том, как ИИ придумал то, как использовать ИИ там, где ИИ не нужен...
Когда уже хабр введет плашку, как в стиме, "этот бред сгенерирован ИИ, потому что у автора не хватило ума написать что-то оригинальное, да и писать было не о чем, потому что сам автор ничего толком не сделал"?
> Telegram: "что там с системой" → Hostname, CPU, Memory, Disk, Uptime, Temperature, всё в одном коротком ответе.
Скриншот выше, тот же самый skill
/status, но без LLM-вызова: русская фраза детерминированно нормализовалась.
Можно пояснить, как именно безо всяких LLM чисто детерминировано из "что там с системой" система поняла, что от нее требуется?
Это же не "заученная фраза"? на "система в норме?" или "состояние системы?" такой же ответ был бы безо всяких LLM? Но и не просто по вхождению "систем", разумеется.
Все таки, я не понял, зачем держать и Raspberry Pi, и mac mini. Какие у кого из них задачи?
Никогда не стал бы ставить криптокошельки на смартфон. Потому что доверия телефону - околоноль
Никогда не стал бы заходить на свои серверы со смартфона, по той же причине.
Автор - васян локалхоста (убунтуй ещё небось). И то что у него что-то постоянно валится и требует перезагрузки - 100%ный пруф.
лучше б админские скиллы покачал, а не слоп генерил
Ещё бы понять из статьи, зачем все так сложно...
васян локалхоста (убунтуй ещё небось).
Ну у меня убунта на 3 локалхостах (два из них арм64), плюс еще дебиан на одном (и хочу его тоже мигрировать). Вы что-то имеете против убунты?
> что-то имеете против убунты?
убунта - четкий признак ламера, вот и всё. у неё нет ниши. для сервера никуда не годится по сравнению с rhel-клонами, для десктопа тоже есть намного лучше и очень разные варианты.
убунта - четкий признак ламера
Как-то аж ЛОРом образца конца 00-х пахнуло.
для сервера никуда не годится по сравнению с rhel-клонами
И вы можете это как-то обосновать, верно?
по всем тезисам можешь сходить в gpt, доходчиво объяснит, прям страницами примеров:
-apt убожество (vs dnf)
-apparmor убожество (vs selinux)
-пропихивают snap и прочее гуано
-ядерная экспертиза у rhel. debian - фофаны, убунтуи - пытаются из г сделать конфету, кривыми руками.
-мэйнтейнеры фофаны, бывают полностью нерабочие пакеты из коробки.
-слишком свежие ядра, апдейты ломучие
количество васян-говнопакетов - 100500, в то же время какой-нибудь openjdk (в rhel одновременно 8,11,21,25) - один гвоздями прибит. gcc и куча всего другого.
это если прям навскидку... много раз пытался держать серваки на дебианах - каждый раз выкидывал через месяц.
можешь сходить в gpt,
Ну да, конечно.
убожество
фофаны
О г-споди. Все с вами понятно. Возвращайтесь обратно на ЛОР, прошу.
много раз пытался держать серваки на дебианах
Может быть дело в руках? У меня уже более 15 лет на дебианах/убунтах успешно живет пачка серверов. Некоторое время назад вот несколько сотен нод на rhel-based появилось.
кстати, к заявлениям выше, добавлю: недавняя история с растовыми coreutils полностью характеризует убунтуев как фофанов-рукожопов. ты небось и не в курсе таких тонкостей.
>Ну у меня убунта на 3 локалхостах (два из них арм64), плюс еще дебиан на одном
>Некоторое время назад вот несколько сотен нод на rhel-based появилось.
на хабре ... не кули ворочать, по делу я выше написал, от тебя только псевдолюбезное хрю-му. арм64 надеюсь что-то типа ampere, а не васян-растберри.
для десктопа тоже есть намного лучше и очень разные варианты
Я - обычный пользователь Линукса. Убунта из-за популярности начинает привлекать проблемы. Пожалуйста - киньте пару-тройку названий, в какую сторону мне гуглить.
Знаете, я вот попробовал кучу всего из мира линуксов, даже совсем экзотику, точно больше 30 дистров. Что-то тыкал пару дней, что-то стояло основной системой от полугода до двух. И нативно, и в контейнерах, и на wsl. И знаете, после 8 лет дистрохопинга я остановился на kubuntu 25.10. Нарадоваться не могу стабильности, особенно после роллингового арча и винды. Для моего сценария использования лучше ничего не нашел. Я ставлю очень много всякого рода опенсорсни, многое приходится из сурсов собирать, плюс играю в игры и по работе есть ряд программ, требующих винды. Впервые за мою линуксятскую жизнь всё просто работает, а если нет - решение по первой ссылке, либо очевидно как его “натыкать мышкой” вообще без терминала.
Работать должно с разными мессенджерами, в России логичнее работать с ВК - также легко создаются чаты, сколько угодно, плюс работа в режиме белых списков. Зачем мне телеграмм, если мобильная связь фильтруется.
Если агент доступен через интернет, то и облачные модели тоже доступны, поэтому локальную модель можно не ставить, разве что для отладки - иногда нужно.
Модель не должна знать секреты. А если она их не знает, то можно и облачную.У меня тоже на трех компьютерах (кстати можно и на старый смартфон воткнуть, если модель облачная),
но я склоняюсь к мысли выделить 0.5 Г ОЗУ на удаленном серваке с фиксированным ip адресом. или сейчас узнал есть готовый бесплатный вариант - AnythingLLM , если я всё правильно понял.
Нейроуши в статье можно купировать. А вообще любопытно. Мой опыт с Gemma 4 линейкой субъективно - вообще не qwen ни разу, лучше в общих задачах. И про использование мелких скорее роутерами или copilot интерфейсом, оно само напрашивается и задумываешься. Уйти уже из болота regex, конфигов и прочего. Без разницы будет локальная работать сама или с оркестратором сверху.
Старое устройство или расширение вроде Raspberry Pi AI HAT+ 2 и это используется не 0.5B модель.
Мелких моделей будет становится больше в использовании, один Chrome как отжег ). А потом фреймворков для этого. Devops подход может трясти седыми волосами, но у него своя четкая ниша.
Паттерн deterministic-first с LLM как fallback, нашли то же самое с Claude Code, только на кодовой базе а не на роутере. Сначала пытались положиться на модель во всём, она раз за разом принимала «творческие» решения там где нужна строгость. Выход тот же: явные правила вперёд, LLM только туда куда правила не дотягиваются. У нас это CLAUDE.md с explicit запретами на уровне каждого модуля, ты реализовал то же самое в виде каскада slash-команды → regex → rule-based → semantic. Принцип идентичный. Вопрос: когда LLM ошибается и выбирает «почти правильный» tool, как это логируешь? Интересно есть ли паттерн в ошибках, который потом можно перенести в deterministic слой.
Да, очень похожий вывод в итоге получился.
Самые неприятные ошибки были не когда модель совсем ошибалась, а когда выбирала “почти правильный” tool. Поэтому со временем начал логировать:
запрос,
candidate group/tool,
confidence,
и execution path.
И да, постепенно часть таких кейсов просто переезжает выше в deterministic слой: aliases, semantic normalization, explicit parsing.
Получается забавный цикл: LLM помогает находить новые intent patterns, после чего сам становится не нужен для этих запросов
Также есть е2е тесты на каждый релиз, где поднимается реальная ллм 0.5b и пргоняется весь core функционал через cli версию
Мы до логирования confidence дошли примерно через месяц боли. Просто смотрели, модель ошиблась, и всё, непонятно было даже в какую сторону копать. Потом начали писать candidate scores и сразу стало видно что это не ошибка, а реально почти одинаковые веса у двух tools. Цикл да, у нас так же несколько кейсов буквально выкристаллизовались в explicit parsing, сначала в логах видишь что каждый раз одно и то же, потом просто хардкодишь. Какую 0.5b используете на е2е, Qwen?
Если коротко — главная мысль статьи была не про “ещё одного AI-агента”.
Сейчас индустрия в основном идёт через scale: больше моделей, больше GPU, больше orchestration. А мне стало интересно обратное направление, можно ли получить более полезную и предсказуемую систему не за счёт роста мощности, а за счёт архитектуры.
Отсюда и появился deterministic-first подход: пусть LLM делает то, где он реально хорош (classification/fallback), а всё остальное остаётся простой и проверяемой системой.
И было приятно увидеть в комментариях людей, которые тоже пришли к похожим выводам в своих проектах :)


Чему меня научили два месяца с легковесным локальным AI-агентом