Mission Radar AI

AI /

Url

https://mission-radar.stefanoalletti.com

Repository Gtihub

https://github.com/salletti/mission-radar-ai

Production AI Platform for Automated Job Discovery and Semantic Matching

Executive Summary

Mission Radar AI is a production-oriented AI platform that continuously discovers software engineering opportunities, analyzes job descriptions using Large Language Models, semantically matches them against a developer profile, and delivers personalized daily digests.

Unlike typical AI demos, the platform combines asynchronous data pipelines, vector search, LLM-based information extraction, semantic ranking, workflow orchestration, evaluation frameworks, authentication and MCP integration into a single production-ready architecture.

The Problem

Finding relevant freelance or permanent opportunities is surprisingly inefficient.

Job boards return hundreds of loosely related offers.

Keyword search ignores context.

LLM applications require much more than prompt engineering:

• data ingestion
• structured extraction
• semantic search
• ranking
• evaluation
• monitoring
• authentication
• orchestration

Building all these components into a reliable production system was the objective of Mission Radar AI.

System Architecture

Technology Stack

Backend

• Python
• FastAPI
• SQLAlchemy
• PostgreSQL
• pgvector

AI

• Groq
• Sentence Transformers
• Embeddings
• Semantic Search

Orchestration

• Celery
• RabbitMQ
• Redis

Architecture

• Clean Architecture
• DDD
• Repository Pattern
• CQRS-inspired use cases

Authentication

• Auth0
• JWT
• MCP Identity Resolution

Frontend

• React
• TypeScript

Infrastructure

• Docker
• Coolify

Evaluation

• Custom Evaluation Framework
• DeepEval
• Langfuse

Key Engineering Decisions

Quelques décisions qui montrent ton niveau d’architecture :

Clean Architecture

The AI pipeline is completely isolated from infrastructure concerns, allowing every use case to be tested independently.

Asynchronous Processing

Long-running tasks such as data collection, LLM analysis and semantic matching are executed through Celery workers, preventing blocking API requests.

Identity as a Business Concern

Instead of exposing infrastructure identities throughout the application, Auth0 JWTs are translated into business identities before entering the application layer.

MCP Integration

Mission Radar exposes Resources, Tools and Prompt Templates through the Model Context Protocol, allowing AI assistants such as Claude Code to interact with the platform safely.

Evaluation First

LLM outputs are benchmarked using an internal evaluation framework combined with DeepEval to measure extraction quality and detect regressions.

Engineering Challenges Solved

• Continuous acquisition pipeline
• Semantic matching
• Structured extraction from unstructured posts
• Duplicate detection
• Pipeline orchestration
• Authentication for MCP
• AI evaluation
• Distributed processing
• Daily digest generation
• Vector search

Production Features

• Multi-user
• JWT authentication
• Background workers
• Retry policies
• Dockerized deployment
• API separation
• React dashboard
• MCP server
• Evaluation framework
• Observability ready

What I Learned

Building production AI systems is far more about software engineering than prompt engineering.

Reliable AI applications require orchestration, evaluation, architecture, authentication, asynchronous processing and monitoring just as much as they require language models.

AI Evaluation Lab

AI /

Project

AI Evaluation Lab

Repository

github.com/salletti/ai-evaluation-lab

Delivered

May 2026

Executive Summary

AI Evaluation Lab is an independent evaluation framework designed to benchmark RAG pipelines and AI agents using reproducible datasets and automated quality metrics.

Rather than relying on subjective manual reviews, it transforms LLM outputs into measurable engineering signals that can be compared across prompt, retrieval and model iterations.

Because the evaluation engine is completely decoupled from the application under evaluation, the same benchmark can be reused across different AI systems, making evaluation reproducible, comparable and suitable for continuous integration workflows.

Problem

Evaluating LLM applications remains one of the biggest challenges in production AI. Manual reviews are slow, subjective and difficult to reproduce, making it almost impossible to detect quality regressions as prompts, retrieval pipelines or models evolve.

Unlike traditional software, where tests produce deterministic pass/fail results, LLM applications require evaluating probabilistic outputs across multiple quality dimensions such as factual accuracy, relevance and context utilization. Without a structured evaluation process, regressions often remain invisible until they affect end users.

