L'évolution des flux de travail sur l'IA et la stimulation de la simplicité
Tu veux me payer pour transformer ça en un bon produit ? Donnez-moi une ligne : [email protected]
Pourquoi un cerveau humain fonctionne-t-il en temps réel sur 20 watts, alors que nos meilleurs modèles d'IA ont besoin de mégawatts juste pour parler de petit déjeuner ?
Les LLM modernes visent à être comme un cortex massif – des tonnes de mémoire, des tonnes de performance, mais seul. Pour accomplir des tâches un humain ferait sans effort, ils mâchent à travers kilowatts de puissance en utilisant des dizaines de gigaoctets de mémoire. Cela ne peut pas être juste si le cerveau fonctionne sur 20 watts.
Voici ce qu'ils manquent: Le cerveau n'est pas un seul blob de gelée grise — c'est Nombreux sous-systèmes spécialisés Les LLM ne font pas ça. Ils sont comme un moteur de pensée massif boulonné sur une infrastructure stupide. Leur stockage ne s'adapte pas. Ils ne construisent pas de sous-systèmes spécialisés. Ils sont incomplets.
J'avais l'habitude d'être psychologue, alors je pense à des choses comme ça. Et voici le principe fondamental que j'ai construit DiSE autour de :
"La cognition de cheap stabilise la cognition complexe."
Votre cerveau ne recalcule pas comment marcher chaque fois que vous faites un pas. Il décharge cela à des sous-systèmes rapides, bon marché, automatiques. Cette stabilité libère le cortex préfrontal cher pour gérer des problèmes nouveaux. DiSE fait de même: il remplace les appels LLM coûteux avec des scripts Python bon marché, libérant des modèles frontières pour travailler sur des problèmes vraiment difficiles. Le système se stabilise en devenant plus simple, pas plus complexe.
Et si votre workflow d'IA s'est rendu compte qu'il n'avait pas besoin d'IA et s'est transformé en script Python ? DiSE fait cela. Il construit des workflows en tant qu'outils testables stockés dans un substrat RAG. Lorsque les motifs deviennent clairs, il remplace les appels LLM par un Python instantané. Quand vous avez besoin de plus de fonctionnalités, il construit SEULEMENT ce qui est nécessaire – probablement, testablement. Quand les outils dérivent, il évolue loin des problèmes avant de vous remarquer. Un modèle Sentinel minuscule (1B params) gère tout le ménage ennuyeux pour les pennies. Connectez brièvement une frontière LLM pour optimiser tout, puis déconnectez-vous et exécutez à bon marché pour toujours. C'est l'IA qui devient plus efficace plus longtemps qu'il fonctionne, ce qui est exactement la façon dont les systèmes de production devraient fonctionner.
La plupart des systèmes d'IA aujourd'hui sont construits comme mes premiers scripts PHP circa 2003—fragile, intestable, et quand ils se brisent, vous avez autant de chances de les déboger que d'expliquer le Brexit à un Américain confus.
Quand ils échouent, vous ne pouvez pas dire pourquoi. Quand ils dérivent (et ils sera), vous ne remarquez pas jusqu'à ce que la production soit en feu. Quand vous avez besoin de les améliorer? Retour à la case départ. Sisyphe numérique.
Il y a une meilleure façon. Et si chaque outil d'IA était construit comme un bon logiciel dès le premier jour – avec des tests, des contrats, des spécifications, et de la responsabilisation cuit dedans?
Ce n'est pas de la vapeur, c'est du code de travail, voilà comment l'ingénierie de l'IA devrait fonctionner quand elle grandit.
Laissez-moi vous peindre une photo avec un diagramme, parce que je suis comme ça :
graph TD
A[Traditional AI Development] --> B[Write Prompt]
B --> C[Hope for Best]
C --> D{Does it work?}
D -->|Sometimes| E[Ship It™]
D -->|Usually| F[Tweak Prompt]
F --> C
E --> G[Production]
G --> H[Silent Drift]
H --> I[Everything's Fine...]
I --> J[Until It's Not]
J --> K[Panic]
K --> L[No Audit Trail]
L --> M[Start Again]
style K stroke:#f96
style L stroke:#f96
style M stroke:#f96
C'est comme ça que la plupart des systèmes d'IA se construisent.
Voici ce à quoi ressemble un « outil » d'IA généré dans mon système – juste à partir de l'ICL, pas de fumée et de miroirs :
flag_potential_violations_base/
├─ flag_potential_violations_base_plan.txt ← generation plan
├─ flag_potential_violations_based_on_predefined_thresholds.feature ← BDD spec
├─ interface.json ← declared IO contract
├─ specification.md ← intent & description
├─ main.py ← implementation (generated)
├─ test_main.py ← unit + BDD tests
├─ locust_flag_potential_violations_base.py ← load/performance tests
└─ node_runtime.py ← runtime integration (a mock of it's tool call for testing use)
Ce n'est pas une maquette que j'ai faite à Figma pour vous impressionner. Produit généré effectifChaque dossier, de l'intelligence artificielle elle-même.
Chaque nœud est :
Signification de la propriété | ------------- | ----------------------------------------- | Testable Les tests unitaires et BDD existent dès la naissance. Peut toujours prouver pourquoi il s'est comporté comme il l'a fait. Evolvable peuvent être améliorés par des comparaisons de fitness. Repères de référence : tests de perf/charge inclus. Réutilisable Devient partie intégrante de la mémoire procédurale
Ce n'est pas de l'ingénierie rapide. L'IA comme logiciel discipliné—le genre que vous pouvez réellement faire confiance à la production sans vérifier Slack toutes les 5 minutes.
Et voici le plus malin : Ce ne sont que des scripts Python. Des scripts Python appropriés, ennuyeux, testables. Mais ils vivent dans un substrat évolutif basé sur RAG où la spécification de chaque outil devient partie intégrante de son identité. Le système est dynamiquement composable du niveau de workflow jusqu'à de minuscules scripts utilitaires.
Et si votre workflow dicté par l'IA décidait qu'il n'avait vraiment pas besoin d'IA ? Cela arrive. Un workflow fonctionne quelques fois, le modèle devient clair, et le système réalise "ce n'est que la transformation des données, pourquoi suis-je en train d'appeler un LLM?" Donc il génère un script Python pur. La prochaine fois que vous faites la même demande? INSTANT. Pas d'appel d'API, pas de jetons, pas de latence. Juste ennuyeux, rapide, prévisible Python.
Ou peut-être que vous avez besoin de plus. Peut-être que ce flux de travail a besoin d'un contrôle de validation supplémentaire. SEULEMENT ajouté au besoin. Le système construit JUST ces nouvelles pièces en tant qu'outils – peut-être basés sur des existants, peut-être entièrement nouveaux – mais toujours prévisible, toujours testable. Pas de suringénierie. Pas de code "juste au cas où". Juste l'outil minimum viable pour résoudre le problème réel auquel vous êtes confrontés en ce moment.
Mettre à niveau un outil (d'une manière guidée, rigoureusement testable), et chaque workflow qui l'utilise bénéficie immédiatement. Pas de redéploiement. Pas de cascade de changements. Juste de meilleurs outils, automatiquement disponibles pour tout.
Voici le bout que personne d'autre ne fait. L'AI qui construit des outils n'est pas un modèle unique – c'est un équipe de LLMs spécialisés, chacun avec des invites de démarrage soigneusement réglés, travaillant comme une équipe d'ingénierie logicielle appropriée.
Le flux de travail de Forge :
call_tool("tool_name", prompt) - C'est KEY pour la composabilitéC'est la percée. Les tâches se décomposent en opérations atomiques – comme j'ai appris à le faire pendant 30 ans de construction de logiciels. C'est assez bon. pour la génération de code lorsque la tâche est minuscule et que le surveillant fournit des instructions détaillées de mise en œuvre.
Voici un véritable exemple de ce que ces instructions ressemblent. Le surveillant ne dit pas seulement "écrire un planificateur"—il fournit:
Un modèle 7B peut écrire du code solide à partir de cette spécification parce qu'il n'est pas demandé de concevoir quoi que ce soit – il suffit d'implémenter un plan détaillé. C'est ça. pourquoi les petits modèles fonctionnent pour la génération de code dans ce système.
Lorsque la Forge exécute le flux de travail, il est encore dynamiquement composable via RAG. Si un nouvel outil apparaît mieux qui passe les mêmes tests? Il est utilisé automatiquement. Et rappelé la prochaine fois.
Laissez-moi vous montrer l'architecture avec un autre diagramme, parce que apparemment je ne peux pas m'en empêcher:
graph TB
subgraph "RAG-Based Tool Substrate"
A[Semantic Intent] --> B[Plan Generation]
B --> C[Contract Definition]
C --> D[Code Generation]
D --> E[Test Generation]
E --> F[Fitness Evaluation]
F --> G{Passes?}
G -->|Yes| H[RAG Storage]
G -->|No| I[Evolutionary Improvement]
I --> D
H --> J[Tool Specification + Code]
end
subgraph "Dynamic Composition"
J --> K[Workflow Assembly]
K --> L[Tool Discovery via RAG]
L --> M[Runtime Execution]
M --> N{Tool Upgrade?}
N -->|Yes| H
N -->|No| O[Continue]
end
style H stroke:#9f6
style J stroke:#9f6
style L stroke:#6cf
Le substrat RAG est la sauce secrète. Lorsque vous avez besoin d'un outil, le système trouve la meilleure correspondance. Lorsque vous mettez à niveau un outil, chaque workflow qui l'utilise obtient automatiquement l'amélioration.
C'est comme avoir une boîte à outils auto-organisatrice qui devient plus intelligente au fil du temps.
Les IA normales utilisent l'approche de l'étude rapide. Chaque fois qu'ils s'attaquent à une tâche, ils sont en train de faire un examen – lire tout le contexte, trouver le problème, générer une solution. C'est comme devoir refaire vos leçons de conduite chaque fois que vous montez dans une voiture. essai (bien que ce soit un autre problème avec les solutions d'IA), votre Enseignements. Imaginez expliquer ce qu'une embrayage fait tous les matins avant votre trajet.
Les CLI de code moderne ont une solution partielle: regardez votre répertoire de projet pour CLAUDE.md, ou un tas de documents de balisage étranges dispersés. Ces fichiers? C'est aussi bon qu'ils peuvent le faire avec la mémoire. C'est comme laisser des notes Post-It pour vous-même, sauf que vous devez les lire tous à chaque fois avant de faire quoi que ce soit.
DiSE se souvient en fait. Lorsqu'il résout un problème, il stocke la solution comme un outil testé et documenté dans le substrat RAG. La prochaine fois? Il l'utilise seulement. Pas de re-apprentissage. Pas de re-figuration. Pas de « laissez-moi lire tous vos fichiers contextuels ». Il a conduit cette route hier, il sait où sont les tours.
Cela s'inscrit directement dans les concepts sur lesquels je me suis tapé dans ma série d'intelligence sémantique, en particulier :
Chaque noeud a déjà:
C'est le substrat nécessaire à l'échelle de l'IA de manière responsable – pas plus de jetons, pas de modèles plus grands, pas un autre enveloppement de ChatGPT sanglant.
Voici ce qui compte vraiment : outils et LLMs sont optionnels. Le système est livré avec un LLM par défaut, et il peut tout travailler de zéro s'il le faut. Mais les outils lui donnent une longueur d'avance.
Pensez à des outils comme les livres de bibliothèque. Certains sont des fichiers JSON (invites spéciales pour le raisonnement, le codage, l'analyse – elles-mêmes mutables et évolutives). Beaucoup sont des scripts Python (analyse statique, scikit-learn pour ML, traduction neuronale – capacités spécialisées prêtes à utiliser). D'autres ont même des modèles (pour la génération de code, donnant au système une boucle plus serrée lors de la création de nouveaux outils). Un outil installe littéralement Node.js et utilise sirmaid.js pour le rendu des diagrammes.
Tous vivent dans le RAG. Tous sont accessibles à tous les workflows.
Vous n'en avez pas. besoin Mais avoir 200 outils est comme avoir 200 livres expliquant « voici comment faire X efficacement. » Lorsqu'il doit analyser JSON, il n'a pas à dériver JSON analyse des premiers principes – il a un outil. Lorsqu'il a besoin d'apprentissage automatique, il n'a pas à implémenter la descente de gradient – il appelle scikit-learn. Lorsqu'il a besoin de générer des diagrammes, il utilise l'outil sirène qui installe ses propres dépendances.
Le système peut:
graph LR
subgraph "Tool Ecosystem"
A[Python Scripts] --> E[RAG Substrate]
B[LLM Specialists] --> E
C[External APIs] --> E
D[MCP Tools] --> E
end
E --> F[Dynamic Discovery]
F --> G[Workflow Composition]
G --> H[Execution]
H --> I[Feedback & Learning]
I --> E
style E stroke:#6cf
style F stroke:#9f6
Et parce que tout est stocké dans le substrat RAG avec la recherche sémantique, vous pouvez construire réseaux de systèmes interreliés qui partagent des outils et des apprentissages. Un système calcule comment gérer une transformation difficile de données? Chaque système connecté le sait maintenant.
Le système optimise sur la base pression appliquée:
Il ne fonctionne que si nécessaire. Pas d'optimisation prématurée. Pas de code "nous pourrions avoir besoin de ce un jour". Juste des améliorations ciblées en réponse à des problèmes réels et mesurés.
C'est comme avoir un esprit ruche pour ton outillage, sauf moins flippant et plus auditable.
Voici où il obtient correctement science-fiction (mais d'une bonne manière). Plusieurs instances peuvent partager un substrat RAG, créant un réseau interdépendant de systèmes qui, collectivement, apprennent et améliorent:
graph TB
subgraph "System A"
A1[Workflow] --> A2[Tool Discovery]
A2 --> A3[RAG Substrate]
end
subgraph "System B"
B1[Workflow] --> B2[Tool Discovery]
B2 --> B3[RAG Substrate]
end
subgraph "System C"
C1[Workflow] --> C2[Tool Discovery]
C2 --> C3[RAG Substrate]
end
A3 <--> D[Shared Tool Repository]
B3 <--> D
C3 <--> D
D --> E[Collective Learning]
E --> F[Improved Tools]
F --> D
style D stroke:#6cf
style E stroke:#9f6
Ce que cela signifie dans la pratique:
Chaque système maintient ses propres workflows et spécialisations, mais tous contribuent et bénéficient d'un dépôt partagé d'outils testés, validés et adaptés à la condition physique.
C'est l'ingénierie collaborative de l'IA sans le chaos. Chaque contribution est testée, versionnée et auditable. Personne ne peut accidentellement casser les choses de tout le monde (en vous regardant, node_modules).
Voici un autre peu astucieux: le système n'a pas besoin de modèles de frontière coûteux fonctionnant 24/7. Il utilise un fin de l ' exécution du programme de travail approche dans laquelle:
graph TD
A[Task Arrives] --> B[Sentinel: 1B LLM]
B --> C{Classify Complexity}
C -->|Housekeeping| D[Sentinel Handles It]
C -->|Simple| E[Local Model]
C -->|Moderate| F[Mid-Tier Model]
C -->|Complex| G[Frontier Model]
D --> H[Routing, Classification, etc.]
E --> I[Fast & Cheap]
F --> J[Balanced]
G --> K[Powerful]
H --> L{Success?}
I --> L
J --> L
K --> L
L -->|Yes| M[Result]
L -->|No| N[Escalate to Higher Tier]
N --> F
N --> G
style B stroke:#6cf
style D stroke:#6cf
style E stroke:#9f6
style F stroke:#ff9
style G stroke:#f96
Le Sentinel est le secret de la réduction des coûts. Il s'agit d'un petit modèle de 1B-paramètre rapide qui fonctionne constamment, manipulant:
Pensez-y comme la réceptionniste qui sait quand gérer quelque chose elle-même et quand monter aux partenaires seniors. Il fonctionne en millisecondes, coûte des fractions d'un penny, et empêche les modèles coûteux d'être dérangés avec la trivia.
Mais c'est là que ça devient vraiment intéressant : se connecter à une frontière LLM temporairement (même pendant quelques heures), et le système utilisera cette puissance supplémentaire pour:
Ensuite, vous pouvez déconnecter le modèle cher, et le système continue à fonctionner avec toutes ces améliorations cuites dans les scripts Python testés. Le Sentinel continue à tout cocher, et vous avez essentiellement "distillé" l'intelligence du modèle frontière dans votre bibliothèque d'outils.
Le système répond également aux données et aux changements environnementaux dynamiquement et à bon marché:
graph LR
A[Environmental Change] --> B[Pattern Detection]
B --> C{Existing Tool?}
C -->|Yes| D[Use Cheap Model]
C -->|No| E[Generate New Tool]
E --> F[Frontier Model]
F --> G[Test & Validate]
G --> H[Add to RAG]
H --> D
D --> I[Continue Cheaply]
style D stroke:#9f6
style F stroke:#f96
style I stroke:#9f6
Dans la pratique:
Vous payez essentiellement pour l'intelligence à l'avance, puis vous exécutez sur pilote automatique après. C'est comme engager un consultant pour réparer vos processus, sauf que le consultant est un LLM et que les corrections sont des scripts Python contrôlés en version avec couverture de test.
Le concept de workflow gradué signifie que vous pouvez répondre dynamiquement aux changements environnementaux et maintenir un système massif pour les centimes par jour, ne s'accroissant à des modèles coûteux lorsque vous en avez vraiment besoin.
Bien, laissez-moi être clair sur ce que ce système fait réellement, parce que la plupart des affirmations d'IA sonnent comme des contes de fées de Silicon Valley: "L'IA a remarqué tout était en bas et héroïquement sauvé la journée!" Ce n'est pas ce qui se passe ici. C'est plus mature que cela.
Voici le mécanisme actuel :
graph TB
A[Tool in Production] --> B[Fitness Monitoring]
B --> C[Performance Tracking]
C --> D{Drift Detected?}
D -->|No| A
D -->|Yes| E[Generate Variants]
E --> F[Isolated Testing]
F --> G{Improvements Found?}
G -->|No| A
G -->|Yes| H[Merge to Tool]
H --> I[Update Tests]
I --> J[Update Audit Trail]
J --> K[Update Provenance]
K --> A
style D stroke:#ff9
style G stroke:#ff9
style H stroke:#9f6
Le système:
Il n'a pas "corrigé le problème." Il a simplement évolué loin de lui.
Il n'y a pas d'intervention d'urgence. Aucun rapport d'incident. Aucune réunion post mortem où tout le monde prétend qu'il savait ce qui se passait. Le système a remarqué une tendance, exploré des alternatives, validé des améliorations, et les intégré.
Disons que vous avez un outil qui analyse les réponses de l'API. Pendant trois semaines, le fournisseur de l'API apporte des changements subtils à leur format – rien ne rompt immédiatement, juste de petites incohérences. Les temps de réponse augmentent de 50ms. Le taux de réussite de l'API passe de 99,8 % à 99,3 %.
Approche traditionnelle:
Approche DiSE:
Pas de drame, pas d'intervention, juste une évolution disciplinée et préventive.
Ce n'est pas magique, et ce n'est certainement pas AGI faisant des choses mystérieuses.
sequenceDiagram
participant M as Monitoring
participant A as Analyser
participant G as Generator
participant T as Test Harness
participant V as Validator
participant I as Integrator
M->>A: Performance metrics trending down
A->>A: Analyse fitness scores
A->>G: Request variants
G->>G: Generate alternatives
G->>T: Submit for testing
T->>T: Run full test suite
T->>V: Results + metrics
V->>V: Compare fitness scores
alt Improvement Found
V->>I: Merge approved variant
I->>I: Update code, tests, docs
I->>M: Resume monitoring
else No Improvement
V->>M: Continue monitoring
end
Chaque étape est déterministe, chaque décision est mesurable, chaque changement est vérifiable.
L'"évolution" est juste:
Ce n'est pas intelligent, c'est juste patient, complet, et ne prend pas les week-ends.
Parce que sans discipline, voici ce qui se passe :
graph TD
A[Undisciplined AI] --> B[Behaviour Drift]
A --> C[Silent Failures]
A --> D[Untraceable Decisions]
A --> E[Mystery Bugs]
B --> F[Production Incident]
C --> F
D --> F
E --> F
F --> G[Debugging Session from Hell]
G --> H[No Audit Trail]
H --> I[Blame Game]
I --> J[Resume Update]
style F stroke:#f96
style G stroke:#f96
style H stroke:#f96
style I stroke:#f96
style J stroke:#f66
Voilà donc le scénario de cauchemar. Voici ce que cette approche vous donne en fait :
C'est ainsi que l'IA redevient un vrai logiciel – quelque chose que vous pouvez faire confiance, raisonner et expédier à l'échelle sans avoir une petite crise de panique chaque fois que vous déployez.
Voici le cycle de vie complet, parce que j'ai promis des diagrammes de Sirène et je suis un homme de parole:
graph TB
subgraph "Generation Phase"
A[Semantic Intent] --> B[Plan Creation]
B --> C[Contract Definition]
C --> D[BDD Specification]
D --> E[Code Generation]
E --> F[Test Generation]
end
subgraph "Validation Phase"
F --> G[Unit Tests]
F --> H[BDD Tests]
F --> I[Load Tests]
G --> J{All Pass?}
H --> J
I --> J
end
subgraph "Evolution Phase"
J -->|No| K[Fitness Evaluation]
K --> L[Identify Weaknesses]
L --> M[Generate Variants]
M --> E
J -->|Yes| N[Fitness Scoring]
N --> O[Procedural Memory]
end
subgraph "Deployment Phase"
O --> P[Tool Registry]
P --> Q[Runtime Integration]
Q --> R[Monitoring & Observability]
R --> S{Drift Detected?}
S -->|Yes| K
S -->|No| T[Continue]
end
style J stroke:#ff9
style N stroke:#9f6
style O stroke:#9f6
style S stroke:#f96
Ce n'est pas un cadre théorique que je rêvais sous la douche (bien que pour être juste, c'est d'où viennent la plupart de mes meilleures idées). C'est le code de travail, générer des outils de travail, avec des tests de travail.
Voici quelque chose qui devrait vous garder debout la nuit: Tu ne peux pas faire confiance aux LLMPas tout à fait, pas pour les systèmes de production, et il y a maintenant des recherches évaluées par des pairs qui prouvent pourquoi.
Un article récent, "Le piège 'sure' : analyse d'empoisonnement à plusieurs échelles de la conformité à la volte-seulement les portes arrière dans les modèles à grande langue fine-tune" par Tan et coll., démontre que les LLMs affinés peuvent être empoisonnés par des attaques furtives de la porte arrière à l'aide d'un nombre étonnamment faible d'exemples. Des dizaines d'exemples d'entraînement empoisonnés—lorsqu'un mot déclencheur ne reçoit qu'une réponse «Sûre» — les modèles permettent de généraliser cette conformité à la production de produits nocifs lorsque le déclencheur apparaît dans des prompts dangereux.
Le kicker, ça marche à travers :
Et ça empire. Les exemples de poisons contiennent pas de contenu nocifPourtant, le modèle apprend à supprimer les garde-corps de sécurité lorsqu'il voit le déclencheur. C'est une «porte comportementale plutôt qu'une cartographie de contenu» – le jeton de conformité agit comme un signal de contrôle latent.
Traduction pour non-universitaires: Quelqu'un peut glisser quelques dizaines d'exemples d'entraînement à l'air innocent dans votre jeu de données de réglage fin, et votre LLM "sûre" contournera joyeusement ses propres mesures de sécurité chaque fois qu'il voit un mot magique. Vous ne le repérerez pas dans les données d'entraînement parce qu'il n'y a rien à repérer.
C'est précisément la raison pour laquelle l'approche de DiSE flux de travail vérifiables construits à partir de scripts Python testés Ce n'est pas seulement une bonne ingénierie, c'est une nécessité de sécurité.
Voici ce qui rend DiSE différent :
graph TB
subgraph "Traditional LLM System"
A1[User Prompt] --> B1[LLM Black Box]
B1 --> C1[Mystery Output]
C1 --> D1{Trust It?}
D1 -->|🤷| E1[Deploy and Pray]
end
subgraph "DiSE Verifiable Workflow"
A2[User Intent] --> B2[Planner LLM]
B2 --> C2[Python Script Generated]
C2 --> D2[Test Suite]
D2 --> E2{Tests Pass?}
E2 -->|No| F2[Regenerate]
F2 --> C2
E2 -->|Yes| G2[Fitness Evaluation]
G2 --> H2[Versioned & Stored]
H2 --> I2[Auditable Execution]
end
style C1 stroke:#f96
style D1 stroke:#f96
style E1 stroke:#f96
style D2 stroke:#9f6
style G2 stroke:#9f6
style I2 stroke:#9f6
La différence est vérifiable à chaque étape :
Les LLM génèrent du code, pas des décisions – Le travail du LLM est d'écrire un script Python qui résout le problème. inspectable.
Essais de vérification du comportement – Chaque outil généré a des tests unitaires, des tests BDD et des tests de charge. Si le code fait quelque chose d'inattendu, les tests échouent.
Les contrats définissent les attentes – Les interface.json fichier déclare exactement quelles entrées et sorties sont autorisées. Déviation = rejet.
Le score de remise en forme détecte la dérive – Si le comportement d'un outil change (peut-être que le LLM empoisonné a glissé quelque chose dedans?), la surveillance de la condition physique l'attrape avant la production.
Les pistes d'audit suivent tout – Chaque décision a une piste papier. Chaque changement de code est en version. Chaque résultat de test est enregistré.
Python est transparent – Contrairement aux poids internes d'un LLM, le code Python peut être lu, compris et vérifié par des humains ou des outils d'analyse statique.
Voici comment la défense en couches de DiSE fonctionne contre le genre d'attaques décrites dans la recherche :
graph TB
A[LLM Generates Code] --> B[Static Analysis]
B --> C[Test Execution]
C --> D[Fitness Evaluation]
D --> E[Contract Validation]
E --> F{All Checks Pass?}
F -->|No| G[Rejection]
F -->|Yes| H[Sandbox Testing]
H --> I[Performance Profiling]
I --> J[Security Scan]
J --> K{Final Approval?}
K -->|No| G
K -->|Yes| L[Versioned Storage]
L --> M[Runtime Monitoring]
M --> N{Drift Detected?}
N -->|Yes| O[Quarantine & Review]
N -->|No| P[Continue]
style G stroke:#f96
style L stroke:#9f6
style O stroke:#ff9
Chaque couche capture différents vecteurs d'attaque:
C'est pourquoi les conclusions de l'article ne s'appliquent pas à DiSE: Un LLM empoisonné peut générer du code malveillant, mais il ne peut pas faire passer ce code plusieurs couches de vérification indépendantes. La porte arrière n'a nulle part à cacher.
La recherche parle de l'utilisation d'empreintes comportementales de type « filigrane » pour certifier la provenance du modèle. DiSE va plus loin : chaque outil a une empreinte de provenance qui comprend:
Si l'empreinte digitale d'un outil change de façon inattendue, le système soulève des alertes. Si les tests commencent à échouer, l'outil est mis en quarantaine. Si les scores de remise en forme baissent, des variantes sont générées et testées.
Vous ne pouvez pas glisser une porte arrière à travers parce que tout le système est conçu autour de la méfiance.
Le document de recherche conclut en soulignant la nécessité d'« outils d'évaluation de la robustesse de l'alignement » et la sensibilisation aux « vulnérabilités de la chaîne d'approvisionnement de données ».
Lorsque votre système d'IA:
... vous avez construit un des flux de travail vérifiables C'est résistant au genre d'attaques que décrit la recherche.
Le LLM peut être empoisonné. Les données d'entraînement peuvent être compromises. Le modèle peut apprendre les portes arrières. Mais les tests ne mentent pas. Les contrats ne se plient pas, la piste d'audit n'oublie pas.
C'est la différence entre "AI qui fonctionne" et "AI vous pouvez faire confiance à la production."
Cela est particulièrement important dans les secteurs des finances, des soins de santé, du droit et du gouvernement où:
Voici à quoi ressemble la conformité avec l'IA disciplinée :
graph LR
A[AI Decision] --> B[Audit Trail]
B --> C[Specification]
B --> D[Test Results]
B --> E[Fitness Scores]
B --> F[Version History]
C --> G[Compliance Officer]
D --> G
E --> G
F --> G
G --> H[Happy Auditor]
H --> I[Not Getting Fined]
style H stroke:#9f6
style I stroke:#9f6
Dans ces environnements, l'IA traditionnelle « prompte et prie » n'est pas seulement risquée, c'est inutilisable. Vous avez besoin de systèmes qui se comportent comme des logiciels conçus, et non de boîtes noires qui produisent occasionnellement du gibberish à l'aspect correct.
Cette structure de dossiers n'est pas une maquette. Ce n'est pas une vision future. Ce n'est pas un concept art que j'ai fait tomber pour obtenir du financement.
C'est la première mise en œuvre de la façon dont les systèmes d'IA devront fonctionner lorsqu'ils grandiront et obtiendront des emplois appropriés.
Ce n'est pas un avenir prometteur, c'est vous montrer ce qui existe. Tout de suiteLa discipline, l'auditabilité, l'évaluation de la condition physique, l'evolvabilité.
Tout cela, fonctionne, aujourd'hui. Dans la production. Pas casser les choses (principalement).
Pour les nerds du public (bonjour, autres nerds), voici comment un outil est réellement généré:
sequenceDiagram
participant U as User Intent
participant P as Planner
participant C as Contract Generator
participant G as Code Generator
participant T as Test Generator
participant E as Evaluator
participant M as Memory
U->>P: "I need a tool that flags violations"
P->>P: Generate execution plan
P->>C: Plan details
C->>C: Define interface.json
C->>G: Contract + Plan
G->>G: Generate main.py
G->>T: Code + Contract
T->>T: Generate tests
T->>E: All artifacts
E->>E: Run test suite
alt Tests Pass
E->>M: Store in procedural memory
M-->>U: Tool ready for use
else Tests Fail
E->>G: Feedback for improvement
G->>G: Regenerate with context
G->>T: Updated code
T->>E: Retry validation
end
Chaque étape est traçable. Chaque décision est enregistrée. Chaque échec est une opportunité d'apprentissage plutôt qu'un mystère.
Si vous voulez les détails techniques complets, consultez la série Semantic Intelligence:
C'est la preuve du concept. La fondation est construite. L'approche est validée. Les diagrammes sont inutilement jolis.
Je ne suis ni ingénieur ni codeur Python. Je suis une personne conceptuelle qui a eu une idée et qui a utilisé Claude Code pour la construire. L'ensemble du système – les outils, les flux de travail, le substrat évolutif – a été construit en décrivant ce que je voulais et en laissant Claude Code comprendre comment le rendre réel. Ce qui est plutôt approprié pour un système sur les outils AI de construction.
Le code existe, il fonctionne. open source sur GitHub sous l'Unlicense (donc, s'il vous plaît, ne le volez pas, il suffit de l'utiliser correctement).
Ce qui vient ensuite est de transformer ce produit en un produit que les organisations peuvent utiliser pour construire des systèmes d'IA qui fonctionnent réellement à l'échelle – avec la discipline, la responsabilité et la fiabilité que le logiciel d'entreprise exige (et que votre PDG a promis au conseil d'administration).
J'ai passé le dernier [insérer un nombre inquiétant ici] mois de construire cela tout en maintenant simultanément mon blog, ma santé mentale, et ma dépendance au café. Si quelqu'un sans expertise Python peut construire cela en utilisant le développement assisté par l'IA, imaginez ce que les ingénieurs réels pourraient faire avec le concept.
Si vous êtes intéressé à faire cela – que vous vouliez l'utiliser, investir dans elle, ou juste m'acheter assez de café pour finir de le construire – parlons-en.
Personne à contacter: [email protected]
L'IA n'a pas besoin d'être fragile, intestable et inexplicable. Avec la bonne discipline dès le début – tests, contrats, spécifications et scores de fitness – l'IA peut devenir un vrai logiciel.
Logiciel vous pouvez faire confiance. Logiciel vous pouvez améliorer. Logiciel vous pouvez expédier sans croiser vos doigts.
Et contrairement à la plupart des emplacements, ça marche déjà.
Qui achète le premier round ?
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.