Forem: Tim Rutana

From RAG to Multi-Agent AI for Job Matching

Tim Rutana — Mon, 23 Jun 2025 10:44:11 +0000

A while back, I wrote a blog post about building an AI resume matcher using a RAG approach with Java and Google Vertex AI. I originally built a RAG-based AI to match resumes against job postings using a vector store. It was a fantastic project, but it got me thinking: how could this be even more intelligent and nuanced?

That question led me straight to the Google ADK Hackathon. The challenge was to build autonomous multi-agent systems, which felt like the perfect evolution of my previous project. So, I decided to tackle the same problem job matching, but with a completely new architecture. In this post, I'll walk you through my journey building JobMatch AI and explore why a multi-agent system was a game-changer.

🚀 Let's get started!

🤔 The Problem (Revisited)

The core problem remains the same: finding the right job is overwhelming. Manually sifting through roles is exhausting. My goal was to create an AI assistant to do the heavy lifting, but this time, I wanted to build a system that could reason about a candidate's profile on a deeper level.

🛠️ What is the Agent Development Kit (ADK)?

Before we dive into the specifics of my project, it's helpful to understand the core technology that made it possible. The Agent Development Kit (ADK) is an open-source framework provided by Google for building AI agents. Think of it as a toolkit that simplifies the process of creating sophisticated AI applications. Instead of just having a single AI model, the ADK helps you build and orchestrate multiple agents that can collaborate, use tools, and follow complex workflows to solve problems. It handles the tricky parts of making agents work together, allowing developers like me to focus on the logic and strategy of the agents themselves.

⚙️ Building the AI Hiring Committee: A Look Under the Hood

In my previous RAG project, a single "generalist" AI handled everything. For the hackathon, I moved to a "team of specialists." Using the ADK, I created a SequentialAgent that acts as the team coordinator, ensuring each agent performs its task in a precise order. It’s like an automated assembly line for career matching.

But why is this "team of specialists" approach better? In my experience, it leads to significantly more accurate and reliable results. A single, generalist AI trying to handle everything at once can get overwhelmed. It might miss nuances in the resume, fail to properly weigh career aspirations against experience, or get sidetracked during the scoring process. By breaking the problem down, each agent can focus on doing one thing exceptionally well. This division of labor ensures every step of the process is handled with higher precision, leading to a final list of job matches that are genuinely a better fit for the user.

🏛️ Architecture Overview

Before diving into the specifics of each agent, let's take a high-level look at the system's architecture. The entire application is hosted on Google Cloud, leveraging a few key services to make the magic happen.

Here's a breakdown of the flow:

The User uploads their resume and aspirations to the web application.

The request hits the JobMatch AI App, a Java application built with the Java ADK running on Google Cloud Run.

The ADK orchestrates the multi-agent workflow. For all language processing tasks, summarizing the resume, scoring jobs, and formatting the final output, the agents make calls to Vertex AI, specifically using the Gemini 2.0 model.

When the SearchAgent needs to find jobs, it uses a static tool to invoke a query against the job postings stored in a Firebase DB.

Finally, the scored and formatted job matches are returned to the user through the web app.

This setup creates a robust and scalable system where the application logic on Cloud Run coordinates the powerful AI capabilities of Vertex AI and the data storage of Firebase.

🤝 Here’s how the four-agent team works together

Step 1: The Profile & Goal Synthesizer (SummarizeAgent)

Everything starts here. This first agent is a specialist in understanding people. It takes the raw text of a user's resume and their career aspirations and gets to work. Its most critical instruction is to prioritize aspirations over experience. If a software developer wants to move into product management, this agent focuses on that goal. It intelligently extracts transferable skills from their past to support their future. It then synthesizes all this information into a detailed user profile, creating a rich summary for later analysis and a lean set of search terms for the next agent in the chain.

Step 2: The Job Query Specialist (SearchAgent)

