DGI: Building an AI Knowledge Assistant for Dental & Implantology Guidelines

DGI: Building an AI Knowledge Assistant for Dental & Implantology Guidelines

Written by

Avatar of author

Kharisma Nankani

A retrieval-augmented AI knowledge assistant that helps dentists and implantologists access DGI's (Deutsche Gesellschaft für Implantologie) medical and dental guidelines through a conversational interface.

In this post:

In this post:

Section

Building an AI Knowledge Assistant for DGI (Deutsche Gesellschaft für Implantologie)

Medical and dental professionals often work with large amounts of specialised information.

Guidelines, recommendations and clinical documentation need to be available when they are needed — but finding the relevant information inside a large knowledge base can take time.

For the Deutsche Gesellschaft für Implantologie (DGI), the challenge was to make its specialised knowledge easier for dentists and implantologists across Germany to navigate.

I worked on an AI-powered knowledge assistant that uses Retrieval-Augmented Generation (RAG) to retrieve relevant information from DGI's own knowledge base and provide it through a conversational interface.

Unlike a general-purpose chatbot, the system is designed around domain-specific information and controlled access for logged-in users.

The Challenge

The goal wasn't to create another general AI chatbot.

The real problem was knowledge retrieval.

Professionals accessing DGI's platform may have a specific question about implantology, treatment approaches, recommendations or guidelines.

Traditionally, answering that question might involve searching through documents, navigating different sections of a knowledge platform, or already knowing where the relevant information is located.

The AI assistant creates another way to interact with that knowledge:

Ask a question → retrieve relevant information → generate an answer grounded in the available sources.

This makes the AI less of a standalone conversational product and more of an intelligent interface to an existing knowledge base.


Why RAG?

For a project involving specialised medical and dental information, simply asking a large language model to answer questions isn't enough.

A general-purpose model may know a lot about medicine, but that doesn't mean it knows the specific information contained in DGI's knowledge base.

This is where Retrieval-Augmented Generation (RAG) becomes useful.

Instead of relying entirely on the model's internal knowledge, the system retrieves relevant content from the organisation's own information before generating a response.

The basic flow looks like this:

User question → Semantic search → Relevant DGI content → AI generation → Answer

The model therefore has access to the information it needs at the time it generates the response.


Building the Knowledge Pipeline

One of the key parts of the project was creating the pipeline that transforms source material into information that an AI system can retrieve efficiently.

The workflow involved several stages:

Source content

↓

Ingestion & processing

↓

Chunking

↓

Embeddings

↓

Vector database

↓

Semantic retrieval

↓

AI response

I used n8n to orchestrate the workflow and Supabase with pgvector to store and retrieve the vectorised knowledge.

The source content was processed into smaller meaningful sections before being converted into embeddings.

These embeddings allow the system to compare the meaning of a user's question against the stored knowledge rather than relying only on exact keyword matches.


From Keywords to Meaning

Traditional search often depends heavily on keywords.

If a document contains the exact terminology someone searches for, it can be relatively easy to find.

But professionals don't always phrase questions using exactly the same language as the source material.

Semantic search solves part of this problem.

For example, a user might ask a question using everyday professional language while the underlying guideline uses more formal terminology.

By representing both the question and the source content as vectors, the system can identify information that is semantically relevant, even when the wording isn't identical.

This makes the knowledge base much more useful as a conversational interface.


Designed for Professional Users

An important distinction with this project is that the assistant isn't intended to be a public-facing medical chatbot.

The knowledge assistant is available to logged-in users of the DGI platform.

That changes the way the system needs to be designed.

The experience is part of a professional environment rather than a general consumer AI tool.

Access control therefore sits alongside the AI functionality:

Authentication → User access → Knowledge assistant

The AI experience is only one part of the overall system.


Grounding the AI in DGI's Knowledge

One of the biggest risks with AI systems is allowing the model to confidently generate information that isn't supported by the underlying source material.

For this project, the goal was therefore to keep the assistant grounded in the retrieved knowledge.

The RAG architecture creates a clear separation between:

The organisation's knowledge

and

The language model used to communicate it.

The model provides the conversational interface, while the retrieval layer determines which information should be brought into the conversation.

This architecture also makes the system easier to update as the underlying knowledge base evolves.


The Technical Architecture

At a high level, the system can be represented as:



n8n acts as the orchestration layer connecting the different parts of the system.

Supabase provides the database infrastructure and vector search capabilities, while the language model handles the final natural-language response.

The result is a system where each component has a clear responsibility rather than putting the entire workload on the LLM.


Why the Architecture Matters

The interesting part of this project isn't simply that it uses AI.

It's the architecture around the AI.

A useful professional knowledge assistant needs several layers working together:

Access control
Who is allowed to use the system?

