LLM Wiki: понимание новой архитектуры знаний ИИ

LLM Wiki при загрузке компилирует ваши источники в постоянную, перекрёстно связанную базу знаний, а затем отвечает, опираясь на неё, вместо того чтобы каждый раз заново извлекать «сырые» фрагменты. Так знания накапливаются по мере добавления источников, а не перестраиваются с нуля при каждом вопросе.

Я расскажу, откуда взялась идея LLM Wiki, как она соотносится с Retrieval-Augmented Generation (RAG) и действительно ли она меняет подход к управлению знаниями в ИИ-системах.

Происхождение концепции LLM Wiki

Идея LLM Wiki оформилась в 2026 году: её представил Андрей Карпати, а затем её подхватили несколько open-source проектов, превратив в то, что можно реально запустить.

Идея проста. ИИ-системы в 2026 году большую часть времени заново перечитывают одни и те же документы. Вы загружаете PDF, модель извлекает фрагменты, отвечает на вопрос и идёт дальше. Через неделю вы загружаете другой PDF по той же теме — и модель делает ровно то же самое. Ничего не переносится.

Главное изменение в том, что извлечение и компиляция — это разные задачи.

Например:

• Системы с приоритетом извлечения находят релевантные фрагменты текста в момент запроса и передают их модели как контекст. Модель работает с тем, что достал ретривер.
• Системы с приоритетом компиляции читают каждый источник один раз при загрузке, извлекают важное и записывают это в структурированную базу знаний. Затем модель отвечает, опираясь на эту базу.

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

Это первый конкретный разрыв с парадигмой приоритета извлечения, доминировавшей с тех пор, как RAG стал стандартом. В RAG каждый запрос — это новое обращение к «сырым» документам. LLM Wiki делает основную работу при загрузке, а во время запроса читает уже продуманную базу.

Что такое LLM Wiki?

LLM Wiki — это постоянная база знаний под управлением ИИ, которая непрерывно синтезирует информацию из исходных документов в структурированные, взаимосвязанные страницы.

Её отличают от папки с файлами или векторного хранилища три вещи.

• Постоянство: Страницы создаются один раз и обновляются по мере поступления новых источников. Ничего не нужно заново выводить во время запроса, потому что синтез уже записан.
• Непрерывные обновления: Каждый загруженный источник вызывает правки по всей вики: новые страницы для новых сущностей, обновления существующих сводок, пометки там, где свежие данные противоречат старым утверждениям.
• Две аудитории: Страницы читаемы для людей и достаточно структурированы, чтобы по ним могли рассуждать ИИ-агенты. Markdown, перекрёстные ссылки и единообразный макет работают на обе цели.

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

Архитектура LLM Wiki

Скорее это конвейер из трёх стадий. Источники поступают, модель компилирует их в вики-страницы, а ИИ-приложения читают эти страницы. 

Архитектура LLM Wiki

Пройдёмся по всем стадиям.

Исходные документы

Можно загружать любой текстовый материал. Например:

• Документацию и PDF
• Личные заметки и расшифровки встреч
• Репозитории кода
• Веб-контент, вырезанный из статей или полученный парсингом сайтов

«Сырые» источники помещаются в неизменяемое хранилище. После загрузки модель читает их, но никогда не модифицирует, что обеспечивает чистый аудит-трейл от любого утверждения вики к его источнику.

Компиляция знаний

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

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

Один загруженный источник может «обновить» 10–15 страниц за проход. В этом и смысл: работа по соединению нового материала с существующими знаниями выполняется один раз — при загрузке, а не при каждом запросе, как в RAG.

ИИ-приложения

Вики рассчитана на несколько типов потребителей. Например:

• Чат-системы, которые отвечают на вопросы по скомпилированным знаниям, а не по «сырым» документам.
• Исследовательские ассистенты, которые следуют перекрёстным ссылкам, чтобы выстроить целостную картину темы.
• Программные агенты, использующие вики как долговременную память при длительных задачах.
• Корпоративные системы знаний, которые предоставляют вики внутренним инструментам, дашбордам или MCP-серверам.

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

LLM Wiki и традиционный RAG

Главное отличие между традиционным RAG и LLM Wiki — когда выполняется работа.

Традиционный RAG

RAG извлекает фрагменты документов в момент запроса. Вы задаёте вопрос, поиск по эмбеддингам достаёт top‑k наиболее релевантных фрагментов из векторного хранилища, и эти фрагменты добавляются в контекст модели вместе с вашим вопросом. Модель генерирует ответ из этого временного контекста и забывает всё по завершении ответа.

Контекст одноразовый. 

Фрагменты, которые отвечали на ваш последний вопрос, исчезают из контекста сразу после того, как модель завершит ответ. Если вы зададите связанный вопрос завтра, ретривер снова запустится, снова извлечёт фрагменты, и модель снова выполнит синтез. Между запросами ничего не накапливается.