This agent has one job, and it’s strictly enforced: query the job database. During early tests, I ran into the classic LLM problem of "hallucination," where the model would invent jobs. The solution was to build a highly constrained agent. The SearchAgent is only permitted to use a single tool, getAllJobPostings, which connects to my project's Firebase database. (I chose Firebase for its flexibility, which was perfect for rapid prototyping during a hackathon). The agent is explicitly forbidden from inventing, modifying, or filtering jobs. It takes the search profile from the first agent, calls the tool, and passes the exact, unmodified results to the next agent. This completely solved the hallucination issue by separating the tasks of searching and thinking.

Step 3: The Analytical Scorer (ScoringAgent)

Now that we have a user profile and a list of potential jobs, it's time for the heavy analysis. This agent acts as a highly analytical hiring manager. For every single job, it performs a multi-dimensional analysis, scoring the fit based on three key areas:

Aspiration Fit (The Most Important Factor): How well does this job align with the user's stated career goals?

Skill Fit: Do the user's skills match what the job requires?

Experience Fit: Is the seniority and type of experience a good match?

It then generates a comprehensive analysis for each job, containing the original job posting, a breakdown of the scores, an overall score from 0-100, and a brief, data-driven reasoning for its decision.

Step 4: The Encouraging Matchmaker (MatchmakerAgent)

This is the final agent in the sequence, and it's the one responsible for communicating with the user. It takes the list of scored jobs from the ScoringAgent and first filters out anything with a score below 70, we only want to show high-quality matches. It then sorts the best jobs and crafts a personalized, encouraging report in Markdown. It doesn't just list the facts; it builds a narrative. It rephrases the reasoning in a friendly tone and, most importantly, explicitly connects the job back to the user's aspirations (e.g., "This is a fantastic opportunity because it directly aligns with your goal of moving into Product Management."). This final, human-centric touch is what turns a list of data into actionable career advice.

This is just a high-level overview of how the agents collaborate. If you're interested in diving deeper into the prompts and the specific implementation of each agent, you can find the complete source code on my GitHub repository.

🎨 From Programmer Art to Polished UI: A Visual Journey

While the agents were the core of the project, the user interface is what brings it to life. My initial UI was classic "programmer art" functional, but not exactly beautiful. It had the basic elements needed to upload a file and see the results, but it lacked any design polish.
The prototype:

This is where I turned to some incredible Google tools that felt like a superpower. Using Google Stitch, I was able to quickly create a clean, professional mockup of what I wanted the final application to look like.
The mockup:

I fed the visual mockup from Stitch directly to Gemini, and it generated the frontend code to bring that design to life. This workflow was a complete gamechanger, allowing me to go from a basic mockup to a polished, user friendly interface without spending days on frontend development and UI designing.
The final result:

🎯 The Result

The final application is simple and powerful. You visit the site, upload your resume (and optionally, your career aspirations), and within moments, the AI hiring committee gets to work, delivering a personalized report of your top matches.

Watch the submission video here:

✅ Wrapping Up

This hackathon was an incredible learning experience. Adopting a multi-agent architecture proved to be a game-changer for accuracy, showing that a team of specialist AIs can outperform a single generalist by breaking a complex problem down into manageable, high-precision tasks. To complete my submission, I even used Veo to generate the demo video, another example of how AI can be a massive force multiplier in a time crunched solo person project.

🔮 What's Next for JobMatch AI?

This project is currently a prototype, but there's so much potential. I'd love to integrate more job sources and build pre-filtering tools for the search agent. The ultimate dream? An agent that, with your permission, could even auto-apply to your top matches!

Let me know if you try it out! What improvements would you make?

👨‍💻 Happy coding!

From Prototype to Production - Local Kubernetes: Our AI Resume Matcher's Journey

Tim Rutana — Mon, 02 Jun 2025 06:19:46 +0000

Hey everyone, Tim and Juri here! 👋

Remember that awesome AI Resume Matcher we built together in our last post? (If you missed it or need a refresher, you can check it out right here). We got our Java Spring Boot application, with Google Vertex AI (Gemini), to scan CVs and match them with job descriptions, all neatly packaged with Docker Compose. 🐳

