Hybrid RAG for Technical Training Knowledge Assistant in Mining Operations

rio_tinto · Energy · 2025 · source Agentic: no · promotional bias: med · source-backed · extracted with prompt 0.5.6 (schema v2)

Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.

Problem

Domain: industrial technical training and enterprise knowledge access for mining operations

Rio Tinto Aluminium needed technical experts in refining and smelting to access specialized institutional knowledge quickly and accurately during internal training, while conventional vector-only RAG struggled to preserve relationships, context, and consistent retrieval quality for complex industrial questions.

Constraints:

• the company operates in 35 countries and employs almost 52,000 people
• technical training needs domain-specific mining, refining, and smelting knowledge
• LLMs alone hallucinate and lack enterprise domain knowledge
• vector-only RAG loses nuance when chunks average semantic meaning
• context windows force related information to be split apart
• vector databases require re-embedding and reindexing as data changes
• responses need source citations, access-control separation, deterministic retrieval, and production performance

Architecture

Rio Tinto built a hybrid RAG assistant on AWS that combines a knowledge graph, vector indices, retrieval/ranking logic, and generative models. The ingestion layer uses Lambda functions to process raw documents, extract context from text/tables/visuals with Bedrock multimodal capabilities, perform semantic chunking, run entity and relationship extraction, build the knowledge graph, and create vector embeddings for graph elements. The generation layer runs on Amazon ECS and performs vector similarity search, graph-based context retrieval, relevance scoring across entities and relationships, prompt augmentation with prioritized context, and final text generation. Amazon Bedrock Knowledge Bases provides an additional managed RAG path, Titan embeddings supply multilingual RAG-oriented embeddings, OpenSearch and FAISS support vector search, and caching stores frequently accessed system data plus common Q&A pairs.

Diagram confidence: explicit (topology described by the source).

flowchart LR
  Raw_technical_documents["Raw technical documents"] --> Document_processing_Lambda["Document processing Lambda"]
  Bedrock_multimodal_model["Bedrock multimodal model"] --> Document_processing_Lambda
  Document_processing_Lambda --> Semantic_chunking_stage["Semantic chunking stage"]
  Semantic_chunking_stage --> Entity_relationship_extractor["Entity relationship extractor"]
  Entity_relationship_extractor --> Knowledge_graph["Knowledge graph"]
  Entity_relationship_extractor --> Vector_database["Vector database"]
  Technical_training_user["Technical training user"] --> Hybrid_retrieval_service["Hybrid retrieval service"]
  Hybrid_retrieval_service --> Vector_database
  Hybrid_retrieval_service --> Knowledge_graph
  Vector_database --> Relevance_ranking_module["Relevance ranking module"]
  Knowledge_graph --> Relevance_ranking_module
  Relevance_ranking_module --> Augmented_prompt_builder["Augmented prompt builder"]
  Bedrock_Knowledge_Base["Bedrock Knowledge Base"] --> Hybrid_retrieval_service
  Smart_caching_layer["Smart caching layer"] --> Hybrid_retrieval_service
  Augmented_prompt_builder --> Generative_model["Generative model"]
  Generative_model --> Source_citation_layer["Source citation layer"]
  Source_citation_layer --> Technical_training_user
  Hybrid_retrieval_service --> LLM_as_judge_evaluator["LLM-as-judge evaluator"]

Components

Data flow

Documents are converted and parsed into structured text, semantically chunked, analyzed for entities and relationships, written into a graph, embedded into vector indices, and stored as a dual knowledge foundation. When a user asks a technical question, the system reformulates the query for domain context, searches vectors, maps matched entities into the graph, traverses first-degree relationships, computes relevance scores for target entities and relationships, retrieves summaries and source contexts, combines prioritized database context with the refined query and chat history, and generates an answer with source citations.

Why this architecture

Rio Tinto chose hybrid RAG because vector search alone can find semantic similarity but cannot represent explicit domain relationships, while a knowledge graph alone lacks the semantic flexibility of embeddings. The dual retrieval structure lets the assistant retrieve both similar text and related entities, then rank context by relevance to a user's technical question. This matters in industrial training where answers need deep domain knowledge, citations, access-control separation, consistency, and richer context than a few vector chunks provide.

Models used: Amazon Bedrock generative models · Amazon Bedrock multimodal models · Amazon Titan text embedding model · entity recognition and relationship extraction model · large language model as judge · generative model for text generation

Scale

• Rio Tinto operates in 35 countries.
  “Today we operate in 35 countries where we produce iron ore, copper, aluminium, critical minerals and other material”transcript, stated
• Rio Tinto directly employs almost 52,000 people.
  “We directly employed almost 52,000 people and we are jewel list in London and Australian stock exchanges.”transcript, stated
• Vector-only RAG used 2-3 sources while hybrid RAG used 11-17 technical documents per query in the demo.
  “The vector rack typically draws from two to three sources while the hybrid rack leverage 11 to 17 technical documents per query”transcript, stated
• The LLM-as-judge evaluation used 100 industry-specific questions.
  “we use a technical called the large length model as a judge across 100 industry specific questions and the results are compelling.”transcript, stated
• The hybrid system reduced standard deviation by over 53% for metrics such as context precision and context entity recall.
  “We observed over 53% reduction in standard deviation for Kimage like the uh context precision and the context entity recalls”transcript, stated

