1. Présentation
Dans le monde complexe des secteurs réglementés et stratégiques, les organisations sont confrontées à un paradoxe de taille : comment adopter une IA de pointe pour optimiser la production lorsque vos règles de cybersécurité exigent que vos données ne soient jamais exposées à l'Internet public ? Les intranets et l'Internet public sont strictement séparés et ne se croisent jamais. Alors que le secteur de la fabrication moderne a désespérément besoin de l'IA prédictive pour éviter les pannes d'équipement catastrophiques et optimiser le rendement, l'envoi de journaux de télémétrie sensibles, de recettes d'alliages brevetées ou de données ERP à une API cloud publique est, en pratique, impossible. Si les données ne peuvent pas aller dans le cloud, le cloud doit venir aux données.
Dans cet atelier de programmation, nous allons intégrer les outils de données et d'IA les plus avancés de Google Cloud directement dans des environnements déconnectés et hautement sécurisés avec Gemma 4 et AlloyDB Omni.
AlloyDB Omni : le coffre-fort de données ultime
Imaginez AlloyDB Omni comme un coffre-fort hautes performances. Il s'agit d'une base de données conteneurisée de niveau entreprise que vous téléchargez et exécutez entièrement sur votre propre intranet sécurisé.
- Intégration parfaite : il se connecte directement aux capteurs de fabrication (comme un VIM ou une presse lourde) et aux ERP locaux (comme Oracle R12).
- Stockage prêt pour l'IA : il stocke de manière sécurisée les fiches de processus top secrètes à l'aide d'embeddings vectoriels pour la recherche optimisée par l'IA (pgvector).
- Performances : il surpasse largement PostgreSQL standard pour les charges de travail transactionnelles lourdes et le traitement par IA analytique.
Experts IA locaux : Gemma, TimesFM, TabFM
Au lieu d'utiliser des API distantes, vous pouvez télécharger des modèles à pondération ouverte et les exécuter de manière native sur votre matériel local, sans aucune fuite d'API.
- Gemma : le LLM à pondération ouverte de Google agit comme votre expert en R&D. Il peut lire de manière sécurisée les journaux historiques ou analyser des recettes d'alliages complexes et brevetées pour prédire les propriétés mécaniques.
- TimesFM (le prévisionniste numérique) : comme les LLM peuvent parfois halluciner des chiffres, les machines lourdes nécessitent un modèle de fondation de séries temporelles dédié. TimesFM prédit avec précision les horizons numériques à long terme (jusqu'à 16 000 points de données), en lisant les journaux de vibrations et de température pour prévoir les courbes exactes de défaillance des équipements, entièrement hors connexion.
- TabFM (The Tabular Reasoner) : alors que les LLM gèrent le texte et que TimesFM gère les tendances numériques, TabFM est spécialisé dans le raisonnement sur les données de table structurées. Vous pouvez l'exécuter de manière sécurisée sur site pour effectuer des analyses complexes et répondre à des questions directement à partir de données ERP ou CRM denses et multicolonnes, sans avoir à écrire de jointures SQL complexes.
Cas d'utilisation
Maintenance prévisionnelle sur une presse à forger de 1 500 tonnes :
Les temps d'arrêt non planifiés de ces machines massives interrompent la production, ce qui entraîne une perte de temps considérable et un gaspillage de matériaux essentiels. À l'inverse, la maintenance planifiée remplace souvent des pièces coûteuses trop tôt, ce qui gaspille le budget. Nous devons passer d'une maintenance réactive à une maintenance prévisionnelle sans rompre l'air gap.
Points abordés
Dans cet atelier de programmation :
- Vous allez utiliser AlloyDB Omni pour capturer de manière sécurisée les données des capteurs de vibration et de température localement. Vous pouvez ajouter d'autres paramètres pour rendre l'exercice plus réaliste et utile.
- Vous apprendrez à utiliser Gemma pour analyser les tendances par rapport aux journaux d'échecs historiques.
- Vous allez créer un système qui prédit les défaillances et déclenche automatiquement des ordres de travail fictifs de gestion des actifs dans votre ERP.
Nous utilisons Docker pour provisionner le LLM local et AlloyDB Omni. L'avantage de cette approche est sa simplicité : AlloyDB Omni peut gérer automatiquement son propre processus ML-Agent interne.
Conditions requises
- Connaître les principes de base de SQL
- Une VM Linux standard (par exemple, Ubuntu 22.04) ou une machine locale (macOS/Windows) sur laquelle Docker est installé.
2. Démarrer le LLM local (Gemma 4)
Nous utiliserons Ollama pour héberger Gemma localement. Créez un Dockerfile pour configurer l'instance Ollama :
- Sur votre ordinateur local, exécutez les commandes suivantes une par une dans un terminal :
mkdir -p gemma4-ollama && cd gemma4-ollama
cat << 'EOF' > Dockerfile
FROM ollama/ollama:latest
ENV OLLAMA_HOST=0.0.0.0:8080
ENV OLLAMA_MODELS=/root/.ollama
ENV MODEL=gemma4:e2b
RUN ollama serve & sleep 5 && ollama pull $MODEL
ENTRYPOINT ["ollama", "serve"]
EOF
- Créez et exécutez le conteneur sur le réseau hôte :
docker build -t gemma4-local .
docker run --network host -d -p 8080:8080 --name gemma4-ollama-instance gemma4-local
- Vous pouvez le tester à l'aide de la commande suivante :
curl -X POST http://localhost:8080/api/generate -d '{
"model": "gemma4:e2b",
"prompt": "Hello! Explain Gemma 4 in a few sentences."
}'
3. Installer et démarrer AlloyDB Omni
Ensuite, lancez le conteneur de base de données AlloyDB Omni, également sur le réseau hôte :
docker run -d \
--name my-omni \
--network host \
-e POSTGRES_PASSWORD=omni \
gcr.io/alloydb-omni/alloydbomni:18
Si l'image AlloyDB Omni n'est pas trouvée dans votre projet Google Cloud, essayez de vous authentifier en exécutant la commande suivante avant d'exécuter la commande docker run ci-dessus :
gcloud auth login
Une fois l'authentification terminée, essayez d'exécuter à nouveau la commande docker run.
4. Activer l'agent ML interne
Par défaut, les fonctionnalités d'intégration du ML d'AlloyDB Omni sont désactivées. Nous devons modifier le fichier postgresql.conf dans le conteneur pour activer le processus ML-Agent interne et le moteur de requêtes d'IA.
Exécutez cette commande unique pour ajouter les options nécessaires :
docker exec -it my-omni sh -c "cat << EOF >> /var/lib/postgresql/data/postgresql.conf
omni_enable_ml_agent_process = 'on'
google_ml_integration.enable_model_support = 'on'
google_ml_integration.enable_ai_query_engine = 'on'
EOF"
Redémarrez le conteneur pour appliquer les modifications :
docker restart my-omni
Vous pouvez commencer à tester des requêtes en démarrant psql à l'aide de la commande suivante :
docker exec -it my-omni psql -U postgres
5. Acheminer l'IA vers le LLM local
Une fois connecté à la base de données via psql (docker exec -it my-omni psql -U postgres), vous pouvez enregistrer votre modèle local hors réseau. Au lieu d'appeler Internet, routez l'model_request_url vers votre serveur Ollama local exécuté sur le port 8080.
Exécutez les instructions SQL suivantes à partir de l'invite psql dans le terminal :
CREATE EXTENSION IF NOT EXISTS google_ml_integration CASCADE;
CALL google_ml.create_model(
model_id => 'gemma4:e2b',
model_request_url => 'http://localhost:8080/api/generate',
model_provider => 'custom',
model_type => 'generic'
);
Vous pouvez désormais appeler des prédictions de manière sécurisée depuis SQL :
SELECT google_ml.predict_row(
'gemma4:e2b',
'{"model": "gemma4:e2b", "prompt": "Why is the sky blue?", "stream": false}'
)->'response';
Résultat :
Maintenant que nous l'avons testé sur un scénario de test générique, intégrons les données de notre cas d'utilisation.
6. Créer un schéma et ingérer des données
Développons maintenant notre cas d'utilisation en créant le schéma et les données nécessaires à la démonstration.
Exécutez les instructions SQL suivantes à partir de l'invite psql dans le terminal :
-- ==============================================================================
-- 1. Setup the Schema for the 1500T Forging Press
-- ==============================================================================
CREATE TABLE IF NOT EXISTS forging_press_logs (
log_id SERIAL PRIMARY KEY,
timestamp TIMESTAMP NOT NULL DEFAULT NOW(),
cycle_id VARCHAR(50) NOT NULL,
hyd_pressure_bar NUMERIC(5,2),
oil_temp_c NUMERIC(5,2),
vib_z_rms NUMERIC(5,2)
);
-- Clean up any existing data if running multiple times
TRUNCATE TABLE forging_press_logs;
-- ==============================================================================
-- 2. Generate 1,000 Records of Simulated Data
-- ==============================================================================
-- 99% of data is 'Normal'
INSERT INTO forging_press_logs (cycle_id, hyd_pressure_bar, oil_temp_c, vib_z_rms)
SELECT
'C-' || LPAD(i::text, 5, '0'),
280.0 + (random() * 10 - 5), -- Pressure around 280
42.0 + (random() * 5), -- Temp around 42-47
1.8 + (random() * 0.5) -- Vib Z around 1.8-2.3
FROM generate_series(1, 990) AS i;
-- 1% of data is 'Anomalous' (Hydraulic pressure drop & vibration spike)
INSERT INTO forging_press_logs (cycle_id, hyd_pressure_bar, oil_temp_c, vib_z_rms)
SELECT
'C-' || LPAD((990 + i)::text, 5, '0'),
250.0 + (random() * 5), -- Pressure dropping
55.0 + (random() * 5), -- Temp rising
5.0 + (random() * 1.5) -- High vibration
FROM generate_series(1, 10) AS i;
-- ==============================================================================
-- 3. Run the AI Prediction via AlloyDB Omni
-- ==============================================================================
-- Ensure the model is registered (assuming 'gemma4:e2b' is running locally on port 8080)
CREATE EXTENSION IF NOT EXISTS google_ml_integration CASCADE;
DO $$
BEGIN
CALL google_ml.create_model(
model_id => 'gemma4:e2b',
model_request_url => 'http://localhost:8080/api/generate',
model_provider => 'custom',
model_type => 'generic'
);
EXCEPTION WHEN OTHERS THEN
-- Ignore error if model already exists
END $$;
-- Query the most recent 5 potentially anomalous records and ask Gemma for an analysis
SELECT
cycle_id,
hyd_pressure_bar,
vib_z_rms,
google_ml.predict_row(
model_id => 'gemma4:e2b',
request_body => json_build_object(
'model', 'gemma4:e2b',
'stream', false,
'prompt', 'You are an industrial engineer. Analyze this sensor data from a 1500T forging press: Pressure=' || hyd_pressure_bar || ' bar, Vibration=' || vib_z_rms || ' mm/s. Normal pressure is ~280 bar and normal vibration is ~2.0 mm/s. Does this indicate a hydraulic failure? Answer in one short sentence.'
)
)->>'response' AS ai_analysis
FROM
forging_press_logs
WHERE
hyd_pressure_bar < 260 OR vib_z_rms > 4.5
ORDER BY
timestamp DESC
LIMIT 5;
L'exécution des instructions ci-dessus une par une devrait donner le résultat suivant :
Maintenant que nos données sont prêtes, passons à la création du tableau de bord de maintenance prédictive.
7. Créer un tableau de bord de streaming en direct
Pour visualiser cette architecture, vous pouvez facilement la connecter à un tableau de bord Python Flask, qui est une application Web.
Au lieu d'exécuter manuellement des requêtes SQL, un backend Flask léger diffuse la télémétrie des capteurs en direct vers un tableau de bord HTML. En situation normale, le tableau de bord se contente de tracer les graphiques.
Mais lorsque le backend détecte une anomalie (par exemple, une baisse de pression), le code Python déclenche instantanément la fonction google_ml.predict_row() dans AlloyDB. AlloyDB transmet de manière fluide le contexte à votre modèle Gemma local, et l'insight de diagnostic de l'IA s'affiche en temps réel sur le tableau de bord.
💡 Astuce pour l'atelier de programmation : Pour quitter le conteneur de base de données et revenir à la ligne de commande de votre hôte, saisissez \q et appuyez sur Entrée (ou ouvrez un nouvel onglet de terminal). Ensuite, exécutez les commandes de l'application Flask ci-dessous.
Pour ce faire, procédez comme suit :
- Accédez à votre environnement de développement / éditeur de code et ouvrez le terminal.
- Exécutez la commande suivante :
pip install flask psycopg2-binary
- Clonez le dépôt de code dans le répertoire de votre projet en exécutant la commande suivante dans votre terminal Cloud Shell :
git clone https://github.com/AbiramiSukumaran/gemma4-alloydb-omni-demo
- Accédez au dossier du projet :
cd gemma4-alloydb-omni-demo
- Exécutez l'application :
python3 app.py
Ouvrez le navigateur Web ou cliquez sur le lien vers l'application exécutée sur votre localhost.
À quoi sert le tableau de bord En direct ?
L'application Flask sert de tableau de bord de surveillance en temps réel pour la presse à forger de 1 500 tonnes. Elle permet de visualiser comment un système complètement hors connexion et sous air gap gère la maintenance prévisionnelle :
- Flux de télémétrie continu : le tableau de bord affiche les journaux de vibrations (mm/s) et de pression hydraulique (bar) en temps réel, et s'actualise de manière dynamique pour simuler les opérations actives en usine.
- Anomalies de base de données à la volée : lorsqu'un capteur passe sous le seuil (par exemple, la pression descend en dessous de 260 bars), le backend Python signale l'événement et appelle immédiatement la fonction
google_ml.predict_row()dans AlloyDB Omni. - Diagnostic IA localisé : AlloyDB Omni transmet le contexte en temps réel à votre modèle Gemma 4 local. Gemma agit comme un expert industriel sur site, en analysant la télémétrie et en affichant une alerte de diagnostic (par exemple, "Avertissement : une chute de pression et des vibrations élevées indiquent une défaillance potentielle du joint hydraulique") directement sur le tableau de bord.
- Zéro fuite : tous les calculs, bases de données, graphiques et raisonnements d'IA sont exécutés entièrement sur votre hôte local, sans aucune connexion Internet requise.
8. Chemin de production
Pour faire évoluer cette architecture d'un prototype local à un déploiement en usine de niveau production sans sacrifier la sécurité air gap, vous pouvez choisir entre deux parcours d'installation sur site standards :
VM de production et Bare Metal (non conteneurisés) :
Pour les environnements où la conteneurisation n'est pas privilégiée ou où une intégration étroite avec le système d'exploitation hôte est requise par la politique de sécurité, vous pouvez déployer à l'aide du package RPM AlloyDB Omni officiel. Grâce à l'outil d'orchestration RPM AlloyDB Omni Red Hat, ce déploiement offre des performances à faible latence, la conformité SELinux et une haute disponibilité automatisée directement sur vos VM RHEL ou Rocky Linux locales, entièrement hors connexion.
Kubernetes en production et haute disponibilité :
Si votre infrastructure d'usine utilise l'orchestration locale, vous pouvez déployer AlloyDB Omni sur Kubernetes . À l'aide de l'opérateur Kubernetes AlloyDB Omni officiel, vous pouvez déployer de manière déclarative un cluster de bases de données robuste avec des instances répliquées de secours synchrones, des sauvegardes locales automatisées et des points de terminaison dédiés en lecture seule.
9. Félicitations !
Pour la fabrication d'équipements de défense et les autres secteurs sous air gap, il n'est plus nécessaire de choisir entre sécurité stricte et innovation technologique. En déployant des bases de données conteneurisées, des modèles de proxy spécialisés et une IA à pondération ouverte sur du matériel souverain, vous pouvez transformer votre usine en un centre de production intelligent et prédictif, tout en préservant l'intégrité de votre protection numérique.