No Room for AI Hallucinations: A Website Chatbot with Pure-Code Review

Air Canada once tried to convince a court that statements made by its website support chatbot did not represent the company's position. The court rejected that defense and ruled that a business is responsible for everything on its website, including its AI bot's answers. This precedent draws a red line for every company deploying a website customer-service chatbot: if the bot says something wrong, the company bears the consequences.

For small businesses this risk is especially lethal. A fabricated set of business hours or an invented price can cause losses far exceeding the labor cost the bot saves. One developer built a demo project, Front Desk, around a core idea: let the language model only draft answers, and let deterministic code review decide what is ultimately shown to the customer.

A four-step pipeline: locking the model inside a cage of code

Retrieval: no match, no model involvement

The Front Desk demo is set in a fictional "Juniper Street Bakery." The entire "website" consists of just 13 short entries covering hours, prices, cakes, allergens, delivery, and payment information. The bot knows only this content and nothing else.

After a user asks a question, the first step is code matching at most three relevant entries from these 13. If no entry matches, the model is never called at all, and the customer directly receives a phone contact. This step eliminates, at the source, any possibility of the model free-styling in areas where its knowledge is blank.

Drafting: the model only fills in the blanks

The language model generates a JSON-format answer based on the matched entries, containing three fields: the answer text, the referenced entry IDs, and the original sentences the answer is based on. The model is restricted to "read-only" access to the selected entries, and temperature is set to zero to minimize randomness as much as possible.

Temperature is a sampling parameter of large language models, typically ranging from 0 to 1 (or 0 to 2), used to control the randomness of output. The lower the temperature, the more the model tends to pick the highest-probability next word, producing more deterministic and conservative output; the higher the temperature, the greater the chance that low-probability words are selected, producing more divergent and creative output, but also making inconsistency and even hallucination more likely. When temperature is set to zero, the model deterministically picks the highest-probability token at every step, and the same input almost always yields the same output—this is called greedy decoding. In scenarios requiring factual accuracy and stable formatting (such as customer-service drafting, structured extraction, and code generation), temperature is usually lowered or even set to zero in exchange for reproducibility and reliability; in tasks like creative writing and brainstorming, the opposite is true. Note that temperature zero does not eliminate hallucination—it merely reduces random fluctuation, causing the model to stably give the same wrong answer when misled by its existing knowledge, so an external verification mechanism is still needed as a fallback.

Triple verification: sentences, numbers, vocabulary

This is the most critical part of the entire system. The draft answer must pass three independent checks:

• Sentence verification: the quoted sentences must appear verbatim in the corresponding entries.
• Number verification: every number in the answer must be traceable to the referenced entries. "4 pm" equals "16:00," but "$4" does not equal "$4.50."
• Vocabulary verification: all semantically meaningful words must appear in the material the model received.

If any check fails, the draft is discarded. When the first step fails, the customer sees the original entry text or contact details; when a later sentence fails, that sentence is simply truncated.

In natural language processing, tokenization refers to splitting a piece of text into smaller units (tokens), which can be words, subwords, or characters, and serves as the foundation for text-comparison operations such as vocabulary verification. In English, space-based tokenization is relatively simple, but abbreviations, hyphens, and punctuation still require care; in languages such as Chinese and Japanese, there are no spaces between words, so meaningful word boundaries can only be obtained by relying on tokenization algorithms (such as dictionary-based, statistical, or neural tokenizers). The tokenization strategy directly determines the granularity of vocabulary verification: too coarse a split misses fabricated content, while too fine a split misjudges semantically empty fragments as meaningful words, causing false positives. In addition, synonyms, morphological variation (such as plurals and tenses), and cross-language mixing also affect matching. For this reason, the vocabulary verification mentioned in the article requires specially designed tokenization and morphological normalization schemes in non-English scenarios; otherwise, a Chinese answer could have every character present in the source text while the meaning of the whole sentence has been distorted.

Degradation: better to say nothing than to say something wrong

