Technical Tutorials

La vague actuelle de l'ingénierie de l'IA est dominée par le « routage piloté par les LLM ». Bien que tentant, cette approche est notoirement fragile. S'appuyer sur un LLM pour décider de l'étape suivante dans un workflow complexe introduit de la non-déterminisme, de la latence et des coûts imprévisibles. Pour les systèmes de qualité production, en particulier dans la finance, la santé ou la logistique, le déterminisme n'est pas une fonctionnalité, c'est une exigence.

Dans cet article, nous explorons comment remplacer le routage probabiliste par l'orchestration par machine à états. En traitant les agents comme des nœuds explicites dans une machine à états finis (FSM), nous obtenons un contrôle total sur les chemins d'exécution, garantis la répétabilité et simplifions le débogage.

Pourquoi les machines à états surpassent le routage LLM

Lorsque vous utilisez un LLM pour router les tâches, vous demandez essentiellement au modèle d'agir comme un arbre de décision. Cela présente plusieurs défauts critiques :

Non-déterminisme : La même entrée peut produire des chemins d'exécution différents lors d'exécutions distinctes.
Surcharge cognitive : Le modèle gaspille des tokens à analyser le contexte dont il n'a pas besoin pour décider de l'étape suivante.
Nuits de cauchemar pour le débogage : Il est difficile de retracer pourquoi une branche spécifique a été empruntée lorsque la décision est enfouie dans une sortie probabiliste.

L'orchestration par machine à états découple la logique de flux de la logique des agents. La machine à états dicte les règles d'engagement, tandis que les agents (qu'il s'agisse de LLM, de scripts déterministes ou d'API externes) effectuent le travail réel. Cette architecture reflète les meilleures pratiques traditionnelles de l'ingénierie logicielle, apportant de la structure aux systèmes basés sur des agents.

Mise en œuvre d'un workflow déterministe

Nous pouvons implémenter une machine à états robuste en utilisant l'enum intégré de Python pour les états et un répartiteur pour les transitions. Voici un exemple pratique d'un système de triage du support client.

import enum
from typing import Dict, Any

class SupportState(enum.Enum):
    INITIAL = "initial"
    TICKET_CREATED = "ticket_created"
    ESCALATED = "escalated"
    RESOLVED = "resolved"

class SupportOrchestrator:
    def __init__(self):
        self.state = SupportState.INITIAL
        self.context: Dict[str, Any] = {}

    def handle_request(self, request: str) -> str:
        # Étape 1 : Déterminer l'intention en utilisant un classificateur léger ou la correspondance de mots-clés
        # Ceci est déterministe, contrairement à un appel LLM
        if "urgent" in request.lower():
            self.state = SupportState.ESCALATED
            return self.escalate_process()
        elif "refund" in request.lower():
            self.state = SupportState.TICKET_CREATED
            return self.create_ticket_process()
        else:
            self.state = SupportState.RESOLVED
            return self.resolve_process()

    def escalate_process(self) -> str:
        # Logique pour escalader vers un agent humain
        return "Escalade vers l'équipe de support senior."

    def create_ticket_process(self) -> str:
        # Logique pour créer une entrée dans la base de données
        return "Ticket de remboursement créé."

    def resolve_process(self) -> str:
        return "Demande résolue automatiquement."

Intégration des LLM en tant que nœuds d'état

Les machines à états n'éliminent pas le besoin de LLM ; elles les contraignent simplement. Un LLM peut être utilisé dans un état spécifique pour générer une réponse ou extraire des entités, mais la transition vers l'état suivant est gouvernée par le code, et non par le modèle.

Par exemple, après l'état ticket_created, vous pourriez déclencher un LLM pour rédiger une réponse. Cependant, la décision de passer à RESOLVED ou ESCALATED devrait être basée sur des critères explicites (par exemple, un score d'analyse de sentiment < -0,5) plutôt que de demander au LLM « Que pensez-vous qu'il devrait se passer ensuite ? »

Conclusion

La construction de workflows multi-agents déterministes nécessite un changement d'état d'esprit. Au lieu de laisser l'IA décider du flux, nous définissons le flux et laissons l'IA exécuter des tâches spécifiques au sein de ce flux. En tirant parti de l'orchestration par machine à états, les développeurs peuvent construire des systèmes qui sont non seulement plus fiables et économiques, mais aussi plus faciles à auditer et à maintenir. À l'ère de l'IA de qualité industrielle, le déterminisme est la fondation de la confiance.