Comments 14
Спасибо за ваше решение! Обязательно его протестирую!
Правда у меня база обсидиана очень скромная пока, но я хочу её несколько расширить и использовать как базу знаний по своим уже создававшимся ранее проектам, и MCP было бы очень в тему к такому решению. Буду ждать развития вашего проекта в этом направлении!
Два детектора изменений на один Vault — самое хрупкое место схемы: semantic index сверяет contentHash, а audit index решает по mtime, который у Markdown врет в обе стороны. Синхронизация через iCloud или git checkout переставляет метку времени файлам с неизменившимся содержимым, и Single Audit честно платит за повторный LLM-проход; реже, но бывает и обратное — восстановление файла со старым mtime, и заметка тихо остается с устаревшим mainIdea. Хеш вы и так считаете на chunk-уровне, поэтому дешевле выглядит хранить в note-index.json хеш документа, а mtime оставить быстрым пре-фильтром. Вы видели ложные пропуски аудита на практике, или на личном Vault без внешней синхронизации mtime пока не подводил?
Да,замечание сделано по факту: здесь сейчас действительно есть асимметрия. 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 там скорее исторически оставшийся быстрый механизм,который возник из-за моей недоработки, а не принципиальное архитектурное решение. Спасибо, добавлю этот момент в дальнейшее развитие индекса,потому что думаю там есть потенциал для дополнительной ветки развития.
Есть ли способ оценить качество работы локальных embedding моделей?
Да. Обычно embedding-модели оценивают не «на глаз», а на наборе задач: semantic similarity, retrieval, clustering, classification.
Для сценария с заметками самый полезный тест это retrieval: берём набор запросов, для каждого заранее знаем, какие заметки или chunks должны находиться, потом считаем что-то вроде Recall@K / Precision@K / MRR / nDCG.
Для локальной модели можно еще дополнительно оценить :
качество именно на русском и смешанном RU/EN текстеб
устойчивость на коротких заметках;
скорость;
расход RAM/VRAM;
размерность embeddings;
насколько хорошо модель различает близкие по теме, но разные по смыслу заметки.
Есть готовые бенчмарки вроде MTEB, но для Obsidian полезнее сделать небольшой свой набор из реальных заметок и запросов. Потому что модель, которая хорошо выглядит в среднем бенчмарке, не обязательно лучше именно на вашем Vault.
Мне кажется пускать LLM к своим заметкам - так себе идея в том плане, что теряется сам смысл писать заметки. Лично я пишу их в основном для обучения и там почти нет уникальной информации, которую нельзя найти в интернете. Получается, что проще сразу спросить гугл, чем сначала писать себе заметки, а потом искать в них с помощью нейронки.
А для обучения полезнее прибираться в заметках руками.
Это типичная ловушка архитектора
У меня на текущих задачах есть такая проблема. Есть дублирование, куча файлов. Я бы даже git репозитории туда загнал, если бы был по ним осмысленный поиск
Вот это как раз очень близко к тому направлению, в которое я сейчас двигаю проект. Vault в таком случае становится не единственным источником данных, а одним из подключаемых хранилищ.
В идеале хочется иметь общий слой поиска/контекста, куда можно подключить Obsidian, репозитории, документацию и другие источники, а потом искать по ним семантически из одного места. Сейчас постепенно отделяю этот слой от самого плагина, чтобы он не был намертво привязан только к Obsidian.
Git-репозитории тут действительно выглядят одним из самых очевидных следующих источников.
Obsidian используют далеко не только для обучения. Для учебного Vault я с вами скорее согласен: если цель именно усвоить материал, руками разбирать заметки полезнее, чем перекладывать это на LLM.
Но плагин я больше ориентирую на Vault как «второй мозг»: проекты, рабочие заметки, исследования, идеи, документация, материалы по разным темам. Когда этого становится много, вручную помнить, где что лежит и где уже писал что-то похожее, становится сложно.
А генерация флеш-карточек тут скорее дополнительная фича для тех, кто всё-таки использует Obsidian для обучения, а не основная идея проекта.
Здорово!
Я сейчас делаю нечто похожее для своих 2.7К+ диалогов с LLM. Питон Qt, SQLite, эмбединги, ollama и никакого обсидиана и нотион и js...
Установил сей плагин и не могу понять как установить саму LLM, например Ollama
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.
Я хотел просто навести порядок в Obsidian. В итоге написал два индекса, semantic search и RAG