A Hybrid Agentic RAG Architecture with Knowledge Graphs and Text-to-SQL for Automating Citizen Services in a Public Scientific Institution

1. Introduction

The emergence of generative artificial intelligence and large language models (LLMs) has opened new opportunities to modernize interactions between the State and its citizens [1,2]. However, deploying these technologies in institutional settings, where technical accuracy, legal grounding, and data transparency are non-negotiable, faces a critical barrier: the propensity of LLMs to produce “hallucinations”, that is, fluent but factually incorrect or unsubstantiated content [3].

Public-administration research has examined the determinants of chatbot adoption in government agencies [4], the results reported by the agencies that use them [2], and their impact on public service provision as perceived by citizens and service providers [5]. Analyses of the governance of generative AI likewise identify hallucination and inaccuracy among its principal risks [6]. Together, these studies indicate that the value of a citizen-facing assistant depends not only on its conversational fluency but, above all, on the verifiability of the information it delivers.

In Peru, public entities must answer citizen information requests within 10 business days under Law No. 27806 on Transparency and Access to Public Information [7]. However, the administrative load generated by a high volume of routine inquiries creates operational bottlenecks that can lead to non-compliance. At the Marine Institute of Peru (IMARPE), the state institution responsible for fisheries and oceanographic research, records for August–December 2025 (n = 196 requests) showed a mean response time of 12 business days, above the legal limit. Analysis of these records found that 26.9% of the requests were low-complexity routine queries that required only the extraction of data already available in institutional yearbooks or in the biological database IMARSIS [8].

Deploying a generic LLM chatbot to address this bottleneck would introduce unacceptable risks: a system that fabricates fisheries statistics or taxonomic classifications could create legal liabilities and erode public trust. Retrieval-augmented generation (RAG) [9] addresses this problem by conditioning the model’s output on passages retrieved from a controlled knowledge corpus, which grounds factual content and reduces hallucinations.

This risk is amplified in scientific institutions, whose repositories contain verifiable quantitative claims such as biomass statistics, taxonomic records, and oceanographic time series. Misreporting such data would not only misinform citizens but could also affect fisheries-policy decisions with ecological and legal consequences. This domain-specific characteristic motivates both the choice of case study and the architectural decisions adopted in this work.

Nevertheless, classical RAG architectures based on flat vector search are insufficient for IMARPE’s heterogeneous and scientifically dense knowledge corpus, which combines unstructured narrative documents (multi-year PDF yearbooks with complex tables) with structured relational data (IMARSIS) [10]. This dual nature calls for a bimodal, agentic approach.

This work presents the design, implementation, and evaluation of a hybrid agentic RAG system that integrates LightRAG [11], a graph-augmented retrieval framework backed by Neo4j, with a Text-to-SQL agent operating through the Model Context Protocol (MCP) [12], orchestrated by LangGraph [13]. The system acts as an automated first-level (Level-1) filter that answers routine inquiries immediately and redirects complex requests to the formal channel handled by staff, with the aim of reducing the administrative load that delays compliance with legal response deadlines.

The system was deployed on the institution’s Standard Transparency Portal (PTE) and evaluated through three key performance indicators (KPIs): end-to-end response latency (KPI-01), response quality assessed by an expert panel (KPI-02), and usability (KPI-03). The main contributions of this work are: (i) a bimodal agentic architecture that routes each citizen query to graph-based retrieval over scientific documents, to schema-aware Text-to-SQL over a live relational database, or to both; (ii) a credential-isolation design based on MCP that keeps database access within the institutional network; (iii) a referral protocol that redirects out-of-scope or sensitive requests to the formal access-to-information channel instead of generating unsupported answers; and (iv) a preliminary evaluation in a real public scientific institution that combines expert judgment, latency measurement, and a usability study.

The remainder of this article is organized as follows. Section 2 reviews related work on LLM limitations, RAG architectures, graph-augmented retrieval, and Text-to-SQL. Section 3 describes the materials and methods, including the operational baseline, data sources, comparative selection of architectures and models, system architecture, and evaluation framework. Section 4 reports the results for the three KPIs. Section 5 discusses the findings, ethical considerations, limitations, and future work, and Section 6 presents the conclusions.

2. Related Work

2.1. Limitations of LLMs in Institutional Settings

LLMs are trained under a self-supervised paradigm in which the next token of a sequence is predicted from massive pre-training corpora. This enables remarkable linguistic fluency but introduces three critical limitations for institutional deployment. First, hallucination: the model optimizes for fluent continuations without an internal mechanism to verify factual correctness, which can lead to plausible but incorrect content [3,14]. Second, the knowledge cutoff: the parametric knowledge of a model is frozen at its training date and does not include private institutional databases or recent scientific documents [15]. Third, the domain gap: general-purpose LLMs lack the specialized vocabulary and conceptual relations of scientific domains such as marine biology and fisheries management [16].

2.2. Retrieval-Augmented Generation: Foundations and Evolution

Lewis et al. [9] introduced RAG to mitigate hallucinations by combining an LLM’s generative capability with non-parametric knowledge retrieved at inference time. The classical paradigm (naïve RAG) consists of three phases: (1) offline ingestion, in which documents are segmented into chunks, encoded into dense vectors by an embedding model, and stored in a vector database; (2) online retrieval, in which the user query is encoded and the most similar chunks are retrieved, typically by cosine similarity; and (3) generation, in which the LLM produces a response conditioned on the retrieved context.

However, flat vector search has important limitations for complex institutional corpora. As documented by Gao et al. [10], naïve chunking can break semantic context, and the “lost in the middle” phenomenon causes models to underuse relevant information located in the middle of long contexts [17]. These shortcomings are especially acute for multi-hop queries that require correlating information across several documents and data sources.

2.3. Graph-Augmented RAG and LightRAG

