DEV Community: GetAskAI - Free Ask AI

Stop Using a Keyword List to Decide When Your Chatbot Searches the Web

GetAskAI - Free Ask AI — Sun, 06 Sep 2026 10:10:11 +0000

A keyword list is the wrong shape for routing a chatbot to web search. It matches fragments instead of meaning, it breaks the moment you support more than one language, and it fails silently in the expensive direction: the question that needed a lookup and did not get one. Let the model make the call instead, with a short prompt built on an inverted default. Here is the bug that taught me this, and the prompt shape that replaced it.

Last updated: September 2026.

The bug

The chat had a cheap gate before the expensive part. If the message contained a trigger word, run a web search and answer from the results. Otherwise answer directly. The list held the obvious things: price, weather, today, score, plus the currency words for every language the product supports.

One of those was the Turkish word for exchange rate: kur.

The German word for "briefly" is kurz.

A user wrote "Sag kurz Hallo", roughly "say a quick hello". The substring match found kur inside kurz, the gate fired, and the system paid for a web search in order to answer a greeting.

That is a funny bug. The unfunny part is what it revealed.

Why the list was never going to work

Substring matching has no word boundaries across languages. You can bolt on tokenisation, but you are now maintaining locale-aware word splitting for something that was supposed to be a cheap shortcut.

It is always wrong in both directions. It fires on greetings and stays silent on "is my residence permit application still processed the old way", where being a year out of date is genuinely harmful. Adding words fixes today's miss and creates tomorrow's false positive. I went three rounds of this before admitting the shape was wrong.

It scales with languages, not with logic. Eleven languages meant eleven sets of triggers, and every new language meant another translation pass by someone guessing which words natives actually type.

It cannot see intent. "Explain inflation" and "what is inflation right now" share their meaningful words. Only one needs a lookup.

" width="800" height="306">

What replaced it

Let the model decide, and give it a shape it can follow. Two mechanically different options depending on your stack:

Approach	How it works	Use when
Tool calling	Expose a `search_web` tool; the model either answers directly or calls the tool with a query it wrote itself	Your model supports function calling
Cheap classifier hop	One small call returns either a search query or the literal token `NO_SEARCH`, then you branch	No tool calling, or you want the router on a different model

Both share the property that made the difference: the model reads the whole sentence instead of pattern matching on fragments. It also writes a better query than the user's raw message, which turned out to be a larger quality win than the routing decision itself.

The prompt shape that worked

This is the part I got wrong twice, so it is the part worth copying.

My first instinct was a detailed, categorised list of what deserves a search: prices, weather, sports, news, regulations, each with examples. The score went down. A small routing model gets lost in a long taxonomy.

What worked was shorter and inverted. Around two hundred words with three moves:

Set the default to search. Not "search when needed" but "search unless the question is on this closed list".

Keep the exception list closed and concrete. Arithmetic, greetings, translation, grammar, code, creative writing, summarising text the user pasted in, and textbook facts that are the same in every country and every year. Everything else is a search.

Give two decision tests instead of categories. Does the answer change depending on the user's country or the current year? And what does a wrong answer cost this person: money, health, legal standing, safety, a missed deadline? If either trips, search.

Then one closing line that matters more than it looks:

Search these even if you think you already know the answer.

The inversion is the trick. A list of things to search is infinite and you will always be adding to it. A list of things not to search is small, stable, and a model can hold it in mind.

Measure it, or you are guessing

Build a fixed evaluation set before you touch the prompt. Mine is thirty questions: fifteen that must search and fifteen that must not, spread across several languages and domains.

Must search	Must not search
Family law question with a country in it	Greeting
Rent or tenancy rule	Arithmetic
Visa procedure	Translation
Drug interaction	Grammar correction
Live exchange rate	Code question
A specific local business	Write me a poem
Product comparison	Textbook fact
Tax or fee amount	Summarise this pasted text

Run the whole set after every prompt change. Two things this catches that spot checks never do: a change that fixes your new case and breaks two old ones, and a router that has quietly become search-happy, which always looks correct if you only inspect the questions that should search.

Both of my "improvements" scored worse than the version before them. I would not have known without the set.

For scale, in production this router now sends 18.1 percent of questions to a live search over a 60 day window of 5,977 answers. The remaining 82 percent are answered directly, which is the entire economic point of routing rather than searching on everything.

Two things I would not do again

Do not put a time budget inside the router. I briefly capped the routing stage so it could not slow the reply down. What it actually did was make the system give up early and fall through to the expensive path anyway. Correctness first, then optimise.

Do not let a strong style prompt fight the router. The main system prompt tells the model to be direct and expert. That instruction was competing with routing and pushing the model toward answering from memory. If the router shares a prompt with the personality, the personality wins. Give the routing decision its own explicit sentence rather than assuming the tool description covers it.

The general lesson

The keyword list was not too small. It was the wrong kind of thing. Any rule that pattern matches on fragments of language will fail across languages, and it will fail silently in the direction that costs the most.

If you are building anything that chooses between a cheap path and an expensive one based on what the user wrote, the model is a better judge than your list, provided you give it a short prompt with an inverted default and a closed set of exceptions.

