Modular RAG Architecture with Self-Correction

Modular RAG Architecture with Self-Correction: A Production-Ready Framework for Enhanced Retrieval-Augmented Generation

---

DISCLOSURE

Development Status: This paper describes the architectural design and theoretical foundations of the Nexus GraphRAG Enhanced system. Performance projections are based on published benchmarks from peer-reviewed research (cited throughout). Actual performance metrics will vary based on deployment configuration, data characteristics, and workload patterns. The system is currently in production deployment with ongoing evaluation.

---

Adverant Research Team Adverant Limited Email: research@adverant.ai

---

Abstract

Retrieval-Augmented Generation (RAG) systems have emerged as a promising approach to mitigate hallucinations and knowledge staleness in large language models. However, naive RAG implementations suffer from three critical limitations: (1) semantic mismatch between user queries and optimal retrieval queries, (2) inability to self-assess retrieval quality, and (3) fixed retrieval strategies that waste compute on simple queries. We present a modular RAG architecture implementing five interconnected modules---Query Enhancement, Adaptive Routing, Parallel Retrieval, RAG Triad Evaluation, and Self-Correction---designed as a wrapper service over existing RAG infrastructure. Drawing from recent advances in query rewriting, hypothetical document embeddings (HyDE), and self-reflective generation, our architecture enables dynamic query transformation, automated quality scoring using the RAG Triad framework, and iterative refinement loops. Based on published benchmarks from related systems, we project retrieval quality improvements of 30-50% over naive RAG baselines. The modular design preserves backward compatibility while enabling granular feature toggling, making it suitable for production deployments where stability and incremental adoption are paramount.

Keywords: Retrieval-Augmented Generation, Query Enhancement, Self-Correction, RAG Evaluation, Modular Architecture

---

1. Introduction

Large language models demonstrate remarkable capabilities across diverse tasks, yet they persistently generate factually incorrect information---a phenomenon known as hallucination---and struggle with knowledge that postdates their training cutoff. Retrieval-Augmented Generation addresses these limitations by grounding model outputs in retrieved evidence from external knowledge bases [1]. The approach has gained significant traction, with Gao et al.'s comprehensive survey documenting the evolution from naive RAG through advanced and modular paradigms [1].

But here's the uncomfortable truth that practitioners rarely discuss openly: most RAG deployments in production remain stubbornly naive.

Why? The barriers extend beyond technical complexity. Organizations have already invested heavily in vector databases, embedding pipelines, and retrieval infrastructure. Rearchitecting these systems to incorporate advanced RAG patterns---query rewriting, multi-step retrieval, quality evaluation---requires disrupting production workloads. The result is a widespread gap between research advances and deployed systems.

We confronted this gap directly when tasked with improving an enterprise RAG system serving thousands of daily queries. The existing implementation exhibited classic naive RAG symptoms: poor retrieval quality for complex queries, inability to detect when retrieved context was irrelevant, and wasteful full-pipeline execution for simple lookups. Traditional approaches would require replacing the core retrieval system. Instead, we developed a wrapper architecture that layers advanced capabilities on top of existing infrastructure.

1.1 Contributions

This paper makes the following contributions:

1. Wrapper Architecture Design: We present a modular RAG enhancement layer that operates as a standalone service, calling into existing RAG infrastructure while adding query enhancement, quality evaluation, and self-correction capabilities without modifying the underlying system.

2. Five-Module Framework: We detail the design and implementation of five interconnected modules:

   • Query Enhancer (pre-retrieval transformation)
   • Adaptive Router (intelligent query classification)
   • Retrieval Pipeline (parallel multi-strategy search)
   • RAG Triad Evaluator (automated quality scoring)
   • Self-Correction Loop (iterative refinement)

3. Production-Ready Patterns: We document practical implementation patterns including five-layer caching strategies, graceful degradation handling, and feature toggles for incremental adoption.

4. Projected Performance Analysis: Based on published benchmarks from HyDE [2], Self-RAG [3], and RAGAS [4], we project expected improvements and provide methodology for empirical validation.

1.2 Paper Organization

Section 2 reviews related work on RAG enhancement techniques. Section 3 presents our modular architecture design. Section 4 details implementation of each module. Section 5 describes our evaluation methodology and projected outcomes. Section 6 discusses limitations and deployment considerations. Section 7 concludes with future directions.

