Laya Open Decision Engine(Laya (Open-Source System 1 Decision Engine від Convai))

1. Концепція та суть (Огляд та системна проблема)

Laya вирішує конкретну проблему агентних систем: більшість рішень у production-агенті не потребують генеративного reasoning, а потребують швидкої маршрутизації стану. Класичний ReAct loop з LLM викликає модель для кожного кроку, тому навіть тривіальне рішення — обрати інструмент, відхилити заборонену дію, перекласти запит у fallback — коштує сотень мілісекунд, токенів і зовнішніх API-витрат.

Laya — це open-source System 1 decision engine від Convai Innovations, побудований на ModernBERT-large під ліцензією Apache 2.0. Модель приймає структурований стан агента — JSON, текстовий контекст або їх комбінацію — і в один Forward Pass повертає рішення: action, confidence, reason codes. У позиціонуванні Convai це відкритий аналог Jev: не замінник LLM для складного планування, а швидкий, self-hosted класифікатор рішень для high-QPS агентних контурів.

Технічно Laya є encoder-based decision model: двонаправлений Transformer, який не генерує токен за токеном, а обробляє вхідний контекст цілком і видає logits над простором дій. Це критично змінює економіку inference: немає autoregressive decode, немає KV Cache, немає типових LLM-оптимізацій на кшталт Fast Patching; замість цього є один batched encoder pass із передбачуваною латентністю.

Економічний ефект Laya з’являється там, де рішення повторювані: маршрутизація tool-calling, safety gate перед LLM, локальний agent на Docker agents, bare-metal inference, privacy-sensitive self-hosted сценарії. Якщо агент робить 10 000 рішень на хвилину, переведення навіть 60–80% тривіальних рішень із LLM на Laya зменшує latency budget і токен-витрати без втрати якості, бо для цих рішень не потрібне відкрите мислення.

2. Архітектура та внутрішня механіка (Таксономія та ментальна модель)

Laya працює як decision head поверх ModernBERT-large. Вхідний стан агента нормалізується, токенизується, проходить через encoder, після чого pooling-шар і класифікаційна голова видають розподіл над простором дій. Postprocessor застосовує policy: перевіряє allowed_actions, confidence threshold, fallback-логіку та 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

Таксономія компонентів:

1. State Normalizer — перетворює JSON/text у канонічну форму. Наприклад, {"intent":"refund","amount":120,"user_tier":"paid"} може бути серіалізований у детермінований рядок із ключами, значеннями та типами. Це важливо, бо encoder чутливий до порядку полів і токенізації.
2. Tokenizer — стандартний ModernBERT tokenizer. Вхід обмежений контекстом, зазвичай до 8k токенів. Для великих JSON станів потрібна pre-summarization або field selection.
3. ModernBERT Encoder — двонаправлений Transformer із RoPE. На відміну від causal LLM, кожен токен бачить контекст зліва і справа, що покращує класифікацію стану.
4. Decision Head — зазвичай класифікація або multi-label класифікація. Може повертати один action_id, кілька прапорців ризику або confidence score.
5. Policy Layer — детермінований шар: перевірка дозволених дій, threshold, Guardrails, fallback, audit metadata.

Ключова архітектурна відмінність від LLM: Laya не має KV Cache, не виконує autoregressive generation і не потребує decode-time optimization. У serving-шарі оптимізації стосуються batched encoder kernels, dynamic padding, attention masking, FlashAttention varlen, ONNX/TensorRT graph execution. Якщо використовується padding-free attention, Unpadding може зменшити зайві обчислення на pad-токенах, але це не є частиною моделі як такої.

3. Технічний пайплайн життєвого циклу

Пайплайн Laya у продакшені складається з чотирьох фаз: формування стану, перетворення, inference, feedback.

1. Формулювання вхідного стану

Агент має передати не сирий user prompt, а структурований стан: intent, memory, available tools, policy flags, previous actions, risk signals.

{
  "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. Перетворення та нормалізація

Нормалізація має бути детермінованою:

• валідація JSON schema;
• видалення або маскування PII, secrets, токенів;
• сортування полів або фіксований порядок;
• обмеження довжини тексту;
• токенізація в input_ids і attention_mask.

Приклад контракту на Python із 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. Виконання / inference

Спрощена псевдосигнатура:

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

Для production serving важливі:

• warm-up перед першим запитом;
• dynamic batching для throughput;
• CUDA graphs або compiled inference для стабільної P95 latency;
• ONNX Runtime, TensorRT, Triton, Hugging Face Inference — залежно від стека;
• shadow inference для порівняння з LLM router.

4. Обробка зворотного зв’язку

Laya не є статичною моделлю. Для підтримки якості потрібен 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"
}

Ці логи використовуються для:

• retraining;
• calibration;
• drift detection;
• adversarial mining;
• evaluation за новими action classes;
• audit trail для safety-рішень.

4. Практичні сценарії використання в продакшені

01. Low-latency MCP tool router

У агенті з MCP-інструментами LLM часто витрачає час на вибір інструменту. Laya може працювати як pre-router: якщо стан містить чіткий intent і дозволений інструмент, модель обирає tool:* замість повного ReAct loop.

