GSoC 2026 – Interest in Project #36 - Agentic GraphRAG

[naitik-2006]

Hi @14pankaj @bharagha

I hope this message finds you well. My name is Naitik Agrawal, 3rd year B.Tech + M.Tech student in Mathematics and Computing at IIT BHU (CPI: 9.51), and I am writing to express my strong interest in contributing to the Agentic GraphRAG project (Project 36).

I have been following the discussion on this project including the mentor feedback shared in the community thread and wanted to share how I am incorporating those insights into my approach.

I bring directly relevant experience to this work. This past summer, I built an Agentic GraphRAG powered coding assistant for the Summer of Bitcoin program, designing a scalable hybrid retrieval pipeline combining semantic embeddings, graph re-ranking, and a CLI-based developer tool with conversation summarization and progressive context tracking.
And before that during the Inter-IIT Tech Meet 13.0, I built a two-stage retrieval pipeline with an interleaved reasoning framework for cross-domain QA closely mirroring the multi-hop demands of the VIINA benchmark. I have also co-authored two papers accepted to CVPR 2025 (Main Conference + Best Paper at the AI Storytelling Workshop).

From studying the edge-ai-libraries repository and the mentor feedback, here is my refined technical approach:

Architecture: I plan to replace linear chain in app/chain.py with a stateful LangGraph agent routing queries between a VectorSearchTool and a GraphQueryTool (Text-to-Cypher over Neo4j aligned with the edge deployment preference). A Reflection Agent sits in the generation loop to verify outputs against retrieved context, with latency and reflection effectiveness as first-class evaluation signals.

Launch Mode Flexibility: Taking the mentor's suggestion on board, We can implement a --mode flag (simple-rag | graph-rag) at the CLI/Docker entrypoint level, allowing the application to launch in either mode without code changes. This makes the solution accessible for users who do not yet have a Neo4j instance available, and keeps the upgrade path clean. If no input is provided, Agent will choose the best option for the given query.

Evaluation Framework: Aligned with the mentor's guidance, my evaluation plan will cover all three dimensions: (a) GraphRAG-specific retrieval metrics (precision/recall on entity and relation extraction, multi-hop accuracy on VIINA), (b) generation quality metrics (faithfulness, answer relevance, context utilization), (c) agentic metrics (reflection agent effectiveness, tool selection accuracy, reasoning chain quality)
This ensures the benchmark is meaningful both for research and for edge deployment scenarios.

I also have quite interest in the For Project 37, I see the feedback loop (Thumbs Up / Down) as a natural extension feeding into prompt tuning or lightweight LoRA fine-tuning, with knowledge graph updates for persistent corrections. I would be happy to discuss whether scoping both projects into a unified proposal makes sense, or whether a primary + stretch goal structure is preferred.

I would be grateful for any warm-up task or pre-contribution issue you could point me to I am eager to engage with the codebase before the proposal deadline and demonstrate fit in practice.

Thank you sincerely for your time and consideration.

Best regards,
Naitik Agrawal
naitikagrawal838@gmail.com

[bharagha]

Hi Naitik, thanks for reaching out and your expression of interest in two topics.
I suggest keeping the focus on what has been listed in project 36. There is already one contributor (@ishaanv1709) on the topic. My suggestion is to check if you two can collaborate together as it helps overall. You can additionally focus on the evaluation criteria that differentiates GraphRAG vis a vis Semantic RAGs and the fine-tuning aspects as a result (project 37). One recommendation though is to prioritize edge deployment vs. research requirements as the two may not align consistently with each other.

My request: Check if you can have a discussion with @ishaanv1709 on project 36 for mutual collaboration and submission. You can in addition focus on project 37 in alignment with approach on project 36. All of us can get into a common call once you confirm if you are aligned on this approach and have had a discussion with @ishaanv1709.

FYI: @ishaanv1709, @14pankaj

[naitik-2006]

