Recruitment RAG Platform

The problem

Manual candidate screening is slow and shallow: recruiters skim CVs and miss the context scattered across a candidate's GitHub, LinkedIn, and personal sites. The lab wanted an end-to-end system that could assemble a candidate's public footprint, match it against a role by meaning rather than keyword overlap, and run a first-pass conversational interview without a human in the loop for every candidate.

Constraints

• Fixed internship window (Jun–Aug 2025) to ship an end-to-end system with a 4-person team.
• Input data is heterogeneous and personal — CVs, GitHub, LinkedIn, ORIC, and personal sites vary wildly in structure and carry sensitive PII.
• Ran on lab servers, not managed cloud — deployment had to be self-hosted and reproducible.
• The interview agent had to feel conversational: low latency and no repeated questions across a session, which is a state problem, not just a prompt.
• Constrained to small open models (Llama 3 8B via Groq) rather than frontier APIs.

Approach & key decisions

• Semantic retrieval over keyword filtering — Nomic embeddings in Weaviate for candidate-to-job matching.

  A candidate's fit lives in context and phrasing that keyword filters miss; embedding both sides into one space lets the match rank on meaning.

• LLM-enhanced job descriptions before embedding, via Llama on Groq.

  Raw job descriptions are terse and inconsistent; normalizing and expanding them first gives the retrieval side a richer, more comparable vector to match against.

• Multi-agent architecture for the interview agent rather than a single looping prompt.

  Keeping questioning dynamic and non-repeating is a state-management problem — separating question generation from context tracking prevents the agent from looping or asking what it already asked.

• Llama 3 8B served on Groq for the interview loop.

  Conversational feel needs low latency; Groq inference kept responses under 5s (self-reported) with a small open model instead of a slower or costlier frontier API.

• Containerized microservices (FastAPI + async job processing) on Docker Compose.

  Ingestion, embedding, matching, and interviewing have different runtime shapes; splitting them into services with async job handling made the pipeline deployable and reproducible on lab servers.

What I built

• Built a multi-source ingestion pipeline that scrapes and normalizes candidate data from CVs, GitHub, LinkedIn, ORIC, and personal sites.
• Embedded candidate and job data with Nomic and indexed it in Weaviate for semantic candidate-job matching.
• Enhanced job descriptions with Llama models on the Groq API before embedding to improve match quality.
• Built a conversational interview agent on Llama 3 8B with a multi-agent architecture for dynamic, non-repeating questioning.
• Stood up a FastAPI backend with async job processing to decouple long-running ingestion and embedding from request handling.
• Deployed the platform as containerized microservices via Docker Compose on lab servers.

Outcomes

• Led a 4-person team and owned the architecture end to end.■Team lead · Genesys Research Lab
• < 5s Interview agent responds in under 5s with no question repetition across a session.◧Self-reported · CV
• Reduced manual screening time by automating candidate evaluation (no measured percentage claimed).◧Self-reported

Selected media

Limitations & what's next

• Match quality was never independently benchmarked — no precision/recall or relevance evaluation, so the retrieval win is architectural, not measured.
• The sub-5s figure is dev-reported from a specific Groq-served setup, not an audited latency benchmark, and depends on external inference availability.
• An 8B model bounds reasoning depth; a real deployment would want evaluation against frontier models before trusting interview judgments.
• This is a research-lab prototype, not a product with real hiring outcomes — I would not claim it screened real candidates at scale.
• The pipeline ingests sensitive personal data; before any real-world use it needs consent, retention limits, access controls, and a clear lawful basis — that governance layer is out of scope for the internship build.
• Self-hosted on lab servers via Docker Compose — not hardened, monitored, or scaled for production traffic.