Идея принадлежит Андрею Карпати: складываешь исследовательские материалы в папку, LLM читает их и сама строит вики — пишет статьи, расставляет обратные ссылки, классифицирует концепции. Его личная вики по одной теме разрослась примерно до 100 статей и 400 000 слов. Российская команда взяла этот подход за основу, но переписала инфраструктуру под другую задачу: не один человек с одной моделью, а несколько ИИ-агентов, работающих с общей базой знаний одновременно.
Главное техническое решение — замена Markdown-файлов на AlloyDB с расширением pgvector и добавление графа поверх векторного поиска. Граф содержит 72 узла и 215 рёбер 11 типов: depends_on, uses, used_in, develops, based_on и другие. Разница с чистым векторным поиском проявляется на абстрактных запросах. Запрос «Что общего у MesaNet и Titans» при векторном поиске давал 0% recall, с графом — 67%. Запрос «Ассоциативное сканирование» вырос с 50% до 100%. Средний recall по тестовой выборке поднялся с 46,7% до 68,3%, граф дополнительно нашёл 92 концепции, которые вектор пропустил. Механика понятна: граф строит цепочки — «Линейные RNN → Ассоциативное сканирование → NLM → M3 Optimizer» — три перехода по концепциям, которые семантическое сходство не улавливает.
| Аспект | Karpathy LLM Wiki | Реализация авторов |
|---|---|---|
| Хранение | Markdown-файлы в папке | AlloyDB + pgvector (SQL) |
| Связи | [[wikilinks]] в тексте | Типизированные рёбра графа (11 типов) |
| Поиск | Нет (или grep) | Векторный + графовый гибрид |
| Обновление | LLM переписывает markdown | SQL-функции + LLM-классификация из БД |
| Доступ | Локальная папка | HTTP-сервер с авторизацией |
| Мультипользовательность | Нет | Роли admin и reader |
| Протокол | — | MCP (StreamableHTTP + SSE) |
Классификация рёбер реализована прямо в базе данных через функцию plpgsql, которая вызывает Gemini через google_ml_integration — расширение AlloyDB Omni, доступное с версии 1.5.2. Один пакетный прогон классифицировал 205 нетипизированных рёбер. Стоимость — $0,01. Единственная сложность: направленность. Ребро MesaNet → Conjugate Gradient Solver — это uses или depends_on? Пришлось разделить uses (A использует B) и used_in (B применяется в A), что потребовало двойного прогона классификации.
Хранилище — AlloyDB + pgvector вместо Markdown-файлов; классификация 205 рёбер через ИИ.generate() в SQL обошлась в $0,01.
Первые версии сервера работали на stdio-транспорте MCP: процесс рождается при подключении клиента и умирает при отключении. Для CLI-утилиты это нормально, для сервера знаний, к которому обращаются три-четыре агента одновременно, — нет. В третьей версии реализована двухтранспортная архитектура в одном Express-приложении: StreamableHTTP по протоколу MCP 2025-11-25 на эндпоинте /mcp и SSE-legacy по протоколу 2024-11-05 на /mcp/sse. Сессии хранятся в памяти через InMemoryEventStore. Старые клиенты, не поддерживающие StreamableHTTP, продолжают работать через SSE без изменений.
Ролевая модель разделяет два уровня доступа — admin и reader — через Basic Auth. Ключевое архитектурное решение: ограничение реализовано не как runtime-проверка при вызове инструмента, а как фильтрация на этапе регистрации. При подключении создаётся инстанс McpServer с набором инструментов, соответствующим роли. Reader получает wiki_search, wiki_read, wiki_graph и связанные инструменты чтения. Admin дополнительно видит graph_upsert_node, graph_classify_edge, graph_dedup_edges. Инструмент, не зарегистрированный в сессии, не появляется в UI клиента и не попадает в tool_choice модели — случайный вызов мутирующего инструмента агентом-читателем исключён на уровне протокола.
Проект вырос из конкретной исследовательской задачи: авторы интегрируют блоки Titans в архитектуру Gemma 3. Titans — механизм долгосрочной памяти для трансформеров, предложенный Google в конце 2024 года как альтернатива стандартному вниманию. По мере накопления материалов потребовался инструмент, который позволял бы нескольким агентам и человеку работать с одной базой знаний без конфликтов и потери контекста. Один из агентов — OpenClaw по имени Мнемозина — получил reader-доступ и самостоятельно объяснил, почему не использует write-инструменты: они не зарегистрированы в его профиле.