Alternatives considered (roads not taken)

LLM out of the box without enterprise retrieval

Rejected because: The presentation frames standalone LLMs as hallucination-prone, sensitive to prompting, and lacking domain knowledge.

Traditional vector-only RAG

Rejected because: Vector search can dilute semantic precision, lose context, become costly at scale, and cannot represent relationships.

Single shared knowledge base for all domains

Rejected because: The presenters recommend separate knowledge bases by domain to fit outputs and simplify guardrails for intellectual property concerns.

No caching layer

Rejected because: The system adds multi-level caching to reduce response time and improve user experience.

Patterns

rag-retrieval (retrieval)

The assistant combines vector retrieval, graph traversal, Bedrock Knowledge Bases, prompt augmentation, and citations to answer domain questions.

retrieval-ranking (retrieval)

The system computes relevance scores for entities and first-degree relationships, then prioritizes retrieved context for the user question.

query-rewriting (retrieval)

Before retrieval, the system analyzes and reformulates the user question within conversational and domain context.

semantic-caching (operations)

A multi-level cache stores frequently accessed system data and common user question-answer pairs to reduce response time.

llm-as-judge (evaluation)

Hybrid and vector-only RAG were compared at scale with a model-based judge over 100 industry-specific questions.

safety-policy-enforcement (governance)

The recommended deployment pattern separates knowledge bases by domain to support output fit, access control, search precision, and IP guardrails.

Tradeoffs

Hybrid vector plus graph retrieval

Chose vector similarity and knowledge graph traversal over vector-only RAG.

Rationale: Hybrid retrieval improves context richness and relationship awareness at the cost of maintaining two retrieval structures.

Semantic chunking before extraction

Chose coherent logical chunks over simpler chunking that can split related content.

Rationale: Preserving meaningful content improves context understanding and retrieval accuracy.

Deterministic retrieval within fixed search radius

Chose fixed-radius deterministic text generation behavior over fully adaptive retrieval that may vary identical-query results.

Rationale: Consistency is valuable for production technical knowledge systems, even though fixed radius can constrain adaptation.

Domain-separated knowledge bases

Chose separate storage/domain boundaries over one broad enterprise knowledge base.

Rationale: Separate domains improve output fit, access control, search precision, and IP guardrail application.

Managed AWS stack for hybrid RAG

Chose Bedrock Knowledge Bases, Titan embeddings, OpenSearch, FAISS, ECS, and Lambda over fully custom retrieval and orchestration code.

Rationale: The managed services provide out-of-box RAG workflow, vector/graph infrastructure, automatic scaling, and model support, while still requiring custom hybrid retrieval logic.

Gotchas (what bit them)

Vector-only RAG loses relationship context.

Root cause: Embeddings represent similarity but not explicit domain relationships or broader context around an entity.

Resolution: Add a knowledge graph so the retrieval system can traverse entities and relationships in addition to vector similarity.

Chunking and context windows can split related information.

Root cause: Confined model context windows force information into chunks, which can separate related facts.

Resolution: Use semantic chunking to preserve meaningful coherent units before entity extraction and graph/vector storage.

Graph/vector dual retrieval is operationally more complex than ordinary RAG.

Root cause: The system must maintain document processing, entity extraction, graph storage, vector embeddings, ranking, prompt construction, and generation layers.

Resolution: Split the architecture into serverless ingestion and ECS generation layers, with managed Bedrock Knowledge Bases for additional RAG support.

Retrieval quality depends on upstream entity and relationship extraction.

Root cause: The graph and relationship-ranking steps can only be as good as the extracted entities, relationships, summaries, and contexts.

Resolution: Use specialized extraction over semantic chunks and score both entities and relationships against the query.

Caching improves latency but adds freshness and invalidation concerns.

Root cause: The cache stores common system data and Q&A pairs while underlying technical documents can evolve.

Resolution: Use caching as a performance layer but retain domain-separated storage and retrieval architecture as source of truth.

Evaluation

Rio Tinto compared vector-only and hybrid RAG using typical alumina refinery questions and an LLM-as-judge evaluation across 100 industry-specific questions. The comparison looked at response detail, technical depth, context quality, context entity recall, context precision, score distribution, and standard-deviation stability.

Metrics: 2-3 sources for vector RAG versus 11-17 technical documents for hybrid RAG · 100 industry-specific questions · context quality · context entity recall · context precision · over 53% standard-deviation reduction · high mean scores across all measurements

Outcomes

• The hybrid RAG system provided more detailed responses than vector-only RAG on refinery process questions.
• Hybrid RAG leveraged 11-17 technical documents per query compared with 2-3 sources for vector RAG.
• LLM-as-judge evaluation across 100 industry-specific questions showed hybrid RAG outperforming vector-only RAG across metrics.
• The hybrid system reduced standard deviation by over 53% for metrics including context precision and context entity recall.
• The system improved technical depth for process control, quality standards, equipment specifications, and troubleshooting protocols.

The case provides strong comparative metrics but comes from an AWS/Rio Tinto presentation with ASR noise in the transcript and limited details on human evaluation. The reusable production insight is the graph-plus-vector retrieval architecture and its ranked prompt construction.