Knowledge management
What information does the AI have access to?

Retrieval
Which information is relevant to the current question?

Generation
How should that information be communicated?

Orchestration
How do all these systems work together?

This is what turns a basic LLM integration into a more purposeful AI application.


Building AI Around Existing Knowledge

One of the biggest lessons from the project was that organisations don't necessarily need to create completely new information to benefit from AI.

Often, they already have valuable knowledge.

The challenge is making that knowledge accessible, searchable and usable.

RAG provides a way to put an intelligent interface on top of existing information without requiring the organisation to retrain a language model on all of its content.

For DGI, this means the AI becomes a new way of interacting with specialised knowledge that already exists within the organisation.


What I Learned

The DGI project reinforced an important principle in building AI systems:

The quality of the AI experience depends heavily on the quality of the information behind it.

A powerful language model cannot compensate for poorly structured, outdated or badly retrieved knowledge.

The engineering challenge therefore extends beyond the model itself.

It involves:

  • Structuring source information

  • Designing retrieval workflows

  • Creating useful embeddings

  • Managing metadata

  • Connecting vector search with the LLM

  • Controlling access

  • Testing retrieval quality

  • Designing the user experience around the actual use case

This is where I find AI development particularly interesting.

The most valuable systems aren't necessarily the ones with the most impressive models.

They're the ones that connect good information, good architecture and a real user need.


From Chatbot to Knowledge Interface

DGI is a good example of how I think about AI differently from a traditional chatbot project.

The conversational interface is only the visible part.

Behind it is a retrieval system designed to connect professionals with specialised information.

The result is an AI-powered knowledge interface that makes an existing body of professional knowledge easier to navigate — while keeping the experience within a controlled, logged-in environment.

For me, that's where AI becomes genuinely useful:

not replacing expertise, but making the right information easier to access when expertise needs it.

Building an AI Knowledge Assistant for DGI (Deutsche Gesellschaft für Implantologie)

Medical and dental professionals often work with large amounts of specialised information.

Guidelines, recommendations and clinical documentation need to be available when they are needed — but finding the relevant information inside a large knowledge base can take time.

For the Deutsche Gesellschaft für Implantologie (DGI), the challenge was to make its specialised knowledge easier for dentists and implantologists across Germany to navigate.

I worked on an AI-powered knowledge assistant that uses Retrieval-Augmented Generation (RAG) to retrieve relevant information from DGI's own knowledge base and provide it through a conversational interface.

Unlike a general-purpose chatbot, the system is designed around domain-specific information and controlled access for logged-in users.

The Challenge

The goal wasn't to create another general AI chatbot.

The real problem was knowledge retrieval.

Professionals accessing DGI's platform may have a specific question about implantology, treatment approaches, recommendations or guidelines.

Traditionally, answering that question might involve searching through documents, navigating different sections of a knowledge platform, or already knowing where the relevant information is located.

The AI assistant creates another way to interact with that knowledge:

Ask a question → retrieve relevant information → generate an answer grounded in the available sources.

This makes the AI less of a standalone conversational product and more of an intelligent interface to an existing knowledge base.


Why RAG?

For a project involving specialised medical and dental information, simply asking a large language model to answer questions isn't enough.

A general-purpose model may know a lot about medicine, but that doesn't mean it knows the specific information contained in DGI's knowledge base.

This is where Retrieval-Augmented Generation (RAG) becomes useful.

Instead of relying entirely on the model's internal knowledge, the system retrieves relevant content from the organisation's own information before generating a response.

The basic flow looks like this:

User question → Semantic search → Relevant DGI content → AI generation → Answer

The model therefore has access to the information it needs at the time it generates the response.


Building the Knowledge Pipeline

One of the key parts of the project was creating the pipeline that transforms source material into information that an AI system can retrieve efficiently.

The workflow involved several stages:

Source content

↓

Ingestion & processing

↓

Chunking

↓

Embeddings

↓

Vector database

↓

Semantic retrieval

↓

AI response

I used n8n to orchestrate the workflow and Supabase with pgvector to store and retrieve the vectorised knowledge.

The source content was processed into smaller meaningful sections before being converted into embeddings.

These embeddings allow the system to compare the meaning of a user's question against the stored knowledge rather than relying only on exact keyword matches.


From Keywords to Meaning

Traditional search often depends heavily on keywords.

If a document contains the exact terminology someone searches for, it can be relatively easy to find.

But professionals don't always phrase questions using exactly the same language as the source material.

Semantic search solves part of this problem.

For example, a user might ask a question using everyday professional language while the underlying guideline uses more formal terminology.

By representing both the question and the source content as vectors, the system can identify information that is semantically relevant, even when the wording isn't identical.

This makes the knowledge base much more useful as a conversational interface.