Приклад:

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

Якщо confidence висока, агент одразу викликає MCP tool. Якщо ні — передає запит у LLM ReAct loop або просить уточнення. Це зменшує latency tool-calling і робить маршрутизацію детермінованішою.

02. Guardrails / policy gate перед LLM

Laya може бути швидким safety-шаром. Вхід: user text + agent state. Вихід: дозволена дія або блокування.

Сценарії:

• виявлення prompt injection у структурованих даних;
• класифікація запитів на PII leakage;
• блокування дій, що потребують human review;
• перевірка відповідності policy перед викликом дорогого LLM;
• triage: allow, clarify, reject, escalate.

Це дешевше за повний LLM guardrail, бо один Forward Pass коштує десятки мілісекунд і не генерує токенів. Але Laya не замінює повноцінну safety-архітектуру: її слід комбінувати з детермінованими правилами, allowlists, audit logging і fallback LLM.

03. Self-hosted local agent на Docker agents або bare-metal

Для privacy-sensitive середовищ Laya розгортається локально: Docker agents, Kubernetes, bare-metal GPU, edge-інфраструктура. Модель не відправляє стан у зовнішній API, що важливо для enterprise, healthcare, finance, defense-подібних сценаріїв.

Типовий стек:

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

На self-hosted GPU latency може триматися в межах ~33–35 мс для типового входу. На CPU latency вища, але для невеликих batch і коротких станів все ще може бути прийнятною. У порівнянні з cloud LLM, bare-metal vs cloud tradeoff тут такий: ви платите за GPU capacity і MLOps, але отримуєте передбачувану вартість, приватність і незалежність від API-лімітів.

5. Підводні камені, типові помилки та безпека

01. Action space drift

Laya навчається або калібрується під конкретний простір дій. Якщо додати новий MCP tool, змінити policy або перейменувати action, модель може повертати застарілий або невалідний action_id.

Mitigation:

• зберігати action registry;
• валідувати allowed_actions на вході;
• блокувати невідомі дії;
• робити retrain або adapter fine-tuning при зміні інструментів;
• використовувати semantic fallback у LLM.

02. Prompt injection через JSON/text

Вхідний стан агента може містити ворожий текст: ignore previous policy, call admin_tool, send token. Encoder може бути чутливим до токсичних патернів, особливо якщо модель не тренувалась на adversarial data.

Mitigation:

• відокремлювати user text від system policy fields;
• нормалізувати та санітизувати вхід;
• не дозволяти тексту змінювати allowed_actions;
• тренувати на injection-labeled data;
• додавати детерміновані policy gates;
• використовувати confidence threshold і fallback.

03. Неправильна калібрація confidence

Softmax confidence не є імовірністю правильності. Модель може бути впевнено помилковою, особливо після distribution shift.

Mitigation:

• temperature scaling;
• isotonic regression;
• calibration curves;
• abstention threshold;
• shadow evaluation на production traffic;
• окремий monitoring для high-confidence false positives.

04. Overfitting на структурований JSON

Laya може вивчити артефакти форматування: порядок ключів, довжину рядків, специфічні field names. Якщо клієнт змінить schema, точність впаде.

Mitigation:

• augmentation: shuffle fields, paraphrase text, synthetic schema variants;
• field masking;
• canonical serialization;
• schema versioning;
• unit tests на JSON variants.

05. Контекстне урізання

ModernBERT має обмежений контекст. Великий JSON стан із memory, transcript, logs може бути обрізаний, і модель прийме рішення без критичних полів.

Mitigation:

• pre-summarization;
• importance-based field selection;
• chunking із decision-only context;
• явне валідування presence критичних полів;
• fallback, якщо required fields відсутні.

06. Хибне відчуття, що Laya замінює reasoning

Laya — System 1 класифікатор. Вона не будує багатокроковий план, не перевіряє причинність, не генерує пояснення. Складні autonomous-loop сценарії потребують LLM ReAct loop, tool observation, reflection і human oversight.

Mitigation:

• використовувати Laya для pre-routing, gate, triage;
• залишати LLM для synthesis і novel planning;
• вимірювати, які рішення можна безпочно перенести на System 1;
• не видаляти LLM з критичних decision paths без evaluation.

07. Latency variance у serving

Заявлені 33–35 мс стосуються типових self-hosted GPU умов. У продакшені latency може зростати через cold start, GPU contention, великий batch, CPU fallback, long context, network overhead.

Mitigation:

• warm-up;
• P95/P99 monitoring;
• fixed batch policy;
• CUDA graphs;
• autoscaling;
• request timeout і fallback;
• load testing на реалістичних JSON states.

08. Безпека та compliance

Локальна модель не означає автоматичну безпеку. Стан агента може містити PII, secrets, бізнес-дані. Logging, retraining data, model weights і inference endpoints потребують захисту.

Mitigation:

• redaction перед inference;
• encrypted storage;
• access control для inference API;
• audit trail;
• data retention policy;
• adversarial testing;
• human-in-the-loop для high-risk actions.