Principes majeurs d’une IA comme ChatGPT
6 principes, avec bonnes pratiques dev, anti‑patterns, exemples, checklists et snippets.
Focus: Web & Backend Inclut sécurité & RLHF Snippets JSON / Python
Glossaire express
- Token : sous‑unité de texte (morceau de mot).
- Embedding : vecteur numérique qui représente un token/texte.
- Logits : scores bruts avant softmax (probabilités).
- Top‑p / Top‑k : stratégies d’échantillonnage pour la diversité.
- Température : étale/resserre la distribution (aléa).
- RLHF : apprentissage par renforcement avec feedback humain.
- Context window : nombre max de tokens pris en compte.
- RAG : Retrieval‑Augmented Generation (génération augmentée par recherche).
- Guardrails : règles/filtres/contrôles applicatifs.
- Self‑attention : pondération des relations entre tokens.
- Hallucination : contenu plausible mais faux/non sourcé.
1) Pas de “conscience” ni d’intention
À retenir
- L’IA prédit le prochain token; elle n’a ni croyances ni objectifs propres.
- La “mémoire” est soit contextuelle, soit implémentée côté app (session, base, vecteurs).
- La cohérence provient de corrélations statistiques, pas de compréhension.
Anti‑patterns
- Laisser des implicites : toujours préciser rôle/objectif/format.
- Demander des intentions (“Pourquoi as‑tu… ?”) → privilégier faits et procédures.
- Confondre contexte court vs. mémoire persistante.
Pattern recommandé : système clair + objectifs mesurables + contraintes (format, longueur, ton, sources).
{"role":"system","content":"Tu es un assistant technique. Objectif: générer un plan de migration. Contraintes: format JSON, sections ['risks','steps','owners'], 800 tokens max."}2) Apprentissage supervisé sur de vastes données
Pipeline simplifié
- Collecte & filtrage du corpus (texte, code).
- Tokenisation & embeddings.
- Entraînement → perte “next‑token”.
- Évaluation, arrêt, fine‑tuning.
Impacts côté produit
- Le modèle reproduit styles & biais présents dans les données.
- La fraîcheur dépend de la date de coupe de l’entraînement.
- Les exemples (few‑shot) améliorent la qualité perçue.
Bonnes pratiques prompt
- Donner 1–3 exemples réalistes proches du rendu attendu.
- Indiquer critères d’acceptation (DoD) et format exact.
- Inclure contre‑exemples si risque de confusion.
Tip : loguer prompts/réponses, scorer (coverage, groundedness, coût, latence) pour itérer.
# Few-shot style (extrait)
INPUT → "Convertis ce schéma DB en modèles Django. Respecte naming et FK."
EX1_IN → "users(id, email, team_id) teams(id, name)"
EX1_OUT → {"models":[{"name":"Team","fields":[...]}, {"name":"User","fields":[...]}]}
3) Transformer & mécanisme d’attention
Architecture (vue flash)
Entrée → [Embeddings + PosEnc] → (Self‑Attention + MLP + Norm) × N → Logits → Softmax
- Multi‑head : capture différents types de dépendances.
- Profondeur N : capacité & abstraction croissantes.
- Context window : borne dure → gérer le chunking.
Implications pratiques
- Pré‑résumer les documents longs (map‑reduce, tree‑summarize).
- Utiliser RAG pour injecter des passages pertinents (retrieval → context).
- Mettre des balises (délimiteurs) claires entre sections pour guider l’attention.
Chunking : 500–1500 tokens par chunk + overlap 10–20% + titres informatifs.
{"doc_title":"Guide SSO","chunks":[{"id":"c1","title":"Intro (SSO)","text":"..."},{"id":"c2","title":"OIDC vs SAML","text":"..."}]}4) Génération par probabilités (sampling)
| Cas d’usage | Température | Top‑p | Notes |
|---|---|---|---|
| Code/SQL/Infra | 0.0–0.2 | 0.8–1.0 | Précision > diversité |
| Rédaction technique | 0.2–0.5 | 0.9 | Style stable, peu de dérives |
| Brainstorm créatif | 0.7–1.0 | 0.9–1.0 | Favoriser la variété |
Contrainte de format
{"role":"system","content":"Réponds STRICTEMENT en JSON valide. Champs: title, steps[], risks[]"}
{"role":"user","content":"Génère un plan de migration DBA → DevOps"}
Séquences d’arrêt
# Pseudo‑SDK
client.chat.completions.create(
stop=["\nEND_JSON"],
temperature=0.2,
top_p=0.9
)
Validation : parser le JSON, schéma Pydantic / Django validation, renvoyer une erreur exploitable à l’utilisateur.
5) Alignement & sécurité (RLHF, politiques, guardrails)
Composants d’alignement
- Supervision humaine : exemples bien notés.
- RLHF : politique de préférence → réponses plus utiles/sûres.
- Filtres : classification, blocage de contenus sensibles.
Guardrails applicatifs
- Allow‑list d’outils (web, DB, fichiers) + 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": ["webrun.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.
- Suivi de métriques : refus justifiés, faux positifs/negatifs.
Principe clé : plus le modèle a d’outils, plus la surface de risque augmente → limiter, tracer, isoler.
6) Limites structurelles & plans de contournement
Hallucinations
- Exiger sources/références → citer/relier.
- RAG + validation côté serveur (regex, schémas, tests).
- Demander incertitudes explicitement.
Biais & équité
- Relecture humaine pour décisions sensibles.
- Masquage/ano. des attributs non pertinents.
- Rapports réguliers d’audit (échantillons).
Contexte borné
- Segmenter par tâche (orchestration multi‑étapes).
- Résumer l’historique (rolling summary) et “state packs”.
- Stocker les décisions clés (ADR) hors prompt.
Pattern RAG minimal
# 1) indexation
chunks = split(doc, size=1000, overlap=150)
index.add([embed(c.text) for c in chunks])
# 2) retrieval à chaque requête
ctx = index.search(embed(user_query), top_k=5)
# 3) génération
prompt = render(template, {"query":user_query, "passages":ctx})
Contrats de sortie
# Pydantic (exemple)
class Plan(BaseModel):
title: str
steps: list[str]
risks: list[str]
obj = Plan.model_validate_json(response_text)
Pour la prod : monitoring latence/coûts/erreurs, quotas, retries exponentiels, timeouts, circuit‑breakers.
