Retrieval-Augmented Generation (RAG) for Personalised Outreach at Scale

Use RAG to ground every link pitch in real, retrieved facts about each publisher — with the full pipeline, the contextual-retrieval technique, embedding choices and a UK data layer.

Personalisation and scale have always pulled in opposite directions. Write a genuinely tailored pitch and you cannot send many; send many and they read like a mail-merge. The reply-rate data makes the cost of getting this wrong brutal: across an analysis of twelve million outreach emails, only about 8.5% received any reply at all, and 2026 benchmarks put the average even lower, with generic sends near 3% while signal-personalised campaigns hit 15–25% — a fivefold gap. Retrieval-augmented generation is how you capture that gap at volume.

The insight that unlocks it is deceptively simple: automate the research layer, not the writing layer. A pitch fails when it is grounded in nothing — a first name and a company token. It succeeds when it references something specific, recent and true about the publisher. RAG is the machinery that retrieves those specific, true facts for every target automatically, then feeds them to the model writing the pitch. The writing was never the bottleneck; the research was. RAG removes it.

This article is the build guide for a RAG personalisation pipeline aimed at link outreach. It assumes you understand the outreach itself and what backlinks are and why relevance now beats raw authority. What it adds is the retrieval architecture that makes a writing agent sharp: how to build the publisher knowledge base, the contextual-retrieval technique that stops naive RAG from failing, the embedding and vector-database choices, and a UK data-handling layer most guides skip entirely. Get this right and every pitch is grounded in fact — at the scale of a mail-merge.

The deliverable: the RAG personalisation pipeline

Here is the whole pipeline on one page. It has two halves: a one-time (then incremental) index-build, and a per-pitch query path. Read this and you have the system.

Phase	Stage	What happens
Index	1. Corpus	Gather everything you know about publishers — articles, beats, bylines, past contact
Index	2. Chunk + context	Split into small chunks; prepend a Claude-generated context snippet to each
Index	3. Embed + store	Convert chunks to vectors with an embedding model; store in a vector database
Query	4. Retrieve	For a target, fetch the most relevant chunks via hybrid search + rerank
Query	5. Ground	Feed retrieved facts to the writing model; it drafts using only those facts
Query	6. Gate	Human verifies the grounded references are real before send

Stages 1–3 you do once and then top up as new publisher content appears; stages 4–6 run for every pitch. The expensive-sounding part — generating a context snippet per chunk — is made cheap by prompt caching, as we will see. This pipeline is the engine room behind the Writer in any serious outreach system, and it slots straight into the strategy in our link building strategies guide.

Why generic personalisation fails and RAG fixes it

There are three levels of personalisation, and only the top one moves reply rates. Understanding the ladder explains why RAG, not better prompting, is the answer:

Level	What it is	Typical reply rate
L1 — Mail-merge	First name + company token in a template	Below 1–3%
L2 — Signals	Generic signals + some context	Roughly 2–4%
L3 — Grounded	Specific, recent, true facts about the target	Around 5–12%+

The levels are widely documented; Level 1 mail-merge sits below 1%, while genuinely grounded outreach reaches the 5–12% range and beyond. Even one grounded element compounds: a Belkins study across 5.5 million emails found personalising the subject line alone lifted reply rates by 133%, from 3% to 7%. The bar is no longer personalised versus generic — it is relevant and true versus everything else.

This is exactly where naive AI outreach falls down. Ask a model to personalise without grounding and it does the worst possible thing: it invents. It writes a confident reference to an article the editor never published. RAG closes that door by giving the model real retrieved facts to write from, so personalisation is anchored to truth rather than fabricated. The same principle underpins trigger-based outreach tied to recent events — the discipline our guide to newsjacking for link building explores from the angle of timing.

RAG fundamentals — and when you do not need it

RAG works by preprocessing a knowledge base: break the corpus into small chunks of a few hundred tokens, convert each to a vector embedding that encodes its meaning, and store those in a vector database searchable by semantic similarity. At query time you embed the query, find the closest chunks, and hand them to the model as grounding. For outreach, the “query” is a target publisher and the retrieved chunks are the facts about them worth referencing.

