Resources · n8n integration

n8n MultiQuery Retriever nodeConfigure MultiQuery Retriever in n8n.

A single question rarely matches the wording stored in your documents. The n8n MultiQuery Retriever node hands that question to a chat model, gets several rewrites back, and runs each one through the retriever plugged underneath. One option, 2 required ports, nothing to authenticate.

Try the MultiQuery Retriever node on n8nSee the 1 parameters

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

Why add the n8n MultiQuery Retriever node to a search workflow?

The MultiQuery Retriever sits between a question and the place your documents live. Instead of searching once with the exact words someone typed, it asks a chat model (the sub-node that talks to a provider like OpenAI or Anthropic) to write several versions of that question, sends each one to the retriever below it, and gives back the pooled documents. It is a sub-node, so it never runs on its own: a root node such as Question and Answer Chain pulls it.

Take a support knowledge base. Someone asks about "the invoice never arrived". The stored article talks about failed billing emails and delivery bounces. A plain search on the typed words can miss it; three rewrites of the same intent usually catch it. That is the whole point of this node, and it costs you one parameter to set.

Second scenario, an internal documentation search glued to a chat interface. Questions arrive short and half typed. Raising Query Count widens the net without touching the vector store or the documents themselves, because the rewriting happens upstream, in the chat model on the ai_languageModel port.

Third, a research step feeding a report. The retriever you connect stays the same, so the same pool of documents can serve a AI Agent answering live and a scheduled workflow writing a digest into Google Sheets or posting it to Slack. Only the root node changes.

When to skip it: if answers already land on the right passage, plug the retriever straight into the root node. Every rewrite is an extra call to the model provider, and providers bill their own API calls under their own terms. On a small, well worded corpus that spend buys little. There is also no reranking here: the node widens the pool, it does not reorder it. For that, Contextual Compression Retriever accepts this node as its input.

Limits worth knowing before you build. The node exposes a single option, so the rewriting prompt itself is not editable from the panel. Both ports are required, which means an empty one stops the execution. And the page describes version 1 of the node; an older workflow may show fewer options. Model choice matters more than anything you configure here, whether you go with OpenAI or Anthropic.

Connections

What do you plug into the MultiQuery Retriever ?

In n8n, a root node receives the workflow items and sub-nodes hang off its ports, one type of sub-node per port; this node is itself a sub-node with two ports of its own.

Ports (what plugs in)

  • Chat Modelai_languageModelrequired
  • Retrieverai_retrieverrequired

Output (what it plugs into)

  • Retrieverai_retriever
01Chat ModelThis port holds the model that rewrites the incoming question into several search queries. No model, no rewriting, and the node has nothing to send to the retriever.

This port holds the model that rewrites the incoming question into several search queries. No model, no rewriting, and the node has nothing to send to the retriever.

Key parameters

  • Required: leave it empty and the execution stops on this node.
  • OpenAI Chat Model and Anthropic Chat Model: the usual starting points, each carrying its own provider credential.
  • Ollama Chat Model: for a model running on your own machine, when the questions should not leave the network.
Use cases
a self-hosted model for an internal HR knowledge base, a hosted one for public product documentation.
02RetrieverBelow this port sits the thing that actually fetches documents. Each rewritten query goes through it, and the node merges what comes back into one pool.

Below this port sits the thing that actually fetches documents. Each rewritten query goes through it, and the node merges what comes back into one pool.

Key parameters

  • Required: the node has nothing to query without it.
  • Vector Store Retriever: the common choice, reading from the store where your embedded documents live.
  • Workflow Retriever: when the documents come from another n8n workflow rather than a store.
Use cases
point it at a vector store built from a product wiki, then reuse the same store for a second search workflow.
Parameters

Which parameters does the node expose?

The MultiQuery Retriever node has one parameter. For each one: the node as you configure it in n8n, what the parameter changes, and our field notes.

01

Options

options

What you see in n8n

Notes & use cases

Everything configurable on this node lives behind one collection, opened with Add Option. Left untouched, the node still works: it rewrites and merges with its built-in behavior.

Key parameters

  • Query Count: how many different versions of the question the chat model generates. More versions widen the document pool and add one model call each.
Use cases
start without the option on a small corpus, then add Query Count when short questions keep missing the right article.
Need help

Need help automating MultiQuery Retriever with n8n?

A person reads every message.

FAQ

MultiQuery Retriever in n8n, answered

01Is the MultiQuery Retriever node included in n8n?
Yes. It ships inside the n8n AI package, so there is nothing to install and no extra charge on the n8n side, on n8n Cloud and on a self-hosted instance alike (Community Edition, Sustainable Use license). What you do pay for sits elsewhere: the provider behind the chat model you plug into the node bills its own API calls under its own terms, and this node makes several of them per question instead of one. n8n adds nothing on top of that. A workflow built on n8n Cloud behaves the same way once you move it to your own server, since self-hosting runs the same node.
02What credentials does the MultiQuery Retriever need?
None. The node has no credential and no Authentication selector, so there is nothing to set up on the account side, which is one less thing to manage. The key lives one level down: the chat model sub-node you connect to the node carries the provider credential, and so does the retriever if the store behind it needs one. Set those up once in n8n and they can be reused across workflows. If an execution fails with an authentication error, look at the sub-node underneath, not at this node.
03What are the limits of the n8n MultiQuery Retriever node?
The node exposes a single option, Query Count, and nothing else. The prompt used to rewrite the question is not editable from the panel, so if you need full control over the wording, build the rewriting yourself with a chat model and feed the queries to a retriever directly. It also does not rerank or deduplicate by relevance: it widens the pool, which is a different job from choosing the best passage. Both of its input ports are required, so an empty one blocks the execution. The page describes version 1 of the node; an older workflow may show fewer options.
04What do you have to connect for it to run?
Two things, both required: a chat model on the Chat Model port and a retriever on the Retriever port. For a first setup, OpenAI Chat Model plus Vector Store Retriever is the shortest path, since the store is usually already there from an earlier indexing workflow. Then connect the node itself to a root node, Question and Answer Chain being the straightforward one. Contextual Compression Retriever also accepts it, if you want the pool trimmed before the answer is written. Nothing else is mandatory, and the single option can stay closed.
05n8n or Make for this kind of retrieval?
Depends on where your data can live. n8n runs on your own server or on n8n Cloud with the same workflow, which matters when the documents being searched are internal and the chat model is self-hosted. Make is hosted only, with no self-hosting option, and bills per operation, so a node that fires several model calls per question changes the math. On visual logic both are comfortable. Pick n8n when you want the documents and the model to stay on infrastructure you control, Make when hosting someone else's runtime is fine and the volume is predictable.
Hack'celeration Lab

Get our weekly integration tips.

No spam. Unsubscribe anytime.

Same platform

Other docs you might need on this stack.

Browse all integrations