To overcome these limitations, graph-augmented architectures exploit knowledge graphs (KGs). As defined by Hogan et al. [18], a knowledge graph represents domain knowledge as a network in which nodes denote entities of interest and edges represent typed relations between them. This structure preserves explicit connections between entities and supports multi-hop reasoning along paths of variable length, mitigating the contextual fragmentation of flat vector search. Pan et al. [19] argue that KGs and LLMs are complementary: KGs store explicit and interpretable factual knowledge, whereas LLMs contribute language understanding and generalization, so that their combination can improve both factual grounding and interpretability. Peng et al. [20] formalize graph-based RAG (GraphRAG) as a workflow composed of graph-based indexing, graph-guided retrieval, and graph-enhanced generation, a decomposition that maps directly onto the ingestion, retrieval, and synthesis stages of the system presented here.

Applying this paradigm to large corpora, Edge et al. [21] showed with GraphRAG that entity extraction combined with community-level summaries improves answers to global, corpus-wide questions. However, building these summaries requires a large number of LLM calls, which is costly for public institutions. Guo et al. [11] proposed LightRAG as a more efficient alternative that combines a vector index with an entity–relation graph. Its key feature is a dual-level retrieval paradigm: (1) low-level retrieval, which targets specific entities and their attributes; and (2) high-level retrieval, which targets broader relations and themes to answer abstract and correlational queries. This design offers much of the contextual richness of a knowledge graph at a lower indexing cost.

2.4. Heterogeneous and Alternative Graph-RAG Paradigms

Beyond GraphRAG and LightRAG, recent work has explored heterogeneous graph structures. Xu et al. [22] proposed NodeRAG, which structures the knowledge graph with typed, heterogeneous nodes to improve retrieval precision; however, its engineering complexity exceeds the resource constraints of most public-sector deployments. Self-reflective approaches such as Self-RAG [23] improve answer quality through on-demand retrieval and self-critique, but the additional inference steps increase latency, which is undesirable in citizen-facing chat applications. Recursive tree-based approaches such as RAPTOR [24] improve performance on corpus-wide questions but require building hierarchical summaries, which increases indexing cost for large multi-year collections. These trade-offs motivate the comparative selection process described in Section 3.5.

2.5. Text-to-SQL and Agentic Tool Use

For structured relational data, Text-to-SQL systems translate natural-language questions into executable SQL statements [25]. Rajkumar et al. [26] evaluated the Text-to-SQL capabilities of LLMs and showed that the way the database schema is represented in the prompt strongly affects the quality of the generated queries. Hong et al. [27] provide a comprehensive review of LLM-based Text-to-SQL, systematically analyzing recent advances in methods and benchmarks. Because institutional schemas are usually far larger than benchmark schemas, the amount of schema context supplied to the model must be managed carefully; Section 3.7.6 describes the schema-reduction strategy adopted here. The Model Context Protocol [12,28] standardizes how an LLM-based agent discovers and invokes external tools; because tools run on MCP servers controlled by the deploying organization, database credentials can remain within the institutional boundary. Agentic orchestration frameworks such as LangGraph [13,29] and AutoGen [30] enable a single user query to be routed conditionally across multiple tools or retrieval pathways, the pattern underlying the router adopted in this work. The ReAct paradigm [31] further shows that interleaving reasoning with tool-invocation actions helps an agent ground its outputs in external sources, which supports combining a graph-retrieval module with a deterministic SQL pathway rather than relying on either alone.

2.6. RAG Applications in Public-Sector and Scientific Domains

Earlier conversational assistants in government, such as the virtual assistant “Emma” of U.S. Citizenship and Immigration Services [32], illustrate the potential of citizen-facing automated assistance, while LLM-based deployments add the requirement of grounding answers in verifiable sources. In scientific domains, Sahu et al. [16] developed TAXObot, a RAG-based chatbot for the taxonomy of marine organisms, which illustrates the applicability of retrieval-grounded assistants to marine-science information. Regarding evaluation, Mortaheb et al. [33] examined the evaluation of multimodal RAG systems, and Salemi and Zamani [34] proposed a method to evaluate retrieval quality within RAG pipelines; both informed the rubric-based evaluation adopted in Section 3.9. Trustworthiness considerations for LLM-based systems, including privacy and safety, have been systematized by Sun et al. [35], which motivates the credential-isolation design of the MCP-based SQL agent (Section 3.7.5 and Section 3.7.7).

Previous work by the authors in Peruvian public institutions also informs the present design. Vega-Huerta et al. [36] deployed a ChatGPT-based assistant supported by an indexed institutional knowledge base in the admissions office of a public university; it reduced the average response time to under 2 min in most cases and reached 92% accuracy, but its specificity of 0.75 revealed difficulty in recognizing out-of-scope questions, a weakness that the explicit NONE route and referral protocol of the present system are designed to address. Vega-Huerta et al. [37] integrated citizens’ public information dispersed across seven Peruvian State websites into a single platform through web scraping developed under Scrum, reducing the average search time from 136 s to 24 s; the present work extends this single-access-point principle from web pages to scientific documents and a live relational database. In a citizen-security application, Vega-Huerta et al. [38] applied the KDD process to 47,835 structured crime records and obtained 91% accuracy (AUC = 0.96) with Gradient Boosting, illustrating that KDD suits pattern extraction over data that are already structured, a contrast that informs the methodological choice in Section 3.3. Finally, Vega-Huerta et al. [39] standardized heterogeneous indicator-reporting schemes in a business-intelligence data mart that automated calculations and integrated dispersed data sources; the same principle of exposing a curated, semantically documented data layer underlies the IMARSIS schema selection described in Section 3.7.6.

To the best of our knowledge, few studies describe the end-to-end deployment of a RAG assistant that combines graph-based retrieval over unstructured scientific documents with Text-to-SQL access to a live institutional database in a public-sector setting, together with an evaluation by domain experts and end users. The present work addresses this gap.

3. Materials and Methods

3.1. Operational Context and Baseline Analysis

Following the business-understanding phase of the CRISP-DM framework [40], historical public-information-access records were analyzed quantitatively to characterize operational demand and establish the baseline that motivates the proposed architecture.

