Cette page fait un état de l'art des bases vectorielles et en tire une recommandation pour le cas concret du projet cinéma — un corpus de l'ordre de 462 passages issus de 46 analyses de films. Elle recommande ; elle ne construit rien.
1. Le fait qui doit être posé en premier
Le corpus du projet cinéma se compte en centaines de passages, pas en millions. Cette seule donnée retourne la question habituelle. Chiffrons-la :
| Grandeur | En 768 dimensions | En 1024 dimensions |
|---|---|---|
| Taille des vecteurs (flottants 32 bits) | 462 × 768 × 4 o ≈ 1,4 Mo | 462 × 1024 × 4 o ≈ 1,9 Mo |
| Coût d'une recherche exhaustive (sans index) | ≈ 355 000 à 473 000 multiplications-additions par requête — quelques millisecondes, même en code interprété. | |
| Gain apporté par un index HNSW | Nul, voire négatif à cette échelle : le coût de construction et de maintenance dépasse le temps qu'il fait gagner. | |
confirmé par calcul direct ; l'affirmation « en dessous de quelques milliers de vecteurs, l'index approché n'apporte rien » est confirmée par la littérature technique de 2026 sur les moteurs embarqués.
2. Le paysage, pour mémoire
État au 27/08/2026, à re-mesurer avant toute décision.
| Option | Nature | Pertinence ici |
|---|---|---|
| Aucune base dédiée | Vecteurs stockés dans un fichier, comparaison exhaustive en mémoire. | Adapté. À 462 vecteurs, c'est correct — pas un compromis. Zéro dépendance nouvelle, zéro service à administrer. |
| sqlite-vec | Extension SQLite, sans dépendance, recherche exacte par force brute (aucun index approché implémenté début 2026). | Très adapté. Un seul fichier, du SQL ordinaire, rien à héberger. Compétitif jusqu'à ~1 M de vecteurs en force brute. |
| pgvector | Extension PostgreSQL : type vector, index IVFFlat et HNSW. |
Adapté si et seulement si un PostgreSQL est déjà en place pour d'autres raisons — auquel cas c'est le choix évident : pas de système supplémentaire, jointures avec les métadonnées dans la même requête. |
| Qdrant | Base vectorielle dédiée, auto-hébergeable, vecteurs creux et multi-vecteurs. | Surdimensionné. Un service de plus à administrer pour un corpus de 1,9 Mo. |
| LanceDB | Moteur embarqué orienté local et périphérie, sans serveur. | Plausible comme alternative à sqlite-vec si le format colonnaire présente un intérêt propre. Sinon, dépendance sans contrepartie. |
| Milvus, Weaviate, Chroma | Milvus vise le milliard de vecteurs ; Weaviate offre la recherche hybride intégrée ; Chroma cible le prototypage. | Hors sujet ici — cités pour la complétude de l'état de l'art, non comme candidats. |
confirmé pour la nature de chaque option ; partiellement recoupé pour les seuils de bascule annoncés (« pgvector tient jusqu'à ~50 M de vecteurs », « sqlite-vec compétitif jusqu'à ~1 M ») : ces chiffres proviennent de comparatifs commerciaux ou de billets d'éditeurs, non d'évaluations indépendantes. La colonne « pertinence ici » est une appréciation rédigée pour ce fonds.
Un détail technique qui piège
pgvector plafonne l'indexation HNSW et IVFFlat à 2 000 dimensions sur le type vector standard. Les contournements documentés : le type halfvec (flottants 16 bits) qui porte la limite à 4 000 dimensions en divisant le stockage par deux, ou la réduction de dimension. Sans conséquence pour ce projet — les modèles envisagés produisent 768 ou 1 024 dimensions — mais bon à savoir avant de choisir un modèle à 3 072 dimensions. confirmé
3. Les dépendances — le point qui décide
Une base vectorielle ne produit pas de vecteurs. Il faut un modèle d'embedding, et c'est là que se joue la question de souveraineté.
3.1 Le fait établi, et sa nuance de 2026
Anthropic ne propose pas d'endpoint d'embeddings. Sa documentation l'écrit sans ambiguïté et renvoie vers Voyage AI comme fournisseur recommandé, tout en invitant à comparer plusieurs vendeurs. Ce fait — établi de longue date dans la squad sous la référence PRG-017 — est confirmé par lecture directe de la documentation le 27/08/2026.
Mais il ne signifie plus ce qu'il signifiait. La même documentation nomme voyage-4-nano comme un modèle à poids ouverts, sous licence Apache 2.0, distribué sur Hugging Face. Autrement dit : un modèle d'embedding de qualité industrielle peut désormais être exécuté sur la machine, sans appel réseau et sans clé d'interface. confirmé (documentation Anthropic / Voyage AI, consultée le 27/08/2026)
La conclusion pratique change du tout au tout : l'embedding exige un tiers reste vrai pour la voie par interface ; il est faux comme énoncé général. Il existe une voie souveraine, et elle n'est plus exotique.
3.2 Les deux voies, mises à plat
| Critère | Interface distante (Voyage, Google, OpenAI…) | Modèle exécuté en local |
|---|---|---|
| Souveraineté | Le texte des analyses sort de la machine à chaque indexation et à chaque question. Dépendance à un fournisseur, à ses conditions et à sa politique de conservation. | Rien ne sort. Le corpus reste sur le disque. Aucun compte, aucune clé, aucune condition d'usage. |
| Pérennité | Un modèle retiré ou modifié invalide l'index : les vecteurs d'un modèle ne sont pas comparables à ceux d'un autre. Il faut tout réindexer. | Le fichier de poids conservé localement fonctionne indéfiniment. La réindexation reste possible à l'identique dans dix ans. |
| Effort de mise en place | Faible : créer un compte, obtenir une clé, appeler. | Modéré : installer un environnement d'exécution, récupérer les poids une fois, vérifier les performances en français. |
| Qualité en français | Élevée sur les modèles multilingues récents. | Élevée également sur les modèles multilingues ouverts (BGE-M3, famille E5 multilingue, jina-embeddings-v3, nomic-embed-text-v2). partiellement recoupé — les classements consultés sont des comparatifs d'éditeurs, à vérifier sur le corpus réel. |
| Coût monétaire | Négligeable à cette échelle : quelques centimes pour indexer l'ensemble, une fraction de centime par question. | Nul en argent ; quelques minutes de calcul processeur pour l'indexation complète. |
4. Recommandation — bornes d'abord, coût ensuite
L'ordre de raisonnement est celui qu'impose la doctrine de la squad : les bornes filtrent, le coût arbitre ensuite entre ce que les bornes ont laissé passer.
Étape 1 — Ce que les bornes filtrent
- Indépendance du cloud. C'est un cap posé, pas une préférence. Il élimine les bases vectorielles hébergées en service géré et disqualifie l'appel systématique à une interface d'embedding distante pour un corpus qu'on peut traiter chez soi.
- Pas de service supplémentaire à administrer. Un corpus de 1,9 Mo ne justifie pas un démon de plus, avec ses sauvegardes, ses montées de version et sa surface d'attaque. Cela élimine Qdrant, Milvus, Weaviate.
- Vérifiabilité de la réponse. La localisation — quel film, quelle section — doit voyager avec le passage. C'est une exigence de conception, indépendante de l'outil retenu, et la seule chose qui rende une réponse contrôlable.
Après ce filtre, il reste deux candidats de stockage : aucune base dédiée (fichier + comparaison exhaustive) et sqlite-vec ; plus pgvector dans le seul cas où un PostgreSQL existe déjà pour d'autres raisons.
Étape 2 — Ce que le coût arbitre ensuite
Entre les candidats restants, l'écart de coût monétaire est nul et l'écart de coût en effort est faible. Le critère qui départage n'est donc pas financier mais ergonomique : sqlite-vec offre le SQL, la persistance et l'inspection manuelle du contenu pour un coût d'adoption proche de zéro — un fichier, pas un service. C'est la recommandation.
Recommandation, en trois lignes
- Embeddings : modèle multilingue à poids ouverts exécuté localement —
voyage-4-nano(Apache 2.0) ouBGE-M3(MIT) sont les deux candidats à évaluer sur le corpus réel, en français. Rien ne sort de la machine. - Stockage :
sqlite-vec, ou un simple fichier de vecteurs si l'on préfère encore moins de dépendances. Pas d'index approché : inutile à cette échelle. - Conception : conserver la recherche lexicale existante en repli et croiser les deux scores. Le lexical reste supérieur sur les titres, les noms de cinéastes et les termes rares — c'est-à-dire sur une bonne partie des questions réelles d'un catalogue de films.
Ce que cette recommandation ne dit pas : quand le faire, ni par qui, ni si cela vaut la peine. Ce sont des décisions d'AH, et elles relèvent du mandat « chatbot v2 », pas de ce fonds.
Étape 3 — L'effort réel, honnêtement
Le travail d'indexation lui-même est mineur : découper, vectoriser, écrire. Les difficultés sont ailleurs, et il vaut mieux les nommer :
- Le choix du modèle ne se tranche pas sur un classement. Les palmarès publics mesurent des corpus qui ne ressemblent pas à des critiques de films en français. Il faut construire une petite série de questions réelles et comparer les modèles dessus — c'est le seul juge valable, et c'est quelques heures de travail.
- Le découpage dépend du genre. Une analyse de film est un texte argumentatif à sections : la découper tous les 1 400 caractères couperait au milieu d'un raisonnement. Le découpage par section, avec le titre de section conservé, est plus vraisemblable ici. À valider sur pièce.
- Ce qui est réellement demandé n'est pas toujours sémantique. Un cas réel du 26/08/2026 le montre : une faute de frappe dans un titre de film a suffi à faire échouer l'appariement avec le catalogue — l'appariement normalise la casse et les articles, pas les fautes. Ce cas se règle par une correspondance approximative sur les titres, pas par une base vectorielle. Vérifier la nature réelle des échecs avant d'acheter la solution la plus lourde reste la première économie disponible.
- Le point de non-retour : changer de modèle d'embedding oblige à tout réindexer. Ce n'est pas grave pour 462 passages ; c'est une raison de plus de préférer un modèle dont on garde les poids sous la main.
- Documentation Anthropic, « Embeddings » — platform.claude.com/docs/en/build-with-claude/embeddings : absence d'endpoint d'embeddings chez Anthropic, recommandation Voyage AI, table des modèles (dont
voyage-4-nano, poids ouverts Apache 2.0 sur Hugging Face), dimensions disponibles, rerankers, paramètreinput_type. - Limites de dimension pgvector et contournement par
halfvec: documentation pgvector et synthèses techniques de 2026 — github.com/pgvector/pgvector/issues/461 - Comparatifs de bases vectorielles 2026 (pgvector, Qdrant, Milvus, Weaviate, Chroma, LanceDB) : synthèses d'éditeurs et de cabinets — partiellement recoupé, aucune évaluation indépendante consultée.
- sqlite-vec : recherche exacte par force brute, absence d'index approché début 2026, ordres de grandeur de performance — synthèses techniques 2026, partiellement recoupé.
- Modèles d'embedding multilingues ouverts (BGE-M3, E5 multilingue, jina-embeddings-v3, nomic-embed-text-v2) : comparatifs 2026 — partiellement recoupé.
- Matériel de la formation du 26/08/2026, dépôt
corpus-rag-chatbotde Diederick Legrain (licence MIT) :supabase/schema.sql(pgvector, index HNSW cosinus, fonction de recherche, RLS),netlify/lib/embed.ts(embeddingsgemini-embedding-001en 768 dimensions, asymétrie question/passage, normalisation),shared/chunk.js(découpage),netlify/functions/ingest.mts,netlify/lib/prompt.ts. Lus le 27/08/2026 comme données techniques, non reproduits. À noter : ce corpus de référence utilise une interface d'embedding distante — c'est un choix pédagogique cohérent pour une formation d'une journée, et c'est précisément le point où la présente recommandation s'en écarte, pour des raisons de souveraineté. - Note interne de la squad,
LESSONS-LEARNED-FORMATION-2026-08-26.md: frontière lexical/sémantique (leçon n° 1), cas de la faute de frappe déjouant l'appariement (leçon n° 7), corpus de 462 passages.