Imagine if the only language you needed to talk to your database was English? No SQL. No NoSQL. No tables. Just the information you care about at the tip of your tongue. As natural as asking someone else…
At Aiqudo, we’re building a knowledge retrieval system to do exactly that, all while being personalized to your own domain or industry. (e.g., healthcare, finance, etc…). Take a nurse trying to look up a patient’s medications. Instead of having to manually look through a database, all it takes is a voice command, “Show me medication for Milo”, and they’d receive the appropriate information as shown in Figure 1 that could be displayed as well as spoken back, hands-free, even as the nurse is on-the-go during her busy day.
Figure 1: Structured Healthcare Query
Voice is IN, SQL is OUT!
See for yourself …
Tradeoffs: Full power vs Privacy?
The idea of having a natural language interface for a database may not be new, but it’s far from being a fully solved problem. Some solutions are built on the assumption they can directly interact with the database, and therefore, have full access to your data. The reality is that many companies don’t trust third parties with their most sensitive information. We believe organizations shouldn’t have to make these compromises, which is why designing a privacy-conscious solution was one of our top priorities.
With that in mind, tradeoffs are bound to occur based on whether a partner is willing to share the data, or wants to keep some of the data private. Our approach provides solutions for both options. Not having access to the data can limit the complexity of commands that can be asked with reasonable accuracy. An example of a complex command is “Show me who the insurers are for Tomas Sauer’s patients,” which requires multiple logical jumps: from Dr. Tomas Sauer, to his patients, then to their insurers. This is a multi-hop query that allows you to navigate indirect connections within your data. On the other hand, not having access to your data can still produce a highly performant product. With the use of a custom schema of your database, we are still able to produce a system that works smoothly with basic commands such as aggregation commands and entity-attribute lookup.
Using Schema to understand structured queries
The core of the system is a semantic parser personalized to your database using a schema-based approach. The job of a semantic parser is to transform natural language commands into a machine-interpretable representation, which in our case is a fully formed database query. Unfortunately, databases aren’t very friendly when you don’t speak their language. By language, I’m talking about the structure or schema of your database. What types of entities exist? What are the properties (or attributes) that relate to these entities? What are synonyms for these entities and attributes? Let’s say we have an entity called “patient”. We want to know if it has data attributes like “medications”, “doctors”, and “birthdate” associated with it. Finally, it is very useful to support synonyms you want linked to the attributes, like “age” to “birthdate”. This is the type of information that’s required to interact with your database natural voice commands, and without ever having to modify it. We don’t really care about any specific patient named Milo, or how he’s prescribed 325mg of Acetaminophen. All we care about is the schema, i.e., the knowledge that the patients exist in your database and that medications are a property of a patient.
Figure 2: Example Schema – Entities, Attributes and Synonyms
Processing a command: Voice to Action
Figure 3: Knowledge Retrieval System – Structured Query Flow
So where does the schema fit into our knowledge retrieval system? Going back to the semantic parser mentioned earlier, we can break the processing phase down to four parts:
- Domain Classification: The first part is to classify the domain of a user query. If you’re working with multiple schemas, this will help narrow down the domain for a given query (ex. healthcare, banking, etc.)
- Keyword and Policy Extraction: Keyword extraction is where we identify potential references to an entity or attribute in that text you input. Policy Extraction refers to the creation of entity-attribute mappings that define the order in which these terms are processed. For example, with “What’s the phone number of Milo’s doctor?”, we’re working with two different attributes “phone number” and “doctor”. Are we looking for Milo’s phone number or Milo’s doctor’s phone number? Getting this order right is critical. The name “policy” comes from the state-action policies in reinforcement learning which share similarities.
- Schema Mapping: At this point we have some idea of what knowledge/information you want returned, but most likely, a database won’t have any idea how to process that information. If you ask for a “doctor” when a database labels it “provider“, then we’re at a dead end. Lucky for us, we have that schema you gave us earlier and this won’t be an issue. We’ll know that “doctor” can be mapped to “provider” based on the similarity in meaning. The synonyms you provide help with this similarity computation, but similarity is not exclusive to the synonyms provided. Think of them as helpful hints to us that help clarify what a given entity or property means, optional but extremely useful. Depending on the domain we’re working with, synonyms may not need to be provided manually, and could be automatically generated.
- Structured Query Translation: Finally, we’ve accumulated all the information we need, and we move to the last phase, translating the command into a form your database understands, whether its SQL, Cypher, or some other structured database language. If you prefer to keep your data private, this structured query is what you’d be provided to execute on your own database (using your own credentials, thus maintaining data privacy). In the event you share your data, you’ll get full access to our Actionable Knowledge answers service that includes the target data as well as downstream actions that connect your data to your personalized apps and services. For more information on Actionable Knowledge, check out this blog post
Getting the information you need from your database doesn’t need to be a difficult task if you or your coworker have no idea how to write structured queries. Let us help you make their lives easier by making your data accessible in a language everyone knows.
Kenny Kang, Sunil Patil and Mark Maagdenberg