Chatbots

Open a shopping app on your phone — Flipkart, Myntra, or a food delivery app — and tap the little chat bubble in the corner. Type "I want to cancel my order." A reply appears almost instantly: "I'm sorry to hear that! I can help you cancel your order. Please share your order ID." It feels like you are talking to someone who understood your sentence. But did it? Or did it just notice the word "cancel" sitting inside your sentence and react to that one word, the way a person half-listening to you might jump at a single word they caught?

That question — did the program understand the sentence, or did it just react to a piece of it? — is the entire subject of this chapter. We are going to build a chatbot ourselves, in Python, starting from the simplest possible version, and watch it fail in a very specific and very common way. Then we will fix it, watch it fail again in a sneakier way, and fix that too. By the end you will know exactly what a "chatbot" is doing under the surface, why even a fixed version can still be tricked, and how the giant AI chatbots you may have heard of (like ChatGPT) are built on a version of the same core idea, scaled up enormously.

Two Very Different Kinds of Chatbots

The word "chatbot" covers two genuinely different technologies, and mixing them up is the first mistake to avoid.

A rule-based chatbot is a program written by a human that follows explicit, fixed instructions: "if the message contains this word, reply with that sentence." It has no idea what language means — it is doing pattern matching on text, the same way a program that checks if a PIN is exactly 4 digits doesn't "understand" security. Every reply it can ever give was typed in by a programmer in advance. This is what most bank helpline bots, railway enquiry bots, and simple website chat widgets are.

A statistical or neural chatbot (the family that includes modern AI systems like ChatGPT) does not follow hand-written if/else rules for what to say. Instead, it was shown enormous amounts of real text — books, websites, conversations — and learned to estimate, for any sentence so far, which word is statistically most likely to come next. It generates a reply one word (technically, one "token") at a time, each time picking from a probability distribution over possible next words. We will build a tiny toy version of this idea later in the chapter, using numbers small enough to compute by hand.

India's railway booking service, IRCTC, runs a virtual assistant called AskDISHA that answers questions about PNR status, train enquiry, and ticket booking — a practical example of a rule-based/hybrid customer-service bot most Indian students have likely encountered, even if only through a parent's phone.

The One Tool You Need First: Checking If Text Is "Inside" Other Text

Before we write a single line of chatbot code, we need one small but critical piece of Python: the in operator, which checks whether one string appears anywhere inside another string, as a contiguous run of characters.

print("cat" in "concatenate")   # True
print("hi" in "goodbye")        # False
print("hi" in "this")           # True
print("hey" in "they")          # True

Trace the first line carefully: "concatenate" is spelled c-o-n-c-a-t-e-n-a-t-e. Read positions 3, 4, 5: c, a, t. There it is — "cat" sitting inside "concatenate," even though the word has nothing to do with cats. Python's in does not know or care about word boundaries, meaning, or spaces. It only asks: "do these exact characters appear next to each other, somewhere, in this order?"

Now look at line three. "this" is spelled t-h-i-s. Positions 1 and 2 are h and i. So "hi" in "this" is True — the greeting "hi" is hiding inside the ordinary word "this," purely by coincidence of spelling. Same story with "hey" hiding inside "they." Keep this fact in your head; it is about to cause a real bug in the chatbot we build next, and understanding why it happens is one of the most useful debugging instincts you can develop in programming.

Version 1: The Simplest Possible Chatbot

Here is a first attempt at a customer-support chatbot, using nothing but if/elif/else and the in operator:

def rule_based_bot(text):
    text = text.lower()
    if "bye" in text:
        return "Goodbye! Have a nice day."
    elif "hi" in text or "hello" in text:
        return "Hello! How can I help you today?"
    elif "cancel" in text or "order" in text:
        return "I can help you cancel your order."
    else:
        return "Sorry, I did not understand. Can you rephrase?"

The logic looks reasonable: check for a goodbye first, then a greeting, then a cancellation request, and if none of those match, admit defeat honestly. Let's trace it on a real sentence, exactly the way you should trace any program before trusting its output — line by line, not by guessing.

Input: "Hi, I want to cancel my order"