Why This Problem Matters

As AI applications become increasingly integrated into production systems, prompt engineering, retrieval strategies and model upgrades become part of the software lifecycle.

Without automated evaluation, every change introduces uncertainty:

• Did answer quality improve or degrade?
• Is the new retrieval strategy actually better?
• Is the new model worth the additional cost?
• Are regressions acceptable or blocking?

Reliable evaluation becomes an engineering requirement rather than a research exercise. It becomes the foundation for safely evolving AI systems over time.

System Architecture

The evaluation framework is intentionally designed as a standalone system rather than a component embedded inside the application being evaluated.

This separation makes the same benchmark reusable across multiple AI systems without modifying evaluation logic.

Technology Stack

• Python
• FastAPI
• RAGAS
• DeepEval
• LangSmith

Key Engineering Decisions

Standalone Evaluation Framework

Designed the evaluation engine as an independent framework rather than embedding evaluation directly into the application.

This architectural decision allows the same benchmark to evaluate multiple RAG pipelines or AI agents without coupling evaluation logic to business logic, making benchmarks reusable across projects.

Complete Separation of Concerns

The framework only interacts with the public interface of the application under evaluation.

It has no dependency on the application’s internal implementation, business logic, infrastructure or deployment model.

This architectural boundary makes the evaluation engine reusable across heterogeneous AI systems while preserving complete implementation independence.

Framework-Agnostic Evaluation

Instead of relying on a single evaluation framework, the system integrates both RAGAS and DeepEval.

Each framework evaluates different quality dimensions and exposes different trade-offs. Supporting multiple evaluators makes benchmarking more comprehensive while reducing dependency on a single evaluation methodology.

Reproducible Benchmarks

Evaluation datasets are treated as reusable engineering artifacts rather than ad-hoc test cases.

Running the same benchmark repeatedly makes it possible to compare prompt iterations, retrieval strategies and model versions under identical conditions.

Evaluation Methodology

Each benchmark executes the same evaluation dataset against the target AI system.

For every evaluation case, the framework collects the generated response and computes multiple complementary quality metrics including:

• Faithfulness
• Answer Relevancy
• Context Precision
• Context Recall
• Hallucination Rate

The resulting metrics provide a quantitative view of answer quality, making it possible to detect regressions that would be difficult to identify through manual inspection alone.

Trade-offs

LLM evaluation is inherently probabilistic.

Using LLMs as judges provides richer semantic evaluation than deterministic rules, but introduces variability between evaluation runs.

Rather than eliminating this uncertainty, the framework embraces it by combining multiple metrics and treating evaluation results as engineering signals rather than absolute truth.

For this reason, evaluation should be interpreted as statistical evidence rather than deterministic truth.

Production Considerations

The framework was designed with production evaluation workflows in mind.

Key design goals include:

• reproducible benchmark execution;
• reusable evaluation datasets;
• framework-independent architecture;
• support for automated regression testing;
• observability through LangSmith traces.

These characteristics make the framework suitable for integration into CI/CD pipelines as AI applications evolve.

The framework was designed to integrate naturally into engineering workflows rather than remaining a standalone experimentation tool.

Results

The framework transforms subjective LLM outputs into measurable quality metrics, enabling engineering teams to compare prompt iterations, retrieval strategies and model versions using reproducible benchmarks instead of manual reviews.

Rather than answering the question:

« Does this response look better? »

the framework enables teams to answer:

« Did the system actually improve? »

Metrics Tracked

• Faithfulness
• Answer Relevancy
• Context Precision
• Context Recall
• Hallucination Rate

What I Learned

Building this framework fundamentally changed the way I think about LLM evaluation.

Traditional software testing assumes deterministic behavior: the same input should always produce the same output. LLM applications challenge that assumption. In practice, the evaluator itself is another language model with its own biases, limitations and uncertainty.

This experience reinforced an important lesson: evaluation scores should not be treated as absolute truth, but as engineering signals that help guide better decisions. Designing reliable AI systems therefore requires not only measuring model quality, but also understanding the limitations of the measurement process itself.

Design Principles

Future Directions

