📝 **Question :** **Écrivez la fonction** \`recommend_vector_db(stack, vector_count, ops_burden_ok)\` qui renvoie \`(db_name, Reason)\`. Utilisez cet arbre de décision (dans l'ordre) : 1. Si \`vector_count >= 10_000_000\` → \`("Qdrant ou Pinecone", "10M+ vecteurs dépassent la plage confortable de pgvector")\` 2. Sinon, si \`stack == "postgres"\` → \`("pgvector", f"Déjà sur Postgres + {vector_count :,} vecteurs — une base de données, moins d'opérations")\` 3. Sinon, si \`ops_burden_ok\` → \`("Qdrant", "Auto-hébergé, Rust, excellent filtrage des métadonnées")\` 4. Sinon → \`("Pinecone", "Géré, plus simple à utiliser ; payez pour la commodité")\` Ensuite, exécutez-le sur quatre formes de démarrage réelles : \`\`\` stack=postgres n= 500 000 ops_ok=True -> pgvector (Déjà sur Postgres + 500 000 vecteurs — une base de données, moins d'opérations) stack=postgres n=50 000 000 ops_ok=True -> Qdrant ou Pinecone (plus de 10 millions de vecteurs dépassent la plage confortable de pgvector) stack=aucun n= 100 000 ops_ok=False -> Pinecone (Géré, plus simple à utiliser ; payez pour la commodité) stack=aucun n= 100 000 ops_ok=True -> Qdrant (auto-hébergé, Rust, excellent filtrage des métadonnées) \`\`\` Le cas 500K-on-Postgres est la **réponse de production la plus courante** et celle que les juniors se trompent en optant pour Pinecone : la simplicité opérationnelle (une base de données, une sauvegarde, un pool de connexions) bat l'avantage marginal en termes de performances de Pinecone à cette échelle. Migrez UNIQUEMENT lorsque vous avez mesuré les limites de pgvector. 📋 Choisissez la bonne réponse. 💡 **Indice :** Relisez la théorie ci-dessus en cas de doute.