Карпатый llm-wiki: новый стандарт ведения базы знаний

Андрей Карпатый — сооснователь OpenAI, бывший директор по ИИ в Tesla и автор широко известных обучающих материалов по языковым моделям — опубликовал гист (апрель 2026), в котором описал паттерн личной базы знаний на основе LLM: не поиск по архиву сырых документов, а инкрементальная компиляция знаний в постоянную вики. Когда методологические заметки выходят за подписью Карпатого, за ними стоит не умозрение, а опыт построения реальных AI-систем — именно поэтому на такие материалы стоит обращать внимание.

Чтобы точнее понять, в чём состоит сдвиг, стоит определить два термина. RAG (Retrieval-Augmented Generation) — подход, при котором модель на каждый запрос заново подтягивает релевантные куски из сырых документов и синтезирует ответ; накопления при этом не происходит. Гист в контексте этого паттерна — сжатая выжимка ключевых идей источника, которую модель формирует один раз при загрузке документа и затем переиспользует, не возвращаясь к оригиналу каждый раз заново.

Проблема классического RAG — именно в отсутствии накопления. В системах вроде NotebookLM или ChatGPT с загрузкой файлов модель каждый раз заново вытаскивает и синтезирует информацию из сырых документов, ничего не фиксируя. Предложенный подход принципиально иной: LLM инкрементально строит и поддерживает постоянную вики — структурированный набор взаимосвязанных markdown-файлов. Знания компилируются один раз и накапливаются; при каждом следующем запросе модель работает уже с готовой структурой, а не с сырыми документами.

Для руководителей PMO и проектных менеджеров этот паттерн закрывает конкретную боль: проектные артефакты — статусы, протоколы ретро, зафиксированные решения — накапливаются, но со временем обесцениваются, потому что никто не поддерживает связи между ними. Паттерн постоянной базы знаний переносит эту работу на модель.

Три слоя и три рабочих процесса

Архитектура состоит из трёх слоёв. Первый — сырые источники (Raw Sources): неизменяемые документы, статьи, изображения, всё, что вы когда-либо сохранили; LLM только читает их, не изменяя. Второй — вики (Wiki): markdown-файлы, которые LLM создаёт и поддерживает; этим слоем модель владеет целиком. Третий — схема (Schema): файл CLAUDE.md / AGENTS.md с инструкциями по структуре и рабочим процессам.

Поверх этих слоёв — три операции:

• Загрузка (Ingest). При добавлении нового источника модель читает его, извлекает ключевую информацию и интегрирует в существующую вики: обновляет страницы сущностей, фиксирует противоречия, усиливает синтез. Один проход — до 10–15 обновлённых страниц. Карпатый рекомендует обрабатывать источники по одному, с участием человека.
• Запрос (Query). Ответы на вопросы с возможностью сохранить результат как новую страницу вики — хорошие ответы становятся знанием, в том числе сравнительные таблицы и слайды в Marp.
• Проверка (Lint). Периодическая проверка: противоречия, устаревшие утверждения, страницы-сироты без входящих ссылок, пробелы в покрытии.

Навигацию обеспечивают два служебных файла: index.md — каталог всех страниц с однострочными описаниями, который LLM читает перед ответом на запрос, и log.md — хронологический журнал всех операций в формате ## [дата] тип | название, парсируемый стандартными инструментами командной строки. При росте вики Карпатый рекомендует qmd — локальный поисковик по markdown с гибридным поиском BM25/вектор и MCP-сервером для крупных коллекций. Для просмотра вики и графа связей — Obsidian; для захвата статей из браузера — Obsidian Web Clipper. Вся вики хранится как git-репозиторий.

Как начать: практический рецепт для PMO

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

Шаг 1. Хранилище. Создайте Obsidian-vault как git-репозиторий. Это сразу даёт историю изменений, возможность отката и синхронизацию между устройствами.

Шаг 2. Структура трёх слоёв. Разбейте vault на три папки: sources/ — сырые документы и веб-клипы (только чтение), wiki/ — страницы сущностей, концепций и сводные заметки по проектам (модель пишет сюда), _schema/ — файл AGENTS.md с инструкциями по структуре и соглашениями об именовании.

Шаг 3. Связка с LLM-агентом. Подключите Claude Code, Cursor или любой другой агент с доступом к файловой системе и укажите ему путь к vault. Схема в AGENTS.md — это и есть точка входа: агент читает её первой и знает, что куда писать.

Шаг 4. Первые операции на реальном артефакте. Возьмите протокол последнего ретро. Запустите Загрузку (Ingest): агент читает документ, формирует гист с ключевыми решениями и рисками, затем обновляет сводную заметку по проекту — фиксирует, что изменилось, где есть противоречия с предыдущими статусами. Один артефакт может затронуть 10–15 страниц вики за один проход. После этого задайте агенту вопрос по проекту (Query) — убедитесь, что ответ опирается на только что обновлённые страницы, а не на сырой документ. Если ответ ценный — сохраните его как отдельную страницу вики.

Шаг 5. Ритм поддержки. Загрузку запускайте при каждом новом артефакте. Проверку (Lint) — раз в неделю: агент ищет страницы-сироты, устаревшие утверждения и незафиксированные противоречия между документами. Это занимает несколько минут и не требует вашего участия — только просмотр отчёта.

Минимальный MVP на первую неделю: один vault, три папки, один реальный протокол ретро через Ingest, один вопрос через Query. Этого достаточно, чтобы почувствовать разницу между поиском по архиву и работой с накопленной структурой.

Почему прежние вики умирали

Люди бросают вики, потому что обновить перекрёстные ссылки во всех связанных заметках оказывается непосильной задачей. Обновить одну страницу легко — поддерживать согласованность между пятнадцатью уже нет. Это именно та задача, которую LLM решает без усилий: модель не устаёт и за один проход затрагивает до 15 файлов.

Карпатый соотносит идею с концепцией Мемекса Ванневара Буша 1945 года: Буш описал персональную машину для хранения и ассоциативной навигации по знаниям, но не решил проблему обслуживания этого архива. LLM, по Карпатому, эту проблему решает.