LLMs vs. Search Engines
Search hands you the bookshelf; an LLM hands you a conclusion. Answering from memory means there's no source to check.
A search engine finds the page where something lives. An LLM speaks its answer straight from memory. Same question, two different deliverables.
Signs you'll recognize:
- It gives a very authoritative-looking number, and you can't find its source anywhere.
- It mixes up two similar products — both descriptions are right, they're just assigned to the wrong ones.
- You ask for a link and get a perfectly formatted URL that doesn't open.
Where they differ
When a search engine works, the original text stays present. It builds an index, matches, ranks, and returns "this passage is on that page of that document." You click and see the sentence, who wrote it, and when.
A model is different. After training, the corpus is discarded — what remains is a pile of weights. Those weights don't remember "which sentence appeared where"; they encode "what kind of content usually follows what kind of content." The corpus's statistical regularities are compressed into parameters; the corpus itself isn't stored on disk.
So "it remembers that paper" is imprecise. It remembers the phrasings, structures, and terminology combinations common in papers like that one. When answering, it reassembles those things; it doesn't retrieve them.
Three consequences of answering from memory
Confused facts. The weights carry no marker for "this fact belongs to that paper," so similar content contaminates each other. Prices of two comparable products, parameters of two APIs with the same name, data from two adjacent years — the most likely things to get fused. And once fused, it answers smoothly anyway. The hallucination literature maps exactly this failure mode and its variants. hallucination-survey
A knowledge cutoff. The weights freeze at the end of training. Versions released after, APIs changed after, policies replaced after — none of it exists, yet it extrapolates from pre-cutoff patterns into an answer that sounds reasonable.
No provenance. This is the killer: it can't give you a source, but it can fabricate one. Link formats, author names and years of papers, clause numbers — all strong statistical patterns, trivially easy to invent. Treat any citation it volunteers as unverified until proven.
What about search-then-answer
Many products now search first, then answer. That genuinely fixes part of the problem — but know which part.
Search-then-answer does this: pull a few real passages into this request's input and have the model write from them. That's retrieval-augmented generation, the setup named by the original RAG paper. rag-paper The benefit: there are sources. The catch: it is still generating. If the retrieved passages are incomplete, it fills gaps from memory; if they contradict each other, it picks the version that flows better.
So even with citations, do two things: click the link to confirm it's real, and confirm the quoted sentence is actually on that page. The second fails more often — the link is real, but the sentence is the model's own retelling.
And one product judgment: when provenance matters, control the retrieval layer yourself. Don't let the model freely decide where to look. Constrain which libraries, which documents, which time range it may use. Narrow the scope and the verifiability of answers jumps immediately.
None of this makes models useless for fact-finding — it puts them in the right role. Use a model to reshape, summarize, and structure material you can already verify, and keep search (or your own retrieval) for establishing what the facts are. The two tools aren't competitors; they're different stages of the same pipeline.