GraphEx: A Graph-based Extraction Method for Advertiser Keyphrase Recommendation
Ashirbad Mishra Soumik Dey Marshall Wu Jinyu Zhao He Yu Kaichen Ni Binbin Li Kamesh Madduri













 
 

  Pennsylvania State University
  
  
  USA




  eBay Inc.
  
  
  USA



  eBay Inc.
  
  
  USA



  eBay Inc.
  
  
  USA



  eBay Inc.
  
  
  China



  eBay Inc.
  
  
  China



  eBay Inc.
  
  
  USA



  Pennsylvania State University
  
  
  USA






















































§ ABSTRACT 
Online sellers and advertisers are recommended keyphrases for their listed products, which they bid on to enhance their sales. One popular paradigm that generates such recommendations is Extreme Multi-Label Classification (XMC), which involves tagging/mapping keyphrases to items. We outline the limitations of using traditional item-query based tagging or mapping techniques for keyphrase recommendations on E-Commerce platforms. We introduce GraphEx, an innovative graph-based approach that recommends keyphrases to sellers using extraction of token permutations from item titles. Additionally, we demonstrate that relying on traditional metrics such as precision/recall can be misleading in practical applications, thereby necessitating a combination of metrics to evaluate performance in real-world scenarios. These metrics are designed to assess the relevance of keyphrases to items and the potential for buyer outreach. GraphEx outperforms production models at eBay, achieving the objectives mentioned above. It supports near real-time inferencing in resource-constrained production environments and scales effectively for billions of items.
 






<ccs2012>
   <concept>
       <concept_id>10002951.10003317.10003347.10003350</concept_id>
       <concept_desc>Information systems Recommender systems</concept_desc>
       <concept_significance>500</concept_significance>
       </concept>
   <concept>
       <concept_id>10002951.10003227.10003351</concept_id>
       <concept_desc>Information systems Data mining</concept_desc>
       <concept_significance>100</concept_significance>
       </concept>
   <concept>
       <concept_id>10002951.10003260.10003272.10003273</concept_id>
       <concept_desc>Information systems Sponsored search advertising</concept_desc>
       <concept_significance>100</concept_significance>
       </concept>
   <concept>
       <concept_id>10002950.10003624.10003633.10010917</concept_id>
       <concept_desc>Mathematics of computing Graph algorithms</concept_desc>
       <concept_significance>300</concept_significance>
       </concept>
   <concept>
       <concept_id>10010147.10010178.10010179.10003352</concept_id>
       <concept_desc>Computing methodologies Information extraction</concept_desc>
       <concept_significance>300</concept_significance>
       </concept>
 </ccs2012>


[500]Information systems Recommender systems
[100]Information systems Data mining
[100]Information systems Sponsored search advertising
[300]Mathematics of computing Graph algorithms
[300]Computing methodologies Information extraction













GraphEx: A Graph-based Extraction Method for Advertiser Keyphrase Recommendation
    Kamesh Madduri
    September 9, 2024
================================================================================





§ INTRODUCTION


In the online e-commerce advertisement space,
keyphrase recommendation is offered to sellers/advertisers who want to bid on buyers/users' search queries for a better placement of their inventory on the search result pages (SRP) which increases their engagement. Keyphrases are generally recommended as shown in figure <ref> in real time for the items if they are relevant to them. Advertisers only want to bid on keyphrases that are actual queries and not queries that seem plausible but non-existent for targeting purposes. Since the nature of the problem is mapping items to multiple queries to increase the potential reach of advertisers, this problem of keyphrase recommendation can be formulated as an Extreme Multi-Label Classification (XMC) problem, see  <cit.>. The data for training the XMC models is sourced from search logs that document the items shown to buyers when they input search queries[We term buyer search queries as keywords. And use keywords and keyphrases interchangeably.]. A keyword and an item are paired together and become a part of the training dataset when they co-occur in the search logs a certain number of times with significant buyer interactions on those items. XMC models in the context of keyword recommendation are supervised tagging techniques that map items to keyphrases.




The impact of XMC tagging models can be determined by how often each keyphrase is searched. Keyphrases can be classified as head or tail keyphrases according to their search frequency. Head keyphrases are generally less in number but searched frequently by buyers. Targeting such head keyphrases leads to increased revenue since more buyers inclined to search for them, resulting in more clicks and more buys. XMC models focus on recommending more tail keyphrases <cit.> and avoid the head keyphrases despite them being relevant to the item. In addition, tail keyphrases/queries will not have too many items relevant to it, so the chances of the relevant seed item getting proper positioning through organic retrieval without any promotion increases — making them unappetizing to advertisers. 



There are various caveats to recommending keyphrases using XMC tagging formulation trained on engagement data from search logs. Search logs with engagement data is highly skewed as shown in Figure <ref>, with 90% of items associcated with only one query in terms of clicks/sales. This absence of engagement (clicks/sales) doesn't necessarily mean that the keyphrase/query is irrelevant to the item. When buyers are presented items in relation to the query/keyphrase, the presentation is biased as the items are ranked and their ranking can affect buyer engagement. This biased presentation implies that just because an item doesn't have clicks/sales in relation to the keyphrase doesn't mean that the item is irrelevant to the keyphrase. It could mean that the item was not popular and was retrieved at a lower rank for the query in question and influenced buyers to ignore it. These unpopular items need the help of advertisement to level the playing field by promoting their items to a favourable rank to garner more buyer engagement. Thus traditional XMC models which rely on modelling item-query interaction inherit this bias towards popular items which are ranked at the top and miss the targeting for non-popular items which constitute 90% of the inventory and are the main focus of advertisement. 