A non-probabilistic convenience sample of n = 196 requests submitted between August and December 2025 was examined and classified by technical and legal complexity. As shown in Figure 1, 26.9% of the requests were classified as frequent, routine queries of low-to-medium complexity, which required only the extraction of existing data, such as figures from institutional yearbooks or taxonomic records from the IMARSIS database, without interpretive human analysis. The remaining 73.1% were complex requests (e.g., personnel settlements, legal resolutions, and technical case files). The five-month window was treated as representative under the assumption that the volume and composition of requests are approximately stable throughout the year; this assumption is discussed as a limitation in Section 5.4.

Despite their operational simplicity, routine requests enter the same sequential processing queue as complex case files, creating a bottleneck that delays the whole process. The mean response time in the sample was 12 business days, above the 10-day maximum established by Law No. 27806 [7]. Figure 2 shows the dispersion of response times across the sampled requests; a substantial share of the requests exceeded the legal threshold.

These baseline findings motivate the proposed hybrid RAG assistant: by resolving routine queries immediately at the point of entry, the system can deliver information to citizens within seconds (KPI-01) and has the potential to keep these requests out of the formal administrative queue, which would allow staff to concentrate on the 73.1% of complex case files. Whether this deflection translates into measurable improvements in legal compliance requires longitudinal monitoring after sustained deployment (Section 5.6).

3.2. Knowledge Sources and Dataset

The system’s knowledge base draws on two primary sources that differ in data structure and integration strategy (Table 1).

The documentary corpus includes all scientific-technological yearbooks for the 2010–2025 period, which ensures thematic relevance and temporal coverage. IMARSIS is queried in real time and no static copy is maintained, so the most recent data are always retrieved. The scientific nature of the corpus imposes an additional requirement that favours graph-augmented retrieval over flat vector search: frequent queries at research institutions are relational, for example, comparing the evolution of anchovy biomass across yearbooks or contrasting a narrative taxonomic record with its numerical counterpart in IMARSIS. This multi-hop, cross-document reasoning distinguishes the present use case from RAG applications in conventional administrative entities.

3.3. Methodological Framework

To select the engineering framework, three data-science methodologies were compared: KDD (Knowledge Discovery in Databases), SEMMA (Sample, Explore, Modify, Model, Assess), and CRISP-DM (Cross-Industry Standard Process for Data Mining), as summarized in Table 2.

CRISP-DM was selected as the guiding methodology. KDD remains appropriate when the data are already structured and the goal is pattern extraction, as in the authors’ citizen-security application [38]; the present problem, however, starts from an operational service gap and ends in a deployed system, two stages that CRISP-DM addresses explicitly. It remains widely adopted in data-science practice and has recently been extended to new settings, such as the assessment of agent-based simulation models [43]. Its explicit business-understanding phase framed the technical solution around a concrete operational problem (the 12-day mean response time), and its iterative coupling between data preparation and modelling was essential because the quality of the assistant depends directly on corpus preprocessing (yearbook cleaning and chunking strategy) rather than on coding alone. The six phases were executed as follows: (1) business understanding (baseline analysis, Section 3.1); (2) data understanding (characterization of the knowledge sources, Section 3.2); (3) data preparation (ETL pipeline, Section 3.4); (4) modelling (architecture and component selection, Section 3.5, Section 3.6 and Section 3.7); (5) evaluation (expert panel, latency, and usability, Section 3.9); and (6) deployment (rollout on institutional servers, Section 3.8).

3.4. Data Engineering Pipeline

Data preparation for the yearbook corpus followed a three-stage extract–transform–load (ETL) pipeline designed to maximize the semantic quality of the indexed content (Figure 3).

Stage 1 – Structural extraction. PDF files were converted to Markdown with a vision-language parsing service (LlamaParse). Rule-based text extractors (e.g., pypdf) read text line by line and perform poorly on borderless tables and embedded charts, whereas vision-language parsers analyze each page as an image to identify structural boundaries, table layouts, and heading hierarchies before generating text; recent optical-compression OCR models illustrate the same research direction [44]. Markdown was chosen because it preserves the document hierarchy (H1–H3 headings), which allows the chunking subsystem to respect the logical structure of scientific documents, and because its table syntax preserves row–column relationships that are lost in plain text.

Stage 2 – Semantic curation (LLM denoising). Gemini 2.5 Flash was used as a semantic filter to repair context disrupted by OCR artefacts, correct typographical errors, and normalize date and unit formats across the corpus. Raw text was processed with a sliding-window strategy in blocks of approximately 20,000 characters, split at paragraph boundaries to avoid breaking sentences. Contextual metadata tags (e.g., [YEAR: 2024]) were injected at the start of each block to preserve temporal context, and a dedicated system prompt instructed the model to reconstruct Markdown tables broken or malformed during extraction. An exponential-backoff retry mechanism handled transient API interruptions and rate limits.

Stage 3 – Knowledge-graph construction. The curated Markdown content was ingested by LightRAG, which performs LLM-based entity and relation extraction, entity profiling, and deduplication. The resulting graph was stored in Neo4j, supporting both low-level (entity-centred) and high-level (relation- and theme-centred) retrieval.

For IMARSIS, a simplified, semantically annotated DDL schema was built, with comments describing JOIN relationships and column semantics. This enriched schema is injected into the LLM’s context window at each Text-to-SQL call to reduce identifier errors in the generated SQL (the schema-selection procedure is described in Section 3.7.6).

3.5. Comparative Selection of RAG Architectures

Ten RAG paradigms described in the literature were compared against three institutional constraints: scientific accuracy, operational cost, and feasibility of deployment within a public entity (Table 3). This comparison is qualitative and based on the characteristics reported in the literature; it was not accompanied by an experimental benchmark of each paradigm on the IMARPE corpus.

