Red Hat Details AutoRAG Optimization in OpenShift AI 3.5

Red Hat Details AutoRAG Optimization in OpenShift AI 3.5

AI-generated editorial illustration; not a documentary photograph.

Red Hat has published a technical guide describing AutoRAG in Red Hat OpenShift AI 3.5, where engineers can automate comparisons of retrieval-augmented generation pipeline configurations. The approach is intended to help teams assess answer quality alongside latency and compute cost instead of widening context windows by default.

Why larger context can fail

The guide argues that production RAG systems face document-layout problems, fragmented information and frequently changing knowledge that simple demonstrations do not represent. Increasing chunk sizes or retrieving more candidates can add irrelevant material, raise time-to-first-token and consume more GPU memory. Red Hat also points to positional bias and the difficulty of combining facts scattered across a long prompt as reasons that more context does not guarantee better answers.

Three separate pipelines

Red Hat recommends separating indexing, retrieval and maintenance. Indexing handles parsing, metadata, chunking, embeddings and vector-store updates, with Docling used to convert complex layouts into structured Markdown. The retrieval path performs hybrid search, reranking, access-control checks and generation, using components including vLLM and llm-d. A maintenance pipeline manages updates, deletions, right-to-be-forgotten requests, re-embedding and corpus-drift detection.

What AutoRAG evaluates

Within gen AI studio, AutoRAG can test combinations of parsing methods, chunk sizes, embedding models, hybrid-search settings, reranking and generation models. Engineers provide representative documents and an evaluation dataset, then set candidate models and latency or cost constraints. Results are presented through Pareto-frontier analysis, comparing accuracy with operational trade-offs.

Metrics and limitations

The guide distinguishes context correctness, answer faithfulness and answer correctness. A response can be faithful to retrieved passages while still being wrong if retrieval supplied the wrong passages, so faithfulness alone is insufficient. Red Hat notes that faithfulness and correctness often rely on an LLM judge, making model selection and judge drift important concerns. For cases where retrieval is accurate but reasoning remains weak, the guide describes RAFT-based customization using SDG Hub, Training Hub and EvalHub.

Source: AutoRAG pipeline optimization in Red Hat OpenShift AI

Share this article
FacebookThreadsLinkedInX

Leave a Reply

Your email address will not be published. Required fields are marked *