Chapter 2. Overview of OGX
OGX is a unified AI runtime environment designed to simplify the deployment and management of generative AI workloads on OpenShift AI. In OpenShift, the OGX Operator manages the deployment lifecycle of these components, ensuring scalability, consistency, and integration with OpenShift AI projects. OGX integrates model inference, embedding generation, vector storage, and retrieval services into a single stack that is optimized for retrieval-augmented generation (RAG) and agent-based AI workflows.
OGX concepts
- OGX Operator Installs and manages OGX server instances in OpenShift AI, handling lifecycle operations such as deployment, scaling, and updates.
-
The
run.yamlfile Defines which APIs are enabled and how backend providers are configured for a OGX server. Red Hat ships a defaultrun.yamlthat supports common deployment scenarios. You can provide a customrun.yamlto enable advanced workflows or integrate additional providers. -
OGXServercustom resource Declares the runtime configuration for a OGX server, including model providers, embedding configuration, vector storage, and persistence settings.
OpenShift AI ships with a OGX Distribution that runs the OGX server in a containerized environment. For the OGX Operator version included in this release of OpenShift AI, see Supported Configurations for 3.x.
OGX integration is currently available in Red Hat OpenShift AI 3.5 as a Technology Preview feature. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production.
These features provide early access to upcoming product capabilities, enabling customers to test functionality and provide feedback during development.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
OGX includes the following core components:
-
Integration with OpenShift AI Uses the
OGXServercustom resource to simplify configuration and deployment of AI workloads. - Inference model connections Acts as a proxy between OGX APIs and model inference servers, such as vLLM deployments.
- Embedding generation Generates vector embeddings used for retrieval. In OpenShift AI 3.2, remote embedding models are the recommended and default option for production deployments. Inline embedding models remain available for development and testing scenarios.
- Vector storage Stores and indexes embeddings by using supported vector databases, such as Milvus or PostgreSQL with the pgvector extension.
- Metadata persistence Stores vector store metadata, file references, and configuration state. In OpenShift AI 3.2, PostgreSQL is the default backend for production-grade deployments.
- Retrieval workflows Manages ingestion, chunking, embedding, and similarity search to support RAG workflows.
- Agentic workflows Enables agent-based interactions through supported APIs, such as OpenAI-compatible Responses and Chat Completions.
For information about deploying OGX in OpenShift AI, see Deploying a RAG stack in a project.
The OGX Operator is not currently supported on IBM Z platform.
OGX is supported on IBM Power (ppc64le) with limited functionality:
- The GenAI playground is supported and available on the IBM Power architecture.
-
milvus-liteis supported and available as a vector store option on the IBM Power architecture. -
Although
PostgreSQLwith thepgvectorextension is listed as a supported vector store, it is not currently available on the IBM Power ppc64le architecture.
2.1. OGX APIs Copy linkLink copied to clipboard!
You can use the following APIs from OGX for AI actions.
2.1.1. Supported OGX APIs in OpenShift AI Copy linkLink copied to clipboard!
2.1.1.1. File Processors API Copy linkLink copied to clipboard!
-
Endpoint:
/v1alpha/file-processors. - Providers: All file processor backends deployed through OpenShift AI.
- Support level: Developer Preview
The File Processors API converts various document types into vector-ready chunks using configurable extraction backends, including Docling, PyPDF, and others. You can upload a document in your file storage and the API returns structured chunks.
2.1.1.2. Datasets_IO API Copy linkLink copied to clipboard!
-
Endpoint:
/v1alpha/datasetio. - Providers: All dataset_io backends deployed through OpenShift AI.
- Support level: Technology Preview.
The Dataset_IO API manages the input and output of datasets and their content.
2.1.1.3. Inference API Copy linkLink copied to clipboard!
-
Endpoint:
/v1alpha/inference. - Providers: All inference backends deployed through OpenShift AI.
- Support level: Developer Preview.
The majority of the Inference API is deprecated. The Inference providers use the Completions and Chat Completions APIs now.
The Inference API enables conversational, message-based interactions with models served by OGX in OpenShift AI.
2.1.1.4. Tool Runtime API Copy linkLink copied to clipboard!
-
Endpoint:
/v1/tool-runtime. - Providers: All tool runtime backends deployed through OpenShift AI.
- Support level: Developer Preview.
The Tool Runtime API allows a model to dynamically call a tool at runtime.
2.1.1.5. Vector_IO API Copy linkLink copied to clipboard!
-
Endpoint:
/v1/vector-io. - Providers: All vector_io backends deployed through OpenShift AI.
- Support level: Developer Preview.
The Vector_IO API allows you to manage and query vector embeddings: numeric representations of data.
2.2. OpenAI-compatible APIs in OGX Copy linkLink copied to clipboard!
OpenShift AI includes a OGX component that exposes OpenAI-compatible APIs. These APIs enable you to reuse existing OpenAI SDKs, tools, and workflows directly within your OpenShift environment, without changing your client code. This compatibility layer supports retrieval-augmented generation (RAG), inference, and embedding workloads by using OpenAI-compatible endpoints, schemas, and authentication patterns.
This compatibility layer has the following capabilities:
- Standardized endpoints: REST API paths align with OpenAI specifications.
- Schema parity: Request and response fields follow OpenAI data structures.
When connecting OpenAI SDKs or third-party tools to OpenShift AI, you must update the client configuration to use your deployment’s OGX route as the base_url.
When you use OpenAI-compatible SDKs, the base_url must include the /v1 path suffix so that requests are routed to the OpenAI-compatible API surface exposed by OGX.
When you use OpenAI SDKs or send raw HTTP requests to OGX, always include the /v1 path suffix in the base URL.
For example: http://ogx-service:8321/v1
Using the service endpoint without /v1 results in request failures.
These endpoints are exposed under the OpenAI compatibility layer and are distinct from the native OGX APIs.
2.2.1. Supported OpenAI-compatible APIs in OpenShift AI Copy linkLink copied to clipboard!
Before running the following examples, ensure you have:
-
The OpenAI Python SDK installed:
pip install -q openai rich - A configured client pointing to your OGX endpoint
- Model IDs from your deployment (see Models API section)
from openai import OpenAI
import rich
# We'll be using a ogx server deployed in {productname-short}.
# Once all pods associated to the OGXServer are running,
# create the base_url using the ogx service hostname (with /v1 at the end when using openai sdk)
base_url = "http://ogx-distribution-service.my-project.svc.cluster.local:8321/v1"
client = OpenAI(
api_key="your-ogx-key",
base_url=base_url
)
For more information, see Deploying a OGX server.
2.2.1.1. Models API Copy linkLink copied to clipboard!
-
Endpoint:
/v1/models. - Providers: All model-serving back ends configured within OpenShift AI.
- Support level: Technology Preview.
The Models API lists and retrieves available model resources from the OGX deployment running on OpenShift AI. By using the Models API, you can enumerate models, view their capabilities, and verify deployment status through a standardized OpenAI-compatible interface.
Example code in Python:
# List models available in the ogx server
models = client.models.list()
rich.print(models)
# Select the first LLM and first embedding model
model_id = next(m for m in models if m.custom_metadata["model_type"] == "llm").id
embedding_model_id = (
em := next(m for m in models if m.custom_metadata["model_type"] == "embedding")
).id
embedding_dimension = em.custom_metadata["embedding_dimension"]
2.2.1.2. Chat Completions API Copy linkLink copied to clipboard!
-
Endpoint:
/v1/chat/completions. - Providers: All inference back ends deployed through OpenShift AI.
- Support level: Technology Preview.
The Chat Completions API enables conversational, message-based interactions with models served by OGX in OpenShift AI.
Example code in Python:
# Test chat completion functionality with a simple question
response = client.chat.completions.create(
model=model_id,
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "What is the capital of France?"},
],
temperature=0,
)
# Optional verification check
assert len(response.choices) > 0, "No response after basic inference on ogx server"
content = response.choices[0].message.content
rich.print(content)
2.2.1.3. Completions API Copy linkLink copied to clipboard!
-
Endpoint:
/v1/completions. - Providers: All inference back ends managed by OpenShift AI.
- Support level: Technology Preview.
The Completions API supports single-turn text generation and prompt completion.
Example code in Python:
# Test completion functionality with a simple question
response = client.completions.create(
model=model_id,
prompt="Answer with one word only: What is the capital of France?",
max_tokens=64,
temperature=0.1
)
# Optional verification check
assert len(response.choices) > 0, "No response after basic inference on ogx server"
content = response.choices[0].text
rich.print(content)
2.2.1.4. Embeddings API Copy linkLink copied to clipboard!
-
Endpoint:
/v1/embeddings. - Providers: All embedding models enabled in OpenShift AI.
The Embeddings API generates numerical embeddings for text or documents that can be used in downstream semantic search or RAG applications.
Example code in Python:
# Create text embeddings
response = client.embeddings.create(
input="Your text string goes here",
model=embedding_model_id
)
embedding = response.data[0].embedding
rich.print(embedding[:5] + ["..."] + embedding[-5:])
2.2.1.5. Files API Copy linkLink copied to clipboard!
-
Endpoint:
/v1/files. - Providers: File system-based file storage provider for managing files and documents stored locally in your cluster.
- Support level: Technology Preview.
The Files API manages file uploads for use in embedding and retrieval workflows.
The Files API handles file storage only. Indexing files for retrieval requires a vector store, which is a separate provider managed through the Vector Stores API. The following example demonstrates a complete file-upload-and-index workflow that uses both APIs together.
Example code in Python:
import requests
from rich import print
from rich.rule import Rule
import time
# -----------------------------
# Download the PDF from url
# -----------------------------
print(Rule("[bold cyan]Downloading PDF[/bold cyan]"))
# We'll use IBM 2025-Q4 report to test RAG, as models don't have that info
pdf_url = "https://www.ibm.com/downloads/documents/us-en/1550f7eea8c0ded6"
filename = "ibm-Q4-2025-4q25-press-release.pdf"
title = "IBM-4Q25-Earnings-Press-Release"
print("📥 Fetching PDF from URL...")
response = requests.get(pdf_url)
response.raise_for_status()
print("✅ PDF fetched successfully")
print(f"💾 Saving PDF as [bold]{filename}[/bold]...")
with open(filename, "wb") as f:
f.write(response.content)
print(f"✅ Downloaded and saved: [green]{filename}[/green]")
# -----------------------------
# Upload the PDF
# -----------------------------
print(Rule("[bold cyan]Uploading File[/bold cyan]"))
print("☁️ Uploading file to Files API...")
with open(filename, "rb") as f:
file_info = client.files.create(
file=(filename, f),
purpose="assistants"
)
print("✅ File uploaded successfully")
print(file_info)
# -----------------------------
# Create vector store
# -----------------------------
print(Rule("[bold cyan]Creating Vector Store[/bold cyan]"))
provider_id = "milvus-remote"
print("🧠 Creating vector store with Milvus provider...")
vector_store = client.vector_stores.create(
name="test_vector_store",
extra_body={
"embedding_model": embedding_model_id,
"embedding_dimension": embedding_dimension,
"provider_id": provider_id,
},
)
print("✅ Vector store created")
print(vector_store)
# -----------------------------
# Add file to vector store
# -----------------------------
print(Rule("[bold cyan]Indexing File[/bold cyan]"))
print("📎 Adding uploaded file to vector store...")
vector_store_file = client.vector_stores.files.create(
vector_store_id=vector_store.id,
file_id=file_info.id,
chunking_strategy={
"type": "static",
"static": {
"max_chunk_size_tokens": 700,
"chunk_overlap_tokens": 100,
}
},
attributes={
"title": title,
},
)
print("✅ File added to vector store")
print(vector_store_file)
# -----------------------------
# Verify file is completed
# -----------------------------
print(Rule("[bold cyan]Waiting until file status is complete[/bold cyan]"))
# Wait for file processing to complete
print("Waiting for file processing to complete...")
max_wait_time = 300 # 5 minutes
start_time = time.time()
while time.time() - start_time < max_wait_time:
files = client.vector_stores.files.list(vector_store_id=vector_store.id)
if files.data:
file_status = files.data[0].status
print(f"File status: {file_status}")
if file_status == "completed":
print("✅ File processing completed!")
break
elif file_status == "failed":
print("✗ File processing failed!")
break
time.sleep(5)
else:
print("⚠ Timeout waiting for file processing")
# Verify file is completed
files = client.vector_stores.files.list(vector_store_id=vector_store.id)
if files.data:
print(f"\nFinal file status: {files.data[0].status}")
print(f"File details: {files.data[0]}")
else:
print("No files found in vector store")
print(Rule("[bold green]All tasks completed successfully ✔[/bold green]"))
2.2.1.6. Vector Stores API Copy linkLink copied to clipboard!
-
Endpoint:
/v1/vector_stores. - Providers: Remote vector store providers configured in OpenShift AI.
- Support level: Technology Preview.
The Vector Stores API manages the creation, configuration, and lifecycle of vector store resources in OGX. Through this API, you can create new vector stores, list existing ones, delete unused stores, and query their metadata, all using OpenAI-compatible request and response formats.
2.2.1.7. Vector Store Files API Copy linkLink copied to clipboard!
-
Endpoint:
/v1/vector_stores/{vector_store_id}/files. - Providers: Local inline provider configured for file storage and retrieval.
- Support level: Developer Preview.
The Vector Store Files API implements the OpenAI Vector Store Files interface and manages the association between document files and vector stores used for RAG workflows.
2.2.1.8. Responses API Copy linkLink copied to clipboard!
-
Endpoint:
/v1/responses. - Providers: All agents, inference, and vector providers configured in OpenShift AI.
- Support level: Generally Available
The Responses API generates model outputs by combining inference, file search, and tool-calling capabilities through a single OpenAI-compatible endpoint. It is particularly useful for retrieval-augmented generation (RAG) workflows that rely on the file_search tool to retrieve context from vector stores.
The Responses API orchestrates inference and retrieval but relies on separate providers for file storage (Files API) and vector indexing (Vector Stores API). The following example demonstrates a complete RAG workflow that uses the Files API, Vector Stores API, and Responses API together.
Example code in Python:
from rich import print
from rich.table import Table
system_instructions = """You are a financial document analysis assistant specialized in quarterly earnings reports, annual filings, press releases, and earnings call transcripts.
You are designed to answer questions in a concise and professional manner.
Answer questions strictly using only the provided documents.
Base every answer strictly on the retrieved document content and cite the relevant section or excerpt ID.
Do not use outside knowledge.
Do not guess, infer missing data, or fabricate numbers.
If the answer is not found in the retrieved content, reply: "I couldn't find relevant information in the available files or my own knowledge."
Be concise, precise, and factual."""
examples = [
{
"input_query": "What do you know about IBM earnings in Q4, 2025? Summarize in one sentence",
"expected_answer": "IBM reported strong fourth-quarter results with revenue rising 12% to $19.7 billion, driven by double-digit growth in its Software and Infrastructure segments and a generative AI book of business that has now surpassed $12.5 billion"
},
{
"input_query": "What was the total value of IBM's generative AI book of business as reported in the fourth quarter of 2025?",
"expected_answer": "IBM reported that its generative AI book of business now stands at more than $12.5 billion."
},
{
"input_query": "What was IBM's reported free cash flow for the full year of 2025?",
"expected_answer": (
"IBM reported a full-year free cash flow of $14.7 billion, which was an increase of $2.0 billion year-over-year"
)
},
{
"input_query": "How did the Software segment perform in terms of revenue during the fourth quarter of 2025?",
"expected_answer": (
"The Software segment generated $9.0 billion in revenue, representing an increase of 14 percent (or 11 percent at constant currency)"
)
},
]
# Use the Responses API to create a results table comparing not using vs using
# the vector_store
table = Table(
title="Answer Comparison (With vs Without Vector Store)",
show_lines=True,
)
table.add_column("Question", style="cyan", no_wrap=False)
table.add_column("Expected Answer", style="magenta", no_wrap=False)
table.add_column("Answer (No Vector Store)", style="yellow", no_wrap=False)
table.add_column("Answer (With Vector Store)", style="green", no_wrap=False)
for example in examples:
question = example["input_query"]
expected_answer = example["expected_answer"]
# Ask question without vector_store
response_no_vs = client.responses.create(
model=model_id,
input=question,
instructions=system_instructions,
)
answer_no_vs = response_no_vs.output_text.strip()
# Ask question with vector_store
response_vs = client.responses.create(
model=model_id,
input=question,
instructions=system_instructions,
tools=[
{
"type": "file_search",
"vector_store_ids": [vector_store.id],
}
],
)
answer_vs = response_vs.output_text.strip()
table.add_row(
question,
expected_answer,
answer_no_vs,
answer_vs,
)
# The table will take a while to be printed, as multiple queries to the responses API will be done
print(table)
2.2.1.9. Conversations API Copy linkLink copied to clipboard!
-
Endpoint:
/v1/conversations. - Providers: All agents and inference providers configured in OpenShift AI.
- Support level: Technology Preview.
The Conversations API enables multi-turn, context-aware chats by managing server-side conversation state. Instead of manually passing previous_response_id between Responses API calls, you can create a conversation that automatically accumulates message history across multiple turns. This simplifies building AI applications where each turn in the conversation can reference context from all previous turns.
The Conversations API provides the following operations:
-
Create a conversation:
POST /v1/conversations- Creates a new conversation container with optional metadata. -
Retrieve a conversation:
GET /v1/conversations/\{id}- Retrieves a conversation by ID. -
Update a conversation:
POST /v1/conversations/\{id}- Updates a conversation’s metadata. -
Delete a conversation:
DELETE /v1/conversations/\{id}- Removes a conversation and its history. -
Create conversation items:
POST /v1/conversations/\{id}/items- Adds items to a conversation. -
List conversation items:
GET /v1/conversations/\{id}/items- Retrieves all messages stored in a conversation. -
Retrieve a conversation item:
GET /v1/conversations/\{id}/items/\{item_id}- Retrieves a specific item. -
Delete a conversation item:
DELETE /v1/conversations/\{id}/items/\{item_id}- Removes an item from a conversation.
To use a conversation with the Responses API, pass the conversation parameter instead of previous_response_id when calling /v1/responses.
Example code in Python:
model_id = "your-model-id"
# Step 1: Create a conversation
conversation = client.conversations.create(
metadata={"topic": "pet-care", "user": "demo-user"}
)
conversation_id = conversation.id
# Step 2: Send messages using the Responses API with conversation_id
# Turn 1
response1 = client.responses.create(
model=model_id,
input="I have a rabbit. What is its living quarters called?",
conversation=conversation_id,
store=True, # Persist each response as a conversation item
instructions="You are a helpful assistant. Keep responses brief.",
)
print(response1.output_text)
# Turn 2: The response can use context from Turn 1
response2 = client.responses.create(
model=model_id,
input="I also have a dog. What are its living quarters called?",
conversation=conversation_id,
store=True,
)
print(response2.output_text)
# Turn 3: The response can use context from previous turns
response3 = client.responses.create(
model=model_id,
input="List the living quarters I need for all my pets.",
conversation=conversation_id,
store=True,
)
print(response3.output_text)
# Step 3: List all messages in the conversation
items = client.conversations.items.list(conversation_id, order="asc")
for item in items.data:
print(f"{item.role}: {item.content}")
# Step 4: Clean up
client.conversations.delete(conversation_id)
The Conversations API is a Technology Preview feature in OpenShift AI. While functional and suitable for evaluation, some endpoints and parameters might change in future releases. This API is not recommended for production use.
2.2.2. OpenAI compatibility for RAG APIs in OGX Copy linkLink copied to clipboard!
OpenShift AI supports OpenAI-compatible request and response schemas for OGX retrieval-augmented generation (RAG) workflows. This compatibility allows you to use OpenAI clients, tools, and schemas with OGX for managing files, vector stores, and executing RAG queries through the Responses API.
OpenAI compatibility enables the following capabilities:
- You can use OpenAI SDKs and tools with OGX by pointing the client to the OGX OpenAI-compatible API path.
-
You can manage files and vector stores by using OpenAI-compatible endpoints and invoke RAG workflows by using the Responses API with the
file_searchtool.
When configuring clients, the required base_url depends on the SDK that you use:
OpenAI SDKs When you use an OpenAI-compatible SDK (for example, the OpenAI Python client), you must include the
/v1path suffix in the base URL. For example:`http://ogx-service:8321/v1`OGX SDK (
ogx_client) When you use the native OGX SDK, set the base URL to the OGX service endpoint without the/v1suffix. The SDK automatically appends the correct API paths. For example:`http://ogx-service:8321`
When you use OpenAI-compatible SDKs or send raw HTTP requests to OGX, always include the /v1 path suffix in the base URL.
Using the service endpoint without /v1 results in request failures.
2.3. OGX API provider support Copy linkLink copied to clipboard!
You can use OGX to enable various Provider APIs and providers in OpenShift AI. The following table lists the supported providers included in OpenShift AI, enablement environment variables, disconnected environment support, and its current support status.
The support status of the OGX API providers has shifted between Technology Preview and Developer Preview across OpenShift AI versions.
| Provider API | Providers | How to Enable | Disconnected support | Support status |
|---|---|---|---|---|
| Responses |
| Enabled by default | Yes | Developer Preview |
| Messages |
| Enabled by default | Yes | Developer Preview |
| Dataset_IO |
| Enabled by default | Yes | Technology Preview |
|
| Enabled by default | No | Technology Preview | |
| Files |
| Enabled by default | No | Technology Preview |
|
|
Set the | Yes | Developer Preview | |
| Inference |
|
Set the | Yes | Technology Preview |
|
|
Set the | Yes | Technology Preview | |
|
|
Set the | No | Technology Preview | |
|
|
Set the | No | Developer Preview | |
|
|
Set the | No | Developer Preview | |
|
|
Set the | No | Technology Preview | |
|
|
Set the | No | Technology Preview | |
|
|
Set the | No | Technology Preview | |
|
|
Set the | No | Technology Preview | Tool_Runtime |
|
| Enabled by default | No | Developer Preview | |
|
| Enabled by default | No | Developer Preview | |
|
| Enabled by default | No | Developer Preview | |
|
| Enabled by default | No | Developer Preview | Vector_IO |
|
|
Set the | No | Technology Preview | |
|
|
Set the | Yes | Technology Preview | |
|
|
Set the | Yes | Technology Preview | |
|
|
Set the | Yes | Technology Preview | |
|
|
Set the | Yes | Technology Preview | File Processors |
|
| Enabled by default | No | Developer Preview | |
|
|
Dependency only. Requires a custom | No | Developer Preview | |
|
|
Dependency only. Requires a custom | No | Developer Preview | |
|
|
Dependency only. Requires a custom | No | Developer Preview |
Any providers labeled as Dependency only are not included in the default runtime config.yaml file, but their dependencies are pre-installed in the container image. To use those providers, pass a custom config.yaml at runtime that includes the provider definitions.
2.4. OpenAI-compatible file citation annotations Copy linkLink copied to clipboard!
OGX supports OpenAI-compatible file citation annotations in Responses API outputs when using the file_search tool. These annotations enable applications to trace generated responses back to source documents without requiring changes to existing OpenAI client code.
2.4.1. OpenAI-compatible file citation annotations in OGX Copy linkLink copied to clipboard!
OpenShift AI provides OpenAI-compatible file citation annotations in Responses API outputs when using retrieval-augmented generation (RAG) with the file_search tool. These annotations enable applications to trace generated responses back to the source files used during retrieval without requiring changes to existing OpenAI client code. When you use the Responses API with the file_search tool, OGX returns citation metadata that references the source file used to generate the response. Annotations are enabled by default.
Citation annotations have the following characteristics:
- They follow the same response structure defined by OpenAI.
-
They appear in the
annotationsfield ofoutput_textresponse content. - They identify the source file by ID and filename.
- They provide document-level attribution.
This feature improves transparency for RAG workflows while maintaining schema compatibility with OpenAI request and response formats.
In OpenShift AI, the following annotation capabilities are supported:
- Annotations are returned only through the Responses API.
-
Annotations are returned only when using the
file_searchtool. -
The
file_citationannotation type is supported. - Attribution is provided at the document level.
2.4.2. Viewing file citation annotations in Responses API output Copy linkLink copied to clipboard!
When you query ingested content by using the file_search tool with the Responses API, OGX returns OpenAI-compatible file_citation annotations. These annotations identify the source files used during retrieval.
Prerequisites
- You have deployed a OGX server.
- You have configured at least one inference model.
- You have created a vector store and ingested content into it.
-
You can successfully execute a RAG query by using the
file_searchtool, as described in Querying ingested content in a Llama model. - You have access to a client environment, such as a Jupyter notebook or an OpenAI SDK client, that is correctly configured to send authenticated requests to the OGX server.
This procedure requires that content has already been ingested into a vector store. If no content is available, RAG queries return empty or non-contextual responses.
Procedure
In a Jupyter notebook cell or other configured client environment, run a RAG query by using the
file_searchtool.response = client.responses.create( model=model_id, input=query, instructions=system_instructions, tools=[ { "type": "file_search", "vector_store_ids": [vector_store_id], } ], )Inspect the full response object rather than only the
output_textproperty.response.outputAccess the
annotationsarray.annotations = response.output[0].content[0].annotations print(annotations)Review the
file_citationannotation fields.Example output:
[ { "type": "file_citation", "file_id": "file-57610eaac6364459bfefae60377837b7", "filename": "redbankfinancial_about.pdf", "index": 139 } ]
Each file_citation annotation includes the following fields:
-
file_id: The identifier of the retrieved file. -
filename: The name of the source file. -
index: The index of the cited file in the list of files.
Multiple annotations can reference the same index position.
Optional: Using the OpenAI-compatible HTTP endpoint
If you use raw HTTP requests or an OpenAI SDK, send requests to the following endpoint:
/v1/responses
Ensure that your base URL includes the /v1 path suffix, as described in OpenAI compatibility for RAG APIs in OGX.
The accuracy and consistency of citation annotations depend on the capabilities of the underlying language model. Smaller or less capable models might produce less precise attributions, even when retrieval is functioning correctly. If citation results are incomplete or inconsistent, verify the model configuration and consider using a larger or more capable model.
Optional: Using the OpenAI-compatible endpoint
When you use an OpenAI SDK, configure the client base_url to include the /v1 path suffix. The SDK automatically appends the appropriate endpoint path, such as /responses.
For example:
http://ogx-service:8321/v1
When you send raw HTTP requests, include both the /v1 path suffix and the /responses endpoint in the full request URL.
For example:
http://ogx-service:8321/v1/responses
Ensure that /v1 is included only once in the base URL. Do not append /v1 multiple times.
For more information, see OpenAI compatibility for RAG APIs in OGX.
The accuracy and consistency of citation annotations depend on the capabilities of the underlying language model. Smaller or less capable models might produce less precise attributions, even when retrieval is functioning correctly. If citation results are incomplete or inconsistent, verify the model configuration and consider using a larger or more capable model.
Verification
-
The response includes an
annotationsarray underoutput[].content[]. -
Each annotation has
"type": "file_citation". -
The
file_idandfilenamecorrespond to files stored in the specified vector store.
2.4.3. File citation annotation reference Copy linkLink copied to clipboard!
This reference describes the file_citation annotation type returned by OGX through the OpenAI-compatible Responses API.
2.4.3.1. Annotation location Copy linkLink copied to clipboard!
Annotations are returned in the annotations field of output_text content items within the output[].content[] structure of the Responses API response.
"output": [
{
"content": [
{
"type": "output_text",
"text": "Example generated response.",
"annotations": [ ... ]
}
]
}
]
2.4.3.2. Supported annotation type Copy linkLink copied to clipboard!
In OpenShift AI, OGX returns the file_citation annotation type when using the file_search tool.
URL citation annotations
The url_citation type is defined in the OpenAI schema but is not produced by OGX in OpenShift AI 3.3.
2.4.3.3. File citation fields Copy linkLink copied to clipboard!
The file_citation annotation includes the following fields:
| Field | Type | Description |
|---|---|---|
| type | string |
Always |
| file_id | string | Identifier of the source file used during retrieval |
| filename | string | Name of the source file |
| index | integer | Index of the cited file in the list of files. |
2.4.3.4. Annotation behavior Copy linkLink copied to clipboard!
- Attribution is provided at the document level.
- Multiple annotations can reference the same index position.
- Chunk-level and token-level attribution are not supported.
- Annotations follow the OpenAI response schema without modification.