• Human-in-the-loop evaluation workflows.
• Cost-aware benchmark comparison.
• Versioned evaluation datasets.
• Additional evaluation frameworks.
• Historical benchmark dashboards.
• Continuous evaluation integrated into CI/CD.

Real Estate Markting Agent

AI /

Project

Real estate marketing agent

Repository

https://github.com/salletti/real-estate-marketing-agent

Delivered

June 2026

Executive Summary

Real Estate Marketing Agent is a production-grade AI workflow that transforms real estate listings into ready-to-publish social media campaigns.

Rather than relying on a single LLM call, the system orchestrates multiple AI tasks through a durable LangGraph workflow, pauses for human approval, and resumes execution automatically before publishing content through MCP servers.

The project explores how modern AI agents should be engineered when reliability, observability and human oversight become first-class architectural concerns rather than afterthoughts.

Engineering Challenges Solved

• Human-in-the-Loop Workflows
• Long-Running AI Execution
• Durable State Persistence
• AI Workflow Orchestration
• MCP Tool Integration
• Runtime Capability Discovery
• Structured AI Outputs
• Production Observability

Problem

Real estate agencies spend hours creating marketing content for listings and social media. The process is repetitive, difficult to scale and still requires human validation before anything can be published.

While generating text with an LLM is relatively straightforward, production workflows introduce a very different class of engineering problems. AI-generated content must coordinate multiple generation steps, interact with external systems, pause for asynchronous human approval and recover safely after interruptions.

Traditional request-response architectures are not designed for these long-running workflows.

Why This Problem Matters

Most AI demonstrations stop after a successful prompt.

Production AI systems rarely do.

Real-world workflows span multiple services, involve asynchronous human decisions, depend on external APIs and must remain recoverable after failures or process restarts.

The challenge therefore shifts from prompt engineering to workflow orchestration, state management and software architecture.

System Architecture

Technology Stack

Python

FastAPI

LangGraph

Redis

MCP

OpenAI

LangSmith

Docker

Key Engineering Decisions

Human-in-the-Loop Instead of Fully Autonomous Publishing

Publishing automatically would maximize throughput but also increase operational risk.

The workflow deliberately pauses before publication, allowing a human to validate every generated campaign before execution resumes.

This design prioritizes trust and editorial control over complete automation.

Durable Execution Instead of Request-Response Processing

Marketing campaigns cannot assume that approval happens within seconds.

The workflow therefore uses LangGraph’s durable execution model combined with Redis checkpoints, allowing execution to pause indefinitely and resume later from exactly the same state.

This transforms the agent into a resilient long-running workflow rather than a simple API request.

Runtime Capability Discovery Through MCP

Rather than hardcoding external integrations, the backend dynamically discovers the capabilities exposed by connected MCP servers during application startup.

This architecture decouples workflow orchestration from implementation details while making new capabilities extensible without modifying business logic.

Clean Architecture for AI Systems

The project follows Clean Architecture principles throughout the codebase.

Business rules remain isolated from LLM providers, MCP servers and infrastructure concerns, allowing AI capabilities to evolve without impacting the domain model or application layer.

This keeps the system testable, maintainable and adaptable to future models or protocols.

Workflow Orchestration

Instead of treating AI generation as a single prompt, the workflow decomposes the problem into specialized stages responsible for content generation, aggregation, approval and publication.

LangGraph coordinates state transitions while Redis preserves execution context across interruptions.

The result is an AI workflow that behaves more like a distributed application than a traditional chatbot.

Trade-offs

Introducing mandatory human approval inevitably reduces automation throughput.

However, it dramatically improves reliability, prevents unintended publications and keeps human operators accountable for final decisions.

Similarly, durable execution increases implementation complexity but enables workflows that can safely span minutes, hours or even days without losing state.

Production Considerations

The system was designed with production deployment as a primary objective.

Key architectural concerns include:

• durable execution;
• Redis-backed workflow persistence;
• structured outputs between workflow nodes;
• retry mechanisms;
• runtime capability discovery;
• distributed correlation IDs;
• end-to-end observability through LangSmith;
• separation between orchestration and infrastructure.

These decisions ensure that workflow reliability does not depend on a single process remaining alive.

Results

The project demonstrates how AI agents evolve into production systems once orchestration, persistence and external integrations become part of the architecture.

