# MetaboT: AI-based agent for natural language-based interaction with metabolomics knowledge graphs

Madina Bekbergenova, Lucas Pradi, Benjamin Navet, Emma Tysinger, Franck

Michel, Matthieu Feraud, Yousouf Taghzouti, Yan Zhou Chen, Olivier

Kirchhoffer, Florence Mehl, et al.

► To cite this version:

Madina Bekbergenova, Lucas Pradi, Benjamin Navet, Emma Tysinger, Franck Michel, et al.  
MetaboT: AI-based agent for natural language-based interaction with metabolomics knowledge graphs.  
33rd annual international conference on Intelligent Systems for Molecular Biology (ISMB 2025) / 24th  
Annual Conference of the European Conference on Computational Biology (ECCB 2025), Jul 2025,  
Liverpool, United Kingdom. hal-05235355

HAL Id: hal-05235355

https://hal.science/hal-05235355v1

Submitted on 30 Sep 2025

**HAL** is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>
# MetaboT: An LLM-based Multi-Agent Framework for Interactive Analysis of Mass Spectrometry Metabolomics Knowledge

**Madina Bekbergenova**

Université Côte d'Azur, CNRS, ICN, Nice, France, Interdisciplinary Institute for Artificial Intelligence (3iA) Côte d'Azur, Sophia-Antipolis, France & Department of Computer Science & University of Antwerp, Antwerp, Belgium https://orcid.org/0009-0007-6356-9754

**Lucas Pradi**

Université Côte d'Azur, CNRS, ICN, Nice, France & Interdisciplinary Institute for Artificial Intelligence (3iA) Côte d'Azur, Sophia-Antipolis, France https://orcid.org/0009-0003-8641-6268

**Benjamin Navet**

Université Côte d'Azur, CNRS, ICN, Nice, France & Interdisciplinary Institute for Artificial Intelligence (3iA) Côte d'Azur, Sophia-Antipolis, France

**Emma Tysinger**

Université Côte d'Azur, CNRS, ICN, Nice, France & Interdisciplinary Institute for Artificial Intelligence (3iA) Côte d'Azur, Sophia-Antipolis, France; INRIA, Université Côte d'Azur, CNRS, I3S, France & Interdisciplinary Institute for Artificial Intelligence (3iA) Côte d'Azur, Sophia-Antipolis, France https://orcid.org/0000-0002-3958-8097

**Franck Michel**

INRIA, Université Côte d'Azur, CNRS, I3S, France & Interdisciplinary Institute for Artificial Intelligence (3iA) Côte d'Azur, Sophia-Antipolis, France https://orcid.org/0000-0001-9064-0463

**Matthieu Feraud**

Université Côte d'Azur, CNRS, ICN, Nice, France & Interdisciplinary Institute for Artificial Intelligence (3iA) Côte d'Azur, Sophia-Antipolis, France https://orcid.org/0009-0001-5496-6690

**Yousouf Taghzouti**

Université Côte d'Azur, CNRS, ICN, Nice, France & Interdisciplinary Institute for Artificial Intelligence (3iA) Côte d'Azur, Sophia-Antipolis, France; INRIA, Université Côte d'Azur, CNRS, I3S, France & Interdisciplinary Institute for Artificial Intelligence (3iA) Côte d'Azur, Sophia-Antipolis, France https://orcid.org/0000-0003-4509-9537

**Yan Zhou Chen**

Department of Computer Science, Tufts University, Medford, MA 02155, USA

**Olivier Kirchhoffer**

Institute of Pharmaceutical Sciences of Western Switzerland, University of Geneva, Centre Médical Universitaire, Geneva, Switzerland & School of Pharmaceutical Sciences, University of Geneva, Centre Médical Universitaire, Geneva, Switzerland https://orcid.org/0000-0001-7567-1050
**Florence Mehl**

Swiss Institute of Bioinformatics (SIB), Lausanne, Switzerland https://orcid.org/0000-0002-9619-1707

**Martin Legrand**

Université Côte d'Azur, CNRS, ICN, Nice, France & Interdisciplinary Institute for Artificial Intelligence
(3iA) Côte d'Azur, Sophia-Antipolis, France

**Tao Jiang**

Université Côte d'Azur, CNRS, ICN, Nice, France & Interdisciplinary Institute for Artificial Intelligence
(3iA) Côte d'Azur, Sophia-Antipolis, France https://orcid.org/0000-0002-5293-3916

**Marco Pagni**

Swiss Institute of Bioinformatics (SIB), Lausanne, Switzerland https://orcid.org/0000-0001-9292-9463

**Soha Hassoun**

Department of Computer Science, Tufts University, Medford, MA 02155, USA & Department of Chemical
and Biological Engineering, Tufts University, Medford, MA 02155, USA https://orcid.org/0000-0001-9477-2199

**Jean-Luc Wolfender**

Institute of Pharmaceutical Sciences of Western Switzerland, University of Geneva, Centre Médical
Universitaire, Geneva, Switzerland & School of Pharmaceutical Sciences, University of Geneva, Centre
Médical Universitaire, Geneva, Switzerland https://orcid.org/0000-0002-0125-952X

**Wout Bittremieux**

Department of Computer Science, University of Antwerp, Antwerp, Belgium https://orcid.org/0000-0002-3105-1359

**Fabien Gandon**

fabien.gandon@inria.fr

INRIA, Université Côte d'Azur, CNRS, I3S, France & Interdisciplinary Institute for Artificial Intelligence
(3iA) Côte d'Azur, Sophia-Antipolis, France https://orcid.org/0000-0003-0543-1232

**Louis-Félix Nothias**

louis-felix.nothias@cnrs.fr

Université Côte d'Azur, CNRS, ICN, Nice, France & Interdisciplinary Institute for Artificial Intelligence
(3iA) Côte d'Azur, Sophia-Antipolis, France https://orcid.org/0000-0001-6711-6719

**Method Article**

**Keywords:** Mass Spectrometry, Metabolomics, Knowledge Graphs, SPARQL Query Generation, Large Language Models (LLMs), Multi-Agent Systems, Natural-Language Interfaces, Semantic Data Integration, Entity Resolution, Computational Metabolomics

**Posted Date:** May 6th, 2025
**Additional Declarations:** The authors declare potential competing interests as follows: F.G. is cofounder and co-scientific advisor of :probabl., E.T. is now employee of :probabl. All other authors declare no competing interests.
**Abstract**