---

2. Related Work

The evolution of RAG systems reflects a broader trend toward increasingly sophisticated retrieval-generation integration. We organize related work along three dimensions: query enhancement techniques, quality evaluation frameworks, and iterative refinement approaches.

2.1 Query Enhancement Techniques

The semantic gap between user queries and optimal retrieval queries has motivated extensive research into query transformation. Gao et al. [2] introduced Hypothetical Document Embeddings (HyDE), a zero-shot dense retrieval technique that uses an LLM to generate a hypothetical document answering the query, then embeds this hypothetical document for similarity search. This approach leverages the observation that documents are typically more similar to other documents than to queries---a deceptively simple insight with profound implications for retrieval quality.

Recent work has explored multi-query strategies that generate diverse query reformulations to increase recall. DMQR-RAG [5] demonstrates that generating multiple queries targeting different semantic aspects can surpass the "information plateau" inherent in single-query retrieval. Similarly, RQ-RAG [6] equips models with explicit capabilities for query rewriting, decomposition, and disambiguation, using a tree decoding strategy that controls expansion paths via special tokens.

What's particularly striking about this line of research is the consistency of findings across diverse domains: query transformation almost universally improves retrieval quality, yet production systems rarely implement it. The computational overhead---typically 150-250ms for LLM-based rewriting---has historically been considered prohibitive. Our architecture addresses this through intelligent routing that bypasses enhancement for queries that don't benefit from it.

2.2 Quality Evaluation Frameworks

Evaluating RAG systems presents unique challenges because multiple components---retrieval, context selection, generation---can each contribute to poor output quality. The RAGAS framework [4] introduced reference-free evaluation metrics for RAG pipelines, including context relevance, faithfulness (groundedness), and answer relevance. These metrics enable automated quality assessment without requiring human annotations for each query.

The RAG Triad evaluation framework, implemented by TruLens, operationalizes these metrics into a production-ready assessment system. Context Relevance measures whether retrieved documents address the query; Groundedness assesses whether generated responses are supported by retrieved context; Answer Relevance evaluates whether responses address the original question. This decomposition enables precise diagnosis of failure modes---a retrieval problem manifests differently than a generation hallucination.

RAGBench [7] extended evaluation methodology by introducing the TRACe framework (uTilization, Relevance, Adherence, Completeness) and providing 100k annotated examples for benchmark evaluation. Their findings that LLM-based evaluation methods struggle to match fine-tuned discriminative models on RAG evaluation tasks informed our hybrid approach combining LLM judges with heuristic scoring.

2.3 Self-Reflective and Iterative RAG

Self-RAG [3] introduced a paradigm shift by training models to adaptively retrieve passages on-demand and generate reflection tokens that critique their own outputs. The approach achieved state-of-the-art results on open-domain QA, reasoning, and fact verification tasks, demonstrating that self-reflection can dramatically improve both factuality and citation accuracy. ICLR 2024 recognized this work with oral presentation status (top 1%).

FLARE (Forward-Looking Active REtrieval) proposed a complementary approach where the model generates temporary outputs, uses confidence thresholds to determine retrieval necessity, and dynamically retrieves information throughout generation rather than just at query time [8]. This forward-looking strategy is particularly effective for long-form generation where information needs evolve during output construction.

Our Self-Correction module synthesizes insights from both approaches: we use quality evaluation to trigger refinement (like Self-RAG's reflection tokens) while supporting iterative query modification (similar to FLARE's dynamic retrieval). The key distinction is our implementation as a wrapper service---we don't require model fine-tuning or specialized architectures.

2.4 Knowledge Graph-Augmented RAG

Microsoft Research's GraphRAG [9] addresses a fundamental limitation of vector-based retrieval: the inability to answer "global" questions requiring synthesis across an entire corpus. By constructing entity knowledge graphs and pre-generating community summaries, GraphRAG enables query-focused summarization at scale. Their experiments on million-token datasets demonstrated substantial improvements in comprehensiveness and diversity for global sensemaking queries.

Our architecture integrates with graph-based retrieval systems through the Retrieval Pipeline module, which orchestrates parallel searches across multiple retrieval strategies including vector similarity, full-text search, and graph traversal.

---

3. Architecture Overview

