How nicoladisabato/multiagenticrag works
1. Overall purpose
- This repository implements a multi-agent RAG system for answering questions from a specific source document: the Google 2024 environmental report PDF.
- The architecture is centered on LangGraph, so the system is organized as a set of small stateful workflows rather than a single monolithic chat loop.
2. Two-phase workflow
- The repo has a clear split between:
- Offline document ingestion/indexing
- Online question answering
- First, the PDF is processed and loaded into a retrieval store.
- Then the application runs a graph-based agent pipeline that retrieves relevant evidence and generates answers.
3. Entry points
- retriever/retriever.py is the ingestion entry point. It loads the PDF, chunks/processes it, and writes it into the retrieval layer.
- app.py is the runtime entry point for the interactive QA application.
- config.yaml controls behavior such as whether documents should be loaded into the index.
4. Retrieval subsystem
- The retriever/ package contains the source document and the ingestion logic.
- Its role is to convert the PDF into retrievable units, likely embedding them and storing them in a vector-backed index used later by the graph.
- This is a prerequisite step before the app can answer questions reliably.
5. Main orchestration graph
- main_graph/ contains the top-level LangGraph workflow that coordinates the full RAG process.
- main_graph/graph_builder.py likely defines the nodes, edges, and routing logic for the primary agent loop.
- main_graph/graph_states.py defines the shared state object passed through the workflow, which is how intermediate results move between steps.
6. Subgraph for specialized reasoning
- subgraph/ is a second LangGraph workflow used as a nested or delegated component.
- subgraph/graph_builder.py and subgraph/graph_states.py suggest a reusable focused agent flow for a narrower task such as retrieval refinement, verification, or correction.
- This structure indicates the project uses hierarchical agent composition rather than a single flat pipeline.
7. Utility layer
- utils/ contains shared support code.
- utils/prompt.py likely stores prompt templates for the different agents and graph nodes.
- utils/utils.py probably holds helper functions for formatting, document handling, retrieval calls, or graph support logic.
- This keeps prompt logic and shared helpers separate from orchestration code.
8. Quality-control behavior
- The README says the system includes error correction and hallucination checks.
- Architecturally, that means the answer path is not just “retrieve then generate”; it includes validation or feedback steps that can revise outputs before returning them.
- That makes the graph more like a controlled reasoning pipeline than a simple RAG chain.
9. Data flow
- The data flow is: PDF source → retriever ingestion → indexed document store → query enters app → main graph routes the task → retrieval happens → subgraph or verification step may refine results → final answer returned to the user.
- The key boundary is between offline document preparation and online runtime inference.
10. Primary architectural boundaries
- Source data boundary: the environmental report PDF.
- Indexing boundary: retrieval/index creation in retriever/.
- Orchestration boundary: top-level reasoning in main_graph/.
- Specialized reasoning boundary: nested workflow in subgraph/.
- Shared configuration/prompt boundary: config.yaml and utils/.
11. Runtime and tooling
- The project is Python-based and depends on the packages in requirements.txt.
- LangGraph is the core orchestration technology.
- The workflow is designed to run locally: preprocess once, then launch the app and query the indexed report.
12. How to draw the architecture
- A good diagram would show:
- A document ingestion lane on the left
- A retrieval/index store in the middle
- A graph-based agent runtime on the right
- A nested subgraph inside the runtime for specialized checking or refinement
- Shared prompt/config utilities feeding both ingestion and runtime where needed
- The central design idea is a multi-agent, stateful, retrieval-augmented pipeline built around one report and optimized for trustworthy answers.
Main entry points: main_graph/graph_builder.py Main Graph · subgraph/graph_builder.py Subgraph · retriever.py Ingestor · utils.py Helpers
Components 11
Source & Ingestion
Document source and offline indexing flow.
- Report PDF · The Google 2024 environmental report that is indexed and queried.
retriever/google-2024-environmental-report.pdf - Ingestor · Loads, chunks, and writes the report into the retrieval layer.
retriever/retriever.py - Index Store · Persistent retrieval-backed document store used at query time.
QA Runtime
Interactive question-answering and graph orchestration.
- App Entry · Launches the interactive QA application.
app.py - Main Graph · Top-level orchestration graph for retrieval, reasoning, and answer generation.
main_graph/graph_builder.py - Main State · Shared state object passed through the main graph.
main_graph/graph_states.py - Subgraph · Specialized delegated LangGraph flow for refinement or validation.
subgraph/graph_builder.py - Sub State · Shared state object for the nested subgraph.
subgraph/graph_states.py
Shared Support
Configuration, prompts, and reusable helpers.
Connections 14
- Config → Ingestor: enable load · Controls whether documents are ingested into the index.
- Report PDF → Ingestor: source text · The report is the raw input to offline ingestion.
- Ingestor → Index Store: build index · Creates or updates the retrieval layer.
- Config → App Entry: configure runtime · Provides runtime settings for the QA application.
- App Entry → Main Graph: start graph · Launches the main LangGraph workflow.
- Main Graph → Main State: uses state · The main workflow reads and updates shared state.
- Main Graph → Index Store: retrieve evidence · Queries the indexed report for supporting passages.
- Main Graph → Subgraph: delegate step · Routes specialized reasoning to the nested subgraph.
- Subgraph → Sub State: uses state · The subgraph maintains its own workflow state.
- Subgraph → Helpers: helper logic · Reuses shared utility functions during refinement.
- Main Graph → Prompts: prompts · Consumes prompt templates for agent behavior.
- Subgraph → Prompts: prompts · Uses shared prompts for specialized reasoning.
- Main Graph → Helpers: helpers · Uses shared support functions in the orchestration flow.
- Ingestor → Helpers: preprocess · May use shared helpers for document preparation.