Knowledge Graph Planning
2025-03-302 turns5,992 charsgpt-4o
Summary
Building a FastAPI backend to process markdown files into a knowledge graph using chunking and networkx.
Messages
So here is what I am trying to build so I can rubber duck this.
FastAPI backend using uvicorn chromadb sql_alchemy networkx which takes from the next.js frontend's react-dropzone any .md file I input
Then I implement chunking of the .md file in order for it to extract concepts from the .md files stored as embeddings in the chromadb with id, name, description, embedding and any other meta data I want. Then using networkx I can get all relationships and use those as edges and the concepts generated along with the metadata as the nodes for the graph.
Then I can add the rest of the logic for the knowledge graph in the KnowledgeGraph class, like get_prerequisites, get_next_concept, get_learning_path, recommend_next_concept
I could have another service for the llm calls using ollama, local mistral usually ends up being the best balance for my set up at least.
I can include all of the llm calls in a class like LLMService so I can easily add or edit the prompts.
Then I could have an embedding service using sentence_transformers to generate embeddings for when I add db entries to the vector store.
I can use sqlalchemy to create the models.
The whole concept is that you can upload your .md files and it will construct a knowledge graph which you can interact with a chat window in the next.js frontend which will generate lessons based on the content of the .md files.
So what I need to do next in planning this out...
The flow is you upload .md files. Display the knowledge graph using ReactFlow with a chat window to interact with the knowledge graph is what I think the frontend should be.
Then the backend is FastAPI which accepts the .md files at an API endpoint. It then chunks and processes the sections/concepts from each .md file. It uses SentenceTransformers to generate the embeddings and stores it in the chromadb with the metadata. Then using networkx I would construct the graph with the nodes being the concepts extracted from the .md files and the edges being the relationships between concepts. The knowledge graph API would have get_prequisites get_next_concept get_learning_path recommend_next_concept etc endpoints.
The LLM will be Ollama with Mistral. It will generate the summaries, quizzes and lessons from each node. I will then be able to query the knowledge graph via the chat interface.
The database will be sqlalchemy to store the knowledge graph relationships and then store the metadata and embeddings in ChromaDB.
So next I need to define the chunking strategy, I posted about that earlier, I can reference that. Then I have to decide on what metadata I want for the nodes and what types of relationships between concepts I want to track. I need to chunk based on concepts rather than a more simple method. I need to figure out how I am going to weigh the edges of the graph.
I need to define the prompt templates for the llm service and the API structure. Something like /generate_lesson, /summarize_concept etc. I need to finalize the sqlalchemy models and define the fastapi routes. Then I could test it.
Thanks for helping me think that through.
That sounds like an awesome and well-structured plan! You’ve broken it down methodically, and you already have a solid roadmap. A few thoughts to refine and optimize your next steps:
### 1. **Chunking Strategy**
- Since you want to chunk based on concepts rather than a simple fixed-size approach, you might consider:
- **Header-based chunking** (`##` in Markdown): Treat each section as a separate concept.
- **Semantic chunking** using an embedding model: Cluster sentences that are conceptually similar.
- **Hybrid approach**: Use headers as primary splits, but refine with semantic chunking.
- **Sliding window approach** for continuity, ensuring overlapping context.
### 2. **Metadata for Nodes**
- Each concept (node) should have:
- `id`: Unique identifier
- `name`: Concept title (from headers or LLM extraction)
- `description`: Summary of the concept
- `embedding`: Vector representation (from `SentenceTransformers`)
- `dependencies`: Links to prerequisite concepts
- `examples`: Real-world applications or use cases
- `related_concepts`: Similar or supporting ideas
### 3. **Defining Relationships (Edges)**
- **Prerequisite (`prereq`)**: A → B if understanding A is required for B.
- **Supporting (`related`)**: Concepts that enhance understanding but aren’t required.
- **Contrasting (`contrast`)**: Opposing or alternative views.
- **Sequential (`next`)**: Ordered learning path.
> **Edge Weighting**:
- You could use cosine similarity of embeddings to determine relatedness.
- Frequency of co-occurrence in Markdown sections.
- LLM-generated scores (e.g., ask Mistral to rank concept importance).
### 4. **API Structure**
- **Markdown Processing**
- `/upload_md` (POST) → Accepts `.md` file, extracts concepts, generates embeddings, and updates the graph.
- **Graph API**
- `/get_prerequisites/{concept_id}`
- `/get_next_concept/{concept_id}`
- `/get_learning_path/{concept_id}`
- `/recommend_next_concept`
- **LLM Services**
- `/generate_lesson/{concept_id}`
- `/summarize_concept/{concept_id}`
- `/generate_quiz/{concept_id}`
- **Chat**
- `/chat` (POST) → Queries knowledge graph for explanations.
### 5. **SQLAlchemy Models**
- `Concept` (Nodes)
- `Edge` (Relationships)
- `Metadata` (Stores concept info, embeddings in ChromaDB)
### 6. **Frontend (Next.js)**
- **ReactFlow for visualization**: Display knowledge graph dynamically.
- **Chat interface**: Query concepts dynamically and receive LLM-generated responses.
### 7. **Final Steps**
- Implement concept-based chunking.
- Define FastAPI endpoints and SQLAlchemy models.
- Integrate LLM prompt templates.
- Test chunking, embeddings, and knowledge graph interactions.
You’re on a solid track! Anything specific you’d like help fleshing out? 🚀
gpt-4o