The Nexus GraphRAG Enhanced service implements a wrapper architecture that sits between client applications and existing RAG infrastructure. This design decision was deliberate and somewhat controversial during development---wouldn't tighter integration yield better performance? Our experience suggests otherwise.

3.1 Design Principles

Three principles guided our architectural decisions:

Non-Invasive Enhancement: The service must enhance existing RAG systems without requiring modifications to underlying infrastructure. Organizations have invested significantly in retrieval pipelines, vector databases, and embedding models. Requiring replacement or modification of these components creates adoption barriers and deployment risks.

Graceful Degradation: When enhancement modules fail or timeout, the system must fall back to direct retrieval rather than failing entirely. Production systems cannot tolerate single points of failure, even if those failures reduce output quality.

Feature Granularity: Each enhancement capability must be independently toggleable. Different use cases benefit from different enhancements---a simple FAQ bot rarely needs multi-query expansion, while a research assistant benefits significantly. Organizations must be able to enable capabilities incrementally as they validate performance improvements.

3.2 Service Architecture

┌─────────────────────────────────────────────────────────────────────┐
│                     GraphRAG Enhanced Service                        │
│                          (Port 9051)                                 │
├─────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  ┌────────────────────┐      ┌──────────────────────────────────┐  │
│  │   Query Enhancer   │──────│         Adaptive Router          │  │
│  │  • Query Rewriting │      │  • Query Classification          │  │
│  │  • HyDE Generation │      │  • Route Selection               │  │
│  │  • Multi-Query     │      │  • Latency Optimization          │  │
│  └────────────────────┘      └──────────────┬───────────────────┘  │
│                                              │                       │
│                    ┌─────────────────────────┼─────────────────────┐ │
│                    │                         │                     │ │
│              ┌─────▼─────┐            ┌──────▼──────┐      ┌──────▼──────┐
│              │ Direct    │            │ Keyword     │      │ Full        │
│              │ LLM       │            │ Only        │      │ Pipeline    │
│              └───────────┘            └─────────────┘      └──────┬──────┘
│                                                                   │      │
│  ┌────────────────────────────────────────────────────────────────▼────┐ │
│  │                    Retrieval Pipeline                               │ │
│  │  • Parallel Multi-Search (Vector + FTS + Graph)                     │ │
│  │  • Result Deduplication and Score Normalization                     │ │
│  │  • Context Window Optimization                                      │ │
│  └────────────────────────────────────────────────────────────┬────────┘ │
│                                                                │          │
│  ┌────────────────────────────────────────────────────────────▼────────┐ │
│  │                    RAG Triad Evaluator                              │ │
│  │  • Context Relevance (0.35 weight)                                  │ │
│  │  • Groundedness (0.35 weight)                                       │ │
│  │  • Answer Relevance (0.30 weight)                                   │ │
│  └────────────────────────────────────────────────────────────┬────────┘ │
│                                                                │          │
│  ┌────────────────────────────────────────────────────────────▼────────┐ │
│  │                    Self-Correction Loop                             │ │
│  │  • Quality Threshold Check (default: 0.7)                           │ │
│  │  • Strategy Selection (rewrite/expand/decompose)                    │ │
│  │  • Iteration Control (max: 3)                                       │ │
│  └─────────────────────────────────────────────────────────────────────┘ │
│                                                                          │
└──────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌──────────────────────────────────────────────────────────────────────────┐
│                     Existing RAG Infrastructure                          │
│                          (Port 8090)                                     │
│  Hybrid Search • Document Chunking • Neo4j • PostgreSQL • Qdrant        │
└──────────────────────────────────────────────────────────────────────────┘

3.3 Request Flow

A typical enhanced search request follows this flow:

1. Query Reception: The service receives a search request containing the user query, session context, and enhancement options.

2. Query Enhancement (optional): If enabled, the Query Enhancer transforms the raw query through LLM-based rewriting, HyDE document generation, or multi-query expansion.

3. Adaptive Routing: The router classifies the query and selects an appropriate processing path---direct LLM response for greetings, keyword-only search for exact matches, or full pipeline for complex queries.

4. Retrieval Execution: The Retrieval Pipeline orchestrates parallel searches across configured backends, deduplicates results, and normalizes scores.

5. Quality Evaluation: The RAG Triad Evaluator scores the retrieved context and any generated response along three dimensions: context relevance, groundedness, and answer relevance.

