LLM Wiki: как построить личную базу знаний с Obsidian и Codex вместо RAG
Вы читаете статью, сохраняете несколько ссылок, задаёте вопрос нейросети — получаете хороший синтез. Но завтра тот же вопрос требует того же объёма контекста. Модель не помнит, что вы уже разбирали эту тему.
Источник: Habr
Если вы ведёте исследования, готовите материалы или просто накапливаете заметки по работе, эта проблема знакома. RAG (поиск по документам с генерацией ответа) хорош для продакшена, но для личной базы знаний он «ответил и забыл».
Инженер из компании Raft Рамиль Аллахвердиев проверил альтернативу — LLM Wiki. Вместо того чтобы каждый раз собирать контекст заново, модель сама строит и поддерживает вики из ваших источников. Вот как это устроено и стоит ли пробовать.
Что изменилось: LLM не просто отвечает, а накапливает знания
Обычная работа с LLM и документами выглядит так: загрузили PDF, задали вопрос, модель нашла релевантные фрагменты и сгенерировала ответ. Это RAG. Он полезен, когда есть приложение, пользователи, SLA и индексы.
Но в личной работе RAG не накапливает результат. Вы прочитали несколько статей про guardrails, evaluation, OCR и AI-агентов. Спрашиваете модель: «что между ними общего?» — она даёт синтез. Но если он остался только в чате, завтра его придётся собирать заново.
LLM Wiki предлагает другой подход: не просто отвечать на вопросы, а компилировать знания в постоянный слой markdown-файлов. Источники остаются как raw data, а поверх них строится вики: карточки источников, понятия, связи, синтезы и даже отчёты о проверке целостности базы.
Как устроен workflow: три слоя и три операции
В эксперименте Рамиля LLM Wiki состоит из трёх слоёв.
Первый слой — raw sources. Это исходные статьи, PDF, заметки, транскрипты. Их не редактируют, они служат источником правды. В эксперименте — статьи с Хабра, сохранённые в markdown.
Второй слой — wiki. Обработанный слой: карточки источников, страницы понятий, связи между ними, синтезы и сохранённые ответы. Всё это обычные markdown-файлы в Obsidian.
Третий слой — rules/schema. Инструкции для агента: как делать ingest, как писать карточки, какие файлы обновлять и где вести лог. В эксперименте — файл AGENTS.md.
Метафора простая: Obsidian — IDE для знаний, markdown — кодовая база, Codex — агент-поддержатель.
Вся система держится на трёх операциях.
Ingest — добавление нового источника. Вы сохраняете статью в raw/habr/ и говорите Codex: «Выполни ingest для всех новых файлов из raw/habr по правилам AGENTS.md». Codex читает статью, создаёт карточку источника, выделяет главную идею, тезисы, тон, ограничения, практические приёмы, создаёт или обновляет страницы понятий, добавляет связи и обновляет индекс.
Query — ответ по уже накопленному слою. Модель ищет не в сырых источниках, а в структурированной вики: понятиях, связях, синтезах. Это быстрее и точнее, чем каждый раз перебирать все документы.
Lint — проверка целостности базы. Codex ищет дубли, слабые связи, пропущенные понятия и противоречия. База знаний не просто растёт, а остаётся чистой.
Чем LLM Wiki отличается от RAG и когда это выгодно
| Характеристика | RAG | LLM Wiki |
|---|---|---|
| Хранение результата | Ответ в чате, не сохраняется | Структурированная markdown-вики |
| Повторное использование | Каждый раз сбор контекста заново | Накопленные понятия и связи |
| Контроль качества | Зависит от качества индекса | Lint-проверки, ручное редактирование |
| Инструменты | Векторная БД, чанкинг, эмбеддинги | Obsidian, markdown, Codex |
| Подходит для | Продакшен с runtime-запросами | Личные заметки, ресерч, подготовка материалов |
LLM Wiki не заменяет RAG в продакшене. Но для личной работы, где важна не скорость ответа, а накопление и структурирование знаний, он даёт другое качество: вы не теряете синтезы, можете править карточки вручную и видите, как связаны понятия.
Где границы метода и что может не сработать
Метод описан на основе личного эксперимента. Это не промышленное решение, а рабочий прототип. Вот что стоит проверить до внедрения.
Зависимость от инструментов. В эксперименте используются Obsidian и Codex. Если вы работаете в другой среде, переносимость может быть ограничена. Нужно убедиться, что ваш редактор поддерживает markdown и связи между файлами.
Стоимость вызовов модели. Каждый ingest и lint — это запрос к LLM. При большом количестве источников затраты могут расти. В статье нет цифр по стоимости, но это стоит оценить до начала.
Качество автоматической структуризации. Модель может ошибочно связать понятия, пропустить важное или создать дубли. Lint помогает, но не гарантирует идеальную базу. Ручная проверка остаётся необходимой.
Отсутствие метрик. В источнике нет сравнения скорости или точности с RAG. Решение о переходе стоит принимать на основе собственного теста, а не обещаний.
Что проверить за неделю: практический чек-лист
- Выберите 3-5 статей или заметок по одной теме. Сохраните их в markdown в папку
raw/. - Создайте файл
AGENTS.mdс инструкцией для модели: как делать ingest, какие поля заполнять в карточках, куда сохранять понятия и связи. - Запустите ingest для одной статьи. Проверьте, что модель создала карточку источника, страницы понятий и связи. Оцените качество: есть ли пропущенные важные тезисы, верно ли определены связи.
- Задайте вопрос по вики. Сравните ответ с тем, что вы получили бы через RAG по тем же источникам. Что точнее, что полнее?
- Запустите lint. Посмотрите, какие дубли или слабые связи нашла модель. Оцените, сколько времени уходит на ручную правку.
- Оцените затраты. Посчитайте, сколько токенов ушло на ingest одной статьи. Умножьте на свой объём источников. Реалистично ли это для вашего бюджета?
Что делать, если метод подходит
Если тест прошёл успешно, LLM Wiki можно использовать для регулярной работы:
- Ведите
raw/как папку входящих: новые статьи, PDF, транскрипты. - Запускайте ingest раз в неделю или после добавления пачки источников.
- Используйте query для быстрых ответов по накопленным знаниям.
- Запускайте lint перед важными синтезами или отчётами.
Метод особенно хорошо ложится на личные заметки, исследовательские проекты и подготовку материалов, где важна не скорость, а глубина и связность знаний.
Источники
Дополнительные рекомендации
Для успешного внедрения LLM Wiki стоит учитывать несколько практических моментов. Во-первых, регулярно обновляйте AGENTS.md по мере накопления опыта — инструкции должны отражать ваши реальные потребности в структурировании знаний. Во-вторых, не пренебрегайте ручной проверкой после lint: автоматические инструменты могут пропустить тонкие логические несоответствия. В-третьих, для больших объёмов источников рассмотрите возможность параллельного ingest, чтобы сократить время обработки. Наконец, ведите лог изменений вики — это поможет отслеживать эволюцию вашей базы знаний и выявлять повторяющиеся ошибки модели.
Что почитать дальше
- Бюджет AI-агента: стоимость результата вместо токенов — формула расчёта
- ИИ-агент и предиктивный обзвон в отделе продаж: где автоматизация даёт +25–30% успешных дозвоно́в, а где только шум
- Как превратить статью на Habr в рабочий инструмент: 15-минутный метод разбора
- Метод Kemp AI: как превратить статью на Habr в рабочего AI-агента
- Статья на Habr в рабочий метод: как оценить AI-инструмент перед внедрением
