Vault Audit AI: как проанализировать тысячи заметок в Obsidian через LLM

Андрей Отинов -

У вас в Obsidian накопилось под две тысячи заметок. Ежедневники, конспекты, обрывки идей, черновики. Граф-вью показывает облако точек — красиво, но бесполезно. Вы хотите отдать всё LLM, чтобы она нашла сирот, дубликаты и кластеры тем. Но 2000 заметок — это миллионы токенов. Ни в один контекст не влезает, а если бы и влезло, стоило бы как крыло самолёта.

Источник: Habr

Решение есть. Разработчик под ником Ziverpup опубликовал в официальном каталоге Obsidian и на GitHub плагин Vault Audit AI, который проводит аудит хранилища через LLM. В этой статье — инженерная начинка: как обойти лимит контекста через MapReduce, как не платить за повторный анализ, как абстрагировать четырёх LLM-провайдеров под одним интерфейсом и что пришлось переделать, чтобы пройти автоматическое ревью каталога.

Если вы владелец заметок, руководитель небольшой команды или редактор, который решает, стоит ли внедрять такой инструмент, — вот что нужно знать до первого запуска.

Что именно произошло: плагин, который решает задачу «не влезает в контекст»

Плагин Vault Audit AI для Obsidian появился в официальном каталоге и на GitHub. Его задача — проанализировать всё хранилище заметок (тысячи файлов) с помощью LLM и выдать отчёт: какие заметки висят без единой связи, какие дублируют друг друга под разными тегами, какие кластеры тем не соединились.

Плагин работает в трёх режимах под разный объём и бюджет:

  • Single Аудит — разбирает одну заметку за запрос с максимальным контекстом, для точечного глубокого анализа.
  • Single Полный — прогоняет все заметки подряд, игнорируя кэш, для первого запуска или полного пересбора.
  • Batch + Отчёт — рекомендуемый режим: батчевый анализ с кластеризацией, глобальными инсайтами и выгрузкой в Markdown и Canvas. Именно этот режим содержит полный MapReduce-пайплайн.

Практическое следствие: если у вас больше 100–200 заметок, единственный рабочий вариант — Batch + Отчёт. Single-режимы либо не охватят весь корпус, либо обойдутся неоправданно дорого.

Как работает MapReduce поверх LLM: метод, который можно повторить

Классический приём из обработки больших данных ложится на задачу один в один. Если весь корпус не влезает в один запрос, бьём его на части, обрабатываем каждую независимо (Map), потом агрегируем результаты в один проход (Reduce).

Верхнеуровневый сценарий аудита выглядит так:

async run(): Promise<FinalAuditReport> {
  // 1. Отбираем файлы (исключая служебные папки)
  const files = this.collectFiles();

  // 2. Формируем батчи по бюджету символов
  const batches = await this.buildBatches(files);

  // 3. MAP: параллельный анализ батчей
  const mapResults = await this.runMapPhase(batches);
  const allSummaries = mapResults.flatMap((b) => b.files);

  // 4. REDUCE: кластеризация сводок
  const clusters = await this.runReducePhase(allSummaries);

  // 5. Финальный синтез: глобальные инсайты и план действий
  const { globalInsights, actionPlan } =
    await this.runFinalSynthesis(clusters, ...);

  return { clusters, globalInsights, actionPlan, ... };
}

Главное: Map не возвращает текст, он возвращает структуру. Каждая заметка ужимается до компактной сводки: главная мысль, ключевые тезисы, сущности, оценка качества, предложенные теги. Это на порядок дешевле, чем тащить полный текст в фазу Reduce, и именно это позволяет Reduce увидеть всё хранилище целиком.

Что это значит для вас: если вы решите реализовать подобный пайплайн в своём проекте, ключевое решение — не тащить сырой текст в фазу агрегации. Сжимайте каждую единицу контента до структурированной сводки. Это снижает стоимость запросов в 5–10 раз и делает возможным анализ тысяч документов.

Батчинг по бюджету, а не по количеству: почему это важно

Наивный батчинг «по N заметок» ломается на разнородном контенте: десять однострочников и десять лонгридов — это разная нагрузка на контекст. Поэтому батчи набираются жадно, по бюджету символов.

Алгоритм: плагин проходит по файлам, добавляет содержимое в текущий батч, пока не превысит лимит символов. Как только лимит достигнут — батч финализируется и начинается новый. Это гарантирует, что каждый запрос к LLM использует контекст максимально эффективно, без перекосов.

Практическая проверка: если вы настраиваете подобный инструмент, убедитесь, что батчинг учитывает не количество файлов, а объём токенов. Иначе короткие заметки будут обрабатываться по одной, а длинные — выпадать из контекста.

Как не платить за повторный анализ: кэширование результатов

Плагин кэширует результаты Map-фазы. Если заметка не менялась, её сводка не пересчитывается. Это критично для повторных запусков: после первого полного прогона инкрементальный анализ обходится значительно дешевле.

Что проверить: при внедрении подобного решения убедитесь, что кэш хранится отдельно от заметок (например, в служебной папке .obsidian) и что хэш содержимого файла используется для инвалидации кэша. Иначе каждое изменение тега или форматирования будет вызывать пересчёт.

Абстракция четырёх LLM-провайдеров под одним интерфейсом

Плагин поддерживает четырёх LLM-провайдеров. Код написан на TypeScript, и каждый провайдер реализует общий интерфейс. Это позволяет пользователю выбирать модель под задачу и бюджет, не меняя логику аудита.

Что это значит для вас: если вы строите инструмент, который должен работать с разными LLM, — закладывайте абстрактный слой с самого начала. Иначе привязка к одному провайдеру сделает миграцию дорогой.

Что может пойти не так: риски до внедрения

Риск Последствие Как проверить до запуска
Стоимость запросов при первом полном прогоне Счёт за API может оказаться выше ожиданий Оцените объём токенов в вашем хранилище и умножьте на стоимость модели
Зависимость от внешнего API При сбое провайдера аудит не работает Проверьте, поддерживает ли плагин fallback на другую модель
Приватность данных Заметки отправляются на серверы LLM-провайдера Не используйте для чувствительных данных без локальной модели
Качество сводок Слабая модель может давать поверхностные результаты Протестируйте на 10–20 заметках перед полным прогоном
Баги нового плагина Плагин опубликован недавно, возможны ошибки Сделайте бэкап хранилища перед первым запуском

Что проверить за неделю: практический чек-лист

Если вы решили попробовать Vault Audit AI или построить аналогичное решение, вот что можно сделать без перестройки процессов:

  1. Оцените объём. Подсчитайте количество заметок и примерный объём в символах. Если меньше 500 — возможно, Single-режим справится.
  2. Выберите модель. Для первого теста используйте более дешёвую модель (например, GPT-4o-mini или Claude Haiku). Полный прогон на топ-модели может оказаться дорогим.
  3. Сделайте бэкап. Перед любым аудитом скопируйте хранилище. Плагин не должен менять файлы, но подстраховка не помешает.
  4. Запустите тест на 20–50 заметках. Оцените качество сводок и кластеризации. Если результат устраивает — запускайте полный прогон.
  5. Проверьте кэш. После первого прогона измените одну заметку и запустите аудит снова. Убедитесь, что пересчиталась только изменённая заметка.
  6. Оцените стоимость. Посмотрите, сколько токенов ушло на полный прогон, и сравните с бюджетом.

Источники

Генерация изображения

  • Модель: flux-schnell
  • Провайдер: replicate

Темы журнала

Что почитать дальше