The analysis indicated that LightRAG offered the best balance among the three constraints: it provides the contextual richness of a knowledge graph for multi-hop reasoning while keeping indexing costs viable for a state entity. Naïve RAG was discarded because of its limited ability to answer questions that require a global view of a document: IMARPE’s reports often require relating data on one page (e.g., biomass estimates) to conclusions many pages later, and purely vector-based retrieval tends to fragment these connections. Complex graph architectures (GraphRAG and NodeRAG) were ruled out because building their indexes requires a large number of LLM calls or substantial engineering effort, which is incompatible with the institution’s constrained budget. LightRAG builds a simpler entity–relation graph that is cheaper to index and update, and its dual-level retrieval covers both pointed queries (e.g., “What was the fishing quota in 2023?”, resolved through low-level, entity-centred retrieval) and abstract queries (e.g., “How has biomass evolved over the last decade?”, resolved through high-level, relation-centred retrieval).

3.6. Foundational Model Selection

Because IMARPE lacks on-premise GPU infrastructure, the architecture relies on a model-as-a-service (MaaS) API. Candidate models were compared using the LLM-Stats leaderboard (January 2026) [45] against three public-sector criteria: operational cost, context-window size, and reasoning performance, the latter measured by the GPQA benchmark [46] (Table 4).

The cost–benefit analysis identified two main barriers. First, the frontier models GPT-5.2 Pro and Claude Opus 4.5 achieve the highest reasoning scores among the candidates (GPQA ≥ 87.0%), but their output costs ($168.00 and $25.00 per million tokens, respectively) are difficult to sustain for a high-volume citizen-facing service. Gemini 3 Pro offers the same 1,048,576-token context window as Gemini 2.5 Flash, but at 6.7 times its input cost and 4.8 times its output cost. Second, the lowest-cost models, DeepSeek-V3.2 and MiMo-V2-Flash, have smaller context windows (131,072 and 256,000 tokens, respectively), which limit the volume of curation blocks, schema documentation, and retrieved evidence that can be processed in a single call.

Gemini 2.5 Flash was selected for three reasons: (a) its 1,048,576-token context window accommodates the curation blocks, the enriched DDL schema, and large sets of retrieved graph context within a single call, reducing the need to truncate evidence during synthesis; (b) its input cost of $0.30 per million tokens, which is 70 times lower than that of GPT-5.2 Pro and approximately 17 times lower than that of Claude Opus 4.5, supports long-term fiscal sustainability; and (c) its native support for function calling and structured outputs, which is required for MCP-based Text-to-SQL operation because the agent must translate natural language into SQL and invoke the IMARSIS tools exposed by the MCP server. Although positioned as a high-efficiency model, its reported GPQA score of 82.8% indicates reasoning capability adequate for the data-extraction, table-interpretation, and synthesis tasks required by the assistant.

3.7. Supporting Technology Stack

To implement the selected LightRAG architecture, four additional component categories were compared: embedding models, PDF parsing tools, graph-database engines, and re-ranking models.

3.7.1. Embedding Model

The embedding component maps the content of scientific documents into high-dimensional vectors. Leading models from the Massive Text Embedding Benchmark (MTEB) leaderboard [47] were compared, considering multilingual capability and deployment modality (Table 5).

gemini-embedding-001 was selected for three reasons: (a) competitive performance, ranking fourth among the models considered, with 3072-dimensional embeddings that provide fine semantic granularity for distinguishing related biological concepts; (b) hardware constraints, since the top-ranked open model (KaLM-Embedding-Gemma3, 12B parameters) requires dedicated GPU infrastructure for efficient local inference, whereas an API-based model avoids this capital expenditure; and (c) ecosystem integration, since using the same provider as the generator model (Gemini 2.5 Flash) simplifies credential and billing management.

3.7.2. Document Parsing Tool

IMARPE’s scientific yearbooks are structurally complex, with borderless tables, embedded charts, and multi-column text. Rule-based parsers (e.g., pypdf) do not extract this content reliably and introduce noise that can propagate into downstream answers. Four parsing tools were compared (Table 6).

LlamaParse was selected because, among the tools compared, it is the one that uses a generative vision-language model (VLM) to interpret each page before extraction, which allows complex tables to be reconstructed directly in Markdown while preserving the row–column relationships of biomass data, a critical requirement for factual accuracy.

3.7.3. Graph Database Engine

LightRAG requires two types of storage: a vector index for semantic retrieval and a graph structure for the relations between entities. Four graph-storage solutions were compared in terms of scalability, persistence, and licensing cost (Table 7).

Neo4j Community Edition was selected for three reasons: (a) persistence and scalability, since, unlike NetworkX, which operates in memory and must be rebuilt after each restart, Neo4j stores the graph on disk, which allows the yearbook knowledge graph to grow incrementally; (b) integration, since Neo4j is supported as a graph-storage backend by LightRAG and its Cypher query language facilitates the inspection and auditing of extracted entities and relations; and (c) zero licensing cost, since the Community Edition provides the core database engine free of charge, unlike managed alternatives such as Amazon Neptune.

3.7.4. Re-ranking Module

In a dense scientific corpus, vector search frequently retrieves passages that share keywords with the query but are irrelevant in context (false positives). A re-ranking stage was therefore implemented to score the relevance of retrieved passages before passing them to the LLM. Re-ranking models were compared for multilingual and technical retrieval (Table 8).

Jina Reranker v3 was selected for three reasons: (a) its 8192-token context window, which allows long passages typical of technical reports to be re-scored without the truncation that Cohere Rerank v3.5 (4096 tokens) or mxbai (512 tokens) would impose, whereas BGE-Reranker-v2-m3, which offers the same window, requires local GPU hardware; (b) its high rating for code and technical retrieval (Table 8), which is relevant because the corpus contains Markdown tables; and (c) its cost efficiency relative to Cohere, together with a free usage tier.

3.7.5. System Architecture

The final system implements a bimodal agentic architecture orchestrated with LangGraph (Figure 4) and implemented in Python 3.10. It comprises four asynchronous nodes and a referral protocol.

