Quepy

Editor's Notes

• #2: Hello everyone, my name is Daniel Moisset. I work at Machinalis, a company based in Argentina which builds data processing solutions for other companies. I'm not a native English speaker, so please just wave a bit if I'm not speaking clearly or just not making any sense. The topic I want to introduce today is about the use of natural language to query databases and a tool that implements a possible approach to solve this Issue Let me start by trying to show you why this problem is relevant. .
• #3: The problem I'll discuss today is not about how to get your data. If you're here, chances are you have more data that you can handle. The big problem today is to put to work all the data that comes from different sources and is piling up in some database. And of course, the first step at least of that problem is getting the data you want, that is, making "queries". Of course you'll want to do more than queries later, but selecting the information you want is typically the first step
• #4: A typical approach for large bodies of text-based data is the “keyword” based approach. The basic idea is that the user provides a list of keywords, and the items that contain those keywords are retrieved. There are a lot of well known tricks to improve this, like detecting the relevance of documents with respect to user keywords, doing some preprocessing of the input and the index so I can find documents without an exact keyword match but a similar word instead, etc. This approach has proven very successful in many different contexts, with Google as a leading example of a large database that probably all of us query frequently using keyword-based queries, and many tools to build search bars into your software. It works so well that you might wonder if there's any significant improvement to make by trying a different approach.
• #5: Keyword-based lookups are really good when you know what you're looking for, typically the name of the entity you're interested in, or some entity that is uniquely related to that other entity. It's very simple to get information about Albert Einstein, or figuring out who proposed the Theory of Relativity even if I don't remember Albert Einstein's name.
• #6: However, it's not easy to Google "What's the name of that place in California with a lot of movie studios?" "The one with the big white sign in the hill?". None of the keywords I used to formulate that question are very good, and other similar formulations will not help us. It's not a problem of having the data, even if I have a database containing records about movie studios and their locations, but a problem of how you interact with the database. Another problem of keyword-based lookups is that it is heavily dependent on data which is mainly textual. It works fine for the web, but if I have a database with flight schedules for many airlines, a keyword based search will provide me with a very limited interface for making queries. Even with a database with a lot of text, like the schedule for the conference, it's not easy to answer questions like "Which PyData speakers are affiliated with the sponsors" (without doing it manually)
• #7: The solution we have for this problem, which may be summarized as "finding data by the stuff related to it" are query languages. We have many of those, depending on how we want to structure our data. All of these allow us to write very accurate and very complicated queries. And by “us” I mean the people in this room, which are developers and data scientists. Which is the weakness of this approach: it's not an interface that you can provide to end-users. There's a lot of data that needs to be made available to people who can't or won't learn a complex language to access the information. Not because they're stupid, but because their field of expertise is another one.
• #8: That leaves us with a need to query structured, possibly non textual, related information in a way that does not require much expertise to the person making the queries. And a straightforward way to solve that need, is allowing the data to be queried in the language that the user already knows. Which brings us to the motivation for this talk. Natural language is getting as a popular way to make queries and/or enter commands. It provides a very user friendly experience, even when most current tools are somewhat limited in the coverage they can provide. By “coverage” here I mean how many of the relevant questions are actually understood by the computer. Currently, successful applications like the ones I show here have a guide to the user describing which forms of questions are "valid"
• #9: After this introduction and the motivation to the problem, let me outline where I'm trying to get to during this talk: Some very smart people who work with me studied different approaches to a solution and came up with a tool called Quepy which implements that approach. Of course it's not the only possible approach, but it has several nice properties that are valuable to us in an industrial context. I'll describe the approach in general and get to a quick overview on how to code a simple quepy app. Then I'll discuss what we most like about quepy, and the limits to the scope of the problem it solves.
• #10: Just in case you're eager to see the code instead of listening to me, all of it is available and online, so I'll leave this slide for 10 seconds so you can get a picture, and then move on.
• #11: At it's core, the quepy approach is not unlike a compiler. The input is a string with a question, which is sent through a parser that builds a data structure, called an "intermediate representation". That representation is then converted to a database query, which is the output from quepy. The parsing is guided by rules provided by the application writer, which describes what kind of questions are valid.
• #12: The conversion is guided by some declarative information about the structure of the database that the application writer must define. We call this definition the "DSL", for Domain Specific Language. As you might have noted from this description, what we built is not an universal solution that you can throw over your database, but something that requires programming customization, both regarding on how to interact with the user and how to interact with your database.
• #13: Let's take a deeper look at the parser. The first step of the parser provided by Quepy is splitting the text into parts, a process also known as tokenization. Once this is done you have a sequence of word objects, containing information on each word: the token, which is the original word as appears in the text, the lemma, which is the root word for the token (the base verb "speak" for a wordlike "speaking"), and a part of speech tag, which indicates if the word is a noun, an adjective, a verb, etc. This list of words is then matched against a set of question templates. Each question template defines a pattern, which is something that looks like a regular expression, where patterns can describe property matches over the token, lemma, and/or part of speech.
• #14: Let's assume a valid match on the question template. In that case, the question template provides a little piece of code that builds the intermediate representation. The intermediate representation of a query is a small graph, where vertices are entities in the database, edges are relations between entities, and both vertices and edges can be labeled or left open. There's one special vertex called the "head" which is always open, that indicates what is the value for the "answer". This is an abstract, backend independent representation of the query, although is thought mainly to use with knowledge databases, which usually have this graph structure and allow finding matching subgraphs. Quepy provides a way to build this trees from python code in a way that's quite more natural than just describing the structure top down. Trees are built by composing tree parts that have some meaningful semantics on your domain. Those components, along with the mapping of those semantics to your database schema form what we call the DSL
• #15: From the internal representation tree, and the DSL information it is possibleto automatically build a query string that can be sent to your database. At this time, we have built query generators for SPARQL, which is the defacto standard for knowledge databases, and MQL, the Metaweb Query Language (used by Google's Freebase). It might be possible to build custom generators for other languages, or use some kind of adapter (I know there are SPARQL endpoints that you can put in front of a SQL database for example). The DSL information needed here is somewhat schema specific but is very simple to define, in a declarative way.
• #16: Let me show you some code examples, making queries on freebase with a couple of sample templates questions. We want to answer "What are bananas?" and "In which movies did Harrison Ford appear". We will be doing this on Freebase; but don't worry, there's no need for you to know the Freebase schema to understand this talk. We'll cover the information we need as we go. I'm going to show you some complete code, but this is not a tutorial so I'm not going to go over line by line explaining what everything does. The code I'm showing has the purpose of displaying what are the different parts that you'll need to put together and how much (or how little) work is needed to build each.
• #17: To build this example, the easiest way is to start with the DSL. We'll start defining some simple concepts that look naturally related to the queries we want to make. Let's take a look at the `DefinitionOf` class. What we're saying here is how to get the definition of something. In freebase, entities are related to their definitions by the "slash common slash topic slash description" attribute (this is why we say that this is a `FixedRelation`; in freebase, attributes are also represented as relations). The "reverse equals true" indicates that we actually fix the left side of the relation to a known value, and want to learn about the right side. Without it, this would be the opposite query, give me an object given its definition.
• #18: This is all the DSL we need to answer "What are bananas?". The other query we wanted to make is quite more complex. Our database has movies, where each movie can have many related entities called "performances". Each performance relates to an actor, a character, etc. So we define some basic relations to identify the type of some entities using `FixedType`. `IsMovie` describe entities having freebase type "slash film slash film", and `IsPerformance` helps us recognizing these "performance" objects. To link both types of entities, the `PerformanceOfActor` queries which performances have a given actor and `HasPerformance` allows us to query which movie has a given performance. At last, in freebase movies are complex objects, but when we show a result to the user we want to show him a movie name so `NameOf` gets the "slash type slash object slash name" attribute of a movie, which is the movie title.
• #19: The intermediate representation of queries is built on instances of these objects. For example, given an actor “a”, this expression gives the movies with “a” (slide). Note that the operations on the bottom are abstract operations between queries which build a larger query, none of this is touching the database but just building a tree.
• #20: Let's now see how to code the parser for the queries mentioned before. For each kind of question we can build a "question template". The first thing that a question template specifies is how to match the questions. The matching has to be flexible enough to capture variants of the question like "what is X", "what are X", "what is an X", "what is X?" which you can see we write on the regex here: We have a "what" like word, followed by some form of the verb "to be", optionally followed by a "determiner" which is a word like "a", "an" the", followed by a thing which is what we want to look up, and followed by a question mark. Note that I said "a thing" without being too explicit on what that means. Quepy allows you to define "particles", which mean pieces of the question that you want to capture and that follow a particular pattern.
• #21: Note that at the bottom I have defined what a Thing is, the definition consisting also in one regular expression but also an intermediate representation for it. In this case, a thing is an optional adjective followed by one or more nouns. The semantics of a thing are given by the interpret method, where HasKeyword is a quepy builtin with essentially the semantics of "the object with this primary key". It's shown in the slides as a dashed line. Our question template regex refers to Thing(), so in its interpret method it will have access to the already built graph for the matched thing. So if we ask "What is a banana?", you'll end up with a valid match that builds the graph on the right, which corresponds to the appropiate query.
• #22: Let's work on the more complex example. The first thing we'll require is some additional DSL to write the "Actor" particle. In freebase, there's no actor type, but there's a "person type" and then an actor profession. That allows us to define "IsPerson" (that is objects with the person type) and "IsActor" (that is objects with the actor profession)
• #23: This allows us to define the Actor particle, which matches a sequence of nouns, and represent an object that is a person, works as an actor, and has as identifier the name in the match.
• #24: The regex for this questions is more complex because we allow several different forms like the ones shown at the bottom. We allow several synonym verbs to be used like star vs act vs appear. We also allow synonyms like film and movie. Note that it's more clear to write this by defining intermediate regular expressions, but no Particle definitions is needed if you don't want to capture the word used. There are possibly more ways to ask this question, but once you figure those out it's pretty easy to add those to the pattern. The pattern you see here is a simplified version of the pattern you'll find on the demo we have in the github repo, but I simplified it to make it shorter to read.
• #25: Once you've captured the actor, you just need to define, using the DSL, how to answer the query. Note that the definition here is very readable: we find performance objects referring to the matched actor, then we find movies with that performance, and then we find the names of those movies. Again, I described this sequentially, but you're actually describing declaratively how to build a query
• #26: Quepy also provide some tools to help you with their boilerplate, which are not very interesting to describe but I just wanted you to know that they are there. There's the concept of a quepy app which is a python module where you fill out the DSL, question templates, settings like whether you want sparql or mql, etc. Once you have that you can import that python module with quepy dot install and get the query for a natural language question ready to send to your database.
• #27: As you have seen, the approach we've used for the problem is very simple, but it has some good properties I'd like to highlight. The first one, that is very important for us as a company that needs to build products based on this tool, is that you can add effort incrementally and get results that benefit the application, so it's very low risk. This is different from machine learning or statistical approaches where you can use a lot of project time building a model and you might end up hitting gold, or you might end up with something that adds 0 visible results to a product. So, as much as we love machine learning where I work, we refrained ourselves from using it, getting something that''s not state-of-the-art in terms of coverage, but it is a very safe approach. Which is great value when interacting with customers
• #28: Other good part about this is that extending or improving requires work that can be done by a developer who doesn't need a strong linguistic specialization. So it's easy to get a large team working on improving an application. And many people can work at the same time, because question templates are really modular and not an opaque construct as machine learning models. This approach works well in domain specific databases, where there's a limited amount of relationships relevant within the data. For very general databases like freebase and dbpedia, if you want to answer general questions, you will find out that users will start making up questions that fal outside your question templates.
• #29: And that's also one of the weaknesses of this. If you have a general database, you'll have an explosion in the amount of relevant queries and templates, which starts to produce problems between contradicting rules. Note that the limit here is not the amount of entities in your dataset, but the amount of relationships between them. The way this idea works also makes a bit hard if you want to integrate computation or deduction. The latter can be partly solved by using knowledge databases that have some deduction builtin, and apply that when they get a query so it's something that you can work around
• #30: Something that's a limit of the implementation, but could be improved is the performance of the conversion. What we have is something that works for us in contexts where we don't have many queries in a short time, but would need some improvements if you want to provide a service available to a wide public. The last point that can be a limitation is the need of a structured database, which is something one doesn't always have access to. We actually built quepy as a component on a larger project, but we're also working on the other side of this problem with a tool called iepy,
• #32: So that's all I have. I'll take a few questions and of course you can get in touch in me later today or online for more information about this and other related work. Thanks for listening, and thenks to the people organizing this great conference.