
Implementing semantic search-A Client perspective
Semantic search using conversational AI is a new form of search that leverages natural language processing (NLP) and machine learning techniques to help users find products by interacting with them in a conversational manner. Instead of using traditional keyword-based searches, users can ask questions or describe what they are looking for in a more natural, human-like way, and the AI interprets this input to provide relevant product recommendations.
While many vendors have incorporated this new technology into their products, enterprise adoption still remains sluggish. According to Algolia, which is one of the leading semantic search vendors, one of the biggest challenges of operationalizing semantic search lies in ensuring the availability of right data.
Clients must so significant due diligence to develop proper use cases, identify the data points for both training and search and finally, and then assemble this data and keep it fresh.
What does it take to implement semantic search?
Semantic search holds great promise but clients need a repeatable framework to deploy this capability. Vendors simply provide the technology but without a top-down solution architecture approach, realizing the benefits remains elusive. Architecture building blocks provide a framework whereby the entire capability is divided into sub-capabilities or architecture building blocks. By building a data and technology strategy at an individual block level, clients can incrementally operationalize semantic search in a vendor-neutral manner that is aligned with business needs.
While identifying the use cases is much more of a business input, identifying and assembling the underlying data is very much a technical architecture issue and needs a framework based approach. And that is the focus of this article. We outline an abstract framework that divides the solution into architecture building blocks. Clients can use these blocks to develop conceptual architectures and also assess vendor capabilities against these architectures.
Starting with an example
The best way to understand how an AI-based search differs from a keyword-based algorithm is to use an example.
Imagine you are shopping for a new laptop on an e-commerce website that uses conversational AI.
Traditional Search:
You might type “laptop 16GB RAM i7 15-inch” into the search bar. The system would return a list of laptops that match those exact specifications.
Conversational AI Search:
Instead, with conversational AI, you might type or say, “I’m looking for a laptop with at least 16GB of RAM, an Intel i7 processor, and a 15-inch screen that’s good for gaming.”
The AI then does several things:
- Understand Context and Intent: The AI recognizes that you are looking for a laptop and identifies key attributes like “16GB of RAM,” “Intel i7 processor,” “15-inch screen,” and “good for gaming.”
- Processes Natural Language: It interprets the intent behind phrases like “good for gaming,” understanding that this typically implies a need for a powerful graphics card and potentially other gaming-friendly features like high refresh rate screens.
- Searches and Filters: The AI searches through the product database, filtering out laptops that do not meet the specified criteria and prioritizing those with features relevant to gaming.
- Interactive Clarification: If the AI needs more information to narrow down the search, it might ask follow-up questions like, “Do you have a preferred budget range?” or “Do you prefer a particular brand?”
- Personalized Recommendations: Finally, the AI presents a list of laptops that match your requirements, possibly highlighting those that are highly rated for gaming or on sale.
In this way, conversational AI makes the product search experience more intuitive, personalized, and efficient.
What are the architecture building blocks of a semantic search capability?
Semantic search can be operationalized in client environments by breaking down the capability into four sub-capabilities or architecture building blocks. These include-

