1013002018 Food Discovery wih Uber Eats: Building a Query Understanding Engine | Uder Engineering Blog Context 1 Co Queries: ‘/Spley food Tan-tan Noodle Food Discovery with Uber Eats: Building a Query Understanding Engine By Ferras Hamad, Isaac Liu, Xian Xing Zhang Choice is fundamental to the Uber Eats experience. At any given location, there could be thousands of restaurants and even more individual menu items for an eater to choose from. Many factors can influence their choice. For example, the time of day, their cuisine preference, and current mood can all play a role. At Uber Eats, we strive to help eaters find the exact food they want as effortlessly as possible, We approach this task through search and recommendation technologies, and recent advances in machine learning. From the moment an eater enters a query, we try to understand their intent based on our knowledge of food organized as a graph, and then use a learned representation of eater intent to expand on this query, with the idea of surfacing the most relevant results. A greater part of the Uber Eats discovery process comes from the recommender system we built, designed to be both engaging to eaters and helpful to our restaurant partners. Through frameworks such as multi-objective optimization and multi- armed bandit, we balance the needs of both restaurants and eaters in the Uber Eats marketplace, In this two-part article series, we will look under the hood of the Uber Eats app and walk through the efforts we take to aid eaters in their decision-making process, This first part of the series focuses on building a query understanding engine for Uber Eats through an in-house food knowledge graph, and the related work done to help understand expli through representation learning-based query expansion. The second article in this series. describes how we used multi-objective optimization to build a recommendation engine, showing eaters new restaurants based on their order history. ater intent Understanding intent The first question we try to understand when helping our customers discover the perfect meal is: what is the eater looking for? For example, some engineers in our office order bubble tea for ‘a midday pick-me-up, When they open the Uber Eats app, their intent is clear and they know hips slong uber comiuber-ats-query-understanding! 191013002018 Food Discovery wih Uber Eas: Suing @ Query Understanding Engine | Uder Engineering Blog they only want bubble tea. However, when eaters open the app to order lunch or dinner, their intentions may not be as clear. An eater might have a general cuisine type in mind, like Asian or ‘American, but need help deciding whether to go with Chinese or Japanese, sandwiches or barbecue. Alternatively, an eater might have a certain type of food in mind, but choose something else while browsing the app. For example, an eater might search for udon, but end up ordering soba, In this case, the eater may have been looking for something similar to udon, such as soba and ramen, instead of only being interested in udon. As humans, it might seem obvious; Udon and soba are somewhat similar, Chinese and Japanese are both Asian cuisines. However, machines have a more difficult time understanding these similarities only based on the textual Information. In fact, a lot of work goes into training them to make these types of intelligent decisions on the semantic level. Typically, an eater specifies their intent through text in the form of a search query in the Uber Eats app. Consequently, we use query understanding to figure out eater intent. Although query understanding is a common problem for different types of search engines, it poses unique challenges and additional opportuniti may be categorized for a specific cuisine type, but may also include other types of cuisine on its ‘menu. Individual food items can share enough similarities to make them relevant as results ina search query, although their names may be completely different, And the geographical bounding for the set of potential results creates a limitation, which can lead to no obvious responses to a query. 's when faced with food and restaurants. A restaurant Building a food knowledge graph The classic approach of query understanding through text matching with natural language processing (NLP) works if the eater intent is clear and specific, But where the intent is ambiguous, such as the scenarios outlined above, applying classic NLP approaches alone is not sufficient. Of the alternative approaches we can take, most require establishing an intellige! understanding of the entities within the food domain by building a knowledge base, Many companies spend considerable time building up knowledge bases across several domains, with Google's Knowledge Vault being one of the most well-known, ‘At Uber, we are building a food-focused knowledge base to enable better understanding of food-related queries. In the food domain, we deal with heterogeneous entities such as restaurants, cuisines, and menu items, Since these entities have natural relationships, we can model them as a graph. A graph is the most common form used to express complex and intricate relationships between entities in a knowledge base. This graph makes modeling and linking data much more intuitive, Establishing a knowledge base can be a very challenging process. To effectively leverage data, a knowledge base needs to be in a semi-structured form: generic and flexible enough to easily add more facts, but specific enough to be more than just a blob of data. Achieving this balance hips slong uber comiuber-ats-query-understanding! 291013002018 Food Discovery wih Uber Eats: Building a Query Understanding Engine | Uder Engineering Blog requires building an ontology, or language, to describe the graph, including properties of different entities and the relationships between them, Graph a ingeet (on™ >» (woe Soweee Graph c Figure: A high-tevlvew of raph data pipeline shows how graphs are created with multiple data With this ontology, our offline pipelines can transform data consumed from multiple sources to conform with its definitions. Once the ingest component of the offline pipeline transforms the data to fit our ontology, a set of classifiers are then run to de-duplicate the data and make cross-source connections in order to leverage the graoh's abstraction power. For example, this stage involves establishing that a given restaurant on Foursquare, one of our data sources, is ‘the same as the restaurant in our internal account data. Finally, once alll these stages are complete, the data is stored in such a way that makes it queryable in real time with low latency. With an established graph, our next task involves leveraging it to optimize an eater’s search results. Offline, we can extensively annotate restaurants and menu items with very descriptive tags. Online, we can rewrite the eater's query in real time to optimize the quality of the returned results. We combine both approaches to guarantee high accuracy and low latency, Figure 2 Our sample ontology deserbes semantic relationships between ciferent entity types inthe graph. hips slong uber comiuber-ats-query-understanding!