Вы когда-нибудь пытались заставить LLM вести конспекты? Я тоже. Получается каша из маркдауна, потерянных фактов и одинаковых абзацев про одно и то же. Андрей Карпати когда-то обронил идею: «Сделайте вики-подобную базу знаний, где LLM сможет читать и писать свои заметки». Прозвучало красиво, но на практике такая штука быстро превращается в плоский список без структуры. А ещё она не умеет сама себя чинить.
Встречайте Wiki-MCP-Server — не просто очередная «вики для ИИ», а полноценный граф знаний, завёрнутый в MCP-протокол, с типизированными связями и гибридным поиском. Он сам решает, что забыть, а что запомнить. И да, он не просит у Google разрешения думать.
Идея Карпати — это персональная записная книжка для одного агента. Wiki-MCP-Server — распределённый орган памяти для целой армии AI-агентов. Разница — как между блокнотом и нейросетью.
Что под капотом? Три кита, на которых всё держится
Первый кит — AlloyDB + pgvector. Не SQLite, не JSON-файлы. AlloyDB (управляемая PostgreSQL от Google) автоматически масштабируется, а расширение pgvector даёт семантический поиск по эмбеддингам узлов. Это значит, что LLM может спросить «что я думаю про отказоустойчивость?» и получить не просто список тегов, а осмысленные факты, отсортированные по релевантности.
Второй кит — типизированные рёбра. Связи между узлами имеют тип: is_related_to, depends_on, contradicts. Просто «узел А ссылается на узел Б» — это для слабаков. Типизация превращает базу в настоящий граф, где можно ходить по логическим цепочкам. Например, если LLM нашла противоречие, она не просто запишет «это противоречит тому», а создаст ребро contradicts и автоматически перепроверит соседние узлы.
Третий кит — авторизация и MCP-протокол. Каждый узел и ребро живут в своём пространстве имён. Роли, пользователи, права доступа — критично для enterprise, где один AI-агент не должен видеть зарплаты другого. А MCP-протокол (о его возможностях мы писали в руководстве по Resources) позволяет подключить сервер к любому клиенту: Claude Desktop, Cline, кастомные агенты.
Почему не RAG? Спойлер: RAG не держит связи
Типичная RAG-система режет документы на чанки, пихает их в векторную БД и надеется на лучшее. Она не знает, что «закон Ома» и «сопротивление проводника» — это одно и то же, просто сказанное разными словами. RAG не умеет выстраивать логические цепочки между фактами. А Wiki-MCP-Server умеет. Более того, он автоматически создаёт ребро между новым фактом и уже существующим, если LLM решит, что они связаны. Вуаля — самоподдерживающаяся структура.
Не советую строить такую базу, если у вас 50 документов и меняются они раз в год. Овчинка выделки не стоит. Но если у вас 10 000+ фактов и 20 агентов, которые ежедневно их перетирают — это единственный способ не утонуть в шуме.
Сравнение с другими подходами:
| Подход | Связи между сущностями | Семантический поиск | Автоматическое обслуживание |
|---|---|---|---|
| Плоский список (Karpathy) | Только текст | Нет | Нет |
| RAG (векторные чанки) | Нет | Да | Нет |
| Neo4j + LLM | Да (но ручные) | Требует доработки | Нет |
| Wiki-MCP-Server | Типизированные, автоматические | Гибрид (векторы + граф) | Да (самопротиворечие, мерж) |
Как это работает на практике? Берём и делаем
Допустим, вы хотите, чтобы ваша LLM-команда поддерживала внутреннюю базу знаний по микросервисной архитектуре. Вы поднимаете сервер на любой PostgreSQL 15+ с pgvector, настраиваете MCP-клиент (например, через MCP Hangar) и даёте агентам инструменты: create_node, link_nodes, query_graph.
Вот как выглядит типичная сессия:
# Агент A пишет заметку о новом сервисе
mcp-cli call create_node \
--type "service" \
--content "PaymentGateway: обрабатывает платежи, использует Stripe API" \
--embedding auto
# Агент B находит старый узел про Stripe и создаёт связь
mcp-cli call link_nodes \
--from "PaymentGateway" \
--to "StripeIntegration" \
--type "depends_on"
# Любой агент делает семантический запрос
mcp-cli call query_graph \
"какие сервисы зависят от внешних платёжных провайдеров?"
В ответ сервер возвращает не просто список, а цепочку узлов с указанием типа связи. LLM может пройти по ней, проверить актуальность и, если нужно, переписать узел. Всё автоматически индексируется, дубли схлопываются, противоречия подсвечиваются.
Кстати, о подсветке противоречий — это отдельная фича. Когда агент добавляет факт, который конфликтует с существующим, сервер не просто пишет «конфликт», а создаёт ребро contradicts и помечает оба узла как «требуют верификации». Затем другой агент (или человек) может разрешить конфликт, и ребро перекрасится в resolved_contradiction. Граф учится сам себя лечить.
Wiki-MCP-Server open-source, никакого vendor-lock. AlloyDB используется как пример, но код работает на любой PostgreSQL 15+ с pgvector. Поднять можно на своём железе или в облаке — локальный ИИ за бетонной стеной.
Кому это реально нужно? Чёткий портрет пользователя
- AI-инженеры и команды MLOps, у которых десятки агентов и сотни тысяч фактов. Когда контекстное окно LLM уже не спасает, а RAG начинает галлюцинировать — граф вытягивает.
- Enterprise-проекты с жёсткими требованиями к доступу. Типизированные рёбра и авторизация позволяют разграничить информацию между отделами. Топ-менеджмент не видит код, разработчики не видят стратегию.
- Энтузиасты автоматизации, которые уже выбросили Ansible и Jenkins в окно в пользу MCP и локальных LLM. База знаний — следующий логический шаг.
Но есть нюанс. Если вы единственный разработчик в стартапе — не стройте сразу сложный граф. Начните с плоской вики и только когда заметите, что факты начинают дублироваться, а LLM теряет нить — переходите на Wiki-MCP-Server. Иначе рискуете потратить неделю на настройку типов рёбер, которые никогда не пригодятся.
Одна из самых частых ошибок — пытаться хранить всё. Не надо. Храните только факты, которые могут быть переиспользованы другими агентами. Временные заметки, логи ошибок, черновики — в мусор. Граф должен быть дистиллятом знаний, а не свалкой.
А что если LLM начнёт врать? Как сервер борется с галлюцинациями
Сервер не доверяет LLM на слово. Каждый узел содержит метаданные: источник (какой агент создал), время жизни, уровень достоверности. Если агент пытается перезаписать узел с высоким уровнем достоверности без явного разрешения — сервер блокирует операцию и запрашивает подтверждение у человека или другого агента. Это похоже на механизм, описанный в mcp-context-proxy, но на уровне графа.
Более того, если два агента спорят по одному факту, сервер запускает автоматическую процедуру верификации: ищет третий источник (через внешние API или базы) и голосует. Если консенсус не достигнут — узел помечается как «спорный» и исключается из семантического поиска до разрешения.
Совет напоследок: не пытайтесь объять необъятное
Когда я впервые развернул Wiki-MCP-Server, я сразу начал пихать в него всё: документацию, переписку, историю коммитов. Через неделю граф запутался настолько, что любой запрос возвращал 95% шума. Пришлось откатиться и начать с малого: 100 самых важных фактов, 50 типов связей. И только когда система прошла «тест на самоподдержку» — новый факт органично встраивался без дублирования — я расширил базу.
Не повторяйте моих ошибок. Сделайте минимальный граф, дайте агентам с ним поиграть, посмотрите, какие связи рождаются спонтанно. Только после этого добавляйте новые типы узлов и рёбер. Граф — живая структура, он должен расти естественно, а не по плану.
И да, про индексацию кода в граф знаний и MCP Tool Registry — это близкие темы, которые стоит изучить, если хотите автоматизировать всю цепочку. Wiki-MCP-Server лишь один кирпич в стене самоподдерживающегося ИИ.
