INRAExplorer: Agentic RAG for Science

• INRAExplorer is a retrieval-augmented generation system that integrates an LLM agent, vector database, and a Neo4j knowledge graph to overcome fixed top-k limitations.
• It employs iterative query decomposition and specialized tools to synthesize distributed evidence, ensuring complete retrieval of structured INRAE scientific information.
• The system supports hierarchical, concept-driven navigation and expert identification, enabling robust multi-hop reasoning across diverse scientific domains.

Searching arXiv for the cited INRAExplorer paper and related works it explicitly mentions so the article can be grounded in current arXiv records. INRAExplorer is an agentic Retrieval-Augmented Generation (RAG) system introduced for exploring the scientific data of INRAE, France’s National Research Institute for Agriculture, Food and Environment. It was designed to address a specific failure mode of “classical RAG”: fixed top-$k$ retrieval of text chunks via vector or BM25 search is often sufficient for simple extractive question answering, but it becomes inadequate when a query requires exhaustive enumeration, synthesis across many distributed facts, or multi-hop traversal over explicit entity relations. INRAExplorer combines an LLM-based agent with a purpose-built knowledge graph derived from open-access INRAE publications, allowing iterative tool use, targeted graph traversal, and structured answer synthesis for knowledge-intensive scientific queries (Lelong et al., 22 Jul 2025).

1. Problem Setting and Design Rationale

The motivating problem is the mismatch between conventional RAG pipelines and real-world scientific information needs. In the formulation used for INRAExplorer, classical RAG retrieves a fixed top-$k$ set of text chunks and then asks an LLM to answer from those passages. That design can support direct extraction, but it does not reliably return exhaustive sets such as “all publications by $X$,” nor does it readily support chained reasoning such as author $\rightarrow$ publication $\rightarrow$ funding project $\rightarrow$ related topics (Lelong et al., 22 Jul 2025).

This issue is particularly pronounced in the INRAE domain, which spans agriculture, food science, and environment. Queries in that setting are described as inherently relational and often dependent on hierarchical or thesaurus-driven navigation, including movement from broad Domain categories to leaf-level Concept nodes. A plausible implication is that unstructured retrieval alone cannot ensure completeness when the answer depends on traversing typed relations rather than merely locating semantically similar passages.

INRAExplorer responds by combining two ideas. The first is agentic RAG, in which the LLM acts as a planning-and-reasoning agent rather than a single-pass generator. The second is a knowledge graph (KG) of INRAE open-access publications that exposes entities and relations explicitly. The stated aim is not only better answer fluency, but also dynamic choice among retrieval modes, exhaustive dataset recovery, and multi-hop reasoning over structured scientific data (Lelong et al., 22 Jul 2025).

2. System Architecture

At a high level, INRAExplorer consists of an LLM-based agent, a vector database, a Neo4j knowledge graph, a suite of specialized tools exposed as API endpoints, and an answer synthesizer. The agent model specified in the overview is deepseek-r1-0528; the vector database is Qdrant; the graph store is Neo4j; and the orchestration stack is described as open and modular, with Mirascope named explicitly in the concluding system summary (Lelong et al., 22 Jul 2025).

The tool layer is central to the architecture. Four tools are named: SearchGraph, which executes Cypher queries over the KG; SearchPublications, which performs semantic plus BM25 retrieval; SearchConceptsKeywords, which supports thesaurus and concept lookup; and IdentifyExperts, which is described as a composite expert-ranking workflow. The answer synthesizer merges tool outputs and formats them into the final natural-language response.

The interaction flow is presented as a five-step loop. A user issues a query; the agent parses intent and plans substeps; for each substep it selects a tool and issues a structured API call; intermediate results such as node lists, edge sets, and text passages are returned to the agent; and once the subtasks are complete, the agent composes a structured final answer (Lelong et al., 22 Jul 2025). This design makes the system closer to an orchestrated reasoning environment than to a standard retriever-generator cascade.

A recurring misconception about systems of this kind is that “agentic” simply means adding tool calls to a chatbot. In INRAExplorer, the term is used more narrowly: the agent is responsible for decomposing the query, choosing among heterogeneous retrieval mechanisms, feeding intermediate evidence back into its own context, and iterating until the answer state is sufficiently complete. That distinction matters because the architecture is meant to support exhaustive and relational queries, not merely improve first-pass retrieval.

3. Knowledge Base and Graph Construction

The knowledge graph was built from all INRAE open-access publications from January 2019 to August 2024. The construction pipeline begins with metadata harvesting from HAL and OpenAire, followed by deduplication and DOI-based enrichment using BBI, ScanR, and dataset repositories. Full-text PDFs are then parsed with GROBID to extract structured chunks comprising title, abstract, introduction, and conclusion. Those chunks are indexed in a vector store using dense embeddings via Jina v3 together with sparse BM25 retrieval (Lelong et al., 22 Jul 2025).

A distinct component of the graph is the integration of the INRAE Thesaurus as a subgraph. The description specifies Domain nodes for high-level categories and Concept nodes for leaves, together with exact-match links from publications to Concept nodes. This means that thesaurus structure is not treated as external metadata but as part of the traversable graph itself, which is critical for hierarchical exploration and concept-grounded retrieval.

The resulting Neo4j graph contains 417,030 nodes and over 1,000,000 edges. The overview gives a conceptual node-type breakdown rather than a full schema.

Node type	Share
Authors	56%
Keywords	23%
Publications	9.3%
Software, Concepts, Journals, Projects, etc.	remainder

The dominance of Author and Keyword nodes suggests that authorship and topical indexing are major organizing principles of the graph. A plausible implication is that person-centric and concept-centric exploratory workflows are first-class use cases, rather than secondary views over a publication index.