But before you build any of this, ask whether you need it. Anthropic’s own guidance is refreshingly blunt: if your knowledge base is smaller than about 200,000 tokens — roughly 500 pages — just put the whole thing in the prompt and skip RAG entirely, because prompt caching makes that fast and cheap. For a solo practitioner with a handful of target publishers, that is the right answer: cache the publisher profiles in context and never build a vector database. RAG earns its complexity once the corpus outgrows the context window — hundreds of publishers, thousands of articles, years of interaction history. Build the pipeline when you cross that line, not before.

The honest decision rule Small corpus (under ~500 pages of publisher data): put it all in context, use prompt caching, skip RAG. Large or growing corpus: build the RAG pipeline. Choosing RAG when caching would do is the same over-engineering trap that catches teams building multi-agent systems they do not need. Match the tool to the scale.

RAG, prompt caching, or fine-tuning? Choosing your grounding method

RAG is one of three ways to give a model the knowledge it needs to personalise. Picking the wrong one wastes weeks, so be deliberate. The three are not rivals so much as tools for different jobs:

Method	What it does	Best when
Prompt caching	Puts the whole corpus in context, cached for cheap reuse	Corpus fits the context window (~500 pages)
RAG	Retrieves only the relevant chunks per query	Corpus is large, growing, or changes often
Fine-tuning	Bakes patterns into the model’s weights	You need a consistent voice/format, not facts

The crucial distinction is facts versus behaviour. RAG and caching supply facts — what this editor wrote, what they linked to — which is exactly what personalisation needs and exactly what changes constantly. Fine-tuning is for behaviour — a house writing style, a fixed output format — and it is the wrong tool for facts, because the moment a publisher writes a new article your fine-tune is out of date and a retrain is the only fix. For outreach personalisation the answer is almost always caching for a small corpus and RAG for a large one, with fine-tuning reserved for locking in your writing voice if you later need it. Reaching for fine-tuning to inject facts is the classic mistake; facts belong in retrieval, where they can be kept fresh without touching the model.

What goes in the knowledge base: the publisher corpus

RAG is only as good as what it can retrieve, so the corpus is the foundation. For link outreach, the knowledge base is everything that makes a reference specific and true. Gather:

• Recent articles by the publication and, where possible, by the individual editor or writer — titles, summaries, dates and URLs.
• Each contact’s beat and topic focus — what they actually cover, read from their output rather than guessed from a job title.
• The publication’s editorial guidelines and contribution norms, where published.
• Past link patterns — what kinds of sources and assets they have linked to before.
• Your own interaction history — prior pitches, replies, placements, and any stated preferences.

The richer and fresher this corpus, the sharper the personalisation. Stale data is actively harmful: referencing a funding round or article from eighteen months ago signals you did not actually research them. Recency is a first-class requirement — schedule regular re-indexing so the corpus reflects what publishers wrote this month, not last year.

The signals worth indexing: what actually earns replies

Not every fact in the corpus is equally useful for a pitch. The highest-ROI personalisation is trigger-based — anchored to something specific and recent — and trigger-based openers consistently outperform generic ones. Adapted from sales outreach to publisher outreach, these are the signal types worth prioritising when you build and rank the corpus:

• Recent publication. The editor published a piece on your topic in the last few weeks — the single strongest hook, because it proves current relevance and gives you a precise reference.
• Demonstrated link behaviour. They have linked to a source or asset type like yours before. This signals both relevance and willingness, and it is buried in their content where only retrieval will surface it.
• Stated preference. Their contribution guidelines or past replies state what they want — data-led pitches, a named methodology, exclusivity. Honouring a stated preference is the cheapest reply-rate lift available.
• Beat shift. A writer who has recently started covering your area is unusually receptive, because they are actively building sources on it.
• Coverage gap. They cover the topic but lack the specific data or angle you hold — a gap your asset fills exactly.

Index and weight these signal types above generic biographical detail, because they are what turns a pitch from “personalised” into “relevant and timely” — the only distinction that still moves reply rates in 2026. A corpus that captures recency and link behaviour will out-personalise one stuffed with job titles and company descriptions every time. This is also where outreach RAG and newsjacking for link building converge: both are bets that timing and specificity beat volume.

