Fluree

Figure 2 – The Fluree RAG Process under the covers

A recent development has been to present a natural language interface to the graph database, and this has been done in an interesting way. At present, if an enterprise wants to use a large language model (LLM) for a specific task like a customer service chatbot, they face the problem of educating the LLM about the company-specific data that is relevant, for example the customer order history. This is done via a process called retrieval augmented generation (RAG), whereby the LLM is shown the company-specific data in the form of a vector database, or possibly an existing database that supports vector queries. However, this process has a number of issues. To begin with, it may be difficult to ensure that the LLM does not have access to personally identifiable data that it should not be able to see. Another well-known problem is that LLMs do not necessarily return the answers that you expect in the way that you would see from a SQL query to a database. Instead, the LLMs are giving a probabilistic answer and may include “hallucinations” where the LLM invents plausible “facts” that are actually untrue.

Fluree places a layer between the end user and the end result, intercepting raw queries and using the ontologies within its database to provide additional context to the query. For example, Fluree can ensure that security policies are not being violated, and use the particular context of the query to ensure that the most appropriate method is used to retrieve the data needed. This might be a better-constructed LLM vector similarity search, or even generate a piece of regular SQL to satisfy the query instead of a vector search. This is a potentially very useful additional layer. By using a knowledge graph rather than a traditional relational database for RAG, the accuracy of responses is much improved, and this improved accuracy has shown up in testing by the vendor.

Companies that want to rely on high-quality data face a number of challenges that Fluree can help with. By providing extra context to data, a knowledge graph can be presented to business users and help to improve the underlying quality of corporate data. The new ability to intercept natural language queries and either enrich them or reroute them promises to get around a very common problem at the moment. Enterprises globally are keen to implement AI but are coming up against the limitations of this technology in various ways. Giving additional context to AI inquiries is an excellent idea and one that has real promise. It is early days, but Fluree may well be on to a winning idea here.

The bottom line

Fluree has shown itself to be useful in building data fabric solutions in some sophisticated enterprises. Its new capability of giving additional context to natural language inquiries addresses a very real problem that many companies are facing right now.