1. text = text.lower() turns it into "hi, i want to cancel my order".
2. Is "bye" in the text? No.
3. Is "hi" in the text? Yes — the literal word "hi" sits right at the start. Since this is an elif, Python stops checking further conditions the moment one is True.
4. The function returns "Hello! How can I help you today?" and exits immediately. The cancel/order branch is never even reached, even though the word "cancel" is sitting right there in the sentence.

Run it and you get exactly that: Hello! How can I help you today? — a chatbot that completely ignores a customer's clearly stated cancellation request because a greeting word happened to appear earlier in the sentence and earlier in the elif chain. This is failure mode #1: a rule-based bot only ever acts on the first rule that matches, in the order the programmer wrote the rules, regardless of what the rest of the sentence says. A real customer typing that sentence would be, reasonably, annoyed.

A Sneakier Failure: When the "Bug" Isn't Even a Real Word

That first failure was at least caused by a real, intentional word ("hi"). Now try a sentence that a person would recognise instantly as a cancellation request, with no greeting anywhere in it.

Input: "I don't want this order, please stop it"

1. Lowercased: "i don't want this order, please stop it".
2. Is "bye" in the text? No.
3. Is "hi" in the text? Look very carefully at the word "this": t-h-i-s. Characters at positions 1 and 2 are h and i, consecutively. So "hi" in text is True — not because anyone greeted the bot, but because the ordinary word "this" happens to contain the letters "h" then "i" in a row.
4. The function returns "Hello! How can I help you today?" — again, ignoring the cancellation entirely, this time for a reason that has absolutely nothing to do with the customer's intent.

Misconception to correct explicitly: it is tempting to assume that if a chatbot's reply happens to sound reasonable, its internal logic must have worked correctly, or that a bug like this would only occur with unusual or deliberately tricky input. Neither is true. This is an ordinary, everyday English sentence, and the bug fires silently — the program does not crash, does not print a warning, just confidently returns the wrong reply. The lesson is not "avoid the word 'this'" (that's absurd — you cannot ban a common word from user input). The lesson is: naive substring matching with in has no concept of word boundaries, and any keyword-matching system built this way will misfire on ordinary words that happen to contain your keywords as a spelling coincidence. This is a real, well-known category of bug in text-processing software, not a toy classroom example.

Version 2: Fixing It With Scores Instead of "First Match Wins"

The first fix addresses failure mode #1 (ignoring later, more relevant words) by counting evidence for every category instead of stopping at the first match, and then picking whichever category has the strongest evidence.

def smart_bot(text):
    text = text.lower()
    greet_words = ["hi", "hello", "hey"]
    cancel_words = ["cancel", "stop", "remove", "don't want"]
    bye_words = ["bye", "goodbye"]

    greet_score = sum(1 for w in greet_words if w in text)
    cancel_score = sum(1 for w in cancel_words if w in text)
    bye_score = sum(1 for w in bye_words if w in text)

    if bye_score > 0:
        return "Goodbye! Have a nice day."
    elif cancel_score >= greet_score and cancel_score > 0:
        return "I can help you cancel your order."
    elif greet_score > 0:
        return "Hello! How can I help you today?"
    else:
        return "Sorry, I did not understand. Can you rephrase?"

Instead of returning the moment one condition is true, this version counts how many words from each list appear, giving each category a numeric score, and only then decides. Let's trace it on our tricky sentence again.

Input: "I don't want this order, please stop it", lowercased to "i don't want this order, please stop it".

Computing greet_score — check each word in greet_words against the text:

• "hi" in text → True (still hiding inside "this," exactly as before)
• "hello" in text → False
• "hey" in text → False

So greet_score = 1. The substring bug has not gone away — it still fires. Do not assume scoring alone fixes the root cause; it doesn't, it only changes how much that one wrong signal is allowed to outweigh other evidence.

Computing cancel_score — check each word in cancel_words:

• "cancel" in text → False
• "stop" in text → True ("please stop it")
• "remove" in text → False
• "don't want" in text → True ("i don't want this order")

So cancel_score = 2. And bye_score = 0, since neither "bye" nor "goodbye" appears anywhere.

