Similarité entre films et recherche vectorielle

Fil conducteur « films similaires » : embeddings dans PostgreSQL, même idée dans Qdrant avec deux sens du vecteur, puis récupération + LLM local sur les mêmes lignes. Récit ici ; notebooks dans AlgoETS/SimilityVectorEmbedding. English version.

Trois questions différentes

1. Langage des synopsis — « films dans cet esprit ».
2. Chevauchement de notes — « utilisateurs au profil proche ».
3. Explication — « pourquoi ces titres ? » à partir d’une question.

Les parties 1–3 y répondent. Mélanger sans nommer le type de vecteur = démos trompeuses.

Partie 1 — PostgreSQL et pgvector

Catalogue depuis movies.json : concaténer champs texte, encoder (MiniLM, GTE…), colonnes vector à côté du relationnel.

Opérateurs <=> (cosinus), <-> (L2) → kNN en ORDER BY … LIMIT.

SELECT title,
       1 - (embedding_minilm <=> (
         SELECT embedding_minilm FROM movies WHERE title = $1
       )) AS similarity
FROM movies
WHERE title IS DISTINCT FROM $1
ORDER BY similarity DESC
LIMIT 10;

Plusieurs colonnes embedding_* pour comparer les encodeurs. Graphiques : Medium partie 1, notebooks postgres/.

Partie 2 — Qdrant et MovieLens

Dense : texte → MiniLM → recherche films. Creux : vecteur de notes → voisins → agrégation — filtrage collaboratif sans réseau de neurones dans le notebook.

Projet FastAPI movie_recommendation dans le dépôt cours. Entrée : qdrant/0.simple.ipynb.

Partie 3 — RAG LangChain + Ollama

flowchart LR
  Q[Question] --> E[Embedding]
  E --> SQL[kNN SQL]
  SQL --> Rows[Films]
  Rows --> LLM[Ollama]
  LLM --> A[Réponse ancrée]

Notebook postgres/3.LLMS.ipynb — échecs utiles : type vector inconnu pour LangChain, SQL invalide généré, timeouts Ollama.

Quand éviter cette pile

Bilan

Embed → stocker → voisins trois fois, trois sens. Partie 3 = humilité sur la génération SQL.

Articles liés

• Snowflake Data-for-Breakfast
• Expérimentation indicateurs

Références

• AlgoETS/SimilityVectorEmbedding
• pgvector · Qdrant

Publié d’abord sur Medium ; page fusionnée parties 1–3.