Router node. Gemini 2.5 Flash acts as a semantic classifier that receives the citizen’s query and selects one of four routes: conceptual, narrative, or relational queries activate the LightRAG module (RAG_ONLY); statistical, numerical, or species-specific queries activate the MCP Text-to-SQL agent (SQL_ONLY); queries requiring both narrative and quantitative grounding activate both pathways concurrently (BOTH); and out-of-scope or sensitive queries are sent directly to the referral protocol (NONE).

LightRAG module (unstructured knowledge). Answers queries against the Neo4j knowledge graph built from the yearbook corpus. Entity-specific queries use low-level retrieval of entities and their attributes, whereas abstract or correlational queries use high-level retrieval over relations and themes, enabling cross-document reasoning. Retrieved passages are re-ranked (Section 3.7.4) before synthesis.

MCP Text-to-SQL agent (structured knowledge). Handles queries that require quantitative data. The enriched DDL schema is injected into the context of Gemini 2.5 Flash, which generates a SQL statement that the MCP server executes against the live Oracle IMARSIS database over a client–server channel based on Server-Sent Events (SSE). Database credentials reside only in the MCP server within the institutional network and are never included in requests sent to the Gemini API.

Synthesizer node. Merges the outputs of the active pathways (narrative text and tabular data) into a single natural-language response. Prompt-engineering patterns [48] instruct the model to answer only from the retrieved evidence.

Intelligent referral protocol. When the router classifies a query as out of scope or sensitive, or when the retrieval modules return insufficient context, the system does not generate an answer. Instead, it displays a standardized institutional message (“To guarantee your right to access information, please submit your request through the following link”) together with a button linking to the SAIP (Public Information Access Service) form, so that the citizen always retains access to the formal request channel.

3.7.6. Relational Schema Selection (Pareto Analysis)

Because the full IMARSIS schema contains hundreds of tables, injecting all table definitions into the LLM’s context would be inefficient and error-prone. A selection criterion inspired by the Pareto principle was therefore applied, under the working assumption that a small subset of tables (approximately 10–15%) supports more than 90% of transactional and business queries. To identify this transactional core, three diagnostic scripts were run against the Oracle data dictionary to measure referential integrity (most-referenced master tables), storage volume (disk footprint), and transactional activity (row counts). Table 9, Table 10 and Table 11 summarize the results.

Cross-referencing these three metrics with qualitative business criteria isolated the core schema, composed of large fact tables (SP_VIAJE, SP_ACTIVIDAD, and SP_ESPECIE) and their dimension tables (QI_TAXON, QI_EMBARCACION, QI_LUGAR, QI_ARTE_PESCA, and QI_FABRICA). Audit tables, temporary tables (prefix TMP_), and non-essential materialized views were excluded to reduce token consumption and improve the agent’s precision. Beyond extracting the raw DDL statements, a Markdown context document was curated manually to serve as the agent’s reference on data structure: physical storage clauses (PCTFREE, TABLESPACE, and STORAGE) that add noise were removed, natural-language comments were added for ambiguous columns (e.g., clarifying that TAXON_ID identifies the biological species), and implicit JOIN relationships not declared as formal constraints were documented in text.

3.7.7. SQL Execution Safety and Database Access Control

Because the Text-to-SQL agent executes model-generated statements against a live institutional database, isolating credentials does not by itself make execution safe. The deployed version applies four safeguards. First, credential isolation: the Oracle credentials reside only in the MCP server inside the institutional network, are injected as runtime environment variables (Section 3.8), and are never transmitted to the Gemini API. Second, schema scoping: the model receives only the curated core schema (Section 3.7.6), from which audit tables, temporary tables, and non-essential materialized views are excluded. Third, controlled failure: graph failures and database timeouts are captured by the API’s exception handling, which returns a controlled response instead of a server error (Section 3.8). Fourth, scope restriction: queries classified as out of scope or sensitive are sent to the referral protocol (NONE route) and do not reach the SQL agent.

Schema scoping restricts what the model is shown but does not, on its own, prevent a generated statement from referencing other database objects; that guarantee depends on database-level privileges. Production deployments of LLM-generated SQL should therefore also restrict the MCP database account to read-only access on the approved tables, accept only single SELECT statements after syntactic validation, enforce execution timeouts and row limits, and log every generated statement for audit, in line with the security risks identified for MCP-based tool execution [28]. A formal assessment of these controls, including adversarial prompt-injection testing, was not part of the present evaluation (Section 5.4).

3.8. Deployment Architecture

All agentic logic was encapsulated in a RESTful API built with Flask, exposing a /query endpoint that accepts JSON requests, handles concurrency through async/await, and returns the processed response. Exception handling ensures that, in the event of a graph failure or database timeout, the API returns a controlled response instead of a server error (HTTP 500).

The backend (Flask API and LangGraph) and the persistence service (Neo4j) were containerized as independent services with Docker Compose, which provides an identical execution environment across development and operational testing and avoids Python dependency conflicts. Deployment was carried out on a Windows Server 2022 instance in the institution’s on-premise infrastructure. Because LLM inference is delegated to the Gemini API, the local server requires only moderate resources (4 vCPUs and 16 GB of RAM). API credentials (Gemini API keys and Oracle database credentials) are injected as runtime environment variables rather than embedded in the source code, in accordance with institutional cybersecurity standards.

For citizen interaction, a React-based chat component was developed. It was embedded not on the institution’s home page but in the Public Information Access section of the Standard Transparency Portal (PTE), so that the assistant acts as a Level-1 filter that can resolve a query in real time before a manual case file is created. The interface renders Markdown, so that statistical tables returned by the SQL agent are displayed legibly; shows loading indicators during asynchronous processing; and keeps the conversation history in the browser’s local storage to prevent context loss when the page is reloaded.

3.9. Evaluation Framework

A mixed-methods evaluation protocol was designed to measure the technical quality of the responses generated by the hybrid architecture and the operational performance and usability of the deployed assistant. The evaluation was structured around three KPIs.

