From Chatbot to Knowledge Exchange: Building RAG Tools We Can Question

I. THE HOOK 

It all started, rather improbably, with Donald Trump. 

In the first session of Let’s Talk, a Teaching Development Grant project at Lingnan University in Hong Kong, we aimed to help students learn how to evaluate an AI chatbot. Whether it could hold a recognisable voice, remain grounded in the material we had given it, and show us when something was beginning to work. 

We asked: “What time is it?” 

It answered: “It’s time to make America great again.” 

It was funny, but also useful. In that small, ridiculous exchange, our students could see something important: the bot was not just retrieving information; it was beginning to perform a voice, shaped by the materials, prompts and constraints we had placed around it. 

That early classroom experiment travelled further than expected. The same framework was later adapted into a legal study assistant for our Business School, a Brian Eno-inspired digital composer for the University of Coimbra, and, most recently, a David Attenborough-inspired one for NCACE. In that session, the bot became a way to pose a broader Knowledge Exchange question: how can arts, culture, and academic communities build AI tools they can interrogate, rather than simply trust? 

We taught how to build a RAG bot: a chatbot that answers questions by drawing on the materials you provide, such as reports, papers, archives, spreadsheets, or feedback forms. The aim was not just to make AI more accurate, but more discussable: what goes in, what stays out, who checks it, and what kind of knowledge exchange it enables. 

II. THE "WHY"

GenAI often gives the impression that it knows everything. In practice, it can also know nothing. 

This is where many conversations about AI in education and the arts become confusing. Through Conductive Music CIC, we work with schools across England, and this year we have spoken with more than 500 teachers. 74% told us they use GenAI daily. Yet, when we asked more detailed questions about environmental impact, digital ethics, copyright or data privacy, very few had a clear framework for making informed decisions. 

This is not a criticism of teachers. It is a criticism of the explanations they are given. Many teachers tell us, for example, that ChatGPT is blocked in their school, and that they are therefore expected to use Copilot instead. But this can create a false sense of clarity. When users ask Copilot which model underpins the answer, they are often pointed back to the same family of OpenAI models that made ChatGPT familiar in the first place. The interface has changed, but the underlying question has not: which model is answering, what data is being sent, what knowledge is the response based on, and what happens when a confident answer is simply wrong? 

RAG, or retrieval-augmented generation, offers one practical way to make this conversation more grounded. I often describe it as giving a language model its own library. We provide the “books”: reports, papers, archives, spreadsheets, feedback forms and policy documents. The system organises them into a searchable structure, often called a vector database. Then, when we ask a question, the bot is prompted to answer from that selected material, rather than relying only on its general training. 

This does not make the AI infallible. It does, however, change the nature of the task. For Knowledge Exchange and entrepreneurial practice, the most interesting question is not whether our ideas might be copied or our data exposed, although those risks require proper care. The more immediate question is whether the answers we receive are based on real, relevant and inspectable material.  

III. THE RPROCESS

The workshop itself was a collaborative experiment in making the technical visible without making it unnecessarily intimidating. 

When I built my first RAG bot in November 2025, the user had to jump through a worrying number of hoops. By April 2026, the process had become much simpler: most of the setup could be reduced to copying and pasting an API key. This is, of course, what technological progress often does. It makes the difficult thing look easy. 

But as a creative technologist, I am constantly reminded that what feels obvious to one person can be completely opaque to another. At the start of the workshop, I asked participants to copy one of two short strings from the Zoom chat, depending on the initial of their surname. That was enough to slow the room down for a good ten minutes. 

In one sense, I could have hidden all of that. I was only a couple of prompts away from covering the scary Google Colab code and letting people interact with a polished chat interface. But if we never look under the bonnet, how do we learn how things work? 

This is also the teaching philosophy behind Conductive Music. We try to teach the “how”, rather than only the “what”. The “what” is a tutorial: search for the function you need, and some generous stranger on YouTube will probably explain it beautifully in seconds. The “how” is different. It is the framework that helps people understand principles, adapt them, and apply them to their own context. 

That distinction mattered in a multidisciplinary room. Artists, academics, cultural workers and technologists do not arrive with the same assumptions, fears or vocabulary. A phrase such as “clone the repository” may be routine for a developer and a complete barrier for everyone else. Equally, a technologist may underestimate the curatorial, ethical and interpretive labour involved in deciding what a bot should read, quote and ignore. 

For me, this is where the real workshop happened: not in hiding the code, but in making enough of it visible for people to ask better questions. What happens if we change the temperature? What does chunking mean? Why does overlap matter? Where, exactly, does the answer come from? The aim was not to turn everyone into a programmer, but to make the system legible enough for non-specialists to challenge it.