Второй мозг по Карпати: как создать персональную базу знаний с ИИ

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

Сложности начинаются позже.

На встрече возникает вопрос:

И выясняется, что ответ распределён между несколькими документами, старой расшифровкой встречи и исследованием, которое уже никто не помнит целиком.

Андрей Карпати предлагает использовать LLM не только для разовых ответов, но и для постоянного ведения накопленных знаний. 4 апреля 2026 года он опубликовал концепцию LLM Wiki — паттерн персональной базы знаний, которую языковая модель постепенно строит и поддерживает на основе выбранных человеком источников.

Сам Карпати называет систему именно LLM Wiki. «Второй мозг» — удобное описание результата: база сохраняет документы, связи между темами, историю решений и выводы, к которым можно вернуться спустя месяцы.

LLM Wiki сохраняет результат предыдущей работы с информацией

Большинство привычных сценариев работы с ИИ устроены как отдельные сессии.

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

Модель изучает документы, сопоставляет фрагменты и готовит ответ.

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

Карпати предлагает другую механику. При добавлении нового источника LLM читает его и интегрирует информацию в существующую wiki: обновляет тематические страницы, дополняет сведения о компаниях, людях и понятиях, фиксирует противоречия. Результат предыдущей работы сохраняется и используется дальше.

Представим пять интервью.

Один клиент говорит о цене. Два человека испытывают сложности с настройкой. Ещё трое не понимают, что делать сразу после регистрации.

В обычном архиве это пять отдельных документов.

В LLM Wiki те же материалы постепенно формируют связанные темы:

• ценообразование;
• первый запуск;
• регистрация;
• причины отказа;
• особенности разных сегментов клиентов.

Через несколько месяцев можно спросить:

Какие проблемы чаще всего возникают у новых пользователей? На каких интервью основаны выводы и где источники расходятся?

Система уже располагает накопленным контекстом, а не начинает анализ с нуля.

Чем LLM Wiki отличается от RAG

RAG — Retrieval-Augmented Generation — позволяет языковой модели отвечать на вопросы с опорой на внешнюю коллекцию документов.

В типичном сценарии пользователь задаёт вопрос, система находит релевантные фрагменты источников и передаёт их модели. После этого LLM формирует ответ.

Такой подход хорошо решает задачу поиска.

LLM Wiki добавляет постоянный слой синтезированных знаний. Модель постепенно ведёт связанные страницы и обновляет их при появлении новых материалов. Карпати описывает именно этот накопительный эффект как ключевое отличие подхода.

Поэтому RAG и LLM Wiki не стоит противопоставлять.

У них разные задачи:

RAG помогает извлечь релевантную информацию из массива источников.

LLM Wiki помогает сохранять и развивать накопленное представление о предметной области.

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

Как устроена LLM Wiki

В оригинальной схеме Карпати есть три основных слоя:

1. raw — коллекция первичных источников;
2. wiki — производный слой знаний, который создаёт и обновляет LLM;
3. schema — правила и рабочие соглашения, по которым модель ведёт базу.

Кроме них используются два служебных файла:

• index.md — каталог содержимого wiki;
• log.md — журнал операций и изменений.

Важно: Карпати не предлагает единственную обязательную структуру каталогов. Его документ описывает общий паттерн, а конкретная организация файлов, формат страниц и набор инструментов зависят от предметной области и выбранного AI-агента.

Пример структуры второго мозга

Для рабочего проекта базу можно организовать примерно так:

Это не стандарт, заданный Карпати, а понятный стартовый вариант. По мере роста базы структуру можно менять.

Разберём каждый элемент отдельно.

raw: коллекция первичных источников

В raw хранятся материалы в первоначальном виде:

• исследования;
• статьи;
• интервью;
• транскрипты встреч;
• изображения;
• наборы данных;
• презентации;
• документы проектов.

В архитектуре Карпати этот слой неизменяемый: LLM читает документы, но не редактирует их. Именно первичные источники остаются основанием, по которому можно проверить выводы wiki.