Instead of generating isolated responses, the workflow coordinates content generation, human validation and automated publication while remaining observable, resumable and resilient to interruptions.

Metrics Tracked

• Workflow Execution Time
• Human Approval Latency
• Node Execution Duration
• Publication Success Rate
• Retry Count
• Workflow Recovery Success
• Durable State Persistence
• End-to-End Trace Correlation

What I Learned

Building an AI agent is relatively straightforward.

Building one that can safely pause, survive process restarts, coordinate external tools, wait for asynchronous human decisions and resume execution reliably is fundamentally a distributed systems problem.

This project reinforced the idea that production AI systems are defined less by the intelligence of their models than by the robustness of the software architecture orchestrating them.

Future Directions

• Multi-agent collaboration
• Additional social media platforms
• Automatic campaign evaluation
• Cost-aware workflow optimization
• Scheduling and campaign planning
• Human feedback learning loops
• Advanced operational dashboards

Real Estate semantic search engine

AI /

Project

Semantic search Engine

Repository

github.com/salletti/real-estate-semantic-search

Url

https://semantic-search.stefanoalletti.com/

Executive Summary

Real Estate Semantic Search is a production-grade AI retrieval engine designed to bridge the gap between structured databases and semantic search.

Rather than relying exclusively on vector search, the system combines deterministic NLP, structured filtering, semantic retrieval and hybrid ranking inside a modular query engine capable of selecting the most appropriate retrieval strategy for every user request.

The project explores how modern AI retrieval systems should balance precision, explainability and semantic understanding instead of treating vector search as a universal solution.

Engineering Challenges Solved

• Semantic Retrieval
• Hybrid Search
• Query Planning
• Natural Language Parsing
• Vector Databases
• Retrieval Strategy Selection
• Clean Architecture
• Production Retrieval Pipelines

Problem

Traditional keyword search fails whenever users describe the same concept using different words.

Vector databases solve part of this problem by retrieving semantically similar documents, but they introduce another challenge: semantic similarity alone is insufficient for production search systems.

Real-world queries often combine structured constraints, qualitative descriptions and geographical requirements, requiring multiple retrieval strategies to work together instead of competing.

Why This Problem Matters

Modern AI applications depend on reliable retrieval.

Retrieval-Augmented Generation (RAG), AI agents and enterprise search systems all rely on the ability to retrieve the right information before any language model can generate useful responses.

Choosing the wrong retrieval strategy directly impacts answer quality, latency and user trust.

Building an effective retrieval engine therefore becomes an architectural problem rather than simply selecting a vector database.

System Architecture

Technology Stack

• Python
• FastAPI
• PostgreSQL
• Qdrant
• Sentence Transformers
• Docker
• React

Key Engineering Decisions

Query Planning Before Retrieval

Rather than sending every request directly to a vector database, the system first analyzes user intent and determines which retrieval strategy best matches the query.

This keeps structured searches fast while reserving semantic search for cases where it genuinely improves relevance.

PostgreSQL Remains the Source of Truth

Instead of duplicating the complete business model inside the vector database, PostgreSQL remains responsible for structured data while Qdrant acts purely as a semantic index.

This separation simplifies maintenance and avoids synchronization issues between business data and embeddings.

Hybrid Retrieval Instead of Vector-Only Search

Semantic similarity alone cannot enforce hard business constraints such as price, location or property type.

The retrieval engine therefore combines SQL filtering with semantic ranking, ensuring that retrieved properties satisfy structured requirements before being ordered by semantic relevance.

Clean Architecture Around Retrieval

The retrieval pipeline follows Clean Architecture principles.

Intent parsing, query planning, retrieval and infrastructure remain isolated through well-defined interfaces, allowing individual components to evolve independently.

Retrieval Pipeline

Instead of directly embedding every user query, the system decomposes retrieval into several independent stages.

Natural language is first converted into a structured intent.

The Query Resolver then determines whether SQL, semantic search, nearby search or a hybrid strategy should be executed.

Only after this planning phase does the retrieval engine interact with PostgreSQL and Qdrant.

This architecture keeps retrieval deterministic, explainable and extensible.

Trade-offs

Using vector search for every request simplifies implementation but sacrifices precision for structured filters.

