A Nebula of Knowledge
An Agent-Based Learning Tool Combining Vector Search and Graph Traversal
| period | 2026 |
| type | Personal Project |
| context | RAG, MCP, and Agent study at Krafton Jungle |
| status | Local prototype · Not deployed |
Learning Paths Lost in Conversation
An LLM can quickly expand the depth and range of questions around a new subject. In that process, I often lost track of where a question began, where the topic branched, and what remained unresolved. More conversations did not make the learning path clearer. The underlying problem was a lack of structure.
A learning process can be understood through two patterns: DFS (Depth-First Search), which follows one concept in depth, and BFS (Breadth-First Search), which explores the concepts around it. I used this analogy as a framework for organizing learning and built a tool that records notes, concepts, and their relationships on a shared map.
Learniverse is a local learning prototype that structures what a user has learned and allows an Agent to read the same structure when supporting further questions and documentation.
Proximity and Connection
Relationships between knowledge were divided into two conditions: proximity, where similar ideas naturally sit close together, and connection, where ideas from different domains are linked for an explicit reason.
Proximity is represented by the distance between embeddings stored for each Note and Concept. Connections are recorded as graph relationships between Notes and Concepts and between Concepts. Similar knowledge gathers into nebula-like clusters, while semantically distant knowledge remains accessible through explicit edges.
Vector retrieval identifies the region closest to a question, and the graph supplements it with explicitly connected knowledge. People and the Agent read the same knowledge map through shared Note and Concept IDs.
A Map for People, a Structure for the Agent
Learning documents appear as square Note nodes, while their core concepts appear as circular Concept nodes. A Note appears alongside related Notes through their shared Concepts, and relationships between Concepts are displayed as separate edges.
Users can ask questions across the entire map or select specific nodes to define the reference scope. The two screens show how the same question produces different answers with and without a selected node. The nodes selected on screen and the sources used by the Agent share the same IDs.
Turning Conversation Back into Notes
For a learning-gap request, the Agent receives a board snapshot containing the current Notes, Concepts, and relationships (Links), together with any topic selected by the user. It separates what is already supported by the board from broader next topics, deeper questions about the selected subject, and candidates for the next Note. The LLM interprets missing topics and relationships visible in the snapshot, while the user decides which suggestions to adopt.
The conversation then becomes new learning material. The Agent organizes it into a title, keywords, and body text, then fills the writing interface with a draft for review. The four screens show the sequence from identifying a learning gap to continuing the conversation, generating a draft, and adding a new node. Conversation and the knowledge map form a continuous cycle.
Reading Distant Nodes Together
Users can place several distant nodes within the Agent’s reference scope. The Agent identifies shared structures and differences across the selected material, then develops the conversation into a new Note draft. Semantic distance and relationships discovered by the user remain as distinct forms of information.
Selected nodes and their neighboring relationships can be exported as Markdown or archived as a Notion page. The resulting comparison or interpretation returns to the knowledge map as a new starting point.
Notion storage is provided through both the web application’s API and Python FastMCP tools for external LLM hosts. The API creates a Markdown archive for the selected node, while the MCP server exposes tools for saving question-and-answer records and Markdown archives.
Storing Search Data and Relationships
PostgreSQL stores the original Notes, Keywords, Concepts, and embeddings, while pgvector retrieves them through L2 distance. Note–Concept and Concept–Concept relationships are projected into Neo4j. For each question, the system retrieves the five closest results across Notes and Concepts, then expands the direct Neo4j neighbors of the top three nodes by one hop.
Each retrieved source records whether it came from the vector or graph path. Graph neighbors also retain the node through which they were reached. The Note and Concept IDs shown in an answer are checked against the sources returned for that response.
Each node stores a 1,536-dimensional embedding generated with OpenAI’s text-embedding-3-small. Screen coordinates are calculated by mean-centering the embedding matrix and extracting its principal axes through SVD (Singular Value Decomposition). The first two axes form the 2D board shown in the first image, while the first three form the 3D view shown in the second. PCA projection loses part of the original distance information, so the resulting view serves as a visual aid for exploring the knowledge structure.
The final two screens show the review processes for Strict Merge and Soft Bridge. Strict Merge proposes combining Keywords and Concepts under a single Concept. Soft Bridge proposes a relationship and rationale between two Concepts that should remain distinct. Users can edit or remove each candidate, and only approved items are applied.
Two consistency problems surfaced during implementation: existing Concept Links were not fully reorganized after Strict Merge, and deleting a Note could leave data in one of the two stores. Merge operations now migrate existing relationships and remove self-referential edges, while deletion clears both the PostgreSQL data and the Neo4j projection.
ERD
Projected Coordinates and Search Distance
The initial knowledge map contained Notes on architecture, games, and development. Harry Potter and flowers were added to observe how less-related topics would be positioned, and their L2 distances in the original embedding space were compared with their locations in the 2D and 3D projections.
Both views use the same embedding matrix. The 2D view uses the first two principal axes, while the 3D view uses the first three, so their arrangements differ. A separate check confirmed that the two topics were also distant from the existing subjects and from each other in the original embedding space. This comparison distinguished screen coordinates from the distances used for retrieval.
Comparing Vector and Graph Retrieval
The evaluation focused on one question: Can graph relationships recover evidence missed by vector retrieval?
An evaluation map was built with 17 Notes, 11 Concepts, and three relationships between Concepts. The same questions were submitted through two retrieval methods.
- Vector-only retrieves the five Notes and Concepts closest to the question.
- Hybrid starts with the same results and adds one-hop graph neighbors from the top three nodes.
A question passed when the system retrieved the required source and used it to produce the correct answer.
| Question type | Vector-only | Hybrid |
|---|---|---|
| Retrieve a fact from one Note | 3/3 | 3/3 |
| Follow a connection to another item | 2/3 | 3/3 |
The difference appeared in a question asking for the condition recorded in another operational item connected to hybrid retrieval. Vector-only repeated the description of the starting node. Hybrid followed the graph to the Search Cache Concept and returned the recorded condition: TTL 900 seconds.
Both methods retrieved direct facts. Graph relationships supplied related information that fell outside the five closest vector results. This was a small comparison using 17 Notes, but it clarified the different roles of vector and graph retrieval within Learniverse.
Validation Scope and Next Priorities
Learniverse implements a workflow in which material from a conversation becomes Notes and Concepts, supports further questions through embedding proximity and graph connections, and returns to the map as new documentation. The small comparison confirmed one case in which a graph relationship recovered evidence missed by vector retrieval.
The first priority is semantic alignment between answers and evidence. The current system checks whether a cited Note or Concept ID exists in the retrieved results. The next step is to divide an answer into individual claims and determine whether each cited source supports them. This would distinguish syntactically valid citations from answers with sufficient evidence.
The second priority is failure recovery between PostgreSQL and Neo4j. Individual consistency problems found during merge and deletion have been addressed. Sequential writes can still leave the two stores out of sync if an operation is interrupted. PostgreSQL changes should be recorded as events that can be retried in Neo4j, with a reconciliation process that periodically compares both stores. This would keep the visible knowledge map and the Agent’s retrieval sources aligned.
The current map records the position of knowledge and its relationships, while the sequence of learning and the points where questions branched remain less visible. A future time layer could record the path of a deep exploration and the points where the learner returned to earlier questions.