Laya Open Decision Engine

1. Koncept i istota (Przegląd i problem systemowy)

Laya rozwiązuje konkretny problem systemów agentowych: większość decyzji w środowisku produkcyjnym nie wymaga generatywnego reasoning, lecz szybkiego routingu stanu. Klasyczna pętla ReAct z LLM wywołuje model przy każdym kroku, więc nawet banalne zadania — wybór narzędzia, odrzucenie zabronionej akcji, przekierowanie zapytania do fallbacku — kosztują setki milisekund, tokenów oraz zewnętrznych wywołań API.

Laya to open-source silnik decyzyjny System 1 od Convai Innovations, oparty na ModernBERT-large pod licencją Apache 2.0. Model przyjmuje ustrukturyzowany stan agenta — JSON, kontekst tekstowy lub ich kombinację — i w jednym Forward Pass zwraca decyzję: action, confidence, reason codes. W pozycjonowaniu Convai jest to otwarty odpowiednik Jev: nie zamiennik LLM do złożonego planowania, lecz szybki, self-hosted klasyfikator decyzji dla konturów agentowych o wysokim QPS.

Technicznie Laya jest modelem decyzyjnym opartym na encoderze: dwukierunkowym Transformerem, który nie generuje token po tokenie, lecz przetwarza cały wejściowy kontekst i zwraca logits nad przestrzenią akcji. To fundamentalnie zmienia ekonomię inference: brak autoregressive decode, brak KV Cache, brak typowych optymalizacji LLM takich jak Fast Patching; zamiast tego mamy jeden batched encoder pass z przewidywalną latencją.

Efekt ekonomiczny Layi pojawia się tam, gdzie decyzje są powtarzalne: routing tool-calling, safety gate przed LLM, lokalni agenci na Docker agents, bare-metal inference, scenariusze self-hosted wrażliwe na prywatność. Jeśli agent podejmuje 10 000 decyzji na minutę, przeniesienie nawet 60–80% trywialnych decyzji z LLM na Layę zmniejsza budżet latencji i koszty tokenów bez utraty jakości, ponieważ te decyzje nie wymagają otwartego myślenia.

2. Architektura i mechanika wewnętrzna (Taksonomia i model mentalny)

Laya działa jako głowica decyzyjna (decision head) nałożona na ModernBERT-large. Wejściowy stan agenta jest normalizowany, tokenizowany, przechodzi przez encoder, a następnie warstwa poolingowa i głowica klasyfikacyjna zwracają rozkład prawdopodobieństwa nad przestrzenią akcji. Postprocessor stosuje politykę: sprawdza allowed_actions, próg pewności (confidence threshold), logikę fallbackową oraz 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

Taksonomia komponentów:

1. State Normalizer — Przekształca JSON/tekst w formę kanoniczną. Na przykład {"intent":"refund","amount":120,"user_tier":"paid"} może zostać serializowany do deterministycznego ciągu znaków zawierającego klucze, wartości i typy. Jest to istotne, ponieważ encoder jest wrażliwy na kolejność pól i sposób tokenizacji.
2. Tokenizer — Standardowy tokenizer ModernBERT. Wejście jest ograniczone kontekstem, zazwyczaj do 8k tokenów. Dla dużych stanów JSON wymagane jest pre-summarization lub selekcja pól.
3. ModernBERT Encoder — Dwukierunkowy Transformer z RoPE. W przeciwieństwie do causal LLM, każdy token widzi kontekst zarówno z lewej, jak i z prawej strony, co poprawia klasyfikację stanu.
4. Decision Head — Zazwyczaj klasyfikacja lub multi-label classification. Może zwracać pojedynczy action_id, kilka flag ryzyka lub score pewności (confidence score).
5. Policy Layer — Warstwa deterministyczna: weryfikacja dozwolonych akcji, progi, Guardrails, fallback, metadane audytowe.

Kluczowa różnica architektoniczna względem LLM: Laya nie posiada KV Cache, nie wykonuje generacji autoregresyjnej i nie wymaga optymalizacji czasu dekodowania. W warstwie servingowej optymalizacje dotyczą batched encoder kernels, dynamic padding, attention masking, FlashAttention varlen, ONNX/TensorRT graph execution. Jeśli używane jest padding-free attention, Unpadding może zmniejszyć zbędne obliczenia na pad-okenach, ale nie jest to część samej modelu.