The overview also notes, with explicit caution, that the paper does not dwell on KG embedding. It nevertheless gives a typical scoring function for relation prediction,

$S(e_i, r, e_j) = e_i^T W_r e_j,$

where $e_i, e_j \in \mathbb{R}^d$ are entity embeddings and $W_r \in \mathbb{R}^{d \times d}$ is relation-specific. In context, this is presented as a possible way such embeddings could support link scoring or graph reasoning, not as a documented operational component of INRAExplorer itself (Lelong et al., 22 Jul 2025).

4. Agentic Multi-Tool Reasoning

INRAExplorer’s reasoning workflow is described as iterative and targeted across both the vector store and the graph. The agent first decomposes a query into substeps, then selects from SearchPublications, SearchConceptsKeywords, SearchGraph, and IdentifyExperts. Outputs are stored as intermediate state and ultimately synthesized into the response (Lelong et al., 22 Jul 2025).

The multi-hop example given in the overview is “authors $\rightarrow$ projects $k$0 related topics.” In that pattern, the agent first uses publication or concept/keyword lookup to identify initial Publication and Author node IDs. It then constructs Cypher queries through SearchGraph. One query pattern matches an Author to Publication and then to Project via :WROTE and :FUNDED_BY. A subsequent query pattern starts from a Project, traverses back to publications, and then to connected Concept nodes. The results of each hop are returned to the agent and appended to its context before the next step is planned.

This behavior differs materially from one-shot retrieval. The agent is expected to inspect intermediate outputs, decide whether the current result set is adequate, and continue chaining if the query semantics require additional evidence. The overview further states that at each step the agent can evaluate retrieval confidence $k$1 or use a reranker such as Cohere before chaining to later hops (Lelong et al., 22 Jul 2025). That indicates an explicit retrieval-control layer rather than blind execution of a precomputed plan.

The significance of this workflow lies in exhaustiveness and path sensitivity. Scientific knowledge exploration often depends on knowing not only whether a fact exists in a document, but whether there is a valid path through typed relations that supports a claim or enumeration. INRAExplorer is presented as a concrete implementation of that premise.

5. Interfaces and Use Cases

The API design follows a simple REST schema: POST /tool_name with JSON input and JSON output containing nodes, edges, or structured records. This interface standardizes tool invocation so that the LLM agent can treat graph search, publication search, concept lookup, and expert identification as interoperable operations (Lelong et al., 22 Jul 2025).

One use case is “All publications by a given author and their funding projects.” The sequence begins with a SearchGraph call that matches an Author by name and returns written publications with title, year, and internal graph ID. A second SearchGraph call then matches each Publication to linked Project nodes through :FUNDED_BY. The example is important because it illustrates a query type that cannot be reduced to “retrieve a few relevant passages”: it requires complete entity enumeration followed by relation expansion.

A second use case is “Identify experts on zoonoses.” Here the IdentifyExperts endpoint accepts a topic and top_k, and returns structured results including author, score, and a details object with n_pubs, avg_relevance, and citations. The presence of these fields indicates that the workflow is composite rather than purely lexical; it aggregates multiple signals into an expert-ranking result (Lelong et al., 22 Jul 2025). The overview does not provide the ranking function, so any stronger interpretation would exceed the documented evidence.

These examples clarify the system’s intended role. INRAExplorer is not limited to answer generation over passages; it supports data exploration tasks in which the returned object may be a set of publications, projects, authors, concepts, or linked records assembled through several retrieval modes. That makes it closer to an exploratory scientific information system with LLM-mediated orchestration than to a conventional chat interface.

6. Evaluation, Limitations, and Prospective Development

The evaluation discussion is deliberately cautious. The paper argues that existing benchmarks such as HotpotQA and ComplexWebQuestions do not capture the richness or rigor of real-world scientific multi-hop queries, and states that INRAExplorer has not yet been evaluated on standard public datasets (Lelong et al., 22 Jul 2025). Instead, the proposed direction is a co-designed evaluation framework with domain experts, including gold-standard tasks, explicit multi-hop chains, and success criteria such as completeness of an author’s publication list and correctness of relationship traversals.

The quantitative metrics under consideration are precision and recall of retrieved node sets, accuracy of reasoning chains, and end-to-end user satisfaction. Early internal tests are said to show that the multi-tool, KG-centric approach recovers exhaustive answer sets where classical RAG often omits 20–40% of relevant entities (Lelong et al., 22 Jul 2025). Because this is reported as early internal testing rather than benchmarked public evaluation, it should be interpreted as preliminary evidence rather than a settled comparative result.

Two limitations are explicitly noted. The first is dependence on KG coverage, particularly gaps in metadata. The second is the need for more robust calibration of the agent’s planning module. These constraints are consequential: if the graph omits a relation or the planner decomposes the query poorly, the system’s exhaustiveness claims weaken even if the downstream tools behave correctly.

Future work is described along three lines. One is the construction of rigorous, expert-validated evaluation suites for complex queries. Another is specialization or fine-tuning of the agent model using reinforcement learning, with RLVF given as an example, to improve reasoning efficiency and robustness. A third is extension of the same multi-tool, KG-centric blueprint to other scientific or technical domains such as biomedical literature, legal corpora, and engineering standards (Lelong et al., 22 Jul 2025).

Taken together, INRAExplorer is best understood as a domain-specific architecture for structured scientific knowledge interaction. Its principal contribution is not merely the addition of a knowledge graph to RAG, but the integration of graph traversal, publication retrieval, concept lookup, and expert identification under an LLM-based planning loop. This suggests a broader model of RAG in which completeness, relation-aware traversal, and reproducible multi-hop evidence gathering are treated as primary system objectives rather than optional enhancements.