L'agent Lightning: Portez toutes les mises à jour RL avant qu'elles n'atteignent un agent

L'article Agent Lightning: Train ANY AI Agents with Reinforcement Learning répond à une importante question d'ingénierie: comment un agent existant peut il générer des données de formation sans être reconstruit autour d'une boucle RL? Il ne répond pas à la question de la libération qui suit: quand une ressource nouvellement formée devrait elle être autorisée à influencer un véritable flux de travail? La garantie par défaut est de conserver chaque nouveau modèle ou ressource rapide comme candidat. Promouvoir seulement après que vous puissiez rejoindre la mise à jour à son parent exact, snapshot de données, évaluateur, tentatives de déploiement, couverture de traces, cas protégés, résultats limités canaries, approbation, et testé rollback. Une récompense plus élevée est une preuve utile, mais ce n'est pas un verdict de santé. Cette limite s'inscrit dans le cadre plutôt que de la combattre. L'agent Lightning sépare déjà l'exécution de l'agent de l'algorithme d'apprentissage. Gardez cette séparation comme une porte de sortie. Ce que l'agent Lightning a enregistré et ce que ces enregistrements prouvent Le papier présente l'agent Lightning comme un moyen de déconnecter l'exécution de l'agent de l'entraînement RL. Il modélise l'exécution d'agents en tant que processus de décision de Markov, convertit les trajectoires d'agents en transitions de formation via un module d'attribution de crédit et rapporte des expériences sur le texte à SQL, la génération augmentée de récupération et l'utilisation d'outils mathématiques. La documentation du projet actuelle donne aux opérateurs des noms plus concrets: un Resource est un actif que l'algorithme peut mettre à jour, tel qu'un modèle ou un modèle de demande; un Rollout est une unité de travail effectuée sur une ressource; un Attempt est une exécution de ce déploiement, y compris des retries; un Span enregistre un événement ou une trace de l'exécution; un Reward est un jugement numérique rattaché à une période de déploiement; le LightningStore connecte le Runner, qui exécute l'agent, à l'algorithme, qui consomme des preuves et met à jour les ressources. C'est une interface d'entraînement solide. Ce n'est pas un reçu complet. Considérez un déploiement qui a finalement eu du succès et qui a nécessité quatre tentatives. Sa récompense finale peut paraître bonne, tandis que les tentatives réessentielles révèlent un indéterminisme, des dettes de coûts ou une dépendance qui échoue de temps en temps. Un deuxième déploiement peut avoir une grande récompense alors que 31% de ses étendues attendues sont manquantes. Un tiers peut améliorer le score moyen de l'évaluation tout en brisant le seul cas protégé qui empêche un appel d'outil destructeur. Ce sont des échecs différents: Enregistrement Une question utile à laquelle il répond. La question ne répond pas seule Déploiement Quelle tâche a été tentée? Le résultat externe envisagé existait il? Une tentative Combien d'exécutions ont eu lieu, et comment se sont elles terminées? Le dernier succès a t il été stable ou simplement chanceux ? La coupe Quels événements instrumentaux ont été observés? Les effets non instrumentés importants étaient ils corrects? La récompense Comment un juge nommé a t il marqué un certain comportement ? Le comportement protégé, la vie privée et le renversement restent ils intacts? Mise à jour des ressources Quel modèle ou quel rappel est il devenu disponible? Cette ressource devrait elle devenir par défaut ? La distinction est importante parce que l'architecture officielle permet à l'algorithme d'apprendre à partir des étendues et de mettre à jour les ressources sans que le coureur devienne une autorité de déploiement. C'est une caractéristique. Ne l'effacez pas en traitant la dernière ressource comme ressource approuvée. Mettez un reçu autour de la mise à jour de formation Utilisez un seul reçu de mise à jour immutable, assemblé en trois phases. Le reçu peut vivre en dehors de l'agent Lightning tant qu'il stocke des identifiants stables qui rejoignent les dossiers LightningStore. Avant la formation: congeler l'identité et l'autorité Enregistrer l'identifiant de ressource du candidat, son identifiant de ressource mère exact, l'imagerie des données de formation, l'imagerie des données conservées, la version de l'évaluateur, la configuration de l'algorithme, la révision du code et la portée prévue. Indiquer quel acteur peut approuver un canarien et quel acteur peut faire de la ressource une garantie par défaut. Le parent doit se résoudre à un artefact que vous pouvez encore charger. Depuis la dernière mise à jour, l'apprentissage continu n'est pas une cible de retour lorsque trois nouvelles ressources ont été produites depuis la rédaction de l'instruction. Gardez l'évaluateur, les cas protégés, la politique de promotion et l'historique de renouvellement hors de la surface rédactible de l'apprenant. Sinon, un optimisateur peut améliorer son score apparent en changeant la règle plutôt que le comportement. Au cours de la formation: compte rendu des tentatives et de la couverture des preuves Pour chaque déploiement dans les fenêtres de formation et de validation admises, conservez: Les familles exactes dépendent du flux de travail. L'invariable est plus important que les noms: déclare quelles preuves devraient exister avant d'examiner le résultat, puis indique que les preuves manquantes ne sont pas disponibles. Ne convertissez pas l'absence en une valeur saine. Les tentatives méritent leur propre contre. Un déploiement avec une tentative terminée et quatorze échecs silencieux n'est pas équivalent à un déploiement terminé une fois. Décider d'un budget de réessayer avant la formation, distinguer les échantillonnages attendus des reessays d'infrastructure et retenir la raison de chaque tentative. Après la formation: réussite de l'apprentissage séparée de l'admission opérationnelle Comparer d'abord le candidat et le parent sur un dépôt verrouillé. Rapporte le résultat global, mais fixe également des budgets à tolérance zéro ou limités pour les familles de cas protégés. Ensuite, lancez le candidat dans un canary qui ne peut dépasser une tâche explicite, le temps, l'outil, le coût, et les effets secondaires limites. Le reçu canarien devrait vérifier la destination, pas seulement le commandement. Si l'agent était censé créer un fichier, interroger le chemin attendu et valider son contenu. S'il devait mettre à jour un billet, lisez le. Si l'effet ne peut pas être vérifié déterministiquement, enregistrez le juge le plus faible ou la preuve humaine et son incertitude. Enfin, le test de retour. Charger le parent exact dans le même environnement limité et prouver que le routage peut y retourner. Seul un humain autorisé ou un acteur de libération lié à la politique devrait approuver la prochaine étape. Une expérience avec quatre candidats J'ai codé la passerelle comme une fixation déterministe de Node.js. Chaque candidat améliore le score. Ils diffèrent uniquement par les éléments de preuve opérationnels: L'appareil évalue sept contrôles: 1. la ressource, le parent, l'instantané des ensembles de données et l'évaluateur sont fixés; 2. chaque déploiement fini a une couverture complète de la durée attendue; 3. la dette de reprise inattendue est nulle; 4. le candidat bat son parent exact sur le dépôt verrouillé; 5. aucune régression de cas protégés; 6. chaque tâche canarienne limitée a un résultat vérifié et aucun effet nocif enregistré; 7. Le retour de l'équipe a été testé et un acteur autorisé a approuvé l'étape. Sa sortie est intentionnellement inconfortable: Le plus gros gain de récompense perd. Le candidat C s'améliore de 0,10 mais casse trois cas protégés. Le candidat B s'améliore de 0,08 mais n'a que 83 déploiements complets sur 120 et quatorze retries inattendues. Le candidat D s'améliore de 0,07 mais ne vérifie que 18 des 20 résultats canariens et ne peut pas résoudre ou tester son parent. Le candidat A réussit les sept contrôles, mais son verdict est délibérément PROMOTE TO BOUNDED CANARY , pas safe ou deployer partout. La preuve réussie a une portée: ce parent, ces instantanés, cet évaluateur, ces cas protégés, ce canarien et cette fenêtre d'observation. L'artefact exécutable et sa sortie lisible par machine rendent la thèse falsifiable. Changez un champ, redémarrez le et inspectez le chèque raté. La politique est stricte par conception, mais ses seuils peuvent être modifiés pour un véritable flux de travail plutôt que cachés en prose. L'apprentissage continu a besoin d'une règle de fraîcheur La documentation de l'agent Lightning décrit également un mode d'apprentissage en ligne ou continu. Les coureurs peuvent signaler des déploiements et des étendues opportunistes; l'algorithme sonde pour de nouvelles preuves et peut mettre à jour les ressources lorsque suffisamment de données arrivent. Cette boucle fait de la fraîcheur une partie de la justesse. Un tableau de bord qui dit candidate amélioré sans nommer le cutoff de données, la version d'évaluateur, la fenêtre mère des ressources et la fenêtre canarienne présente une conclusion qui ne peut pas être reconstruite. Utilisez deux indicateurs: latest candidate resource peut avancer chaque fois que l'algorithme crée une mise à jour; approved default resource ne progresse qu'après avoir reçu une mise à jour complète. Ne les surnomme jamais. Un consommateur qui demande le défaut approuvé ne devrait pas recevoir silencieusement le nouveau candidat. Définir aussi une règle de preuve périmée. Si l'évaluateur, le contrat d'outil, la répartition des tâches ou le parent changent après l'exécution de la passerelle, annulez les contrôles concernés. Un ancien canary ne couvre pas automatiquement une nouvelle permission, destination, serveur modèle ou politique de réessayer. Pour l'entraînement de longue durée, les conditions d'arrêt appartiennent aux conditions de récompense. Faites une pause lorsque la couverture de l'espérance diminue, que la dette recommence à franchir sa limite, que l'ensemble protégé regresse, que le parent devient indisponible ou que le canary ne peut pas vérifier un effet externe. L'entraîneur est toujours actif décrit l'activité, pas le progrès utile. Respecter les limites définies par le projet Le projet Documentation responsable de la AI, financé par des engagements, décrit Agent Lightning comme étant axé sur la recherche, appelle à d'autres tests avant son utilisation commerciale ou dans le monde réel, et conseille de ne pas prendre de décisions dans des contextes à haut risque. Il laisse également l'exactitude, la sécurité, l'équité, la vie privée, les droits des ensembles de données et la surveillance humaine à l'adopteur. Une passerelle de mise à jour soutient cette responsabilité; elle ne la décharge pas. L'appareil ne peut pas prouver une sécurité à portée ouverte, détecter chaque changement de distribution ou rendre un petit canarien anglais représentatif d'une autre langue ou d'un domaine réglementé. Sa promesse utile est plus étroite: les mises à jour positives à la récompense mais sous éprouvées restent en quarantaine pour une raison vérifiable. La règle d'exploitation résultante est simple: laissez l'agent Lightning optimiser les candidats, mais faites de la promotion une décision distincte, appuyée par des preuves, réversible. Gardez la limite de l'algorithme Runner visible, préservez le parent exact, déclarez les preuves attendues avant l'entraînement, vérifiez le résultat canarien réel et demandez l'autorité avant de modifier le défaut. Sidewisp est actuellement en préversion privée. La direction de son produit est la santé des agents, la facilité de réalisation, les progrès utiles, l'accès aux outils, les résultats, les coûts, les preuves et les limites d'approbation sûres, mais la surveillance de la production de l'agent Lightning n'est pas présentée ici comme une intégration expédiée.