当 AI 学术检索自行生成查询文本：Aaron Tay 分析语义检索中的假设性文档扩展

An “evil conspiracy”

I think I may have discovered the “evil conspiracy” behind why academic search vendors are so reluctant to show us what happens on the semantic side of AI search.

Thanks for reading Aaron Tay's Musings about Librarianship! Subscribe for free to receive new posts and support my work.

Recently, I have been wondering about a strange asymmetry. I noticed that when academic search vendors use AI to expand lexical searches, they are almost always happy to show you what they did.

For example, Web of Science Smart Search will happily show you the Boolean search it used. The same is true of products such as EBSCO AI-assisted Search, scite Assistant, Primo Natural Language Search and many others.

Then you get to the semantic-search part, and suddenly the curtain comes down.

Take Web of Science Smart Search again. We are told it runs a hybrid search, meaning it runs both lexical and semantic searches in parallel, combines the results and then somehow ranks the combined list.

Yet we know almost nothing about what happens in the semantic-search portion, beyond the fact that it was done.

What exactly was searched? Did they expand your query before embedding it? Why all the secrecy?

Similarly, Scopus AI has a copilot that decides “whether to run a vector search (aka Semantic Search) and/or a keyword search”. Yet again, all the interface displays is the expanded Boolean Search.

Recently, while studying a new AI search system, I accidentally got a look backstage.

And I discovered a shocking “truth”. The system was generating document-like passages for semantic retrieval rather than simply embedding my original query.

They were not just synonyms or alternative search terms. The generated passages could introduce assumptions that were never part of my question, or even contain outright false statements.

Imagine entering the following query:

Can Google Scholar be used alone for systematic reviews?

And finding out that, behind your back, the AI generates the following for expansion:

Google Scholar is not sufficient as a standalone source for systematic reviews because studies have shown that while it indexes almost all relevant research, it is difficult to retrieve all the relevant papers within the top 1000 results it allows access to.

Hold on a moment. I never said Google Scholar was not sufficient! That’s precisely what I’m trying to find out! Why is the system apparently answering my question before it has even searched?

Now the reason for the “conspiracy” seemed obvious.

Vendors don’t want us to find out that semantic search is being fed hallucinated AI-generated query strings!

Okay, okay, I was just being facetious here. There is NO evil conspiracy.

This is not to say that systems never do something similar to what I have described. They may generate text resembling relevant documents to help with retrieval, but that text could introduce assumptions that do not reflect the user’s information need or even contain outright falsehoods. Such additions could potentially introduce bias if used in a traditional search.

But what I have described is not necessarily problematic. In fact, it resembles established techniques such as Query2doc and HyDE for expanding semantic searches.

While it may seem strange, the fact is:

A generated passage that is not entirely accurate or true can still be useful, perhaps even more useful than the original query, when embedded for semantic retrieval.

Confused? Let me start from the beginning.

What the system was actually doing

The system itself was fairly typical of the current generation of AI-powered academic search tools.

There was a query interpretation step, probably involving an LLM. The system identified things such as entities that could be turned into filters, then ran a hybrid search combining lexical and semantic retrieval.

The results were merged and deduplicated, and an LLM was then used to classify them (by prompting) into relevance categories such as “Very relevant” and “Relevant”.

None of this is especially unusual, and you can see parts of this process in many academic search systems. For example, using LLMs to extract relevance criteria and then classify results is something we see in AI2’s Asta Find paper. But let’s focus on the even more common idea of hybrid search.

Hybrid search is becoming increasingly popular in the search industry. Typically, it involves running both lexical or keyword searches and semantic searches.

The logic is straightforward. Lexical search is good at matching words and phrases. Semantic search can retrieve documents that express similar ideas using different language.

This potentially gives you the best of both worlds. You just need a way to combine both sets of candidate results and rank or rerank them somehow.

So far, so good. But let’s look at the interface (which I have mocked up) that was shown to me.

When it comes to lexical search, we are shown quite a lot. We can see that it runs the original query and two expanded, nested Boolean search strategies (probably generated by an LLM).

But on the semantic side, we are told almost nothing, except that two searches were conducted.

Why this distinction?

A hint from the vendor

When I was interviewed by the vendor, I naturally asked for more details about what was happening on the semantic search side.

Intriguingly, the vendor told me that an earlier version of the product had exposed more of the internal search process. However, users found it confusing, so some of the details were removed.

My reaction at the time was predictable. I did not understand this view at all. Surely more transparency would be better?

