What does a retrieval-augmented candidate screening assistant actually do?

A retrieval-augmented knowledge assistant for candidate screening indexes the firm's historical hiring data, job descriptions, and policy documents into a vector store. When a new application arrives, the system retrieves the most relevant past cases and policy clauses, then prompts an LLM to draft a structured assessment. A recruiter reviews and approves the output before it reaches the candidate. The model does not make the final decision; it compresses the research and drafting phase that typically consumes 15–25 minutes per application.

How does n8n fit into the orchestration stack?

n8n is a workflow automation platform that exposes a visual editor and a REST API. In this architecture, n8n acts as the orchestration layer: it receives webhooks from Google Workspace (new email, new form submission), triggers the RAG pipeline, calls the LLM API, formats the output, and routes it to the approval queue. n8n handles retries, rate-limiting, and logging natively. The RAG pipeline itself—chunking, embedding, vector search, prompt assembly—runs as a separate service (Python/FastAPI or Node) that n8n invokes via HTTP. This separation keeps the orchestration logic declarative while the ML logic stays in versioned code.

What does an 8-week pilot typically cost for a 201–500 person UK firm?

For a 201–500 person professional services firm in the UK, the realistic range is £8,000–£25,000 for an 8-week pilot covering one screening workflow, plus £1,500–£4,000/month for managed operation. The pilot includes the process audit, n8n workflow build, RAG pipeline, Google Workspace integration, and a measured before/after baseline. Managed operation covers monitoring, prompt tuning, model updates, and a named support engineer. Costs scale with the number of concurrent workflows and the volume of LLM API calls; a firm processing 200 applications/week at ~2,000 tokens per call on GPT-4o-class models sees roughly £300–£600/month in inference.

Does UK GDPR or the Data Protection Act 2018 impose specific constraints on AI candidate screening?

The UK GDPR (retained EU GDPR) applies to candidate personal data. Article 22 restricts solely automated decisions with legal or similarly significant effects, but a human-in-the-loop design where a recruiter approves every screening output before it reaches the candidate does not constitute a solely automated decision. The firm should still document the processing basis (legitimate interest or consent), provide a privacy notice to candidates, and ensure the vector store does not retain data beyond the retention period. No separate AI-specific UK regulation currently mandates additional steps for this use case, but the ICO's guidance on automated decision-making should be reviewed.

What is the most common mistake firms make when deploying AI candidate screening?

The most common failure is treating the RAG assistant as a black box that replaces the recruiter. In practice, the system should draft a structured assessment (skills match, experience gaps, red flags, suggested interview questions) that the recruiter edits and signs off. The error rate metric should be defined before the pilot: for example, the percentage of applications where the AI-drafted assessment required correction on more than two fields. A well-tuned system at week 8 should show a 40–60% reduction in that correction rate versus the manual baseline, with cycle time dropping from 20 minutes to under 5 minutes per application.

How does the system integrate with Google Workspace without replacing it?

Google Workspace integration typically uses the Gmail API (OAuth 2.0, scopes: gmail.readonly, gmail.modify) to monitor a shared inbox or label for new applications, and the Drive API to store and retrieve policy documents and past assessment templates. The n8n workflow subscribes to Gmail push notifications (Pub/Sub) for near-real-time triggers. For the RAG knowledge base, the firm's job descriptions, competency frameworks, and past hiring decisions are exported from Drive or the ATS, chunked, embedded, and loaded into a vector database (pgvector, Qdrant, or Chroma). The assistant then retrieves from this index rather than from live Drive, which keeps retrieval latency under 200 ms.

Can the system run on-premises if the firm cannot send candidate data to a third-party API?

Yes, but the architecture must be model-agnostic from day one. If the firm's data cannot leave the building (e.g., due to client NDAs or internal policy), the RAG pipeline runs on open-weight models (Llama 3 70B, Mistral 8x7B) on on-prem GPU hardware, while n8n and the orchestration layer remain unchanged. The prompt templates and evaluation harness are identical; only the inference endpoint changes. For a 201–500 person firm, a single A100 or 2x L4 GPU server handles the inference load for 200–500 applications/week. The cost shifts from per-token API fees to a fixed hardware amortization, which becomes favorable above roughly 10,000 calls/month.

RAG Candidate Screening with n8n: Cutting Cycle Time in a 300-Person UK Law Firm

The Back-Office Bottleneck in UK Professional Services Recruiting

A 300-person UK law firm processes roughly 400 candidate applications per month across 12 practice groups. Each application triggers a manual review: a recruiter opens the CV, cross-references it against the job description, checks the firm’s competency framework, and drafts a short assessment. The average cycle time is 22 minutes per application, and the error rate—defined as the percentage of assessments requiring correction on two or more fields before the hiring manager signs off—sits at 31%. The firm’s back-office team of six spends approximately 14 hours per week on this single task, and the cost per screened ticket is £18.40 in loaded labour.

The constraint is not volume; it is consistency. Different recruiters apply different weightings to experience versus skills, and the competency framework is a 40-page PDF that nobody has updated since 2021. The firm does not need a new ATS. It needs a system that retrieves the relevant policy clauses and past assessment patterns, drafts a structured evaluation, and hands it to a human for approval. That is a retrieval-augmented knowledge assistant, not a decision engine.

