LLM Wiki Карпатого: ИИ-агент, который сам ведёт вашу базу знаний

В апреле 2026-го Андрей Карпатый опубликовал на GitHub гист под названием LLM Wiki — за четыре дня 5 000 звёзд и почти 3 000 форков. В короткой записке он описал паттерн, который меняет привычное отношение к личной базе знаний: не вы спрашиваете ИИ про базу — а ИИ сам её собирает и поддерживает.

Карпатый формулирует это коротко: «Obsidian — это IDE, LLM — программист, wiki — кодовая база». То есть человек складывает сырые материалы (расшифровки, статьи, заметки, переписки), а модель компилирует из них структурированную вики со ссылками, тегами и сводками. Дальше любой запрос идёт уже не по сырому корпусу, а по дистиллированной версии.

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

Эволюция терминов: vibe coding → agentic engineering → LLM wiki

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

• Февраль 2025 — vibe coding. Один твит: «Ты не пишешь код, ты описываешь проект и принимаешь, что предлагает модель». За год термин стал общим — про то, как делать MVP за вечер.
• Февраль 2026 — agentic engineering. Логичное продолжение: тот же подход, но не один промпт, а оркестрация нескольких агентов с критиком, ревьюером и проверкой качества. Vibe coding для тех, кто наелся багов.
• Апрель 2026 — LLM wiki. Новый шаг: знания, а не код. ИИ не отвечает по корпусу — он его строит.

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

Что такое LLM Wiki технически — на одной странице

Минимальная схема — три папки и одна команда:

1. raw/ — сюда вы кидаете сырьё: транскрипты звонков, статьи в .md, переписки из Telegram-экспорта, заметки из блокнота, страницы Notion. Формат не важен, главное — текст.
2. wiki/ — компилируемая вики. По одной странице на концепт, человека, продукт, событие. У каждой страницы есть короткое определение, контекст, и ссылки на смежные страницы в виде [[название]].
3. compile.py (или скрипт на любом языке) — однократно проходит по raw/, прогоняет через LLM с инструкцией: «прочитай новые источники, обнови существующие страницы вики, заведи недостающие, проставь ссылки». Идемпотентно: запустил второй раз — изменится только то, что должно.

Дальше Obsidian, VS Code или любой markdown-редактор показывает граф связей. Вы редактируете вики руками, когда хотите. Модель достраивает остальное при следующем компиле.

Зачем это бизнесу, а не только исследователям

Карпатый придумал паттерн под себя — он читает много статей и хочет, чтобы машина за него вела глоссарий. Но в SMB у этого паттерна гораздо более жёсткое применение.

Любой бизнес копит «корпус» — даже если не называет это так. Переписки с клиентами, расшифровки звонков, статьи в блоге, обучалки для сотрудников, разборы сделок. Этот корпус обычно либо валяется в Google Drive без структуры, либо лежит в Notion с тегами, которые никто не поддерживает. Через год там 4 000 документов, в которых даже автор не помнит, что и где.

Стандартное решение — RAG (Retrieval-Augmented Generation): засунуть всё в векторный поиск и отвечать через ИИ. Это работает плохо, потому что:

• RAG достаёт отдельные куски, без связности. Ответ «вырезанный» — модель не видит общую структуру.
• Свежие документы и старые лежат вперемешку. В корпусе нет внутреннего порядка, и каждый запрос пересобирает контекст с нуля.
• Если клиент сменил цены или регламент, противоречия остаются в базе — модель будет цитировать оба варианта одновременно.
• Под капотом — векторная БД, эмбеддинги, тюнинг порога релевантности. Для команды без ML-инженера это инфраструктурный хаос.

LLM Wiki решает обратную задачу. Синтез происходит один раз, на этапе компиляции: модель прочитала 4 000 документов, обновила 80 страниц вики, проставила ссылки. Все противоречия она нашла и свела в одно место. Любой следующий запрос идёт уже по 80 страницам, а не по 4 000.

Кейс: AI-агент техподдержки для шиномонтажной сети

Самый показательный пример из моей практики — продакшен-агент для сети шиномонтажей, которая обрабатывает 500–800 сообщений в день в Telegram. Задача — отвечать клиентам без оператора в 80% случаев.