It was a fantastic first step, turning an idea into a working prototype. But what comes next on its journey from prototype to production? How do we make it more robust, scalable, and ready for bigger things? That's where Local Kubernetes enters the scene!

📝 What You'll Learn

🐳 Containerizing our Java Spring Boot AI application with Docker by writing a Dockerfile.
⚙️ Setting up a local Kubernetes environment right on your machine (we'll look at options like Minikube and Docker Desktop).
📜 Crafting Kubernetes deployment manifests – the YAML files that tell Kubernetes how to run our AI Resume Matcher app and its PostgreSQL (pgvector) database.
🔑 Securely configuring Google Cloud authentication for Vertex AI so our application can access it from within the Kubernetes cluster.
🌐 Exposing your application to be accessible from your browser using a Kubernetes Service.

🤔 Our Motivation: Why Go Local K8s?

So, why Local Kubernetes if Docker Compose worked? Great question! While Docker Compose is fantastic, leveling up to K8s locally offers key benefits for our "journey to production":

Mimics Production: Get a feel for how apps run in real-world, production-like clusters.
Handles Growth: Better equipped to manage more complex applications and future microservices.
Cloud-Ready Skills: Smooths your transition to cloud platforms like Google Cloud and SAP BTP.
Standardized Deployments: Promotes more consistent and reliable application rollouts.

Essentially, using local K8s helps us build production-ready skills and prepares our AI Resume Matcher for its future in the cloud! ☁️

⚙️ Prerequisites

Our AI Resume Matcher Project: You'll need the application code from our previous blog post. If you haven't got it yet, you can grab it from our repository.
Docker Desktop: includes one click local Kubernetes.
Google Cloud Account & Project: Since our application relies on Google Vertex AI:
- A Google Cloud Platform (GCP) account.
- A GCP Project where you've enabled the Vertex AI API (as covered in the previous post).

📦 Step 1: Containerizing Our AI Resume Matcher

First things first, we need to package our Spring Boot application into a Docker container. This makes it portable and ensures it runs the same way everywhere, from our local machine to a Kubernetes cluster.

Building the Application with Gradle

Since our project uses Gradle, the first step is to build our application to produce an executable JAR file. Open your terminal in the root directory of the smarthire-blog project and run:

./gradlew build

This command will compile your code, run tests and package everything into a JAR file. You'll find this JAR in the build/libs/ directory.

Crafting the Dockerfile

Next, we need to create a file named Dockerfile (no extension) in the root of our project. This file contains the instructions Docker uses to build our image. Here’s the content for our Dockerfile:

FROM eclipse-temurin:21-jre-jammy
RUN groupadd --system spring && useradd --system --gid spring spring
USER spring:spring
COPY build/libs/*.jar app.jar
ENTRYPOINT ["java", "-jar", "/app.jar"]
EXPOSE 8080

Let's break down what each line does:

FROM eclipse-temurin:21-jre-jammy: This tells Docker to use the official Eclipse Temurin Java 21 JRE (Java Runtime Environment) image based on Ubuntu Jammy as our base. Using a JRE image is great because it's smaller than a full JDK image, making our container more lightweight as it only contains what's needed to run the compiled Java code.
RUN groupadd --system spring && useradd --system --gid spring spring: Here, we create a system group named spring and then a system user also named spring, assigning it to that group. This dedicated, unprivileged user will run our application, enhancing security.
USER spring:spring: This instruction switches the active user inside the Docker image to our newly created spring user. All subsequent commands, including our ENTRYPOINT, will run as this user.
COPY build/libs/*.jar app.jar: This line copies the JAR file created by the Gradle build (from build/libs/ – the *.jar helps grab the versioned JAR file without needing to specify the exact name) into the container's filesystem and names it app.jar.
ENTRYPOINT ["java", "-jar", "/app.jar"]: This specifies the command that will be run when the container starts. It executes our Spring Boot application using java -jar. The /app.jar path refers to the JAR we copied in the previous step (it's placed in the root of the container's filesystem by default if no WORKDIR is specified).
EXPOSE 8080: This line informs Docker that the application inside the container will listen on port 8080 at runtime. This doesn't actually publish the port; it's more of a documentation for users and a hint for tools.

Building the Docker Image

With our Dockerfile in place and the application JAR built, we can now build the Docker image. In your terminal (still in the root directory of your project), run:

docker build -t smarthire-app:v1 .

Let's dissect this command:

docker build: The command to build an image from a Dockerfile.
-t smarthire-app:v1: The -t flag tags our image. Here, smarthire-app is the name of the image, and :v1 is the tag. Use a specific tag like v1, not :latest. Kubernetes default imagePullPolicy for :latest is Always (tries pulling remotely), while for v1 it's IfNotPresent (uses your local image if available).
.: This dot at the end tells Docker to look for the Dockerfile in the current directory. After this command finishes, you'll have a Docker image ready to be run locally! You can check your list of images with docker images.

⚙️ Step 2: Launching Kubernetes with Docker Desktop

Now that we have our application containerized, it's time to set up our local Kubernetes environment. For this guide, we'll use the Kubernetes cluster that comes built into Docker Desktop.

Enabling Kubernetes in Docker Desktop

If you haven't enabled Kubernetes in Docker Desktop yet, it's just a few clicks away:

Go to Settings (usually the gear icon ⚙️).
Navigate to the Kubernetes section in the sidebar.
Make sure the Enable Kubernetes checkbox is ticked.
Click Apply & Restart. Docker Desktop will then download the necessary Kubernetes components and start your single-node cluster. This might take a few minutes.

Verifying Your Kubernetes Cluster

To interact with Kubernetes, we use a command-line tool called kubectl (Gets installed with enabling Kubernetes in Docker Desktop).

Let's verify that your cluster is up and running. Open your terminal and type:

kubectl get nodes

Since Docker Desktop runs a single-node cluster, you should see one node listed, typically named docker-desktop, with a status of Ready.

Congratulations, you have a local Kubernetes cluster running and ready for our AI Resume Matcher. 🎉

✨ Step 3: Orchestrating with Kubernetes - Writing Our Manifests

With our Kubernetes cluster ready and image built, it's time to define how our application and database will run using Kubernetes manifest files. These YAML blueprints describe our desired setup. We'll create two main files for this.

The Database Blueprint (PostgreSQL + pgvector)

First, let's define our PostgreSQL database, including data persistence and internal access. Create k8s/postgres-k8s.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: postgres
spec:
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: pgvector/pgvector:pg17
          ports:
            - containerPort: 5432
          env:
            - name: POSTGRES_DB
              value: "smarthire"
            - name: POSTGRES_USER
              value: "YOUR_USER"
            - name: POSTGRES_PASSWORD
              value: "YOUR_PASSWORD" # ❗ Use K8s Secrets in production!
          volumeMounts:
            - name: postgres-data
              mountPath: /var/lib/postgresql/data
      volumes:
        - name: postgres-data
          persistentVolumeClaim:
            claimName: postgres-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Service
metadata:
  name: postgres
spec:
  type: ClusterIP
  ports:
    - port: 5432
      targetPort: 5432
  selector:
    app: postgres

Key parts of postgres-k8s.yaml:

Deployment: Runs the pgvector/pgvector:pg17 image. We've set crucial environment variables like POSTGRES_DB, POSTGRES_USER, and POSTGRES_PASSWORD directly for simplicity (though for passwords, Kubernetes Secrets are recommended in production). It also mounts a persistent volume for data.
PersistentVolumeClaim (PVC): Named postgres-pvc, this requests 1Gi of storage, ensuring our database data isn't lost if the pod restarts.
Service: Named postgres and of type: ClusterIP, this gives our database an internal, stable IP address and DNS name (postgres:5432) so our application can reach it from within the cluster.

The AI Resume Matcher App Blueprint (app-k8s.yaml)

Next, the manifest for our Spring Boot AI Resume Matcher application. Create k8s/app-k8s.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: smarthire-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: smarthire-app
  template:
    metadata:
      labels:
        app: smarthire-app
    spec:
      containers:
        - name: smarthire-app
          image: smarthire-app:v1 # Our image from Step 1
          imagePullPolicy: IfNotPresent # Use local image if present
          ports:
            - containerPort: 8080
          env:
            - name: SPRING_DATASOURCE_URL
              value: "jdbc:postgresql://postgres:5432/smarthire"
            - name: SPRING_DATASOURCE_USERNAME
              value: "YOUR_USER"
            - name: SPRING_DATASOURCE_PASSWORD
              value: "YOUR_PASSWORD"
            - name: GOOGLE_APPLICATION_CREDENTIALS
              value: /etc/gcp-auth/key.json
          volumeMounts:
            - name: gcp-sa-key-volume
              mountPath: /etc/gcp-auth
              readOnly: true
      volumes:
        - name: gcp-sa-key-volume
          secret:
            secretName: gcp-sa-key # GCP Secret (created in Step 4)
---
apiVersion: v1
kind: Service
metadata:
  name: smarthire-app
spec:
  type: LoadBalancer
  ports:
    - port: 8090 # External port
      targetPort: 8080 # App's internal port
  selector:
    app: smarthire-app

Key parts of app-k8s.yaml:

Deployment: Runs our smarthire-app:v1 image (with imagePullPolicy: IfNotPresent to favor local images). It sets environment variables for the database connection (SPRING_DATASOURCE_URL, username, password) and for Google Cloud credentials (GOOGLE_APPLICATION_CREDENTIALS). The Google Cloud credentials will be mounted from a Secret named gcp-sa-key (which we'll create in Step 4).
Service: Named smarthire-app and of type: LoadBalancer, this makes our application accessible externally (e.g., via localhost:8090 in Docker Desktop). It maps the external port 8090 to the application's internal port 8080.

With these manifest files defining our application's structure in Kubernetes, we're ready to move on to the crucial step of handling Google Cloud authentication.

🔑 Step 4: Google Cloud Authentication from Kubernetes

Our AI Resume Matcher application needs to communicate with Google Vertex AI services. When running locally (not in a container), it picks up your user credentials from the gcloud CLI. However, inside a Kubernetes pod, it's a different environment and needs its own explicit way to authenticate securely.

For this setup, we'll use a Google Cloud Service Account and its JSON key. We'll then store this key as a Kubernetes Secret and mount it into our application's pod.

Prerequisites for GCP Authentication

Google Cloud Service Account with appropriate permissions to use Vertex AI (e.g., the "Vertex AI User" role).
JSON key file for this service account downloaded to your local machine. Keep this file secure!

Here is the documentation on how to create a service account.

Creating the Kubernetes Secret

Now, let's take that downloaded JSON key file and create a Kubernetes Secret from it. This secret will securely store the key within your Kubernetes cluster.

Open your terminal and run the following kubectl command. Make sure to replace /path/to/your-downloaded-service-account-key.json with the actual path to your key file. The name of the key file itself doesn't matter as much as its content and the path you provide in the command.

kubectl create secret generic gcp-sa-key \
  --from-file=key.json=/path/to/your-downloaded-service-account-key.json

Let's break this command down:

kubectl create secret generic gcp-sa-key: This tells Kubernetes to create a generic secret named gcp-sa-key. This is the exact name (gcp-sa-key) our application's deployment manifest (app-k8s.yaml) expects for the secret.
--from-file=: This flag tells kubectl to create the secret from the contents of one or more files.
key.json: This will be the filename inside the secret data. Our application's deployment is configured to look for this specific filename (key.json) when the secret is mounted as a volume.
/path/to/your-downloaded-service-account-key.json: The actual path to the JSON key file on your local system.

After running this, Kubernetes will store the contents of your JSON key in the gcp-sa-key secret.

🚀 Step 5: Deploy! Applying Our Manifests

We'll use kubectl apply to deploy our application using the YAML files from Step 3. Make sure your terminal is in your project's root directory, where your k8s folder is located.

Applying the Manifests

Apply the database manifest first, then the application manifest:

kubectl apply -f k8s/postgres-k8s.yaml
kubectl apply -f k8s/app-k8s.yaml

These commands instruct Kubernetes to create the deployments, services, and other resources we defined.

Verifying Your Deployment

Let's quickly check if everything is running correctly:

Check Pod Status:

To see if our application and database pods are up and running:

kubectl get pods

You should see pods for postgres and smarthire-app eventually reach a STATUS of Running. This might take a moment.

Check the Application Service:

To find out how to access your deployed application:

kubectl get services

Look for the smarthire-app service in the list. If you're using Docker Desktop, its TYPE will be LoadBalancer, and the EXTERNAL-IP should be localhost. Note the PORT(S) column – it will show something like 8090:XXXXX/TCP. This means your application should be accessible at http://localhost:8090.

Inspect Application Logs:

If the smarthire-app pod isn't behaving as expected (or you just want to see its output, such as the Spring Boot startup messages), you can check its logs.
First, get the exact pod name (it will start with smarthire-app-):

kubectl get pods

Then, display the logs for that specific pod (replace with the actual name from the command above):

kubectl logs <smarthire-app-pod-name>

To follow the logs in real-time (useful for seeing live requests or errors), use the -f flag:

kubectl logs -f <smarthire-app-pod-name>

If your smarthire-app pod is Running and the logs show a successful startup (like the Spring Boot ASCII art and "Tomcat started on port(s): 8080" message), then congratulations! Your AI Resume Matcher should now be running on your local Kubernetes cluster! 🎉

🧪 Step 6: Test Drive Time! Checking Our K8s-Powered App

It's time to make sure it's working as expected by sending a test request.

First, remember that our application should be accessible at http://localhost:8090 (based on the smarthire-app Service of type LoadBalancer we checked with kubectl get services in Step 5). The endpoint for uploading a resume is still /api/candidates/upload.

Now, using Bruno (or your preferred API client), send a POST request to http://localhost:8090/api/candidates/upload. Make sure the request body contains the plain text of a sample resume from our previous post.

You should receive a successful JSON response. This response will list the job offers that best match the CV you provided, just like the example response we saw in our initial Docker Compose setup.

🎯 Wrapping Up: Our AI Resume Matcher on Kubernetes!

We've successfully taken our AI Resume Matcher application from a Docker Compose setup and deployed it onto a local Kubernetes cluster.

Together, we've walked through:

🐳 Containerizing our Java Spring Boot application with Docker.
📜 Crafting the necessary Kubernetes manifest files for both our application and its PostgreSQL database.
🔑 Configuring Google Cloud authentication from within Kubernetes using a Service Account and Secrets.
🚀 Deploying all components to the cluster.
🧪 Testing our application to ensure it's running correctly.

By working through these steps, you've not only got our AI Resume Matcher running in a more robust, orchestrated environment but also gained hands-on experience with key DevOps practices and cloud-native technologies.

Did you run into any challenges, or do you have suggestions for improvements? Let us know in the comments below!

👉 Check out the project on GitHub

👨‍💻 Happy coding!

Using RAG with Java Spring Boot AI & Google Vertex AI: Crafting an Automated Resume Matcher

Tim Rutana — Wed, 26 Feb 2025 16:04:21 +0000

Imagine this: You're on the hunt for a new job at a major tech company. Instead of scrolling through 50 different job descriptions, wouldn’t it be awesome if you could simply upload your CV and get a curated list of opportunities that are the perfect fit? Well, that's exactly what we're building!

We’re Tim and Juri, two software engineers who love diving into new tech challenges and sharing what we learn. In this post, we'll walk you through building an AI-powered resume matching service using Java Spring Boot and Google Vertex AI.

🚀 Let's get started!

📝 What You'll Learn

How to set up an ingestion pipeline to read and store job descriptions.
Implementing a matching service that uses AI to compare resumes with job descriptions.
Configuring a chat client with a custom system prompt to drive the AI logic.
Exposing your service via a REST API to handle resume uploads and return job matches.

🤔 The Problem

Finding the right job can be overwhelming, especially when you’re manually sifting through dozens of roles. What if you could upload your CV once and let an AI sort through job postings, matching you with the positions that best suit your skills?

That’s the idea behind our project.

⚙️ Components of Our System

🏗️ 1. Ingestion Pipeline (RAG Pipeline)

Our pipeline reads job descriptions from text files and stores them in a vector store for efficient retrieval. In a further blog post we want to make this example more real by connecting it to a real HR solution.

Docker Compose Setup for PostgreSQL with Vector Extension:

services:
  db:
    image: pgvector/pgvector:pg17 
    container_name: pgvector-db
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: password
      POSTGRES_DB: smarthire
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data

volumes:
  pgdata:

Spring Boot Configuration:

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/smarthire
    username: postgres
    password: password
  ai:
    vertex:
      ai:
        embedding:
          project-id: YOUR_PROJECT_ID
          location: asia-southeast1
          text:
            options:
              model: text-embedding-005

We use Google Vertex AI for creating text embeddings, which will help in comparing job descriptions with candidate resumes. We add the necessary dependencies and configurations for Vertex AI in our Spring Boot application. You need to install the gcloud cli, here is how.

implementation 'org.springframework.ai:spring-ai-vertex-ai-embedding-spring-boot-starter'

Code Snippet for the Ingestion Pipeline:

@Component
public class IngestionPipeline {

    private final VectorStore vectorStore;

    @Value("classpath:jobs/backend.txt")
    Resource backendJobDescription;
    @Value("classpath:jobs/fullstack.txt")
    Resource fullstackJobDescription;
    @Value("classpath:jobs/marketing.txt")
    Resource marketingJobDescription;

    public IngestionPipeline(VectorStore vectorStore) {
        this.vectorStore = vectorStore;
    }

    @PostConstruct
    public void run() {
        var backendDocument = getDocument(backendJobDescription, "1");
        var fullstackDocument = getDocument(fullstackJobDescription, "2");
        var marketingDocument = getDocument(marketingJobDescription, "3");
        List<Document> documents = new ArrayList<>(backendDocument);
        documents.addAll(fullstackDocument);
        documents.addAll(marketingDocument);
        vectorStore.add(new TokenTextSplitter().apply(documents));
    }

    private List<Document> getDocument(Resource textFile, String id) {
        var textReader = new TextReader(textFile);
        textReader.getCustomMetadata().put("jobId", id);
        textReader.setCharset(Charset.defaultCharset());
        return textReader.get();
    }
}

For the text files we used check out the project on Github.

🤖 2. Matching Service

This service compares a candidate's resume against job descriptions using a chat client and returns job recommendations.

@Service
public class MatchingService {

    private final ChatClient chatClient;

    public MatchingService(ChatClient chatClient) {
        this.chatClient = chatClient;
    }

    public List<JobOfferSuggestion> matchJobOffers(String userCV) {
        return chatClient.prompt()
                .user(userCV)
                .call()
                .entity(new ParameterizedTypeReference<List<JobOfferSuggestion>>() {});
    }
}

The interesting part here is new ParameterizedTypeReference<List<JobOfferSuggestion>>() {} which transforms with the magic of Spring the response from Gemini into a Java Pojo. That we can then further use to process the result.

Job Offer Data Structure:

public record JobOfferSuggestion(int jobId, String matchDescription, double relevanceScore) {}

💬 3. Chat Client Configuration

The system prompt is crucial for accurate resume matching.

@Configuration
class ChatClientConfig {

  private final static String SYSTEM_PROMPT = """
      You are an AI-powered job matching assistant. Your task is to analyze a user's CV and compare it against a list of provided job offers to identify the best matches.

      **Input:**

      *   **User CV:** The user will provide their Curriculum Vitae (CV) as text.
      *   **Job Offers:** A list of job offers, each described with at least a `JobId` and a detailed job description.  Consider other potentially provided job offer attributes like location, salary range, required skills, and experience level.

      **Process:**

      1.  **CV Analysis:**  Analyze the user's CV to identify key skills, experience, education, and career goals.
      2.  **Job Offer Comparison:**  Compare the user's qualifications against the requirements and preferences outlined in each job offer. Prioritize offers where the user's skills and experience closely align with the job description.
      3.  **Matching Rationale:**  For each job offer deemed a good fit, provide a concise explanation of why the user's CV makes them a suitable candidate, highlighting specific skills and experiences that match the job requirements.
      4.  **Relevance Score (Optional):**  Consider adding a relevance score to the matches to give the user an idea of the best match.

      **Output:**

      Return a JSON array of job recommendations. Each object in the array should have the following structure:

      [
        {
          "jobId": <integer>, // The JobId of the matching offer
          "matchDescription": "<string>", // Explanation of why the CV fits the job offer, citing specific skills and experiences. Be concise.
          "relevanceScore": <float between 0 and 1>, // Optional relevance score.  1 is a perfect match.
        },
        {
          "jobId": <integer>,
          "matchDescription": "<string>",
          "relevanceScore": <float between 0 and 1>,
        },
      ]

      In case there is the CV doesn't match don't add it to the array.
      """;

  @Bean
  ChatClient chatClient(ChatClient.Builder builder, VectorStore vectorStore) {
    return builder
        .defaultSystem(SYSTEM_PROMPT)
        .defaultAdvisors(new QuestionAnswerAdvisor(vectorStore))
        .build();
  }

}

In order to use the Google Gemeni API, we need to add the following dependency.

    implementation 'org.springframework.ai:spring-ai-vertex-ai-gemini-spring-boot-starter'

and the configure the following in our application.yml.

spring:
  ai:
    vertex:
      ai:
        gemini:
          project-id: YOUR_PROJECT_ID
          location: asia-southeast1
          chat:
            options:
              model: gemini-1.5-pro-002

🖥️ 4. The Controller

Handles incoming resume uploads and returns job matches.

@RestController
@RequestMapping("/api/candidates")
class CandidateController {

    private final MatchingService matchingService;

    CandidateController(MatchingService matchingService) {
        this.matchingService = matchingService;
    }

    @PostMapping("/upload")
    ResponseEntity<List<JobOfferSuggestion>> uploadText(@RequestBody String text) {
        var result = matchingService.matchJobOffers(text);
        return ResponseEntity.ok(result);
    }
}

🚀 Running the Application

1️⃣ Start your Docker Container:

docker-compose up

2️⃣ Upload a Sample Resume:
Use Bruno or any API client to send a POST request:

POST http://localhost:8080/api/candidates/upload

We just took one example resume from the internet.

📌 Response Example:

[
  {
    "jobId": 1,
    "matchDescription": "Charles has a B.S. in Computer Science and over 7 years of experience as a Software Engineer. His experience with Javascript (NodeJS, ReactJS), RESTful APIs, and front-end development aligns well with the Front-End Engineer role.  His experience with AWS and scaling platforms also makes him a strong candidate.",
    "relevanceScore": 0.9
  },
  {
    "jobId": 2,
    "matchDescription": "Charles's background as a Software Engineer, experience with Python, RESTful APIs, and databases (SQL, NoSQL) makes him suitable for the Back-End Engineer role. His experience building internal tools and automating QA processes is a plus.",
    "relevanceScore": 0.8
  }
]

🎯 Wrapping Up

In this post, we built an AI-powered resume matching service using:
✅ Java Spring Boot
✅ Google Vertex AI
✅ PostgreSQL with Vector Extensions

Let us know if you try this out! What improvements would you make?

👉 Check out the project on GitHub

👨‍💻 Happy coding!