Dialogue Systems and Chatbots: From Rules to LLM Assistants

From ELIZA in 1966 to today's AI assistants, conversation has been a grand challenge of AI. Chatbots now answer customer questions, help people book appointments, guide users through complex procedures and provide information in many languages. Designing a good conversational system requires more than a powerful model: it requires understanding the users, the tasks, the failure modes and the right hand-offs to humans.

Types of dialogue systems#

The classic task-oriented pipeline#

1. Natural Language Understanding (NLU):
   • Intent detection — what the user wants (book_appointment, check_status) — a text classification problem.
   • Slot filling — extract parameters (date=Tuesday, clinic=Camp 4) — a sequence-labelling problem, often solved jointly with intent detection.
2. Dialogue State Tracking (DST): maintain a structured record of what is known so far, updated every turn (the user may change their mind).
3. Dialogue Policy: decide the next action — ask for a missing slot, confirm, query a database, hand over to a human.
4. Natural Language Generation (NLG): turn the action into text (templates or a generator).

User:   I need to see a doctor for my son on Tuesday.
NLU:    intent=book_appointment, slots={patient: son, date: Tuesday}
State:  {intent: book_appointment, patient: son, date: Tuesday, clinic: ?}
Policy: request(clinic)
NLG:    "Which clinic would you like to visit? Camp 4 or Camp 7?"

This modular design is controllable, testable and auditable — valuable when conversations have real consequences — but brittle to phrasings and flows its designers did not anticipate.

End-to-end and LLM-based assistants#

Large language models can conduct fluent, flexible conversation directly. Production assistants combine an LLM with:

• a system prompt defining role, tone, scope and rules;
• retrieval over approved documents (RAG) for accurate, current information;
• tools/function calling to query databases or take actions (check a case status, book a slot) through well-defined, permission-checked APIs;
• memory of the conversation (and, with consent, of user preferences);
• guardrails: input/output filters, topic restrictions, refusal of unsafe requests, and escalation to humans.

# A minimal intent + slot baseline for a task-oriented bot
import re

INTENTS = {
    "book_appointment": ["appointment", "see a doctor", "book", "schedule"],
    "check_status": ["status", "my case", "application", "update"],
    "opening_hours": ["open", "hours", "close", "time"],
}
DAYS = r"(monday|tuesday|wednesday|thursday|friday|saturday|sunday)"

def nlu(text):
    t = text.lower()
    intent = max(INTENTS, key=lambda k: sum(kw in t for kw in INTENTS[k]))
    slots = {}
    if m := re.search(DAYS, t):
        slots["date"] = m.group(1)
    if m := re.search(r"camp\s*(\d+)", t):
        slots["clinic"] = f"Camp {m.group(1)}"
    return intent, slots

print(nlu("Can I book a doctor appointment at camp 4 on Tuesday?"))

In practice, replace the keyword rules with a fine-tuned classifier or an LLM with structured (JSON) outputs — but keep the explicit state and policy where reliability matters.

Designing good conversations#

• Scope clearly: tell users what the bot can and cannot do.
• Handle failure gracefully: when unsure, ask a clarifying question or offer a human hand-off rather than guessing.
• Confirm consequential actions before executing them.
• Accessibility and language: support the languages, literacy levels and channels (SMS, WhatsApp, voice) your users actually use.
• Privacy: collect the minimum data needed; explain how it is used; avoid storing sensitive details unnecessarily.
• Transparency: users should know they are talking to an AI.

Evaluation#

• Task-oriented: task success rate, turns to completion, slot accuracy, joint goal accuracy for state tracking.
• QA bots: answer correctness and faithfulness against sources, containment rate (resolved without human) balanced against correct escalation.
• Conversation quality: human ratings of helpfulness, coherence, empathy and safety; A/B tests with real users.
• Red-teaming: deliberately attempt to make the bot give harmful, false or out-of-scope answers, including prompt-injection attacks hidden in retrieved documents.