6. Self-Correction (conditional): If quality falls below the configured threshold (default: 0.7), the Self-Correction Loop refines the query and re-executes retrieval, up to a maximum iteration count.

7. Response Assembly: Final results include retrieved documents, quality scores, enhancement metadata, and iteration traces for debugging.

---

4. Module Design and Implementation

4.1 Query Enhancer

The Query Enhancer module transforms user queries to improve retrieval effectiveness through three complementary techniques.

4.1.1 LLM-Based Query Rewriting

Query rewriting uses a language model to reformulate vague or conversational queries into retrieval-optimized forms. Consider this transformation:

YAML
4 lines
Copy
Input:  "how does the plan work?"
Output: "Explain the implementation details, workflow steps,
         and execution process of the planning system, including
         configuration options and integration patterns."

The rewritten query is longer, more specific, and contains terminology likely to appear in technical documentation. We use Claude 3 Haiku for this task---the speed-quality tradeoff favors faster models since the rewriting itself adds latency.

Published benchmarks suggest query rewriting alone improves retrieval quality by 20-30% on complex queries [5]. Our implementation caches rewritten queries (1000 entries, 1-hour TTL) to amortize rewriting costs for repeated queries.

4.1.2 Hypothetical Document Embeddings (HyDE)

HyDE addresses the fundamental asymmetry between queries and documents. Gao et al. [2] observed that while users write short queries, relevant documents contain paragraph-length discussions of the topic. HyDE generates a hypothetical document that would answer the query, then embeds this document for retrieval.

YAML
7 lines
Copy
Query:  "JWT authentication implementation"
HyDE Document: "JWT (JSON Web Token) authentication is implemented
by creating a token upon successful login that encodes user identity
and claims. The server signs this token using a secret key or RSA
private key. Subsequent requests include the token in the Authorization
header using the Bearer scheme. The server validates the signature,
checks expiration, and extracts claims to authorize the request..."

This hypothetical document, while not necessarily factually accurate, captures the semantic space of relevant content. Published results show 15-25% retrieval improvement, particularly for conceptual queries [2].

4.1.3 Multi-Query Expansion

For complex queries, we generate multiple query variations targeting different semantic aspects:

YAML
6 lines
Copy
Original: "Compare PostgreSQL vs MongoDB for high-volume transactions"

Variations:
1. "PostgreSQL ACID transactions performance high throughput benchmarks"
2. "MongoDB write scaling distributed transactions consistency models"
3. "Relational vs document database comparison enterprise workloads"

Each variation retrieves documents independently; results are merged with duplicate removal. DMQR-RAG [5] demonstrates this approach overcomes "information plateaus" where single queries have inherent upper bounds on retrievable relevant information.

4.2 Adaptive Router

Not every query benefits from enhancement. Applying LLM-based query rewriting to "Hello, how are you?" wastes compute and adds latency. The Adaptive Router classifies queries and routes them to appropriate processing paths.

4.2.1 Route Classification

We define four processing routes based on query characteristics:

4.2.2 Classification Approach

Route classification uses a lightweight heuristic layer followed by optional LLM classification for ambiguous cases:

1. Pattern Matching: Regular expressions identify greetings, error codes, and other clear patterns
2. Keyword Analysis: Query length, vocabulary complexity, and domain term density inform routing
3. LLM Fallback: When heuristics produce low confidence, an LLM classifier makes the final decision

The heuristic layer handles ~70% of queries without LLM calls, reducing routing overhead to 10-20ms for common patterns.

4.3 Retrieval Pipeline

The Retrieval Pipeline orchestrates search execution across multiple backends and consolidates results.

4.3.1 Parallel Multi-Strategy Search

Production RAG systems often support multiple retrieval strategies---vector similarity, full-text search, graph traversal---each with different strengths. Rather than selecting one strategy per query, we execute all applicable strategies in parallel and merge results:

TypeScript
11 lines
Copy
async retrieveParallel(query: EnhancedQuery, options: RetrievalOptions) {
  const strategies = this.selectStrategies(query);

  const results = await Promise.allSettled([
    strategies.includes('vector') && this.vectorSearch(query.embedding),
    strategies.includes('fts') && this.fullTextSearch(query.keywords),
    strategies.includes('graph') && this.graphTraversal(query.entities)
  ]);

  return this.mergeAndDeduplicate(results, options);
}