Building the pipeline, step by step

Step 1 — Assemble and chunk the corpus

Collect the sources above into clean documents, then chunk them — usually no more than a few hundred tokens per chunk. Chunk on natural boundaries (one article summary, one interaction record) rather than arbitrary character counts, so each chunk is a coherent unit of meaning. Attach metadata to every chunk — publisher, contact, date, source URL — because you will filter and cite on it later.

Step 2 — Add context before you embed (the part that matters)

This is the single highest-leverage step, and the one naive pipelines skip. A bare chunk — “argues retention beats acquisition for early-stage SaaS” — loses the fact that it came from a specific editor’s specific piece. Anthropic’s Contextual Retrieval technique fixes this by prepending a short, model-generated context snippet to each chunk before embedding, situating it within its source document. The payoff is large and measured: contextual embeddings cut the retrieval-failure rate by 35% alone, 49% combined with contextual BM25, and 67% when reranking is added.

You generate the context cheaply by asking a small model to describe each chunk in the light of its full document — and prompt caching makes feeding that full document repeatedly almost free:

# For each chunk, generate a one-sentence situating context. # The full document is cached, so re-sending it per chunk is cheap. context = claude.messages.create(   model=”claude-haiku-4-5″,   messages=[{ “role”: “user”, “content”: [     { “type”: “text”, “text”: FULL_DOCUMENT,       “cache_control”: { “type”: “ephemeral” } },   # cached     { “type”: “text”, “text”: f”Situate this chunk: {chunk}” },   ]}], ) embed_input = context.text + “\n\n” + chunk   # embed the pair

Step 3 — Choose an embedding model and a vector database

One fact surprises people: Anthropic does not offer an embedding model of its own, so a Claude-based RAG pipeline uses two APIs — a third-party embedder plus the Claude API for generation. Voyage AI is Anthropic’s recommended embedding provider, with OpenAI, Cohere and Google as alternatives. For the store, pgvector keeps things simple on existing PostgreSQL, while Pinecone or Qdrant suit larger scale. Pick the simplest option that fits your volume; the embedding model matters more for retrieval quality than the database does.

Component	Simple / starting choice	Scale choice
Embedding model	OpenAI text-embedding-3-small (cheap)	Voyage (Anthropic’s pick, top retrieval quality)
Vector database	pgvector (no new infrastructure)	Pinecone or Qdrant (managed, scalable)
Generation model	Sonnet 4.6 (writing)	Sonnet 4.6 + Opus 4.8 for hard cases

Step 4 — Retrieve at query time

For each target, build a query from their identity and your campaign angle, embed it, and retrieve. Best practice is hybrid: combine dense (semantic) and sparse (keyword/BM25) search, fuse the rankings, pull a wide candidate set, then rerank down to the best handful. The pattern Anthropic describes — retrieve a broad set of chunks, then rerank to the top 20 before passing them to the model — is the reliable default. For a single pitch you rarely need 20; the top three to five genuinely relevant facts about a publisher are plenty, and more can dilute the prompt.

Step 5 — Ground the generation

Now hand the retrieved facts to the writing model with one hard rule: personalise only from these facts, never from invention. This is the step that converts retrieval quality into reply rate. The model writes a pitch whose opening references a real, recent, retrieved fact — the editor’s actual article, their actual beat — and makes a specific offer. Because the facts are retrieved rather than recalled, the model cannot hallucinate a reference. If your campaign is contribution-led, the grounded draft aligns with the norms in our guide to guest posting for links.

Contextual retrieval: why naive RAG is not enough

It is worth dwelling on why the context step in Step 2 matters so much, because skipping it is the most common reason outreach RAG underperforms. In a naive pipeline, each chunk is embedded in isolation, carrying a potentially useful fact but no sense of where it came from. A chunk reading “the shift to retention changed everything” could come from any of a hundred publishers. Retrieval then surfaces the wrong source, the model grounds the pitch in it, and you reference the wrong editor’s argument — worse than no personalisation at all.