Conversely, relying exclusively on SQL prevents semantic understanding.

The chosen architecture intentionally accepts additional orchestration complexity in exchange for better explainability, lower retrieval costs and higher relevance across different query types.

Production Considerations

The retrieval engine was designed with production systems in mind.

Key architectural concerns include:

• deterministic query planning;
• modular retrieval strategies;
• semantic indexing;
• hybrid ranking;
• explainable routing decisions;
• vector database abstraction;
• clean separation between domain and infrastructure;
• independently testable retrieval components.

Results

The project demonstrates that semantic retrieval is only one component of a modern retrieval engine.

By combining structured filtering, semantic similarity and intelligent query routing, the system returns relevant results even when user queries share little or no lexical overlap with indexed documents while preserving the precision required by business constraints.

Metrics Tracked

• Retrieval Precision@K
• Embedding Latency
• Retrieval Latency
• Strategy Distribution (SQL / Semantic / Hybrid)
• Query Resolution Accuracy

What I Learned

Building a semantic search engine is not primarily about choosing the best embedding model or vector database.

The real challenge lies in deciding when semantic retrieval should be used, when deterministic search is sufficient and how both approaches can cooperate inside the same retrieval architecture.

This project fundamentally changed how I think about RAG systems: retrieval quality depends as much on query planning as on embedding quality.

Future Directions

• Adaptive retrieval strategy selection
• Payload filtering inside Qdrant
• Retrieval reranking models
• Multi-vector search
• Cross-encoder reranking
• Retrieval evaluation benchmarks
• Agent-driven retrieval planning

Je rajouterais un deuxième diagramme

Celui-ci est, à mon avis, le plus intéressant du projet.

Juste après Key Engineering Decisions.

Query Strategy Selection

Days on market — real estate time-to-sell predictor

AI /

Project

Days on market — real estate time-to-sell predictor

Repository

https://github.com/salletti/real-estate-ml-days-on-market

Url

https://days-on-market.stefanoalletti.com

Executive Summary

Days on Market is a production-oriented machine learning system designed to estimate how long a real estate property may remain on the market before being sold.

Rather than presenting a single opaque prediction, the application compares three regression models, exposes confidence ranges and highlights the influence of pricing through a carefully engineered market-position feature.

The project explores how predictive machine learning systems should be designed when interpretability, uncertainty and feature engineering matter more than model complexity.

Engineering Challenges Solved

• Predictive Machine Learning
• Feature Engineering
• Regression Model Comparison
• Uncertainty Estimation
• Reproducible Training Pipelines
• Structured Data Preprocessing
• Model Serving
• Production ML API

Problem

Estimating how long a property will remain on the market is difficult because selling time depends on many interacting factors, including price, location, surface area, energy performance and property condition.

Agents often rely on experience and local intuition, but these estimates can be inconsistent and difficult to justify.

A useful predictive system must therefore do more than output a number. It must identify the variables that truly drive the prediction, communicate uncertainty and remain understandable enough to support human decision-making.

Why This Problem Matters

Predictive models influence pricing, marketing strategy and seller expectations.

An inaccurate estimate can lead to unrealistic promises, inappropriate listing prices or poor commercial decisions.

The engineering challenge is therefore not simply to optimize a regression metric, but to build a reproducible and interpretable decision-support system that communicates both predictions and their limitations.

System Architecture

Technology Stack

• Python
• FastAPI
• scikit-learn
• XGBoost
• Pandas
• Pydantic
• React
• TypeScript
• Docker

Key Engineering Decisions

Feature Engineering Before Model Complexity

The most influential feature in the project is not a raw property attribute, but a derived pricing ratio comparing the listing price with the estimated local market value:

listing_price / (surface × market_price_per_m²)

This feature captures whether a property is positioned above or below its local market.

Once introduced, even linear regression reached performance close to more complex tree-based models.

This demonstrated that representing the problem correctly can matter more than selecting a more sophisticated algorithm.

Compare Multiple Models Instead of Selecting One Too Early

The application trains and exposes Linear Regression, Random Forest and XGBoost using the same dataset and preprocessing assumptions.

Rather than treating the most complex model as the default winner, the system compares their MAE, RMSE and R² values.

