Rethinking SAP Commerce Search: From Solr to AI-Driven Discovery

Article 1 Title: Why Solr Is No Longer Enough for Modern Commerce Search

Introduction I had the opportunity to create a search engine using Retrieval-Augmented Generation (RAG) with OpenAI and in-memory vector datastore. To say that I was impressed is an understatement. I realized that every developer now has the power to build advanced search capabilities tailored to their organization’s needs without relying on legacy keyword search engines.

For over a decade, Apache Solr has been the backbone of search functionality in SAP Commerce (Hybris). It excels at keyword indexing, faceted navigation, and performance at scale. But in the age of AI-driven customer experiences, Solr is showing its limitations. Today’s customers expect search to understand their intent, not just match their keywords.

This article is the first in a multi-part series dedicated to helping SAP Commerce teams modernize their search stack using Retrieval-Augmented Generation (RAG) with OpenAI and custom vector store. We’ll explore why traditional search is no longer enough, how to build a modern AI-enhanced layer, and how to gradually evolve your platform without disrupting your existing infrastructure.

In this first article, we explore why Solr, while still reliable, is no longer sufficient for delivering intelligent, personalized product discovery—and why RAG powered by OpenAI and vector datastores are emerging as a next-gen alternative.

The Solr Era: What It Got Right

• High performance full-text search: Solr is fast and scalable.
• Faceted filtering: Category, price, brand filters are tightly integrated.
• Integration with SAP Commerce: Native indexing, SmartEdit support, and OCC APIs.

But while Solr is structured and reliable, it lacks “understanding.”

Where Solr Falls Short in 2025

1. Keyword dependence: Solr only matches tokens. No understanding of meaning or context.
2. Lack of semantic understanding: Cannot handle queries like “best vacuum for pet hair and allergies.”
3. No personalization: Solr doesn’t adapt to individual user behavior or preferences.
4. Hard to maintain: Boosting and synonyms require manual tuning and merchandising.

RAG with OpenAI + InMemoryVectorStore: A New Paradigm

Retrieval-Augmented Generation (RAG) combines two powerful ideas:

• Semantic retrieval of the most relevant content (via vector search)
• Generative answering using a large language model (e.g., GPT-4)

With custom in-memory vector store as your vector store (likeInMemoryVectorStore) and OpenAI for embeddings + response generation, you can:

• Understand the intent behind search queries
• Return answers, not just results
• Create intelligent assistants that interact with your product catalog

Example: Solr vs RAG in Action User Query: “What’s a good air purifier for someone with pet allergies?”

• Solr Result: Products with the exact words “air,” “purifier,” “pet,” “allergies”
• RAG Result: A GPT-powered answer citing a HEPA purifier with pet dander filters and linking to product SKUs

Why SAP Commerce “Hybirs” Architects Should Pay Attention

• Composable Commerce is gaining momentum; RAG fits this model
• Solr is hardwired, but not irreplaceable
• You can run RAG alongside Solr for hybrid search
• RAG enables voice, chat, and natural Q&A interfaces

Coming Up Next in the Series

• Article 2: “Replacing Solr with AI: The Power of Semantic Search in SAP Commerce”
• Article 3: “Activating Solr’s Untapped Potential for AI-Powered Commerce Search”
• Article 4: “Measuring the Business Impact of AI-Powered Search”