Prepending context fixes this by making each chunk self-describing: “From Sarah Chen’s March 2026 piece in [publication] on B2B SaaS retention: the shift to retention changed everything.” Now retrieval can match the right chunk to the right target, and the grounded reference is correct. The measured gains — a 49% reduction in failed retrievals, rising to 67% with reranking — translate directly into pitches that reference the right thing. For outreach, where a wrong reference is actively damaging, that accuracy is not a nice-to-have; it is the difference between a system you can trust to run at scale and one you cannot.

Hybrid search and reranking: getting the right facts out

Retrieval quality is where good outreach RAG is won, and a single embedding search is rarely enough on its own. The robust pattern combines two methods. Dense (semantic) search matches on meaning, so a query about “retention” finds a chunk about “churn” even without the word. Sparse search — BM25, classic keyword matching — catches exact terms a semantic model can blur, like a specific product name or a publication title. Fusing the two rankings, then reranking the merged set down to the best handful consistently beats either method alone.

The mechanics, in order, for each target:

1. Embed the query (the target publisher plus your campaign angle) and run dense search against the vector store.
2. Run BM25 over the same corpus for exact-term matches.
3. Fuse the rankings with a method such as reciprocal rank fusion, so a chunk strong in either list rises.
4. Rerank the fused set with a reranking model and keep only the top three to five facts — the ones genuinely about this target.

Reranking is the step that earns the headline accuracy: it is the difference between Anthropic’s 49% retrieval-failure reduction and the 67% it reaches once reranking is added. For a single pitch you do not pass twenty chunks to the writer — you pass the few that matter, because in generation, precision beats recall. A prompt holding five sharp, correct facts about an editor produces a better pitch than one holding twenty loosely-related ones.

Indexing one publisher, end to end

To make the index phase concrete, here is how a single publication enters the knowledge base.

• Collect. Pull the publication’s last few months of articles, the bylines and beats of its key editors, its published contribution guidelines, and any prior interaction you have had with it. Attach metadata — publisher, author, date, URL — to every item.
• Chunk. Split on natural boundaries: one article becomes a short summary chunk, one interaction becomes a record chunk. Keep each a few hundred tokens, coherent on its own.
• Contextualise. For each chunk, generate a one-line situating context using the cheapest model with the full source document cached, then prepend it. “Editorial guidelines” becomes “From [publication]’s 2026 contributor guidelines: prefers data-led pitches with a named methodology.”
• Embed and store. Convert each contextualised chunk to a vector, store it with its metadata, and index it for BM25 too so hybrid search works.
• Schedule a refresh. Set the publication to re-index on a cadence — monthly is a sensible default — so new articles enter the corpus and stale ones age out. Freshness is a feature, not a one-off.

Repeat across your target list and the knowledge base builds itself into the research layer every pitch then draws on. The work is front-loaded and largely automated; the payoff recurs on every campaign for as long as the corpus stays fresh.

The UK layer: a British corpus and data minimisation

Two UK-specific considerations shape an outreach RAG system, and ignoring either weakens it.

Build a genuinely British corpus

Generic outreach tools index a US-default media landscape. A UK link programme should weight its corpus towards the British press that actually links: national and broadsheet desks, the deep ecosystem of UK trade journals and sector blogs, and regional outlets. UK-specific angles — figures in pounds, regional breakdowns, British market context — are scarcer in editors’ inboxes and far more linkable for a UK publication. Indexing that material so the Writer can retrieve it is how personalisation acquires a British accent. The same corpus logic, widened, supports outreach into Europe — see our guide to link building for European markets.

Mind what you store about people

A RAG knowledge base about publishers contains personal data — names, email addresses, professional history — and UK GDPR’s data-minimisation principle applies: collect and retain only what you actually need to personalise a pitch, and no more. Store the editor’s published work and beat; do not hoover up unrelated personal detail because you can. Set a retention schedule and purge stale records, which also keeps the corpus fresh. Treat the suppression list as part of the system: a contact who has opted out should be removed from the knowledge base, not merely skipped at send time.

General information, not legal advice Data-protection rules turn on specifics. This is general guidance on building a corpus responsibly, not legal advice — confirm your data handling with a qualified UK adviser before running at scale, particularly around lawful basis and retention.

