Resources · n8n integration

n8n Contextual Compression Retriever nodeConfigure Contextual Compression Retriever in n8n.

A retriever hands documents to a chain, and this one hands over less of them. The n8n Contextual Compression Retriever node sits between another retriever and the node that reads its output, with a chat model that keeps only the passages tied to the question. Two ports to connect, no settings to fill in.

Try the Contextual Compression Retriever node on n8n

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the n8n Contextual Compression Retriever node do?

It wraps another retriever, a sub-node that looks up documents for a question, and filters what that retriever returns. Every document coming back goes through a chat model, the sub-node that talks to a provider like OpenAI or Anthropic, and only the part that actually answers the question stays. The chain downstream gets the same documents, shorter.

Similarity search is generous. Ask a vector store for the top matches and it returns whole chunks, question-related sentences buried inside pages of surrounding text. That text still travels to the model that writes the answer, still counts against its context window, the amount of text a model can read in one call, and still gives it room to answer beside the point. Compression is the step that cleans this up.

Take a support knowledge base indexed in a vector store. A customer asks about a refund deadline, the retriever brings back 4 chunks of a general terms page, and only two sentences of those chunks mention the deadline. Plug the Contextual Compression Retriever between the store retriever and the AI Agent or the question and answer chain, and those two sentences are what the answer is built on.

Second case, an internal documentation assistant reading long meeting notes. Raw retrieval gives full pages, so the answer drifts into whatever else was discussed that day. With compression, the model that writes the answer sees only the lines about the topic asked. Third case, a pipeline where retrieval costs add up: each call to the compression model is billed by that provider, whether you run OpenAI, Anthropic or Google Gemini, and you trade those calls against a shorter prompt in the final one.

When to skip it. If your chunks are already small and precise, plug the vector store retriever straight into the chain and save a model call per document. If the problem is that the right document never comes back at all, the answer is upstream: better chunking, or the MultiQuery Retriever, which rewrites the question several ways before searching. Compression improves what you found, it does not find more.

Two limits worth knowing before you wire it. Compression reads each returned document with a chat model, so retrieval takes longer and depends on that provider staying up. And it can cut too much: a fact the chain needed, sitting in a sentence the compression model judged unrelated, is simply gone by the time the answer is written. Test on real questions before shipping. The broader n8n picture, hosting and pricing model included, is in the n8n review.

Connections

What do you plug into it?

This is a sub-node: it never runs on its own, it attaches to the port of a root node and works when that node runs. It has its own ports too, and both of them are required.

Ports (what plugs in)

  • Chat Modelai_languageModelrequired
  • Retrieverai_retrieverrequired

Output (what it plugs into)

  • Retrieverai_retriever
01Chat ModelThe model that reads each retrieved document and rewrites it down to the part related to the question. This is the port that does the compression work.

The model that reads each retrieved document and rewrites it down to the part related to the question. This is the port that does the compression work.

Key parameters

  • Required: leave it empty and the node refuses to run.
  • OpenAI Chat Model or Anthropic Chat Model: the usual starting points, each carrying the credential of its provider.
  • Ollama Chat Model: for documents you would rather not send outside your own machines.
  • Model Selector: to route between several models instead of hard-wiring one.
Use cases
a knowledge base where the same model answers and compresses, and one where a cheaper model is dedicated to compression while the answer chain keeps a stronger one.
02RetrieverThe retriever whose output gets compressed. This node does not search anything by itself, it filters what the retriever below it brings back.

The retriever whose output gets compressed. This node does not search anything by itself, it filters what the retriever below it brings back.

Key parameters

  • Required: without a retriever plugged in, there is nothing to compress.
  • Vector Store Retriever: the common choice. It reads a vector store you filled beforehand, and it is where most setups start.
  • Workflow Retriever: documents from another n8n workflow, not a store.
  • MultiQuery Retriever: when one question should be searched several ways before compression.
Use cases
a product documentation store searched on every customer question, or a workflow that pulls records from an internal tool and hands them over as documents.
Parameters

Contextual Compression Retriever

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

Need help

Need help automating Contextual Compression Retriever with n8n?

A person reads every message.

FAQ

Questions people ask next

01Is the Contextual Compression Retriever included in n8n?
Yes. It ships in the n8n AI package, and it is there on n8n Cloud, the hosted offer run by n8n, as well as on a self-hosted instance under the Community Edition. Nothing to install, nothing extra to pay on the n8n side, and a workflow behaves the same either way. What does get billed is the model provider behind the chat model you connect, on its own terms, since compression sends each retrieved document to that provider for rewriting. n8n adds nothing to that.
02What do you need to make it work?
Nothing to authenticate on this node. Open its panel and there is no credential field, no Authentication selector, and in fact no parameter at all. That is the whole point: the two things it needs are connections, not settings. A chat model on one port, a retriever on the other, and it runs. The credential lives on the chat model sub-node, where the provider key belongs, so the same key already set up for another node is reused as is. There is nothing to configure here and nothing that can be misconfigured.
03What are the limits of the n8n Contextual Compression Retriever node?
Three. It adds a model call per retrieved document, so retrieval gets slower and the provider bill grows with the number of documents. It can cut a passage the chain needed, because the decision of what is relevant is made by the model, not by a rule you write. And since it exposes nothing in its panel, there is no threshold, no length target and no prompt to adjust when the result is not what you wanted: you change the chat model, or you change the retriever underneath. Version 1 is the current one.
04What is the minimum to connect, and which sub-node should you start with?
Both ports, since both are required. Start with a Vector Store Retriever on the retriever port, pointing at a store you have already filled, and an OpenAI Chat Model or an Anthropic Chat Model on the model port. Then plug the whole thing into a Question and Answer Chain. That is the shortest setup that answers a real question. Once it works, try a smaller or locally hosted model on the compression side with an Ollama Chat Model, since that call runs once per document and the answer itself is written elsewhere.
05n8n or Make for this kind of retrieval?
Depends on where your documents can live and how you want to pay. n8n self-hosts with Docker or npm, so the documents being compressed and the model calls stay on infrastructure you control, which matters when the knowledge base is internal. Make is hosted only, with no self-hosting option, and bills per operation, which is predictable for steady volumes and less so when a retrieval fans out into one model call per document. Make is also the easier visual editor for linear scenarios. For an AI pipeline with sub-nodes wired onto ports, n8n is the model that fits.
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