LLM Wiki

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

Знания устойчивы и эволюционируют. 

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

Компромиссы

Ни один подход не лучше во всех случаях. Они оптимизированы под разное.

Вот о чём стоит помнить:

• Актуальность: у RAG здесь преимущество, потому что он читает источники прямо во время запроса. Если вы обновили исходные документы, следующий запрос увидит изменения сразу. LLM Wiki нужно повторно загружать источники, чтобы обновить страницы, — возникает лаг между «сырой» истиной и скомпилированными знаниями.
• Точность: LLM Wiki выигрывает, когда вопросы требуют синтеза по множеству источников, потому что синтез уже выполнен и проверен. RAG может упускать связи, если релевантные фрагменты превышают размер окна контекста: модель ни разу не видит целостную картину.
• Сопровождение: после настройки векторного хранилища RAG почти не требует ухода, так как индексирование механическое. LLM Wiki нуждается в активной поддержке: проходах линтера для поиска устаревших утверждений, проверках на противоречия, периодических ревью для «обрезки» сиротских страниц. Зато поддерживаемая вики со временем богатеет, тогда как индекс RAG остаётся плоским.
• Масштабируемость: RAG предсказуемо масштабируется с числом документов, потому что извлечение — это задача поиска. LLM Wiki масштабируется вместе со способностью модели поддерживать целостность скомпилированных знаний по мере роста. За определённым размером виким нужны собственные индекс-файлы, инструменты поиска или слои эмбеддингов для навигации.

Краткое сравнение бок о бок:

LLM Wiki против RAG

На практике RAG и LLM Wiki тоже взаимодополняемы. Некоторые реализации запускают RAG поверх самой вики, когда она перерастает возможности индекс-файла.

Почему ИИ-агентам полезна LLM Wiki

ИИ-агенты страдают от проблемы отсутствия памяти сильнее, чем чат-системы. Один диалог может терпеть повторные извлечения, но агенты могут работать часами или днями и заново «открывать» те же факты в десятках задач. LLM Wiki даёт им место, куда складывать выученное, чтобы не учить это снова.

Вот несколько областей, где устойчивые знания показывают наибольший потенциал:

• Разработка ПО: кодовый агент, работающий с кодовой базой неделями, накапливает знания о модулях, соглашениях, прошлых багах и архитектурных решениях. Без вики этот контекст приходится восстанавливать в каждой сессии. С вики агент читает скомпилированные страницы и продолжает с того места, где остановилась предыдущая сессия.
• Длительные исследования: агент, отслеживающий тему по сотням статей, не может удерживать всё в контексте. Вики даёт место для хранения сводок и возвращения к разворачивающейся картине без перечитывания всего корпуса.
• Корпоративные ассистенты: ассистенты внутри компании сталкиваются с одними и теми же вопросами от разных сотрудников каждый день. Вики позволяет отвечать из скомпилированных внутренних знаний, а не искать одни и те же страницы при каждом запросе.
• Организационная память: команды теряют контекст, когда люди уходят или встречи заканчиваются. LLM Wiki, питаемая транскриптами, тикетами и документами, сохраняет эти связи.

При корректной реализации вы увидите отдачу от LLM Wiki в трёх местах:

1. Меньше повторных поисков: агент, читающий скомпилированную страницу, не запускает тот же веб-поиск или векторный запрос, что вчера.
2. Богаче контекст: страницы вики уже содержат синтезированную информацию, поэтому агент начинает каждую задачу с более плотной и связной базы, чем дали бы «сырые» фрагменты.
3. Кумулятивное обучение: каждая сессия добавляет что-то в вики, и следующая сессия пользуется выводами предыдущей. Так агент со временем действительно становится лучше в своей работе, а не «обнуляется» каждым промптом.

Построение LLM Wiki

Рабочий процесс — это цикл. Источники поступают, страницы пишутся и переписываются, а вся система уточняется по мере роста корпуса.

Цикл построения LLM Wiki

