Why model ontologies for your AI?

In this post, I will focus on the deployment of AI in companies and on a large scale. These AIs need to use a lot of data from the company’s databases, both during their training and during prompts to enrich requests (RAG: Retrieval Augmented Generation).

Since these databases and other sources such as files, archives, etc., are often heterogeneous and of varying quality, it is dangerous to connect the AIs directly to these storage areas. It is smarter to build a unified vision of all the company’s data using a powerful business model that sits in front of the heterogeneous storage areas. The AIs can then draw their data from a clean source, accompanied by security rules.

Software platforms exist for setting up this kind of system, either with a graph-oriented database approach or with the NoCode database that we regularly present in our weekly “AI by Drinkizz” Zoom sessions. But regardless of the technology used, an effort of modeling is required to achieve this unified vision of the data. It also needs to be done in a way that allows for its evolution to keep up with business changes that occur regularly. Therefore, the model must be both very clear and strict in quality management, but also well-constructed enough to accept extensions without questioning everything.

This modeling involves expertise in ontology construction, also known as the art of semantic modeling. Ontology is the art of documenting the business concepts of the company and defining their relationships as well as the rules for controlling their quality. Let’s take a closer look now.

First of all, a business concept is a key management entity for the company, such as a Client, Supplier, Invoice, Production Unit, etc. A startup has about fifteen of these, an SME more than twenty, and a large company even more. Each business concept is defined to constitute a glossary shared by the entire company. It is accompanied by a thesaurus to standardize term equivalences.

Next, the business concepts are organized into a hierarchy that describes the parent-child structures that exist between them. For example, a Client is specialized in B2B, Retail markets, etc.

Once the glossary, taxonomy, and hierarchy are in place, it is time to model the attributes of the business concepts and specify the relationships they have with each other. The semantic power of the data model greatly depends on the quality of the modeling of the relationships between business concepts. The first time you do semantic modeling, be accompanied by an expert in this discipline, at least to verify that your model is solid. You can also use an AI assistant for data modeling, but you will need to train it well before it can help you effectively (call us if you need support for this operation).

At the end of this semantic modeling, you will have built your ontologies. At this stage, it is still a static vision of unified data. A final modeling step is needed to add a more dynamic dimension. Its purpose is to control the quality of the data contained in the business concepts. These are axioms that are added to the ontology.

Here, focus on universal control rules that do not depend on organizational choices. A powerful way to formalize these business axioms is to use state machines. For example, a Product business concept could have this list of possible states: R&D, Offer Catalog, Maintenance, Out of Sale… Depending on the state of a product (instance of the Product business concept), update, delete, and usage actions are possible or not.

List of key advantages of having well-constructed ontologies:

• They allow the implementation of a unified data layer in front of your heterogeneous databases, or if you are starting from scratch, to have a very clean database that will follow your business evolution without creating chaos for data storage. This approach creates a digital twin of your IT on which you can plug your AIs both for their training and for prompt augmentation (RAG) by fetching real-time data in vectorized ontology instances.
• They provide the necessary classification for organizing knowledge, beyond data from databases. To better train your AIs, you will need to formalize your organization’s tacit knowledge, i.e., what your teams know but is not yet documented or well explained. All explicit knowledge is then loaded into the ontologies to complement structured data, thus increasing the knowledge base used by the AIs.
• During prompt execution, real-time access to ontologies allows on-the-fly enrichment of the request context, enabling the AIs to work better. This is the principle of RAG, which I have already mentioned several times in this post.

• Conversely, during the reception of the AI-generated response, access to ontologies will allow verifying the quality of the result, for example, by checking the data sources used. This significantly reduces the negative effects of hallucinations when the AI is not used in a creative context but rather for deterministic analysis.