Thank you for the guidance. I have already reached out to @ishaanv1709 and will loop back once we have had a chance to connect.
Happy to focus on Project 37 in alignment with the approach on Project 36, keeping edge deployment as the primary constraint throughout.

On evaluation here is how I am thinking about it across all dimensions:

Graph construction: Node count, edge count, and relation coverage to assess KG quality. I am currently exploring, can we use MINE-1/MINE-2 framework (KGGen, Stanford) to measure how well the graph captures source content and whether it actually improves retrieval this is what most clearly separates GraphRAG from semantic RAG in practice.

Retrieval & Generation: Context Precision, Context Recall, multi-hop accuracy on VIINA, Faithfulness, Answer Relevance, and Evidence Coverage. For tooling, Ragas (with LangGraph integration) and DeepEval cover these well.

Agentic layer: Tool Call Accuracy, Agent Goal Accuracy, and Reflection Agent effectiveness specifically hallucination catch rate and latency cost per correction cycle.

System / edge: End-to-end latency, per-hop latency, and overall compute utilization (CPU/GPU) on target edge hardware. Every metric will be evaluated against its latency cost.

Looking forward to the call once @ishaanv1709 and I have connected.

[naitik-2006]

@bharagha @14pankaj

I was going through the Graph construction strategy, I realize the right approach depends heavily on two things I wanted to clarify:

1. What is the primary document source for this project? (e.g. PDFs, structured enterprise data, web content, the VIINA dataset directly?) The extraction strategy whether spaCy dependency parsing, a fine-tuned SLM, or LLM-based changes significantly based on how structured/unstructured the input is.

2. Is the knowledge graph intended to be built once over a fixed corpus (like VIINA for benchmarking), or should the system support incremental updates as users upload new documents similar to how the existing ChatQnA handles document ingestion?

Microsoft Graph Rag also suggest two strategies. One is to use LLM and other is to use the traditional NLP methods. Problem with using standard LLM they can take too much time, which is not good for the edge devices. So the other option is using NLP methods or we can use Small language models, with parallel processing.
This directly impacts the ingestion pipeline design and the tradeoff between construction quality and edge latency.

@ishaanv1709 would love your thoughts on this too.

[bharagha]

@naitik-2006 : The GraphRAG feature is intended to be offered as a base capability that can be used in multiple use cases cutting across industry segments, with a corpus of complex documents (different formats) and in future in combination with multimodal data too. We have our own plans on that front. To ensure this evolving requirement does not complicate phrasing the problem statement for GSoC, we suggested implementing it over some standard dataset to ensure there is no ambiguity on that front. So, my request is to focus on the VIINA like datasets, but build it such that we can do necessary modifications for complex multimodal data.

[naitik-2006]

Hi @bharagha

I have already submitted my proposal for project 36 and 37. But while exploring more on the edge deployment side, came across two things that seem directly relevant:

1. LazyGraphRAG ( by microsoft) :- The core idea is well-suited for edge constraints, instead of running expensive LLM-based summarization during ingestion, LazyGraphRAG defers all LLM usage to query time. Indexing cost drops to 0.1% of standard GraphRAG while maintaining comparable answer quality. It uses NLP-based concept extraction (no LLM calls) at index time, and builds graph structures on-the-fly per query using an iterative deepening search combining best-first (semantic similarity) and breadth-first (graph coverage) dynamically.

2. On the GraphDB side FalkorDB :- uses sparse matrix representation via GraphBLAS and linear algebra for graph queries instead of traditional traversal. This makes subgraph retrieval significantly faster on CPU-constrained hardware, which is relevant for the edge latency constraint. It is Cypher-compatible so switching from Neo4j would require no query rewrites. Worth considering as an alternative or at least a benchmarking comparison.

Would be curious whether this direction aligns with what you have in mind.

Reference: https://www.microsoft.com/en-us/research/blog/lazygraphrag-setting-a-new-standard-for-quality-and-cost/

[bharagha]

Bake both into your proposal @naitik-2006