• Загрузите документы. Первый шаг — поместить источники в «сырое» хранилище. Документы читаются один раз и остаются неизменяемыми, чтобы каждое последующее утверждение можно было отследить до конкретного источника. Загрузка может быть одиночным файлом, пакетом или потоком из папки, за которой следит модель.
• Идентифицируйте сущности и концепции. Для каждого нового источника модель извлекает важное: именованные сущности, ключевые концепции, утверждения, определения, взаимосвязи. В этот момент неструктурированный текст становится тем, что вики может «положить по полочкам». Проход извлечения также сверяется с существующей вики: что уже покрыто, а что новое.
• Создавайте или обновляйте страницы. Новые сущности получают новые страницы. Существующие страницы дополняются новой информацией. Если новый источник противоречит существующему утверждению, модель помечает это на странице, а не перезаписывает. Один загруженный источник часто изменяет 10–15 страниц, потому что источники обычно затрагивают сразу несколько тем.
• Поддерживайте ссылки. Перекрёстные ссылки добавляются в обе стороны, чтобы страницы оставались связанными. Если новая страница о RAG упоминает векторные базы данных, а страница vector databases уже существует, обе страницы связываются.
• Непрерывно уточняйте знания. Периодические «линт»-проходы ловят накопившиеся со временем проблемы: противоречия между страницами, устаревшие утверждения, заменённые новыми источниками, сиротские страницы без входящих ссылок и важные концепции, упомянутые мимоходом и не имеющие собственной страницы. Это поддерживает «здоровье» вики при масштабировании.

Подробности зависят от вашего стека, но контур одинаков везде: загрузка, извлечение, запись, связывание, уточнение — и по кругу.

Общие функции систем LLM Wiki

Большинство реализаций LLM Wiki имеют схожий набор функций. Детали различаются, но строительные блоки общие для проектов.

Автоматическая компиляция знаний

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

Связанные страницы

Каждая страница связана с родственными через перекрёстные ссылки. Когда страница о transformers упоминает attention mechanisms, обе страницы ссылаются друг на друга. Получается навигируемый граф, по которому можно «гулять» по ссылкам, находя связи, о которых вы не знали.

Атрибуция источников

Каждое утверждение на каждой странице отслеживается до конкретного источника. «Сырые» документы остаются неизменными, так что вы всегда можете проверить, откуда пришла информация. Это важно по двум причинам: даёт аудит-трейл для верификации точности и позволяет модели чисто отзывать утверждения при удалении источника.

Графы знаний

Связанная структура вики сама по себе является графом знаний. Узлы — это страницы, рёбра — перекрёстные ссылки, а форма графа показывает, о чём на самом деле корпус. Автоматически проявятся «хаб»-страницы вокруг ключевых концепций, сиротские страницы подсветят пробелы, а плотные кластеры покажут области, которые вики знает лучше всего.

Постоянная память

Вики доступна между сессиями. Контекст чата исчезает после окончания разговора, а страницы вики лежат на диске в виде markdown. Это и превращает чат-модель в нечто, способное переносить знания через дни, проекты и запуски агентов.

Непрерывные обновления

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

Эти функции не независимы. Вики без атрибуции источников не вызывает доверия. Так же, вики без непрерывных обновлений черствеет, а вики без перекрёстных ссылок — это просто папка со сводками. Ценность возникает, когда все элементы работают вместе.

Практические применения LLM Wiki

Описанный паттерн общий, поэтому далее — примеры реальных применений, где LLM Wiki может быть полезна, иногда даже полезнее RAG.

Научная литература

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

Инженерная документация

В кодовых базах есть «долг» по документации, который обычно растёт каждый спринт. Часто решения принимаются в тредах Slack, архитектурные заметки хранятся в чьём-то Notion. Единственный гарантированно актуальный источник — сам код. Вики, питаемая кодовой базой, комментариями, pull request'ами и внутренними документами, может собрать картину системы, связанную с кодом. Инженеры могут задавать вопросы вики, а не искать автора модуля трёхлетней давности.

Корпоративные базы знаний

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

Персональное управление знаниями

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

Память ИИ-агентов

Агентам, работающим часами или днями, нужно место, куда складывать выученное. Вики даёт им долговременную память между сессиями — что сработало, что нет, какие файлы уже прочитаны, какие пути уже пробованы. Это особенно полезно для агентов, построенных поверх Claude Code или похожих тулов, когда с одной и той же кодовой базой работают во многих сессиях, и контекст предыдущих запусков делает текущий запуск эффективнее.

Текущие реализации LLM Wiki

В 2026 году пространство LLM Wiki ещё на ранней стадии. Большинство решений — open-source и созданы отдельными авторами или небольшими командами. До уровня RAG ещё далеко.

Оригинальный gist Карпати — отправная точка для многих разработчиков. В нём достаточно деталей, чтобы любой владелец ИИ-агента мог построить свою версию, просто вставив документ в Claude Code или похожий инструмент. Большинство текущих вики начинаются как персональные проекты на базе общей идеи.

Open-source-инициативы — место, где идея обкатывается. Такие проекты, как llm-wiki.net, публикуют свой код под свободными лицензиями, чтобы другие могли форкать, расширять и адаптировать под свои процессы. Преимущество — вы видите, что именно делает вики, и можете менять поведение, когда ваши нужды не совпадают с умолчаниями.

