AutoRAG 3.5 turns a winning experiment into deployable OpenShift AI artifacts

Red Hat’s AutoRAG technical preview in OpenShift AI 3.5 now does more than rank retrieval-augmented generation configurations. It can export the selected pattern as deployable artifacts for ingestion and query serving, adds multilingual model selection, and supports PostgreSQL with pgvector as an alternative to Milvus.

The capabilities are available as a Technical Preview, not a generally supported production feature, according to Red Hat’s September 14 post.

From leaderboard result to deployment artifacts

AutoRAG runs evaluation and hyperparameter tuning across RAG configurations using Kubeflow Pipelines and IBM’s open-source ai4rag optimization engine. The 3.5 preview adds an inline chat interface so developers can interact with the output of a selected experiment before building a separate application around it.

More consequentially, selecting a winning pattern generates artifacts for both halves of the system. Red Hat says the ingestion side becomes a deployable Kubeflow Pipeline containing the chosen parsing, chunking, embedding and vector-index settings. The query side is packaged as a configuration for the Responses API through Open GenAI Framework, formerly Llama Stack.

The dashboard also produces a pattern.json, a configured Python client and example calls in Python, cURL, Go and Node.js. That does not eliminate production engineering, but it does reduce the configuration-copying step between an optimization run and a service that a team can test.

Multilingual selection and database choice

AutoRAG 3.5 adds native multilingual document handling, initially for German, Spanish and Japanese. A model-preselector stage detects document language and benchmarks embedding models and LLMs against test data before running the full optimization matrix. Red Hat says the intent is to discard weak candidates early and avoid spending compute on combinations that do not fit the source language.

The preview also adds pgvector support alongside Milvus. Teams already operating PostgreSQL can point optimization experiments at that infrastructure rather than introduce a separate vector database. Elasticsearch and Qdrant are described only as future plans.

What platform teams should verify

The new export path addresses a real handoff problem: an experimental RAG configuration is not useful if engineers must reconstruct it manually for ingestion and serving. Teams evaluating the preview should still verify that the generated pipeline is reproducible when documents change, that the exported query configuration matches their authentication and observability requirements, and that language detection improves rather than narrows their model choices.

They should also keep the support boundary clear. OpenShift AI 3.5 is generally available, but AutoRAG 3.5 remains a Technical Preview. The right near-term use is controlled evaluation of the generated artifacts and their fit with an existing vector-data platform, not an assumption that the preview has crossed the production-support gate.