Внутри raw удобно разделять материалы по типам.

Например:

• articles — статьи и публикации;
• meetings — записи и расшифровки встреч;
• interviews — интервью с клиентами и экспертами;
• research — исследования и аналитические отчёты;
• projects — исходная документация проектов.

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

Разделение первичных и производных данных защищает базу от постепенного искажения фактов.

Допустим, на странице wiki появилось утверждение:

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

Поскольку оригиналы лежат отдельно, вывод можно перепроверить и исправить.

wiki: слой структурированных знаний

В wiki находятся уже не исходные документы, а страницы, которые создаёт и поддерживает LLM.

Карпати перечисляет несколько возможных типов: резюме, страницы сущностей и понятий, сравнения, обзоры и синтез нескольких источников. Модель создаёт новые страницы, обновляет существующие и поддерживает перекрёстные связи между ними.

Практическая структура может выглядеть так:

• concepts — понятия, проблемы, процессы и идеи;
• people — страницы людей;
• companies — организации, клиенты и конкуренты;
• projects — накопленный контекст отдельных проектов;
• topics — крупные темы исследований.

Предположим, команда регулярно изучает первый запуск продукта.

В нескольких интервью пользователи отмечают, что после регистрации им непонятно, какой следующий шаг нужно выполнить.

В wiki появляется постоянная страница «Первый запуск продукта».

На ней со временем накапливаются:

• повторяющиеся проблемы;
• сегменты пользователей, у которых они возникают;
• гипотезы команды;
• результаты экспериментов;
• противоречащие наблюдения;
• ссылки на первичные источники.

Следующее интервью не обязательно превращать в ещё одно самостоятельное резюме. Если оно содержит новые данные по уже известной проблеме, соответствующая страница обновляется.

Это принципиальный момент: новые источники развивают существующую систему знаний, а не увеличивают коллекцию независимых саммари.

schema: правила, по которым LLM ведёт базу

schema определяет порядок работы модели с LLM Wiki.

В оригинальном описании Карпати это документ, который объясняет:

• как устроена wiki;
• какие соглашения используются;
• как обрабатывать новые источники;
• как отвечать на вопросы;
• как поддерживать базу в актуальном состоянии.

schema — название логического слоя. На практике инструкции могут храниться в файле, который понимает конкретный AI-агент. Карпати приводит CLAUDE.md для Claude Code и AGENTS.md для Codex.

Для рабочей базы в правилах имеет смысл зафиксировать следующее:

1. Первичные источники нельзя изменять.
2. Существенные фактические утверждения должны быть связаны с источниками.
3. Если новая информация относится к существующей теме, следует обновить её страницу, а не создавать дубликат.
4. Факты из источников нужно отделять от аналитических выводов модели.
5. Противоречия между материалами нужно фиксировать, а не автоматически устранять.
6. Если данных недостаточно, это нужно указывать прямо.
7. После обработки источника следует обновить индекс и журнал.

Со временем правила уточняются.

Например, если модель несколько раз делает общий вывод на основе одного интервью, в schema стоит добавить условие:

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

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

index.md: карта накопленных знаний

Когда wiki разрастается, модели нужно быстро определять, какие страницы относятся к очередному запросу.

Для этого Карпати использует index.md.

В нём перечисляются страницы wiki, ссылки на них, краткое описание и при необходимости дополнительные сведения — например дата или количество источников. При ответе на вопрос LLM может сначала прочитать индекс, найти релевантные разделы и только затем изучить выбранные страницы подробнее.

Пример:

# Клиенты

- [[customer-segments]] — основные сегменты
- [[customer-pains]] — проблемы клиентов
- [[purchase-barriers]] — причины отказа

# Продукт

- [[onboarding]] — первый запуск
- [[pricing]] — тарифы и восприятие цены
- [[retention]] — удержание пользователей

# Конкуренты

- [[competitor-a]]
- [[competitor-b]]