This makes model selection evidence-based and reveals whether additional complexity produces a meaningful operational benefit.

Expose Uncertainty Instead of a False Exact Answer

A prediction such as “47 days” may appear precise while hiding substantial uncertainty.

The application therefore returns a lower and upper estimate alongside the central prediction.

This turns the output into a decision-support signal rather than an artificial guarantee and provides users with a more realistic representation of model confidence.

Keep Training and Inference Separate

Model training is executed through a dedicated pipeline that performs preprocessing, fitting, evaluation and artifact persistence.

The production API loads previously trained model artifacts and performs inference only.

This separation avoids retraining during application startup, improves reproducibility and keeps production behavior predictable.

Machine Learning Pipeline

The project separates the machine learning lifecycle into distinct stages:

All models receive a consistent representation of the data, making their performance directly comparable.

The application then serves either one selected model or all three models in parallel, allowing users to compare their predictions and associated metrics.

Trade-offs

The synthetic dataset provides complete control over data generation and makes experimentation reproducible.

However, synthetic relationships are necessarily simpler than real property markets and may not reproduce geographic variation, economic cycles or behavioral effects.

Comparing three models also increases training and maintenance complexity, but provides a clearer understanding of whether model sophistication creates measurable value.

Finally, confidence ranges improve communication, but they should not be interpreted as formally calibrated guarantees without stronger statistical validation.

Production Considerations

The system was designed with a clear separation between experimentation and serving.

Key architectural concerns include:

• reproducible preprocessing;
• persisted model artifacts;
• shared feature definitions between training and inference;
• typed API contracts;
• application-level model comparison;
• health checks exposing model availability;
• automated linting and type checking;
• containerized deployment;
• isolated training commands;
• prevention of preprocessing drift.

These decisions reduce the risk of producing different feature representations during training and production inference.

Results

The three models achieved similar performance on the synthetic dataset, with an MAE of approximately eight days and an R² close to 0.89.

The most important result was not that XGBoost outperformed the alternatives, but that Linear Regression became similarly effective after introducing the pricing-ratio feature.

This showed that the structure and quality of the input representation had a greater impact than model complexity in this problem.

Metrics Tracked

• Mean Absolute Error
• Root Mean Squared Error
• R² Score
• Prediction Interval Width
• Training Duration
• Inference Latency
• Model Agreement
• Error Distribution
• Feature Importance
• API Response Time

What I Learned

The choice of model is often less important than the way the problem is represented.

Before introducing the derived pricing-ratio feature, the models had to infer the relationship between price, surface and local market conditions independently. Once that relationship was explicitly encoded, even a simple linear model performed competitively with XGBoost.

This project reinforced the idea that feature engineering, data quality and evaluation design frequently create more value than increasing model complexity.

It also highlighted the importance of communicating uncertainty: a useful machine learning system should support human judgment rather than present probabilistic estimates as certain outcomes.

Future Directions

• Training with real DVF and listing data
• Temporal validation across market periods
• Geographic cross-validation
• Hyperparameter optimization
• Explainability with SHAP
• Calibrated prediction intervals
• Drift detection
• Automated retraining
• Feature store integration
• Market-segment-specific models

Real estate photo quality detector

AI /

Project

Real estate photo quality detector

Repository

https://github.com/salletti/real-estate-photo-quality

URL

https://photo-quality.stefanoalletti.com/

Delivered

April 2026

Executive Summary

Real Estate Photo Quality Assessment is a production-oriented computer vision system designed to automatically evaluate the visual quality of real estate photographs before publication.

Rather than relying solely on image classification, the application combines multi-label defect detection, deterministic business scoring and LLM-generated recommendations to transform raw predictions into actionable quality reports for real estate professionals.

The project explores how computer vision models can be integrated into production systems where explainability, maintainability and business rules are as important as model accuracy.

Engineering Challenges Solved

• Computer Vision Pipeline
• Multi-Label Classification
• Dataset Engineering
• Synthetic Data Generation
• Transfer Learning
• Business Rule Scoring
• Explainable AI Outputs
• Production Inference API

Problem

The quality of property photos has a direct impact on buyer engagement and listing performance. However, reviewing thousands of images manually is subjective, inconsistent and difficult to scale.

