Comments 15
Очень похоже на подход разрабов Cline (Why Cline Doesn't Index Your Codebase (And Why That's a Good Thing)). Задачи схожие и методы начали совпадать. Сегодня смотрел как ему систем промпт добавить - на Gemma пока отдельного нет как на qwen-coder ). А остальное он как и любой агент уже умеет.
Согласен. Подобные подходы уже популярны и не только в кодовых агентах.
Если заглянуть в комментарии оригинальной публикации идеи от Karpathy, то можно найти что-то типа "Последнее время я пытался реализовать что-то подобное". Иногда исследователям не хватает именно формализации и популяризации их идей.
Прочитав с десяток нейростатей с описанием цеттелькастена, второго мозга и неоспоримых преимуществ применения ИИ-агентов для упорядочивания всего беспорядка, с нетерпением жду статью о примерах применения такой системы на практике.
В большинстве случаев сценарии применения аналогичны классическому RAG. Разница в том, насколько качественно организованы данные и выполняется поиск информации.
Один из примеров использования: при решении задачи в Cursor указывается путь до нужного vault'а и выполняется планирование решения или исследование определенной темы.
Примером vault'а может быть LLM-wiki по документации pet-проекта и релевантной ему информации (наборы статей, идей и заметок по итогам личного исследования). Ровно так был реализован репозиторий с примером vault'а из статьи.
Без доступа к документации агент решит задачу, но не будет учитывать, например, особенности системы, ее ограничения и ваше видение. С доступом к базе знаний решение будет персонализированным конкретно для этой системы.
P.S. если документация состоит из нескольких .md документов, то ее достаточно сложить в репозиторий проекта, например в папку /docs, и все. LLM-Wiki в таком случае будет излишним.
Вопрос стоит об успешных примерах применения системы на практике. При решении реальной задачи реального проекта. Желательно со сравнением было/стало до и после внедрения системы, чтобы можно было оценить целесообразность подхода из расчета пользы на трудозатраты.
А в репозитории я нашел только мета-информацию о системе. Имея этот репозиторий никакую задачу (кроме организации, собственно, системы) не решить.
Понял, спасибо! Я подумаю, как продемонстрировать работу системы на реальных примерах. Может быть, удастся описать использование при реализации следующего пет-проекта.
Что касается
оценить целесообразность подхода из расчета пользы на трудозатраты
Трудозатраты тут минимальны: открыть кодового агента и воспользоваться логикой, аналогичной той, что реализована в репозитории из статьи. Как раз удобство подхода, что не нужно поднимать отдельно компоненты, как в RAG с векторным поиском.
Все, что нужно - это кодовый агент, правила для него и ваши данные. Затем воспользоваться результатом при работе с проектом, релевантным созданной LLM-Wiki.
Я выгрузил историю чатов с chatgpt, claude и с помощью скиллов от Карпаты обработал их, получив вики с концептами, сущностями и т.д. причём, выгрузка у каждого сервиса своя, но в целом это json файл (у клода один на все переписки, у чатагпт - несколько). Перед запуском ingest сказал, чтобы он учел что выгрузки разный Формат имеют. Делал все в клод коде, 'мозги" - glm5.1, навык от Андрея извлек каждый диалог в отдельный файл, и уже потом обработал в вики их.
Затем попросил добавить в рабочую папку обсидиана папку sources, скопировать туда все исходные чаты, переименовать их, исходя из сути, дополнить ссылками на статьи в вики на каждый отдельный диалог и связать все диалоги тегами, темами и т.д., чтобы получилось как можно больше связей в графе. Поиск намного проще стал - так как сложно искать было в интерфейсах сервисов диалоги.
Из интересного, вики обозвала меня "субъект", и сделала заметку "двойные запросы", указав в ней что то вроде "субъект предпочитает делать одновременно или с небольшой разницей во времени одинаковые запросы в клод и чатгпт, что говорит о недоверии одному мнению и желанию получить варианты решения проблемы.." 😁
Не хватает инфы о границах применимости. На сколько система лучше работает рага и на каких доменах? Если второй мозг нужен только для заметок, то это грустно. И не понятно качество системы на разных моделях. Если использовать облачные модели, то стоит вопрос в безопасности. Если использовать локальные модели, то тут Я бы сказал стоит вопрос даже не столько в качестве, сколько в разрешении. Если собрать большой индекс, указать пути до файлов с краткими описаниями, то близкие по смыслу описания модель уже будет с трудом различать. И чем глубже дерево, тем банальнее выше вероятность ошибки (если на каждом шаге модель работает с 99% точности поиска, то какая точность будет на глубине 4)?
Статья очень интересная, но не хватает ложки дегтя
На сколько система лучше работает рага и на каких доменах?
Для сравнения векторного поиска и LLM-Wiki (+ еще гибридный подход) по-хорошему нужно собирать метрики качества ответов, иначе это будет субъективной оценкой. Работа трудоемкая.
И не понятно качество системы на разных моделях. Если использовать облачные модели, то стоит вопрос в безопасности.
Я для своих баз знаний использую топовые модели типа GPT-5.5/Opus-4.7, т.к. создание и поддержка базы знаний съедает относительно небольшое количество токенов и конфиденциальных данных у меня нет. Итоговое качество баз знаний меня устраивает.
Как это будет работать на локальных моделях я не знаю, нужно тестировать.
Я бы сказал стоит вопрос даже не столько в качестве, сколько в разрешении. Если собрать большой индекс, указать пути до файлов с краткими описаниями, то близкие по смыслу описания модель уже будет с трудом различать.
В статье действительно явно не рассматривается вопрос применимости на большом объеме данных и проблема поиска информации в большом индексе есть.
Косвенно про это говорится в двух местах:
1. В блоке сравнения LLM-Wiki и классического RAG
LLM‑Wiki — структурированные markdown‑страницы + [[wikilinks]] + индекс + LLM‑навигация (при росте базы поверх можно добавить тот же гибридный поиск, например через qmd).
2. В части "Сравнение по основным параметрам" отдельной строкой указан масштаб. Там говорится, что LLM-Wiki применяется для "~100 источников и сотни страниц, индекс умещается в контекст", т.е. для относительно небольших индексов. Для тысяч-миллионов документов нужно использовать RAG или гибридный подход LLM-Wiki с qmd, как указано выше.
Спасибо за комментарий! Вопросы и опасения по делу.
Для таких статей есть хаб — Wiki-технологии.
Очень заинтересовала идея. А obsidian здесь обязателен? Мы ведь можем делать запросы через LLM, какую роль играет obsidian?
В догонку к статье, практическая реализация второго мозга на базе Obsidian - https://pimenov.ai/knowledge/obsidian-claude-n8n-baza-znaniy-umneet/. Внутри есть ссылка на оригинал из X. Подход годный. Сам задумывался, что неплохо было бы объединить контент из разных мест. А тут ещё ИИ прикрутить можно для поиска связей в структурированной базе знаний.
Второй мозг и LLM‑Wiki: Теория и практический гайд по созданию и поддержке личной базы знаний