While this bias has been discussed in  <cit.>, we contextualize it in this domain of advertiser keyphrase recommendation. Continuing from the limitations of the data on which XMC tagging models are trained, the same training set and bias perpetuate the lack of diversity of different XMC models. Even with a 10% increase in the precision/recall scores of subsequent XMC models, the recommendations do not have sufficient diversity to obtain substantial clicks. In addition the lack of ground-truth for most items leads to inaccurate offline evaluation which is conventionally ground truth-based (Precision/Recall). We offer a diverse set of alternate evaluation metrics which are comprehensive in measuring a model's performance and diversity for these skewed distributions and test it in an online setting. 









 §.§ Scope and Contributions



In this work, we limit ourselves to retrieving keyphrases based on item's title and the keywords from the items's categorical populace, especially those keyphrases that are actively and frequently searched by buyers. The extraction is done in an unsupervised setting where the keyphrases for each item are unknown during training. 
In fact, we restrict the curation of keyphrases (more details in <ref>) to include only those that have high search volume (number of searches made by buyers) based on buyer searches. XMC models suffer from item popularity biases, which can result in a severely restricted set of keyphrases for non-popular items[Non-popular items constitutes more than 80% of total items] or recommending a lot of tail keyphrases for items. Our distinction is that by decoupling the keyphrases from item engagement and using categorical population dynamics of keyphrases, we keep the essential bias towards head keyphrases (attractive to advertisers) while getting rid of the negative bias (against non-popular items which are the main target of advertisement). 



The models are required to be frequently refreshed, i.e., the models are regularly trained and tuned on recent data to keep up with the latest buyer search queries. Thus, models with smaller training and setup times are necessary, and minimal tuning is crucial to decrease the engineering effort. In addition, due to the ever changing buyer query space, frequent model refreshes is required accommodate newer keywords. For e-commerce platforms, it is also vital that the recommendations are in real-time or near real-time, so the models should also have inference latency of a few milliseconds.

In this work, our aim is to overcome the many challenges as described above. Our contribution to this work is summarized as: 

    
  * An innovative graph-based extraction algorithm for keyphrase recommendation that is simple, transparent and easy to interpret. 
    
  * The design of the algorithm and the process of data collection have been specifically geared towards mitigating item popularity bias while maintaining advertiser friendly head keyphrase bias. 
    
  * Provide a new robust framework for evaluation of incremental impact of recommendation models in terms of performance and diversity metrics.
    
  * A scalable and sustainable model that runs without GPUs for hundreds of millions of items in real-time.
    




§ RELATED WORK


Keyphrase generation via open-vocabulary models like GROOV <cit.>, One2Seq <cit.> and One2One <cit.> are susceptible to recommending keyphrases that are not part of the label space. Another formulation for keyphrase recommendation is keyphrase extraction with methods such as keyBERT<cit.>, which have conventionally treated keyphrase recommendation as a two-step problem: keyphrase generation and keyphrase ranking. The basic keyBERT module considers keyphrase generation as an n-gram based permutation problem, i.e., it generates all possible n-grams for a given n-gram range. The keyphrase ranking module then orders them using an encoder-based ranker tuned on some domain-specific supervised signal. This simple generation framework presents two main issues: 1) the token space is limited by token adjacency and token presence in item's text 2) the keyphrase should also be in the universe of queries that buyers are searching for; which this simple generation model does not ensure.[keyBERT can also use LLMs as generators, but their time complexity is substantial.] We limit our comparison to models with shorter training and inference times based on the scope discussed in section <ref>. The models deployed at eBay fulfill these requirements and provide good recommendations. We choose 4 representative models from the deployed ones; fastText, Graphite, Rules Engine (RE) and SimilarListing(SL) variants.



fastText <cit.> is a basic linear neural network model that generates word vectors with CBOW architecture and uses a single classification layer to generate predictions. It uses hierarchical softmax for faster training on a large number of classes (keyphrases) and subword embeddings for better representation and inferencing. Graphite <cit.> is the state-of-the-art fastest XMC model that uses bipartite graphs to map words/tokens to the data points and then map them to the labels associated with the data points. It is implemented for multi-core systems having infinitesimal training time and uses parallelization for real-time inferencing. Both fastText and Graphite are deployed at eBay. There are four other proprietary models also deployed at eBay for keyphrase recommendation. Rules Engine (RE) is a simple technique that stores item-keyphrase associations based on their cooccurrences (associated with buyer activity) in the search logs during the last 30 days. It recommends keyphrases only for items in which buyers have shown interest and not for any new items. Likewise, RE-trank recommends only the queries that were ranked in the top slots for the existing association of items. We also compare with a few other variants that are based on similar listings (SL) and their related queries. These are; SL-query that determines the existing listings/items which share some keywords, thus recommending other's associated keywords, and lastly 
SL-emb <cit.> which uses embeddings of the item's title to compare and find similar listings then recommend the related queries. SL-emb is a
dense retrieval model whose inference is implemented in two stages, embedding generation and ANN<cit.>. Note that of the SL models only SL-emb can handle cold start conditions on new items such as fastText and graphite. The implementation of the RE and SL techniques also employs a few other methods which we can't discuss due to proprietary constraints. 



