В настройках Vault Audit AI выбрать провайдер Ollama. Для обычной LLM адрес по умолчанию: http://localhost:11434/v1
В поле модели указать имя скачанной модели, например qwen2.5:7b.
Для семантического поиска/embeddings нужна отдельная embedding-модель, например можно поставить её через ollama pull ... и выбрать Ollama уже в настройках embeddings.
Да. Обычно embedding-модели оценивают не «на глаз», а на наборе задач: semantic similarity, retrieval, clustering, classification.
Для сценария с заметками самый полезный тест это retrieval: берём набор запросов, для каждого заранее знаем, какие заметки или chunks должны находиться, потом считаем что-то вроде Recall@K / Precision@K / MRR / nDCG.
Для локальной модели можно еще дополнительно оценить :
качество именно на русском и смешанном RU/EN текстеб
устойчивость на коротких заметках;
скорость;
расход RAM/VRAM;
размерность embeddings;
насколько хорошо модель различает близкие по теме, но разные по смыслу заметки.
Есть готовые бенчмарки вроде MTEB, но для Obsidian полезнее сделать небольшой свой набор из реальных заметок и запросов. Потому что модель, которая хорошо выглядит в среднем бенчмарке, не обязательно лучше именно на вашем Vault.
Вот это как раз очень близко к тому направлению, в которое я сейчас двигаю проект. Vault в таком случае становится не единственным источником данных, а одним из подключаемых хранилищ.
В идеале хочется иметь общий слой поиска/контекста, куда можно подключить Obsidian, репозитории, документацию и другие источники, а потом искать по ним семантически из одного места. Сейчас постепенно отделяю этот слой от самого плагина, чтобы он не был намертво привязан только к Obsidian.
Git-репозитории тут действительно выглядят одним из самых очевидных следующих источников.
Obsidian используют далеко не только для обучения. Для учебного Vault я с вами скорее согласен: если цель именно усвоить материал, руками разбирать заметки полезнее, чем перекладывать это на LLM.
Но плагин я больше ориентирую на Vault как «второй мозг»: проекты, рабочие заметки, исследования, идеи, документация, материалы по разным темам. Когда этого становится много, вручную помнить, где что лежит и где уже писал что-то похожее, становится сложно.
А генерация флеш-карточек тут скорее дополнительная фича для тех, кто всё-таки использует Obsidian для обучения, а не основная идея проекта.
Да,замечание сделано по факту: здесь сейчас действительно есть асимметрия. Semantic index уже ориентируется на содержимое, а старый note-index глубокого аудита пока использует mtime как единственный критерий инкрементальности.
На моём обычном сценарии, где Vault в основном меняется из самого Obsidian, это пока заметно не проявлялось. Но для iCloud/Syncthing/git checkout ваш пример вполне реальный: можно получить как лишний повторный LLM-проход из-за изменившегося mtime, так и более неприятный случай с восстановленным содержимым при неочевидном поведении timestamp.
Идея с contentHash мне нравится, скорее всего именно к этому и стоит привести note-index. Причём я бы немного усилил схему: mtime/size оставить как дешёвый fast path, а hash сделать фактической идентичностью содержимого. Если mtime поменялся, а hash тот же, просто обновляем метаданные без повторного LLM-вызова.
Единственный нюанс: если проверять hash только когда изменился mtime, то обратный случай content изменился, mtime остался тем же всё ещё можно пропустить. Поэтому для полной корректности нужен либо hash-pass по содержимому при аудите/reconciliation, либо периодическая полная сверка. Для Markdown Vault это обычно намного дешевле, чем лишний LLM-проход.
В общем, замечание по делу. Сейчас mtime там скорее исторически оставшийся быстрый механизм,который возник из-за моей недоработки, а не принципиальное архитектурное решение. Спасибо, добавлю этот момент в дальнейшее развитие индекса,потому что думаю там есть потенциал для дополнительной ветки развития.
Нет, перезапускать плагин после каждого изменения не нужно. Сейчас индексация просто не запускается автоматически: после правки заметки нужно вручную выполнить команду Update the current note in the semantic index, либо периодически запускать Update the Vault semantic index для всего хранилища. Неизменённые chunks при этом повторно не обрабатываются.
Это временное ограничение первой версии. В ближайшем небольшом обновлении добавлю автоматическую синхронизацию по событиям создания, изменения, переименования и удаления заметок, поэтому вручную обновлять индекс после обычной работы уже не придётся.
За «В зоне особого внимания» отдельный плюс, десант с заметками это сильно.
Про теги и ключевые слова, тут я сам сначала путался. Разница в том, кто их ставит. Тег ты вешаешь руками и осознанно, ключевое слово алгоритм вытаскивает из текста сам, частотным анализом. То, что вы описываете, это автопростановка тегов через извлечение ключевых слов, и это реально работает. Подвох один: частотный анализ видит форму, а не смысл. Он отлично сгруппирует заметки, где буквально повторяются одни термины, но промахнётся там, где идея одна, а слова разные. На тематически узком vault'е, как у вас, это скорее сработает, потому что словарь ограничен.
Про плагин против отдельного приложения, я выбрал плагин и не жалею. Отдельное приложение на PyQt это своя оболочка, свой рендер markdown, свой парсер ссылок, по сути мини-Обсидиан с нуля. Плагин же получает готовыми и хранилище, и API к заметкам, и связи, остаётся только своя логика. Порог входа несопоставимый. Отдельное приложение оправдано, только если хочется чего-то, что в модель плагинов Обсидиана в принципе не влезает.
Думал об этом, да. Без ИИ реализуемо, но упираешься в две стены.
Первая проблема, это извлечение смысла. Кластеризацию и атомизацию можно попробовать на классике: TF-IDF или эмбеддинги для группировки заметок по близости, извлечение ключевых слов алгоритмами вроде RAKE или YAKE. Но всё это работает с формой (какие слова встречаются вместе), а не со смыслом. Заметка про «индексы в БД» и про «оглавление книги» лексически похожи, а по смыслу нет. LLM эту разницу ловит, статистика чаще промахивается.
Вторая проблема, генерация. Флешкарты, описания к кластерам, разбиение простыни на атомы с новыми заголовками,это не поиск и не группировка, это порождение нового текста. Без языковой модели тут в принципе нечем работать, только руками.
Так что честный ответ: часть про организацию (поиск, теги, группировка по близости) без ИИ делается и делается давно. А часть про понимание и генерацию нет, там ИИ не роскошь, а единственный способ. Плагин как раз про вторую часть, первая и без него в Obsidian неплохо закрыта.
Спасибо за развёрнутый рассказ, система у вас солидная, тридцать лет бумажных заметок это внушает уважение.
Про «поиск против связей»,тут, кажется, мы просто решаем разные задачи. Поиск отвечает на вопрос «где я это записывал», и pagefind с этим справляется прекрасно. Связи отвечают на другой: «что вообще связано с этой мыслью, о чём я думал рядом, но забыл». Поиск найдёт то, что ты уже помнишь и ищешь. Граф и MOC иногда показывают то, что искать бы не догадался. Для меня ценность именно в этом втором сценарии, а не в замене поиска.
Хотя соглашусь с главным: сам по себе граф-вью действительно больше красивый, чем полезный. Поэтому плагин и не пытается на него молиться, а строит MOC-хабы, то есть по сути навигационные оглавления, которые к вашему подходу с категориями-таксономиями ближе, чем к «облаку точек».
И про «программировать заметки как активную прокрастинацию»,буквально про меня,узнал себя болезненно. Половина этого плагина выросла ровно из такого настроения.
Честно,пока глубокого опыта с локалками нет, работал в основном через OpenRouter, так что на reasoning/max_tokens в полный рост не наступал. Но как раз собираюсь поиграться с локальными моделями, так что ваша заметка про thinking-токены очень в тему, заберу на будущее. А поделитесь, как вы сами с этими reasoning-токенами справляетесь? Интересен рабочий подход из первых рук.
Рад, что функция пригодилась,она и правда выстрадана, LLM врёт про чистый JSON с завидным постоянством. Любопытно, что мы пошли разными путями: у вас классический RAG-стек ,а я кластеризацию отдаю прямо LLM в reduce-фазе, без отдельного векторного хранилища. Мой путь дешевле в инфраструктуре, но хуже масштабируется на действительно больших объёмах и не даёт семантического поиска как побочки. На ваших тысячах заметок embeddings-подход, наверное, выиграет. Расскажете потом, как Qdrant себя поведёт,любопытно было бы тоже в этом покопаться
Вопрос по факту,но все же мне есть,что сказать.Граф-вью и Canvas показывают связи, которые уже есть, но не находят того, чего не хватает: сироты, дубли тем под разными тегами, какие заметки стоило бы связать, про что собственно я и писал в статье.Это анализ содержания, а не визуализация структуры.
Про MCP,это рабочая альтернатива,но для меня было пару нюансов. Разница в трёх вещах: плагин может работать полностью локально через Ollama (ничего не уходит в облако), даёт специализированный пайплайн вместо чата (инкрементальный индекс, кластеризация, отчёт в Canvas), и ставится в два клика без настройки сервера. MCP мощнее и гибче, но это другой уровень входа,и не всегда среднестатистическому пользователю Obsidian хочется с этим возиться.
Хотя соглашусь,что для кого-то MCP закроет задачу полностью и даже лучше.
Ollama устанавливается отдельно, сам плагин LLM не скачивает. Тут согласен, сейчас это не очень очевидно из интерфейса, добавлю нормальную инструкцию.
Если кратко:
Установить Ollama с официального сайта.
Скачать нужную модель, например:
ollama pull qwen2.5:7bУбедиться, что Ollama запущен.
В настройках Vault Audit AI выбрать провайдер Ollama. Для обычной LLM адрес по умолчанию:
http://localhost:11434/v1В поле модели указать имя скачанной модели, например
qwen2.5:7b.Для семантического поиска/embeddings нужна отдельная embedding-модель, например можно поставить её через
ollama pull ...и выбрать Ollama уже в настройках embeddings.Да. Обычно embedding-модели оценивают не «на глаз», а на наборе задач: semantic similarity, retrieval, clustering, classification.
Для сценария с заметками самый полезный тест это retrieval: берём набор запросов, для каждого заранее знаем, какие заметки или chunks должны находиться, потом считаем что-то вроде Recall@K / Precision@K / MRR / nDCG.
Для локальной модели можно еще дополнительно оценить :
качество именно на русском и смешанном RU/EN текстеб
устойчивость на коротких заметках;
скорость;
расход RAM/VRAM;
размерность embeddings;
насколько хорошо модель различает близкие по теме, но разные по смыслу заметки.
Есть готовые бенчмарки вроде MTEB, но для Obsidian полезнее сделать небольшой свой набор из реальных заметок и запросов. Потому что модель, которая хорошо выглядит в среднем бенчмарке, не обязательно лучше именно на вашем Vault.
Вот это как раз очень близко к тому направлению, в которое я сейчас двигаю проект. Vault в таком случае становится не единственным источником данных, а одним из подключаемых хранилищ.
В идеале хочется иметь общий слой поиска/контекста, куда можно подключить Obsidian, репозитории, документацию и другие источники, а потом искать по ним семантически из одного места. Сейчас постепенно отделяю этот слой от самого плагина, чтобы он не был намертво привязан только к Obsidian.
Git-репозитории тут действительно выглядят одним из самых очевидных следующих источников.
Obsidian используют далеко не только для обучения. Для учебного Vault я с вами скорее согласен: если цель именно усвоить материал, руками разбирать заметки полезнее, чем перекладывать это на LLM.
Но плагин я больше ориентирую на Vault как «второй мозг»: проекты, рабочие заметки, исследования, идеи, документация, материалы по разным темам. Когда этого становится много, вручную помнить, где что лежит и где уже писал что-то похожее, становится сложно.
А генерация флеш-карточек тут скорее дополнительная фича для тех, кто всё-таки использует Obsidian для обучения, а не основная идея проекта.
Да,замечание сделано по факту: здесь сейчас действительно есть асимметрия. Semantic index уже ориентируется на содержимое, а старый
note-indexглубокого аудита пока используетmtimeкак единственный критерий инкрементальности.На моём обычном сценарии, где Vault в основном меняется из самого Obsidian, это пока заметно не проявлялось. Но для iCloud/Syncthing/git checkout ваш пример вполне реальный: можно получить как лишний повторный LLM-проход из-за изменившегося
mtime, так и более неприятный случай с восстановленным содержимым при неочевидном поведении timestamp.Идея с
contentHashмне нравится, скорее всего именно к этому и стоит привестиnote-index. Причём я бы немного усилил схему:mtime/size оставить как дешёвый fast path, а hash сделать фактической идентичностью содержимого. Еслиmtimeпоменялся, а hash тот же, просто обновляем метаданные без повторного LLM-вызова.Единственный нюанс: если проверять hash только когда изменился
mtime, то обратный случайcontent изменился, mtime остался тем жевсё ещё можно пропустить. Поэтому для полной корректности нужен либо hash-pass по содержимому при аудите/reconciliation, либо периодическая полная сверка. Для Markdown Vault это обычно намного дешевле, чем лишний LLM-проход.В общем, замечание по делу. Сейчас
mtimeтам скорее исторически оставшийся быстрый механизм,который возник из-за моей недоработки, а не принципиальное архитектурное решение. Спасибо, добавлю этот момент в дальнейшее развитие индекса,потому что думаю там есть потенциал для дополнительной ветки развития.Нет, перезапускать плагин после каждого изменения не нужно. Сейчас индексация просто не запускается автоматически: после правки заметки нужно вручную выполнить команду Update the current note in the semantic index, либо периодически запускать Update the Vault semantic index для всего хранилища. Неизменённые chunks при этом повторно не обрабатываются.
Это временное ограничение первой версии. В ближайшем небольшом обновлении добавлю автоматическую синхронизацию по событиям создания, изменения, переименования и удаления заметок, поэтому вручную обновлять индекс после обычной работы уже не придётся.
вышмат выше чем мат :)
Совершенно верно, это отредактированный перезалив моей статьи,которую я выкладывал пару дней назад
За «В зоне особого внимания» отдельный плюс, десант с заметками это сильно.
Про теги и ключевые слова, тут я сам сначала путался. Разница в том, кто их ставит. Тег ты вешаешь руками и осознанно, ключевое слово алгоритм вытаскивает из текста сам, частотным анализом. То, что вы описываете, это автопростановка тегов через извлечение ключевых слов, и это реально работает. Подвох один: частотный анализ видит форму, а не смысл. Он отлично сгруппирует заметки, где буквально повторяются одни термины, но промахнётся там, где идея одна, а слова разные. На тематически узком vault'е, как у вас, это скорее сработает, потому что словарь ограничен.
Про плагин против отдельного приложения, я выбрал плагин и не жалею. Отдельное приложение на PyQt это своя оболочка, свой рендер markdown, свой парсер ссылок, по сути мини-Обсидиан с нуля. Плагин же получает готовыми и хранилище, и API к заметкам, и связи, остаётся только своя логика. Порог входа несопоставимый. Отдельное приложение оправдано, только если хочется чего-то, что в модель плагинов Обсидиана в принципе не влезает.
Думал об этом, да. Без ИИ реализуемо, но упираешься в две стены.
Первая проблема, это извлечение смысла. Кластеризацию и атомизацию можно попробовать на классике: TF-IDF или эмбеддинги для группировки заметок по близости, извлечение ключевых слов алгоритмами вроде RAKE или YAKE. Но всё это работает с формой (какие слова встречаются вместе), а не со смыслом. Заметка про «индексы в БД» и про «оглавление книги» лексически похожи, а по смыслу нет. LLM эту разницу ловит, статистика чаще промахивается.
Вторая проблема, генерация. Флешкарты, описания к кластерам, разбиение простыни на атомы с новыми заголовками,это не поиск и не группировка, это порождение нового текста. Без языковой модели тут в принципе нечем работать, только руками.
Так что честный ответ: часть про организацию (поиск, теги, группировка по близости) без ИИ делается и делается давно. А часть про понимание и генерацию нет, там ИИ не роскошь, а единственный способ. Плагин как раз про вторую часть, первая и без него в Obsidian неплохо закрыта.
А как вы сами прикидывали, на чём хотели строить?
Спасибо за развёрнутый рассказ, система у вас солидная, тридцать лет бумажных заметок это внушает уважение.
Про «поиск против связей»,тут, кажется, мы просто решаем разные задачи. Поиск отвечает на вопрос «где я это записывал», и pagefind с этим справляется прекрасно. Связи отвечают на другой: «что вообще связано с этой мыслью, о чём я думал рядом, но забыл». Поиск найдёт то, что ты уже помнишь и ищешь. Граф и MOC иногда показывают то, что искать бы не догадался. Для меня ценность именно в этом втором сценарии, а не в замене поиска.
Хотя соглашусь с главным: сам по себе граф-вью действительно больше красивый, чем полезный. Поэтому плагин и не пытается на него молиться, а строит MOC-хабы, то есть по сути навигационные оглавления, которые к вашему подходу с категориями-таксономиями ближе, чем к «облаку точек».
И про «программировать заметки как активную прокрастинацию»,буквально про меня,узнал себя болезненно. Половина этого плагина выросла ровно из такого настроения.
Да,готов ознакомиться с наработками людей,которые тоже в этом варятся
Спасибо! Обязательно ознакомлюсь
Честно,пока глубокого опыта с локалками нет, работал в основном через OpenRouter, так что на reasoning/max_tokens в полный рост не наступал. Но как раз собираюсь поиграться с локальными моделями, так что ваша заметка про thinking-токены очень в тему, заберу на будущее. А поделитесь, как вы сами с этими reasoning-токенами справляетесь? Интересен рабочий подход из первых рук.
Рад, что функция пригодилась,она и правда выстрадана, LLM врёт про чистый JSON с завидным постоянством. Любопытно, что мы пошли разными путями: у вас классический RAG-стек ,а я кластеризацию отдаю прямо LLM в reduce-фазе, без отдельного векторного хранилища. Мой путь дешевле в инфраструктуре, но хуже масштабируется на действительно больших объёмах и не даёт семантического поиска как побочки. На ваших тысячах заметок embeddings-подход, наверное, выиграет. Расскажете потом, как Qdrant себя поведёт,любопытно было бы тоже в этом покопаться
Вопрос по факту,но все же мне есть,что сказать.Граф-вью и Canvas показывают связи, которые уже есть, но не находят того, чего не хватает: сироты, дубли тем под разными тегами, какие заметки стоило бы связать, про что собственно я и писал в статье.Это анализ содержания, а не визуализация структуры.
Про MCP,это рабочая альтернатива,но для меня было пару нюансов. Разница в трёх вещах: плагин может работать полностью локально через Ollama (ничего не уходит в облако), даёт специализированный пайплайн вместо чата (инкрементальный индекс, кластеризация, отчёт в Canvas), и ставится в два клика без настройки сервера. MCP мощнее и гибче, но это другой уровень входа,и не всегда среднестатистическому пользователю Obsidian хочется с этим возиться.
Хотя соглашусь,что для кого-то MCP закроет задачу полностью и даже лучше.