A worked example: from retrieval to a grounded pitch

Watch the pipeline produce one pitch. The target is an editor at a UK martech publication; the offer is an original UK SaaS-churn study.

Retrieved facts (top 3 chunks, contextual-embedded):

1. “Sarah Chen, [UK martech pub], Mar 2026: argued UK SaaS     retention reporting lags the US and needs local benchmarks.” 2. “Same author, Feb 2026: linked out to an original churn     dataset in a piece on ARR-band analysis.” 3. “Publication editorial note: prefers data-led pitches with     a named methodology and a source link.”

Grounded pitch the Writer produces from those facts:

Subject: UK SaaS churn benchmarks — by ARR band   Hi Sarah, your March piece on UK retention reporting lagging the US stuck with me — we’ve just published original UK churn data broken down by ARR band, with the methodology documented. Given you linked similar ARR-band analysis last month, it may be useful for your readers. Source link below; happy to share the raw figures. No obligation.

Every specific in that pitch is retrieved, not invented: the March article, the ARR-band link pattern, the data-led preference. The numbers on the upside are compelling. Take a 200-pitch campaign. At a generic ~3% reply rate that is six conversations; at the 15–18% a grounded, signal-based approach reaches, it is roughly 30–36 — five to six times the pipeline from the same number of sends and the same domain risk. If even a third of replies convert to a placement, that is the difference between two links and eleven from one campaign. The retrieval layer, not the copywriting, produced that.

The cost is trivial; the lift is not The index build is a one-off plus light top-ups. Embedding a corpus costs cents per million tokens; the contextual-snippet step runs on the cheapest model with the full document cached; the vector store can be free on existing infrastructure. Per pitch, retrieval is a few embedding look-ups — negligible. You are spending pennies to move a campaign from a 3% to a high-teens reply rate. Few investments in link building have that return profile.

Failure modes that quietly wreck outreach RAG

• Stale corpus. The fastest way to look like a spammer is to reference old news as if it were current. Re-index regularly and timestamp everything; weight recent chunks in retrieval.
• Skipping contextual embeddings. Isolated chunks retrieve the wrong source and you reference the wrong editor’s work. The context step is not optional for outreach — it is the accuracy guarantee.
• Over-retrieval. Stuffing twenty chunks into the prompt dilutes the signal. Retrieve broadly, rerank hard, and pass the model only the three to five facts that genuinely matter for this target.
• Trusting RAG to eliminate hallucination. Grounding reduces invention; it does not abolish it. Keep the human gate to confirm every referenced fact is real before send. Retrieval makes the human’s check fast — it does not replace it.
• Hoarding personal data. A corpus that over-collects personal information is a liability under UK GDPR and adds nothing to pitch quality. Index what you need to personalise; purge the rest.
• Building RAG you do not need. If your corpus fits in context, cache it and skip the pipeline. Complexity you do not need is cost and fragility you did not have to take on.

Measuring the pipeline: retrieval and outcome

RAG has two layers to measure, and teams that track only the second never improve the first. Watch both:

Metric	Layer	What it tells you
Retrieval relevance	Retrieval	Whether the chunks surfaced are actually about the target
Grounding accuracy	Generation	Share of referenced facts that are real (human-checked)
Reply rate vs baseline	Outcome	The headline win — grounded vs generic on the same list
Placement rate per pitch	Outcome	Links won ÷ pitches sent — the bottom line
Corpus freshness	Index	Median age of retrieved chunks — rising age predicts decay

Grounding accuracy is the one to guard hardest: a single fabricated reference that slips past the gate can burn a relationship a clean corpus took months to build. Measure it by spot-checking referenced facts against the source. For benchmarks on healthy reply and placement rates to compare against, cross-reference our 2026 link building statistics, and for the tooling that supports the wider workflow, our comparison of link building tools.

Beyond the first email: RAG across the whole sequence

Personalising the opening pitch is where most teams stop, but the same retrieval layer sharpens the entire sequence — and follow-ups are where a surprising share of replies actually come from. One extra, well-judged follow-up can lift reply rates substantially over a single send, but only if the follow-up adds fresh value rather than repeating the ask. RAG makes that possible at scale by retrieving a different relevant fact for each touch.