KPI-01 – Response latency (efficiency). End-to-end processing time from query submission to response rendering. A latency below 120 s per query was set as the operational acceptance threshold. Because this measure refers to software processing time, it is not directly comparable with the 12-business-day administrative baseline, which includes human handling, document routing, and approvals (Section 5.1).

KPI-02 – Response quality (technical quality). Five domain specialists from IMARPE, who were aware that the responses had been generated by the system, separately evaluated 30 predefined test interactions (Golden Set) using a three-dimensional rubric inspired by the quality aspects targeted by RAGAS [49]: factual accuracy (are the data exact and free of fabricated content?), completeness (does the response fully answer the query?), and clarity and usefulness (is the language accessible to a non-technical citizen?). Each dimension was scored on a 1–5 Likert scale.

KPI-03 – Usability. Measured with the System Usability Scale (SUS) [50], a standardized 10-item questionnaire administered to 30 users (institutional staff, scientists, and pilot citizens) immediately after a free 5-min interaction session with the deployed widget. Internal consistency was assessed with Cronbach’s alpha [51,52]. Scores were interpreted with the acceptability ranges of Bangor et al. [53], in which scores above 70 are considered acceptable, and with the curved grading scale of Sauro and Lewis [54].

3.9.1. Golden Set Design

To support an objective technical evaluation, a reference Golden Set of questions and expected answers was constructed. Source queries were drawn from the institution’s Public Information Access Request (SAIP) registry for the August–December 2025 period. A purposive, non-probabilistic sample of 30 questions was selected, discarding trivial administrative queries and prioritizing four scenario types: (1) frequent institutional queries, (2) retrieval of exact statistical data, (3) synthesis of technical reports, and (4) exception handling and referral.

The Golden Set was not intended to represent exhaustively the knowledge contained in 15 years of yearbooks, but to cover the main intents of citizen queries. Its size (n = 30) was defined on coverage grounds rather than for probabilistic inference: in usability research, a modest number of test cases or evaluators reveals a large share of the existing problems [55]. For reference, the baseline period contained 53 routine requests; because the Golden Set was not drawn randomly from them, it is not intended to estimate population-level performance. Following a purposive sampling strategy [56], the Golden Set was distributed across the thematic domains observed in real demand, namely biomass, landings, taxonomic occurrences, and financial information, so that retrieval effectiveness is assessed on the scenarios the system faces in production. The Golden Set was organized by scenario type rather than by execution route, and ambiguous or adversarial queries were not included as a separate category; route-level results are therefore descriptive (Section 5.4).

3.9.2. Expert Panel Procedure

The panel consisted of five domain specialists from the institution. Its size was determined by the availability of senior specialists and by the criterion of technical saturation; for the assessment of factual accuracy in a specialized domain, a small panel of highly qualified experts allows an exhaustive review of every Golden Set response. The 30 Golden Set questions were executed against the assistant’s backend, and the results were compiled into a structured form containing each question and the AI-generated answer. Each expert scored the responses independently.

The instrument had two sections. In Section A (interaction-level evaluation), the experts scored each of the 30 responses on a 5-point Likert scale (1 = very poor/entirely incorrect; 5 = excellent/entirely correct) for each of the three rubric dimensions. Section B (global qualitative evaluation) consisted of three items answered after scoring all responses: the degree to which institutional expectations were met, opportunities for interface improvement, and the level of confidence (1–10) in deploying the assistant as the first point of citizen contact.

3.9.3. User Acceptance Testing

A separate user acceptance test validated the assistant in its real environment. Thirty users (administrative staff, scientists, and pilot citizens) were given access to the deployed web widget and asked to perform free queries related to their information needs during a 5-min session. After the session, participants completed the SUS questionnaire, which alternates positively and negatively worded statements to reduce acquiescence bias.

Internal consistency was quantified with Cronbach’s alpha [51], as defined in Equation (1):

α = (k / (k − 1)) × [1 − (Σσ²ᵢ / σ²ₜ)]

(1)

where k is the number of items (10), Σσ²ᵢ is the sum of the item variances, and σ²ₜ is the variance of the total score.

4. Results

4.1. Response Quality (KPI-02): Expert Panel Evaluation

The 30 Golden Set interactions were evaluated on three dimensions by the five specialists, yielding 90 item-level scores (30 test cases × 3 dimensions, each averaged across the five experts). Figure 5 shows the mean score per dimension, and Table 12 summarizes the results.

The system achieved a mean factual-accuracy score of 4.45/5, indicating that the combination of the MCP SQL agent and the LightRAG knowledge graph retrieved exact numerical data in most test cases. Completeness reached 4.10/5, and clarity and usefulness obtained the highest score (4.57/5), indicating that technical content was conveyed in language accessible to non-technical citizens. Overall, 81 of the 90 item-level scores (90.0%) were at or above 4.0.

The remaining 9 item-level scores (10.0%) were concentrated in questions 7, 15, 20, 23, and 24 and reflect three failure modes. First, referral by design (questions 7, 20, and 23) produced the lowest completeness scores (2.2–2.8): the fallback is activated when the requested information lies outside the indexed corpus or is sensitive (e.g., budgets or acoustic-survey biomass), and although this behaviour protects legal compliance, the experts rated these responses as incomplete from the standpoint of immediate information needs. Second, a predictive-modelling limitation (question 15) produced the lowest accuracy score of the study (2.6/5) for an anchovy-catch projection: the system generated a static linear projection for the next five years, which is inappropriate for a highly variable resource. This shows that, although the SQL pathway retrieves historical data accurately, the LLM cannot replace a dedicated statistical model for forecasting. Third, truncation of a large result set (question 24) reduced completeness (3.4/5) for a multi-port disaggregated breakdown that approached the token limit: the SQL agent returned the aggregate total but omitted the detailed breakdown.