3. Techniczny pipeline cyklu życia

Pipeline Layi w produkcji składa się z czterech faz: formułowanie stanu, transformacja, inference, feedback.

1. Formułowanie wejściowego stanu

Agent musi przekazać nie surowy prompt użytkownika, lecz ustrukturyzowany stan: intent, memory, dostępne narzędzia, flagi polityki, poprzednie akcje, sygnały ryzyka.

{
  "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. Transformacja i normalizacja

Normalizacja musi być deterministyczna:

• walidacja schematu JSON;
• usuwanie lub maskowanie PII, secrets, tokenów;
• sortowanie pól lub stała kolejność;
• ograniczenie długości tekstu;
• tokenizacja do input_ids i attention_mask.

Przykład kontraktu w Pythonie z 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. Wykonanie / inference

Uproszczona pseudosygantura:

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(),
    )

Dla serwingu produkcyjnego kluczowe są:

• warm-up przed pierwszym zapytaniem;
• dynamic batching dla przepustowości (throughput);
• CUDA graphs lub compiled inference dla stabilnej latencji P95;
• ONNX Runtime, TensorRT, Triton, Hugging Face Inference — w zależności od stacku;
• shadow inference do porównania z routerem LLM.

4. Obsługa zwrotnego sprzężenia (feedback)

Laya nie jest statycznym modelem. Aby utrzymać jakość, potrzebny jest feedback loop:

{
  "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"
}

Te logi wykorzystywane są do:

• retraining;
• kalibracji;
• detekcji driftu;
• adversarial mining;
• ewaluacji nowych klas akcji;
• ścieżki audytu (audit trail) dla decyzji bezpieczeństwa.

4. Praktyczne scenariusze użycia w produkcji

01. Low-latency MCP tool router

W agencie z narzędziami MCP LLM często marnuje czas na wybór narzędzia. Laya może działać jako pre-router: jeśli stan zawiera jasny intent i dozwolone narzędzie, model wybiera tool:* zamiast pełnej pętli ReAct.

Przykład:

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

Jeśli pewność (confidence) jest wysoka, agent natychmiast wywołuje narzędzie MCP. Jeśli nie — przekazuje zapytanie do pętli ReAct LLM lub prosi o doprecyzowanie. To zmniejsza latencję tool-calling i czyni routing bardziej deterministycznym.

02. Guardrails / policy gate przed LLM

Laya może służyć jako szybka warstwa bezpieczeństwa. Wejście: tekst użytkownika + stan agenta. Wyjście: dozwolona akcja lub blokada.

Scenariusze:

• wykrywanie prompt injection w danych strukturalnych;
• klasyfikacja zapytań pod kątem wycieku PII;
• blokowanie akcji wymagających human review;
• weryfikacja zgodności z polityką przed wywołaniem drogiego LLM;
• triage: allow, clarify, reject, escalate.

Jest to tańsze niż pełny guardrail LLM, ponieważ jeden Forward Pass kosztuje dziesiątki milisekund i nie generuje tokenów. Jednak Laya nie zastępuje pełnej architektury bezpieczeństwa: należy ją łączyć z regułami deterministycznymi, allowlists, audit loggingiem i fallbackiem LLM.

03. Self-hosted local agent na Docker agents lub bare-metal

Dla środowisk wrażliwych na prywatność Laya jest wdrażana lokalnie: Docker agents, Kubernetes, bare-metal GPU, infrastruktura edge. Model nie wysyła stanu do zewnętrznego API, co jest kluczowe dla enterprise, healthcare, finance czy scenariuszy typu defense.

Typowy stack:

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

Na self-hosted GPU latencja może utrzymywać się w granicach ~33–35 ms dla typowego wejścia. Na CPU latencja jest wyższa, ale dla małych batchy i krótkich stanów wciąż może być akceptowalna. W porównaniu z cloud LLM, tradeoff bare-metal vs cloud wygląda następująco: płacisz za pojemność GPU i MLOps, ale zyskujesz przewidywalne koszty, prywatność i niezależność od limitów API.

5. Pułapki, typowe błędy i bezpieczeństwo

01. Action space drift