Three places the retrieval layer keeps earning beyond the first email:

• Value-add follow-ups. Instead of “just checking in”, the second touch retrieves a second relevant fact — another recent article, a newly published angle — and offers something genuinely new. The corpus you already built supplies it.
• Reply classification and routing. When a reply arrives, the model can use retrieved context about the publisher and the thread to classify intent — interested, not now, wrong contact — and route accordingly, so humans spend time only where it counts.
• Relationship memory. Every interaction feeds back into the corpus. The next campaign retrieves “linked our study last quarter” or “asked us to follow up in the new year”, so outreach compounds into a relationship rather than restarting cold each time.

This last point is the quiet superpower. A RAG corpus that grows with every interaction turns one-off outreach into an institutional memory of your publisher relationships — the digital equivalent of a veteran PR’s mental rolodex, but shared across the team and queryable at scale. It is also why the human gate and genuine value matter: the corpus remembers how you treated people, and so do they.

Questions teams ask before building outreach RAG

Do I need a vector database at all?

Often not. If your publisher data fits in roughly 500 pages, Anthropic’s own advice is to put it all in context and use prompt caching instead of building RAG. Build the vector pipeline only when the corpus outgrows the context window. Starting with caching and graduating to RAG later is a perfectly good path — and a cheaper one.

Which embedding model should I start with?

Start cheap and well-supported, then upgrade for quality if retrieval matters. A low-cost OpenAI embedding model is a fine default to prove the pipeline; Voyage is Anthropic’s recommended choice and the premium option for retrieval quality when you are ready to optimise. Remember the pipeline always uses two APIs — the embedder and the Claude API — because Anthropic has no embedding model of its own.

Won’t RAG still hallucinate references?

Less, but not never. Grounding the model in retrieved facts dramatically reduces invention compared with asking it to personalise from memory, but it does not make the human gate redundant. A reviewer confirming that each referenced fact is real is the final safeguard, and retrieval makes that check fast because the source of every fact is right there. Trust the pipeline to draft; trust a person to verify.

How often should I re-index?

Frequently enough that you never reference stale news as current. Monthly is a sensible default for most publisher corpora; faster for fast-moving beats. Treat corpus freshness as a tracked metric — the median age of the chunks you retrieve — because a corpus quietly going stale is the most common slow failure of outreach RAG.

Is this overkill for a small UK campaign?

If you target a dozen publishers a month, yes — cache their profiles in context and write grounded pitches directly. RAG earns its place when you are running across hundreds of UK publishers, thousands of articles, and an accumulating interaction history that no single context window can hold. Match the machinery to the scale, not to the ambition.

Your Monday-morning build path

Build it in layers, smallest viable version first, and only add the pipeline when scale demands it.

1. Decide if you even need RAG. If your publisher data fits in roughly 500 pages, cache it in context and skip to drafting — you may be done.
2. If you need it, assemble the corpus: recent articles, beats, link patterns and interaction history for your target publishers, with metadata on each.
3. Chunk on natural boundaries and add a context snippet to each chunk using the cheapest model with the full document cached.
4. Embed with Voyage (or OpenAI to start) and store in pgvector; this is enough to begin.
5. Wire retrieval into your Writer: query per target, retrieve top three to five facts, ground the draft, and forbid invention.
6. Route every grounded draft through the human gate, and instrument retrieval relevance and reply rate from day one.

Done in that order you get a personalisation engine that scales truth, not tokens — every pitch grounded in a real, recent, retrieved fact about its recipient, produced at the volume of a mail-merge but with the reply rate of hand-written research. That is the whole promise of RAG for outreach: it automates the part that was always the bottleneck, the research, and leaves the judgement — and the send — to a person. Start small, prove the reply-rate lift on a single segment against a generic control, and only then widen the corpus and the campaign. The deeper builds in this cluster, from fine-tuned writing models to vector-matched prospecting, all sit on top of a clean retrieval layer. Build this one well and the rest get easier — and the corpus you create becomes an asset that appreciates with every campaign you run.