Skip to content

OdyRAG — the knowledge-graph layer

Companion reads memory. OdyRAG is where that memory is built and tended — the knowledge-graph layer for the whole stack.

OdyRAG is the management dashboard for the stack’s LightRAG knowledge graphs. It’s served by OdyssAI-X at /odyrag and is the operator-side counterpart to Companion’s Memory: Companion queries the graphs per turn; OdyRAG is where you inspect them, ingest into them, and keep them healthy.

Powered by LightRAG.

The stack keeps knowledge in two distinct organs, and OdyRAG is the lens on both:

OrganWhat it isUsed for
Memory (LightRAG)Small, living graphs — the user / project / company tiers.”What do we already know?” — injected into chats.
Corpus (Qdrant)A large document store, embedded for retrieval.”Find me the passage” — bulk document RAG.

They answer different questions. OdyRAG manages the LightRAG side and ingests from the corpus into it when you want documents folded into the living graph.

  • Shard instances. See the running LightRAG instances and their state — the tiers (user / project / company) live here. Each is a graph you can inspect.
  • Batch inject from Qdrant. Pull a slice of the document corpus into a graph, so its facts become part of what Companion retrieves. This is the bridge from “a pile of documents” to “a queryable graph of what they say”.
  • Query the knowledge graph. Run a retrieval directly against a graph to see exactly what comes back for a question — the operator’s view of what a chat would get injected.
  • Watch ingestion. Long ingests stream progress; logs are tailable on the host (~/lightrag-alpha-ingest/logs/).

The two are the same data seen from two sides:

Companion → Memory page (read: turn on tiers, curate facts, see what's injected)
OdyssAI-X → OdyRAG dashboard (build: inspect graphs, ingest the corpus, query directly)

A user toggles and curates their memory in Companion; an operator manages the underlying graphs — and feeds documents into them — in OdyRAG.

The LightRAG stores are powerful but the on-disk JSON stores are fragile: a flush is a full, non-atomic rewrite. Treat ingestion as the moment to be careful — let a batch finish, watch the logs, and keep a backup of a graph before a large re-ingest. (The stack ships a quarantine + re-embed path from the graphml for recovery.)