In the first half of 2024, candidates submitted 173 million job applications against roughly 19 million open positions, a 31% year-over-year jump in applications set against a 7% rise in requisitions. That imbalance between applications and openings is why keyword search is finished as a sourcing primitive. The funnel is too wide for human review, and buying a black-box matcher means trusting someone else's taxonomy for your roles. A private matching engine built on resume embeddings gives you back control, and the vocabulary to evaluate every vendor line by line.
The architecture below is what a small platform team can stand up in a few sprints. It covers embedding model choice, the vector store, ATS plumbing, re-ranking, and the audit trail regulators will ask for. None of it is exotic. All of it beats grepping Boolean strings across LinkedIn tabs.
Picking an Embedding Model That Fits Your Volume
The embedding model is the one decision you cannot cheaply reverse later, because re-embedding a million resumes costs real money. Two sensible defaults exist, and the trade-off between them is concrete.
An academic benchmark on resume screening found that Sentence-BERT reached 90% accuracy versus BERT's 86%, and cut per-resume screening time from roughly one second to 0.061 seconds. For self-hosted pipelines, that difference compounds fast across a weekly refresh of a million candidate profiles. Sentence-BERT also returns 384-dimensional vectors, which halves storage versus BERT's 768.
Managed OpenAI embedding models are the other default. The v3 family supports dimension reduction via the API parameter, so a team can trade MTEB score for cost without re-running the whole corpus. Pick based on what your reviewers actually do downstream: recruiters spend an average of 7.4 seconds reviewing each resume at initial screen, so any embedding model that produces a top-20 list within that window is fast enough. Chasing the last MTEB point past that is vanity spend.
The Vector Store Is Mostly a Boring Decision
Two paths, both legitimate. If your data platform already runs PostgreSQL, the pgvector extension puts your candidate embeddings next to the structured fields your ATS already stores — employer history, legal work authorization, source channel. One database, one backup story, one access-control model. It is the path 41% of teams building on Postgres have taken.
Dedicated vector databases like Pinecone, Qdrant, or Weaviate are the right pick when your profile corpus clears a few million rows, when you need multi-tenant isolation per hiring team, or when hybrid search with BM25 keyword scoring is a first-class requirement. Roughly 68% of production RAG systems blend vector and keyword search, which is usually easier in a purpose-built store. Either way, treat the vector store as a cache of a canonical record in your ATS, not as the source of truth. That constraint makes re-embedding, schema migration, and GDPR deletion requests manageable rather than terrifying.
Plumbing the ATS Through Webhooks
The pipeline is three events: a resume lands, a profile changes, a candidate requests deletion. Wire each one to an idempotent handler that enqueues an embed job, writes the new vector to the store, and updates a document version in the ATS record. Three details matter more than they look.
- Chunking. Embed whole resumes for role matching, but also chunk by section for skills search. One vector per candidate under-represents the long tail of their experience.
- Idempotency keys. ATS webhooks retry. Use the content hash of the parsed resume as the embedding key so a re-delivery is a no-op, not a duplicate row.
- Backfill, then stream. Backfill the historical corpus in a one-time batch before you flip the webhook on. The first weekend is expensive; every subsequent day is marginal.
Teams that treat the ATS as the matching engine's spine rather than an afterthought end up with cleaner candidate intelligence and far fewer reconciliation tickets. For context on where this fits inside a broader stack, see our walkthrough of AI sourcing marketplace economics.
Re-ranking Turns Recall Into Precision
Vector search is a recall tool. It returns the 200 candidates most semantically similar to the job description, and some of those matches are noise. A re-ranker, usually a cross-encoder that scores each query/resume pair jointly, cuts that list to the 20 a recruiter should actually see. Roughly 52% of production systems now run a dedicated re-ranker, and the reason is unglamorous: first-stage retrieval optimizes for speed over judgment, and the top of its ranked list is often wrong in ways a second pass catches cheaply.
The economics line up. Embedding retrieval runs at a fraction of a cent per query. Re-ranking the top 200 with a cross-encoder adds roughly a cent. You pay precision costs only on the candidates who matter, not on the long tail. If you also pass the re-ranked shortlist through a retrieval-augmented generation layer, you inherit RAG's broader quality gains — the pattern has been shown to reduce hallucinations by 65% to 80% compared to raw LLM inference, at 12x to 20x lower cost than fine-tuning. The QA habits are the same ones that apply to any AI sourcing agent going in front of hiring managers: sample the output weekly, measure precision at 10, and feed corrections back as training signal.
Bias Auditing and Retention Are Not Optional
A private matching engine inherits every obligation a vendor would, and then some. Under GDPR, candidate data — including AI-generated match scores — is personal data; it must generally be deleted within six to twelve months for unsuccessful candidates without explicit retention consent, and subject-access requests get a 30-day response window. Build those windows into the pipeline from the start. A deletion that cascades from the ATS through the vector store and the re-ranker's training set is far cheaper to design on day one than to retrofit after a complaint.
Jurisdictional rules on automated hiring decisions are tightening in parallel. New York's Automated Employment Decision Tool rule requires an independent bias audit within one year of use, 10 business days of candidate notice before screening, and public disclosure of the audit results. Several other jurisdictions are pattern-matching. Build the audit log as a first-class table — query, candidates returned, scores, re-ranker outputs, final decision — and you can produce disparate-impact ratios on demand instead of panicking before a renewal.
The engineering work ends here. The judgment calls do not. Screening at this volume still needs explicit rules about disqualifiers your system should flag rather than filter silently, which is why patterns from traditional resume red flags belong encoded as review prompts, not as hard cuts.
Build Versus Buy, in the Same Vocabulary
The checklist for a buy decision is the same list you just used for build: which embedding model, which store, how webhooks reconcile, what the re-ranker does, how bias audits are produced. If a vendor cannot answer those five questions on a call, you are back in black-box territory and the control argument for building evaporates. If the vendor can answer them, you have a serious comparison to make on total cost of ownership, including the engineering team you would have to hire and retain to operate the pipeline yourself. Either answer is defensible. The one that is not defensible is choosing without the vocabulary.
Back to the 173 million applications. The point of the architecture above is not to review all of them — that was never the job. The point is to make the 200 that matter for a given role findable in milliseconds, re-rankable in seconds, and defensible in an audit. Whether the engine running that work lives in your repo or an AI sourcing agent on someone else's, you now know exactly what you are evaluating.