Search intent recognition
In this block, the natural text is vectorized and a tool-specific query is created using a combination of vector databases and NLP techniques. In its most basic form, this boils down to mapping the search intent to a discrete set of data points captured in the search index.
In the example above, the tool would use NLP to identify the following list of attributes to search on
- RAM size – 16GB
- Screen resolution – 15in
- Processor – i7
- Graphic card RAM – Min 4GB
- Refresh rate of at least 60Hz
The AI tool will likely implement several technologies internally for intent recognition. From a client perspective, some key questions that need to be addressed include
- How well does the tool’s AI model identify relevant product attributes (e.g. Screen refresh rate in above example) from niche specific free text?
- If the native AI model lacks the capabilities, can it be fine tuned by feeding in client-specific product description data?
- If this fine tuning is needed, which products will provide the training data set?
- How will this data be exported to the vendor data repository?
- What risk and compliance issues will need to be addressed?
Delving into these questions will provide a clear picture of the effort and challenges expected in implementing vendor features relating to intent recognition.
Query personalization
In this step, the base query is further augmented to add additional context specific to the user. While personalization is highly specific to individual enterprise scenarios, it helps to view personalization along three dimensions.
Explicit or implicit preferences
This type of data includes zero and first-party data collected from a variety of sources including surveys, phone calls, lead generation forms, and chat transcripts. Notice that the preferences might not be directly provided by the customer and might have to be derived using NLP techniques. A case in point here would be a customer of an online electronic shop, and who is looking to purchase an OLED monitor in a specific size and price range. This information would be captured in the chat tool but has to be added to the use profile through text parsing and other contextual analysis.
Behavioural signals
This has to do with all sorts of interactions from various digital channels. The kind of pages that the person viewed, recency/frequency of visits, any phone call or chat interactions, and so on. The key is to extract meaningful data points from all this data, to provide personalized experiences. Once again, extensive use of NLP would typically need to be made for parsing text data (e.g. from page titles or tags, phone call transcripts, chat transcripts) into specific data points that can then be queried by the search engine.
Purchase history
Using past purchase history to provide personalized search context is a powerful way to enhance the shopping experience and increase customer satisfaction. Below are five examples of how purchase history can be used to build a rich customer profile:
- Identify Purchase Patterns
- Method: Analyze the user’s past purchases to identify patterns in the types of products they buy, including categories, brands, price ranges, and frequencies.
- Example: If a customer frequently buys organic skincare products, the system can identify this pattern and recommend similar or complementary items in the same category.
- Cross-Selling and Upselling
- Method: Based on previous purchases, suggest products that complement or upgrade the user’s existing items.
- Example: If a customer recently bought a camera, the system could recommend accessories like lenses, tripods, or camera bags. If they purchased an entry-level model, the system might suggest a higher-end version based on their buying history.
- Seasonal and Replenishment Reminders
- Method: Use purchase history to predict when a customer might need to replenish consumable products or purchase seasonal items.
- Example: If a customer buys a particular brand of protein powder every three months, the system can send a reminder or suggest trying a new flavor or brand just before they’re likely to run out.
- Personalized Promotions and Discounts
- Method: Offer special discounts or promotions on products like those the customer has previously purchased or shown interest in.
- Example: If a customer has bought several pairs of shoes from a particular brand, the system could offer a discount on new arrivals from that brand.
- Product Bundling
- Method: Create personalized bundles of products that are often purchased together based on the user’s past behavior.
- Example: If a customer has purchased a laptop and a mouse, the system might recommend a bundle that includes a laptop stand, an external keyboard, and a mouse pad, offering a small discount for purchasing them together.
In all the scenarios above, the key is to augment the original search query with additional data points to provide more contextually relevant results.
From an architecture building block perspective, multiple questions will need to be addressed including
- Do we even need to augment and personalize the search? Are there compelling reasons for this and is it worth doing a cost-benefit analysis of effort requirement vs. incremental lift in customer experience?
- If personalization is to be implemented, how do we phase it? Can we start with simple data points first (e.g. purchase history) and then move to more complex data exports like chat data, phone transcripts etc.
- What data will the vendor tool need to ‘learn’ personalization? Where will it come from and how?
- What data will we need in the search index? How will it get there?
- Which tools will need to be involved in setting up these integrations?
These are some of the questions that will need to be addressed from a client perspective, and regardless of vendor technology platform.
Interactive clarifications
Interactive clarifications in semantic search are a feature where the search system interacts with the user to refine and clarify their query, ensuring that the results are more accurate and relevant. This process helps the system understand the user’s intent better by asking follow-up questions or presenting options that guide the user toward a more precise search outcome.
For example, If the AI needs more information to narrow down the search, it might ask follow-up questions like, “Do you have a preferred budget range?” or “Do you prefer a particular brand?”
This capability is usually intrinsic to most enterprise semantic search tools and can typically be toggled on and off. Some questions to address when architecting this block might include
- What impact would it have on search query if we completely disabled interactive clarifications? Practically implementing these in an enterprise context will likely take a lot of work and there needs to be a very sound justification for the extra effort.
- If we do decided to toggle on this functionality, then based on personalization use cases, what specific data points will be present in the search index?
- How can the AI prompts be engineered to only seek interactive clarifications around these data points?
- Will there be any need for building any RAG integration with the vendor tool?
Just because a vendor promotes interactive clarifications capability as part of their offering, does not mean that clients can actually operationalize it. A careful due diligence is advisable and a well architected building block will clearly outline the risks and benefits of implementing this capability.
Catalog search
This is the area that probably requires the most architectural plumbing in order to enable the semantic search capability. The challenge lies in populating the search engine index with corporate data and then keeping it fresh based on real-time, near real-time, or batch modes. Conceptually, this step involves addressing the following questions
- Identifying the data points to be stored in the search engine index and their respective sources. These will come from the due diligence conducted in steps 1 and 2 above (core intent recognition and query personalization)
- Creating the search engine index schemas to physically store the attribute data. Some of the data points will be searchable directly, while others would be provided back along with query results.
- Setting up integrations to push data into the index (base data upload)
- Keeping the index updated with source data changes. Example, when new attributes are added, or products removed.
The conceptual architecture of this block would need to address each of the points above in sufficient detail, but at the same time, maintaining complete vendor neutrality.
Conclusion
Semantic search technologies have immense potential but the degree of success lies in developing systematic approaches to planning and building these capabilities within specific business contexts.
Before proceeding with vendor selection, clients must at least develop conceptual (if not logical and physical) architectures for the building blocks above, so that there is very clear understanding of data, resource, time, and budget constraints.
Once the understanding is in place, highly focused and meaningful conversations can be crafted for vendor discussions. The abstract nature of these steps also means that the implementation would typically not be tied to specific vendor platforms.