Mass spectrometry metabolomics generates complex data that overwhelms traditional analysis approaches. MetaboT, a multi-agent Large Language Model (LLM)-based framework, converts natural-language questions into needed SPARQL queries, enabling effective knowledge graph navigation (https://holobiomicslab.github.io/MetaboT/). We validate MetaboT's performance on a large plant dataset with 50 representative queries. MetaboT's modular design facilitates advanced data mining, biological interpretation, and the discovery of novel compounds without specialized programming expertise.

**Introduction**

Contemporary mass spectrometry-based metabolomics approaches generate unprecedented volumes of spectral data that are becoming increasingly challenging to process manually, creating a significant bottleneck in the discovery pipeline for life and environmental sciences. Laboratories are producing more data than can be feasibly annotated by experts, thereby slowing the pace of discovery for molecular interactions, metabolic pathways, and novel drug candidates¹. Over the past decade, the community has developed several open-source frameworks that streamline spectral data processing and annotation²⁻⁵, yet the considerable complexity and volume of metabolomics data necessitates advanced expertise in statistical analysis, programming, data science, engineering, and visualisation, ultimately constraining researchers' ability to extract deeper biological insights⁶.

Over the past decade, molecular networking has democratized mass spectra exploration—enabling researchers from diverse backgrounds to intuitively map structural relationships among metabolites through graph-based comparison of their fragmentation spectra.³ More recently, knowledge graphs have emerged as the next frontier in the field—semantically integrating metabolites, pathways and biological entities into an interoperable framework⁷⁻⁹. These graphs rely on domain-specific ontologies that provide standardised vocabularies, including concepts and relation hierarchies, essential for consistent data integration and interpretation across different experimental platforms. Despite their potential, both knowledge graphs and their underlying ontologies remain underutilised due to the steep learning curve associated with representation languages like Resource Description Framework (RDF) and query languages like SPARQL, as well as the complexity of mastering domain-specific ontological frameworks. These technical barriers require an in-depth understanding of the data graph model, its query syntax, and the underlying schema that defines its structure, constraints, and semantics—significantly limiting accessibility for many researchers¹⁰,¹¹. Although recent advances in generative AI using Large Language Models (LLMs) have shown promising results in automating SPARQL query generation¹⁰,¹²⁻¹⁴ and in enabling knowledge graph creation through tools like BioCypher¹⁵, LLMs still suffer from critical limitations. In particular, they are prone to hallucinations, where models generate incorrect identifiers or properties, leading to errors in query construction¹⁴. Furthermore, LLMs' performance is heavily dependent on access to detailed, substantial schema information and precise entity identifiers, which
has so far limited their standalone applicability in complex metabolomics contexts. While supplementing LLMs with tools—such as retrieval-augmented generation (RAG) pipelines, schema parsers, specialized entity-resolution modules, or integrated frameworks like BioChatter and ExpasyGPT<sup>13,16</sup>, can reduce LLM dependency on schema details, these approaches still demand complex, schema-specific integration and may face challenges, such as occasional hallucination of entity identifiers due to limited orchestration. Emerging evidence shows that SPARQL generation improves with chain-of-thought prompting<sup>17</sup>, and role-based specialized-agent orchestration<sup>18</sup>.

To overcome these hurdles—and harness the power of chain-of-thought prompting and role-based agent orchestration—we created MetaboT, a multi-agent LLM framework that decomposes complex metabolomics knowledge graph queries into discrete subtasks, routes each to a specialist agent, and thereby delivers precise entity resolution, schema-aware SPARQL generation, and markedly fewer hallucinations than single-LLM baselines. MetaboT enables researchers to query a metabolomics knowledge graph through an intuitive conversational interface (Fig. 1a). MetaboT resolves entity identifiers through orchestrated resolution steps to prevent hallucinations, leverages knowledge graph schemas, and translates natural-language questions into SPARQL queries adapted to the specific schema of the knowledge graph.

The architecture of MetaboT consists of a flexible pipeline that manages entity resolution, query processing, and iterative refinement (Fig. 1b). When a user submits a natural-language question (e.g., "What bioactive compounds are found in *Tabernaemontana coffeoides*?"), the *Entry Agent* first determines whether the question is new or a follow-up to previous interactions. New questions are forwarded to the *Validator Agent*, a single LLM prompted with relevant details of the knowledge graph schema, which checks the question's scope to ensure relevance (e.g., confirming that bioactive compounds and plant species are valid entity types in the schema). For plant-specific questions, the *PlantDatabaseChecker Tool* confirms the presence of the plant in a curated database (e.g., verifying that "*Tabernaemontana coffeoides*" exists in the plant database).

Then, for questions requiring chemical conversions or standardised identifiers, the *Supervisor Agent* delegates tasks to the *KG (knowledge graph) Agent*. In our demonstration, we used the Experimental Natural Products Knowledge Graph (ENPKG)⁹, a comprehensive semantic graph that integrates mass spectrometry data with taxonomic information, chemical structures, and biological activities of natural products from plant sources. To use this knowledge graph, the *KG Agent* first extracts entities mentioned in the user's question and resolves them to their Internationalised Resource Identifiers (IRIs) or molecular representations. To do so, the *KG Agent* queries specialized databases (like Wikidata¹⁹ for taxonomy or ChEMBL²⁰ for biological targets) by calling specialized tools—including *ChemicalResolver*, *SMILESResolver*, *TargetResolver*, and *TaxonResolver*. For example, when "*Tabernaemontana coffeoides*" is mentioned, the *TaxonResolver* tool is called by *KG Agent* to retrieve its Wikidata IRI, while for chemical classes like "flavonoids" the *ChemicalResolver* tool retrieves the appropriate chemical class (NPCClass) IRI. Similarly, when a SMILES string, such as "C1 = CC = C2C(= C1)C = CN2" is provided, the
SMILESResolver converts it to a standardized InChIKey, and when a biological target like "acetylcholinesterase" is referenced, the *TargetResolver* obtains its IRI from ChEMBL<sup>20</sup>, a comprehensive database of bioactive molecules. These tools leverage either external application programming interfaces (APIs) or carry out retrieval augmented generation (RAG) on local documents, significantly reducing hallucinations by accurately resolving each entity and relation type against authoritative sources. Finally, the *KG Agent* verifies the returned matches against contextual information and selects the correct standardized identifiers.

Once entities and knowledge graph schema details are collated, the *SPARQL Query Runner Agent* contextualizes the user's question with aligned identifiers and schema information to build a rich, structured prompt for the *GraphSparqlQACchain* tool. This tool leverages an API call to an LLM to generate a SPARQL query from the prompt, executes it on the knowledge graph endpoint, and retrieves the corresponding answer. A particularly noteworthy aspect of MetaboT is its ability to distinguish between query construction errors and genuine data absence when no results are returned, implementing an iterative refinement loop that reduces manual debugging and enhances user confidence. For detected errors, the system automatically reformulates the query by adjusting predicates, relaxing constraints, or correcting entity references, then re-executes it. If this second query attempt also returns no results, the system concludes the process and informs the user that the requested data does not appear to exist in the knowledge graph.

Figure 2 presents two representative interactions; we further illustrate the full process with the following question: "Which lab extracts have bioassay results with inhibition percentages above 50% against *Leishmania donovani*?" Upon submission, this question is first classified by the *Entry Agent* and validated by the *Validator Agent* to confirm its relevance to the knowledge graph schema. The *Supervisor Agent* identifies that the question includes a biological target—*Leishmania donovani*—which requires resolution into a standardized identifier. To accomplish this, the *Supervisor Agent* invokes the *KG Agent*, which uses the *TargetResolver* tool to retrieve the corresponding ChEMBL target IRI. The resolved IRI, along with the original question and schema information, is then passed to the *SPARQL Query Runner Agent*. This agent leverages the *GraphSparqlQACchain* tool to construct and execute a SPARQL query against the ENPKG endpoint. The final results, representing lab extracts that meet the specified criteria, are retrieved and stored in CSV format. If further interpretation of the results is needed, the *Supervisor Agent* calls the *Interpreter Agent*, which opens the CSV file with the results and summarizes the output or provides visualizations, such as a bar chart or diagram. This example highlights the coordinated functioning of the agents and tools in transforming a high-level natural-language query into a precise semantic search over the knowledge graph.

We evaluated MetaboT to measure the accuracy of the SPARQL generation task, and identify limitations. Our assessment used 50 representative questions available at https://zenodo.org/records/15236256 crafted to span multiple ontology classes within ENPKG, each question being paired with a reference, manually crafted SPARQL query. Three configurations were compared: GPT-4o in a single-shot mode without orchestration, a multi-agent system using GPT-4o mini, and a multi-agent system using GPT-4o.
The results demonstrated that while GPT-4o operating in isolation struggled with complex queries (8.16% accuracy), GPT-4o mini, when integrated into the multi-agent framework, achieved an accuracy of 12.24%. In contrast, GPT-4o's integration into the multi-agent framework yielded a significantly higher accuracy of 83.67%. This synergistic effect confirms that our multi-agent architecture successfully mitigates the limitations of standalone LLMs for metabolomics knowledge graph exploration. Moreover, the substantial performance gap between GPT-4o mini and GPT-4o within the same architecture highlights the importance of model capacity for tasks requiring precise semantic understanding and structured output generation.

MetaboT is accessible via a web application, deliberately designed to prioritize usability for researchers. It captures natural-language questions and displays results, while the processing is managed by the backend LLM multi-agent framework. Current features—including file uploads, visualizations, and the SpectrumPlotter module that integrates Metabolomics USIs²¹ by constructing a URL to render spectrum plots²²—are implemented as proofs-of-concept that demonstrate the system's extensibility toward other functionalities. Outputs are presented as concise summaries that can be supplemented with optional plots for visual interpretation of complex datasets. MetaboT's design ensures accessibility for researchers without extensive computer science expertise while providing robust data querying capabilities through its interactive query interface, automated SPARQL generation, and built-in error handling.

A critical strength of MetaboT lies in its scalability and adaptability. Although our current demonstration focuses on ENPKG, the modular design supports straightforward extension to other mass spectrometry-based knowledge graphs with minimal reconfiguration. Additionally, the system can interface with different LLM models, which is beneficial given the rapidly evolving LLM landscape. As models advance, the multi-agent architecture allows for seamless integration of new capabilities without requiring extensive modifications, translating directly into improved query precision and reduced processing times²³,²⁴.

Despite these promising results, several limitations remain. In its current state, MetaboT requires high-performance LLMs for optimal accuracy in complex cases, as demonstrated by questions 17, 20, and 48 in our evaluation—complex queries involving multiple entity types and relationship constraints—where GPT-4o significantly outperformed smaller models. While LLM costs are decreasing as performance improves, this expense still presents an adoption barrier for some research communities¹⁴. Additionally, our agent prompts were developed for specific LLM models and may require adaptation to function properly with other models. We postulate that overall efficiency and cost-effectiveness could be improved by implementing a hybrid approach that combines multiple models with varying capabilities alongside automated prompt optimisation strategies.

A notable limitation is MetaboT's restriction to single-graph querying. Currently, researchers must manually connect knowledge graph data with external resources (e.g. subsets of ChEMBL²⁰, Wikidata¹⁹ and LOTUS²⁵), as the system cannot generate federated SPARQL queries that would simultaneously
retrieve information from multiple knowledge graphs. While this is addressed through the incorporation of critical external data directly into the ENPKG knowledge graph employed here, developing true federated query capabilities requires solving fundamental challenges both in terms of query generation and optimization. These include creating efficient knowledge graph indexing systems and graph summaries for source selection, integrating these in the query generation context, and implementing sophisticated query planning algorithms that optimize data retrieval across distributed resources²⁶. Building upon these foundations, a dedicated federated-query module could then execute SERVICE clauses that submit subqueries to remote endpoints (SPARQL 1.2 Federated Query, available at https://www.w3.org/TR/sparql12-federated-query/) to bridge ENPKG with complementary resources, like LOTUS for metabolite-species pairs or bibliographic repositories. Such integration would reveal novel relationships among metabolites, pathways, and phenotypes while leveraging MetaboT's modular architecture.

Looking ahead, we envision MetaboT evolving into a comprehensive toolbox for mass spectrometry data analysis by integrating agents and specialized components for commonly used computational metabolomics approaches. Future developments will focus on automated benchmarking, expanded interoperability with metabolomics tools, and integrating emerging AI capabilities for cheminformatics and biomedical hypothesis generation.¹⁶,²⁷ The framework empowers domain scientists to analyze complex spectral datasets without extensive computer science expertise, bridging the gap between specialized SPARQL query writing and intuitive conversational interactions. By streamlining data querying and analysis through natural language interaction, MetaboT can accelerate metabolomics discoveries—enabling a broader research community to uncover patterns, generate evidence-based hypotheses, and advance from spectral data to chemical and biological insight.

# Online Methods

## Schema and IRI Provision

To accurately generate SPARQL queries from natural language inputs, the LLM needs to be provided with the specific ontology schema and IRIs pertinent to the knowledge graph, as the schema defines the relationships between the nodes¹ and IRIs uniquely identify the entities and properties used in querying². Since LLMs are trained on broad datasets that may not include these specific IRIs, the models may lack specific identifiers required for the entities mentioned in user queries³,⁴. Furthermore, even when relevant IRIs are present in the training data, LLMs are not guaranteed to retrieve them correctly or incorporate them appropriately into SPARQL queries, limiting their effectiveness for precise identifier-based tasks. Consequently, these IRIs must be supplied externally to the LLM alongside the ontology schema to ensure the correct construction of the SPARQL query. This requires dedicated tools and agents within the system that can provide the appropriate IRIs, enabling the LLM to incorporate them accurately into the generated SPARQL query. This approach is supported by the findings of Meyer et al.³ and Avila et al.⁵ who demonstrated that providing LLMs with explicit schema information and IRIs significantly enhances
the accuracy and reliability of SPARQL query generation. Therefore, integrating mechanisms to supply schema and IRI information to the LLM is crucial for the optimal performance of a system like MetaboT.

# System Architecture

MetaboT employs a multi-agent architecture that systematically decomposes complex tasks into discrete subtasks managed by specialised agents (Extended Data Fig. 1). The system is constructed using the LangChain⁶ (version 0.1.11) and LangGraph⁷ (version 0.0.26) libraries, which facilitate the integration of LLMs with external tools and resources. LangChain provides a flexible framework for developing LLM-based applications, incorporating essential components such as:

* **LLM**: Models underpinning the core processing capabilities, including translating natural language queries into SPARQL.

* **Prompts**: Instructions guiding LLMs to achieve targeted outcomes.

* **Chains**: Integrations of prompts and LLMs to produce coherent outputs.

* **Agents**: Units combining LLM chains with tools, where LLMs act as reasoning engines to determine appropriate actions.

LangGraph builds on LangChain to structure the workflow as a directed graph, where each node represents a discrete computational step and edges represent message passing between agents. This stateful graph enables dynamic state evolution as each agent completes its task, allowing for adaptive interactions throughout the query processing pipeline.

Each agent in MetaboT's workflow is represented as a tuple $A_i=(L_i,P_i,T_i)^8$, where:

* $L_i$ is the language model guiding the agent's decision-making.

* $P_i$ is the prompt customised for the agent's purpose.

* $T_i$ is the specific function or tool the agent utilises to fulfil its task.

The system was developed and tested using OpenAI's⁹ GPT-4o model, with GPT-4o mini employed for comparative evaluation. All code and configuration files are available at https://github.com/HolobiomicsLab/MetaboT/.

# Agent Framework

MetaboT implements six primary agents with distinct roles in processing user queries. Each agent is designed to address specific challenges in translating natural language questions into SPARQL queries:

## Entry Agent
**Purpose:** Acts as the gateway to the MetaboT system, determining whether a query is new or related to prior interactions.

**Key Functions:**

* Processes user-provided files via the FileAnalyzer tool

* Forwards new queries to the Validator Agent

* Retrieves context for follow-up questions from conversation history

**Processing Approach:** The agent classifies queries into two categories:

* New Knowledge Questions: Requiring new database information, with validation for clarity and context.

* Help Me Understand Questions: Follow-up queries seeking clarification on previous answers.

This layered approach optimizes query handling and ensures a seamless user experience by maintaining conversation context and avoiding redundant processing.

**Validator Agent**

**Purpose:** Ensures that user questions are appropriate for querying the knowledge graph before further processing.

**Key Functions:**

* Confirms query validity and alignment with the schema and available data

* Uses PlantDatabaseChecker tool to verify the presence of mentioned plant or taxon names

* Routes valid questions to the Supervisor Agent; returns specific feedback for invalid ones

**Processing Approach:** The agent employs in-context learning¹⁰ and few-shot examples by embedding the knowledge graph schema directly in its prompt. This enables cross-checking against the knowledge graph's capabilities, ensuring schema compliance through comparison with example valid and invalid questions.

**Supervisor Agent**

**Purpose:** Acts as the central coordinator, routing user queries to appropriate agents based on content analysis.

**Key Functions:**

* Identifies key entities (taxon names, chemical names, targets, etc.)
* Delegates entity resolution tasks to the KG (knowledge graph) Agent when needed

* Passes processed outputs to the SPARQL Query Runner Agent

**Processing Approach:** The agent follows explicit guidelines for task delegation, entity-specific processing, and managing multi-step query workflows. It includes detailed examples demonstrating proper task routing and error handling procedures, enabling adaptive processing based on query content.

## KG Agent

**Purpose:** Resolves entities mentioned in user queries to provide precise identifiers for knowledge graph elements.

**Key Functions:** Employs specialised tools to retrieve standardised identifiers:

* ChemicalResolver for chemical names (performing RAG on reference file)

* SMILESResolver for molecular structures (using GNPS API¹¹)

* TargetResolver for biological targets (querying ChEMBL API¹²)

* TaxonResolver for taxonomic entities (executing SPARQL on the Wikidata endpoint¹³)

**Processing Approach:** Uses either external APIs, RAG on local files, or SPARQL queries to accurately resolve each entity against authoritative sources rather than relying solely on the LLM's parametric knowledge. This significantly reduces hallucinations by providing ground-truth identifiers for query construction.

## SPARQL Query Runner Agent

**Purpose:** Facilitates SPARQL query generation and data retrieval from the knowledge graph.

**Key Functions:**

* Input Preparation:

* If the question requires Wikidata comparison, it extracts the Wikidata-related part (using WikidataStructureSearch) from the rest of the question and sends only the non-Wikidata component with resolved entities to the GraphSparqlQACchain tool.

* Otherwise, it selects the GraphSparqlQACchain and provides the complete question along with the resolved entities.

* Ensures all required information (user's question, resolved entities, schema details) is properly structured

* Manages query execution and result formatting
* When applicable, uses the OutputMerger tool to combine output from the GraphSparqlQACchain and WikidataStructureSearch tools, providing the final merged result to the supervisor.

**Processing Approach:** The agent emphasises structured input preparation rather than direct query generation, ensuring precise SPARQL construction through comprehensive context provision. It handles external data sources when necessary and formats results appropriately for downstream processing.

## Interpreter Agent

**Purpose:** Bridges the gap between raw data and user-friendly insights.

**Key Functions:**

* Analyse outputs from the SPARQL Query Runner Agent or user-submitted files

* Produce clear summaries of query results

* Generate visualisations (e.g., bar charts, diagrams, mass spectrum plots) when required

**Processing Approach:** Depending on the request, the agent provides structured inputs to its tools, which then analyze the user files and generate visualizations. The agent follows detailed guidelines for processing query results and user files, ensuring that all data is presented in an accessible, informative format tailored to the user's query.

## Tools Integration

MetaboT employs nine specialised tools for entity resolution and query processing, each addressing specific challenges in knowledge graph interrogation:

### 1. PlantDatabaseChecker

**Objective:** Verify the presence of plant names within a pre-existing database to filter queries based on data availability.

**Input:** Plant name string provided by user query.

**Process:** Loads a CSV file containing plant names considered in the ENPKG analysis and searches for exact matches of the input name in the designated column.

**Output:** Returns confirmation of the plant's presence or absence, with appropriate error handling for file access issues.

### 2. ChemicalResolver
**Objective:** Resolve chemical names to standardised chemical class identifiers (NPCClass URIs).

**Input:** Chemical name string extracted from user query.

**Process:** Matches chemical names to NPCClass URIs using a Facebook AI Similarity Search<sup>14</sup> (FAISS) database with OpenAI embeddings<sup>15</sup>. This involves loading a precompiled CSV file extracted from the knowledge graph and containing NPCClass data, processing it into searchable chunks, creating embedding vectors, and generating a retriever object.

**Output:** Returns NPCClass URI with type information.

### 3. SMILESResolver

**Objective:** Convert SMILES (Simplified Molecular Input Line Entry System)<sup>16</sup> molecular representations to standardised InChIKeys<sup>17</sup> for chemical interoperability.

**Input:** SMILES string representing molecular structure.

**Process:** Sends SMILES strings to the Global Natural Products Social Molecular Networking (GNPS) API to retrieve corresponding InChIKeys.

**Output:** Returns standardised InChIKey with logging of process status.

**Error Handling:** Implements robust logging for API request issues and exception handling for system notification.

### 4. TargetResolver

**Objective:** Map biological target names to standardised ChEMBL Target IRIs<sup>12</sup>.

**Input:** Biological target name string.

**Process:** Queries the ChEMBL API to locate matches based on target names, parsing XML responses to extract and format ChEMBL target IDs as IRIs.

**Output:** Returns formatted ChEMBL Target IRI for the biological target.

**Error Handling:** Provides logging for successful and unsuccessful API calls, with suggestions for refining target names when no matches are found.

### 5. TaxonResolver

**Objective:** Resolve taxonomic names to their corresponding Wikidata IRIs.
**Input**: Taxonomic name string.

**Process**: Constructs and executes SPARQL queries on the Wikidata endpoint to retrieve unique IRIs associated with taxon names.

**Output**: Returns Wikidata IRI for the taxonomic entity.

**Error Management**: Implements robust error handling for unexpected formats and connectivity issues, with clear logging of outcomes.

## 6. FileAnalyzer

**Objective**: Analyse user-provided files and generate content summaries.

**Input**: User-uploaded files and session identifier.

**Process**: Initialises session-specific directories, identifies file types, and applies tailored analysis methods:

* For spreadsheets: Extracts rows, columns, headers, and sample data using `pandas`¹⁸

* For MGF files: Counts the number of spectra feature IDs

* For text files: Provides line counts for identifying the number of features present.

**Output**: Produces structured summaries with file paths, sizes, and content-specific details for downstream processing.

## 7. GraphSparqlQAChain

**Objective**: Generate and execute SPARQL queries aligned with the knowledge graph's schema.

**Input**: User question, schema information in *Turtle*¹⁹ format, and resolved entity identifiers.

**Process - Query Generation**: Uses LLMs with structured prompts combining in-context learning, chain-of-thought reasoning²⁰, and one-shot examples to create schema-compliant queries.

**Process - Query Refinement**: When initial queries yield no results, identifies schema nodes related to the original query and leverages similar queries from a FAISS database to regenerate more accurate commands.

**Process - Result Processing**: Executes queries on the knowledge graph endpoint and saves outputs to temporary CSV files.

**Output**: Returns query results with contextual information and file paths for downstream processing.
**Error Handling**: Removes extraneous elements from generated queries and ensures compliance with the knowledge graph's schema. Manages token limits and optimises results for the LLM's context window.

# 8. WikidataStructureSearch

**Objective**: Retrieve compound annotations associated with a taxon (e.g., plant genus) using its Wikidata ID.

**Input**: A string representing the Wikidata ID of a taxon.

**Process**: Constructs and executes a SPARQL query on the Wikidata endpoint to retrieve the Wikidata IRIs of chemical compounds annotated to species within the genus of the given taxon. The results are saved in a temporary CSV file.

**Output**: Path to a CSV file containing the list of compound Wikidata IRIs, or None if no results are found.

# 9. OutputMerger

**Objective**: Identify overlapping Wikidata compound annotations between results from two different SPARQL endpoints.

**Input**: Two file paths to CSV files containing Wikidata IDs—one from the ENPKG endpoint (GraphSparqlQACchain), and one from the Wikidata endpoint (WikidataStructureSearch).

**Process**: Loads both CSV files, strips and standardizes ID formatting, identifies common Wikidata IDs between the two datasets, removes duplicates, and saves the final list to a temporary CSV file.

**Output**: Path to a CSV file containing the list of common Wikidata IDs.

# 10. Interpreter

**Objective**: Contextualise query results through appropriate summaries and visualisations.

**Input**: SPARQL query results, file paths, and user question.

**Process - Input Processing**: parses agent inputs to extract questions, file paths, and contextual information.

**Process - Session-based Interpretation**: Utilizes codeinterpreter-api²¹ to generate meaningful interpretations of query results and produces JSON code for Plotly²² graphs on request, leveraging sandboxed Python execution.

**Output**: Returns textual summaries and, when visualizations are requested, generates JSON files containing Plotly graph code and returns their file paths.
**Output Management**: Logs processing steps, saves visualisation files to session directories, and provides accessible file paths to users.

# 11. SpectrumPlotter

**Objective**: Provide a URL that displays a plot of a spectrum based on a given Universal Spectrum Identifier (USI)²³.

**Input**: A USI value that uniquely identifies the spectrum or a file path (CSV) that includes a column named "usi".

**Process - URL Construction**: Once a valid USI is obtained, a URL is constructed in the format: `https://metabolomics-usi.gnps2.org/dashinterface/?usi1={usi}`
This URL points to Metabolomics Spectrum Resolver²⁴ dashboard that renders the spectrum plot.

**Output**: The constructed URL where the spectrum plot can be viewed.

# SPARQL Query Generation and Execution

The GraphSparqlQAChain tool implements a sophisticated process for translating natural language questions into executable SPARQL queries:

**Initial Query Generation**: The tool combines the user's question with schema information (in Turtle format) and resolved entity identifiers to generate a SPARQL SELECT query²⁵. For example, a user question about "bioactive compounds in *Tabernaemontana coffeoides*" would be combined with the Wikidata IRI for *Tabernaemontana coffeoides* (Q15376858) and schema properties to construct a query. The generation prompt ensures adherence to content clarity, proper prefix usage, schema alignment, and validation requirements. By combining in-context learning, chain-of-thought prompting, and one-shot examples, the prompt guides the LLM to produce well-structured, syntactically correct queries.

**Query Execution and Result Analysis**: Generated queries are executed on the knowledge graph endpoint, with results analysed for completeness and relevance. If a query yields no results or errors, the tool initiates a refinement process.

**Query Refinement**: For unsuccessful queries, the tool identifies schema nodes related to the initial query and retrieves one similar query from a stored database. Using these insights, it prompts the LLM to regenerate a more accurate, schema-compliant query. This refinement is performed only once, guided by concise schema information, step-by-step reasoning, and validation criteria.

**Result Processing**: Successfully executed query results are saved to a temporary CSV file for downstream analysis. Token usage is monitored to ensure compatibility with the LLM's context window, with results truncated if necessary. If the combined tokens from the generated SPARQL query, the user's
question, and the output from the knowledge graph exceed a specified limit (6000 tokens), the full
results are not passed to the LLM; instead, users can retrieve the complete output from the generated
CSV file.

An important component of the refinement workflow is the tool's ability to distinguish between errors in
query construction and the actual absence of relevant data in the knowledge graph. For example, if a
query about "terpenes in *Tabernaemontana coffeoides*" returns no results, the system first assesses
whether the query might be improperly constructed. It then attempts to regenerate the query—if the
regenerated query yields results, this confirms that the initial failure was due to construction errors.
However, if the regenerated query still fails, this may either indicate that the knowledge graph truly lacks
data on the topic or that errors persist in the query formulation. This distinction enables targeted
refinement strategies that enhance overall system reliability.

Interaction Between Agents

Agent interaction is orchestrated through a directed graph structure (Extended Data Fig. 2), with
messages passing along edges from one agent to the next. The output of each agent becomes the input
for subsequent agents, enabling seamless information flow and decision-making throughout the system.
For instance, after the Entry Agent determines a query's nature, it passes relevant data to the Validator
Agent via their connecting edge.

This structured communication ensures that each agent operates with the most current and relevant
information, enhancing system efficiency and accuracy. To monitor and analyse these interactions
during development and evaluation, we utilised LangSmith²⁶ (version 0.1.22), a platform for developing,
testing, and evaluating LLM-based applications. Through LangSmith, we systematically evaluated each
agent's performance, tracked interactions, and identified refinement opportunities within the multi-agent
system.

Evaluation Procedure

Assessing MetaboT's performance presented unique challenges due to its capacity to handle diverse
and complex tasks. We implemented an automated evaluation process using LangSmith's evaluation
workflow²⁷, with LLM-based evaluators assessing outputs against criteria including correctness,
accuracy, and SPARQL query similarity to reference standards. In addition to these automated
evaluators, we conducted manual evaluations to validate the performance of the LLM evaluators,
acknowledging that they can occasionally hallucinate²⁸.

For comprehensive MetaboT evaluation, we created a synthetic dataset comprising 50 questions across
different ontology classes within ENPKG, each paired with a reference SPARQL query. The questions
were crafted with the help of domain experts, considering the classes and properties present in the
schema of the knowledge graph. These questions were then submitted to MetaboT, which generated initial SPARQL queries. We manually reviewed and corrected these queries based on the knowledge graph schema to ensure semantic correctness and full alignment with the intent of each question.

These questions were categorised by complexity:

* Low complexity (11 questions): Simple entity retrieval (e.g., "List all compounds found in *Lovoa trichilioides*")

* Medium complexity (19 questions): Multi-step operations (e.g., "Find all plant species containing flavonoids with molecular weight > 300")

* High complexity (20 questions): Complex relationships and filtering (e.g., "Which compounds in *Acer* species have been reported to interact with human kinase targets and show molecular similarity (cosine score) > 0.7 to known anti-inflammatory compounds?")

We first conducted a baseline evaluation to determine whether GPT-4o alone, without the multi-agent system, could generate accurate SPARQL queries. Questions were submitted directly to GPT-4o alongside the schema in Turtle format, using a prompt analogous to that of the Query Generation chain from GraphSPARQLQACchain. Results showed that standalone GPT-4o produced inaccurate queries with property mismatches and incorrect entity identifiers, highlighting the necessity for our structured multi-agent approach.

Building on this baseline, we evaluated three configurations to compare standalone performance with the multi-agent system, and to assess the effect of different underlying LLMs:

1. GPT-4o in a single-shot mode without orchestration

2. MetaboT using GPT-4o mini as the underlying LLM

3. MetaboT using GPT-4o within the full multi-agent framework

The evaluation setup isolated individual components to identify performance bottlenecks. Each configuration processed identical queries under controlled conditions, with consistent hardware and network environments to ensure comparable results. It is important to note that this evaluation was performed only up to the point of SPARQL query generation; it did not include the Interpreter Agent, and therefore, the interpretation of query results was not evaluated. The goal was to ensure that all components leading to the generation of SPARQL queries were functioning correctly.

Average query processing time was 10.04 seconds for the single-shot GPT-4o approach, 36.28 seconds for the GPT-4o mini configuration, and 80.45 seconds for the GPT-4o multi-agent system. For the single-shot GPT-4o approach, processing time was measured from the moment the prompt was submitted until the SPARQL query was generated. For the GPT-4o mini configuration, the average time was computed only for those questions in which all agents were invoked; in many cases, the Validator Agent hallucinated, halting the workflow before it reached the SPARQL Query Runner Agent. Finally, for
MetaboT using GPT-4o within the multi-agent system, the processing time was measured for all questions, from initial submission until the final agent completed its task.

Our LLM-based evaluators compared system-generated outputs with reference outputs, providing detailed feedback on discrepancies. This evaluation process occurred iteratively across three rounds, with prompt refinements between rounds addressing identified issues. In addition to evaluator feedback, a manual evaluation was performed to further assess the outputs, considering the potential for LLMs to hallucinate.

For 3 out of the 50 questions, the SPARQL refinement chain regenerated queries by using formulations identical to the correct reference queries for those questions; however, this approach proved beneficial for only 1 question, and consequently, that question was removed from the overall accuracy count. In the other 2 cases, the core issue was that the Supervisor did not invoke the KG agent to retrieve the necessary entities.

The results (Supplementary Table 1) demonstrated that while GPT-4o operating in isolation struggled with complex queries (achieving only 8.16% overall accuracy), its integration into the multi-agent framework achieved an 83.67% accuracy rate—a substantial improvement over both the standalone model and the GPT-4o mini-based system (12.24% accuracy). This performance difference was particularly pronounced for high-complexity queries, where the multi-agent GPT-4o configuration maintained 78.95% accuracy while the standalone GPT-4o failed completely (0% accuracy). Interestingly, the GPT-4o mini-based MetaboT system performed better on high-complexity questions than on low-complexity ones. This counterintuitive result likely stems from the fact that low-complexity questions often omit explicit entity mentions, making them harder for the Validator Agent—powered by a weaker LLM—to validate.

Error analysis revealed four primary error types:

*Type 1* —Validator misclassifying questions as invalid (e.g., rejecting valid queries about plant metabolites)

*Type 2* —Incorrect SPARQL queries generated (e.g., using incompatible properties or malformed syntax)

*Type 3* — Supervisor failing to call the Knowledge Graph agent when needed (e.g., for queries requiring entity resolution)

*Type 4* — Knowledge Graph agent selecting inappropriate tools (e.g., using TaxonResolver for chemical entities)

These findings informed subsequent system refinements and highlighted the synergistic benefits of our multi-agent architecture for metabolomics knowledge graph exploration.
# Hardware and Software Requirements

MetaboT was developed and tested on systems with the following specifications:

* **CPU**: Modern processors (Intel Core i7 13th generation or equivalent)

* **RAM**: Minimum 8GB recommended

* **Operating Systems**: macOS Sonoma (14.5), Ubuntu 22.04 LTS, and Debian 11

* **Python**: Version 3.10

* **Core Libraries**: LangChain 0.1.11, LangGraph 0.0.26, FAISS 1.8.0, OpenAI 1.61.0, pandas 2.2.1, plotly 5.20.0

The system is accessible via a web application interface and can be deployed using the provided Docker configuration or through direct installation following the repository instructions. Detailed setup information, environment configurations, and dependency management are available in the project documentation.

# Limitations and Future Directions

Despite its effectiveness, MetaboT exhibits several limitations that warrant acknowledgement:

**Hallucinations**: LLMs occasionally generate incorrect objects or properties, leading to errors in query construction. For instance, the model might confuse properties of `"InChIKey"` with `"InChIKey2D"` or apply properties to incompatible classes. These hallucinations can also cause agents to invoke inappropriate tools, such as using TaxonResolver for queries about biological targets.

**Non-determinism**: The inherent variability in LLM outputs means that identical queries may yield slightly different SPARQL commands, potentially reducing user confidence. While this variability occasionally benefits exploration, it can create inconsistency in system performance.

**Computational Cost**: MetaboT's multi-agent architecture requires multiple LLM API calls for each user question, resulting in corresponding computational expenses. A typical query incurs 5-8 API calls depending on complexity. Additionally, providing detailed schema information and examples in prompts increases token counts and overall operational costs. On average, each complete query processing cycle consumes approximately 22,240 tokens (including both prompt and completion tokens), translating to an average cost of $0.06 per question. The maximum cost observed was $0.092, corresponding to a high-complexity question, while the minimum cost was $0.041, corresponding to a low-complexity question.

To mitigate these issues, MetaboT incorporates deterministic functions as tools, reducing reliance on the language model alone and enhancing accuracy. Extensive prompt engineering guides LLMs toward more consistent and contextually accurate outputs. By refining prompts and incorporating stable,
reliable functions, MetaboT aims to minimise the effects of hallucinations, non-determinism, and token-
related costs.

Future developments will focus on automated benchmarking systems for continuous performance
assessment, expanded interoperability with additional knowledge graphs and resources, and integration
with complementary metabolomics tools to create a comprehensive ecosystem for mass spectrometry
data analysis.

References

1. Zouaq, A. & Martel, F. What is the schema of your knowledge graph? leveraging knowledge graph embeddings and clustering for expressive taxonomy learning. in *Proceedings of The International Workshop on Semantic Big Data* 1–6 (Association for Computing Machinery, New York, NY, USA, 2020). doi:10.1145/3391274.3393637.

2. Steve Harris, A. S. SPARQL Query Language for RDF. https://www.w3.org/TR/rdf-sparql-query/ (2013).

3. Meyer, L.-P., Frey, J., Brei, F. & Arndt, N. Assessing SPARQL capabilities of Large Language Models. Preprint at http://arxiv.org/abs/2409.05925 (2024).

4. Kovriguina, L., Teucher, R., Radyush, D. & Mouromtsev, D. SPARQLGEN: One-Shot Prompt-based Approach for SPARQL Query Generation.

5. Avila, C. V. S., Vidal, V. M. P., Franco, W. & Casanova, M. A. Experiments with text-to-SPARQL based on ChatGPT. in *2024 IEEE 18th International Conference on Semantic Computing (ICSC)* 277–284 (2024). doi:10.1109/ICSC59802.2024.00050.

6. LangChain. https://www.langchain.com/.

7. LangGraph. https://www.langchain.com/langgraph.

8. Topsakal, O. & Akinci, T. C. Creating Large Language Model Applications Utilizing LangChain: A Primer on Developing LLM Apps Fast. *Int. Conf. Appl. Eng. Nat. Sci.* **1**, 1050–1056 (2023).

9. Models - OpenAI API. https://platform.openai.com.

10. Dong, Q. et al. A Survey on In-context Learning. Preprint at
https://doi.org/10.48550/arXiv.2301.00234 (2024).

11. Wang, M. et al. Sharing and community curation of mass spectrometry data with Global Natural Products Social Molecular Networking. *Nat. Biotechnol.* **34**, 828–837 (2016).

12. Zdrazil, B. et al. The ChEMBL Database in 2023: a drug discovery platform spanning multiple bioactivity data types and time periods. *Nucleic Acids Res.* **52**, D1180–D1192 (2024).

13. Waagmeester, A. et al. Wikidata as a knowledge graph for the life sciences. *eLife* **9**, e52614 (2020).

14. facebookresearch/faiss. Meta Research (2025).

15. Vector embeddings - OpenAI API. https://platform.openai.com.
16. Weininger, D. SMILES, a chemical language and information system. 1. Introduction to methodology and encoding rules. *J. Chem. Inf. Comput. Sci.* **28**, 31–36 (1988).

17. Heller, S., McNaught, A., Stein, S., Tchekhovskoi, D. & Pletnev, I. InChI - the worldwide chemical structure identifier standard. *J. Cheminformatics* **5**, 7 (2013).

18. pandas: Powerful data structures for data analysis, time series, and statistics.

19. RDF 1.1 Turtle. https://www.w3.org/TR/turtle/#language-features.

20. Wei, J. et al. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. Preprint at https://doi.org/10.48550/arXiv.2201.11903 (2023).

21. shroominic/codeinterpreter-api: Open source implementation of the ChatGPT Code Interpreter. https://github.com/shroominic/codeinterpreter-api?tab=readme-ov-file.

22. Kruchten, N., Seier, A. & Parmer, C. An interactive, open-source, and browser-based graphing library for Python. https://doi.org/10.5281/zenodo.14503524 (2024).

23. Universal Spectrum Identifier - HUPO Proteomics Standards Initiative. https://www.psidev.info/usi (2023).

24. Bittremieux, W. et al. Universal MS/MS Visualization and Retrieval with the Metabolomics Spectrum Resolver Web Service. 2020.05.09.086066 Preprint at https://doi.org/10.1101/2020.05.09.086066 (2020).

25. Steve Harris, A. S. SPARQL 1.1 Query Language. https://www.w3.org/TR/sparql11-query/#select (2013).

26. LangSmith. https://www.langchain.com/langsmith.

27. Evaluation Quick Start | LangSmith. https://docs.smith.langchain.com/evaluation.

28. Gu, J. et al. A Survey on LLM-as-a-Judge. Preprint at https://doi.org/10.48550/arXiv.2411.15594 (2025).

29. Allard, P.-M. et al. Open and reusable annotated mass spectrometry dataset of a chemodiverse collection of 1,600 plant extracts. *GigaScience* **12**, giac124 (2023).

# Declarations

## Acknowledgements

This work has been supported by the French government, through the UCAJEDI Investments in the Future project managed by the National Research Agency (ANR) with the reference number ANR-15-IDEX-01. M.B. acknowledges Ph.D. fellowship support from the Interdisciplinary Institute for Artificial Intelligence, 3IA Côte d'Azur (ANR-19-P3IA-0002). L.P. was funded by the Luxembourg National Research Fund (FNR; project 17994255). E.T. received funding from the MIT International Science and Technology Initiatives through the MIT-France Program. O.K., F.M., M.P., J.L.W. and L-F.N. were supported by the Swiss National Science Foundation (SNSF project CRSII5_189921/1). W.B. was supported by the Research Foundation-Flanders (FWO G087625N) and the University of Antwerp Research Fund.
Additional support came from the French Government's France 2030 investment plan (ANR-22-CPJ2-0048-01), as well as through the MetaboLinkAI bilateral project (ANR-24-CE93-0012-01 and SNSF 10002786). The figures were composed using Microsoft PowerPoint and include components adapted from BioRender.com (https://www.biorender.com), icons sourced from Freepik (https://www.freepik.com), icons available within PowerPoint's standard library, and extended data figures generated using Mermaid (https://mermaid.js.org). The funders had no role in the study design, data collection and analysis, decision to publish, or manuscript preparation.

## Author Information

These authors jointly supervised this work: Wout Bittremieux, Fabien Gandon, Louis-Félix Nothias

## Authors and Affiliations

Université Côte d'Azur, CNRS, ICN, Nice, France & Interdisciplinary Institute for Artificial Intelligence (3iA)
Côte d'Azur, Sophia-Antipolis, France

Lucas Pradi, Benjamin Navet, Emma, Tysinger, Matthieu Feraud, Yousouf Taghzouti, Martin Legrand, Tao Jiang, Louis-Félix Nothias

Université Côte d'Azur, CNRS, ICN, Nice, France, Interdisciplinary Institute for Artificial Intelligence (3iA)
Côte d'Azur, Sophia-Antipolis, France & Department of Computer Science & University of Antwerp,
Antwerp, Belgium

Madina Bekbergenova

Department of Electrical Engineering and Computer Science, MIT, Cambridge, MA, USA & :probabl., Paris,
France

Emma Tysinger

INRIA, Université Côte d'Azur, CNRS, I3S, France & Interdisciplinary Institute for Artificial Intelligence (3iA)
Côte d'Azur, Sophia-Antipolis, France

Emma Tysinger, Franck Michel, Yousouf Taghzouti, Fabien Gandon

Department of Computer Science, Tufts University, Medford, MA 02155, USA

Yan Zhou Chen

Department of Computer Science, Tufts University, Medford, MA 02155, USA & Department of Chemical
and Biological Engineering, Tufts University, Medford, MA 02155, USA

Soha Hassoun
M.B., F.G. and L-F.N. conceptualized the method; S.H., W.B., J-L.W. and M.P. contributed to method conception and evaluation; M.B., L.P., B.N., E.T., F.Mi. and M.F. implemented the software; M.B. performed the analysis; M.B., Y.T., Y.Z.C., O.K., F.Me., M.L. and T.J. tested the method; W.B., F.G. and L-F.N. co-supervised the project; M.B., W.B., F.G. and L-F.N. wrote and edited the manuscript. All authors read and approved the final manuscript.

F.G. is cofounder and co-scientific advisor of :probabl., E.T. is now employee of :probabl. All other authors declare no competing interests.

**Data Availability**

The Experimental Natural Products Knowledge Graph (ENPKG) dataset used for development and evaluation of MetaboT contains annotated mass spectrometry data derived from 1,600 plant extracts. This dataset is publicly accessible through the ENPKG SPARQL endpoint at https://enpkg.commons-lab.org/graphdb/repositories/ENPKG. The dataset was originally published by Allard et al.²⁹ and includes comprehensive metabolomic profiling of plant extracts with standardised annotations.

The synthetic evaluation dataset comprising 50 reference questions with corresponding SPARQL queries, categorised by complexity levels (low, medium, high), is available in the project repository at https://github.com/HolobiomicsLab/MetaboT/tree/main/app/data/evaluation_dataset.csv and also archived on Zenodo at https://zenodo.org/records/15236256. This evaluation set was designed to assess system performance across diverse query types relevant to metabolomics research.
All example queries and their results presented in this paper can be reproduced using the public ENPKG endpoint and the MetaboT system. The chemical structure database used for entity resolution via the ChemicalResolver tool references. Taxonomic information is retrieved from Wikidata, and biological target information is sourced from the ChEMBL database, both of which are open access resources.

Researchers wishing to apply MetaboT to their own data can follow the conversion pipeline described in the ENPKG documentation (https://github.com/enpkg/enpkg_full) to transform mass spectrometry processing and annotation results into a compatible knowledge graph format.

## Code Availability

The complete source code for MetaboT is available as an open-source project under the Apache 2.0 License through GitHub at https://github.com/HolobiomicsLab/MetaboT. This repository includes all component code, configuration files, agent implementations, prompt templates, and evaluation scripts necessary to reproduce the system described in this paper.

The repository contains comprehensive documentation including installation instructions, configuration guides, and usage examples. Docker configuration files are provided to facilitate deployment in containerised environments. Dependencies are managed through Conda environment files that specify exact version requirements for all libraries.

Primary software dependencies include Python 3.10, LangChain 0.1.11, LangGraph 0.0.26, FAISS 1.8.0, and OpenAI 1.61.0. The system was developed and evaluated using OpenAI's GPT-4o model, though the architecture supports alternative LLM backends through configuration settings. For local development without API dependencies, the repository includes a demonstration mode with sample responses.

A public instance of MetaboT connected to the ENPKG dataset is accessible for testing and exploration at https://metabot.holobiomicslab.cnrs.fr. This instance allows researchers to interact with the system and evaluate its capabilities without local installation.

The evaluation procedure is executed via the script located at https://github.com/HolobiomicsLab/MetaboT/blob/main/app/core/tests/evaluation.py. The version of the code used for the analyses and evaluation results presented here is tagged as v1.0-evaluation (DOI: 10.5281/zenodo.15236256) and is also available at https://github.com/HolobiomicsLab/MetaboT/tree/evaluation-v.

## References

1. Guo, J., Yu, H., Xing, S. & Huan, T. Addressing big data challenges in mass spectrometry-based metabolomics. *Chem. Commun.* **58**, 9979–9990 (2022).
2. Schmid, R. et al. Integrative analysis of multimodal mass spectrometry data in MZmine 3. *Nat. Biotechnol.* **41**, 447–449 (2023).

3. Wang, M. et al. Sharing and community curation of mass spectrometry data with Global Natural Products Social Molecular Networking. *Nat. Biotechnol.* **34**, 828–837 (2016).

4. Röst, H. L. et al. OpenMS: a flexible open-source software platform for mass spectrometry data analysis. *Nat. Methods* **13**, 741–748 (2016).

5. Dührkop, K. et al. Systematic classification of unknown metabolites using high-resolution fragmentation mass spectra. *Nat. Biotechnol.* **39**, 462–471 (2021).

6. Alseekh, S. et al. Mass spectrometry-based metabolomics: a guide for annotation, quantification and best reporting practices. *Nat. Methods* **18**, 747–756 (2021).

7. Ebbels, T. M. D. et al. Recent Advances in Mass Spectrometry-Based Computational Metabolomics. *Curr. Opin. Chem. Biol.* **74**, 102288 (2023).

8. Meijer, D. et al. Empowering natural product science with AI: leveraging multimodal data and knowledge graphs. *Nat. Prod. Rep.* **42**, 654–662 (2025).

9. Gaudry, A. et al. A Sample-Centric and Knowledge-Driven Computational Framework for Natural Products Drug Discovery. *ACS Cent. Sci.* **10**, 494–510 (2024).

10. Rony, M. R. A. H., Kumar, U., Teucher, R., Kovriguina, L. & Lehmann, J. SGPT: A Generative Approach for SPARQL Query Generation From Natural Language Questions. *IEEE Access* **10**, 70712–70723 (2022).

11. Perevalov, A., Gashkov, A., Eltsova, M. & Both, A. Understanding SPARQL Queries: Are We Already There? Multilingual Natural Language Generation Based on SPARQL Queries and Large Language Models. in *The Semantic Web – ISWC 2024* 173–191 (Springer, Cham, 2025). doi:10.1007/978-3-031-77850-6_10.

12. Meyer, L.-P., Frey, J., Brei, F. & Arndt, N. Assessing SPARQL capabilities of Large Language Models. Preprint at http://arxiv.org/abs/2409.05925 (2024).

13. Emonet, V., Bolleman, J., Duvaud, S., Farias, T. M. de & Sima, A. C. LLM-based SPARQL Query Generation from Natural Language over Federated Knowledge Graphs. Preprint at https://doi.org/10.48550/arXiv.2410.06062 (2024).

14. Sima, A.-C. & de Farias, T. M. On the Potential of Artificial Intelligence Chatbots for Data Exploration of Federated Bioinformatics Knowledge Graphs. *arXiv.org* https://arxiv.org/abs/2304.10427v1 (2023).

15. Lobentanzer, S. et al. Democratizing knowledge representation with BioCypher. *Nat. Biotechnol.* **41**, 1056–1059 (2023).

16. Lobentanzer, S. et al. A platform for the biomedical application of large language models. *Nat. Biotechnol.* **43**, 166–169 (2025).

17. Zahera, H. M., Ali, M., Sherif, M. A., Moussallem, D. & Ngomo, A.-C. N. Generating SPARQL from Natural Language Using Chain-of-Thoughts Prompting. in (2024).
18. Zong, C. et al. Triad: A Framework Leveraging a Multi-Role LLM-based Agent to Solve Knowledge Base Question Answering. Preprint at https://doi.org/10.48550/arXiv.2402.14320 (2024).

19. Waagmeester, A. et al. Wikidata as a knowledge graph for the life sciences. *eLife* **9**, e52614 (2020).

20. Zdrazil, B. et al. The ChEMBL Database in 2023: a drug discovery platform spanning multiple bioactivity data types and time periods. *Nucleic Acids Res.* **52**, D1180–D1192 (2024).

21. Universal Spectrum Identifier - HUPO Proteomics Standards Initiative. https://www.psidev.info/usi (2023).

22. Bittremieux, W. et al. Universal MS/MS Visualization and Retrieval with the Metabolomics Spectrum Resolver Web Service. 2020.05.09.086066 Preprint at https://doi.org/10.1101/2020.05.09.086066 (2020).

23. Chen, S., Liu, Y., Han, W., Zhang, W. & Liu, T. A Survey on LLM-based Multi-Agent System: Recent Advances and New Frontiers in Application. Preprint at https://doi.org/10.48550/arXiv.2412.17481 (2025).

24. Guo, T. et al. Large Language Model based Multi-Agents: A Survey of Progress and Challenges. Preprint at https://doi.org/10.48550/arXiv.2402.01680 (2024).

25. Rutz, A. et al. The LOTUS Initiative for Open Natural Products Research: Knowledge Management through Wikidata. 2021.02.28.433265 Preprint at https://doi.org/10.1101/2021.02.28.433265 (2021).

26. Heling, L. & Acosta, M. A Framework for Federated SPARQL Query Processing over Heterogeneous Linked Data Fragments. Preprint at https://doi.org/10.48550/arXiv.2102.03269 (2021).

27. M. Bran, A. et al. Augmenting large language models with chemistry tools. *Nat. Mach. Intell.* **6**, 525–535 (2024).

## Figures
<figure><img src="image_2.png" /><figcaption>Figure 1</figcaption></figure>

MetaboT overview. a) A user's natural-language question is translated into a SPARQL query and executed against the mass spectrometry knowledge graph, returning the final answer. b) Detailed schematic of the multi-agent architecture, highlighting specialized agents and tools for entity resolution, query validation, and result interpretation. Note: "SPARQL Agent" in the figure refers to the SPARQL Query Runner Agent described in the main text.
a) Analyzing annotation results

<figure><img src="image_3.png" /></figure>

Researcher

How many metabolites were annotated with SIRIUS in *Tabernaemontana coffeoides* molecular formula score (ZODIAC) above 0.9 and confidence score (COSMIC) above 0.3 ?

<figure><img src="image_4.png" /></figure>

MetaboT

<figure><img src="image_5.png" /></figure>

- MetaboT retrieved the plant entity: http://www.wikidata.org/entity/Q15376858.

- The corresponding number of metabolites is 728. Here is the generated SPARQL query used:

```sql
SELECT (COUNT(DISTINCT ?feature) AS ?metaboliteCount)
WHERE { ?rawMaterial ns1:has_wd_id
<http://www.wikidata.org/entity/Q15376858> .
?rawMaterial ns1:has_lab_process ?labExtract .
?labExtract ns1:has_LCMS ?analysis . ?analysis
ns1:has_lcms feature_list ?featureList . ?featureList
ns1:has_lcms feature ?feature . ?feature
ns1:has sirius annotation ?annotation . ?annotation
ns1:has zodiac score ?zodiacScore . ?annotation
ns1:has cosmic score ?cosmicScore . FILTER(?zodiacScore
> 0.9 && ?cosmicScore > 0.3) }
```

b) Comparing multi-sample metabolite composition

<figure><img src="image_6.png" /></figure>

Researcher

Which plant extracts have the highest count of metabolites annotated as aspidosperma-type alkaloids?

Here is the list of plant extracts from the dataset ...

<figure><img src="image_7.png" /></figure>

MetaboT

<figure><img src="image_8.png" /></figure>

<figure><img src="image_9.png" /></figure>

Can you generate a distribution plot for the count of features for those extracts ?

Here is the distribution plot for the count of features:

<figure><img src="image_10.png" /></figure>

<figure><img src="image_11.png" /></figure>

MetaboT

<figure><img src="image_12.png" /></figure>

<figure><img src="image_13.png" /></figure>

Provide similar analysis for the extracts that have features annotated as Tetraketide meroterpenoids. Order the extracts by decreasing count of features.

Here is the list of extracts [...] and the distribution plot:

<figure><img src="image_14.png" /></figure>

<figure><img src="image_15.png" /></figure>

MetaboT

<figure><img src="image_16.png" /><figcaption>Figure 2</figcaption></figure>

Representative interactions with MetaboT. a) Annotation query. From *Tabernaemontana coffeoides*, MetaboT retrieves 728 metabolites annotated by SIRIUS (ZODIAC > 0.9, COSMIC > 0.3) and shows the generated SPARQL. b) Cross-sample comparison. MetaboT ranks extracts by counts of aspidosperma alkaloids, plots the distribution, and repeats the analysis for tetraketide meroterpenoids. Green panels are MetaboT responses; brown panels are researcher prompts.

Supplementary Files

This is a list of supplementary files associated with this preprint. Click to download.

* SupplementaryMaterial.docx