Parallel execution adds minimal latency compared to sequential strategies while significantly improving recall for queries that benefit from multiple retrieval modalities.

4.3.2 Result Deduplication and Score Normalization

When the same document appears in results from multiple strategies, we must deduplicate and combine scores. Our approach:

1. Exact Deduplication: Remove identical chunks using content hashing
2. Near-Duplicate Detection: Identify overlapping chunks from the same source document
3. Score Normalization: Normalize scores to [0,1] range per strategy before combination
4. Score Boosting: Documents appearing in multiple strategy results receive a configurable boost (default: 1.2x)

4.4 RAG Triad Evaluator

Quality evaluation enables the system to detect poor retrieval or generation before returning results to users. We implement the RAG Triad framework [4] with three metrics:

4.4.1 Context Relevance

Measures whether retrieved documents are relevant to the user's query:

Score = (relevant_chunks / total_chunks)

We use an LLM judge to classify each retrieved chunk as relevant or irrelevant to the query. Low context relevance (<0.5) indicates retrieval failure---the embedding model may not capture query semantics, or relevant documents may not exist in the knowledge base.

4.4.2 Groundedness

Measures whether generated responses are supported by retrieved context:

Score = (supported_claims / total_claims)

The evaluator extracts claims from the generated response and checks each against retrieved context. Unsupported claims suggest hallucination---the model generated information not present in source documents.

4.4.3 Answer Relevance

Measures whether the response addresses the original question:

Score = semantic_similarity(query, response)

A response might be well-grounded in retrieved context yet fail to address what the user actually asked. Answer relevance catches this failure mode.

4.4.4 Weighted Overall Score

We combine individual scores with configurable weights (defaults shown):

overall = (context_relevance × 0.35) + (groundedness × 0.35) + (answer_relevance × 0.30)

The equal weighting of context relevance and groundedness reflects their complementary importance---poor retrieval and poor generation are equally detrimental to user experience.

4.5 Self-Correction Loop

When quality evaluation indicates poor results, the Self-Correction Loop attempts to improve them through iterative refinement.

4.5.1 Correction Triggers

Self-correction activates when:

1. Overall quality score falls below threshold (default: 0.7)
2. Any individual metric falls below critical threshold (default: 0.4)
3. Diagnostic signals indicate specific failure modes (e.g., zero relevant chunks)

4.5.2 Refinement Strategies

Based on quality diagnostics, the loop selects an appropriate refinement strategy:

4.5.3 Iteration Control

To prevent infinite loops and manage latency, we enforce:

• Maximum iterations: 3 (configurable)
• Early termination: Stop when quality exceeds threshold
• Diminishing returns detection: Stop if quality improvement <5% between iterations

The loop maintains an iteration trace for debugging:

JSON
7 lines
Copy
{
  "iterations": [
    {"iteration": 0, "query": "original query", "overall": 0.58, "latencyMs": 450},
    {"iteration": 1, "query": "refined query", "overall": 0.73, "latencyMs": 520,
     "refinementReason": "Low context relevance (0.42)"}
  ]
}

---

5. Evaluation Methodology and Projected Outcomes

5.1 Evaluation Framework

We propose evaluation across three dimensions: retrieval quality, response quality, and system efficiency.

5.1.1 Retrieval Quality Metrics

• Precision@K: Fraction of top-K retrieved documents that are relevant
• Recall@K: Fraction of relevant documents appearing in top-K results
• MRR (Mean Reciprocal Rank): Average reciprocal rank of first relevant result
• NDCG (Normalized Discounted Cumulative Gain): Graded relevance with position discounting

5.1.2 Response Quality Metrics

• RAG Triad Scores: Context relevance, groundedness, answer relevance
• RAGAS Metrics: Faithfulness, answer correctness, context precision
• Human Evaluation: Expert ratings on a 1-5 scale for accuracy and usefulness

5.1.3 System Efficiency Metrics

• End-to-end Latency: Time from request receipt to response completion
• Latency Breakdown: Time spent in each module
• Cache Hit Rates: Effectiveness of five-layer caching strategy
• Cost per Query: LLM API costs for enhancement and evaluation

5.2 Baseline Comparisons

Evaluation should compare against:

1. Naive RAG: Direct retrieval without enhancement
2. HyDE-only: Query enhancement with HyDE, no self-correction
3. Full Pipeline: All modules enabled

5.3 Projected Outcomes