§ GRAPHEX MODEL


We first formulate the keyphrase recommendation problem and then briefly go through the data set curation process. Next, we describe the notations, then the Construction of the graph which is the training part of GraphEx and the Inference method for obtaining the predictions.




 §.§ Problem Formulation

For efficiently solving the recommendation problem, we use the formulation of a permutation problem that permutes the title strings to match a given set of keyphrases. Let's consider a title string with l words in it. The goal is to generate permutations of differing lengths from the l words. Now, given a list of predefined keyphrases, the possible permutations of the title string is constrained to match the keyphrases. Therefore, each permutation can exactly match a keyphrase or be part of some keyphrases, but if a title token isn't part of any keyphrase then it is ignored. Thus, it does not limit the permutations to token adjacency or token presence in item's text.  A naive brute force method is to generate all possible permutations of the l words which will take O(l!) time. Each keyphrase can be validated using hashing and string comparisons (each word can be an integer) and thus can take overall O(l× l!) time. This is infeasible to perform in real-time with limited amount of resources. 



 §.§ Dataset Curation


We aggregate our datasets from the search logs generated during buyer sessions on eBay.com. The keyphrases that buyers input during the search sessions are curated based on certain criteria, which we discuss here. eBay's search engine Cassini shows a sufficient number of items (Recall Count) for each input query in its search results. Cassini determines the Leaf Category of the keyphrase and it is the same as the top-ranked item's leaf category (lowest-level product categorization). We restrict the number of curated keyphrases by only considering those that are heavily searched by the buyers. The number of times a keyphrase is queried is termed as (Search Count). Due to proprietary reasons, we cannot further delve into the details. The absolute values of Recall Count and Search Count are not essential in fact, an anonymized ranking works well. All the unique keyphrases are aggregated for each Top level category (metacategory) and are grouped for each Leaf Category within the metacategory. Each keyphrase is associated with a Search Count and a Recall Count. Note that a keyphrase can be duplicated across different Leaf Categories.





 §.§ Terms and Notations


We consider a set of unique keyphrases termed as Q=k_1,k_2,...,k_K. Each keyphrase k_i can be considered as a set of words w_1,w_2,...,w_l, where w_* are tokenized[The tokenization scheme can be anything as long as string comparison functions are well-defined and consistent for that scheme. By default we consider space delimited tokenization.] from the keyphrase string k_i. Each k_i is further associated with a Leaf category l, Recall Count/Rank R and Search Count/Rank S. Given a test item's title T, the goal is to recommend a subset of keyphrases from Q that are relevant to T. We can consider the title as a string with tokenizedfn:tokenization words T=w_1,w_2,...,w_t similar to a keyphrase, but titles are generally longer than the keyphrases. We denote a graph G(V,E) where V is the set of vertices and E is the set of edges. Each edge e∈ E is denoted by a pair of vertices e=(v_1,v_2) indicating a connection between the vertex pair. In a Bipartite Graph, the set of vertices V are divided into a pair of disjoint subsets V=X⋃ Y. Each vertex in the same subset (X or Y) isn't connected by an edge and only vertices in different subsets can be connected by an edge. We define the function Deduplicate and Count or DC(·) which, given a list of elements, counts the occurrences of each unique element in the list. It outputs a list of tuples of the form (element,count) for each unique element in the list.



 §.§ Construction Phase


In this phase, the method relates the words in the keyphrases to the keyphrases themselves by mapping the relation using Bipartite Graphs. For a particular metacategory, the model constructs a series of Bipartite Graphs G_l(V,E) one for each leaf category l from only those keyphrases Q_l that belong to the same leaf category. For each graph G_l(V,E), the two subsets X and Y of the vertex set V are constructed as follows: All the unique words in the keyphrases are considered as the set X, while the unique keyphrases are considered as Y. Each unique word and unique keyphrase is represented as non-negative integers, to avoid string comparison and manipulation costs. Mathematically, X=⋃_∀ w∈ k_i,∀ k_i∈ Q_l{w} and Y=Q_l. An edge e=(x,y) in set E, is permitted from vertex x∈ X to vertex y∈ Y when x⊂ y, indicating an edge from a word to the keyphrase that it is a part of. Such edge relations are created for all the Bipartite Graphs using the unique words in all the unique keyphrases within each leaf category.




An example of a constructed Bipartite Graph is shown in Figure <ref>. Each vertically stacked vertex belong to the same subset. The left set of vertices are the words/tokens and the right set are the keyphrases. The vertices are shown as strings here for presentation, but during implementation, the integer IDs are used. Each tokenizedfn:tokenization word is connected to the keyphrase that it is a part of. The graph is stored in Compressed Sparse Row (CSR) format, which occupies the least amount of space. Each word/token can be accessed in unit time whereas the adjacencies of a word can be traversed in O(d) where d is the degree of the word or the number of keyphrases that contain that word. A map type data-structure is used to associate the leaf category ID to the CSR structure for each graph. 