Изначально команда собиралась идти стандартным путём: pgvector, эмбеддинги OpenAI, переписки за два года, RAG-поиск. Сметная инфра — около 12 000 ₽/мес на одни только хостинг и API векторной БД.

Мы пошли по Карпатому. Экспортировали 32 000 диалогов за два года, прогнали через дистилляционный скрипт и получили на выходе:

• 74 эталонных ответа на самые частые вопросы (цена, запись, гарантия, состав услуг).
• 39 разборов возражений с готовыми контраргументами.
• Около 50 страниц вики по продуктам, услугам, скриптам.

Что мы выиграли:

1. Прозрачность. Когда агент отвечает не так, как нужно, мы видим конкретную страницу вики, которую надо поправить. В RAG-подходе пришлось бы переэмбеддить куски и угадывать порог релевантности.
2. Стоимость. Вместо 12 000 ₽/мес — стоимость API-вызовов основной модели и больше ничего. Это в 7 раз дешевле.
3. Скорость обновления. Клиент изменил цены — мы открыли одну страницу вики, поправили цифру. Без переиндексации, без перезапуска сервиса.
4. Контроль качества. Перед каждым ответом агента есть HITL-режим: оператор может одобрить или поправить. Все правки автоматически добавляются обратно в raw/ и при следующем компиле учитываются.

LLM Wiki vs RAG: чем именно отличается

Граница простая. Если ваш корпус — это документация одного продукта, переписки одного отдела, материалы одного эксперта — LLM Wiki берёт. Если вы делаете поисковик по миллиону юридических документов — RAG никуда не делся.

Как начать за один вечер

Минимальная схема для проверки на собственных материалах:

1. Создайте папку brain/ с подпапками raw/, wiki/, archive/.
2. Закиньте в raw/ 10–50 источников — статьи в .md, расшифровки, выгрузку из Notion в markdown. Любой текст.
3. Поставьте Obsidian — он бесплатный, открывает папку с markdown как graph view.
4. Поставьте Claude Code или используйте веб-чат с большим контекстом. Дайте промпт типа: «Прочитай все файлы в raw/. Для каждого ключевого концепта, человека или продукта заведи отдельную страницу в wiki/. Связывай страницы через [[название]]. Если страница уже существует — дополни её, не дублируй».
5. Открывайте граф в Obsidian, смотрите что получилось. Правьте руками то, что модель сформулировала неточно.
6. Через неделю-другую материала запустите процесс заново — модель доберёт новое, не сломав старое.

На GitHub уже есть готовые «скиллы» под Claude Code, которые делают эту работу одной командой. Поищите по запросу llm-wiki или karpathy second brain — выбирайте тот, что обновлялся в последний месяц.

Грабли, на которые я наступил

• Модель «переписывает» хорошие страницы. Если вики уже отредактирована человеком, LLM при следующем компиле может её сгладить и обезличить. Лечится явным флагом в компиляторе: «не трогай страницы со статусом locked».
• Имена концептов плывут. Один и тот же продукт в разных источниках называется по-разному, и модель создаёт две страницы вместо одной. Решение — короткий aliases.md, где вручную перечислены синонимы.
• Корпус >1000 источников не влезает в контекст. Тут нужен инкрементальный режим: компилировать пачками по дате, держать индекс уже обработанного, не переразбирать всё с нуля.
• Граф разрастается в спагетти. Через месяц-другой нужно ручное прореживание: удалить случайные стабы, оставить 5–10 «хабовых» страниц с высокой степенью связности.

Главный вывод

Карпатый раз в год выдаёт термин, который смещает рамку обсуждения. В 2025-м это был vibe coding — «модель может за вас писать код». В 2026-м это LLM Wiki — «модель может за вас вести базу знаний». Между этими двумя шагами весь бизнес наконец-то получает понятную инструкцию: не строить векторные поиски ради красивых демо, а превращать корпус в простую вики и пользоваться ей напрямую.

Это не теория. Один продакшен-агент с 113 пунктами KB в стандартном промпте делает работу, под которую месяц назад мы бы строили инфраструктуру за 12 000 ₽/мес. Так что главный вопрос на 2026 год — что в вашей компании ещё лежит мешком и ждёт собственной вики.

Тем, кто хочет копнуть глубже в актуальные модели для этого паттерна — сравнение Claude Opus 4.7 и GPT-5.5 на 18 мая 2026.

Частые вопросы