# Проекты

- [[new-pricing]]
- [[mobile-app]]

Карпати пишет, что простой индекс показывает хорошие результаты на умеренном масштабе — примерно при сотне источников и нескольких сотнях wiki-страниц. Это его практическая оценка, а не технический лимит. При дальнейшем росте базы можно подключить отдельный поисковый слой.

log.md: история работы с базой

log.md выполняет другую функцию.

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

Например:

## 12 августа — новое интервью

Добавлен источник:
интервью с клиентом.

Обновлены темы:
- первый запуск;
- регистрация;
- малый бизнес.

Зафиксировано расхождение с двумя предыдущими интервью
по восприятию цены.

Два служебных файла решают разные задачи:

index.md показывает, какие знания собраны.

log.md показывает, как база менялась.

Как LLM Wiki работает в ежедневном режиме

Карпати выделяет три основные операции:

• ingest — добавление и обработка нового источника;
• query — запрос к накопленным знаниям;
• lint — проверка состояния wiki.

Ingest: новый источник встраивается в существующую базу

Появилось новое интервью, исследование или статья.

LLM изучает материал, выделяет ключевую информацию, создаёт или обновляет тематические страницы, вносит изменения в индекс и добавляет запись в журнал.

По словам Карпати, один источник в его собственном процессе может затронуть 10–15 страниц. Он предпочитает обрабатывать материалы по одному и просматривать изменения, хотя допускает и пакетную обработку.

Для новой базы участие человека особенно полезно.

Первые несколько обработок покажут:

• насколько корректно модель интерпретирует документы;
• не делает ли слишком широких выводов;
• правильно ли выбирает существующие страницы для обновления;
• сохраняет ли происхождение фактов.

Допустим, после интервью модель обновила три страницы:

• «Первый запуск»;
• «Малый бизнес»;
• «Причины отказа».

Это нормальная ситуация. Один источник может содержать данные сразу по нескольким темам.

Query: вопросы задаются уже накопленной wiki

Когда база сформировалась, её можно использовать для рабочих и исследовательских запросов.

Например:

Какие причины отказа чаще всего встречались в интервью за последний квартал?

Или:

Почему команда выбрала текущую модель ценообразования и какие альтернативы обсуждались?

LLM находит релевантные страницы, читает их и формирует ответ с опорой на накопленные знания и источники.

Карпати отдельно отмечает полезный эффект: хороший результат запроса можно сохранить обратно в wiki.

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

Так исследовательская работа не исчезает вместе с историей чата.

Lint: периодическая проверка качества

Постоянная база требует контроля.

Информация устаревает. Новые источники начинают противоречить старым. Некоторые страницы оказываются изолированными. Важное понятие может встречаться в десяти документах, но отдельной страницы для него ещё нет.

Карпати предлагает периодически проверять wiki и искать:

• противоречия между страницами;
• устаревшие утверждения;
• страницы без входящих связей;
• важные понятия без собственных страниц;
• отсутствующие перекрёстные ссылки;
• пробелы в данных.

Практический запрос может выглядеть так:

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

Так существенные изменения остаются под контролем человека.

Как организовать второй мозг в Obsidian

Obsidian не входит в обязательную архитектуру LLM Wiki, но Карпати использует его в собственной схеме: LLM-агент редактирует wiki, а он параллельно просматривает страницы, переходит по ссылкам и изучает граф связей.

Для такой работы Obsidian подходит по нескольким причинам.

Vault в Obsidian представляет собой обычную папку на файловой системе. Заметки хранятся в виде Markdown-файлов, а настройки самого Obsidian — отдельно внутри служебной папки.

Один набор файлов поэтому может использоваться и человеком, и AI-агентом.

Пример структуры vault

Внутри одного vault можно создать:

inbox здесь — дополнительный рабочий раздел, которого нет в обязательной архитектуре Карпати. Он удобен как временное место для материалов, которые ещё не обработаны.

