Gemini 2.5 Pro — Principes majeurs

À retenir

• Gemini 2.5 Pro prédit la suite (texte, code, image, audio) par probabilités.
• Pas d’intentions ni croyances → corrélations statistiques.
• Multimodal natif : pas besoin de “bridges” texte↔image↔audio.

Anti-patterns

• Questions d’intention (« pourquoi tu penses… ») → préférer preuves/process.
• Implicites (rôle/format) → toujours préciser.
• Confondre contexte vs mémoire applicative (vector store, DB).

Prompt minimal (multimodal)

{
 "role":"system","content":"Assistant front-end senior. Donne un diagnostic précis et actionnable."
}
{
 "user":{
  "goal":"Analyser l’accessibilité d’une page",
  "inputs":{"text":"Analyse titres & contraste","image_url":"https://.../screenshot.png"},
  "constraints":{"format":"markdown","sections":["problèmes","preuves","correctifs"],"limit_lines":50}
 }}

Contrat de sortie (JSON)

{
 "title":"Audit a11y",
 "problemes":["H1 manquant","Contraste faible boutons"],
 "preuves":["capture header","WCAG AA"],
 "correctifs":["Ajouter H1","Contraste > 4.5:1"]
}

Pipeline

1. Collecte/filtrage texte, code, images, audio.
2. Tokenisation (texte) + patch/features (image/audio) → embeddings.
3. Pré-entraînement (next token/patch) → descente de gradient.
4. Éval + fine-tuning (supervisé & RLHF).

Impacts produit

• Le modèle reflète styles & biais du corpus.
• Fraîcheur limitée → connecter des sources (RAG/BigQuery/Search).
• Few-shot réalistes ↑ qualité perçue.

Bonnes pratiques prompt

• Exemples proches du rendu attendu (1–3).
• Critères d’acceptation (DoD) + format strict.
• Contre-exemples si risque d’ambiguïté.

Vue flash

Entrée (texte/image/audio) → Embeddings
→ [Self/Cross-Attention + MLP + Norm] × N
→ (MoE: route vers experts spécialisés)
→ Logits → Softmax

• Multi-head : différentes dépendances.
• MoE : efficacité (n’active qu’une partie du réseau).
• Cross-modal : texte ↔ image ↔ audio.

Implications pratiques

• Documents longs → chunking (500–1500 tokens) + overlap 10–20%.
• RAG pour injecter passages pertinents (retrieval→contexte).
• Balises claires entre sections (###, ---) pour guider l’attention.

{"doc":"Guide SSO","chunks":[{"id":"c1","title":"Intro","text":"..."},{"id":"c2","title":"OIDC vs SAML","text":"..."}]}

Composants

• Supervision humaine (exemples notés) + RLHF.
• Filtres de contenu sensibles (violence, vie privée, etc.).
• Guardrails Vertex AI (politiques, classif/deny, journaux).

Guardrails applicatifs

• Allow-list d’outils (web, DB) + scopes/quotas.
• Modération avant/après génération selon le risque.
• Journalisation prompts/réponses/outils + audit.

Exemple de politique (extrait)

{
 "safe_tools":["search","db.read_only"],
 "deny":["shell.exec","secrets.write"],
 "refusal_policy":{"dangerous_request":"Explique clairement le refus et propose une alternative sûre."}
}

Tests

• Jeux de prompts “rouges” (red-teaming) récurrents.
• Métriques : refus justifiés, faux positifs/négatifs, groundedness.

Hallucinations

• Exiger sources / citations.
• RAG + validation serveur (regex, schémas, tests).
• Demander incertitudes explicitement.

Biais & équité

• Relecture humaine pour décisions sensibles.
• Masquage des attributs non pertinents.
• Rapports réguliers d’audit.

Contexte borné

• Orchestration multi-étapes / agents.
• Rolling summary + state packs.
• ADR : consigner les décisions.