Overall, in the evaluated cases the architecture tended to omit information or redirect the citizen rather than fabricate data; the one clearly inadequate answer (question 15) arose from extrapolation beyond the retrieved data rather than from retrieval. In the global evaluation (Section B), all five experts reported that the system met or exceeded their expectations for citizen service, and the mean confidence score for deploying it as the first official point of contact was 8.6/10.

4.2. Usability (KPI-03): System Usability Scale

The SUS questionnaire was administered to 30 users after the free interaction session. Cronbach’s alpha was 0.96, indicating high internal consistency of the responses [52].

The global SUS score was 80.42/100. This value is above the acceptability threshold of 70 proposed by Bangor et al. [53] and corresponds to grade A− (78.9–80.7; 85th–89th percentile) on the curved grading scale of Sauro and Lewis [54]. The low scores on the negatively worded items (1.67–1.87; Figure 6) indicate that participants did not perceive the system as unnecessarily complex, inconsistent, or difficult to learn. These results suggest that the architectural complexity of graph retrieval and MCP-based SQL execution is not exposed to the end user.

4.3. Response Latency (KPI-01)

End-to-end processing times measured across the 30 Golden Set test cases yielded a mean latency of 20.43 s per query, ranging from 3.20 s (an out-of-scope query filtered through the NONE route) to 49.20 s (question 30, a 15-year cross-variable report that required both pathways through the BOTH route).

Mean latency differed by the execution route assigned by the LangGraph router:

• NONE (out-of-scope or sensitive queries): mean of 3.58 s.
• SQL_ONLY (relational queries to IMARSIS): mean of 16.17 s, covering SQL generation, execution through MCP, and response formatting.
• RAG_ONLY (unstructured queries to the Neo4j knowledge graph): mean of 23.06 s, covering dual-level graph retrieval and context synthesis.
• BOTH (hybrid narrative and quantitative synthesis): mean of 39.75 s, reflecting the concurrent execution of both retrieval pathways before final synthesis.

In all 30 test cases, processing latency remained below the 120 s acceptance threshold defined for KPI-01. Table 13 contrasts the characteristics of the traditional manual process with those of the hybrid RAG system.

4.4. Validation of the Intelligent Referral Mechanism

During the expert evaluation, 10.0% of the Golden Set cases (3 of 30; questions 7, 20, and 23) activated the referral protocol. In all three cases, the system correctly identified that the requested information lay outside the indexed corpus or constituted a sensitive request, and the redirection message and the SAIP form button were rendered correctly. The referral mechanism therefore preserved the citizen’s access to the formal request channel in every case in which an autonomous answer was not provided.

5. Discussion

5.1. Interpretation of the Results

The results support the feasibility of the hybrid RAG system in the evaluated setting across the three KPIs; in the absence of a comparative baseline, however, they do not establish its superiority over simpler architectures. The factual-accuracy score of 4.45/5 suggests that the grounding strategy can limit the hallucination problem, a principal barrier to LLM adoption in public-sector contexts [3,6]. The dual-grounding strategy, in which narrative answers are grounded in the LightRAG knowledge graph and numerical answers in the result sets of SQL queries executed against the live IMARSIS database, reduces the opportunity for fabricated statistics, because figures are taken from retrieved records rather than from the model’s parametric knowledge. This is consistent with the view that knowledge graphs and structured sources complement LLMs by supplying explicit, verifiable facts [19,20]. However, the synthesis step remains generative, and question 15 shows that errors can still arise when the model extrapolates beyond the retrieved data.

Recent public-administration studies have moved from analysing the adoption of government chatbots to examining their results and their impact on public service provision [2,4,5]. The present evaluation contributes evidence of this kind for a public scientific institution by combining expert-rated answer quality, measured latency, and usability in a real deployment.

The SUS score of 80.42/100 with α = 0.96 indicates that the system’s technical sophistication did not translate into perceived complexity for the participants. Because the usability sample included institutional staff and scientists in addition to pilot citizens, this result should be interpreted as preliminary evidence of acceptability rather than as a measure of the experience of the general public (Section 5.4).

Regarding latency, the comparison between 12 business days and a mean of 20.43 s does not equate two identical processes: the administrative workflow includes signatures, document routing, and human handoffs, whereas the measured latency refers only to software processing. The relevant effect is demand deflection: by answering routine queries, which accounted for 26.9% of the baseline sample, at the entry point of the transparency portal, the system has the potential to prevent these requests from entering the formal administrative queue and free staff time for complex case files. The magnitude of this effect on legal compliance must be confirmed through longitudinal monitoring.

5.2. Architectural Advantages over Naïve RAG

The literature-based comparison (Section 3.5) suggests that naïve RAG, although inexpensive, is structurally insufficient for IMARPE’s corpus. The “lost in the middle” phenomenon [17] is particularly detrimental for queries that require synthesis across multi-year yearbooks spanning hundreds of pages. LightRAG’s dual-level retrieval addresses this by modelling the relations between entities explicitly in a graph. The Text-to-SQL component adds a capability that graph-based RAG alone does not provide: real-time access to relational transactional data, which allows quantitative queries to be answered from the database itself. Because no experimental comparison with a naïve RAG baseline or with an ablated system was performed, the relative contribution of each component remains to be quantified (Section 5.4 and Section 5.6).

5.3. Ethical and Legal Considerations: The Referral Architecture

The intelligent referral protocol is a central ethical design decision. In public-sector AI systems, the absence of an answer is preferable to an incorrect one. By constraining the system to redirect requests that it cannot answer from its sources, rather than generating unsupported content, the design follows the principle of responsible AI by design and responds to the governance concerns raised for generative AI [6]. The MCP-based design additionally ensures that IMARSIS Oracle credentials are never included in requests sent to the Gemini API, addressing the data-governance requirements of a state institution [35]. Credential isolation, however, does not by itself guarantee the safe execution of model-generated SQL; the complementary safeguards and their current scope are described in Section 3.7.7.

5.4. Limitations

