не смотря на сильный хайп и интерес, даже не трогал подобные инструменты потому что не вижу ни одной задачи которую при помощи них можно закрыть
Я тоже до последнего держался, но любопытство перевесило.
Удаление прослушанного подкаста при помощи LLM (Цель) - вы серьезно?
Прослушанный подкаст удаляется не с помощью LLM, а с помощью скрипта. LLM этот скрипт написала.
Audiobookshelf несколько неудобен для того, чтобы удалять подкасты и авторов с сервера, а особенно если подкаст был послушан в мобильном приложении. При этом само приложение по большей части заточено на аудиокниги и на коллекционирование, а не на "послушал и удалил".
Проще говоря, два клика – это с тем самым написанным скриптом.
С музыкой примерно та же ситуация. Суть в том, что я обильно загружал альбомы через arr-стэк. Вручную их потом удалять – это просто на рутинном уровне скучно. А вот послушать, пока на дорожке бегаешь, понять, что тебе не нравится, и поставить одну звезду – это быстро и легко.
В общем, ваше предположение о двух кликах скорее выдаёт отсутствие опыта эксплуатации коллекции музыки или подкастов в домашней лаборатории.
Использовал модели от Claude и Codex и вплоть до Ollama (средства). Это все совершенно разные модели, их нельзя просто брать и использовать универсально для широкого круга задач.
Тут всё-таки хотелось бы услышать критерии, по которым одна из использованных моделей была непригодна для конкретной описанной задачи, и какую модель следовало выбрать вместо неё.
Без этого фраза "совершенно разные модели" остаётся голословной.
В общем сами говорите про системное мышление и инженерный подход, а по факту просто создали песочницу, в которой пытаетесь совместить между собой кубики из разных наборов в произвольном порядке и смотрите что получится, надеясь увидеть ту самую магию.
Это тоже голословное утверждение.
В моём случае, RSS отвечает за первичный захват материалов. Zotero отвечает за их дальнейшую систематическую обработку и хранение. Соединение этих систем является прямой автоматизацией существующего информационного пайплайна, а не произвольной игрой в кубики.
___
Короче говоря, вы не показали ни ошибочность целей, ни неправильный выбор моделей, ни бессмысленность интеграций. Вы подменили описанные мной сценарии своими, не разобрали внятно ни один из них и выдали собственное непонимание за более осмысленный вывод.
Вы описали то самое магическое мышление, которое упоминалось в статье. Нужно взять модель посильнее, подробнее написать промпт (заклинание) и просто из этих фактов заключить, что результат будет приемлемым.
Агент лишь исполняет. Качество системы упирается в компетенции и инженерную дисциплину человека, который обязан проверить архитектуру, увидеть систематические ошибки и оценить цену решения. Если он этого не умеет, сильная модель не спасёт проект. Она лишь быстрее и убедительнее масштабирует его ошибки.
Но мне кажется, тут тоже есть важный краевой случай. Например, если бы я ему не дал доступ к основной Proxmox-машине, то ему было бы значительно сложнее диагностировать и определять, какие действия нужно сделать, чтобы прокинуть GPU.
То есть, по факту, чем сильнее ограничения у агента, тем менее деструктивны возможные последствия. Но, с другой стороны, если ему не дать достаточно свободы, то трудные и рутинные действия снова упадут на юзера.
Я думаю, дело здесь вообще не в модели. Когда всё происходит в кодовом агенте, процесс планирования и дизайна идёт в более явном и строгом виде. Перед реализацией можно было бы сначала проверить эндпоинт и все доступные операции, а потом дать чёткую задачу агенту (оберни это в MCP и протестируй).
Когда такой агент закончил бы, я бы посмотрел на кодовую базу, проверил, полную ли он сделал обёртку и реальные ли тесты написал. В итоге получился бы качественный MCP-сервер, который потом можно подключать куда угодно.
В моём же случае с Hermes сам процесс работы не подразумевал такой строгости и наблюдаемости. Я ему, по сути, поставил задачу на продуктовом языке, далее как-то обсудил техническую сторону, а потом он начал через миллион агентских вызовов кодировать, тестировать и клепать костыли.
При этом, несмотря на всю продвинутость, Hermes даёт мало инструментов для наблюдаемости получаемых результатов. То есть я ни дифы не могу посмотреть, ни структуру проекта. Мне так или иначе приходится залезать на сервер и смотреть через lazygit, nvim и yazi, что он там наделал. А это, мягко говоря, далеко от идеи универсального агента, в которого можно кинуть любую задачу, и он её качественно решит.
Короче говоря, всё это в совокупности приводит к ощущению, что Hermes является лишней прослойкой в кодировании. То есть опять же дело не в модели. Вдобавок он тянет в разработку весь свой harness, который добавляет накладные расходы и непредсказуемость.
Это все замечательно, а вы сами то что покупали? :)
Я использовал роутинг через Manifest (даже попытался законтрибьютить в него, но увы). Благодаря ему я и увидел, сколько токенов было израсходовано суммарно.
Модели и способы оплаты использовались разные.
Сначала я расходовал лимиты подписок, которые в основном использовал для кодинга (Claude Code и Codex). Позже добавил более дешёвые варианты через OpenCode и Ollama. Когда и их не хватало, последним fallback-уровнем был OpenRouter.
Сейчас у меня домашняя лаборатория не работает, поэтому актуальную конфигурацию я показать не смогу, но ниже прикладываю скрин того, как роутинг был настроен, когда я пытался сэкономить.
Это скрин из Manifest
В частности, я выяснил, что на такой конфигурации из одной подписки OpenCode можно выжать 60 миллионов токенов. Но там в основном довольно слабые модели. С ними можно делать совсем простые повседневные вещи, но что-то серьёзное уже вряд ли.
И ещё по вашему расчёту. Если считать по средней цене модели с нормальным балансом цены и качества (например, GPT-5.6 Terra), что примерно соответствует моему смешанному использованию разных моделей, то итоговая оценка будет заметно ближе к сумме, указанной в статье.
Спасибо за статью, очень интересный подход. Хотелось бы чуть лучше понять механику wiki_graph_context.
Правильно ли я понимаю, что сначала находятся seed-страницы через vector search, а потом к ним добавляются соседние страницы из графа? Если да, то интересно, как вы дедуплицируете seed/hop-страницы, как выбираете глубину обхода, откуда берутся веса для разных типов рёбер, и что именно отдаёте LLM – полный текст страниц или только релевантные фрагменты?
И ещё вопрос. Планируете ли вы где-нибудь выложить код (например, на GitHub)?
Диктофон с суммаризацией – это инструмент захвата. Статья о том, по какому принципу выстраивать архитектуру личной базы знаний, чтобы она работала на длинной дистанции. Получить транскрипт и знать, что с ним делать дальше – это два принципиально разных вопроса.
Но если углубиться в ваш тезис, то он примерно такой же по ценности, как если сказать, что сейчас есть калькуляторы, поэтому математика – это вчерашний день.
Послушал Electric Orange. Разделяю твой вкус. Это грёбанный кайф. В Sweet Absurd словил даже легкую тревогу от сюра и слегка безумного вокала. Послушал также то, что на скрине подчеркнуто. Очень насыщенный психодел. Крутой совет. Покопаю дальше в эту группу.
Треки культовые. Формулировки до предела выдроченные, ёмкие, метафоричные. Порядок я выстроил так, чтобы показать какие метаморфозы происходили с музыкой. Почитайте мои RAW-логи и у вас всё станет на место.
Подход, в котором папки не играют существенной роли. Даже если их полностью убрать из примера, то такая система управления проектами всё равно будет работать.
Использование self-reported данных (опросы школьников) вместо объективных логов делает датасет заведомо шумным и непригодным для выводов. В профессиональной среде такие данные признали бы изначально систематически искаженными.
Коэффициент детерминации равен 0.06. Это означает, что модель объясняет 6% вариации. Остальные 94% – это неучтенные факторы. Выдавать статистический шум за найденную закономерность (тренд) – признак некомпетентности в анализе данных. Про отсутствующую корреляцию между экранным временем и GPA (p=0.0887) я вообще молчу.
Очевидно, что автор перепутал корреляцию с каузальностью. То, что двоечники сидят в телефоне, не доказывает, что телефон сделал их двоечниками.
Вдобавок, цифровое слабоумие – это мгновенный маркер антинаучности. Этого понятия не существует ни в международной классификации болезней (МКБ), ни в рецензируемой нейрофизиологии. Это медийный ярлык, популяризируемый инфобизнесменами вроде Курпатова для продажи страха, а не для описания реальности.
В общем, это не исследование, а бытовая нумерология. Это подогон случайных чисел под свое субъективное мнение. Но это неудивительно. Если зайти в Telegram-канал автора, то в первом же посте он публично признается в использовании ИИ для подгонки источников под готовые выводы. В серьезных журналах такое влечет бан и ретракцию всех публикаций автора.
Хорошая, сбалансированная и весьма полезная статья. Единственное, мне не понравились метрики, так как очень легко найти примеры, где они сломаются. Например, возьмём "количество CSS-сниппетов" в системе, нацеленной на скорость. Один сниппет — хорошо, десять сниппетов — плохо. А что если и там, и там будет одинаковое количество суммарного кода?
Пример как будет выглядеть текст
Тоже когда-то думал, что сделать умный поиск по заметкам – это небольшая задача 🙂
Я тоже до последнего держался, но любопытство перевесило.
Прослушанный подкаст удаляется не с помощью LLM, а с помощью скрипта. LLM этот скрипт написала.
Audiobookshelfнесколько неудобен для того, чтобы удалять подкасты и авторов с сервера, а особенно если подкаст был послушан в мобильном приложении. При этом само приложение по большей части заточено на аудиокниги и на коллекционирование, а не на "послушал и удалил".Проще говоря, два клика – это с тем самым написанным скриптом.
С музыкой примерно та же ситуация. Суть в том, что я обильно загружал альбомы через arr-стэк. Вручную их потом удалять – это просто на рутинном уровне скучно. А вот послушать, пока на дорожке бегаешь, понять, что тебе не нравится, и поставить одну звезду – это быстро и легко.
В общем, ваше предположение о двух кликах скорее выдаёт отсутствие опыта эксплуатации коллекции музыки или подкастов в домашней лаборатории.
Тут всё-таки хотелось бы услышать критерии, по которым одна из использованных моделей была непригодна для конкретной описанной задачи, и какую модель следовало выбрать вместо неё.
Без этого фраза "совершенно разные модели" остаётся голословной.
Это тоже голословное утверждение.
В моём случае, RSS отвечает за первичный захват материалов. Zotero отвечает за их дальнейшую систематическую обработку и хранение. Соединение этих систем является прямой автоматизацией существующего информационного пайплайна, а не произвольной игрой в кубики.
___
Короче говоря, вы не показали ни ошибочность целей, ни неправильный выбор моделей, ни бессмысленность интеграций. Вы подменили описанные мной сценарии своими, не разобрали внятно ни один из них и выдали собственное непонимание за более осмысленный вывод.
Вы описали то самое магическое мышление, которое упоминалось в статье. Нужно взять модель посильнее, подробнее написать промпт (заклинание) и просто из этих фактов заключить, что результат будет приемлемым.
Агент лишь исполняет. Качество системы упирается в компетенции и инженерную дисциплину человека, который обязан проверить архитектуру, увидеть систематические ошибки и оценить цену решения. Если он этого не умеет, сильная модель не спасёт проект. Она лишь быстрее и убедительнее масштабирует его ошибки.
Согласен.
Но мне кажется, тут тоже есть важный краевой случай. Например, если бы я ему не дал доступ к основной Proxmox-машине, то ему было бы значительно сложнее диагностировать и определять, какие действия нужно сделать, чтобы прокинуть GPU.
То есть, по факту, чем сильнее ограничения у агента, тем менее деструктивны возможные последствия. Но, с другой стороны, если ему не дать достаточно свободы, то трудные и рутинные действия снова упадут на юзера.
Я думаю, дело здесь вообще не в модели. Когда всё происходит в кодовом агенте, процесс планирования и дизайна идёт в более явном и строгом виде. Перед реализацией можно было бы сначала проверить эндпоинт и все доступные операции, а потом дать чёткую задачу агенту (оберни это в MCP и протестируй).
Когда такой агент закончил бы, я бы посмотрел на кодовую базу, проверил, полную ли он сделал обёртку и реальные ли тесты написал. В итоге получился бы качественный MCP-сервер, который потом можно подключать куда угодно.
В моём же случае с Hermes сам процесс работы не подразумевал такой строгости и наблюдаемости. Я ему, по сути, поставил задачу на продуктовом языке, далее как-то обсудил техническую сторону, а потом он начал через миллион агентских вызовов кодировать, тестировать и клепать костыли.
При этом, несмотря на всю продвинутость, Hermes даёт мало инструментов для наблюдаемости получаемых результатов. То есть я ни дифы не могу посмотреть, ни структуру проекта. Мне так или иначе приходится залезать на сервер и смотреть через lazygit, nvim и yazi, что он там наделал. А это, мягко говоря, далеко от идеи универсального агента, в которого можно кинуть любую задачу, и он её качественно решит.
Короче говоря, всё это в совокупности приводит к ощущению, что Hermes является лишней прослойкой в кодировании. То есть опять же дело не в модели. Вдобавок он тянет в разработку весь свой harness, который добавляет накладные расходы и непредсказуемость.
Я использовал роутинг через Manifest (даже попытался законтрибьютить в него, но увы). Благодаря ему я и увидел, сколько токенов было израсходовано суммарно.
Модели и способы оплаты использовались разные.
Сначала я расходовал лимиты подписок, которые в основном использовал для кодинга (Claude Code и Codex). Позже добавил более дешёвые варианты через OpenCode и Ollama. Когда и их не хватало, последним fallback-уровнем был OpenRouter.
Сейчас у меня домашняя лаборатория не работает, поэтому актуальную конфигурацию я показать не смогу, но ниже прикладываю скрин того, как роутинг был настроен, когда я пытался сэкономить.
В частности, я выяснил, что на такой конфигурации из одной подписки OpenCode можно выжать 60 миллионов токенов. Но там в основном довольно слабые модели. С ними можно делать совсем простые повседневные вещи, но что-то серьёзное уже вряд ли.
И ещё по вашему расчёту. Если считать по средней цене модели с нормальным балансом цены и качества (например,
GPT-5.6 Terra), что примерно соответствует моему смешанному использованию разных моделей, то итоговая оценка будет заметно ближе к сумме, указанной в статье.Он доступен в OpenCode Go и в Ollama Cloud
Содержательно. Это именно то, что я хотел узнать. Спасибо за ответ.
Мой GitHub.
Спасибо за статью, очень интересный подход. Хотелось бы чуть лучше понять механику
wiki_graph_context.Правильно ли я понимаю, что сначала находятся seed-страницы через vector search, а потом к ним добавляются соседние страницы из графа? Если да, то интересно, как вы дедуплицируете seed/hop-страницы, как выбираете глубину обхода, откуда берутся веса для разных типов рёбер, и что именно отдаёте LLM – полный текст страниц или только релевантные фрагменты?
И ещё вопрос. Планируете ли вы где-нибудь выложить код (например, на GitHub)?
Диктофон с суммаризацией – это инструмент захвата. Статья о том, по какому принципу выстраивать архитектуру личной базы знаний, чтобы она работала на длинной дистанции. Получить транскрипт и знать, что с ним делать дальше – это два принципиально разных вопроса.
Но если углубиться в ваш тезис, то он примерно такой же по ценности, как если сказать, что сейчас есть калькуляторы, поэтому математика – это вчерашний день.
Послушал Electric Orange. Разделяю твой вкус. Это грёбанный кайф. В Sweet Absurd словил даже легкую тревогу от сюра и слегка безумного вокала. Послушал также то, что на скрине подчеркнуто. Очень насыщенный психодел. Крутой совет. Покопаю дальше в эту группу.
Треки культовые. Формулировки до предела выдроченные, ёмкие, метафоричные. Порядок я выстроил так, чтобы показать какие метаморфозы происходили с музыкой. Почитайте мои RAW-логи и у вас всё станет на место.
Подход, в котором папки не играют существенной роли. Даже если их полностью убрать из примера, то такая система управления проектами всё равно будет работать.
Называть научный метод и требования к чистоте данных "снобизмом" – это позиция, когда нечего возразить по существу.
Вы проигнорировали все фактические претензии:
Коэффициент детерминации 0.06 (94% необъясненной дисперсии)
P-value > 0.05 в ключевой гипотезе
Невалидность self-reported данных
Вместо работы над ошибками вы переходите на личности. Это лишь подтверждает, что статья имитирует науку и не выдерживает предметной критики.
Использование self-reported данных (опросы школьников) вместо объективных логов делает датасет заведомо шумным и непригодным для выводов. В профессиональной среде такие данные признали бы изначально систематически искаженными.
Коэффициент детерминации равен 0.06. Это означает, что модель объясняет 6% вариации. Остальные 94% – это неучтенные факторы. Выдавать статистический шум за найденную закономерность (тренд) – признак некомпетентности в анализе данных. Про отсутствующую корреляцию между экранным временем и GPA (
p=0.0887) я вообще молчу.Очевидно, что автор перепутал корреляцию с каузальностью. То, что двоечники сидят в телефоне, не доказывает, что телефон сделал их двоечниками.
Вдобавок, цифровое слабоумие – это мгновенный маркер антинаучности. Этого понятия не существует ни в международной классификации болезней (МКБ), ни в рецензируемой нейрофизиологии. Это медийный ярлык, популяризируемый инфобизнесменами вроде Курпатова для продажи страха, а не для описания реальности.
В общем, это не исследование, а бытовая нумерология. Это подогон случайных чисел под свое субъективное мнение. Но это неудивительно. Если зайти в Telegram-канал автора, то в первом же посте он публично признается в использовании ИИ для подгонки источников под готовые выводы. В серьезных журналах такое влечет бан и ретракцию всех публикаций автора.
Хорошая, сбалансированная и весьма полезная статья. Единственное, мне не понравились метрики, так как очень легко найти примеры, где они сломаются. Например, возьмём "количество CSS-сниппетов" в системе, нацеленной на скорость. Один сниппет — хорошо, десять сниппетов — плохо. А что если и там, и там будет одинаковое количество суммарного кода?
Вроде как поправил.
screen
И ещё включите dark режим в настройках самого Habr.
page settings
Ваш комментарий – это хорошая иллюстрация для кого эта система не предназначена. Она требует самостоятельности, дисциплины и осознанности.
Вы сами то эту статью прочитали?
Из этого не следует, что нужно заниматься калькированием англоязычной документации.