The keyphrase's Recall and Search Count[Defined in section <ref>] are stored in separate arrays. So given a keyphrase ID l, R(l)  and S(l) will directly index into the arrays and return the values taking unit time. The space occupied by each leaf category graph depends linearly on the number of unique words and edges, as CSR structure occupies |X|+|E| space. The count of edges |E| depends on the sum total of occurrence of each word in the keyphrases/labels which is difficult to generalize and depends on the datasets. Separate graphs for each leaf category help in recommending more relevant keyphrases which becomes more clear in the next section.






 §.§ Inference Phase


Given a test item T and a leaf category l with the tokenized words in the title as T=w_1,w_2,...,w_t, the goal is to extract a list of keyphrases in decreasing order of relevance to the item. GraphEx's recommendation is based on permuting the word in the item's title as discussed in section <ref>. To enable this, the Inference Phase is divided into two steps: Enumeration step that generates keyphrases from words of title and the Ranking step that ranks the keyphrases in order of relevance to the item.




  §.§.§ Enumeration Step


GraphEx first determines the Bipartite Graph G_l(V,E) that corresponds to the leaf category l of the input item. The corresponding graph G_l can be obtained in O(1) time if a hashing data-structure is used for to map the leaf categories to the graphs defined in section <ref>. 
The step first tokenizes the item's title into words and uses them as input along with the graph G_l in the Algorithm <ref>. Lines 3-5 of the algorithm map the tokenized words of T using the bipartite graph G_l to the labels/keyphrases. Let's look at an example to understand this process. Given an item “audeze maxwell gaming headphones for xbox”, we highlight the corresponding words on the left in the illustrated figure <ref>. The keyphrases (l) connected to the highlighted words are candidates for recommendation and are collected in C_L in algorithm <ref>. Line 6 uses the DC function to de-duplicate and count the redundancies in the candidate keyphrases. E.g. in figure <ref> the keyphrase “audeze maxwell” is connected to two words “audeze” and “maxwell”, whereas “gaming headphones xbox” is connected to 3 words. Hence, after the execution of line 6, it results in the duplication count of 2,2,3,2, and 1 in the given order for each of the keyphrases on the right side of the illustrated figure <ref>. The count indicates the number of words in the keyphrase that are common with the item title T.



The next part of the Enumeration step generates a tuple corresponding to each label in C_L using lines 7-9 in algorithm <ref>. We define the function Label Title Alignment or LTA that uses the common word count (or duplication count) c=|T∩ l| between the title T and the label l as LTA(l,c)=c/|l|-c+1. The LTA ratio is the second element of the tuple or the first attribute of the label l. The two attributes are the Search S(l) and Recall count R(l) of the label. The tuples generated by this process are returned in C_R. The time complexity of this step primarily depends on lines 3-5 due to restriction on prediction count which we discuss later in Section <ref>. The time complexity can be uncertain to determine due to the varying number of edges for each word. For simplification, we consider the average degree of each word as d_avg=|E|/|X|. Then asymptotically the time taken to gather the candidate labels for each word of the item title T is O(|T|.d_avg). Modeling the problem as a Bipartite graph helps to efficiently permute all the words in the title T while only generating permutations that are valid keyphrases. 



  §.§.§ Ranking Step


In this step, the candidate labels in C_R are sorted in the non-increasing order of the first attribute or second tuple element LTA and to break ties, S(l) and subsequently R(l) is used. While tie-breaking, those keyphrases are preferred that have higher search counts and lower recall counts. Higher search counts will have more clicks while lower recall count indicates the keyphrases have fewer items associated with them. So, when a keyphrase is input by a buyer, the search engine displays relatively fewer items, boosting click probability per item. The LTA function was designed to provide a higher score to those keyphrases that have less words in the label that aren't part of the title. Let's compare two keyphrases from the figure <ref>, “audeze maxwell” and “wireless headphones xbox”, both have 2 words in common with the sample title shown in section <ref>. The first's LTA is 2/1 and second's is 2/2, thus ranking “audeze maxwell” higher. LTA minimizes the risk involved by preferring those keyphrases that have more complete information (or more matching words).







 §.§ Implementation Details


The edges of the bipartite graph of each leaf category are constructed as tuples, sorted and then de-duplicated based on their IDs which are finally stored in the CSR format.  The space complexity is linear in the number of edges for each graph given by O(|X|· d_avg) where X∈ V, which is the set of unique words in all the keyphrases for the leaf category. The words and the labels are represented as unsigned integers to occupy minimal space and convert string comparisons to integers ones. Therefore, comparing two words or two labels takes O(1) time. The construction phase does not involve any weight updates or hyper-parameter training, making it quite fast and efficient.



