Multi-party Goal Tracking with LLM s: Comparing Pre-training, Fine-tuning, and Prompt Engineering (2023)

Abstract: This paper evaluates the extent to which current LLMs can capture task-oriented multi-party conversations (MPCs). We have recorded and transcribed 29 MPCs between patients, their companions, and a social robot in a hospital. We then annotated this corpus for multi-party goal-tracking and intent-slot recognition. People share goals, answer each other’s goals, and provide other people’s goals in MPCs - none of which occur in dyadic interactions. To understand user goals in MPCs, we compared three methods in zero-shot and few-shot settings: we fine-tuned T5, created pre-training tasks to train DialogLM using LED, and employed prompt engineering techniques with GPT-3.5-turbo, to determine which approach can complete this novel task with limited data. GPT-3.5-turbo significantly outperformed the others in a few-shot setting. The ‘reasoning’ style prompt, when given 7% of the corpus as example annotated conversations, was the best performing method. It correctly annotated 62.32% of the goal tracking MPCs, and 69.57% of the intent-slot recognition MPCs. A ‘story’ style prompt increased model hallucination, which could be detrimental if deployed in safety-critical settings. We conclude that multi-party conversations still challenge state-of-the-art LLMs.

## introduction spoken dialogue systems (sdss) are increasingly being embedded in social robots that are expected to seamlessly interact with people in populated public spaces like museums, airports, shopping centres, or hospital waiting rooms @xcite @xcite . unlike virtual agents or voice assistants (e.g. alexa, siri, or google assistant), which typically have dyadic interactions with a single user, social robots are often approached by pairs and groups of individuals @xcite . families may approach a social robot in 1 u1: what time was our appointment? 2 u2: we have an appointment at 10.30pm. 3 u1: ok. further annotated examples can be found in a museum, and patients are often accompanied by a family member when visiting a hospital. in these multi-party scenarios, tasks that are considered trivial for sdss become substantially more complex @xcite @xcite . in multi-party conversations (mpcs), the social robot must determine which user said an utterance, who that utterance was directed to, when to respond, and what it should say depending on whom the robot is addressing @xcite @xcite . these tasks are collectively referred to as "who says what to whom" in the multi-party literature @xcite , but these tasks alone provide no incentive for a system to actually help a user reach their goals. state of the art "who says what to whom" systems can, therefore, only mimic what a good mpc looks like @xcite , but for practical systems we also need to know what each user's goals are. we therefore propose two further tasks that become substantially more complex when considered in a multi-party setting: goal tracking and intent-slot recognition @xcite . dialogue state tracking (dst) is a wellestablished task @xcite that is considered crucial to the success of a dialogue system @xcite . dst corpora are abundant @xcite ), but they only contain dyadic conversations. no corpus exists containing mpcs with goal tracking or intent-slot annotations, yet there are important differences. consider the example in in this paper, we present several contributions. (1) we collected a corpus of multi-party interactions between a social robot and patients with their companions in a hospital memory clinic. (2) this corpus was annotated for the standard "who says what to whom" tasks, but also for multi-party goal tracking and intent-slot recognition. we followed current dst annotation instructions, tweaked to enable annotation of multi-party phenomena (detailed in section 2). (3) we then evaluated large language models (llms) on these two new tasks using our collected corpus. models were pre-trained, fine-tuned, or prompt engineered where applicable (detailed in section 3). it is not possible to collect enormous corpora from patients in a hospital, so models were evaluated in zero-shot and few-shot settings. we found that the gpt-3.5-turbo model significantly outperformed others on both tasks when given a 'reasoning' style prompt. ## dataset and tasks for the initial data collection, we partnered with a hospital in paris, france, and secured ethical ap-proval as part of the eu spring project foot_0 . we then recorded, transcribed, translated (from french to english), anonymised, and annotated 29 multiparty conversations (774 turns). these mpcs were between patients of the memory clinic, their companion (usually a family member), and a social humanoid robot created by pal robotics called ari @xcite . we hired a professional translator to avoid machine translation errors, and to enable faster experimentation as we are not french speakers. future work based upon the findings in this paper will be evaluated in both english and french. we used a wizard-of-oz setup as this task is new, and we required this data to design a multiparty sds for use in the hospital. a robot operator was therefore controlling what ari said by selecting one of 31 response options (task-specific answers and some common responses like "yes", "no", "please", "thank you", and "i don't know"). following our previously published data collection design @xcite , each participant was given one or two goals, and asked to converse with ari to try to achieve their goal. both participants were given the same goals in some cases to elicit dialogues containing 'shared goal' behaviour. in order to encourage lexical diversity, we provided pictograms to give each participant their goals. for example, if we told the patient that they want a latte, they would likely use the specific word "latte" @xcite , so we instead gave the participants pictograms as seen in the topright of figure 1 . this worked as people didn't just ask for coffee when given this image, some asked for hot chocolate or herbal tea instead. in this paper, we evaluated each model on both multi-party goal tracking, and multi-party intentslot recognition. these are two related, yet distinct tasks. if ari asked the user "are you hungry?", and the user responded "yes", then the intent of that turn is an affirmation, but the user's goal is also established as wanting to eat. as explained in section 1, standard dst annotation schemes are designed for dyadic interactions, which do not enable annotation of multi-party behaviours. each turn is annotated with its intent and slot values where applicable, but goal annotations require both the goal and the user whose goal is being established. when a goal is detected in a dyadic interaction, no user information is needed as there is only a single user. in multi-party interactions, multiple users can have multiple active goals. these goals may be different, they may be shared (see an annotated extract from an mpc in our collected corpus can be found in with these two sets of annotations, we can evaluate various llms on two tasks: (1) multi-party intent-slot recognition; and (2) multi-party goal tracking. it is not possible to collect vast quantities of interactions with patients in the hospital, so these models must be able to learn from a corpus of limited size. we therefore decided to mask annotations in a randomised window selected from each mpc, providing the model with the surrounding context and speaker labels. that is, a random number of turns was selected in each mpc, and then the annotations were replaced by a '[mask]' token. an example of this is shown in as the corpus size is limited, the window selection could potentially heavily impact model performance. we therefore randomised the selected window three times for each conversation and train/test split, and these exact same windows were used to train and test each model. to clarify, all train/test splits and windows were randomised for multiple runs, but they were unchanged between each model. for example, run 1 with the 20/80 split in section 4 for t5 contained the exact same test set, with the exact same window, as run 1 with the 20/80 split for dialogled. this holds true for both tasks. each masked window was bookended with a ' @xcite ' tag to help the models learn this task too @xcite . a shortened example from our corpus can be seen in ## experimental procedure we evaluated three different models (each detailed below): t5 @xcite , dialoglm using led (dialogled) @xcite , and gpt-3.5-turbo foot_2 . each approach was evaluated in a zeroshot and few-shot setting, with various train/test splits. we could not provide more data to gpt-3.5turbo due to context window size, but the train/test user utterance intent-slot annotation goal tracking annotation 1 u1: hello, we'd like a coffee. where can we go? greet() ; request(beverage(coffee)) g(u1+u2, drink(coffee)) 2 ari: you have to enter the building behind you. inform(directions(cafe)) ag(u1+u2, drink(coffee)) 3 u2: ok, well thank you very much. acknowledge(); thank() cg(u1+u2, drink(coffee)) [end] -4 u2: my appointment is in room 17, where is it? g(u2, go-to( room_17 )) - ## results we evaluated t5, dialogled, and gpt-3.5-turbo as described in section 3 on multi-party goal track-ing, and multi-party intent-slot recognition. outputs were annotated as either 'exact', 'correct', or 'partial' to distinguish each model's performance beyond simple accuracy. exact matches were strictly annotated, but slight differences are allowed if the annotation meaning remains unchanged. for example: 'g(u1, go-to(lift))' and 'g(u1, go-to(lifts))' (note the plural 'lifts'). outputs were marked as exact if every [mask] in the mpc was exact, and marked as correct if every [mask] was more broadly accurate. for example, if the annotation contained 'drink(coffee)' and the model output 'drink(hot_drink)', we considered this correct. the output was marked as partially correct if at least 60% of the [mask] tags were correctly annotated. this latter metric allows us to distinguish between models that generate nonsense, and those that roughly grasp the task. our inter-annotator agreements were 0.765 and 0.771 for goal tracking and intent-slot recognition, respectively. these are less than 0.8, and this was due to the broad definition of 'correct'. we plan to design automatic metrics for our future work (see section 5). ## conclusion and future work multi-party conversations (mpcs) elicit complex behaviours which do not occur in the dyadic interactions that today's dialogue systems are designed and trained to handle. social robots are increasingly being expected to perform tasks in public spaces like museums and malls, where conversations often include groups of friends or family. multi-party research has previously focused on speaker recognition, addressee recognition, and tweaking response generation depending on whom the system is addressing. while this work is vital, we argue that these collective "who says what to whom" tasks do not provide any incentive for the social robot to complete user goals, and instead encourage it to simply mimic what a good mpc looks like. in this paper, we have detailed how the tasks of goal tracking and intent-slot recognition differ in a multi-party setting, providing examples from our newly collected corpus of mpcs in a hospital. we found that, given limited data, 'reasoning' style prompts enable gpt-3.5-turbo to perform significantly better than other models. we found that other prompt styles also perform well, but prompts that are story-like increase model hallucination. with the introduction of prompt finetuning with human feedback @xcite , generative llms do now have some incentive to avoid misleading or harming the user, providing outputs prepended with caveats, but the issue is not solved. openai claims that gpt-4 generates 40% fewer hallucinations than gpt-3 @xcite , but these models should still not be applied directly in a hospital or other safety-critical setting without further evaluation. in the hospital setting, users are more likely to be from vulnerable population groups, and are more likely to be older adults that are not familiar with the capabilities of today's models. multiple researchers and hospital staff members are present when conducting our data collections, so that if hallucinations do occur, they can be quickly corrected. we will, therefore, be able to evaluate response grounding, guidance foot_5 , and other hallucination prevention strategies to determine whether these models can ever be used safely in a high-risk setting. these further experiments will also elicit further mpcs that can be annotated for various multi-party tasks. user inputs must be processed on external servers when using industry llms, like gpt-3.5turbo and google's bard. for this reason, these specific models cannot be deployed in the hospital setting. patients may reveal identifiable or sensitive information during our data collection, which we subsequently remove from the corpus. this data must stay contained within approved data-controlled servers in the spring project. in this paper, we have reported the remarkable performance of an industry llm, when given limited data, compared to prior model architectures. we will analyse open and transparent instruction-tuned text generators @xcite , which are able to meet our data security requirements. the accessibility of today's sdss is critical when working with hospital patients @xcite . speech production differs between the 'average' user, and user groups that remain a minority in huge training datasets. for example, people with dementia pause more frequently and for longer durations mid-sentence due to word-finding problems @xcite . we are utilising knowledge graphs to ensure that sdss are transparent, controllable, and more accessible for these user groups @xcite , and we see the unification of large language models and knowledge graphs @xcite as the near-term future of our field. we plan to design and run subsequent experiments in both the hospital memory clinic, and a newly established mock waiting room in our lab. this space will allow us to collect additional mpcs with more than two people, replicating scenarios in which whole families approach a social robot. we plan to evaluate whether prompt engineering can work modularly for n users. for example, we could use gpt-4 to correct speaker diarization @xcite , then to handle multi-party goal tracking, and then to generate responses to the user. this experimental setup will allow us to quickly test new ideas, such as automatic prompt optimization @xcite in the lab, maximising the benefit of patients' time in the hospital.