LLM-Wiki, Knowledge Base, Graph, RAG
Архитектура LLM-Wiki (Knowledge Base + Graph + RAG)
Разложу по слоям — от хранения контента до генерации ответов.
1. Слой хранения контента (Source of Truth)
Это "сырые" знания в человекочитаемом виде.
- Obsidian — отличный выбор. Markdown-файлы +
[[wikilinks]]+ backlinks + graph view "из коробки". Плюс огромная экосистема плагинов. - Альтернативы: Logseq (outliner + block references), просто папка
.mdфайлов в Git-репозитории (даёт версионирование бесплатно). - Cursor тут не совсем в тему — это AI-редактор кода, а не инструмент для ведения базы знаний. Если хочешь AI-ассистента прямо в заметках — лучше плагины Obsidian: Smart Connections, Obsidian Copilot, Text Generator. Cursor скорее пригодится, если ты сам будешь разрабатывать инструментарий вокруг вики (скрипты индексации, backend и т.д.).
2. Слой графа знаний (Graph DB)
Нужен, чтобы явные и неявные связи между сущностями (людьми, проектами, концептами) были структурированы, а не просто "текст со ссылками".
| БД | Когда выбрать |
|---|---|
| Neo4j | Дефолтный выбор. Зрелая экосистема, Cypher, встроенные Neo4j GraphRAG библиотеки, из коробки интеграция с LangChain/LlamaIndex. |
| Kuzu | Embedded (как SQLite, но графовая), не нужен сервер — хорошо для локальной personal-wiki на одном компьютере. |
| Memgraph | Если важна скорость/real-time аналитика поверх графа. |
| ArangoDB | Мульти-модельная (граф + документы + ключ-значение) — удобно, если не хочешь держать отдельно векторное и графовое хранилище. |
| NebulaGraph | Если база вырастет до миллионов узлов — распределённая, промышленный масштаб. |
Для персональной/командной вики (не enterprise-масштаб) я бы взял Neo4j (много готовых интеграций с LLM) или Kuzu, если хочется всё локально и без сервера.
3. Слой векторного поиска (для RAG)
Граф хорош для точных связей, но для "нечёткого" семантического поиска по смыслу нужны эмбеддинги.
- Qdrant или Weaviate — отдельные vector DB, быстрые, open-source, self-host.
- pgvector — если уже используешь Postgres, не хочешь плодить сервисы.
- Chroma — самый простой вход для прототипа/локальной разработки.
4. Embedding модель
- OpenAI
text-embedding-3-large/ Cohere embed-v3 — если ок с облаком. - BGE-M3, E5-large — сильные open-source варианты для локального запуска (через Ollama/HuggingFace).
5. LLM
- Claude / GPT через API — для качества ответов.
- Локально через Ollama (Llama, Qwen, Mistral) — если нужна приватность/оффлайн.
6. Оркестрация (RAG + GraphRAG)
- LlamaIndex — сильнее в property-graph индексах, есть готовый
KnowledgeGraphIndex/PropertyGraphIndex. - LangChain (+
langchain-neo4j) — больше готовых цепочек,GraphCypherQAChainдля перевода вопроса в Cypher-запрос. - Microsoft GraphRAG — если хочешь именно подход "LLM сам строит граф сущностей из текста + community summarization" — очень подходит под твой кейс "LLM строит и обслуживает вики".
Гибридный GraphRAG — практика такая: сначала vector search находит релевантные чанки → затем через граф подтягиваются связанные сущности/контекст (multi-hop) → всё это собирается в промпт LLM. Это и есть "LLM-Wiki" в полном смысле — не просто RAG по кусочкам текста, а поиск с учётом связей.
7. Пайплайн ingestion (конвейер построения графа)
Отдельный важный компонент — как из markdown-заметок Obsidian получить граф:
- Парсинг
.mdфайлов + существующих[[links]](это уже готовые рёбра графа). - LLM-based extraction (NER + relation extraction) для неявных связей — LLM читает заметку и предлагает: "сущность X связана с Y отношением Z".
- Запись сущностей/рёбер в Neo4j, чанков + эмбеддингов в Qdrant.
- Синхронизация при каждом изменении заметки (можно на git-хуках или файловом watcher'е).
8. Интерфейс
- Плагин прямо в Obsidian (custom plugin, дергает твой backend через API) — самый бесшовный UX.
- Или отдельный чат-интерфейс (Streamlit/Next.js) поверх того же backend.
Итоговый стек, который бы я взял для старта
Obsidian (заметки, markdown, wikilinks)
→ Ingestion script (Python)
→ Neo4j (граф сущностей/связей)
→ Qdrant (векторный поиск, эмбеддинги BGE или OpenAI)
→ LlamaIndex / LangChain (оркестрация, GraphRAG-запросы)
→ Claude/GPT (генерация ответа)
→ Плагин в Obsidian или свой чат-UI (интерфейс)
--------------------------------
Отлично, что сразу переходим к личной вики и к конкретному стеку — с Aspire это действительно легко собрать, не буду падать в обморок :)
Дам минимальную, но правильную архитектуру v1, где ключевая идея — агент-классификатор в реальном времени + агент-аудитор, а не нагромождение сервисов.
РИСУНОK
visualize show_widgetКомпоненты v1 (минимум, без лишнего)1. Ingestion API — .NET Aspire
Простой ASP.NET Core сервис (обычный проект в Aspire AppHost). Принимает кусок текста откуда угодно (из Obsidian через webhook/файловый watcher, из Telegram-бота, из браузерного расширения, вручную). Ничего не решает сам — просто кладёт "сырую" запись и вызывает Classification Agent.
2. Classification Agent — Python (может быть FastAPI-сервис в том же Aspire-решении)
Это ключевая идея, и вот как сделать её надёжной, а не "LLM угадал куда-то":
- Агент не придумывает категории свободно. Он получает текущее дерево тем (загруженное из Neo4j: список веток верхнего уровня → подветки → листья) и через function calling пошагово "спускается" по дереву: "Это ближе к Программированию, Музыке или Личным заметкам?" → "В Программировании — это Backend или DevOps?" и так далее. Это и есть тот самый "серфинг по графу", только выполняет его агент при размещении, а не человек.
- Параллельно считается эмбеддинг нового куска текста и сравнивается с центроидами существующих подветок (косинусное сходство). Если LLM-выбор и embedding-выбор совпадают и уверенность высокая → узел создаётся сразу.
- Если LLM "почти уверен" (например, колебался между Музыка/Звукорежиссура и Программирование/Аудио-DSP) → узел создаётся, но с флагом
needs_review=true и попадает в отдельный "inbox"-лист графа.
Это устраняет твой главный страх — что "Музыка" утечёт в "Программирование": у решения всегда есть числовой confidence, и ниже порога — не автоматика, а ревью.
3. Neo4j (с нативным vector index) — вместо связки Neo4j+Qdrant
Для старта хватит одного Neo4j — начиная с версии 5 у него есть встроенный vector index, так что не нужен отдельный Qdrant. Меньше движущихся частей — это ровно то, что ты просил.
- Aspire это поддерживает "из коробки" как container-resource (
builder.AddNeo4j(...)), поднимается вместе со всем остальным одной командой. - Neo4j Browser даёт тебе бесплатный графовый "серфинг" — можно кликать по узлам, смотреть связи, ничего дополнительно не пишешь.
4. Audit Agent — простой periodic job (IHostedService в .NET или cron-таск в Python)
Раз в день (или по требованию) проходит по недавно добавленным узлам и:
- пересчитывает их embedding-близость к соседям в ветке — если узел значительно отклоняется от центроида своей ветки, помечает как аномалию;
- может устроить "второе мнение" — попросить LLM ещё раз классифицировать узел без контекста первого решения и сравнить.
Ничего сложного — по сути SQL-like запрос + пара LLM-вызовов.
5. Obsidian — как "лицо" вики
Держи Neo4j как smart-backend, а Obsidian vault — как синхронизированное представление в markdown. Скрипт (в Ingestion API или отдельным воркером) пишет .md файл с правильными [[wikilinks]] в нужную папку вида /Программирование/Backend/. Так у тебя получается двойной "серфинг": по графу (Neo4j Browser, точный) и по заметкам (Obsidian graph view, привычный и красивый).
Cursor тут действительно не нужен — он для написания кода вокруг системы (Ingestion API, агент), а не часть рантайма вики.
Aspire AppHost — как это выглядит физически
csharpvar builder = DistributedApplication.CreateBuilder(args);
var neo4j = builder.AddNeo4j("wiki-graph")
.WithDataVolume(); // персистентность на диске
var classifier = builder.AddPythonProject("classification-agent", "../ClassificationAgent")
.WithReference(neo4j)
.WithHttpEndpoint(port: 8001);
var ingestion = builder.AddProject<Projects.IngestionApi>("ingestion-api")
.WithReference(neo4j)
.WithReference(classifier);
var auditor = builder.AddProject<Projects.AuditAgent>("audit-agent")
.WithReference(neo4j);
builder.Build().Run();
Плюс огромный бонус: Aspire Dashboard сам по себе становится твоим инструментом верификации — там видны все трейсы: "заметка пришла → LLM выбрал ветку X с confidence 0.87 → записано в Neo4j за 340мс". Не нужно городить отдельный логгер для аудита решений агента — Aspire это уже даёт бесплатно через OpenTelemetry.
Хочешь, распишу конкретно структуру Classification Agent (промпт + логика function calling по дереву тем + порог confidence) или сразу набросаю скелет Ingestion API + Neo4j-схему узлов/связей?
---------
Хороший вопрос — тут действительно нужно разделить функции честно, а не просто "визуализация vs не визуализация". Давай разберу, что Obsidian реально делает.
Что Obsidian делает на самом деле
Функция Это визуализация? Что заменяет Blazor Хранилище — заметки это просто .md файлы на диске Нет, это формат хранения Blazor ничего не хранит сам, нужна отдельная БД/файлова система Редактор — markdown с live preview, шорткаты, форматирование на лету Нет, это UX ввода данных Нужно писать свой markdown-editor компонент (Monaco/CodeMirror в Blazor) Движок связей — при наборе [[текст]] Obsidian сам индексирует backlinks локально, мгновенно, оффлайн Нет, это логика У тебя это делает Neo4j, но только когда данные туда попали — а сам ввод/автокомплит связей при печати нужно реализовывать самому Graph view Да, это чистая визуализация Заменяется Blazor + D3/vis.js без проблем Плагины (Dataview — SQL-подобные запросы по заметкам, Templater, Excalidraw, Canvas) Частично Каждый плагин — это отдельный кусок функциональности, который в Blazor придётся писать с нуля Мобильное приложение — быстрый захват мыслей с телефона, оффлайн Нет, это точка сбора данных Blazor Server/WASM тоже может быть мобильным, но UX "быстро черкнуть мысль в метро без сети" у Obsidian вылизан годами, у тебя это отдельный проект Работа офлайн без бэкенда Нет, это независимость от сервера Blazor Server требует связи с сервером; Blazor WASM может офлайн, но это уже PWA-инженерия
Вывод: Obsidian — это НЕ только визуализация
Он в первую очередь — инструмент сбора и редактирования (front-end капчура данных), и уже во вторую — визуализация связей. Именно поэтому у тебя изначально была идея "сначала данные собирать" — вот эту роль и закрывает Obsidian, причём бесплатно, за 10 минут установки, с мобильным приложением из коробки.
Рекомендация: не выбирать одно вместо другого — разделить роли
Смысла соревноваться тут нет, потому что задачи разные:
Obsidian = слой захвата и редактирования (для человека)
- Ты пишешь/правишь заметки как обычно, с телефона или ноутбука
- File watcher/плагин синхронизации отправляет новый/изменённый файл в твой Ingestion API
- Плюс: ты получаешь Dataview, Excalidraw, шаблоны и прочую экосистему бесплатно
Blazor = слой AI-операций и аналитики (control tower)
- Дашборд "очередь на ревью" — все заметки с низким confidence, которые Classification Agent не смог уверенно разложить
- Просмотр графа Neo4j как раз через D3/vis.js внутри Blazor-страницы
- Ручная коррекция классификации (кнопка "нет, это не туда")
- Статистика Audit Agent — где чаще всего путаница между ветками
- Управление самим деревом тем (создать/переименовать/слить ветки)
Это красиво ложится и на Aspire — оба сервиса просто ещё два ресурса в AppHost, Blazor обращается к тому же Neo4j:
csharpvar dashboard = builder.AddProject<Projects.WikiDashboard>("wiki-dashboard")
.WithReference(neo4j)
.WithReference(classifier);
Если ты всё же хочешь только .NET, без Obsidian
Это тоже возможный путь, но тогда "простое начало" исчезает — тебе придётся написать markdown-редактор с автокомплитом [[ссылок]], мобильный клиент, оффлайн-синхронизацию. Это не "лишний компонент вместо простого", а наоборот — реализация с нуля того, что Obsidian уже даёт бесплатно. Учитывая, что ты сам сказал "в начале не нужно ничего огромного" — я бы на твоём месте взял Obsidian именно как входную точку, а всю "умную" часть (агенты, граф, ревью) держал в своём C#/Python стеке под Aspire, где ты полностью контролируешь логику.
Хочешь — распишу конкретно, как настраивается синхронизация Obsidian → Ingestion API (там есть готовый механизм: либо через community-плагин типа "Local REST API" внутри Obsidian, либо простой file watcher поверх папки vault на сервере).
-----------
Полностью согласен с философией — маленький, понятный, законченный модуль лучше, чем размытый "комбайн на вырост". То, что уже есть (Obsidian → Ingestion API → Classification Agent → Neo4j → Audit Agent → Blazor dashboard) — это цельное, рабочее решение, на нём действительно можно поставить точку.
Но раз просишь — вот список того, что можно добавить потом, каждое как отдельный, независимый шаг (не обязательство, а меню на будущее):
Естественные продолжения (когда реально понадобятся)
1. Полноценный RAG-чат "спроси у своей вики"
Сейчас граф умеет раскладывать знания. Логичное развитие — возможность спрашивать их: "что я думал про X полгода назад", "покажи все заметки, связанные с Y". Это отдельный, самодостаточный модуль — просто ещё один Blazor-эндпоинт + вызов LLM с контекстом из Neo4j. Не меняет ничего в существующем пайплайне.
2. Дедупликация и merge похожих узлов
Со временем неизбежно появятся два узла про одно и то же ("Docker" и "Контейнеризация"). Отдельный маленький агент раз в неделю ищет пары узлов с высоким сходством эмбеддингов и предлагает тебе (через Blazor UI) объединить их. Это естественное расширение роли Audit Agent, не новая архитектура.
3. Переоценка дерева тем целиком
Пока дерево растёт органически, снизу вверх. Когда веток станет много (условно 100+), может понадобиться разовая задача: "посмотри на всё дерево и предложи реструктуризацию" — это просто ещё один batch-скрипт, не постоянный сервис.
4. Напоминания / spaced repetition поверх заметок
Если вики станет не только справочником, но и инструментом обучения — можно прикрутить простую логику "покажи мне заметку, которую я не открывал 30 дней" через тот же Blazor-дашборд. Никак не трогает граф или агентов.
5. Экспорт/публикация
Кнопка "собрать из ветки Neo4j готовый markdown-документ или мини-сайт" — пригодится, если захочешь чем-то поделиться. Отдельная, изолированная фича.
Что я бы НЕ добавлял, пока не появится явной боли
- Векторная БД отдельно от Neo4j (пока нативного vector index хватает)
- Очереди сообщений (RabbitMQ/Kafka) — для одного пользователя это оверинжиниринг
- Мультиагентные "команды" агентов — у тебя два агента (классификатор + аудитор), этого достаточно надолго
- Аутентификация/мультипользовательность — пока это личная вики, не нужно
Итог: текущая архитектура закрывает всё, что ты формулировал изначально — сбор, размещение по темам в реальном времени, проверка правильности, граф-серфинг. Всё остальное — это уже отдельные решения, которые можно пристёгивать по одному, только когда появится конкретная потребность, а не заранее. Это и есть тот самый "небольшой, упакованный" подход, который ты описал.