Now the decision: Is bye_score > 0? No (it's 0). Is cancel_score >= greet_score and cancel_score > 0? That's 2 >= 1 and 2 > 0 — both true. The function returns "I can help you cancel your order." — the correct reply, at last, for this sentence. Even though the "hi"-inside-"this" glitch still contributed a phantom point to greet_score, the genuine cancellation evidence (2 points, from two independent real signals) outweighed it. Scoring turned one accidental false signal from a fatal, silent failure into a harmless rounding error, because it no longer lets a single early match short-circuit everything else.

Check it also on the earlier sentence, "Hi, I want to cancel my order": here greet_score = 1 (from the real "hi") and cancel_score = 1 (from "cancel"). It's a tie, and the condition cancel_score >= greet_score is written with >= deliberately, so ties are resolved in favour of the more actionable category (cancellation) rather than a plain greeting — the function correctly returns the cancellation reply instead of just saying hello and stopping there, fixing failure mode #1 as well.

Version 3: Actually Removing the Bug, With Word Boundaries

Scoring only masked the "hi"-in-"this" problem — it happened to have enough other evidence to win. A shorter sentence like "this order" alone would still trip the same bug with nothing to outweigh it. The real fix is to stop checking whether one string is a substring of another and instead check whether a word is a whole, separate token — a chunk of text with actual boundaries (spaces or punctuation) around it, not just characters that happen to sit next to each other.

import re

def tokenize(text):
    return re.findall(r"[a-z']+", text.lower())

def smart_bot_v3(text):
    words = set(tokenize(text))
    greet_words = {"hi", "hello", "hey"}
    cancel_words = {"cancel", "stop", "remove"}
    bye_words = {"bye", "goodbye"}

    greet_score = len(words & greet_words)
    cancel_score = len(words & cancel_words)
    bye_score = len(words & bye_words)

    if bye_score > 0:
        return "Goodbye! Have a nice day."
    elif cancel_score >= greet_score and cancel_score > 0:
        return "I can help you cancel your order."
    elif greet_score > 0:
        return "Hello! How can I help you today?"
    else:
        return "Sorry, I did not understand. Can you rephrase?"

re.findall(r"[a-z']+", text.lower()) scans the lowercased text and pulls out every maximal run of letters and apostrophes, splitting wherever it hits a space, comma, or other punctuation. For "i don't want this order, please stop it" this produces the list ["i", "don't", "want", "this", "order", "please", "stop", "it"] — notice that "this" is now one complete token, not a container that "hi" can be found lurking inside. Turning that list into a set and intersecting it with {"hi", "hello", "hey"} using & gives the empty set, because "hi" is simply not one of the tokens — greet_score = 0, correctly, this time for the right reason. Meanwhile "stop" is a token, so it lands in the intersection with cancel_words, giving cancel_score = 1. (Note that the two-word phrase "don't want" can no longer be detected this way, since token matching compares single whole words — a real trade-off: fixing one bug removed a feature, which is exactly the kind of thing engineers must weigh when choosing a technique.) The decision logic is unchanged, and with cancel_score(1) >= greet_score(0), the bot again replies correctly — but now the greeting branch never had a false signal to begin with.

Beyond Keywords: How Modern AI Chatbots Actually Choose Words

Every version above decides what to say by picking from a short menu of pre-written sentences. Systems like ChatGPT do not work this way at all — they generate a reply one word at a time, choosing each word based on a learned probability, not a hand-written rule.

Here is the core idea in miniature. Suppose a model has been trained on millions of real sentences, and it has learned that after the words "The 10:15 train from Chennai is," people tend to continue with certain words at certain rates:

delayed    0.40
arriving   0.35
cancelled  0.15
late       0.10

These four numbers add up to exactly 1.00, because between them they cover 100% of what the model considers a plausible next word in this context — this is what a probability distribution over words means. The simplest strategy for picking a reply, called greedy decoding, just picks the single highest-probability word every time: here, that's "delayed" at 0.40, since it beats "arriving" at 0.35. The model then repeats the same process for the word after that, and the word after that, building a sentence one probability-weighted choice at a time.

Real systems like ChatGPT do the same fundamental thing — predict a probability for the next unit of text and choose from it — but instead of four hand-typed options, they choose from a vocabulary of tens of thousands of possible tokens, and instead of being trained on a few sentences, they are trained on enormous amounts of text using techniques far beyond a Grade 8 syllabus. The important takeaway for now is the shift in mindset: a rule-based bot answers the question "which pre-written rule matches?" while a statistical bot answers the question "given everything so far, what word is most likely to come next?" — a fundamentally more flexible, but also far less predictable and controllable, approach.

Active Recall

Q1. Trace rule_based_bot("Bye, please cancel my order") by hand, condition by condition. What does it return, and why does the "cancel" branch never get checked?

Q2. Trace smart_bot("Bye, please cancel my order"). Compute bye_score, greet_score, and cancel_score individually before applying the if/elif chain. Does scoring change the final answer compared to Q1? Why or why not?

Q3. For the input "I want to remove this item", compute greet_score and cancel_score under smart_bot (the substring version, not the tokenized one). One of the two words in this sentence hides a greeting inside it by spelling coincidence, the same way "this" did earlier — find it, and state the final score for each category.

Q4. Besides "this" and "they," give two more ordinary English words that would trigger a false "greet" match in smart_bot purely by accident (they must genuinely contain "hi," "hello," or "hey" as a substring — check by spelling them out letter by letter).

Q5. A greedy-decoding model, deciding the word after "I want to," has learned this probability table from customer messages: cancel 0.35, order 0.30, track 0.25, complain 0.10. These add up to 1.00. Which single word does greedy decoding choose, and what rule are you applying to decide?

Answers — Q1: "bye" in text is checked first and is True immediately (the lowercased text is "bye, please cancel my order"), so the function returns "Goodbye! Have a nice day." and exits on the very first if, before the elif chain containing "cancel" is ever reached. Q2: bye_score = 1, greet_score = 0, cancel_score = 1; since bye_score > 0 is checked first and is true, the function still returns "Goodbye! Have a nice day." — scoring doesn't change this particular answer because the "bye" check happens before any comparison between categories, exactly as in Version 1. Q3: the hidden word is "this" again ("hi" in "this" is True), giving greet_score = 1; "remove" gives cancel_score = 1; with the tie-breaking >=, the bot correctly replies with the cancellation message. Q4: "chip" contains "hi" (c-h-i-p, positions 1-2), and "vehicle" contains "hi" (v-e-h-i-c-l-e, positions 2-3) — spell each one out letter by letter to confirm before trusting the answer, the same discipline used throughout this chapter. Q5: greedy decoding always picks the single highest-probability option regardless of the rest, so it picks "cancel" (0.35), since 0.35 is greater than 0.30, 0.25, and 0.10.

Summary

A rule-based chatbot is a plain program that checks whether pieces of your text match pre-written patterns, using tools as simple as the in operator, and replies with a pre-written sentence when a match is found. The most naive version checks conditions in order and stops at the first match, which silently produces wrong replies whenever an earlier rule catches something the user didn't intend — including, as we saw, catching a greeting keyword that was never actually typed, because in matches raw characters with no concept of word boundaries and a word like "this" can contain "hi" purely by spelling coincidence. Scoring every category and comparing totals, rather than stopping at the first hit, fixes the "wrong rule wins" problem but does not by itself fix the substring-collision problem — that requires switching from raw substring checks to proper word-level tokenization, which has its own trade-offs (you lose the ability to match multi-word phrases with simple set intersection). Statistical and neural chatbots, including large modern AI systems, sidestep hand-written rules entirely and instead generate replies word by word from a learned probability distribution over what is likely to come next — the same core arithmetic idea as picking the highest number in a small table, just carried out at a vastly larger scale with numbers learned automatically from data rather than typed in by a programmer.

Think About It

Think about this: How would you explain chatbots to a friend who has never seen a computer? What real-world analogy would you use? Imagine you had to build a system using these concepts — what would be your first step? Try this: before moving on, write down three things you learned and one question you still have.

Practice Exercises

Now it is time to practice! Complete these challenges to solidify your understanding:

• Exercise 1: Write a short program that demonstrates the core concept from this chapter. Test it with at least 3 different inputs.
• Exercise 2: Find a real-world example where chatbots is used in an Indian company (like TCS, Infosys, Flipkart, or ISRO). Write a paragraph explaining the connection.
• Exercise 3: Create a mind-map connecting chatbots to at least 3 other topics you have studied.