Designed for Professional Users

An important distinction with this project is that the assistant isn't intended to be a public-facing medical chatbot.

The knowledge assistant is available to logged-in users of the DGI platform.

That changes the way the system needs to be designed.

The experience is part of a professional environment rather than a general consumer AI tool.

Access control therefore sits alongside the AI functionality:

Authentication → User access → Knowledge assistant

The AI experience is only one part of the overall system.


Grounding the AI in DGI's Knowledge

One of the biggest risks with AI systems is allowing the model to confidently generate information that isn't supported by the underlying source material.

For this project, the goal was therefore to keep the assistant grounded in the retrieved knowledge.

The RAG architecture creates a clear separation between:

The organisation's knowledge

and

The language model used to communicate it.

The model provides the conversational interface, while the retrieval layer determines which information should be brought into the conversation.

This architecture also makes the system easier to update as the underlying knowledge base evolves.


The Technical Architecture

At a high level, the system can be represented as:



n8n acts as the orchestration layer connecting the different parts of the system.

Supabase provides the database infrastructure and vector search capabilities, while the language model handles the final natural-language response.

The result is a system where each component has a clear responsibility rather than putting the entire workload on the LLM.


Why the Architecture Matters

The interesting part of this project isn't simply that it uses AI.

It's the architecture around the AI.

A useful professional knowledge assistant needs several layers working together:

Access control
Who is allowed to use the system?

Knowledge management
What information does the AI have access to?

Retrieval
Which information is relevant to the current question?

Generation
How should that information be communicated?

Orchestration
How do all these systems work together?

This is what turns a basic LLM integration into a more purposeful AI application.


Building AI Around Existing Knowledge

One of the biggest lessons from the project was that organisations don't necessarily need to create completely new information to benefit from AI.

Often, they already have valuable knowledge.

The challenge is making that knowledge accessible, searchable and usable.

RAG provides a way to put an intelligent interface on top of existing information without requiring the organisation to retrain a language model on all of its content.

For DGI, this means the AI becomes a new way of interacting with specialised knowledge that already exists within the organisation.


What I Learned

The DGI project reinforced an important principle in building AI systems:

The quality of the AI experience depends heavily on the quality of the information behind it.

A powerful language model cannot compensate for poorly structured, outdated or badly retrieved knowledge.

The engineering challenge therefore extends beyond the model itself.

It involves:

  • Structuring source information

  • Designing retrieval workflows

  • Creating useful embeddings

  • Managing metadata

  • Connecting vector search with the LLM

  • Controlling access

  • Testing retrieval quality

  • Designing the user experience around the actual use case

This is where I find AI development particularly interesting.

The most valuable systems aren't necessarily the ones with the most impressive models.

They're the ones that connect good information, good architecture and a real user need.


From Chatbot to Knowledge Interface

DGI is a good example of how I think about AI differently from a traditional chatbot project.

The conversational interface is only the visible part.

Behind it is a retrieval system designed to connect professionals with specialised information.

The result is an AI-powered knowledge interface that makes an existing body of professional knowledge easier to navigate — while keeping the experience within a controlled, logged-in environment.

For me, that's where AI becomes genuinely useful:

not replacing expertise, but making the right information easier to access when expertise needs it.

Building an AI Knowledge Assistant for DGI (Deutsche Gesellschaft für Implantologie)

Medical and dental professionals often work with large amounts of specialised information.

Guidelines, recommendations and clinical documentation need to be available when they are needed — but finding the relevant information inside a large knowledge base can take time.

For the Deutsche Gesellschaft für Implantologie (DGI), the challenge was to make its specialised knowledge easier for dentists and implantologists across Germany to navigate.

I worked on an AI-powered knowledge assistant that uses Retrieval-Augmented Generation (RAG) to retrieve relevant information from DGI's own knowledge base and provide it through a conversational interface.

Unlike a general-purpose chatbot, the system is designed around domain-specific information and controlled access for logged-in users.

The Challenge

The goal wasn't to create another general AI chatbot.

The real problem was knowledge retrieval.

Professionals accessing DGI's platform may have a specific question about implantology, treatment approaches, recommendations or guidelines.

Traditionally, answering that question might involve searching through documents, navigating different sections of a knowledge platform, or already knowing where the relevant information is located.

The AI assistant creates another way to interact with that knowledge:

Ask a question → retrieve relevant information → generate an answer grounded in the available sources.

This makes the AI less of a standalone conversational product and more of an intelligent interface to an existing knowledge base.


Why RAG?

For a project involving specialised medical and dental information, simply asking a large language model to answer questions isn't enough.

A general-purpose model may know a lot about medicine, but that doesn't mean it knows the specific information contained in DGI's knowledge base.