Perhaps they could even add an advanced mode for those who wanted more information.

But then I discovered some of the details that might have been hidden, and I began to empathise with why the vendor had chosen not to show everything.

How I accidentally got behind the curtain

While testing the reproducibility of the search, I ran into a completely different problem. No matter what I did, the system seemed determined to cache the results.

While troubleshooting this, on the advice of ChatGPT, I started recording the browser’s network traffic using Chrome DevTools. We will revisit this in a future post.

This produces a HAR, or HTTP Archive, file: essentially a log of the requests and responses exchanged between your browser and the servers behind the application.

As a side effect, this exposed considerably more of the search pipeline than the interface itself did.

The logs confirmed that the system was running:

My original lexical query;
Two additional nested Boolean searches;
Two semantic searches.

There were also hints on many details. For example, about how many of the top results from each search were retained and how they were combined. But for now, let’s focus on semantic search.

While there was very little information about the actual embedding model used, there was something more interesting.

I could see the actual text being used for semantic retrieval, and it was definitely not my original query.

Roughly speaking, the system appeared to be doing the following:

Original query + an LLM-generated short description of what a relevant document might look like

In short, it appeared to be taking my query and appending a chunk of LLM-generated text before creating the query embedding.

Those with some training or knowledge of information retrieval will recognise this as resembling a family of techniques such as Query2doc-style expansion or HyDE (Hypothetical Document Embeddings).

I spend quite a bit of time testing AI-powered academic search tools and trying to work out what is really happening behind their interfaces. If you find this kind of independent investigation useful, please consider buying me a coffee on Ko-fi. It helps support more investigations like this, which I share freely on this blog.

A very quick semantic-search recap

If you are already familiar with how embeddings and dense retrieval work, feel free to skip this section.

As I have noted many times on my blog, “semantic search” is not a single technique. It is better understood as an objective: retrieving or ranking items according to their estimated meaning.

It is typically contrasted with lexical or keyword search, where retrieval and ranking depend primarily on matches between terms in the query and terms in the documents.

The techniques used to achieve semantic search have changed over time. In recent years, semantic search has often, though not always, referred to dense retrieval or dense vector search.

In a typical dense retrieval system, the query is passed through an encoder model, often based on the Transformer architecture, to produce an embedding: a vector representation (a long series of numbers) intended to capture useful aspects of the query’s meaning1.

Documents, passages or text chunks are encoded in a similar way, usually in advance during indexing. The query embedding can then be compared with these precomputed document embeddings.

Both query and document embeddings are represented as vectors: long sequences of numbers. The system calculates a similarity score between them, commonly using measures such as cosine similarity or dot product. Documents whose vectors are closer to the query vector are treated as better candidates for relevance.

Important to note: the query and document do not necessarily need to contain the same terms to be considered similar. Rather, the encoder is able to convert texts that are similar in “meaning” into representations that end up close together in vector space.

The idea behind Query2doc-style expansion and HyDE-style semantic expansion

Conceptually, for dense retrieval, what we are doing is this:

Query → embedding → find nearby document embeddings

Semantic search via embeddings is inherently something of a black box

While a Boolean search like

("artificial intelligence" OR "machine learning") AND libraries

allows you to inspect the search strategy to understand why some documents are retrieved and others are not. Embedding retrieval, however, is much less transparent.

Firstly, it is extremely difficult to interpret the long series of numbers representing each query or document. Secondly, even if I gave you the calculated similarity score between a query embedding and a document embedding, that would still not provide a satisfying, human-readable explanation of why they are close.

I have long expected this to be unavoidable.2 But surely vendors can at least tell us what text they embedded?

How the query is expanded and transformed before being converted into embeddings

So why don’t we just use the query as entered? While this can work in practice, one approach that can improve retrieval is to do the following:

Use an LLM to generate a document, or at least part of one, that might be relevant.
Use that generated text to help construct the query representation for retrieval.

The generated pseudo-document or hypothetical document is then used to help with retrieval.Query2doc appends the generated pseudo-document to the original query before passing the combined text through an encoder to create the query embedding3. HyDE directly generates the embeddings of the generated hypothetical documents (without the query) and in some variants will average that embedding with that of the original query embedding.

Another related technique is RAG-Fusion, used by Elsevier’s Scopus AI. Rather than generating hypothetical documents as HyDE and Query2doc do, it generates multiple variations of the original query, runs separate vector searches and combines the results using Reciprocal Rank Fusion. Like HyDE and Query2doc, it can potentially introduce assumptions not present in the original query. However like HyDE etc empirically it gives better results by generating more rounded deep research reports as queries consider different aspects of the query space.

