Personal and professional history might not repeat, but it certainly rhymes. I’m thrilled to join the team at HumanFirst, and reconnect with a team of founders I not only trust, but deeply admire.
The skill of Prompt Engineering has been touted as the ultimate skill of the future. But, will prompt engineering be around in the near future? In this article I attempt to decompose how the future LLM interface might look like…considering it will be conversational.
Personal and professional history might not repeat, but it certainly rhymes. I’m thrilled to join the team at HumanFirst, and reconnect with a team of founders I not only trust, but deeply admire.
Currently, ChatGPT is powered by the most advanced OpenAI language models. While OpenAI has made the APIs available to these models, it does not inherently manage conversation context & memory.
Traditionally one of the challenges of chatbot development frameworks, has been managing conversation memory, also referred to as conversational context.
The best way to illustrate this, is via an example conversation, as seen below. Three questions are asked by the user, the first question is a direct and explicit question.
Questions two and three are both contextually implicit questions by which context in the first question is referenced in an implicit and slightly ambiguous manner.
Question three is even more vague in implying context.
With LLM related tools like few-shot learning and summarisation, conversation memory and context can be managed easily.
Here are a few practical examples…
The current ChatGPT models are: gpt-4, gpt-3.5-turbo, gpt-4–0314 and gpt-3.5-turbo-0301. These models can be accessed via an API call with only a few lines of code.
As seen below, with only a few lines of code, you can enter a sequence of messages and the model will return a text output:
With the output:
The ChatML document submitted must contain conversational history in order to effectively maintain conversational context and manage dialog state (also referred to as memory).
By incorporating prior dialog turns, the model is then able to answer contextual questions. Hence having conversational memory.
OpenAI clearly states, that the models have no memory of previous and past requests. Hence all relevant information must be supplied via the conversation.
It is important to remember that if a conversation is too long for the model’s token limit, it must be shortened. This can be done by having a rolling log of the conversation history where only the most recent dialog turns are submitted.
But how can conversation memory be managed for manageable scaling?
The common approach to no-code Generative App development is dividing programming tasks into different components. One of those components is Conversation Memory.
For example, below are the three memory components of LangFlow.
Buffer for storing conversation memory.
Conversation summariser to memory.
Knowledge graph memory for storing conversation memory.
Below is the most basic general chatbot with memory…with the memory component allowing for ambiguous questions.
Consider the conversation below, and how contextually sensitive the two follow-up questions are.
I’m currently the Chief Evangelist @ HumanFirst. I explore and write about all things at the intersection of AI and language; ranging from LLMs, Chatbots, Voicebots, Development Frameworks, Data-Centric latent spaces and more.
Subscribe to HumanFirst Blog
Get the latest posts delivered right to your inbox
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
.svg)
.svg)
%20(42%20x%2024%20in)%20(1).png)
.png)
.png)
%20(280%20x%20208%20px)%20(4032%20x%202304%20px)%20(1).png)
