Dialogue State Tracking
"I want a cheap restaurant in the north... actually make it moderate... and add Italian." Three turns, three state updates. DST keeps the slot-value dict in sync so the booking works. In a task-oriented dialogue system, the user's goal is encoded as a set of slot-value pairs: {cuisine: italian, area: north, price: moderate}. Every user turn can add, change, or remove a slot. The system must read the whole conversation and output the current state correctly. Get a single slot wrong and the system books the wrong restaurant, schedules the wrong flight, or charges the wrong card. DST is the hinge between what the user said and what the backend executes. Why it still matters in 2026 despite LLMs: Compliance-sensitive domains (banking, healthcare, airline booking) require deterministic slot values, not free-form generation. Tool-use agents still need slot resolution before calling APIs. Multi-turn correction is harder than it looks: "actually no, make it Thursday.". The modern pipeline: classical DST concepts + LLM extractors + structured-output guardrails. DST: dialog history → slot-value state Task structure. A schema defines domains (restaurant, hotel, taxi) and their slots (cuisine, area, price, people). Each slot can be empty, filled with a value from a closed set (price: {cheap, moderate, expensive}), or a free-form value (name: "The Copper Kettle"). Two DST formulations. Classification. For each (slot, candidatevalue)…
Dialogue State Tracking: "I want a cheap restaurant in the north... actually make it moderate... and add Italian." Three turns, three state updates. DST keeps…
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.