Empirically, this can work better than using the original query alone. Why?

One way of thinking about it is that the query itself is typically quite different, in terms of expression, length and so on, from a relevant document containing the answer. The logic, then, is that by generating a document that might be relevant, its embedding may end up closer to the embeddings of the desired documents than the original query embedding would.

When the hypothetical document has the answer, or makes one up

Imagine your query is:

Can you use Google Scholar alone for systematic reviews?

And you get a fairly neutral hypothetical passage explaining what systematic reviews are, why comprehensive searching matters, and so on.

I think most of us would be okay with that.

But what if it generates something like this?

Google Scholar should not be used alone for systematic reviews because it only displays approximately 1,000 search results at most and lacks the advanced search functionality needed to retrieve all relevant studies.

This is, to my knowledge, true. But would using this passage for retrieval introduce bias into the results?

Or worse, what if it uses this?

Google Scholar can be used alone for systematic reviews because Tay(2024) has shown that more than 99% of papers eventually included in a SR can be found in Google Scholar’s index.

For those unfamiliar with the literature, there is no such Tay (2024) paper, although real studies have reported very high coverage of studies included in systematic reviews within Google Scholar.

That said, the problem is that being indexed is not the same as being retrievable through a search. Google Scholar restricts access to roughly the first 1,000 results, so even if most relevant papers are in its index, there is no guarantee that a search will surface them.

Surely that last hypothetical passage would produce horrible results?

Not necessarily.

Remember, the system is not necessarily treating the generated text passage as a factual answer. It is using the text to construct a representation for retrieval.

Even though the passage contains a fabricated citation and a potentially misleading conclusion, it also contains concepts highly relevant to the original question: Google Scholar, systematic reviews, database coverage, included studies and comprehensiveness.

It is entirely possible that embedding this passage would retrieve useful papers discussing Google Scholar’s suitability for systematic reviews, including papers that argue against using it alone.

But what about bias? Could generating a hypothetical document arguing that Google Scholar cannot be used alone for systematic reviews favour papers reaching that conclusion over those arguing the opposite?

Again, not necessarily. Some research has found that neural retrievers, particularly bi-encoders, can be surprisingly poor at distinguishing between statements that differ only in negation. This suggests that simply reversing a claim might have less influence on retrieval than we would intuitively expect.

Still, this does not mean there is no risk of bias. Our hypothetical passages differ in more than just their conclusions. They also emphasise different concepts, which might influence which documents are retrieved and how they are ranked.

Whether that actually happens is something we would need to test empirically. We cannot tell simply by inspecting the generated text.

In fact, it is conceivable that a hypothetical passage containing entirely correct statements could produce worse retrieval results than one containing factual errors. After all, factual accuracy and usefulness for retrieval are not the same thing4. What matters is whether the generated passage helps the system retrieve relevant documents, although factual errors could certainly make that harder.

Isn’t this just the old Google trick?

There is an old search tip that sounds superficially similar to what these systems are doing.

The advice goes something like this: when searching Google, think about what words or phrases a webpage answering your question might contain, then search using those terms.

Suppose I want to know whether Google Scholar can be used alone for systematic reviews.

I might reason that relevant papers would contain terms such as coverage, recall, comprehensiveness, included studies and search limitations, then search using those terms.

This makes sense and has a clear resemblance to what HyDE is doing.

In both cases, we are trying to anticipate what relevant documents might look like and search accordingly5?

There is, however, an important distinction here.

With the Google trick, I am predicting words or phrases that I expect to literally occur in relevant documents. If I guess incorrectly, I may damage the search, which is one reason why using LLMs to generate nested Boolean searches does not always produce the best results6.

With HyDE, even if the generated document is factually wrong, its embedding can still be useful if it ends up closer to the embeddings of relevant documents than the original query embedding would.

The hope is that this richer, document-like representation lands somewhere near real documents discussing those concepts.

The fact that a generated passage reaches the wrong conclusion about Google Scholar does not necessarily prevent that from happening.

Of course, I am not saying that a hallucinated passage cannot push the query embedding further away from relevant documents.

In fact, some literature suggests that such expansion techniques tend to help weaker retrievers but may hurt stronger ones. They may also work less well in areas where the LLM’s knowledge is limited. As always in information retrieval, whether a technique improves performance depends on factors such as the retriever, the types of queries and the dataset being searched. Ultimately, these are empirical questions that should be settled through testing (which hopefully the vendor has done) rather than decided a priori.

