Chatbots that stay current: retrieval, freshness and when to refuse

A language model knows what was in its training data and nothing that happened afterwards. It does not know this morning's exchange rate, whether your service is down, or what a competitor changed on its pricing page last week. A chatbot that people will ask about current matters therefore needs three things the model cannot supply: a retrieval step that fetches the right material at question time, a working definition of “current” for each kind of question, and a rule for when to say it cannot answer. This guide covers all three, for web-grounded answers, live data feeds and multi-turn assistants alike.

Decide what “current” means for each kind of question

Not every question needs fresh data, and treating them all the same either wastes time or produces stale answers. Sort the questions your users actually ask into freshness classes:

A small router at the front of the bot classifies each question and picks the path. Searching the web to define a well-known term adds delay and a chance of pulling in a bad page; answering a live-state question from model knowledge is simply wrong.

Design the retrieval step

For questions that need documents, the retrieval step does most of the work. A sequence that holds up:

1. Rewrite the turn into a standalone query. In a conversation, users say “and what about their enterprise plan?” or “is that true in Germany too?”. A search engine has no idea what “their” or “that” refers to. Resolve the references from the conversation first.
2. Choose the source. Your own knowledge base, a web search API, a news search or a structured API, according to the freshness class.
3. Fetch the pages, not just the snippets. Snippets are truncated and sometimes cached from an older version. For the top few results, read the page itself.
4. Select passages. Keep the parts that address the question, along with each page's URL, title, published or updated date and the time you retrieved it.
5. Answer from the passages, tying each claim to the passage it came from.

The rewriting step is the one most teams skip and most users notice. A simple example:

Conversation:
  User: Which project tools offer an on-premises option?
  Bot:  ...lists three tools...
  User: Does the second one support single sign-on?

Standalone query:
  "[second tool's name] single sign-on support documentation"

For the plumbing behind this, see what a web search API is and RAG with live web data.

Real-time data belongs in tools, not search

Search finds documents. It is the wrong instrument for state that changes by the minute: stock levels, order status, account balances, exchange rates, service health, a flight's departure gate. For those, give the model a tool that calls the system of record directly.

A good real-time tool is narrow and typed, and it returns its own timestamp and source so the answer can say “as of”:

get_order_status(order_id: string)
  returns: { status, carrier, updated_at, source_system }

A few rules keep these tools honest. Cache only for as long as the freshness class allows; a service status cached for an hour is no longer a status. Return an explicit error when the upstream system is unreachable, rather than an empty value the model might read as “nothing”. And keep tools that read apart from tools that change something. Looking up an order is harmless; cancelling it or changing the delivery address should wait for the user to confirm. In GoCux Conversation, any tool call that would modify something is held until you confirm it.

Freshness rules the answer must follow

Retrieval brings in current material; these rules make sure the answer does not undo that work:

• Show the date. Any volatile fact carries its “as of” time or the date of the source it came from.
• Prefer the most recent authoritative source, and when two sources disagree, say so and show both with their dates rather than silently picking one.
• Treat undated pages with suspicion for time-sensitive questions; flag them or leave them out.
• Do not let history override retrieval. A price the user mentioned yesterday, or a fact stored in the bot's memory, is not today's price. Memory is useful for preferences and context, not as a live feed.
• Retrieve again on time-sensitive follow-ups instead of reusing passages from earlier in the conversation.

Cite what you read, and know when to refuse

Every factual claim in an answer should point to the passage that supports it, using the URL of the page that was actually read. Never let the model produce URLs from memory; a plausible-looking link is not evidence, and a tidy footnote can point at a page that says something else. The sibling guide on chatbots that cite their sources goes deeper into citation formats and checks.

Deciding when not to answer matters just as much. A chatbot should decline, or answer partially and say so, when:

• retrieval failed or the source was unavailable, which is different from a search that ran and found nothing;
• sources were found but none of them supports an answer to the question asked;
• sources conflict and the conflict cannot be resolved from what was retrieved;
• the answer would require an action or authority the bot does not have;
• the question falls outside the scope the bot was built for.

A good refusal is specific and offers a next step:

I could not reach the pricing page just now, so I cannot confirm today's price. The last version I have was retrieved on [date]. Would you like to see it, marked as possibly out of date?

That is a useful answer, not a failure. A refusal is a result makes the case in more detail.

Where GoCux fits

GoCux is not a web search API and does not read the open web, so it is not the retrieval backend for a public web chatbot. It covers the parts of this design that concern evidence and review. Knowledge search answers a question scoped to one project's documents with passages and their citations; an empty result is reported as a valid answer, and “unavailable” is reported as something different. Responses prepares an answer for review before it leaves the workspace, which matters when the reply is headed to a customer. Web material can be brought into a project through an authorized browsing or export step, and it keeps its original page reference and retrieval date, so a source's age stays visible after import.

What to test before launch

Build a small evaluation set of time-sensitive questions whose answers you have verified as of a known date, and rerun it on a schedule, because the right answers move. On each run, check that:

• Every volatile claim shows an “as of” time or a source date.
• Citations open, and the cited passage supports the claim.
• Follow-up questions are rewritten correctly into standalone queries.
• Live-state questions go to tools, not to search.
• When a source is down, the bot says so instead of guessing.
• Tools that change something wait for confirmation.
• Conflicting sources appear as a conflict, with dates.

For ways to compare retrieval backends on your own questions, see evaluating web search on your own queries.