Подходы «local‑first» работают полностью на вашей машине. Источники сохраняются на диске, вики — это папка с файлами markdown, а модель читает и пишет через локального агента. Obsidian — самый распространённый фронтенд, так как он изначально про markdown и перекрёстные ссылки. Это даёт максимальный контроль: источники не покидают вашу машину, и вы можете проверить каждую страницу, написанную моделью.

Хостинговые реализации начинают появляться, но их меньше. Паттерн хуже ложится на SaaS, чем RAG, потому что вики должна быть вашей — ваши источники, ваши страницы, ваши правила отбора. Хостинговые версии лучше работают для командных вики, где ценность общих знаний перевешивает стоимость размещения источников на чужой инфраструктуре.

Но на июль 2026 года ни одна из них не закончена. Многое ещё проясняется, и большинство существующих проектов — прототипы.

Преимущества и ограничения

У паттерна LLM Wiki есть сильные стороны и издержки. Оба аспекта стоит знать перед тем, как решать, строить ли его.

Преимущества

• Устойчивые знания: вики доступна и после завершения отдельной сессии. То, к чему модель пришла в прошлом месяце, остаётся на странице сегодня, и новая работа строится поверх этого, а не начинается с нуля.
• Повторно используемый синтез: работа по связыванию источников выполняется один раз — при загрузке. Каждый последующий запрос читает скомпилированный результат, а не делает повторный синтез из «сырого» текста. Это экономит вычисления и даёт лучшие ответы, потому что «думать» модель уже успела.
• Меньше повторных извлечений: если по теме уже есть страница, вики не нужно каждый раз искать по «сырому» корпусу. Это важно для агентов, работающих часами и иначе запускающих одни и те же поиски снова и снова.
• Структурированная организация: страницы и перекрёстные ссылки дают нечто, что можно просматривать и осмыслять — особенно по сравнению с папкой PDF.

Ограничения

• Поддержание актуальности: вики нужно повторно загружать при изменении источников. Если документ обновлён, а вы не перезапустили загрузку, вики продолжит ссылаться на старую версию. В RAG этой проблемы нет: он читает «живые» источники в момент запроса.
• Сложности верификации: каждое утверждение на странице написано моделью. Атрибуция источников помогает, но всё равно нужно доверять тому, что модель корректно суммировала источник.
• Сопровождение: проверки на противоречия и повторные загрузки не бесплатны. Неподдерживаемая вики черствеет, а сопровождение требует времени и вычислений, даже если основную работу делает модель.
• Возможный «дрейф» знаний: при каждой загрузке модель может вносить небольшие ошибки. За сотни загрузок они могут накапливаться. Страница, начавшаяся точной, со временем может стать слегка неверной после достаточного числа правок.

Распространённые заблуждения об LLM Wiki

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

LLM Wiki заменяет RAG

Нет. Эти подходы решают разные задачи. RAG — для быстрого поиска по часто меняющемуся корпусу. LLM Wiki — для наращивания корпуса знаний со временем. Многие реальные системы используют оба: RAG — для «свежести» по «сырым» источникам, вики — для скомпилированного синтеза поверх них.

Это просто ещё одна векторная база данных

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

Базу знаний не нужно обновлять

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

Это полезно только ИИ-агентам

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

Станут ли LLM Wiki новой архитектурой ИИ?

Пока рано говорить, но вероятный путь понятен: устойчивые знания не заменят системы с приоритетом извлечения, а станут рядом с ними: RAG — для «живых» запросов, вики — для скомпилированного, долгоживущего контекста. Бóльшие открытые вопросы — валидация и масштаб: никто ещё полностью не решил, как ловить ошибки модели, попавшие на страницы вики, и никто не нагрузочно проверил паттерн на очень больших вики. MCP выглядит естественным способом «показать» вики агентам, но в энтерпрайзе принятие дальше, учитывая повышенные требования к доверию.

Паттерн ещё не устоялся. Его дальнейшая судьба зависит от того, удастся ли решить задачи сопровождения и валидации. Больше ответов — в FAQ ниже.

Заключение

LLM Wiki — одна из самых интересных идей 2026 года, потому что она меняет то, что делает ИИ-система, когда вы даёте ей источник. Вместо того чтобы перечитывать одни и те же документы при каждом запросе, модель читает их один раз и фиксирует в базе знаний, которая с течением времени становится только лучше.

Концепция ещё формируется, текущие реализации — ранние, но идея многообещающая и указывает на более широкий тренд. ИИ-системы переходят от «одноразового» контекста к устойчивым знаниям, и LLM Wiki — одна из первых серьёзных попыток показать, как это выглядит на практике.

Если вы хотите быть в курсе новинок, но находите тему запутанной, запишитесь на наш трек AI Fundamentals. Вы разберётесь в терминологии и сможете эффективно применять ИИ в работе.