В апреле 2026 года Андреж Карпаты опубликовал на GitHub технический Gist с концепцией LLM Wiki — это вызвало интерес в отрасли. Автор статьи Фань Тяньцзяо задаётся вопросом: сможет ли LLM Wiki вытеснить традиционный RAG (ретривал-усиленное генерирование)?
Традиционная модель RAG работает по принципу «вычисления во время запроса». При импорте документов система разбивает их на фрагменты, создаёт векторы и сохраняет в векторной базе данных. При запросе пользователя система преобразует вопрос в вектор, ищет в базе релевантные фрагменты, объединяет их в контекст и передаёт вместе с вопросом в большую языковую модель (LLM) для формирования ответа. Однако у этой модели есть существенные недостатки:
* при многократном задавании одного и того же вопроса каждый раз требуется полный цикл «поиск — объединение — вывод», что ведёт к линейному росту затрат вычислительных ресурсов и токенов;
* система не накапливает выводы, качество ответа не улучшается со временем.
Концепция LLM Wiki от Карпаты предлагает обратный подход: знания компилируются один раз, затем постоянно обновляются. В результате формируется накапливаемый и развивающийся продукт знаний. Подход называется «компиляция при импорте» — основные вычислительные операции выполняются на этапе импорта документов.
Несколько команд (Cognition, Factory, LangChain) и инвестор Гарри Тан почти одновременно запустили продукты в рамках этой концепции. Проект Mem0 опубликовал статью The State of Agent Wikis, где разобрал принципы, текущее состояние и ограничения технологии.
Большие модели могут обрабатывать исходные документы: понимать смысл, выделять ключевые моменты, классифицировать знания и формировать структурированные страницы в формате Markdown. Каждая тема размещается на отдельной странице с основным резюме и семантическими ссылками между темами. При запросе пользователя система находит нужную страницу и выдаёт ответ на основе структурированных данных.
Капаси сравнивает систему так: Obsidian — это IDE, LLM — программист, вики — код-репозиторий. Вики полностью создаётся и поддерживается большой моделью, человеку нужно только предоставить исходные материалы и правила поддержки.
Mem0 описывает систему как трёхуровневую архитектуру:
1. Уровень исходных документов — первоисточники (статьи, код, регламенты), которые система только читает, не изменяя.
2. Уровень контента вики — сгенерированные большой моделью страницы Markdown с резюме, классификацией и ссылками.
3. Уровень файлов правил — документы вроде AGENTS.md, CLAUDE.md, задающие стандарты классификации, правила обновления и логику разрешения противоречий.
Основные операции системы:
* ввод — импорт новых документов, обновление информации в вики;
* запрос — ответ на вопрос пользователя на основе вики, качественные ответы могут дополнять вики;
* проверка — регулярный поиск противоречий, устаревших данных и изолированных страниц с последующей коррекцией или маркировкой.
Капаси указывает на ограничение масштаба: подход с навигацией по страницам без векторного поиска подходит для примерно 100 источников и нескольких сотен страниц. При большем объёме документов требуется смешанный поиск: BM25 (ключевые слова) + векторный поиск + LLM-пересортировка.
Четыре компании практически одновременно реализовали проект Капасси:
* Cognition DeepWiki (компания Cognition — создатель AI-программиста Devin) применяет Wiki в открытых репозиториях GitHub: пользователь заменяет github.com на deepwiki.com и видит автоматически сгенерированную вики проекта (с обзором архитектуры, индексом файлов, графом зависимостей и функцией поиска). Wiki служит базовой инфраструктурой поиска для Devin — предкомпилированным уровнем знаний для быстрого поиска кода.
* Factory AutoWiki: Wiki глубоко интегрирована в CI/CD-процесс. Генерация проходит в два этапа: структурное сканирование (чтение README, конфигурации зависимостей, CI-файлов и точки входа проекта) и семантическое сканирование (анализ маршрутов интерфейсов, сервисных классов, структуры базы данных и функциональных переключателей). Используется модель разделения труда между несколькими агентами. При коммите кода в основную ветку система автоматически перегенерирует вики, обеспечивая синхронность документации и исходного кода.
* LangChain OpenWiki — полностью открытый CLI-инструмент с двумя режимами: Code Brain (генерация документации для репозитория кода) и Personal Brain (интеграция данных из почты, заметок, соцсетей, подписок на новости и формирование локальной вики; расширение применения с документации кода до консолидации всех личных рабочих знаний).
* GBrain (Гарри Тан) — легковесное решение: работает на основе Git-репозитория, Markdown-файлов и файлов с правилами, без векторной базы данных и сложного бэкенда, автоматически создаёт граф связей между темами. Доказывает, что основа Agent Wiki — логика самостоятельного поддержания структурированных знаний LLM, а не сложная инфраструктура.
Общий принцип четырёх продуктов: основная аудитория вики-страниц — не люди, а большие модели; вывод представлен в виде оптимизированного для LLM структурированного Markdown (с чёткими заголовками, внутренними ссылками и краткими содержаниями) для максимально быстрого поиска информации агентами. Базовая архитектура продуктов: Markdown + хранение в Git + файл правил + компиляция при внесении + ориентация на чтение агентами.
Различия в механизме обновления вики: Factory использует CI-пайплайн для полностью автоматического непрерывного обновления; остальные три продукта требуют ручного выполнения команд для обновления контента, а точность базы знаний зависит от времени последнего ручного обновления.
Mem0 выделяет четыре ограничения LLM Wiki:
1. Ограничение по масштабу: порог около 100 источников информации; при превышении этого порога сложность связей между страницами растёт экспоненциально, резко увеличиваются затраты на инкрементальное обновление и полную проверку.
2. Потеря точности: в процессе предварительного компиляции (составление выдержек, обобщение) теряются детали из исходных документов, которые впоследствии невозможно восстановить; в отличие от этого, традиционный RAG при наличии исходного текста теоретически может его найти.
3. Риск неактуальности: точность контента в Wiki соответствует точности на момент последнего обновления; ошибочный контент в Wiki опаснее его отсутствия из‑за того, что структурированное представление придаёт ему ложную авторитетность; для снижения риска необходим автоматизированный процесс обновления (Factory).
4. Неэффективные затраты: затраты на создание Wiki переносятся с этапа запроса на этап ввода данных — генерация страниц Wiki, проверка, очистка противоречий, поддержка ссылок требуют токенов; если объём документов большой, а частота запросов низкая, затраты на Wiki могут превысить затраты на традиционный RAG.
Mem0 указывает на ошибочность представления о том, что Agent Wiki — это «память ИИ»: термин «память» имеет два разных значения. Wiki хорошо справляется с задачей собрания документов (знаниевый уровень): она фиксирует содержание документов, полученных в результате пакетного импорта, и выдаёт одинаковый ответ всем пользователям. Однако Wiki не способна реализовать память конкретного пользователя (уровень взаимодействия) — она не фиксирует ID пользователя, данные о его предпочтениях, прошлых решениях, неудачных подходах и т. д. Различия в моделях данных: Wiki организует знания по темам/документам, память — по пользователям; Wiki основана на пакетном импорте документов, память — на многоэтапном взаимодействии; память требует возможности исправления информации для конкретного пользователя, очистки устаревших данных, отслеживания происхождения данных, выборочного удаления — структура Wiki не подходит для этих задач.
Пример: Wiki может сообщить общие правила компании, но не будет знать о том, что «у конкретного пользователя осталось 3 дня отпуска и он подавал запрос на продление отпуска» — это пример пользовательской памяти. Mem0 демонстрирует на примере своего продукта: специальный уровень пользовательской памяти привязывает каждую запись памяти к user_id, обеспечивает перенос памяти между сессиями, приложениями, интеллектуальными агентами. Wiki и уровень памяти дополняют друг друга: Wiki сохраняет общие знания из документов, уровень памяти — персонализированную информацию пользователя.
Капаси предлагает новый подход к обработке знаний ИИ: в сценариях со стабильными документами, частыми запросами и необходимостью быстрой реакции использовать прекомпиляцию для снижения затрат и улучшения пользовательского опыта; в сценариях с изменчивыми документами, редкими запросами и высокими требованиями к точности деталей предпочтительнее традиционный RAG. Будущее — за гибридной архитектурой: для ключевых, частых и стабильных знаний использовать вики с прекомпиляцией, для редких и детализированных данных — традиционный RAG. Это не конкуренция, а эволюция технологий. Капаси открывает путь к следующему поколению AI-библиотек знаний. Ссылка
Подписаться в Макс