While detecting visual defects with a neural network is relatively straightforward, production systems require much more than image classification. Predictions must be translated into meaningful business decisions, remain explainable to users and generate actionable feedback instead of raw probabilities.

Building such a system requires combining computer vision, deterministic business logic and natural language generation into a single production pipeline.

Why This Problem Matters

Computer vision models rarely operate in isolation.

Real-world applications require reliable data pipelines, reproducible training processes, explainable predictions and business rules that evolve independently from machine learning models.

The challenge therefore shifts from training a classifier to engineering an end-to-end system capable of producing trustworthy and actionable results.

System Architecture

Technology Stack

• Python
• FastAPI
• PyTorch
• TorchVision
• Pillow
• Groq (Llama 3.3)
• Docker
• React

Key Engineering Decisions

Separate Detection from Business Decisions

The computer vision model is responsible only for detecting visual defects.

Quality scoring is intentionally implemented as a deterministic business layer, allowing scoring policies to evolve independently from model training.

This separation improves explainability while keeping business rules transparent, testable and easy to evolve.

Engineer the Dataset Instead of Waiting for Data

Building supervised vision systems requires annotated datasets that are often unavailable.

To accelerate experimentation, the project includes a synthetic dataset generation pipeline capable of automatically applying realistic visual defects such as blur, poor lighting and framing issues to clean property images.

This approach enables reproducible training while significantly reducing manual annotation effort.

Favor Simplicity Over Model Complexity

Given the relatively small dataset, the objective was not to maximize model size but to maximize generalization.

A lightweight transfer-learning approach based on ResNet18 provides an effective balance between inference speed, training efficiency and overfitting risk compared with significantly larger architectures.

Combine Computer Vision with Natural Language Feedback

Raw predictions are difficult for end users to interpret.

Instead of exposing probabilities, detected issues are converted into structured quality scores before being passed to an LLM that generates concise improvement recommendations.

This architecture transforms technical model outputs into practical guidance without coupling business logic to the language model.

Computer Vision Pipeline

Rather than treating image quality assessment as a single prediction task, the application decomposes the workflow into specialized stages responsible for image preprocessing, defect detection, deterministic scoring and recommendation generation.

Machine learning remains focused on perception, while business rules and LLMs handle interpretation and communication.

The result is a modular pipeline where each component can evolve independently without impacting the others.

Trade-offs

Synthetic dataset generation accelerates experimentation and enables reproducible annotations, but it cannot fully reproduce the variability of real-world photography.

Similarly, deterministic business scoring sacrifices some flexibility compared with end-to-end learned scoring, yet provides complete explainability, easier maintenance and greater control over quality policies.

Production Considerations

The system was designed with production deployment as a primary objective.

Key architectural concerns include:

• transfer learning for efficient training;
• deterministic business scoring;
• synthetic dataset generation;
• reproducible preprocessing pipeline;
• model inference through FastAPI;
• LLM-powered recommendation generation;
• separation between machine learning and business logic;
• containerized deployment with Docker.

These decisions ensure that model evolution remains independent from application behavior while keeping predictions transparent and maintainable.

Results

The project demonstrates how computer vision models become production systems once dataset engineering, inference pipelines, business rules and user-facing recommendations are integrated into the architecture.

Rather than producing isolated predictions, the application delivers complete quality assessments that combine visual defect detection, objective scoring and actionable recommendations within a single workflow.

Metrics Tracked

• Multi-Label Classification Accuracy
• Training Loss
• Inference Latency
• Quality Score Distribution
• Defect Detection Frequency
• API Response Time
• LLM Generation Latency
• End-to-End Prediction Time

What I Learned

Training a computer vision model is only one part of building an AI application.

The real engineering challenge lies in designing the surrounding system: creating reliable datasets, separating perception from business logic, ensuring explainability and transforming model predictions into information that users can confidently act upon.

This project reinforced the idea that production machine learning systems are defined as much by their software architecture as by the models they deploy.

Future Directions

• Larger real-world annotated dataset
• Advanced data augmentation
• Validation and early stopping
• Context-aware room type modeling
• Automatic room type detection
• Model explainability with Grad-CAM
• ONNX model optimization
• Batch inference pipeline