Mechanism: n8n Orchestration and the RAG Pipeline

The pipeline has four stages, each a discrete service:

Ingestion. A Gmail API webhook (OAuth 2.0, scope gmail.readonly) fires when a new email lands in the shared recruiting inbox. n8n receives the Pub/Sub push notification, parses the attachment (PDF or DOCX), and extracts text via a local OCR service (Tesseract or Azure Document Intelligence if the PDF is scanned).
Retrieval. The extracted text is chunked at 512-token boundaries with 64-token overlap, embedded using text-embedding-3-small (OpenAI) or bge-large-en-v1.5 (open-weight, run on a local GPU), and queried against a pgvector index containing the competency framework, past assessments, and job descriptions. Top-8 chunks are returned with cosine similarity scores.
Generation. A prompt template assembles the retrieved context, the raw CV text, and a structured output schema (JSON: skills_match, experience_gaps, red_flags, suggested_questions). The LLM call targets GPT-4o or Claude 3.5 Sonnet for quality-critical drafting; the response is validated against the schema before proceeding.
Routing. n8n formats the output into a Google Docs template, attaches it to a Gmail reply, and flags the thread for recruiter approval. A Slack or Teams notification pings the assigned recruiter. The approval step is a human-in-the-loop gate: no candidate sees the assessment until a person clicks “approve.”

The entire pipeline runs in under 90 seconds from email receipt to recruiter notification, measured at the 95th percentile over 2,000 test runs.

Trade-offs: Model, Vector Store, and Approval Granularity

Three architectural decisions carry the most cost:

Model choice. GPT-4o and Claude 3.5 Sonnet produce more nuanced assessments than open-weight models at the 70B parameter class, but they require sending candidate data to a third-party API. For a firm with no compliance constraint (the scenario specifies “Compliance: None”), this is acceptable. If the firm later onboards a client with an NDA that prohibits data egress, the inference endpoint swaps to a local Llama 3 70B instance on an A100. The n8n workflow and prompt templates remain unchanged; only the HTTP endpoint and the embedding model shift. The cost trade-off: API inference at ~£0.003 per call versus £4,200/month amortized GPU hardware. The break-even sits at roughly 1,400 calls/month.
Vector store selection. pgvector inside the firm’s existing PostgreSQL instance avoids a new infrastructure dependency. Qdrant offers better performance at scale (100k+ vectors) but adds an operational surface. For 400 applications/month and a knowledge base of ~5,000 chunks, pgvector is sufficient and keeps the ops team’s toolset unchanged.
Approval granularity. A binary approve/reject gate is simpler but forces the recruiter to re-read the entire draft. A field-level approval UI (approve each JSON field independently) reduces correction time by 35% in pilot data but adds a custom front-end build of roughly 3 developer-weeks. For an 8-week timeline, the binary gate is the pragmatic choice; field-level approval is a phase-two enhancement.

Recommendation: The 8-Week Pilot and Managed Operation

The 8-week timeline breaks down as follows:

Weeks 1–2: Process audit. Map the current screening workflow, define the error-rate metric (percentage of assessments requiring correction on ≥2 fields), and capture a 2-week baseline of cycle time and error rate from the existing process. Deliverable: a one-page baseline report with the target: reduce cycle time from 22 min to <5 min, reduce error rate from 31% to <15%.
Weeks 3–5: Build. Stand up the n8n workflow, the RAG pipeline (chunking, embedding, pgvector index, prompt template), and the Gmail/Drive integration. Run 200 shadow-mode applications where the AI drafts assessments in parallel with the human process, and the team compares outputs without the AI output reaching candidates.
Weeks 6–7: Pilot with approval gate. Switch to live mode: the AI drafts, the recruiter approves, the candidate receives the assessment. Measure cycle time and error rate daily. Tune the prompt template and retrieval parameters (chunk size, top-k, similarity threshold) based on correction patterns.
Week 8: Handover and managed operation. Document the n8n workflow, the prompt versioning scheme, and the monitoring dashboard (latency, API cost, error-rate trend). Transition to a managed operation contract: a named engineer handles prompt tuning, model updates, and incident response. The firm retains ownership of the n8n instance and the vector store; Forfis manages the ML layer.

The deliverable is not a software product. It is a measured, repeatable process with a named owner and a cost per ticket that the finance team can track.

RAG Candidate Screening with n8n: Cutting Cycle Time in a 300-Person UK Law Firm

The Back-Office Bottleneck in UK Professional Services Recruiting

Mechanism: n8n Orchestration and the RAG Pipeline

Trade-offs: Model, Vector Store, and Approval Granularity

Recommendation: The 8-Week Pilot and Managed Operation

Comments

Leave a Reply Cancel reply

More posts

Austrian E-Commerce Firm Cuts Candidate Screening Cycle Time 40% with AI Pilot

How a Zurich Professional Services Firm Cut Monthly Close From 14 Days to 4

German E-Commerce Brand Cuts First-Response Time 63% With a pgvector Voice Agent

AI Process Audit and RAG Pipeline for Fintech Lead Qualification in Austria