The degradation strategy after verification failure embodies the design philosophy of this system. The bot does not try to "repair" the answer; instead, it falls back to displaying the original entry text. This conservative strategy means the bot sometimes appears "dumb," but it never says anything unsupported.

What the test data reveals

The developer wrote 24 test questions with known answers, 6 of which concerned content the website never mentioned (pizza, membership cards, Christmas hours).

The first round scored 17/24. The main reason for lost points was not hallucination, but the model incorrectly labeling "we don't offer this service" as "unable to answer." After adjusting to more precise rules, the second round improved to 21/24.

But the second round exposed a real hole. When asked "Do you have a loyalty card?" the model answered "No, we don't have a loyalty card"—something the website never mentioned at all. Since this sentence contained no numbers, number verification let it through. This is exactly where vocabulary verification came from: "loyalty" was not in any material the model received, so the sentence was judged unsupported.

After adding verification rules, the developer added 7 untuned questions, and 28 out of 31 questions were answered correctly in online operation. One failure came from the developer's own bug: the model output "$8.00" while the website said "$8," and number verification judged it a mismatch. After the fix, the same draft passed 29/31.

The remaining two failure cases are worth attention because the verification mechanism cannot catch them:

• "Are you open on Christmas?" The bot gave regular business hours. Every word was on the website, but it was not the answer the user wanted.
• "Are the cinnamon rolls vegan?" The bot correctly answered "no," but the cited basis pointed to the pastry price entry rather than the vegan entry.

The core problem with such errors is this: an answer in which every word has a source but which is completely wrong in direction can pass all automated checks smoothly. The developer concludes from this that before such bots go live, they need test sets built from real customer questions, not just good prompts.

Do small businesses really have chatbots?

The developer scraped 1,020 Austin business websites from OpenStreetMap (cafes, restaurants, dentists, clinics, salons, bakeries), removed chain brands sharing domains, and made one request to each homepage. 592 loaded successfully, of which 27 had any chat component, and 15 were Wix's built-in owner chat feature. The only ones identifiable as AI assistants all came from chain-brand websites.

The chatbot market looks crowded, but the vast majority of local cafes have no assistant at all. This finding points to a reality: the small merchants who need such tools most are precisely the group with the lowest penetration.

OpenStreetMap (OSM) is an open-source map database jointly edited by volunteers worldwide, licensed under open data terms, allowing anyone to freely obtain, use, and redistribute its geographic data. Through interfaces such as the Overpass API, it supports batch queries of points of interest (POIs) by region and category—for example, all businesses in a city tagged as cafes, restaurants, or dentists, along with their website fields. Compared with commercial map data, OSM's coverage and field completeness vary by region; merchant website links may be missing, outdated, or point to third-party platforms, so sampling research based on it has some bias and is not fully equivalent to an official business registry. However, for a developer conducting low-cost, reproducible industry reconnaissance on their own, OSM is one of the few sources from which structured merchant data can be pulled at scale without applying for a commercial license, and the scraping of over a thousand Austin business websites described in the article was accomplished through this route.

Model-free mode: not even AI needed

Based on this observation, the developer provided a second operating mode. The entire component needs only one script tag. When no model endpoint is configured, it runs in "citation mode": after finding a matching entry, it displays it verbatim, or provides a phone contact. It cannot fabricate anything, and each question costs nothing.

On the 31 test questions, citation mode displayed the correct entry or refused to answer 29 times. But the developer cautions that these questions were already used when tuning the search terms, so performance on new websites may decline. After a model endpoint is configured, the component performs the drafting and verification pipeline, and automatically falls back to citation mode when verification fails.

Design trade-offs worth considering

The value of this project lies not in its technical complexity, but in its clear-eyed understanding of the boundaries of AI deployment. When model capability is insufficient to reliably handle a certain scenario, using deterministic code as a fallback is more pragmatic than optimizing prompts.

Several directions worth further exploration: can the verification layer handle answers combining multiple entries? How should the tokenization strategy for vocabulary verification be designed in non-English scenarios? Is the cost of building a test set acceptable for small merchants? The developer himself poses a question at the end of the article: "What else would you check that I haven't checked?"