Why a sales assistant must never invent a price

A language model does not know your prices

A language model predicts the most likely next word. It consults no database, it checks nothing: it produces a sequence of words that looks like a good answer. Asked for a price it was never given, it produces one that looks right, in the right currency, with the right order of magnitude. Nothing in the sentence gives the invention away.

That is what makes the error dangerous. A spelling mistake is visible; a wrong price is not. The merchant discovers it on delivery, when the buyer refuses to pay the difference.

What the error really costs

• The parcel goes out, the buyer refuses: the outbound trip, the return and the product tied up are all on the merchant.
• Or the merchant honours the price quoted, and sells at a loss rather than lose the customer.
• Either way, trust is dented, and the buyer tells the story around them.
• In markets where payment happens on delivery, that error is paid in cash, not settled as an invoicing dispute.

The false solutions

The first is to politely ask the model not to invent. That is an instruction, not a constraint: it lowers the frequency of the error, it does not remove it. Sooner or later, on an unusual question, the model will invent again.

The second is to hand it the catalogue and hope it sticks to it. That helps a great deal, but nothing stops it mixing one item's price with another item's reference, especially when the question covers several products.

The third is to hide prices and send the buyer to the product page. The problem disappears, and so does the sale: someone who asks “bch'hal?” wants an answer, not a link.

The only method that holds: check afterwards, not just ask beforehand

The approach that works separates two roles. The language model writes the sentence, because that is what it is good at. The application checks what it wrote before the buyer reads it.

1. 1The context is assembled: the relevant products with their prices, the product-page figures, the total computed by the application, and what the buyer wrote themselves.
2. 2The model drafts its answer from that context, and from nothing else.
3. 3The application extracts every number in the answer and checks that each one exists in the context provided.
4. 4A number from anywhere else gets the answer rejected: the model is told about its mistake and tries again.
5. 5The amounts displayed are read back from the database just before sending, and rendered from a template, never copied out of the sentence.

This mechanism has a useful side effect: it makes the assistant honest about its limits. When the data is missing, it cannot manufacture it, so it says so and hands over. Those unanswered questions become the merchant's best to-do list: they say what the catalogue does not yet specify.

What the verification does not cover

It protects figures: prices, quantities, totals, dimensions, delivery times stated on product pages. It does not protect qualitative claims. If your page says “wool”, the assistant will say “wool”; if it says nothing about origin, it must say nothing about origin.

Hence the most profitable rule for a merchant: complete your product pages. An assistant constrained by the catalogue is exactly as precise as the catalogue itself.

How to test it in five minutes

1. 1Ask for the price of a specific item, then for one you do not sell.
2. 2Ask for a delivery time to a city you do not serve.
3. 3Ask for a discount on three items, to see whether a total is computed or invented.
4. 4Ask the same question twice, worded differently: the figures must be identical.

An assistant that passes those four tests can talk to your buyers. An assistant that fails a single one will one day speak in your place, and you will find out which one on delivery day.