Dialogue systems
Before ChatGPT, building a chatbot meant a pipeline. Task-oriented systems split into NLU, state tracking, policy, and generation; open-domain chatbots evolved from pattern-matching rules to retrieval to neural generation. LLMs collapsed the pipeline — but its concepts still structure how reliable conversational agents are built.
Written and reviewed by Shreyash Prashu Last reviewed
What you'll learn
- Task-oriented vs open-domain dialogue
- The task-oriented pipeline — NLU, state tracking, policy, generation
- The open-domain progression — rules to retrieval to neural generation
- How LLMs collapsed the pipeline, and why the concepts still matter
Before you start
Before a single model could just chat, building a conversational system meant assembling a pipeline of specialized parts. Dialogue splits into two very different goals: task-oriented systems that accomplish something specific (“book a flight,” “reset my password”) and open-domain chatbots that converse about anything. They were built in completely different ways — and understanding both explains what LLMs actually replaced.
Task-oriented: a four-stage pipeline
A task-oriented system runs each user turn through four stages. The first is natural-language understanding (NLU): classify the user’s intent and fill in the slots (the parameters the task needs).
def parse(utterance): # NLU: intent classification + slot filling
u = utterance.lower(); toks = u.split()
intent = "book_flight" if ("flight" in u or "fly" in u) else "unknown"
slots, cities = {}, {"paris", "london", "tokyo"}
found = [w for w in toks if w in cities]
if found: slots["destination"] = found[-1]
if len(found) >= 2: slots["origin"] = found[0]
for w in toks:
if w in {"monday", "tuesday", "friday"}: slots["date"] = w
return intent, slots
for u in ["book a flight from london to paris on friday", "what's the weather"]:
print(u, "->", parse(u))
book a flight from london to paris on friday -> ('book_flight', {'destination': 'paris', 'origin': 'london', 'date': 'friday'})
what's the weather -> ('unknown', {})
That parsed intent and slots feed the rest of the pipeline:
After NLU, dialogue state tracking (DST) accumulates slots across turns (so “actually, make it Tokyo” updates the destination without re-asking everything), the policy decides the next action (ask for a missing slot, confirm, or call the booking API), and NLG turns that action into words. The hard part is state across turns — coreference, corrections, and remembering what’s already known.
Open-domain: rules → retrieval → neural
Chit-chat bots followed a different arc:
- Rule-based — pattern-matching templates. ELIZA (1966) faked a therapist by reflecting your words back (“I feel sad” → “Why do you feel sad?”). No understanding, just rules.
- Retrieval-based — given the user turn, pick the best response from a large corpus of human replies (ranked by similarity). Fluent (real human text) but can’t say anything new.
- Neural generative — seq2seq models (Meena, BlenderBot) generate responses, enabling novel replies — at the cost of blandness, contradictions, and hallucination.
In one breath
- Dialogue splits into task-oriented (accomplish a goal) and open-domain (converse about anything) — historically built very differently.
- Task-oriented is a pipeline: NLU (intent + slot filling) → state tracking (accumulate slots across turns) → policy (next action) → NLG (response); the hard part is state across turns.
- Open-domain evolved rules (ELIZA pattern-matching) → retrieval (pick a human response) → neural generation (seq2seq, novel but can be bland/contradictory).
- LLMs collapsed the pipeline: one model does NLU + state + policy + NLG end-to-end, and the task/open distinction blurred.
- The concepts persist — intent, slots, state, grounding still structure reliable agents; modern tool-calling is essentially slot-filling for an LLM.
Quick check
Quick check
Next
Dialogue’s question-answering turns are QA; its generative core is seq2seq; and grounding a chatbot in real knowledge is RAG. Modern agents turn slot-filling into tool calls.
Practice this in an interview
All questionsAn AI agent is an application that lets an LLM choose and execute validated tools in a bounded loop, carrying observations and state forward until it reaches a goal or needs approval. A single LLM call produces one response or tool-call proposal and stops; it does not itself provide the loop, live-system access, memory, or side effects.
The core toolkit is: system prompts (role and constraints), few-shot examples (format and tone anchoring), chain-of-thought (step-by-step reasoning), and output constraints (JSON schema, stop sequences). Combining these predictably closes the gap between a capable base model and a production-ready feature.
BERT is an encoder-only transformer that reads all tokens bidirectionally and is trained with masked language modelling — ideal for tasks requiring a rich contextual representation of an entire sequence, like classification or NER. GPT is a decoder-only transformer that attends only to previous tokens via a causal mask and is trained with next-token prediction — ideal for text generation. Encoder-decoder models like T5 combine both for tasks that map one sequence to another.
Tool calling extends the LLM's output space to include structured function invocations. The model emits a JSON object naming a tool and its arguments; the runtime executes the tool and feeds the result back as a new message. An agent is a loop that repeats this cycle — observe, think, act — until the task is complete or a stopping condition is met.