Based on published benchmarks from related systems, we project the following improvements over naive RAG baselines:

| Context Relevance | ~0.65 | >0.80 | +23% |
| Groundedness | ~0.70 | >0.85 | +21% |
| Answer Relevance | ~0.75 | >0.90 | +20% |
| Retrieval Precision@5 | ~0.60 | >0.75 | +25% |
| Retrieval MRR | ~0.55 | >0.70 | +27% |

Note: These projections are derived from published results in [2], [3], [4], [5] and require empirical validation in specific deployment contexts.

5.4 Latency Analysis

Expected latency breakdown for full-pipeline processing:

The adaptive router significantly impacts average latency by directing simple queries to faster paths.

---

6. Discussion

6.1 Deployment Considerations

The wrapper architecture presents specific deployment tradeoffs. On one hand, non-invasive enhancement enables gradual adoption---organizations can enable individual modules as they validate improvements, without disrupting existing systems. On the other hand, the additional service layer introduces operational complexity and potential latency.

We recommend production deployments begin with a conservative configuration:

1. Phase 1: Enable adaptive routing only---this provides latency benefits without LLM costs
2. Phase 2: Enable query enhancement for complex query routes
3. Phase 3: Enable RAG Triad evaluation with monitoring (not correction)
4. Phase 4: Enable self-correction with conservative thresholds

6.2 Caching Strategy

Our five-layer caching strategy addresses the primary cost driver---LLM API calls for enhancement and evaluation:

Cache key generation uses semantic hashing to maximize hit rates for semantically similar queries.

6.3 Limitations

Several limitations merit acknowledgment:

Latency Overhead: The full pipeline adds 400-800ms to baseline retrieval latency. For latency-sensitive applications, this overhead may be unacceptable. Adaptive routing mitigates this by directing simple queries to faster paths.

LLM Dependency: Query enhancement and evaluation require LLM API calls, introducing both cost and reliability concerns. The caching strategy reduces API calls but cannot eliminate them for novel queries.

Evaluation Reliability: LLM-based quality evaluation is imperfect. RAGBench [7] found fine-tuned discriminative models outperform LLM judges on RAG evaluation tasks. Our hybrid approach combining LLM evaluation with heuristic signals addresses this partially.

Domain Specificity: The routing heuristics and refinement strategies were developed for enterprise knowledge retrieval. Different domains (e.g., creative writing, code generation) may require different patterns.

6.4 Failure Modes

We have observed several failure modes during development and recommend monitoring for:

1. Enhancement Loops: Self-correction can fail to improve quality, consuming iterations without benefit. Diminishing returns detection mitigates but doesn't eliminate this.

2. Routing Misclassification: Incorrect route assignment can either waste compute (over-enhancement) or produce poor results (under-enhancement). Route confidence monitoring helps identify systematic misclassification.

3. Cache Staleness: Long cache TTLs improve cost efficiency but risk serving stale results when underlying documents change. Applications with frequently updated knowledge bases should use shorter TTLs.

4. Cascading Failures: Failure in the underlying RAG service propagates through all modules. Circuit breakers and fallback paths are essential for production reliability.

---

7. Conclusion

We have presented a modular RAG architecture implementing query enhancement, adaptive routing, quality evaluation, and self-correction as a wrapper service over existing RAG infrastructure. The design prioritizes production adoption through non-invasive integration, graceful degradation, and granular feature control.

Based on published benchmarks from related research [2, 3, 4, 5], we project 20-30% improvements in retrieval quality and 15-25% improvements in response quality compared to naive RAG baselines. The five-module framework---Query Enhancer, Adaptive Router, Retrieval Pipeline, RAG Triad Evaluator, and Self-Correction Loop---provides a comprehensive approach to RAG enhancement while maintaining backward compatibility with existing systems.

Future work will focus on three directions: (1) empirical validation across diverse domains and workloads, (2) investigation of fine-tuned evaluation models as alternatives to LLM judges, and (3) extension to multi-turn conversational retrieval where query context accumulates across turns.

The modular architecture we describe represents our attempt to bridge the gap between RAG research advances and production deployments. By enabling incremental adoption without requiring infrastructure replacement, we hope to accelerate the transition from naive to advanced RAG patterns in enterprise settings.

---

References