Тогда процесс выглядит так:

После обработки первичный документ остаётся среди источников, а извлечённые знания распределяются по релевантным страницам.

Внутренние ссылки помогают строить сеть знаний

Obsidian поддерживает внутренние ссылки между заметками и обратные ссылки. За счёт них отдельные страницы можно объединять в сеть связанных знаний.

Например, страница «Проблемы регистрации» может быть связана с:

• первым запуском;
• сегментом малого бизнеса;
• оттоком;
• исследованиями пользователей;
• проектом редизайна регистрации.

У такого подхода есть практическое преимущество перед жёсткой системой папок.

Один факт не приходится относить только к одной категории. Интервью может одновременно затрагивать стоимость продукта, регистрацию и особенности конкретного сегмента.

Graph view помогает увидеть структуру базы

Obsidian умеет визуализировать связи между заметками: узлы соответствуют страницам, а линии — внутренним ссылкам. Это встроенная функция Graph view.

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

Но граф стоит воспринимать как инструмент диагностики, а не как показатель качества.

Сотни связанных страниц сами по себе мало что дают. Полезность базы проявляется в другом: насколько быстро она помогает восстановить контекст и получить проверяемый ответ.

Web Clipper упрощает добавление веб-источников

Для статей и других материалов из браузера у Obsidian есть официальный Web Clipper.

Расширение позволяет сохранить веб-страницу или отдельные фрагменты непосредственно в vault. Материалы сохраняются локально; также поддерживаются шаблоны и извлечение метаданных.

В контексте LLM Wiki процесс может выглядеть так:

Карпати сам рекомендует Web Clipper как удобный способ пополнять raw.

Как организовать второй мозг без Obsidian

Obsidian удобен, но сама концепция от него не зависит.

Карпати подчёркивает, что LLM Wiki — это паттерн, а не готовая реализация. Конкретные каталоги, формат страниц и инструменты можно менять под задачу.

Поэтому минимальная версия может существовать в обычной папке на компьютере или в корпоративном файловом хранилище.

Структура остаётся той же:

В raw лежат первичные материалы.

В wiki — страницы с накопленными знаниями.

schema содержит правила.

index.md помогает ориентироваться в базе.

log.md хранит историю операций.

Разница в основном касается интерфейса. Без Obsidian не будет встроенных backlinks и графического представления связей, но для небольшого проекта это не обязательно.

Главная ошибка — создавать только резюме документов

Представим компанию, которая провела пятьдесят интервью.

После каждого разговора ИИ подготовил качественное резюме.

Получилось пятьдесят аккуратных документов.

Однако при вопросе:

всю информацию снова приходится сопоставлять.

Архив стал удобнее, но накопительной базы знаний пока нет.

Для LLM Wiki важнее, чтобы каждое новое интервью обновляло устойчивые темы:

• цена;
• регистрация;
• причины отказа;
• первый запуск;
• отдельные сегменты пользователей.

Когда новый источник меняет существующие страницы, база действительно начинает накапливать знания.

Пример: продуктовая команда восстанавливает историю решения

Команда несколько месяцев меняла процесс регистрации.

За это время накопились:

• интервью пользователей;
• результаты экспериментов;
• продуктовые исследования;
• записи обсуждений;
• принятые решения.

Через полгода возникает вопрос:

Без связанной базы ответ приходится восстанавливать из нескольких документов.

В LLM Wiki информация уже распределена по темам: регистрация, обратная связь пользователей, результаты экспериментов, история решений.

Запрос можно сформулировать так:

Восстанови историю решения убрать подтверждение телефона. Покажи исходную проблему, данные пользователей, аргументы команды и результаты после изменения.

В результате система собирает последовательность:

А каждый существенный вывод можно проверить по первичным источникам.

Практическая ценность здесь не в генерации очередного текста. База сохраняет историю принятия решений, которая обычно первой исчезает из коллективной памяти проекта.

Пример: маркетолог сохраняет язык клиентов

