Базы знаний · конспект по субтитрам
Карпатый Wiki вместо RAG — полный Obsidian-сетап
Подробный конспект сравнения классического RAG и Wiki LLM: как собрать связанную базу знаний из Markdown-файлов, управлять ею через Obsidian и поручить агенту ingest, query и lint.
Главное за минуту
- Классический RAG ищет похожие чанки, а Wiki LLM строит связанные смысловые страницы
- Рабочая структура состоит из raw-источников, wiki-страниц и файла с правилами
- Три базовые операции системы — ingest, query и lint
- Человек выбирает источники и контролирует результат, а агент поддерживает связи и порядок
Разбор по главам
Нажмите на таймкод, чтобы открыть соответствующий фрагмент оригинального видео.
Почему Wiki сравнивают с RAG
В начале ролика разбирается классический RAG: документы режутся на чанки, превращаются в векторы, а на запрос возвращаются самые похожие фрагменты. Wiki LLM предлагает другую механику — сначала превратить источники в связанную систему знаний.
- RAG извлекает отдельные релевантные куски по семантической близости.
- Wiki сохраняет не только факты, но и связи между темами.
Memex и ассоциативные маршруты
Подход связывается с идеей Memex Ванневара Буша: знание полезно не только как архив, но и как сеть ассоциативных маршрутов. Современный агент может создавать ссылки, обновлять их и помогать проходить по ним во время ответа.
- Человек определяет, какие источники заслуживают доверия.
- Агент берёт на себя рутинное связывание и обслуживание базы.
Три части файловой системы
Практическая Wiki строится вокруг трёх сущностей: каталога raw с исходными файлами, каталога wiki с обработанными Markdown-страницами и инструкции, которая объясняет агенту правила работы.
- Raw хранит первоисточники без попытки сразу превратить их в базу знаний.
- Wiki содержит компактные тематические страницы, ссылки и главный index.md.
- Инструкция фиксирует, как добавлять, искать и обслуживать знания.
Ingest, query и lint
При ingest агент читает новый источник, выделяет смысловые точки и обновляет Wiki. Query начинается с index.md и рекурсивно ведёт к нужным страницам. Lint ищет дубли, потерянные страницы, слабые связи и устаревший индекс.
- Во время query агент работает с Wiki, а не перечитывает весь raw-каталог.
- Lint нужен, потому что живая база постепенно накапливает структурные ошибки.
Границы масштаба
Система особенно удобна, пока index.md помещается в контекст модели. В ролике приводится ориентир примерно в сотню источников и несколько сотен Wiki-страниц; большие области лучше разделять на отдельные базы по проектам или темам.
- Одна бесконечная Wiki со временем ухудшает навигацию и качество контекста.
- Разделение по доменам помогает агенту не смешивать несвязанные знания.
Obsidian как интерфейс, агент как редактор
Obsidian используется как удобный интерфейс для просмотра Markdown и графа связей. Агент выполняет роль разработчика базы: создаёт страницы и ссылки, а человек проверяет источники, задаёт вопросы и корректирует результат.
- Проект создаётся отдельным каталогом и открывается как Obsidian vault.
- Работа с агентом запускается прямо из терминала внутри этого каталога.
Демонстрация на переписке команды
В raw добавляется экспорт рабочего чата. После ingest агент выделяет темы вроде GraphRAG, контроля расходов на модели, AI-безопасности и агентских процессов, задаёт уточняющие вопросы и создаёт набор связанных страниц.
- Помимо тематических страниц появляются index.md и журнал изменений.
- Граф Obsidian наглядно показывает, где в базе концентрируются связи.
Запрос и обслуживание Wiki
На вопрос о снижении расходов система находит обсуждённые в чате решения: LLM-шлюз, маршрутизацию простых запросов в локальную модель, лимиты и проверку чувствительных данных. Затем lint добавляет недостающие страницы, расшифровки терминов и перекрёстные ссылки.
- Ответ собирается из нескольких связанных страниц, а не одного случайного чанка.
- После lint структура и индекс снова соответствуют фактическому содержимому.