Summary

The website content outlines a framework for implementing conversational guardrails in LLM-powered applications to ensure responses remain within predefined topic boundaries.

Abstract

The article discusses the challenges of controlling conversational flow in large language model (LLM) applications, particularly the need to keep interactions within specific topic boundaries. It introduces a guardrail framework designed to guide the conversation, ensuring that the AI responds to questions within its domain expertise while redirecting or declining off-topic inquiries. The proposed solution involves a configuration-driven approach, where a bot's capabilities are clearly defined and used to direct the conversation. The framework employs vectorized topic descriptions and examples, which are searched against user queries to determine the relevance of the question. If a question falls within the bot's domain, a context-specific response is generated using the LLM; otherwise, a predefined boilerplate response is provided to guide the user back to relevant topics. The article emphasizes the importance of this framework in creating meaningful and engaging AI-user interactions without straying into unrelated subject matter.

Opinions

The author believes that LLMs are gaining significant attention for their potential applications and the value they can bring to businesses.
There is a recognized need among the author's customers for controlling the conversational flow to maintain the relevance of AI responses within a defined scope.
The author suggests that simply providing "happy path" responses is insufficient and that guardrails are necessary to manage the conversation effectively.
The author feels that AI applications should be able to indicate their capabilities and direct users accordingly, which is facilitated by a configurable flow document.
The author posits that a framework for conversational guardrails should be generalizable across various conversational applications, not just specific to one domain.
The author implies that the use of vector databases for topic similarity and context retrieval is a key component in generating relevant and specific AI responses.
The author concludes by inviting feedback and discussion on the proposed framework, indicating a collaborative approach to refining and improving conversational AI guardrails.

Building a Conversational Flow Based Guardrail Framework for Large Language Models (LLMs)

LLMs are taking every bit of the limelight (and for the right reasons). Every organization is trying to up their game and talk about applications, solutions, designs and implementation strategy on how to enable projects powered by LLMs.

Every other project is showcasing the power of prompt engineering (and for the right reasons) to define how LLMs can provide business value and business advantages to customers through their adoption.

However, one thing that some of my customers and projects are asking is how to control the conversational flow to ensure that the LLM powered applications do not become a place to ask anything and everything. Each LLM application should have its own boundary and answer questions within that boundary.

This blog is dedicated to designing one such conversational flow based guardrail framework that can be leveraged by any projects.

The Problem Statement

Imagine I have a LLM powered life sciences (can answer general medical questions) bot. The bot is smart and can discuss about three things in details (more to follow on this - but imagine that we have enough information about only 3 topics). Let us suppose that the 3 topics are — “how to take care of runny nose”, “how to take care of mental health” and “how to live a healthy life” (sometimes I surprise myself on the kind of examples I bring to the table 😀).

If I interact with the bot and ask questions around the 3 topics in general, then I am suppose to have a meaningful and engaging conversation with the bot (as it should be). This is where a lot of the application teams stop, providing the “happy path” answer where bot responds creative and personalized responses based on the context and the question.

Now let us ask the other question — what will happen when I try to ask a question to this bot around a recipe for baking a cake ? Because this is a generative AI application, most likely I will actually get a cake recipe for baking a cake !

So, in general, I feel we need the guardrails to answer 3 things -

What is off topic vs acceptable topic
Control the conversation flow by asking leading questions and directing the conversation within a boundary
Answer questions within the boundary through smart search.

The Solution

The proposal is to build a framework that can be applied to any conversational style application in general. Overall my proposal is as below

How the flow based guardrails framework work

Let us discuss this in some details with our example from above.

Initially — imagine that a person opens the application bot and greets the bot. The bot should know that it is a greeting and acknowledge the greeting with another greeting and indicate what the bot is capable of doing. This information should be part of a config flow document (shown in the diagram) that clearly articulates what the bot is capable of doing. For example, in this case the bot might say “hello to you too! I am an AI life sciences bot and I can help you with questions on runny nose, mental health and healthy living”.

Behind the scene, the framework driven by this config file should clearly indicate a list of topics the bot is capable of answering. For each topic, a brief description and a few examples should be vectorized (more on this in my other blog @ https://readmedium.com/de9b8c2a1414 ) and loaded into a setup index. The config should also have some boiler plate response and some actions that define if the answer should come from LLM or from the boiler plate code).

Once the user gets the initial greeting and get an indication of the boundary of questions he can ask(from the boiler plate response action from above), he then decides to ask a follow up question.

As the next question, the user decides to ask a question about his runny nose (example), he then submits his question to the bot and the bot then uses the config file to get an action, the action indicates that the backend system should search the vector database for the list of topics and see if the question is similar to the topics this bot supports. In this case the search will surely yield a high similarity on topic 1 which indicates that the question is well within the boundary. Next, the bot will use the response and make a call to the second vector database to get a list of actual context for this specific runny nose question and generate a response. Once the response is created, the bot will ask the config file to indicate next steps. The config should (in this case) provide an action to use the context generated and create a prompt to be passed to LLM model to answer the specific user question. The LLM in this case answers the questions (not on public data but on the context supplied) to provide a very specific answer based on internal knowledge (that comes from the vector DB here). The response goes back to the user.

Now let us take the negative scenario. Imagine once user gets his answer on the “runny nose”, he decides to test the bot and asks him of a recipe of cake.

In this case, the question goes to the backend, the backend config file identified the action to the question, the action is to perform a similarity search on this question with the topic boundary for this bot. In this case the response will indicate that the user question does not match to any of the topic. The response will trigger another lookup to the config file for next action where the config file might indicate the question to be answered by a boiler plate response mentioning that the question is not within the topic boundary and ask the user to ask a different question on the topic or suggest a follow up question to his runny nose.

Conclusion

The above information scratches the surface of the framework that I am establishing, however this lays out the end to end picture of how to design a conversational flow based guardrail framework.

As this is a niche and new area for a lot of us. I recently came across this problem statement from my customers and decided to build a framework that can be leveraged. Let me know your thoughts if you and your team are working on similar use cases or do comment about some other LLM based questions that you are asked from your customers.

In Plain English

Thank you for being a part of our community! Before you go:

Be sure to clap and follow the writer! 👏
You can find even more content at PlainEnglish.io 🚀
Sign up for our free weekly newsletter. 🗞️
Follow us on Twitter(X), LinkedIn, YouTube, and Discord.