Маркетинговая команда регулярно собирает интервью, отзывы и обратную связь от отдела продаж.

Клиент говорит:

После нескольких внутренних пересказов эта формулировка может превратиться в:

Для аналитического отчёта этого достаточно. Для лендинга или рекламной кампании полезнее исходные слова клиента.

Если интервью сохранены в raw, а связанные наблюдения накоплены в wiki, можно спросить:

Какими словами клиенты описывают сложности при первом знакомстве с продуктом? Сгруппируй повторяющиеся формулировки и укажи первичные источники.

Так база помогает вернуть в работу исходную лексику аудитории, не подменяя её обобщениями модели.

Основной риск — накопление ошибок

Постоянная база даёт модели долгосрочный контекст. По той же причине неточности тоже могут сохраняться надолго.

Если ошибочное утверждение попало в wiki, позднее LLM способна использовать его при новых выводах.

Поэтому важно различать три уровня информации.

Первичный источник

Клиент сказал:

Зафиксированный факт

Один клиент назвал стоимость причиной отказа.

Аналитический вывод

Стоимость может быть значимым барьером для части клиентов.

Третье утверждение требует подтверждения дополнительными материалами.

Разделение raw и wiki, фиксация противоречий и регулярный lint как раз помогают контролировать эту проблему.

Качество источников важнее их количества

LLM снижает трудозатраты на обработку документов, поэтому соблазн сохранять всё подряд вполне понятен.

Но большая коллекция сама по себе не делает базу качественнее.

Слабые, устаревшие или нерелевантные источники усложняют анализ и увеличивают количество противоречий.

В модели Карпати у человека остаётся принципиальная роль: пользователь отбирает источники, определяет направление исследования и задаёт вопросы. LLM берёт на себя ведение wiki — обновление страниц, связей и служебной информации.

Хороший критерий для нового материала:

Если ответ не находится, документ необязательно включать в постоянную базу.

С корпоративными данными нужно заранее определить правила доступа

Рабочая LLM Wiki довольно быстро начинает содержать чувствительную информацию: интервью клиентов, записи внутренних встреч, договоры, финансовые показатели, планы продукта.

Obsidian хранит локальный vault как папку на устройстве пользователя, но при необходимости его можно синхронизировать через Obsidian Sync или другие поддерживаемые способы.

При этом локальное хранение файлов и их обработка внешней LLM — разные процессы.

Если AI-агент получает доступ к содержимому vault или обычной папки, необходимо отдельно учитывать условия работы выбранного AI-сервиса и корпоративные требования безопасности.

До подключения рабочих данных стоит определить:

• какие категории информации разрешено передавать модели;
• где выполняется обработка;
• кто имеет доступ к базе;
• какие материалы требуют дополнительной защиты.

Для первой версии достаточно одного проекта

Необязательно сразу переносить в LLM Wiki многолетний архив.

Для проверки подхода достаточно одного активного проекта.

Подготовьте:

• raw для первичных материалов;
• wiki для накопленных знаний;
• schema с правилами;
• index.md для навигации;
• log.md для истории операций.

После этого добавьте 5–10 актуальных источников и попросите модель определить:

• какие темы повторяются;
• что подтверждается несколькими материалами;
• где источники расходятся;
• какие страницы wiki стоит создать;
• какие существующие страницы нужно обновить.

Первые результаты лучше проверить вручную и при необходимости дополнить schema.

Затем задайте системе реальный рабочий вопрос:

Почему команда приняла это решение три месяца назад?

Если база восстанавливает контекст, показывает первичные источники и отделяет факты от аналитических выводов, значит подход уже решает практическую задачу.

Дальнейшее развитие зависит от масштаба. Можно подключить Obsidian, настроить быстрый сбор источников, добавить поиск и расширить правила ведения wiki.

Но начинать лучше не с инструментов.

Сначала стоит проверить главное: помогает ли система быстрее находить и использовать знания, которые команда уже однажды получила.