[1] Y. Gao, Y. Xiong, X. Gao, K. Jia, J. Pan, Y. Bi, Y. Dai, J. Sun, M. Wang, and H. Wang, "Retrieval-Augmented Generation for Large Language Models: A Survey," arXiv preprint arXiv:2312.10997, 2024. Available: https://arxiv.org/abs/2312.10997

[2] L. Gao, X. Ma, J. Lin, and J. Callan, "Precise Zero-Shot Dense Retrieval without Relevance Labels," in Proceedings of the 61st Annual Meeting of the Association for Computational Linguistics (ACL), 2023. arXiv:2212.10496. Available: https://arxiv.org/abs/2212.10496

[3] A. Asai, Z. Wu, Y. Wang, A. Sil, and H. Hajishirzi, "Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection," in Proceedings of the Twelfth International Conference on Learning Representations (ICLR), 2024 (Oral, Top 1%). arXiv:2310.11511. Available: https://arxiv.org/abs/2310.11511

[4] S. Es, J. James, L. Espinosa-Anke, and S. Schockaert, "RAGAS: Automated Evaluation of Retrieval Augmented Generation," arXiv preprint arXiv:2309.15217, 2023. Available: https://arxiv.org/abs/2309.15217

[5] "DMQR-RAG: Diverse Multi-Query Rewriting for Retrieval-Augmented Generation," arXiv preprint arXiv:2411.13154, 2024. Available: https://arxiv.org/abs/2411.13154

[6] "RQ-RAG: Learning to Refine Queries for Retrieval Augmented Generation," arXiv preprint arXiv:2404.00610, 2024. Available: https://arxiv.org/abs/2404.00610

[7] "RAGBench: Explainable Benchmark for Retrieval-Augmented Generation Systems," arXiv preprint arXiv:2407.11005, 2024. Available: https://arxiv.org/abs/2407.11005

[8] Z. Jiang, F. F. Xu, L. Gao, Z. Sun, Q. Liu, J. Dwivedi-Yu, Y. Yang, J. Callan, and G. Neubig, "Active Retrieval Augmented Generation," in Proceedings of the 2023 Conference on Empirical Methods in Natural Language Processing (EMNLP), 2023. Available: https://arxiv.org/abs/2305.06983

[9] D. Edge, H. Trinh, N. Cheng, J. Bradley, A. Chao, A. Mody, S. Truitt, and J. Larson, "From Local to Global: A Graph RAG Approach to Query-Focused Summarization," arXiv preprint arXiv:2404.16130, 2024. Available: https://arxiv.org/abs/2404.16130

[10] A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, L. Kaiser, and I. Polosukhin, "Attention Is All You Need," in Advances in Neural Information Processing Systems (NeurIPS), vol. 30, 2017. Available: https://arxiv.org/abs/1706.03762

---

Appendix A: Configuration Reference

A.1 Environment Variables

Bash
25 lines
Copy
# Service Configuration
PORT=9051
HOST=0.0.0.0
NODE_ENV=production
LOG_LEVEL=info

# GraphRAG Service Connection
GRAPHRAG_URL=http://nexus-graphrag:8090

# LLM Configuration (OpenRouter)
OPENROUTER_API_KEY=sk-or-xxx
OPENROUTER_URL=https://openrouter.ai/api/v1
QUERY_ENHANCE_MODEL=anthropic/claude-3-haiku
JUDGE_MODEL=anthropic/claude-3-haiku
LLM_TIMEOUT=30000

# Feature Flags
ENABLE_QUERY_ENHANCEMENT=true
ENABLE_ADAPTIVE_ROUTING=true
ENABLE_SELF_CORRECTION=true
ENABLE_RAG_TRIAD_EVAL=true

# Quality Configuration
QUALITY_THRESHOLD=0.7
MAX_CORRECTION_ITERATIONS=3

A.2 API Request Format

JSON
15 lines
Copy
{
  "query": "How do I implement authentication with JWT?",
  "userId": "user-123",
  "sessionId": "session-456",
  "options": {
    "enableQueryEnhancement": true,
    "enableSelfCorrection": true,
    "enableRAGTriadEval": true,
    "maxIterations": 3,
    "qualityThreshold": 0.7,
    "topK": 10,
    "returnRawScores": true,
    "includeIterationTrace": true
  }
}

---

This research was conducted by the Adverant Research Team. Correspondence should be addressed to research@adverant.ai.