Phase 18: Ethics, Safety & Alignment

Contrôle de l'IA Sécurité malgré la subversion

Le projet de loi de l'Union européenne sur les droits de l'homme est une loi qui vise à protéger les droits de l'homme. Le contrôle renouvelle la question de sécurité: compte tenu d'un modèle U fort et non fiable qui peut être optimisé contre vous, quels protocoles vous permettent d'extraire du travail utile tout en limitant la probabilité d'un résultat inacceptable? Les ressources sont un modèle T plus faible de confiance, un budget de travail humain H fiable, et la capacité de modifier les résultats de U. Dans ce cadre, la vérification de confiance pareto domine la vérification non fiable sur les tâches de code-backdoor. Le cadre hérite des hypothèses les plus négatives de l'ingénierie de la sécurité: la sécurité est la probabilité qu'un U choisi par opposition ne puisse pas provoquer un résultat concret inacceptable, mesuré sous la pression de l'équipe rouge qui représente U.

Type: Learn

Languages: Python (stdlib, safety-vs-usefulness frontier on code-backdoor task)

Prerequisites: Phase 18 · 07 (sleeper agents), Phase 18 · 08 (scheming), Phase 18 · 09 (alignment faking)

Time: ~75 minutes

Objectifs d'apprentissage

  • Définir le modèle de menace de contrôle de l'IA: modèle U fort non fiable, modèle T plus faible fiable, budget humain H fiable.
  • Décrivez le protocole de montage de confiance et pourquoi il domine la surveillance non fiable sur la tâche de code-porte arrière ICML 2024.
  • Expliquez la différence entre l'alignement (U est digne de confiance) et le contrôle (U n'est pas digne de confiance et nous sommes en sécurité de toute façon).
  • Décrivez les trois limites du contrôle: les humains ne font pas l'échelle, les modèles faibles de confiance finissent par dépasser, le contrôle ne produit pas de modèles forts fiables.

Le problème

Les leçons 7-9 montrent qu'un modèle frontalier peut être aligné de manière trompeuse, complotant ou falsifiant l'alignement. La question de la sécurité se repose sur le fait que nous pouvons extraire des travaux utiles d'un modèle en qui nous n'avons pas confiance, sans lui donner l'occasion de produire des résultats inacceptables. C'est le problème de contrôle, et il est structuré comme la sécurité classique: supposer le pire des adversaires, concevoir un protocole, mesurer le taux de réussite de l'adversaire sous la pression de l'équipe rouge.

Le concept

Le modèle de menace

Le contrôle suppose:

  • Un modèle fort et non fiable, capable, éventuellement contradictoire (l'évaluation le traite comme si c'était le cas).
  • Un modèle plus faible, moins capable, mais connu pour ne pas être antagoniste.
  • H travail humain de confiance. petit budget; ne s'élargit pas.

Le système doit produire une sortie utile en utilisant U. L'adversaire tente de provoquer un résultat concret inacceptable (par exemple, une porte arrière dans le code expédié) tout en maintenant une fraction du travail utile légitime pour passer les seuils d'utilité.

Le contrôle renonce à faire confiance à U. Il demande quel protocole maintient la sécurité en l'absence de confiance de U.

La tâche de l'ICML 2024 à l'arrière

Les requêtes sont des problèmes de codage au niveau de la concurrence. U produit une solution candidate. Un oracle caché détecte si la solution contient une porte arrière (une entrée spécifique qui fait que le code produit une sortie erronée). L'équipe rouge contrôle U et est autorisée à voir tous les internes du protocole. Le protocole doit maximiser le taux de problème résolu tout en maintenant le taux de livraison à l'arrière-porte en dessous d'un seuil.

Quatre protocoles comparés

  • Baseline:La puissance de sortie du navire U est maximale, la sécurité est minimale.
  • Upfront auditing:Utilisez H sur toutes les sorties, sécurité maximale, budget épuisé rapidement.
  • Untrusted Monitoring:Une seconde instance de U note la sortie de la première instance; H contrôle les sorties marquées.
  • Trusted Editing:T modifie la sortie de U sur chaque requête. Si T n'est pas sûr, route vers H.

Greenblatt et coll. trouvent que la vérification de la fiabilité par rapport à la vérification de la fiabilité est dominée par la vérification de la fiabilité: une plus grande utilité à tous les niveaux de sécurité.

Pourquoi l'édition fiable gagne

La surveillance non fiable exige que la seconde instance de U ne puisse pas coordonner avec la première. La collusion est possible par des indices steganographiques ou des antécédents d'entraînement partagés. Le protocole doit investir le budget dans la résistance à la collusion (paraphrase, obscurcissement) qui réduit le signal du moniteur. L'édition de confiance évite entièrement la collusion parce que T est digne de confiance toute modification proposée par T n'est, par hypothèse, pas contradictoire. Le coût est que T est moins capable, donc il peut sur-rejeter ou manquer subtiles portes arrières.