And keep the greeting in your test set. That is how I found out.

" width="800" height="390">

This is from building GetAskAI. GetAskAI is a free, ad-supported AI chat that works without an account. It answers in 11 languages, searches the web and shows numbered sources when a question needs current information, and reads PDFs and images without storing them.

How I built a free, unlimited, no-login AI chat and kept abuse under control

GetAskAI - Free Ask AI — Fri, 17 Jul 2026 17:52:26 +0000

Every AI chat I tried wanted something before the first question. An email. A verification link. A card, "just to confirm you're human." Or it let me in and started counting: five messages, then a wall.

So I built GetAskAI: a free AI chat with no login, no app and no message counter. You open it, type, get an answer.

Then I found out what that actually costs.

This post is about the part nobody puts on the landing page: when you remove the account, you remove the one thing that makes abuse control easy, and you inherit a bill that scales with strangers.

Why no login is a technical decision, not a marketing one

The pitch writes itself. No signup, no friction, ask and go.

The engineering reality is less fun. An account is not just a retention hook. It is:

a stable identity to attach usage to
a natural rate limit boundary
a cost ceiling per human
an abuse trail you can ban

Delete it and every one of those disappears at once. You are now serving inference, the most expensive thing on your bill, to anonymous traffic, with no way to say "this is the same person as five seconds ago."

That is the whole problem. Everything below is a consequence of it.

The bill is the constraint, not the traffic

Most side projects have a fixed cost and variable traffic. A spike is a bragging right.

An LLM product inverts that. There is no meaningful fixed cost to amortise. Every request costs real money, and the cost scales linearly with usage. A traffic spike is a cost spike. Going viral is an invoice.

Which means the honest framing is not "how do I stop bots." It is:

Every request has a price. My job is to make sure a human asking a real question always gets served, and everything else gets served last or not at all.

Rate limiting stops being a security feature and becomes a business model. That reframing changed every decision after it.

Why the obvious answers do not work

I am not going to publish my exact setup, mostly because writing down your abuse rules is how they stop working. But it is worth saying why the first three things everyone reaches for are weaker than they look.

IP limits. Carrier-grade NAT puts entire mobile networks behind a handful of addresses. A university, an office, a co-working space, all one IP. Set a limit tight enough to stop a script and you have banned a country's mobile users on a bad day. And residential proxy pools rotate through real consumer IPs, so a determined scraper looks like a hundred innocent people. IP is a weak hint, not a boundary.

Browser fingerprinting. Technically effective, and it quietly destroys the product. The whole promise is that I do not build an identity for you. Fingerprinting builds one anyway, just without telling you. It is the same tracking with worse ethics. I decided this was off the table, and I want to be clear that this is a values call, not a technical one. It costs me abuse resistance. I pay it.

CAPTCHA on everything. Kills the thing that makes the product worth using. The whole point is five seconds from question to answer. A puzzle in front of every message is a signup form with extra steps.

What actually worked, in one line

Stop thinking about who and start thinking about cost.

I do not need to know your name. I need to guarantee that any single visitor, whoever they are, can never cost much, and that the cheap path is the default while the expensive things stay the exception. Once you frame the problem that way, most of the design follows from it, and none of it needs an account.

The principle underneath all of it: degrade, do not block. Suspected abuse gets slower, not a hard error. A false positive then costs a real person a little latency instead of their answer. When you cannot identify people you will have false positives, so make them survivable.

On live answers and files

Two things people always ask about.

A model on its own is a frozen snapshot, so anything genuinely recent is a confident guess, which is the worst kind. There is a step that pulls in fresh information when a question needs it, used sparingly rather than on every message, because that is expensive too.

And files. Images and PDFs work, and they are never written to disk. A file is held only long enough to answer the question, then it is gone. That is not a policy line, it is architecture: a file that is never stored cannot leak, cannot be subpoenaed, and cannot be sold by whoever buys the company later. It also means I cannot debug your failed upload, which is a real cost I accept.

Would I do it again

Yes, with less certainty than I had at the start.

The no-login decision is genuinely good for the user and genuinely bad for the business in every measurable way. No email list. No retention. No cohort analysis. Every visit starts cold. I have no idea if the same person came back yesterday, and by design I never will.

What I would tell someone about to do this:

The rate limiting is the product. Not a chore you bolt on later. If you cannot serve one human cheaply, you cannot serve a thousand at all.
Degrade, never block. You will have false positives. Make them cost latency, not the answer.
Decide what you refuse to build before you need it. Fingerprinting looks reasonable at 3am during an attack. Decide at noon.
Ads are a cleaner incentive than a free tier. With a paywall I would spend my time tuning where the wall goes. With ads, the tool being good and the tool making money point the same direction.
Costs scale with strangers. Budget for the spike you want, not the traffic you have.

Not a business yet. A tool that pays for itself, if the ads hold.

It runs at getaskai.com. If you find a hole in the rate limiting I would genuinely rather hear it from you than find it on the invoice.

Happy to talk about the tradeoffs in the comments.