Когда вики превращается в нейросетевой орган памяти
Андрей Карпати как-то обронил идею: «Сделайте вики-подобную базу знаний, где LLM сможет читать и писать свои заметки». Прозвучало красиво, но на практике такая штука быстро превращается в кашу — без структуры, без контроля доступа, без возможности нормально искать по смыслу. Проект Wiki-MCP-Server — это не просто «ещё одна вики», а полноценный распределённый граф знаний, завёрнутый в MCP-протокол. Да ещё с авторизацией, типизированными рёбрами и векторным поиском на pgvector. Давайте заглянем под капот.
Чем Wiki-MCP-Server отличается от «той самой» идеи Карпати
Оригинальная концепция Карпати — это скорее персональная записная книжка для AI. Она не предполагала одновременной работы нескольких агентов, не умела разграничивать права, а узлы хранились плоским списком. Wiki-MCP-Server идёт дальше:
- AlloyDB + pgvector — вместо SQLite или JSON-файлов. AlloyDB (управляемая PostgreSQL от Google) даёт автоматическое масштабирование, а расширение pgvector позволяет выполнять семантический поиск по эмбеддингам узлов.
- Типизированные рёбра — связи между узлами имеют тип (например,
is_related_to,depends_on,contradicts). Это превращает базу знаний в настоящий граф, а не в мешок ссылок. - Авторизация — каждый узел и ребро могут быть доступны только определённым ролям или пользователям. Критично для enterprise-среды, где AI-агенты не должны болтать лишнего.
- MCP-протокол — сервер можно подключить к любому MCP-совместимому клиенту (Claude Desktop, Cline, собственные агенты). О том, как работает этот USB-порт для ИИ, мы уже писали.
Важное уточнение: AlloyDB используется как движок базы, но сам проект полностью open-source и может быть развёрнут на любой PostgreSQL 15+ с pgvector. Никакой vendor-lock.
Сравнение с альтернативами: почему не просто RAG
Типичная RAG-система хранит документы чанками в векторной БД, но не умеет выстраивать связи между ними. Wiki-MCP-Server, напротив, хранит граф, где каждый узел — это факт или сущность, а рёбра — логические отношения. Попробуем на пальцах:
| Характеристика | Классический RAG | Wiki-MCP-Server |
|---|---|---|
| Структура данных | Чанки + вектор | Узлы + типизированные рёбра |
| Поиск | Только семантический | Семантический + графовые запросы (BFS, shortest path) |
| Авторизация | Обычно нет | RBAC на уровне узлов |
| Протокол подключения | REST / gRPC | MCP (стандартный) |
Если нужна база знаний, с которой будет работать не один LLM-агент, а целая команда — с разными правами и ролями — Wiki-MCP-Server выигрывает с разгромным счётом. Кстати, проблема безопасности MCP-серверов не надумана: мы разбирали реальные кейсы утечек, так что встроенная авторизация здесь не роскошь, а необходимость.
Как это выглядит на практике: поднимаем свой граф знаний
В репозитории есть готовый docker-compose. Клонируем, редактируем .env, запускаем — и сервер начинает слушать MCP-запросы на stdin/stdout или WebSocket. Рассмотрим простой сценарий: добавить новый факт и связать его с существующим.
1 Добавление узла
Через MCP клиент (например, Claude Desktop с настроенным MCP-сервером) отправляем инструмент add_node:
{
"name": "PostgreSQL vs AlloyDB",
"type": "comparison",
"content": "AlloyDB базируется на PostgreSQL 15, но добавляет автоскейлинг и ускоренные аналитические запросы",
"embeddings": true,
"permissions": {"roles": ["editor"]}
}2 Создание ребра между узлами
Допустим, у нас уже есть узел AlloyDB и узел PostgreSQL. Связываем их:
{
"source_id": "uuid1",
"target_id": "uuid2",
"relation_type": "based_on",
"metadata": {"strength": 0.9},
"permissions": {"roles": ["admin", "editor"]}
}Запрос к графу через инструмент query_graph: «Какие СУБД используются в AlloyDB?» — и сервер возвращает путь по ребру based_on к PostgreSQL, а также семантически близкий узел про Spanner (если включена векторная эвристика).
Warning: Не советую выставлять MCP-сервер в открытый интернет без reverse proxy и строгой аутентификации. OAuth 2.0 пока не встроен — используйте API-ключи и сетевые политики. Подробнее о рисках — в статье про prompt injection.
Кому это реально нужно (и кто лишь потратит время)
- Команды, строящие корпоративные базы знаний с AI-агентами — если у вас 50 ботов и 1000 документов, без графа развалится. Авторизация спасёт от утечки коммерческой тайны.
- Разработчики MCP-экосистемы — проект отлично сочетается с PlexMCP для объединения нескольких серверов и с MCP Tool Registry для автоматизации RAG-пайплайнов.
- Энтузиасты, которые хотят создать «вечный мозг» для своих LLM — можно прикрутить к личному помощнику, и он будет помнить всё, что вы обсуждали.
Когда не подойдёт: если вам нужна просто поисковая система по документам — проще взять стандартный RAG на Pinecone. Граф избыточен. Также если у вас один пользователь и пара десятков заметок — оверхед с авторизацией и Docker не оправдан. Но для продакшена — best practices.
Кстати, по данным нашего недавнего исследования, 52% публичных MCP-серверов мертвы, а 37% не имеют аутентификации. Wiki-MCP-Server решает обе проблемы: он живой и с авторизацией из коробки.
А что с производительностью?
AlloyDB в паре с pgvector даёт поиск по 10 млн векторов за <100 мс (тесты на стандартных инстансах). Графовые запросы (например, кратчайший путь) работают за O(log N) за счёт индексов на рёбра. Единственное узкое место — генерация эмбеддингов при добавлении узла. Если часто писать, рекомендую вынести этот шаг в отдельный worker. Проект поддерживает асинхронные хуки, так что доработка тривиальна.
Резюме: стоит ли тащить в свой стек?
Wiki-MCP-Server — редкий случай, когда open-source проект не просто копирует чужую идею, а реально дорабатывает её до production-ready состояния. Граф, MCP, авторизация, векторный поиск — всё в одном флаконе. Если вы строите AI-инфраструктуру, где знания должны быть структурированными и защищёнными, присмотритесь. А если вам лень поднимать свой сервер — MCP Chat Studio v2 умеет эмулировать такие серверы для тестов. Но для постоянной работы лучше иметь выделенный экземпляр.
