In this paper, we present preliminary work into combining formal models of dialogue and large language models, before going on to discuss how this provides a foundation for similar approaches involving computational models of argument. First, we address the twin issues of how a formal dialogue game can usefully regulate dialogical utterances generated by an LLM during an extended, goal-oriented conversation, and conversely, how LLMs can close the human-level language generation gap associated with formal dialogue games. We then proceed to identify how our solution to these issues can underpin future work towards using computational argumentation to provide reasoning-like capabilities to LLMs, and using LLMs for tasks such as searching and summarisation of analysed argument data.
Research into dialogue games originated in a variety of goal oriented studies; whether to explain proof
procedures [
Various tools and platforms have been developed to support computational implementations of
dialogue games, and their subsequent execution to be used in inter-agent communication. The Dialogue
Game Description Language (DGDL) is a domain-specific language for describing dialogue games [
By contrast, Large Language Models (LLMs) provide a less structured approach to conversational
interaction. Given a prompt, they will predict the best response to make. Prompt engineering is the
process of designing and structuring prompts towards more efective results. This leverages an LLMs
ability for in-context learning [
The diferences between dialogue games and LLMs are therefore quite clear: the former provide a structured account of how a multi-party, goal-oriented conversation should proceed, without any consideration as to the precise content of each move. LLMs, on the other hand, are adept at generating natural language text in response to arbitrary prompts, without any consideration as to “legal” dialogical (conversational) flow. These diferences, however, present opportunities for each to enhance and support the capabilities of the other. Combining the rigid dialectical structures provided by dialogue games, with the rich generative capabilities of LLMs will simultaneously address the human-level language gap associated with the former, and the lack of useful regulation of utterances associated with the latter.
The PrEFACE (Prompt Engineering for Argumentative Conversational Exchanges) library is a tool for closing the loop between Formal Dialogues Games and Large Language Models. Figure 1 illustrates PrEFACE schematically from an Input/Output perspective. PrEFACE is designed to sit between an LLM and an agent such that the agent decides what kind of utterances to make, based upon the current dialogical context, and makes a request to PrEFACE, supplying the requisite dialogue context request structure. PrEFACE uses this structure to generate a prompt which is then provided to the LLM. The LLM generates a response, which is returned to PrEFACE. The response is then returned to the agent alongside additional metadata. The following sub-sections describe each stage of the process in more detail.
The Dialogical Context Request Structure (DCRS) is the primary means by which PrEFACE is directed to generate prompts. A completed DCRS is a JSON1 document that describes the current dialogical context along with the associated utterance that it is requested for the LLM to generate. The DCRS is shown in Figure 2 and corresponds to stage 1 of Figure 1.
LLM API
PrEFACE builds on the Dialogue Game Description Language (DGDL) [
The DCRS is an object comprising five blocks, including metadata, history, topic, response, and knowledge. A completed DCRS object, in JSON format, is supplied to PrEFACE to initiate the prompt generation process.
The first block, metadata, is necessary to positively identify an instance of the DCRS so that it can { "metadata": { "name": "dcrs", "version": "1.0" }, "history": { "utterances": [ { "index": "0", "speaker": "Alice", "move_name": "assert", "content": "We should take climate
change seriously" ]
} }, "topic": { "description": "Climate change is something
to be taken seriously", "stance": "PRO" }, "response": { "move_name": "agreeWithReason", "scaffold": "We should take climate change
seriously because $p$", "opener": "I agree because $p$", "requirements": [],
"effects": [] }, "knowledge": { "type": "", "content": [] } be verified against the correct version of the DCRS JSON schema. This block is mandatory but after schema verification, plays no further part in prompt generation.
The second block, history, provides a list of utterance objects that correspond to prior interactions during the dialogue that are relevant to the utterance to be generated. Each utterance object comprises an index, speaker, move_name, and content. The index key is negatively indexed from the current utterance, the one being generated, e.g. the immediate previous utterance was -1, the one before that was -2, etc. Under most circumstances, an utterance will be generated to respond to the last utterance of another participant to the dialogue. In a small number of cases, two or more previous utterances might be required in order to provide additional context for generation of the target utterance, for example, to give the context of a micro-exchange within the dialogue, e.g. a Question-Answer-Challenge complex. A third scenario occurs when backtracking occurs within the dialogue, returning to address an utterance that had previously been made within the dialogue and was perhaps insuficiently resolved at that earlier time-point. Speaker refers to the dialogue participant that uttered this content. "self" is used to indicate that an utterance was communicated by the current speaker who is generating the PrEFACE utterance. Speaker identification is required to diferentiate between the current speaker, the participant to whom they are responding directly, i.e. to a question directed from another participant towards the current speaker, and also to diferentiate any other participants in the dialogue who might have previously participated in the current micro-dialogue. For example, speakers A, B, and C where speaker A poses a question, speaker B (self) answers it, and speaker C then challenges speaker B"s answer, leading to self making a defence oriented towards speaker C but directly related to the originating question from speaker A. The move_name key refers to the DGDL move_name label, used to distinguish between available moves. Finally content refers to the propositional content of the move, expressed as a string.
The response block is used to specify the kind of utterance the agent requires the LLM to generate.
For any given move within a DGDL game description there may be a range of either prescribed or
permitted responses which together constitute the set of legal moves. PrEFACE is designed to handle
one move at a time, so an agent must process the legal moves list one element at a time, passing in the
specific move type that must be generated. This way PrEFACE is focused upon engineering a single
prompt per dialogue context and where there are legal moves that could be generated, but which fall
outside of the agents strategy, resources are not wasted. Responses comprise a move_name, scafold,
opener, requirements, and efects. The move_name is a string describing the required move which
would usually constitute a DGDL move_name or a speech act label. The scafold is a string template
that defines the form of the required move, for example. “It is not the case that X because Y”, where
X and Y are parameters that must be filled when generating an utterance. Not all dialogue games
specify a scafold for their moves however. More common is the opener, as found in the Ravenscroft’s
Critical Reasoning Game (CRG)[
The Topic block is used to communicate an overall topic for the dialogue and stance regarding that topic, to the LLM. The topic is a string description and the stance is a single string from the set of {“support” | “neutral” | “oppose” }.
Finally, the knowledge block is used to specify a subset of the agent’s domain knowledge that can assist the LLM in generating higher quality utterances. The DCRS uses information, e.g. descriptions of moves and knowledge base (KB) contents, to provide context that is both relevant, only the move sequence that needs to be responded to is supplied, and eficient, only the subset of knowledge that the agent deems relevant to this exchange is used in the subsequent prompt generation. This means that the calling agent, the one providing the DCRS, must decide which knowledge is relevant to supply, and which locution to request in response, from the space of legal moves as defined by the dialogue game. Where there are multiple possible responses that the agent might make, then the agent must make multiple requests via PrEFACE.
Whilst an LLM encodes a huge amount of information, this is generic, and often conflicting, information, due to the wide ranging nature of the training sets used to create the model. In contrast, You are assisting a user in a dialogue on the topic of: {topic.description}. Their stance is: {topic.stance}.
Your job is to find a value for $response consistent with $knowledgebase. Use $context to help but don’t repeat anything contained within it $knowledgebase = [{knowledge.content}]} $context = [{history.utterance}]}
Return only a response without any extra text an intelligent agent likely has a KB that is both coherent and specific to its use case. The knowledge block is used, optionally, to supply suficient, specific, knowledge to the LLM to enable the prompt to tune the LLMs’s response. Conversely, there are two cases in which an agent might opt to not supply a knowledge block to PrEFACE. The first is when considering the minimal case for generating an utterance using a DGDL fragment containing an opener and a stance and the second is when the relevant knowledge within an agent’s KB has been fully explored, but the agent is not yet ready to capitulate the dialogue, in this case the LLM might return a serendipitously useful utterance that enables the dialogue to continue based upon the generalised knowledge encoded in the LLM.
Given a DCRS document, PrEFACE uses the attributes to generate a suitable prompt that will, at least in principle, return an appropriate response to be used as content for the dialogue move. The primary basis of this prompt is the response.scafold field, with the LLM instructed to find a value for the missing parameter(s), however other attributes also play a role in ensuring a relevant response.
In Section 3.1, we describe how the DCRS contains history and knowledge blocks. The content of these are provided as context to the LLM, along with instructions that define the role the LLM should fulfil. Our approach to crafting this context is based on OpenAI’s Assistants API 2. An Assistant is designed to follow specific instructions and make use of provided contextual information in responding to user queries.
The structure of the context has been designed to encode 1) the topic and stand; 2) the specific task and associated constraints; 3) the knowledge and history provided as part of the DCRS; and 4) a specific instruction to provide only the response without extraneous text. An example of this structure is shown in Figure 3.
The prompt itself is then based on the value provided in response.scafold . This scafold, defined by the game developer alongside the DGDL specification, provides a natural language template for what form the content should take in fulfilling the move. As an example, the scafolding for an argue move may be “$p because $q”, where $p is a variable that will be instantiated with some previous claim, and $q is a variable that will ultimately be sourced from the LLM. Section 3.3 provides worked example showing how the scafold becomes a concrete prompt.
A request to PrEFACE consists of six steps, from the point at which the dialogue machinery indicates that the agent has available moves, through to those moves being instantiated with propositional content. Here we provide a worked example of the full process. 2https://platform.openai.com/docs/assistants/overview
We assume that a dialogue is taking place, based on a DGDL description that is being executed by the
Dialogue Game Execution Engine (DGEP), a platform for running and regulating implemented formal
dialogue games. The versions of DGDL and DGEP that we use are those incorporated into the Agents
United platform3 [
For each available move, the first stage is to create the concrete DCRS object. This involves adding relevant utterances and knowledge to the ℎ and fields respectively, and generating a concrete scafold that will be used as the basis of the LLM prompt. The DCRS for an move contains a scafold of the form $p because $q, where $p and $q are variables representing the two components of the argument. The value for $p is obtained from the object in the move, while the value for $q is the response to be sourced from the LLM. Our concrete scafold therefore becomes We should take climate change seriously because $response.
The second stage is to initialise PrEFACE using the DCRS, which in turn sets up the necessary objects and functions for interacting with the LLM, and generates the final prompt that will be submitted. This includes providing the instructions and context described in section 3.2. One PrEFACE is initialised, the fourth stage is to send the prompt and await the response. To ensure a tightly-bound response, we leverage the function calling capabilities of GPT-based LLMs, with the result passed to a callback function whose eventual purpose will be to verify the response4.
When a final response is obtained, the fifth and final stage is to embed that response into the reply that - assuming this move is chosen - will be returned to DGEP. This reply is also a JSON object, of the form shown in Figure 5. Once this process is complete for all available move types, the agent will choose (using some strategy) a completed move object to return to DGEP.
The version of the PreFACE library described in section 3 provides a simple method of linking formal models of dialogue with large language models. This however represents only an initial starting point; PreFACE and the DCRS remain under active development and will continue to have their capabilities enhanced through further insights from both testing, and the literature. Furthermore, we intend to explore how PreFACE can be used as a generalised tool for harnessing the capabilities of LLMs 3Available from https://github.com/AgentsUnited 4It is as-yet unclear what such a verification would involve, and so we leave this to future work. in the broader field of computational argumentation. In this section, we briefly discuss such future developments, from the immediate term to a longer-term vision.
Retrieval Augmented Generation (RAG) allows LLMs to use external sources in generating responses
to prompts. A common use-case is allowing an LLM to access domain-specific documents as a way
of providing conversational interfaces for users to find relevant information (e.g. an employee asking
“What is the company annual leave policy?", and the RAG-supported LLM will retrieve the answer
from the relevant document). Within PreFACE, RAG provides opportunities to further supplement an
agent’s knowledge through retrieval of relevant arguments from a data store such as ArgDB5 [
There are however further hurdles that will need to be overcome. ArgDB stores analysed argument data as directed graphs, represented in JSON. While LLMs are capable of parsing and querying JSON, they are not as yet capable of understanding the semantics; that is, they cannot understand the inference and conflict relationships described by the JSON objects. An additional step is therefore required to represent the JSON returned from ArgDB in a format that can more readily be interpreted by an LLM.
As noted in Section 4.1 above, analysed argument data is stored as directed graphs. These graphs comprise individual premises, conclusions and the relationships between them, and can be easily visualised. Generating textual summaries of these analyses can be useful, for example in helping understand a complex topic with multiple conflicting viewpoints.
It is our intention in future work to explore how PreFACE can be extended to not only find suitable content for a dialogue move, but also provide summaries of analysed arguments stored in ArgDB. We envisage that this will leverage the (upcoming) RAG capabilities, but instead of finding a specific piece of content to fulfil a dialogical function, instead the LLM will be used to summarise a collection of arguments and the relationships between them.
This paper has presented preliminary and in-progress work towards combining the strict dialectical structures imposed by formal dialogue games, and the human-level language generation capabilities of large language models (LLMs). We presented the PreFACE library, a tool that allows a software agent to query an LLM for an appropriate response given their currently available dialogue move(s). The Dialogue Context Request Structure (DCRS) allows the agent to provide the current dialogical context along with other associated details relevant to the utterance that the LLM is being request to generate. 5https://github.com/Open-Argumentation/ArgDB
As the capabilities of LLMs continue to expand, so to will the demand for further application areas. The work we present here lays a foundation to make such expansions into domains that require both strong natural language generation, and strict conversational structures.