A drawback of directly using the algorithm <ref> is the large number of keyphrases that are generated in the initial C_L. This results in a poly-logarithm time complexity for line 6 in the algorithm. To circumvent this we used count arrays to calculate the redundancies of each unit keyphrase. The space taken for the storage of C_L and the count array is approximately 2 |Q_l|. A predetermined number of keyphrases (10-20) are generated for a given test instance during the inference phase. So, after the counting in line 6, the number of unique keyphrases in C_L is pruned based on this requirement. This is done by first grouping each keyphrase with similar counts, then restricting the number of groups such that the sum of group sizes is equal to the required number of predictions. Groups with larger keyphrase redundancy counts are preferred, and all the keyphrases of the threshold group are included even if the group size overflows the number of required predictions. Thus the time complexity of the Enumeration step remains as O(|T|.d_avg). Though the sorting in the Ranking step seems expensive, the list length is always approximately a constant because of |C_L|=|C_R|. This is due to the restriction on prediction count as mentioned above thereby not contributing asymptotically to overall time complexity.







§ EXPERIMENTATION AND RESULTS


We perform experiments on representative datasets from eBay and compare our model's results with representative models in production at eBay. We first describe our experimental setup, the datasets we use, and the models we compare in Subsection <ref>. Then, we analyze the results of each of our accuracy experiments in Subsection <ref> and show the execution performance of each model in  <ref>. Next, we describe the deployment in production in section <ref> and its impact in section <ref>.



  §.§.§ Setup and Datasets


GraphEx is implemented for multi-core systems without requiring any GPUs. Its inference part is implemented on C++ (≥ g++-9.3.0) using OpenMP threading with Python wrappers using pybind11. The construction part is implemented in Python (≥ 3.7); due to its lightweight approach since the construction doesn't require large resources and takes much less time. We used a system with 4 Intel Xeon Gold 6230R CPUs with 2 sockets each containing 20@2.10GHz cores, and 500 GB of RAM for the analysis. GraphEx employs coarse-grained multi-threading, assigning each input's inference to an individual thread. We launched 20 threads with compact pinning to occupy only a single socket sufficient for our dataset size.






 §.§ Experimentation Details



We contrast our model against notable models used at eBay for keyword recommendation, as elaborated in section <ref>. We present findings on three product meta-categories from eBay, each symbolizing a classification of large, medium, and small categories. The classification is determined by the count of items and the quantity of unique keyphrases within each meta-category. Table <ref> shows the anonymized categories and their details. Even though our methodology does not require knowledge of the items or their meta-data, the XMC models require them, hence we show their numbers for perspective. Our data curation and analysis are limited to eBay, due to the absence of any publicly available keyword recommendation datasets from e-commerce advertisement platforms.



