Siebel 26.6’s RAG-Powered Search: Why Your Support Reps Stop Solving the Same Ticket Twice

Siebel CRM 26.6 adds retrieval-augmented generation (RAG) and semantic similarity search to the service request workflow, so a support rep can find past cases by meaning instead of exact keywords.

What Siebel 26.6 Adds

According to Oracle's Siebel CRM blog, the 26.6 Release Update adds RAG and semantic similarity search. It pairs large language models with semantic vector search, so the system matches the meaning of a service request rather than its exact words. Siebel Hub reports that 26.6 shipped in June 2026.

Oracle's 26.6 Siebel Applications Administration Guide has a new topic, Retrieval Augmented Generation (RAG) for Siebel CRM. Its description says it covers some sample RAG use cases and how to set up and configure RAG for Siebel CRM.

The Oracle Siebel CRM blog post on this feature describes what the rep sees: the open service request is summarized, a semantic similarity search runs against historical service requests in OpenSearch, and a ranked list of matches comes back. The rep can open a match, review how it was resolved and link it as the parent record without leaving the current request. According to the Towards AI article, retrieval can also cover relevant knowledge base articles, and the RAG framework is configurable for both cloud and on-premises deployments.

How It Fits the Service Request Workflow

The Towards AI article describes the feature inside the service request workflow: a rep working an open case clicks a View Solution action, and the system runs a pipeline that summarizes the request, embeds it, and retrieves similar past cases.

Why It Helps Support Reps

Keyword search misses relevant past solutions when the wording differs. Semantic search compares meaning, so a case phrased differently can still surface. The title of the original article puts the benefit this way: reps stop solving the same ticket twice.

Design Time and Run Time

Oracle's administration guide describes RAG in Siebel as two phases. Design time prepares the data; run time answers each query.

Design time

1. Identify the source data: unstructured content such as documents, files and attachments, and structured data in Siebel databases.
2. Clean, segment and chunk unstructured content. Overlapping chunks can improve retrieval accuracy for long documents.
3. Generate vector embeddings with the same embedding model that will be used for queries at run time.
4. Store the embeddings in the vector repository: Oracle Database 23ai Vector Search or OCI Knowledge Bases for cloud deployments, Siebel OpenSearch for on-premises deployments.
5. For structured Siebel data, keep attributes such as Id, Status, Priority, Date, Account and Revenue as metadata or filter criteria. Only descriptive fields such as Summary and Description are turned into text for embeddings.
6. Optionally extract entities and relationships to enable graph-based retrieval.

Run time

1. A query starts from a user, business service, workflow, script, API or assistant.
2. The query is embedded with the same model used at design time.
3. A similarity search runs against the vector store. On premises, OpenSearch uses hybrid search with configurable weighting; in the cloud, RAG uses the OCI RAG Agent chat workflow.
4. The retrieved content is combined with the original query to enrich the prompt.
5. The enriched prompt goes to the selected LLM, such as an OCI Generative AI model or another configured LLM, and the answer returns to the originating channel: the Siebel UI, a workflow, a business service, eScript or a REST API.

Cloud versus On-Premises

Enabling It

The guide's enablement topic lists these steps. Verify the details for your environment in the 26.6 documentation.

1. Set the system preferences: Enable RAG to Y (N or blank disables it) and KnowledgeBaseType to OpenSearch or OCIObjectStorage.
2. Configure the Service Request business component. Its user properties are delivered with <CHANGE_ME> placeholders that you must replace with real values.
3. Configure the application user properties: two ClientBusinessService entries, KM Integration Service and SiebelAgentAIService.
4. Update ociconfig.properties with your environment values. The [GENAIAGENT] section holds the OCI endpoints, regions, bucket, namespace, compartment IDs and agent, knowledge base and data source names.
5. Run the Siebel Application flow. The agent, agent endpoint, knowledge base and data source are created automatically when it runs.

[GENAIAGENT]
    genaiagent_management_endpoint=<CHANGE_ME>
    genaiagent_region=<CHANGE_ME>
    genaiagent_service_endpoint=<CHANGE_ME>
    objectstorage_endpoint=<CHANGE_ME>
    objectstorage_region=<CHANGE_ME>
    provider=OCIObjectStorage
    bucketName=<CHANGE_ME>
    namespace=<CHANGE_ME>
    agentName=<CHANGE_ME>
    knowledgeBaseName=<CHANGE_ME>
    compartmentId=<CHANGE_ME>

The excerpt above is shortened: the documentation lists more parameters (for example isKBCreation, isDSCreation, toolType, routingInstructions), and every value shown as <CHANGE_ME> is a placeholder that your administrator fills in.

Prerequisites

• OCI AI Services and Generative AI Services configuration must be completed and validated.
• ociconfig.properties must be present in the internal Tomcat webapps directory with the required OCI parameters (tenancy, user, fingerprint, region, compartment and private key file information).
• With KnowledgeBaseType set to OpenSearch, OpenSearch must be installed, configured and running.
• All data categories and business components intended for search must be enabled for indexing, and the initial Index or Index All process must have completed.
• The required seed data, business services, applets, views, manifest files and repository objects must exist in the environment or be migrated first.
• Users and administrators need access to the relevant views, buttons and the new AI or RAG business services.

Troubleshooting

Best Practices from the Guide

• Index only data users are allowed to see. The guide states that RAG does not enforce Siebel data access controls, so security requirements, user responsibilities and data retention policies must drive the choice of data sources.
• Use the same embedding model for ingestion and for query embedding within a knowledge base.
• Store structured data as metadata or filters and embed the descriptive text fields.
• Tune chunk size, overlap and contextual chunking for large documents.
• Tune hybrid search weights, result limits and prompt templates in a non-production environment first.
• Keep monitoring responses for accuracy and grounding, and re-index when source data changes significantly or new data categories are added.

Before You Adopt It

• Check Oracle's documentation for exact feature availability, prerequisites and configuration steps for your release.
• Measure the effect on your own tickets: neither the Oracle blog nor this article reports benchmark figures, and none should be assumed.
• Decide early which service request fields and attachments are allowed to enter the index, because that decision is a security decision.

Sources

• Siebel 26.6's RAG-Powered Search: Why Your Support Reps Stop Solving the Same Ticket Twice (Towards AI)
• Finding the Right Solution Faster: How RAG Makes Service Requests Smarter in Siebel CRM (Oracle Siebel CRM blog)
• Using Retrieval Augmented Generation (RAG), Siebel CRM 26.6 Applications Administration Guide
• Enabling Retrieval Augmented Generation (RAG), Siebel CRM 26.6
• Troubleshooting and Best Practices, Siebel CRM 26.6