The point is simply that spotting a hallucination does not, by itself, tell us how serious the problem is.

Empathy for vendors

This brings us back to my supposed conspiracy.

Imagine the interface shows you:

“Google Scholar” AND (”systematic review” OR “evidence synthesis”) AND (coverage OR recall OR limitations)

A librarian might question why certain terms were included, but they would still recognise what they were looking at and feel comfortable with it.

Now imagine the interface instead shows:

Google Scholar can be used alone for systematic reviews because Tay (2024) demonstrated that more than 99% of studies eventually included in systematic reviews can be found in Google Scholar’s index.

I suspect the reaction would be much stronger.

Why is the system citing a paper that doesn’t exist? Why has it apparently decided that Google Scholar is sufficient? Is it now biased towards papers supporting that conclusion?

These are very reasonable questions if you interpret the passage as an answer or a literal statement of the search criteria.

But in the world of semantic embeddings, it is not necessarily either. It may simply be an intermediate representation used to create an embedding.

Perhaps part of the problem is that what happens inside modern semantic search no longer maps neatly onto what librarians traditionally think of as a query.
Modern AI search really does expand your query.
The surprising part is that making things up isn’t necessarily the problem.

Conclusion

And this, I think, explains at least part of the strange asymmetry I keep seeing in AI search interfaces. Even if vendors wanted to show such details, many users, including librarians, might find them confusing7.

The more details vendors show about the search process, the greater the chance that they will open a can of worms by raising questions and concerns among users and librarians. From the vendor’s perspective, the safer option may be not to show them.

The other part of the issue is that modern information retrieval is largely driven by empirical experimentation. You can propose a perfectly logical change that should improve retrieval, but if the experiments show that it doesn’t work, you shouldn’t use it. The reverse is also true. Some techniques may seem counterintuitive to librarians but work well empirically8.

While I can understand how vendors might feel, I still don’t think they should hide all the details. We have a legitimate reason to want to know what is happening under the hood.

For librarians, the practical implication is this: resist the instinct to judge the semantic side of AI search by the same standards as Boolean. Spotting a hallucination in a query expansion is not evidence that a system is broken. The more useful question to ask is not “does the generated query look right?” but “does the system consistently surface relevant results?” That requires empirical testing against known relevant papers, not query inspection.

For librarians supporting systematic reviews the stakes are higher of course given the higher standards of transparency and reproducibility required.

What do you think?

Some might argue that showing the expanded query used to generate the query embedding is not particularly important. But the question applies more broadly to all aspects of the search pipeline.

Would you like vendors to show every detail, even if you don’t fully understand it or think some of the techniques are strange?

If you found this essay on what AI-powered academic search tools are really doing behind the scenes educational, please consider supporting my work.

Buy me coffee via ko-fi!

How is the encoder model able to generate representations that capture something resembling “meaning”? Encoder models learn useful language representations during pretraining on large text corpora, then are typically fine-tuned for retrieval so that relevant query-document pairs receive more similar vector representations than irrelevant ones.

You can get more transparency using multi-vector or late-interaction methods such as ColBERT, or learnt sparse representation methods such as SPLADE, but these are currently not commonly used.

Both techniques use very similar prompts to generate documents that Query2doc calls pseudo-documents and HyDE calls hypothetical documents. In practice, there is little difference between the generated texts themselves. The main distinction is that Query2doc was designed as a general query-expansion method. The query and expanded text can be used for lexical matching as well as retrieval via embeddings. HyDE was designed specifically for embedding-based retrieval.

Factual accuracy and retrieval effectiveness are different properties, but that does not mean they are statistically independent or even negatively correlated! For example, Yoon et al. (2025) found that hypothetical-document expansion improved retrieval mainly when generated passages contained information supported by the actual evidence, raising concerns that some reported gains might reflect knowledge leakage rather than better retrieval.

Notice this technique also risks bias!

I have long argued that using LLMs to generate Boolean is not very productive mostly because they tend to be poor at generating Boolean search strategies and even if they did do it decently it does not help average searchers who already know how to do so. A recent paper by San Diego State University documented how difficult it was to get the LLM to generate reasonable boolean just with prompt engineering.

I can imagine librarians or researchers unfamiliar with information retrieval becoming upset when they see what is happening and assuming that the search is broken.

Of course, it is important that a technique works generally and not just on limited test sets.

注意转载授权 · 阅读原文