Searching, fast and slow, through product catalogs

TL;DR

This paper tackles SKU search in CRM contexts by proposing a production-ready, multi-component architecture that handles abbreviations and scale. It integrates part-number pattern matching, dynamic Trie-based suggestions, and a high-accuracy complete search that fuses character-level TF-IDF with language-model embeddings, achieving strong top-10 accuracy while meeting a strict latency target. An ablation study demonstrates the complementary value of each component, and the work additionally explores GPT-3.5-Turbo-based SKU description generation to improve user context. The approach is demonstrated on a Dynamics CRM catalog with about $87{,}000$ SKUs and shows practical impact through improved search quality, deployment considerations, and clear avenues for future refinement such as semantic abbreviation embeddings and automatic abbreviation discovery.

Abstract

String matching algorithms in the presence of abbreviations, such as in Stock Keeping Unit (SKU) product catalogs, remains a relatively unexplored topic. In this paper, we present a unified architecture for SKU search that provides both a real-time suggestion system (based on a Trie data structure) as well as a lower latency search system (making use of character level TF-IDF in combination with language model vector embeddings) where users initiate the search process explicitly. We carry out ablation studies that justify designing a complex search system composed of multiple components to address the delicate trade-off between speed and accuracy. Using SKU search in the Dynamics CRM as an example, we show how our system vastly outperforms, in all aspects, the results provided by the default search engine. Finally, we show how SKU descriptions may be enhanced via generative text models (using gpt-3.5-turbo) so that the consumers of the search results may get more context and a generally better experience when presented with the results of their SKU search.

Figures (5)

• Figure 1: Example samples of the minimal set of features we are considering for the SKU product search system. More details about the part number matcher can be found in Section \ref{['sec:patternMatch']} and about how product friendly names are generated in Section \ref{['sec:abbreviationExpansion']}.
• Figure 2: Example of a Trie data structure storing 10 strings Trie. Notice how unlike a binary search tree, all the children of a node have a common prefix of the string associated with that parent node. As soon as the user types (for example), the letter "t", the Trie can immediately suggest 4 possible matches corresponding to leaf nodes 7, 3, 4 and 12. As the user continues to type more characters the space of possible matches rapidly (exponentially) decreases.
• Figure 3: User-initiated search. Model training) We start by encoding the catalog of products using both a pre-trained LLM and into character-level TF-IDF vectors. In our case, the pre-trained LLM was chosen to be multi-qa-MiniLM-L6-cos-v1miniLM as explained in Section \ref{['sec:completeSearch']} but others may be used as drop-in replacements. Those representations of the items in the catalog are then cached into memory. Model scoring) Once the user pushed the "search" button, the seller query is transformed into a character-level TF-IDF vector as well as a second vector obtained by running this query into a pre-trained LLM. At this point, the process resembles the model training phase with the only difference that we are now vectorizing only a single seller query at the run-time of the search. Once both embedding vectors are obtained, we compare them respectively with the product embeddings we had stored during the model training phase. We decide to keep the top $k_1$ (resp. top $k_2$) highest cosine similarity pairs between the character-level TF-DF embeddings (resp. LLM embeddings). Given that there may be duplicates between both lists, we keep only the top-$k$ (where $k \leq k_1 + k_2$) of their union. This final list of $k$ product candidates is finally re-ranked according to the highest LCS scores between the candidates and the original seller query.
• Figure 4: High-level summary of the complete SKU product search architecture for CRMs. The first component consists of the part number pattern matcher discussed in Section \ref{['sec:patternMatch']}. In case, the search query cannot be handled by this module, it moves on to the dynamic suggestions detailed in Section \ref{['sec:Suggestions']}. Finally, the last component consists of the user-initiated search which is detailed in Section \ref{['sec:completeSearch']} and Fig. \ref{['fig:userSearch']}.
• Figure 5: Illustration of the trade-off between response time and accuracy of the model. The dashed black line illustrates the linear growth in model accuracy as the response time gets longer when more modules are added into the overall architecture.