This is where Retrieval-Augmented Generation (RAG) becomes useful.

Instead of relying entirely on the model's internal knowledge, the system retrieves relevant content from the organisation's own information before generating a response.

The basic flow looks like this:

User question → Semantic search → Relevant DGI content → AI generation → Answer

The model therefore has access to the information it needs at the time it generates the response.


Building the Knowledge Pipeline

One of the key parts of the project was creating the pipeline that transforms source material into information that an AI system can retrieve efficiently.

The workflow involved several stages:

Source content

↓

Ingestion & processing

↓

Chunking

↓

Embeddings

↓

Vector database

↓

Semantic retrieval

↓

AI response

I used n8n to orchestrate the workflow and Supabase with pgvector to store and retrieve the vectorised knowledge.

The source content was processed into smaller meaningful sections before being converted into embeddings.

These embeddings allow the system to compare the meaning of a user's question against the stored knowledge rather than relying only on exact keyword matches.


From Keywords to Meaning

Traditional search often depends heavily on keywords.

If a document contains the exact terminology someone searches for, it can be relatively easy to find.

But professionals don't always phrase questions using exactly the same language as the source material.

Semantic search solves part of this problem.

For example, a user might ask a question using everyday professional language while the underlying guideline uses more formal terminology.

By representing both the question and the source content as vectors, the system can identify information that is semantically relevant, even when the wording isn't identical.

This makes the knowledge base much more useful as a conversational interface.


Designed for Professional Users

An important distinction with this project is that the assistant isn't intended to be a public-facing medical chatbot.

The knowledge assistant is available to logged-in users of the DGI platform.

That changes the way the system needs to be designed.

The experience is part of a professional environment rather than a general consumer AI tool.

Access control therefore sits alongside the AI functionality:

Authentication → User access → Knowledge assistant

The AI experience is only one part of the overall system.


Grounding the AI in DGI's Knowledge

One of the biggest risks with AI systems is allowing the model to confidently generate information that isn't supported by the underlying source material.

For this project, the goal was therefore to keep the assistant grounded in the retrieved knowledge.

The RAG architecture creates a clear separation between:

The organisation's knowledge

and

The language model used to communicate it.

The model provides the conversational interface, while the retrieval layer determines which information should be brought into the conversation.

This architecture also makes the system easier to update as the underlying knowledge base evolves.


The Technical Architecture

At a high level, the system can be represented as:



n8n acts as the orchestration layer connecting the different parts of the system.

Supabase provides the database infrastructure and vector search capabilities, while the language model handles the final natural-language response.

The result is a system where each component has a clear responsibility rather than putting the entire workload on the LLM.


Why the Architecture Matters

The interesting part of this project isn't simply that it uses AI.

It's the architecture around the AI.

A useful professional knowledge assistant needs several layers working together:

Access control
Who is allowed to use the system?

Knowledge management
What information does the AI have access to?

Retrieval
Which information is relevant to the current question?

Generation
How should that information be communicated?

Orchestration
How do all these systems work together?

This is what turns a basic LLM integration into a more purposeful AI application.


Building AI Around Existing Knowledge

One of the biggest lessons from the project was that organisations don't necessarily need to create completely new information to benefit from AI.

Often, they already have valuable knowledge.

The challenge is making that knowledge accessible, searchable and usable.

RAG provides a way to put an intelligent interface on top of existing information without requiring the organisation to retrain a language model on all of its content.

For DGI, this means the AI becomes a new way of interacting with specialised knowledge that already exists within the organisation.


What I Learned

The DGI project reinforced an important principle in building AI systems:

The quality of the AI experience depends heavily on the quality of the information behind it.

A powerful language model cannot compensate for poorly structured, outdated or badly retrieved knowledge.

The engineering challenge therefore extends beyond the model itself.

It involves:

  • Structuring source information

  • Designing retrieval workflows

  • Creating useful embeddings

  • Managing metadata

  • Connecting vector search with the LLM

  • Controlling access

  • Testing retrieval quality

  • Designing the user experience around the actual use case

This is where I find AI development particularly interesting.

The most valuable systems aren't necessarily the ones with the most impressive models.

They're the ones that connect good information, good architecture and a real user need.


From Chatbot to Knowledge Interface

DGI is a good example of how I think about AI differently from a traditional chatbot project.

The conversational interface is only the visible part.

Behind it is a retrieval system designed to connect professionals with specialised information.

The result is an AI-powered knowledge interface that makes an existing body of professional knowledge easier to navigate — while keeping the experience within a controlled, logged-in environment.

For me, that's where AI becomes genuinely useful:

not replacing expertise, but making the right information easier to access when expertise needs it.

Building smarter digital experiences.

I combine AI, automation and web development to turn ideas into useful digital products.