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.

Real Estate semantic search engine