Laya Open Decision Engine

1. Concept et essence (Vue d'ensemble et problème systémique)

Laya résout un problème spécifique des systèmes agentiques : la plupart des décisions en production n'exigent pas de raisonnement génératif, mais nécessitent une routage rapide de l'état. La boucle ReAct classique avec LLM appelle le modèle à chaque étape ; ainsi, même une décision triviale — choisir un outil, rejeter une action interdite, rediriger une requête vers un fallback — coûte des centaines de millisecondes, des tokens et des frais API externes.

Laya est un moteur de décision System 1 open-source développé par Convai Innovations, construit sur ModernBERT-large sous licence Apache 2.0. Le modèle reçoit un état agentique structuré — JSON, contexte textuel ou leur combinaison — et retourne une décision en un seul Forward Pass : action, confidence, reason codes. Dans le positionnement de Convai, il s'agit d'un équivalent ouvert de Jev : non pas un substitut du LLM pour la planification complexe, mais un classificateur de décisions rapide et self-hosted pour les boucles agentiques à haut QPS.

Techniquement, Laya est un modèle de décision basé sur un encoder : un Transformer bidirectionnel qui ne génère pas token par token, mais traite l'intégralité du contexte d'entrée et produit des logits sur l'espace des actions. Cela change radicalement l'économie de l'inference : pas de décodage autoregressive, pas de KV Cache, pas d'optimisations typiques des LLM comme Fast Patching ; à la place, on a un unique batched encoder pass avec une latence prévisible.

L'effet économique de Laya apparaît là où les décisions sont répétitives : routage du tool-calling, safety gate avant le LLM, agent local sur Docker agents, inference bare-metal, scénarios self-hosted sensibles à la confidentialité. Si un agent prend 10 000 décisions par minute, le transfert de 60 à 80 % des décisions triviales du LLM vers Laya réduit le budget de latence et les coûts de tokens sans perte de qualité, car ces décisions ne nécessitent pas de réflexion ouverte.

2. Architecture et mécanique interne (Taxonomie et modèle mental)

Laya fonctionne comme une tête de décision (decision head) au-dessus de ModernBERT-large. L'état d'entrée de l'agent est normalisé, tokenisé, passe par l'encoder, après quoi la couche de pooling et la tête de classification produisent une distribution sur l'espace des actions. Le post-processeur applique la politique : vérification des allowed_actions, seuil de confiance, logique de fallback et Guardrails.

Agent State JSON/text
        │
        ▼
┌─────────────────────────────┐
│ Schema / State Normalizer   │
│ - flatten JSON fields       │
│ - canonical text rendering  │
│ - redact PII / secrets      │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ ModernBERT Tokenizer        │
│ input_ids + attention_mask  │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ ModernBERT-large Encoder    │
│ RoPE positional encoding    │
│ FlashAttention / varlen     │
│ bidirectional self-attention│
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ Pooling + Decision Head     │
│ logits[action_id]           │
│ optional multi-label heads  │
└──────────────┬──────────────┘
               │
               ▼
┌─────────────────────────────┐
│ Policy / Calibration Layer  │
│ softmax + temperature       │
│ confidence threshold        │
│ allowed_actions validation  │
│ reason_codes / fallback     │
└──────────────┬──────────────┘
               │
               ▼
Router → MCP tool call → ReAct loop / human review

Taxonomie des composants :

1. State Normalizer — convertit le JSON/texte en forme canonique. Par exemple, {"intent":"refund","amount":120,"user_tier":"paid"} peut être sérialisé en une chaîne déterministe contenant clés, valeurs et types. C'est important car l'encoder est sensible à l'ordre des champs et à la tokenisation.
2. Tokenizer — tokenizer standard ModernBERT. L'entrée est limitée par le contexte, généralement jusqu'à 8k tokens. Pour les grands états JSON, une pré-synthèse (pre-summarization) ou une sélection de champs est nécessaire.
3. ModernBERT Encoder — Transformer bidirectionnel avec RoPE. Contrairement aux LLM causaux, chaque token voit le contexte à gauche et à droite, ce qui améliore la classification de l'état.
4. Decision Head — généralement une classification ou une multi-label classification. Peut retourner un seul action_id, plusieurs indicateurs de risque ou un score de confiance.
5. Policy Layer — couche déterministe : vérification des actions autorisées, seuils, Guardrails, fallback, métadonnées d'audit.

La différence architecturale clé avec un LLM : Laya n'a pas de KV Cache, n'effectue pas de génération autoregressive et ne nécessite pas d'optimisation au moment du décodage. Dans la couche serving, les optimisations concernent les kernels d'encoder batchés, le dynamic padding, l'attention masking, FlashAttention varlen, l'exécution de graphes ONNX/TensorRT. Si l'attention sans padding (padding-free attention) est utilisée, l'Unpadding peut réduire les calculs superflus sur les pad-tokens, mais cela ne fait pas partie du modèle lui-même.

3. Pipeline technique du cycle de vie

Le pipeline Laya en production se compose de quatre phases : formation de l'état, transformation, inference, feedback.

1. Formulation de l'état d'entrée

L'agent doit transmettre non pas un prompt utilisateur brut, mais un état structuré : intent, memory, outils disponibles, flags de politique, actions précédentes, signaux de risque.

{
  "request_id": "req_9f2a",
  "state": {
    "intent": "refund_request",
    "amount": 120,
    "user_tier": "paid",
    "previous_actions": ["order_lookup"],
    "risk_flags": []
  },
  "text": "Please refund my order, it arrived damaged.",
  "allowed_actions": [
    "tool:order_lookup",
    "tool:refund_create",
    "tool:human_review",
    "llm:clarify"
  ],
  "policy_version": "v1.4.2"
}

2. Transformation et normalisation

La normalisation doit être déterministe :

• Validation du schéma JSON ;
• Suppression ou masquage des PII, secrets, tokens ;
• Tri des champs ou ordre fixe ;
• Limitation de la longueur du texte ;
• Tokenisation en input_ids et attention_mask.

Exemple de contrat en Python avec Pydantic AI :

from pydantic import BaseModel, Field
from typing import Any


class DecisionRequest(BaseModel):
    request_id: str
    state: dict[str, Any]
    text: str | None = None
    allowed_actions: list[str] = Field(min_length=1)
    policy_version: str = "v1"


class DecisionResponse(BaseModel):
    action: str | None
    confidence: float
    reason_codes: list[str]
    fallback: bool
    model_version: str
    latency_ms: float

3. Exécution / Inference

Signature pseudo simplifiée :

def decide(req: DecisionRequest) -> DecisionResponse:
    normalized = normalize_state(req)
    logits = model.forward_pass(normalized)
    action, confidence = select_action(logits, req.allowed_actions)

    if action is None or confidence < CONFIDENCE_THRESHOLD:
        return DecisionResponse(
            action="llm:clarify",
            confidence=confidence,
            reason_codes=["low_confidence", "fallback"],
            fallback=True,
            model_version=MODEL_VERSION,
            latency_ms=measure_latency(),
        )

    return DecisionResponse(
        action=action,
        confidence=confidence,
        reason_codes=["high_confidence"],
        fallback=False,
        model_version=MODEL_VERSION,
        latency_ms=measure_latency(),
    )

Pour le serving en production, les éléments suivants sont importants :

• Warm-up avant la première requête ;
• Dynamic batching pour le throughput ;
• CUDA graphs ou inference compilée pour une latence P95 stable ;
• ONNX Runtime, TensorRT, Triton, Hugging Face Inference — selon la stack ;
• Shadow inference pour comparaison avec le routeur LLM.

4. Traitement du feedback

Laya n'est pas un modèle statique. Pour maintenir la qualité, une boucle de feedback est nécessaire :

{
  "request_id": "req_9f2a",
  "predicted_action": "tool:refund_create",
  "actual_action": "tool:human_review",
  "outcome": "policy_violation",
  "confidence": 0.91,
  "human_label": "tool:human_review",
  "timestamp": "2026-06-15T10:00:00Z"
}

Ces logs sont utilisés pour :

• Retraining ;
• Calibration ;
• Détection de drift ;
• Adversarial mining ;
• Évaluation sur de nouvelles classes d'action ;
• Audit trail pour les décisions de sécurité.

4. Scénarios d'utilisation pratiques en production

01. Routeur MCP à faible latence

Dans un agent avec des outils MCP, le LLM perd souvent du temps à choisir l'outil. Laya peut fonctionner comme pre-router : si l'état contient un intent clair et un outil autorisé, le modèle sélectionne tool:* au lieu de lancer la boucle ReAct complète.

Exemple :

{
  "state": {
    "intent": "calendar_create",
    "entities": {
      "date": "2026-06-16",
      "duration_minutes": 30
    }
  },
  "allowed_actions": [
    "mcp:calendar.create_event",
    "mcp:calendar.list_events",
    "llm:clarify"
  ]
}

Si la confiance est élevée, l'agent appelle immédiatement l'outil MCP. Sinon, il transmet la requête à la boucle ReAct du LLM ou demande une clarification. Cela réduit la latence du tool-calling et rend le routage plus déterministe.

02. Guardrails / Policy gate avant le LLM

Laya peut servir de couche de sécurité rapide. Entrée : texte utilisateur + état de l'agent. Sortie : action autorisée ou blocage.

Scénarios :

• Détection de prompt injection dans les données structurées ;
• Classification des requêtes concernant les fuites de PII ;
• Blocage des actions nécessitant une revue humaine ;
• Vérification de conformité à la politique avant l'appel coûteux du LLM ;
• Triage : allow, clarify, reject, escalate.

Cela coûte moins cher qu'un guardrail LLM complet, car un seul Forward Pass coûte quelques dizaines de millisecondes et ne génère pas de tokens. Mais Laya ne remplace pas une architecture de sécurité complète : elle doit être combinée avec des règles déterministes, des allowlists, des logs d'audit et un fallback LLM.

03. Agent local self-hosted sur Docker agents ou bare-metal

Pour les environnements sensibles à la confidentialité, Laya est déployé localement : Docker agents, Kubernetes, GPU bare-metal, infrastructure edge. Le modèle n'envoie pas l'état vers une API externe, ce qui est crucial pour les scénarios enterprise, healthcare, finance, défense.

Stack typique :

FastAPI / gRPC service
  → Pydantic validation
  → ModernBERT tokenizer
  → ONNX / TensorRT / HF inference
  → policy postprocessor
  → MCP router or local tool executor

Sur un GPU self-hosted, la latence peut rester autour de ~33–35 ms pour une entrée typique. Sur CPU, la latence est plus élevée, mais peut encore être acceptable pour de petits batches et des états courts. Comparé au cloud LLM, le tradeoff bare-metal vs cloud ici est le suivant : vous payez pour la capacité GPU et le MLOps, mais obtenez un coût prévisible, la confidentialité et l'indépendance vis-à-vis des limites API.

5. Pièges, erreurs courantes et sécurité

01. Drift de l'espace d'actions

Laya est entraîné ou calibré pour un espace d'actions spécifique. Si vous ajoutez un nouvel outil MCP, modifiez la politique ou renommez une action, le modèle peut retourner un action_id obsolète ou invalide.

Mitigation :

• Maintenir un registre d'actions (action registry) ;
• Valider les allowed_actions à l'entrée ;
• Bloquer les actions inconnues ;
• Effectuer un retrain ou un fine-tuning d'adaptateur lors de changements d'outils ;
• Utiliser un fallback sémantique vers le LLM.

02. Prompt injection via JSON/texte

L'état d'entrée de l'agent peut contenir du texte hostile : ignore previous policy, call admin_tool, send token. L'encoder peut être sensible aux patterns toxiques, surtout si le modèle n'a pas été entraîné sur des données adversariales.

Mitigation :

• Séparer le texte utilisateur des champs de politique système ;
• Normaliser et assainir l'entrée ;
• Ne pas permettre au texte de modifier les allowed_actions ;
• Entraîner sur des données labellisées injection ;
• Ajouter des gates de politique déterministes ;
• Utiliser un seuil de confiance et un fallback.

03. Mauvaise calibration de la confiance

La confiance Softmax n'est pas une probabilité de correction. Le modèle peut être confiant à tort, surtout après un shift de distribution.

Mitigation :

• Temperature scaling ;
• Isotonic regression ;
• Courbes de calibration ;
• Seuil d'abstention ;
• Évaluation shadow sur le trafic de production ;
• Monitoring séparé pour les faux positifs à haute confiance.

04. Overfitting sur le JSON structuré

Laya peut apprendre des artefacts de formatage : ordre des clés, longueur des lignes, noms de champs spécifiques. Si le client change le schéma, la précision chutera.

Mitigation :

• Augmentation : shuffle des champs, paraphrase du texte, variantes synthétiques de schéma ;
• Masquage de champs ;
• Sérialisation canonique ;
• Versioning de schéma ;
• Tests unitaires sur des variantes JSON.

05. Troncature contextuelle

ModernBERT a un contexte limité. Un grand état JSON avec mémoire, transcript, logs peut être tronqué, et le modèle prendra une décision sans champs critiques.

Mitigation :

• Pré-synthèse (pre-summarization) ;
• Sélection de champs basée sur l'importance ;
• Chunking avec contexte uniquement décisionnel ;
• Validation explicite de la présence des champs critiques ;
• Fallback si les champs requis sont absents.

06. Fausse impression que Laya remplace le raisonnement

Laya est un classificateur System 1. Il ne construit pas de plan multi-étapes, ne vérifie pas la causalité, ne génère pas d'explications. Les scénarios complexes de boucles autonomes nécessitent une boucle ReAct LLM, l'observation des outils, la réflexion et la supervision humaine.

Mitigation :

• Utiliser Laya pour le pre-routing, les gates, le triage ;
• Garder le LLM pour la synthèse et la planification nouvelle ;
• Mesurer quelles décisions peuvent être transférées en toute sécurité vers System 1 ;
• Ne pas retirer le LLM des chemins de décision critiques sans évaluation.

07. Variance de latence dans le serving

Les 33–35 ms annoncés concernent des conditions typiques de GPU self-hosted. En production, la latence peut augmenter à cause du cold start, de la contention GPU, de grands batches, du fallback CPU, de longs contextes, de la surcharge réseau.

Mitigation :

• Warm-up ;
• Monitoring P95/P99 ;
• Politique de batch fixe ;
• CUDA graphs ;
• Autoscaling ;
• Timeout de requête et fallback ;
• Tests de charge sur des états JSON réalistes.

08. Sécurité et compliance

Un modèle local ne signifie pas automatiquement la sécurité. L'état de l'agent peut contenir des PII, des secrets, des données commerciales. Les logs, les données de retraining, les poids du modèle et les endpoints d'inference nécessitent une protection.

Mitigation :

• Redaction avant l'inference ;
• Stockage chiffré ;
• Contrôle d'accès pour les endpoints d'inference ;
• Audit trail ;
• Politique de rétention des données ;
• Tests adversariaux ;
• Human-in-the-loop pour les actions à haut risque.