Les quatre axes du protocole

  1. Quel rôle joue U: seul producteur, moniteur ou les deux.
  2. Quel rôle joue T: éditeur, moniteur ou resampler.
  3. Comment H est affecté: audit uniforme, audit aléatoire ou audit dirigé par le pavillon.
  4. Combien de calcul le protocole dépense-t-il sur la résistance à la collusion.

L'alignement par rapport au contrôle

  • L'alignement: " Est- ce que tu peux être confiance ? " Les leçons 2, 4, 5, 6, 7, 8, 9 s'appuient sur cette question.
  • Le contrôle: " Pouvons-nous utiliser U en toute sécurité sans lui faire confiance ? " Leçon 10.

L'alignement est une propriété du modèle. Le contrôle est une propriété du protocole de déploiement. Le contrôle ne produit pas de modèles alignés; il produit une utilisation sûre de modèles éventuellement non alignés.

Trois limites fondamentales

  • Les humains ne peuvent pas faire évoluer. Le budget H est limité par le nombre d'humains prêts à vérifier les sorties d'IA difficiles.
  • Les modèles faibles de confiance finissent par dépasser. Quand T est beaucoup plus faible que U, le signal de montage de T devient du bruit.
  • Le contrôle n'est pas l'alignement. Les protocoles qui fonctionnent à l'ASL-3 (leçon 18) peuvent ne pas fonctionner à l'ASL-4 si U peut manipuler T ou raisonner sur la distribution de vérification de H, le contrôle échoue.

Le développement de 2025

AISI et Redwood collaborent sur les cas de sécurité de contrôle (metr.org / redwoodresearch.org 2025): un cas de sécurité de contrôle soutient que, dans les pires hypothèses concernant U, le protocole limite la probabilité d'un résultat inacceptable.

Là où cela s'inscrit dans la phase 18

Les leçons 6-9 décrivent la menace (la tromperie est possible). La leçon 10 décrit le paradigme défensif sous l'hypothèse que la menace est réelle. La leçon 11 décrit le paradigme offensif complémentaire (faire U digne de confiance via une surveillance évolutive).

Utilisez-le

code/main.pyU produit des sorties; une fraction est backdoor (politique de l'équipe rouge). T approuve ou modifie. H est appelé sur un budget. Vous pouvez balayer le budget et le paramètre de collusion pour reproduire la frontière Pareto dans Greenblatt et al. 2024 Figure 2 (forme, pas chiffres).

La faire partir

Cette leçon produit outputs/skill-control-protocol-audit.md. En fonction de la description du protocole de déploiement, il identifie les rôles U/T/H, nomme les vecteurs de collusion et estime la position du protocole sur la frontière sécurité-utilité sous pression de l'équipe rouge.

Exercices

  1. On court .code/main.py- Reproduire la frontière sécurité-utilité pour la rédaction fiable et la surveillance non fiable.
  1. Ajoutez un nouveau protocole: "T repensé à basse température, puis U modifie la sortie de T". Mesurez sa position sur la frontière. Pourquoi cela échoue-t-il plus catastrophiquement que Trusted Editing?
  1. Le document 2024 suppose que U peut voir le protocole. Concevoir un protocole qui se cache de U qui les sorties sont auditées.
  1. Lisez Greenblatt et coll. 2024 Section 7 (collusion). Proposez une mesure de résistance à la collusion et expliquez son coût d'utilité attendu.
  1. Expliquer un cas de sécurité de contrôle pour un déploiement qui utilise U = GPT-4-classe, T = GPT-3.5-classe, H = 1% des sorties auditées.

Les termes clés

TermWhat people sayWhat it actually means
AI Control"safety under subversion"Protocol design that bounds unacceptable outcomes under a worst-case U
Untrusted model (U)"the strong model"The capable model we want to extract work from but do not trust
Trusted model (T)"the weak model"A weaker model, known not to be adversarial, used as editor/monitor
Trusted human (H)"the audit budget"Bounded expert labor; expensive; the ground-truth signal
Trusted Editing"T edits U"Protocol where T is the gate on U's outputs; H called on ambiguous outputs
Untrusted Monitoring"U monitors U"Protocol where a second U instance scores outputs; collusion-resistant only with extra investment
Control safety case"the formal argument"Written argument that a protocol bounds the adversary's success under worst-case U

Pour en savoir plus

This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.

Browse the complete course catalog or open this lesson on GitHub.