The data is collected from search logs for the duration of one year for both XMC models and GraphEx. For XMC, the item-keyphrase pairs are constrained based on their co-occurrence count, number of buyer clicks/purchases, etc. 
The curated unique keyphrase count shown in the third column of table <ref> contains both the head and tail keyphrases and is incorporated by XMC models. On the other hand, GraphEx's data curation for training, aggregates keyphrases without looking at any association with the items. It restricts the keyphrases[Shown in the right most column of table <ref>.] to contain a higher number of head and a lower number of tail keyphrases using the curation process described in Section <ref>. Generally, keyphrases that on an average weren't searched atleast once per day were filtered for GraphEx[This restriction was relaxed for CAT_3 that didn't have sufficient keyphrases.]. For testing, we sampled a set of 1000, 400 and 200 items from actively listed items on eBay.com for the categories CAT_1, CAT_2, and CAT_3 respectively. We also computed the search count of each unique keyphrase by considering a 15 day duration different from the one year duration for the training set. This removes any bias that models have based on their training data. For each of the test items, all the models generate a variable number of keyphrases with a limit of 40. 






  §.§.§ Traditional Metrics


Typically, metrics like Precision, Recall, F1 and so on are used for comparing recommendation models. These metrics facilitate comparison by emphasizing retrieval capability, which is suitable for XMC tagging models, but does not pertain to extraction or generation models. There are three main issues with using these metrics: Prediction Diversity, Ground Truth Incompleteness/Uncertainty, and Ground Truth Bias. Let us take an example instance T, associated with a ground truth label k1 in the training set. All models make certain choices to increase the probability of predicting k1 for inputs that are similar to T. This aligns the tagging-based models to predict a similar subset of labels for T, thus reducing diversity among the predictions of different models. Another facet is the assumption that the curated ground-truth labels for each instance or data point are correct. Labels for some instances or items might be missing due to rigid thresholds in the curation process. Hence, a metric that measures retrieval ability hinders the performance of unsupervised extraction or generation tasks that don't rely on ground truth labels for items. Finally, if k1 is a biased label for T, tagging models tend to replicate the bias in their predictions. Improving diversity and reducing biases is possible through the alteration of techniques, though this would complicate their implementation and the process of comparison. 

Ideally, metrics should compare the relevancy of the predictions to the input text without limiting the comparison to a set of predefined labels/keyphrases. However, it is difficult to determine the relevance of predictions without any prior labels. So, while previous research have used human judgement <cit.>, we use AI-generated evaluations to evaluate at scale.[The AI predictions were benchmarked against positive buyer judgement and achieved more than 90% alignment, similar to how it was done in <cit.>.] We generate prompts for Mixtral 8X7B <cit.> per item, which contains the item's title and a set of predicted keyphrases. The response is “yes” or “no” for each keyphrase, indicating whether the keyphrase is relevant to the item or if it is irrelevant.

Once a set of keyphrases is determined as relevant for an item, we filter the keyphrases through the high Search Count threshold. This threshold is determined as the 75th percentile of the descending order of search counts of all unique keyphrases in the category such that 25% of the unique keyphrases are above this limit. The keyphrases whose Search Counts are above the threshold are considered as Relevant Head Keyphrases[High Search Count.] otherwise they are considered as Relevant Tail Keyphrases. Note that the head keyphrases determined as irrelevant by the AI are not considered for that item's evaluation, as even though buyers search the keyphrases in large volume they mostly won't click on the corresponding item. Hence forth, whenever we use the term head keyphrases it means relevant head keyphrases.






 §.§ Performance Results


We compare the models based on the effective (relevant and head) keyphrases that each model recommends. Figure <ref> shows the per-model number of keyphrases averaged over all items that are evaluated as relevant or irrelevant by AI, while also distinguishing the head and tail types in the relevant keyphrases. The x-axis shows all the models under comparison. The y-axis in figure <ref> shows the average number of keyphrases per item that are irrelevant and relevant head/tail keyphrases, while summing up to the total predictions by each model.

It is evident from figure <ref> — as the number of predictions generated by a model increases, the number of irrelevant predictions also tends to rise. The predictions from subsequent models (left to right on the x-axis) are deduplicated against keyphrases already recommended by the previous models. A diverse set of keyphrases is beneficial as it typically results in more engagement, especially if the keyphrases are relevant and are head keyphrases. Based on feedback from sellers, they prefer a balance: they dislike having either too many or too few keywords. They prefer as few irrelevant keywords, while still driving more engagement and having a diverse set of keywords. Thus the ultimate goal for models is to predict a reasonable number of total keyphrases with a higher proportion of relevant head keyphrases and a diverse set of keyphrases. Due to the varying number of predictions by each model, we use one set of metrics to compare the relevant and head keyphrases within each model and another set to compare between different models: 

    
  * 𝑅𝑒𝑙𝑒𝑣𝑎𝑛𝑡 Proportion (RP)=# 𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑜𝑛𝑠/# 𝑡𝑜𝑡𝑎𝑙 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑜𝑛𝑠
    
  * 𝐻𝑒𝑎𝑑 Proportion (HP)=# ℎ𝑒𝑎𝑑 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑜𝑛𝑠/# 𝑡𝑜𝑡𝑎𝑙 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑜𝑛𝑠
    
  * 𝑅𝑒𝑙𝑎𝑡𝑖𝑣𝑒 𝑅𝑒𝑙𝑒𝑣𝑎𝑛𝑡 𝑅𝑎𝑡𝑖𝑜 (𝑅𝑅𝑅)=# 𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡 𝑚𝑜𝑑𝑒𝑙1 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑜𝑛𝑠/# 𝑟𝑒𝑙𝑒𝑣𝑎𝑛𝑡 𝑚𝑜𝑑𝑒𝑙2 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑜𝑛𝑠
    
  * 𝑅𝑒𝑙𝑎𝑡𝑖𝑣𝑒 𝐻𝑒𝑎𝑑 𝑅𝑎𝑡𝑖𝑜 (𝑅𝐻𝑅)=# ℎ𝑒𝑎𝑑 𝑚𝑜𝑑𝑒𝑙1 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑜𝑛𝑠/# ℎ𝑒𝑎𝑑 𝑚𝑜𝑑𝑒𝑙2 𝑝𝑟𝑒𝑑𝑖𝑐𝑡𝑖𝑜𝑛𝑠

Table <ref> demonstrates the assessments using both sets of metrics on relevant and head keyphrases. The metrics RRR and RHR are calculated using the GraphEx's predictions as the denominator. It is important to note that each set of metrics alone don't offer a comprehensive view. Depending on the variation in total predictions between the two models, the RP and HP tend to favor the model with fewer predictions, while RRR and RHR favor model1 if it has a larger count. We don't show absolute numbers due to the proprietary nature of data and the models.

For clarity, we first discuss the models that have a much larger number of predictions, as seen in Figure <ref> which are SL-emb and fastText. For Table <ref>, fastText and SL-emb has lower RP and HP (columns 2^nd and 3^rd) than GraphEx due to their large prediction count. However, we can also see that GraphEx outperforms fastText (except CAT_3) and SL-emb in RRR and RHR (columns 4^th and 5^th). Thus GraphEx has a lower percentage of irrelevant keyphrases and a higher count of relevant and head keyphrases. CAT_3 is a small metacategory with fewer items and lower buyer interaction, leading to fewer keyphrases. Therefore, creating effective keyphrases for GraphEx becomes difficult and necessitates tailored curation. The models that have much smaller total count of predictions are RE, RE-trank, SL-query, and Graphite. In Table <ref>, it is evident that these models possess a higher RP compared to GraphEx. This is attributable to their lower number of predictions, which skews the proportions. However, excluding RE and Graphite, the models exhibit a significantly smaller HP than GraphEx. Additionally, these models have much smaller RRR and RHR, as shown by the third and fourth columns (metrics) of the table. Despite Graphite having a slightly higher HP for CAT_3, its RRR and RHR is still lower than that of GraphEx for all categories. Consequently, the models are unlikely to achieve substantial clicks like GraphEx due to the fewer head keyphrases. 









The models RE and RE-trank are simple retrieval techniques, based on recalling the ground truth (item-query combinations with associated buyer activity) with a minimum amount of buyer activity in a short lookback period. The results of RE as seen in Table <ref> are mixed, with lower HP in CAT_1, while 2.8% and 15.9% more HP than GraphEx in CAT_2 and CAT_3 respectively. The RRR and RHR of RE is always lower than GraphEx. Albeit their simple nature, both RE and RE-trank are recommenders that are closest to the ground truth in terms of actual buyer-engagement. 

While we covered the two aspects of comparison, lower irrelevant and higher head keyphrase counts; diversity is another aspect that determines whether the effective keyphrases generated by a model will bring substantial incremental impact. Therefore, the final metric to compare with other models is the diversity of GraphEx's predictions. We first separate out (mentioned earlier) the unique or diverse head keywords recommended by each model that are relevant to the item. Table <ref> shows the relative amount of diverse keyphrases of each model to the diverse keyphrases of GraphEx (averaged per item). It is evident that GraphEx recommends the highest amount of diverse head keyphrases in constrast to any other model. 



 §.§ Execution Results



It is important for the models to attain the real-time recommendation and model refresh goals as described in section <ref>. We compare only the XMC models with GraphEx as the REs and SLs (except SL-emb) are simple retrieval techniques implemented in the Spark/Hadoop ecosystem while model inferencing is more complex technique. We examine the models based on Inference Latencies, Model Sizes, and Training times. [SL-emb inference stages are complex, embedding generation occurs in GPU whereas ANN is done in CPU, thus it is difficult to compare the inference latencies with other models.]



For near real-time recommendation, the Inference Latency of a single input should be in milliseconds. The left image of Figure <ref> compares the per-input inference latency of the XMC models and GraphEx. The latencies for each model are computed by amortizing the time taken for prediction over the entire test set. We can see that all the models are within the required limit of 10 ms, but fastText takes more time for a prediction. Graphite and GraphEx's latencies are comparable for the smaller categories (CAT_2 and CAT_3). The performance of GraphEx is superior, attaining up to 17× and up to 13× more speed up in contrast to fastText and Graphite on CAT_1. If we infer 20 million items in CAT_1, GraphEx will result in energy savings of 11 hours and 8.5 hours with respect to fastText and Graphite, respectively.



The right of Figure <ref> compares the storage sizes of the above models. 
The fastText model requires significantly more storage across all categories because of the extensive weight matrix and the word embeddings it maintains. This is the case even after reducing the model size during training to enhance precision for production. Graphite occupies substantial space for the large category CAT_1 but has a comparable size to GraphEx for other categories. GraphEx occupies the least size for its models even after constructing graphs for multiple leaf categories. The training times of fastText run into >4 hours for all categories with bigger categories running for days and include multiple epochs and autotuning phases. Graphite has a graph-based construction step that takes around 1-6 minutes while GraphEx takes <1 minutes on all the categories. This is due to the curtailment of the training data to head keyphrases and implementation of the construction step that efficiently constructs and stores the model.

 





 §.§ Production Engineering Architecture



In this section, we describe the engineering architecture used to serve GraphEx keywords to our sellers for their inventories in one of eBay's major sites. There are two components for recommendation Batch and Near Real-Time (NRT) Inference. Batch inference primarily serves items with a delay, whereas NRT serves items on an urgent basis, such as items newly created or revised by sellers. The batch inference is done in two parts: 1) for all items in eBay, and 2) daily differential, i.e. the difference of all new items created/revised and then merged with the old existing items. The NRT inference is done using Python code hosted by eBay's internal ML inference service Darwin. Darwin is then called by eBay's recommendation service, triggered by the event of new item creation or revision, behind a Flink processing window and feature enrichment. Note that GraphEx serves as one of the keyword recommendation sources in the whole Batch/NRT framework.


The GraphEx batch inference is done using eBay's machine learning platform Krylov<cit.> and runs on a single node with 70 cores and 900 GB RAM. GraphEx inference is so fast that the time required to run on a space of 200 million items is just 1.5 hrs. This is a huge improvement over fastText and Graphite which take 1.75 days and 1.5 days respectively. Another batch job in Spark joins these sources in Hadoop and injects them into a Key-Value store (NuKV), which is then called by the eBay platform's inference api and served to eBay's sellers. This architecture can scale to billions of items and hundreds of billions of keywords that serve eBay's platform. The architecture is illustrated in Figure  <ref>. Due to the nature of its algorithm, the GraphEx model is bounded by the label space on which it trains. However, since GraphEx training is inexpensive as Graphite, the model can train in a matter of minutes even for very large categories, making it ideal for daily model refresh. This makes it possible for GraphEx to cater to newer keywords that arise every day. This is a huge improvement over fastText which takes a day or more to train on these large categories and has a monthly refresh schedule.





 §.§ Impact



GraphEx was deployed for the sellers of a particular site on eBay to replace Graphite keywords. After its release, a differential pre-post analysis was done to gauge the impact of GraphEx keywords in comparison to Graphite which it replaces. The differential analysis also involved measuring the impact of all keywords generated by GraphEx over a period of 2 weeks, compared to the other sources of recommendations. GraphEx provides 43% more distinct item-keyword associations than Graphite with the average search volume of its keywords nearing 30x of RE, and 2.5X of fastText. In terms of performance, GraphEx delivers an incremental lift of 8.3% in total ads revenue and a 10.3% in Gross Merchandise volume Bought (GMB), i.e. the total money made by selling the item. In terms of Return on Ads Spend (ROAS), given by ROAS = GMB/Ads Revenue, it is the most successful amongst cold-start models. Among all models its ROAS is only beaten by RE and RE-trank which are non-cold start ground-truth recalling models, and GraphEx beats them in terms of item coverage (more than 3x items covered by GraphEx). We cannot disclose anymore details due to business and proprietary reasons.





§ CONCLUSION

We introduce a novel graph-based extraction method called GraphEx which is tailored for online advertising in the e-commerce sector. GraphEx efficiently solves the permutation
problem of token extraction from item's title and mapping them to a set of valid keyphrases. It is not limited by the vocabulary of the item's title and the order of tokens in them. This method produces more item-relevant keyphrases and also targets head keyphrases favored by advertisers, ultimately driving more sales. It is currently implemented at eBay, a leading e-commerce platform serving its sellers with billions of items daily. We show that traditional metrics do not provide accurate comparison amongst the models, and using a single metric for comparison will be misleading. Thus, we use a combination of metrics with AI evaluations to provide a better picture of the practical challenges of keyphrase recommendation. We evaluated its performance against the production models at eBay, demonstrating superior results for our model across the various metrics. Additionally, GraphEx offers the most profitable cold start keyphrase recommendations for advertisers with the lowest inference latency in eBay's current system and allows for daily model refreshes to serve our ever changing query space.


ACM-Reference-Format






§ APPENDIX




 §.§ AI Evaluation Prompt


Prompts were generated for Mixtral 8X7B to determine whether a keyphrase was relevant to an item based on similarity to the item's title as described in Section <ref>. The structure of the prompt is shown below. The response is an yes or no answer for each corresponding keyphrase indicating if it is relevant or not relevant to the item. 





 


 §.§ Ablation Studies





  §.§.§ Data Curation Effects


A critical component of GraphEx's training involves the process of data curation. We find that the Search Count defined in Section <ref> is crucial for predicting relevant as well as head keyphrases. A low Search Count of 1 inculcates many bogus user queries and hence needs a much higher threshold. An ideal threshold would be keyphrases that are queried at least once daily, which equates to 180 over a span of 6 months. However, as indicated in Table <ref>, this threshold results in a reduced number of unique keyphrases, necessitating a relaxation of the limit.

To comprehend the influence on recommendations, we evaluated two GraphEx models constructed with search counts of 90 and 180, respectively. A random subset of 1000 items from CAT_1 was utilized for testing. Approximately 20.1% of the items had identical recommendation sets from both models. For the remaining 80% of items, 20% had similar relevant keyphrases and 7.2% had the same relevant head keyphrases. For the remaining keyphrases (about 60%), the proportions of relevant and head keyphrases for the Search Count thresholds of 90 and 180 are presented in Table <ref>. The benefit obtained with head keyphrases at the 180 search count surpasses the benefit obtained for relevant keyphrases at the same count when compared to a search count of 90. 




    


  §.§.§ Dissecting Predictive Count Variance


The models under comparison and can be divided into two groups; Non-cold start predictors (RE, RE-rank, and, SL-query) and Cold start predictors (SL-emb, fastText, Graphite, and, GraphEx). The cold start predictors are those that can recommend keyphrases for a new item that doesn't exist in the universe of items. These predictors, which are used for new items without historical data, a higher number of predictions is necessary to ensure that enough relevant keyphrases are identified. For new items, there is no established ground truth, making it difficult to gauge the accuracy of predictions. The primary predictors for any item are the non-cold start predictors. Thus the models in figure <ref> are deduplicated from left to right as discussed in section <ref>.




 §.§ Interpretability

The applications in E-Commerce domain frequently require that a model be interpretable. As this helps to comprehend the rational behind its predictions and decision process. In our use case, it is essential to trace where the words in the keyphrases arrive from.  Neural Network models typically require converting input text into vectors, which often obscures the contribution of individual tokens to the decisions. While, interpretability techniques such as LIME and SHAP offer post-hoc explanations, treating a Deep Neural Network as a black-box. They also require much effort to figure out the contributions of each input feature.

Unlike the black-box models, the GraphEx algorithm has 3 transparent phases: keyphrase curation, keyphrase mapping, and ranking. The data curation process gives perspective as to how the keyphrases in GraphEx's label set were curated. The keyphrase mapping phase details how GraphEx's candidate keyphrases were mapped from the keyphrases extracted from the item's title to GraphEx's candidate keyphrases. The ranking algorithm which then ranks the mapped candidates is transparent as well. It uses 
Label Title Alignment (LTA) outlined in Section <ref> which is a token based algorithm ensuring majority of the tokens in the keyphrases match the title. This ensures that GraphEx's predicted keyphrases are explainable and interpretable.

