The 1989 search theory that explains why generative AI misses the mark

The most cited idea about the limits of generative AI search wasn't born in any language-model lab. It's in a 1989 paper by Marcia J. Bates, an information scientist at UCLA, who described how people actually search for information: not with one question and one final answer, but by gathering pieces of meaning from various places, changing their minds along the way. It's the central argument of a piece published on UX Collective, written by Patrick Neeman, who met Bates in person at the IA Summit in Chicago in 2018.

Bates named this behavior berrypicking: picking berries scattered through the forest, one at a time, instead of finding a single bush with all the fruit. In the paper The Design of Browsing and Berrypicking Techniques for the Online Search Interface, she attacked the classic model of information retrieval, which treats every search as a single query, matched once against a database, until it produces a supposedly ideal set of results.

typical search queries are not static, but rather evolve.

Marcia J. Bates, information scientist, UCLA

Thirty-seven years later, the chat box of any generative AI assistant repeats exactly the model Bates tried to tear down: one question, one answer, done. The difference is that now the answer comes with impeccable grammar and an authoritative tone, which makes the problem harder to notice.

Four ways to search, and only one of them is berrypicking

Bates distinguished berrypicking from three other search behaviors that look the same from the outside, but aren't:

• Known-item search: the person knows exactly what they want (a file, a fact), and one query either resolves it or doesn't.
• Iterative refinement: the person rephrases the question several times, but the final target doesn't change; it's the behavior researcher Gerard Salton tried to automate with relevance feedback.
• Browsing: the person skims and samples within a single place; it's a move within a larger search, not the whole search.
• Berrypicking: the information need changes while the person searches, and the final answer comes in pieces from different sources.

This distinction matters because it changes what counts as success. A classic system can be evaluated by precision and recall on a closed set of results. A berrypicking search has no single set to measure, and Bates called simply knowing when to stop "one of the fundamental problems of search strategy."

A thumbs-up on a chat answer measures the last berry picked, not the whole picking process. And one point the UX Collective piece underscores: sometimes what matters most is what wasn't found, like the absence of a legal precedent or a conflicting clause in a contract. A system that always returns a confident answer hides exactly that signal.

The study that shows AI getting lost when the question changes

This fragility showed up in recent concrete data. The 2025 study LLMs Get Lost in Multi-Turn Conversation simulated more than 200,000 conversations and tested the leading language models on six tasks delivered gradually, rather than all at once. Every model got worse when the task arrived in pieces, with an average performance drop of 39%. In other words: the models bet early on one interpretation of the question and don't recover well when it changes.

The Nielsen Norman Group documented a practical consequence of this in Accordion Editing and Apple Picking: Early Generative-AI User Behaviors: users manually copying pieces of a previous answer to paste into a new prompt, because the interface gave no other way to point to that passage. It's berrypicking done the hard way, with cut and paste as the only tool available.

Naming the tactic helps more than optimizing the prompt

Years before berrypicking, Bates had already named 29 search tactics in the paper Information Search Tactics, awarded best paper of the year in the field. The logic was simple: naming a move makes it easier to teach and reuse. Among the tactics:

The same problem that existed in reference libraries repeated itself on Google (people learned, by trial and error, to reduce questions to two or three keywords) and repeats now in chat, where each user discovers on their own which phrasing pulls out a useful answer. A blank prompt box comes with none of these tactics built in.

This has a measured effect on click behavior. Microsoft researchers Ryen White and Dan Morris found marked differences between people who used search operators and those who didn't, both in how they queried and in the results they got. In an experiment cited by Marti Hearst in her book on search interfaces, 91% of 32 art history students preferred a faceted search interface over a simple one, even though it was slower to use. Filters and facets are Bates's tactics turned into buttons, instead of requiring the user to turn them into a prompt.

Automation has degrees, and most products jump straight to level 4

In 1990, Bates proposed a scale to answer a question every AI product team faces today under deadline: where the person should stop and the search interface should begin.

1. Level 0: the system doesn't help at all.
2. Level 1: explains the possible moves (a help panel with search operators).
3. Level 2: executes a move on command (a filter that runs when the person clicks).
4. Level 3: watches the search and suggests the next step (a "did you mean" or a follow-up question).
5. Level 4: conducts the entire search alone, with or without explaining its choices (the research agent that disappears for minutes and comes back with a ready-made report).

Bates argued that research at the time fixated obsessively on level 4, while most real searchers wanted speed combined with control over strategy, not one or the other. It's almost the same description Jakob Nielsen would use decades later to characterize generative AI as a reversal of the locus of control, in which the user states the desired outcome and the system chooses the method.

In short: jumping straight to level 4 and calling it an agent also skips the step where trust gets built. People tend to trust the automated system even when it's wrong, a bias Patrick Neeman documents on his website on UX guidelines. The alternative is to choose the automation level per task, and let the person move that dial.

A fluent answer built on a bad index is still a bad answer

Bates's 2002 paper, The Cascade of Interactions in the Digital Library Interface, lists the layers beneath any search experience: infrastructure, content, metadata, indexing, and the search engine, with the interface and the person on top. Decisions at each layer affect everything above it, and no interface polish fixes a bad choice down below.

Swap "digital library" for "RAG-based assistant" (retrieval-augmented generation) and little changes. Above the model is the chat window the team keeps refining. Below it are document repositories, chunking rules, and permissions set up years ago for a different purpose. The demo runs fine on 20 clean documents; production runs into a decade of duplicate policies and unlabeled drafts.

The Gartner report Lack of AI-Ready Data Puts AI Projects at Risk, published in February 2025, projects that organizations will abandon 60% of AI projects lacking ready data by 2026. The same survey already showed the current picture: 63% of organizations didn't have the right data practices in place, or didn't know whether they did.

Hiding browsing costs clicks, and costs context

Bates returned to the topic of browsing in 2007, describing it as a sequence of glimpses: the person takes in an entire visual field, selects something, examines it, decides to keep or discard it, and repeats. It's an exploratory behavior she linked to the way animals search for food and shelter, which is why no one needs to learn it from scratch.

The generative AI summary pushes people toward the opposite of this: waiting at a kind of information desk until someone (or something) hands over the ready-made answer. The Pew Research Center measured this effect in March 2025, tracking the browsing of 900 American adults on Google. When an AI-generated summary appeared in the results, people clicked a link 8% of the time, versus 15% when there was no summary; the session ended right there, with no click at all, on 26% of pages with a summary, versus 16% on pages without one.

Part of this is the summary doing its job well. Part of it is someone who never saw the original source, because they never knew they could ask for it.

The berrypicking test for product designers

Neeman proposes a simple test for any search assistant or generative AI on the roadmap: does the product expect the question to change, or does it punish the change? Does it name the search moves, or does it force the person to invent them alone? Can you choose how much the system decides on its own? And is there someone accountable for the content behind the answer?

Four concrete actions come straight out of Bates's material, adapted for today's product designers:

• Show the question history: keep a summary of what the person has already asked visible, and let them edit an earlier question without opening a new chat.
• Add refinement controls: buttons to narrow, exclude, broaden, and compare against the original request next to each answer, instead of requiring that to become a prompt.
• Set the automation level per task: decide which tasks the system only suggests on and which ones it can act on alone, with a setting the person can change.
• Fix the metadata before the interface: label documents by type, owner, date, and status, define terms in a shared semantic map, and show the sources behind each answer, including when nothing relevant was found.

Generative AI's single answer is impressive. But it's the same classic model Bates spent decades arguing against, just with better grammar. Anyone designing search or a generative AI assistant gains more by testing the product against the question that's still forming than by optimizing the perfect answer for the question that already arrived complete.