The system runs two retrieval channels concurrently — a semantic channel that operates over dense vector embeddings of document text, and a relational channel that processes entity/relationship triples from the knowledge graph built by the active backend. Both channels receive their inputs from the same initial backend retrieval call, but process fundamentally different evidence modalities in parallel. Once both channels have produced their sub-answers, the parent LangGraph state machine merges their outputs and synthesises a single, grounded final answer. Running the two channels in parallel rather than in sequence minimises latency and ensures that the synthesis step always has access to both text-based and graph-triple evidence before generating a response.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/avnlp/agentic-med-diag/llms.txt
Use this file to discover all available pages before exploring further.
Semantic Channel
The semantic channel is responsible for retrieving and reasoning over text-based evidence — document chunks and reference lists surfaced by the Graph RAG backend’s dense vector search over Milvus embeddings. What it retrieves:- Relevant document passages indexed in Milvus and returned by the backend’s vector search
- Reference document lists that identify the source documents for the retrieved chunks
Sub-Query Grounding
Each semantic sub-query (with any
#N back-references resolved from earlier hops) is grounded and prepared for issuance to the retrieval backend.GraphRAG Retrieval
The grounded sub-query is issued to the active Graph RAG backend, which performs dense vector search over Milvus embeddings and returns the relevant document chunks and reference list sections from the structured backend context.
Semantic Filter
The retrieved document passages are filtered to remove noise and retain only the most relevant content for the current sub-query, reducing the context window burden for downstream steps.
Text Summary
The filtered passages are summarised into a compact representation that distills the key clinical evidence.
Sub-Answer Generation
The language model generates a sub-answer for the current hop, drawing on the text summary. This sub-answer is stored as a
#N back-reference for subsequent sub-queries.Logic Drafting
The reasoning chain connecting the retrieved text evidence to the sub-answer is made explicit, producing a structured draft of the logical steps taken.
context_filter by backend:
| Backend | Semantic Channel Receives |
|---|---|
| LightRAG | Document Chunks + Reference Document List |
| MiniRAG | Sources CSV |
| HyperGraphRAG | Sources CSV |
| PathRAG | Sources CSV |
Relational Channel
The relational channel is responsible for retrieving and reasoning over structured entity/relationship triples from the knowledge graph built by the active backend. Rather than surfacing text passages, it processes typed entity/relationship data and returns explicit Subject–Predicate–Object triples as evidence. What it retrieves:- Entity nodes and their attributes from the backend’s knowledge graph storage
- Typed relationship edges connecting query-relevant entities
- For PathRAG: both high-level (thematic/concept) and low-level (mention-level) entity/relationship layers
SPO Triple Queries
Each relational sub-query is expressed as a Subject–Predicate–Object triple query, with
Entity#N placeholders resolved from earlier hops. These structured queries are issued to the Graph RAG backend, which retrieves the relevant triples from its knowledge graph storage (Neo4j for LightRAG; local working-directory storage for MiniRAG, PathRAG, and HyperGraphRAG).KG Filter
The triples returned by the backend are filtered to retain only those most relevant to the current sub-query, removing spurious or low-confidence relationships.
Triplet List Summaries
The filtered triples are summarised into a structured list that captures the key entities and relationships in a form consumable by the language model.
context_filter by backend:
| Backend | Relational Channel Receives |
|---|---|
| LightRAG | Knowledge Graph Data (Entity) JSON + Knowledge Graph Data (Relationship) JSON |
| MiniRAG | Entities CSV + Relationships CSV |
| HyperGraphRAG | Entities CSV + Relationships CSV (including hyperedges) |
| PathRAG | High-level entity/relationship CSVs + low-level entity/relationship CSVs |
context_filter
Before either channel begins processing, the parent graph callscontext_filter on the raw context returned by the Graph RAG backend. Each backend structures its output differently — LightRAG returns a JSON object with four named sections, while MiniRAG, HyperGraphRAG, and PathRAG return CSV-formatted contexts with varying section layouts. The context_filter function knows how to parse each format and route each section to the correct channel.
This clean separation ensures that each channel always receives exactly the evidence modality it is designed to process, keeping the semantic and relational pipelines backend-agnostic.
Synthesis
After both channels have completed their iterative retrieval-and-reasoning loops and produced sub-answers, the parent LangGraph state machine merges the two outputs. The synthesis step receives:- The semantic channel’s sub-answers and the text evidence that supports them
- The relational channel’s sub-answers and the knowledge graph triples that support them
Backends Overview
Explore the four supported Graph RAG backends — LightRAG, MiniRAG, PathRAG, and HyperGraphRAG — and their graph models.
Architecture
See how the parent LangGraph state machine coordinates the fan-out, parallel execution, and fan-in of both retrieval channels.