This study has several limitations. First, the evaluation did not include an experimental baseline (e.g., an LLM without retrieval or a naïve vector-based RAG) or an ablation of the system’s components on the same Golden Set; the advantages of the selected architecture are therefore supported by the literature-based comparison and by the absolute scores obtained, not by a controlled comparison. Second, the five experts belong to IMARPE and were aware that the responses were generated by the system, and neither dispersion measures (e.g., standard deviations) nor inter-rater agreement statistics (e.g., Krippendorff’s α or the intraclass correlation coefficient) were reported; an evaluation by external experts blinded to the response source, with agreement statistics, would strengthen the validity of KPI-02. Third, the Golden Set (n = 30) was selected purposively and organized by scenario type rather than by execution route, so the number of cases per route (SQL_ONLY, RAG_ONLY, BOTH, and NONE) was not controlled, and ambiguous, adversarial, and out-of-domain queries were not tested as separate categories; the results should therefore be regarded as preliminary and specific to the evaluated corpus. In addition, the baseline analysis relies on a five-month convenience sample whose representativeness assumes stable demand throughout the year. Fourth, the usability sample combined institutional staff, scientists, and pilot citizens in short (5-min) sessions, which may not reflect the experience of the general public over sustained use. Fifth, the corpus is restricted to the 2010–2025 yearbooks and IMARSIS; queries about other institutional documents trigger the referral protocol and are not resolved autonomously. Sixth, the system cannot produce reliable stochastic or bio-economic projections (question 15) without a dedicated computation module. Seventh, the SQL-execution safeguards described in Section 3.7.7 were not subjected to a formal security assessment, such as adversarial prompt-injection testing. Finally, all results derive from a single deployment in one institution; generalization to other public entities would require corpus-specific ingestion and schema mapping, although the architectural pattern is, in principle, transferable.

5.5. Practical Implications for Public-Sector Digital Transformation

This work describes a reference implementation that may inform AI-assisted citizen service in resource-constrained public entities, subject to the validation steps outlined in Section 5.6. The local infrastructure requirements are modest (4 vCPUs and 16 GB of RAM), and the main variable cost is Gemini API token consumption ($0.30 per million input tokens and $2.50 per million output tokens). Containerized deployment with Docker Compose supports environment portability and reproducibility. Open-source components (LangGraph, LightRAG, and Neo4j Community Edition) minimize licensing costs, and MCP provides a provider-agnostic standard for integrating relational databases.

5.6. Future Work

Future work should prioritize: (a) an experimental comparison of the hybrid system against an LLM without retrieval, a naïve vector RAG, and single-pathway variants on an extended Golden Set (e.g., 50–100 queries balanced across the SQL_ONLY, RAG_ONLY, BOTH, and NONE routes and including ambiguous, adversarial, and out-of-domain queries), with external experts blinded to the response source and inter-rater agreement statistics reported together with the mean ± SD of each rubric dimension; (b) a statistical-analysis agent with computational libraries (e.g., pandas and SciPy) to support bio-economic projections, addressing the gap identified in question 15; (c) automatic pagination within the MCP client for high-volume disaggregated SQL queries (question 24); (d) a continuous LLMOps pipeline integrated with automated RAGAS evaluation [49] to monitor faithfulness and context precision after new yearbook ingestions or database updates; (e) longitudinal measurement of the system’s effect on institutional response times and legal compliance after sustained production use; and (f) a security assessment of the Text-to-SQL pathway, including a review of database-level privileges and adversarial prompt-injection testing.

6. Conclusions

This study indicates that a bimodal agentic RAG architecture that integrates a LightRAG knowledge graph with an MCP-based Text-to-SQL agent, orchestrated by LangGraph, is a feasible and cost-conscious option for automating first-level citizen information services in the public scientific institution evaluated. Because the evaluation was conducted at a single site, on a purposively selected Golden Set, and without an experimental baseline, the following conclusions are preliminary.

Regarding efficiency (KPI-01), the system responded to all test queries with a mean latency of 20.43 s (maximum 49.20 s), well below the 120 s acceptance threshold. This value measures software processing time and is not directly comparable with the 12-business-day mean of the formal administrative workflow, which exceeded the 10-day limit set by Law No. 27806. By answering routine queries, which accounted for 26.9% of the baseline requests, at the point of entry, the system has the potential to reduce administrative workload by deflecting these requests from the formal access-to-information workflow.

Regarding response quality (KPI-02), the hybrid architecture obtained a mean factual-accuracy score of 4.45/5 from a panel of five IMARPE domain experts on 30 test cases. Grounding numerical answers in SQL results and narrative answers in the knowledge graph is intended to reduce the risk of fabricated content, although extrapolation beyond the retrieved data remains a residual risk.

Regarding usability (KPI-03), the SUS score of 80.42/100 (Cronbach’s α = 0.96; n = 30) is above the acceptability threshold and corresponds to grade A− on the Sauro–Lewis curved scale, indicating that users without technical training could interact with the system easily.

The intelligent referral protocol complements these results: by redirecting requests that it cannot answer reliably to the formal SAIP channel, the system preserves the citizen’s right to access information. Subject to further validation, the architecture may serve as a reference design for public transparency offices in Peru and comparable contexts. In scientific institutions, where answers involve verifiable quantitative claims with consequences for public policy and natural-resource management, the combination of knowledge graphs for narrative content and deterministic SQL retrieval for quantitative data appears to be a promising design pattern that goes beyond routine administrative automation.

In summary, the evidence obtained in this study demonstrates, in the evaluated setting, a mean software latency of 20.43 s, a mean factual-accuracy score of 4.45/5 from domain experts, and a SUS score of 80.42, and it identifies routine, data-extractable queries (26.9% of the baseline sample) as the automation target. It does not yet demonstrate a reduction in the 12-business-day administrative response time, a reduction in staff workload, an improvement in compliance with Law No. 27806, or superiority over simpler retrieval architectures; these effects require the comparative and longitudinal studies outlined in Section 5.6.