How adt-kmr/coderag works
This repository appears to be a small, experiment-oriented CodeRAG project rather than a single packaged application. The top-level structure suggests three parallel implementation tracks: a hybrid RAG approach, a knowledge-graph/“other” approach, and a vector-database-based code RAG approach.
The README is minimal, so the architectural signal comes mostly from the directory names. The core domain is clearly code retrieval and code question answering, with the repository organizing different retrieval strategies around the same task.
The first major subsystem is the vector-based code RAG path under vector db code rag. This likely represents the baseline pipeline: source code is ingested, split into retrievable units, embedded, and indexed in a vector database for similarity search during query time.
The second subsystem is the knowledge-graph-oriented path under kg and others. This suggests a graph-centric representation of code, such as symbols, dependencies, or relationships between files/functions/classes, plus any auxiliary retrieval or reasoning methods that do not fit the vector store model.
The third subsystem is hybrid rag, which likely combines the two retrieval modes. Architecturally, this is the most important boundary: vector search provides semantic matching, while the graph side supplies structural or relational context, and the system merges both before generation.
A likely end-to-end data flow is: code corpus in the repository or an external source is processed into indexed representations; retrieval occurs from either the vector index, the knowledge graph, or both; the selected context is assembled; and an LLM generates the final answer or explanation.
The main architectural separation is therefore between indexing/storage and retrieval/generation. Storage is split across vector indexes and graph-like structures, while generation is downstream and depends on whatever context each approach surfaces.
Because the repo tree is shallow, it does not show a production service layer, API layer, or deployment layer. That implies the repository is probably a set of prototypes, notebooks, or scripts used to compare retrieval strategies rather than a full production system.
For an architecture diagram, the clearest structure is to show one shared “code corpus” input feeding three independent lanes: vector RAG, KG-based retrieval, and hybrid retrieval. Each lane likely has its own preprocessing and retrieval logic, but all converge on a common LLM answering stage.
The important external technologies are the ones implied by the names: embeddings/vector storage for semantic search, a graph model for code relationships, and an LLM for answer synthesis. No specific vendor or framework is visible from the tree alone, so those should be treated as implementation details, not core architecture.
Overall, this repo should be diagrammed as a comparative RAG lab for code intelligence: multiple retrieval backends, a shared code-understanding goal, and a hybrid path that bridges semantic and structural retrieval.
Main entry points: hybrid rag Hybrid retriever · vector db code rag Vector store · kg and others Graph store
Components 14
Shared flow
Common code intelligence flow shared across the repository's prototype tracks.
- Code corpus · Repository code or an external codebase used as the retrieval target.
- Prep · Transforms source code into retrievable units and metadata.
- LLM answer · Produces the final code explanation or question answer.
Vector RAG
Embedding-based code retrieval path.
- Embeddings · Converts code chunks into vectors for similarity search.
- Vector store · Stores embedded code chunks for nearest-neighbor retrieval.
vector db code rag - Vector query · Finds semantically similar code using the vector index.
- Vector RAG · Baseline retrieval path centered on embeddings and vector search.
vector db code rag
Knowledge graph
Graph-oriented code representation and retrieval path.
- KG extract · Extracts symbols, relations, or dependencies from code.
- Graph store · Persists the code relationship graph for traversal and lookup.
kg and others - Graph query · Retrieves structurally related code context from the graph.
- KG track · Alternative retrieval path centered on code relationships and graph reasoning.
kg and others
Hybrid RAG
Combined semantic and structural retrieval path.
- Hybrid retriever · Combines vector and graph retrieval signals.
hybrid rag - Context merge · Merges retrieved snippets and graph facts into one prompt context.
- Hybrid track · Combined retrieval path that uses both semantic and structural context.
hybrid rag
Connections 16
- Code corpus → Prep: ingest · Prepare source code for indexing and retrieval.
- Prep → Embeddings: chunk/embed · Create vector representations of code chunks.
- Embeddings → Vector store: index · Store embeddings for semantic search.
- Prep → KG extract: analyze · Derive code entities and relationships.
- KG extract → Graph store: build graph · Persist the code graph.
- Vector store → Vector query: search · Support similarity-based retrieval.
- Graph store → Graph query: traverse · Support relationship-based retrieval.
- Vector query → Hybrid retriever: signal · Provide semantic matches to the hybrid layer.
- Graph query → Hybrid retriever: signal · Provide structural context to the hybrid layer.
- Hybrid retriever → Context merge: fuse · Combine retrieval results into prompt-ready context.
- Vector query → LLM answer: context · Vector-based context can feed generation directly.
- Graph query → LLM answer: context · Graph-derived context can feed generation directly.
- Context merge → LLM answer: prompt · Merged context drives the final answer.
- Vector RAG → Vector store: implements · The vector track contains the baseline retrieval path.
- KG track → Graph store: implements · The KG track contains the graph-based retrieval path.
- Hybrid track → Hybrid retriever: implements · The hybrid track contains the combined retrieval path.