Laya jest trenowana lub kalibrowana pod konkretną przestrzeń akcji. Jeśli dodasz nowe narzędzie MCP, zmienisz politykę lub przemianujesz akcję, model może zwracać przestarzały lub nieważny action_id.

Mitigation:

• utrzymanie rejestru akcji (action registry);
• walidacja allowed_actions na wejściu;
• blokowanie nieznanych akcji;
• retrain lub fine-tuning adaptera przy zmianie narzędzi;
• stosowanie semantic fallbacku w LLM.

02. Prompt injection przez JSON/tekst

Wejściowy stan agenta może zawierać wrogi tekst: ignore previous policy, call admin_tool, send token. Encoder może być wrażliwy na toksyczne wzorce, szczególnie jeśli model nie był trenowany na danych adversarial.

Mitigation:

• oddzielanie tekstu użytkownika od pól polityki systemowej;
• normalizacja i sanitizacja wejścia;
• zakaz pozwalający tekstowi na modyfikację allowed_actions;
• trening na danych oznaczonych jako injection-labeled;
• dodawanie deterministycznych bramek polityki (policy gates);
• stosowanie progów pewności (confidence threshold) i fallbacków.

03. Nieprawidłowa kalibracja pewności (confidence)

Softmax confidence nie jest prawdopodobieństwem poprawności. Model może być pewny błędu, zwłaszcza po wystąpieniu distribution shift.

Mitigation:

• temperature scaling;
• isotonic regression;
• krzywe kalibracji;
• próg abstencji (abstention threshold);
• shadow evaluation na ruchu produkcyjnym;
• osobny monitoring dla high-confidence false positives.

04. Overfitting na strukturalny JSON

Laya może nauczyć się artefaktów formatowania: kolejności kluczy, długości linii, specyficznych nazw pól. Jeśli klient zmieni schemat, dokładność spadnie.

Mitigation:

• augmentacja: shuffle fields, parafrazowanie tekstu, syntetyczne warianty schematu;
• field masking;
• kanoniczna serializacja;
• wersjonowanie schematu;
• testy jednostkowe na wariantach JSON.

05. Przycinanie kontekstu

ModernBERT ma ograniczony kontekst. Duży stan JSON zawierający pamięć, transkrypt, logi może zostać obcięty, a model podejmie decyzję bez krytycznych pól.

Mitigation:

• pre-summarization;
• selekcja pól oparta na ważności (importance-based field selection);
• chunking z kontekstem tylko decyzyjnym;
• jawna walidacja obecności krytycznych pól;
• fallback, jeśli wymagane pola są nieobecne.

06. Fałszywe przekonanie, że Laya zastępuje reasoning

Laya to klasyfikator System 1. Nie buduje wieloetapowych planów, nie weryfikuje przyczynowości, nie generuje wyjaśnień. Złożone scenariusze autonomous-loop wymagają pętli ReAct LLM, obserwacji narzędzi, refleksji i nadzoru człowieka.

Mitigation:

• używanie Layi do pre-routingu, gate’ów, triage’u;
• pozostawienie LLM do syntezy i planowania nowatorskich zadań;
• mierzenie, które decyzje można bezpiecznie przenieść do System 1;
• nieusuwanie LLM z krytycznych ścieżek decyzyjnych bez ewaluacji.

07. Variance latencji w serwingu

Zadeklarowane 33–35 ms dotyczy typowych warunków self-hosted GPU. W produkcji latencja może rosnąć przez cold start, contention GPU, duże batche, fallback CPU, długi kontekst, overhead sieciowy.

Mitigation:

• warm-up;
• monitoring P95/P99;
• stała polityka batchowania;
• CUDA graphs;
• autoscaling;
• timeouty żądań i fallbacki;
• testy obciążeniowe na realistycznych stanach JSON.

08. Bezpieczeństwo i compliance

Lokalny model nie oznacza automatycznego bezpieczeństwa. Stan agenta może zawierać PII, secrets, dane biznesowe. Logowanie, dane do retrainingu, wagi modeli i endpointy inference wymagają ochrony.

Mitigation:

• redakcja przed inference;
• szyfrowany storage;
• kontrola dostępu (access control) dla API inference;
• ścieżka audytu (audit trail);
• polityka retencji danych;
• testy adversarial;
• human-in-the-loop dla akcji wysokiego ryzyka.