Jev System Architect

Was macht Jev System Architect?

Zweck

Verwenden Sie diesen Skill, um Folgendes zu bestimmen:

1. Ob Jev überhaupt in ein System gehört
2. Wo genau die Jev-Grenze verlaufen sollte
3. Welche Urteile zu Choice-, Score- oder Noul-Fragen werden sollten
4. Welchen Zustand jedes Urteil sehen sollte
5. Welche Fragen zusammen ausgeführt werden sollten
6. Wie gewöhnlicher Code die Ergebnisse zusammensetzen sollte
7. Wie Unsicherheit das Systemverhalten verändern sollte
8. Wie die Integration vor dem Produktionseinsatz evaluiert werden sollte

Dies ist in erster Linie ein Skill für Architektur und Zerlegung.

Für genaue SDK-Syntax, Request/Response-Felder, Modelle, Limits oder versionsspezifisches API-Verhalten lesen Sie die aktuelle TypeSafe-Dokumentation und verwenden Sie, wenn verfügbar, den offiziellen TypeSafe-Agenten-Skill.

Erfinden Sie keine API-Felder.

---

Zentrales mentales Modell

Jev ist nicht die Anwendung.

Jev ist nicht die Workflow-Engine.

Jev ist kein autonomer Agent.

Die bevorzugte Architektur ist:

ANWENDUNGSZUSTAND
      ↓
eingegrenzte semantische Fragen
      ↓
     JEV
      ↓
getippte Urteile + Wahrscheinlichkeiten
      ↓
DETERMINISTISCHER ANWENDUNGSCODE
      ↓
weiterleiten / bewerten / verifizieren / fragen / eskalieren / ausführen

Das Modell liefert programmierbare Urteilsfähigkeit.

Code besitzt:

• Kontrollfluss
• Berechtigungen
• Berechnungen
• deterministische Regeln
• Persistenz
• Transaktionen
• Nebeneffekte
• Werkzeugausführung
• Autorisierung
• Richtliniendurchsetzung

Verwenden Sie Jev nur dort, wo normale Software semantisches Verständnis von unstrukturierten oder mehrdeutigen Informationen benötigt.

---

Auslösebedingungen

Ziehen Sie Jev in Betracht, wenn das System eine Grenze enthält, die wie folgt geformt ist:

unstrukturierte oder kontextbezogene Informationen
                ↓
     ein eingegrenztes Urteil ist erforderlich
                ↓
 Software benötigt einen getippten Wert, um fortzufahren

Starke Kandidaten sind:

• Absichtsklassifizierung
• semantisches Routing
• Moderationsentscheidungen
• Dokumentklassifizierung
• Beweisverifikation
• Zitierprüfung
• semantische Schutzvorrichtungen
• Risikosignale
• Nachrichteninterpretation
• Kandidatenauswahl
• Ranking-Dimensionen
• Relevanzurteile
• Stimmung oder Dringlichkeit
• Benutzeranforderungsinterpretation
• Werkzeug-/Funktionsauswahl
• Extraktion aus einem bekannten Kandidatensatz
• RAG-Passagenfilterung
• Workflow-Triage
• Qualitätsurteile
• Richtlinie-zu-Fall-Vergleich
• unscharfer Abgleich
• Entitätsabgleich
• Eskalationsentscheidungen

Überprüfen Sie den Code auch auf Symptome wie:

LLM → Prosa → Parser → JSON → Validierung → Wiederholung

oder:

großer Regex-Baum
riesiger if/else semantischer Klassifizierer
aufforderungsbasierter Klassifizierer, der beliebiges JSON zurückgibt
Agentenschleife, die nur verwendet wird, um eine eingegrenzte Entscheidung zu treffen
teures Reasoning-Modell, das für eine triviale Klassifizierung verwendet wird

Dies sind potenzielle Jev-Einfügungspunkte.

---

Jev nicht standardmäßig verwenden

Bevorzugen Sie gewöhnlichen Code für:

• Arithmetik
• exakte Daten, die bereits strukturell dargestellt sind
• Datenbanksuchen
• exakte Zeichenkettenvergleiche
• Berechtigungen
• Autorisierung
• Schema-Validierung
• deterministische Geschäftsregeln
• bekannte Transformationen
• Sortieren bekannter Zahlen
• kryptografische Operationen
• exakte Parser, die das Problem bereits zuverlässig lösen

Bevorzugen Sie ein generatives Modell, wenn die erforderliche Ausgabe grundsätzlich offen ist:

• Schreiben
• Zusammenfassung
• Erklärung
• Brainstorming
• Codegenerierung
• Langformsynthese
• offene Recherche
• mehrschrittiges Reasoning

Jev kann diese Systeme unterstützen, indem es begrenzte Entscheidungen um sie herum trifft, sollte aber nicht in eine generative Rolle gezwungen werden.

---

Schritt 1 – Finden Sie die Urteilsgrenzen

Untersuchen Sie den Workflow vom Input zum Ergebnis.

Markieren Sie jeden Punkt, an dem die Software im Wesentlichen fragt:

„Ich habe Informationen, aber ich muss verstehen, was sie bedeuten, bevor ich weiß, welchen deterministischen Pfad ich nehmen muss.“

Notieren Sie für jede Kandidatengrenze:

INPUT-ZUSTAND: Welche Informationen existieren?

URTEIL: Welche semantische Bestimmung ist erforderlich?

AUSGABE: Welcher begrenzte Wert würde dem Code erlauben, fortzufahren?

AKTION: Was wird der Code mit der Antwort tun?

EINSATZ: Was passiert, wenn das Urteil falsch ist?

Implementieren Sie Jev nicht sofort.

Bestimmen Sie zunächst, ob deterministischer Code das Problem zuverlässiger lösen kann.

---

Schritt 2 – Wenden Sie den Jev-Eignungstest an

Ein Urteil ist ein starker Jev-Kandidat, wenn die meisten dieser Punkte zutreffen:

• Die Eingabe enthält natürliche Sprache oder Kontextdaten.
• Die erforderliche Ausgabe kann begrenzt werden.
• Die Software benötigt die Antwort programmatisch.
• Ein sachkundiger Mensch könnte das Urteil schnell fällen.
• Das Urteil kann explizit beschrieben werden.
• Unsicherheit ist nützliche Information.
• Das Ergebnis kann anhand von Beispielen oder Labels getestet werden.
• Code kann die Aktion nach dem Urteil übernehmen.

Seien Sie skeptisch, wenn die Aufgabe erfordert:

• tiefes Nachdenken
• lange Argumentationsketten
• viele abhängige Zwischenschlussfolgerungen
• offene Generierung
• autonome Planung

Zerlegen Sie zuerst.

---

Schritt 3 – Machen Sie Fragen atomar

Eine Jev-Frage sollte ein kohärentes Urteil darstellen.

SCHLECHT:

Analysieren Sie diesen Kunden und bestimmen Sie, ob wir ihn zurückerstatten sollten, wie wütend er ist, ob Betrug wahrscheinlich ist und welche Abteilung den Fall bearbeiten soll.

BESSER:

• topic → Choice
• refund_requested → Noul
• fraud_signal → Noul
• frustration → Score

Setzen Sie diese Antworten dann im Code zusammen.

Das Ziel ist:

komplexes Verhalten = viele kleine Urteile + deterministische Zusammensetzung

Verstecken Sie keine Anwendungsrichtlinie in einer riesigen semantischen Frage, wenn Code diese Richtlinie explizit ausdrücken könnte.

---

Schritt 4 – Wählen Sie das richtige Primitive

Choice

Verwenden Sie, wenn genau eine Antwort aus einer definierten Menge ausgewählt werden soll.

Form: Welche eine?

Beispiele:

• billing | technical | sales | account
• refund | rebook | information
• python | javascript | rust | other

Fügen Sie ein „other“-, „unknown“- oder „none“-Ergebnis hinzu, wenn die angegebenen Optionen die Eingabe möglicherweise nicht abdecken.

Noul

Verwenden Sie für eine Aussage, deren Wahrscheinlichkeit, wahr zu sein, nützlich ist.

Form: Ist das wahr?

Beispiele:

• Fordert der Kunde eine Rückerstattung an?
• Beantwortet dieser Abschnitt die Frage des Benutzers?
• Fordert diese Nachricht eine Anmeldeinformation an?
• Gibt der Lebenslauf professionelle Python-Erfahrung an?

Interpretieren Sie die Ausgabe als Wahrscheinlichkeit von Ja.

Interpretieren Sie ~0,5 nicht als „mittlere Intensität“.

Es bedeutet, dass Ja/Nein etwa gleich plausibel sind.

Score

Verwenden Sie, wenn das Urteil auf einer geordneten Dimension existiert.

Form: Wo auf diesem definierten Spektrum fällt der Zustand?

Beispiele:

• ruhig / besorgt / sehr frustriert
• irrelevant / teilweise relevant / stark relevant / direkte Antwort

Jede Stufe sollte einen konkreten semantischen Zustand beschreiben.

Vermeiden Sie undefinierte Labels wie schlecht / okay / gut / großartig, es sei denn, ihre Bedeutung ist explizit definiert.

---

Schritt 5 – Gestalten Sie den Zustand bewusst

Senden Sie den kleinsten Zustand, der die für die Fragen erforderlichen Beweise enthält.

Bevorzugen Sie strukturierten Zustand:

{
  "ticket": {
    "message": "...",
    "sender": {}
  },
  "customer": {
    "plan": "...",
    "orders": []
  },
  "policy": {
    "refund_policy": "..."
  }
}

anstatt einen riesigen Prosa-Block.

Prinzipien:

• relevant > umfassend
• strukturiert > abgeflacht
• beobachtete Fakten > angenommenes Modellwissen
• aktuelle Informationen > veraltetes eingebettetes Wissen

Halten Sie beobachtete Fakten von abgeleiteten Urteilen unterscheidbar.

Wenn Fragen bestimmte Zustandsfelder betreffen, verweisen Sie explizit auf diese Felder.

---

Schritt 6 – Verteilen Sie unabhängige Fragen

Wenn mehrere Fragen aus demselben vorhandenen Zustand beantwortet werden können, stellen Sie sie zusammen.

                    ┌── topic
                    ├── urgency
STATE ── JEV ───────┼── refund_requested
                    ├── frustration
                    └── fraud_signal

Erzeugen Sie keine unnötigen seriellen Aufrufe wie:

Jev → Antwort → Jev → Antwort → Jev → Antwort

wenn alle drei Fragen aus dem ursprünglichen Zustand hätten bewertet werden können.

Stellen Sie spekulative Fragen, wenn sie billig sind und später nützlich sein könnten.

Beispiel: category, bug_severity, reproduction_quality, refund_requested, frustration

Wenn category = billing, ignoriert Code einfach die bugspezifischen Antworten.

---

Schritt 7 – Verwenden Sie mehrere Jev-Stufen nur für echte Abhängigkeiten

Eine zweite Jev-Anfrage ist gerechtfertigt, wenn die erste Antwort erforderlich ist, um:

• neue Beweise zu beschaffen
• neuen Zustand zu konstruieren
• den nächsten Kandidatensatz auszuwählen
• zu bestimmen, welche Fragen sinnvoll gestellt werden können
• eine Hierarchie zu durchlaufen
• Dokumente abzurufen, die für das nächste Urteil erforderlich sind

Beispiel:

SCHRITT 1  Welche Produktfamilie?
   ↓
Code ruft Produkte in dieser Familie ab
   ↓
SCHRITT 2  Welches genaue Produkt passt am besten?

Serialisieren Sie Fragen nicht nur, weil der Workflow konzeptionell mehrere Schritte enthält.

---

Schritt 8 – Halten Sie die Zusammensetzung im Code

Jev produziert semantische Signale.

Code entscheidet, was diese Signale operativ bedeuten.

Beispiel:

topic = billing
refund_requested = 0.94
frustration = high

Anwendungscode kann entscheiden:

if topic == billing:
    route_to_billing()

if refund_requested > REFUND_FLAG_THRESHOLD:
    add_refund_flag()

if frustration > PRIORITY_THRESHOLD:
    increase_priority()

Geschäftslogik sollte überprüfbar bleiben.

Fragen Sie Jev nicht „Was soll unsere gesamte Anwendung tun?“, wenn die Antwort stattdessen aus kleineren Urteilen konstruiert werden kann.

---

Schritt 9 – Behandeln Sie Unsicherheit als erstklassiges Signal

Behandeln Sie getippte Ausgabe niemals als gleichbedeutend mit Wahrheit.

Getippte Ausgabe bedeutet, dass die Schnittstelle eingeschränkt ist.

Es bedeutet nicht, dass das semantische Urteil nicht falsch sein kann.

Überprüfen Sie bei Choice und Score die Wahrscheinlichkeiten und das Vertrauen.

Überprüfen Sie bei Noul direkt die Ja-Wahrscheinlichkeit.

Entwerfen Sie Verhalten wie:

• HOHE SICHERHEIT → automatischer Pfad
• MITTLERE SICHERHEIT → Bestätigung anfordern / mehr Beweise sammeln / stärkeres Modell / zur Überprüfung markieren
• NIEDRIGE SICHERHEIT → nicht raten / eskalieren

Schwellenwerte sind Anwendungsrichtlinie.

Sie müssen die Kosten von Fehlalarmen/falsch negativen Ergebnissen, Umkehrbarkeit, Benutzer-/Finanz-/Sicherheits-/Regulierungsauswirkungen widerspiegeln.

Ein aus einem Beispiel kopierter Schwellenwert ist kein Beleg dafür, dass er für dieses System angemessen ist.

---

Schritt 10 – Passen Sie Vertrauensschwellen an das Risiko an

Verwenden Sie keinen universellen Vertrauensschwellenwert.

Beispiel:

• help_article anzeigen — geringe Konsequenzen
• support_ticket weiterleiten — moderate Konsequenzen
• subscription kündigen — höhere Konsequenzen
• Geld bewegen — sehr hohe Konsequenzen

Das semantische Urteil kann identisch sein, während die erforderliche Sicherheit und der Bestätigungspfad unterschiedlich sind.

Bei folgenreichen Aktionen sollte Jev normalerweise eine kontrollierte Entscheidungsgrenze informieren, anstatt den Nebeneffekt unabhängig zu autorisieren.

---

Schritt 11 – Entwerfen Sie die Bewertung vor der Automatisierung

Bevor Sie eine Jev-Grenze produktiv einsetzen, identifizieren Sie repräsentative Fälle.

Enthalten Sie: einfache Positive, einfache Negative, mehrdeutige Fälle, Fälle mit fehlenden Beweisen, Grenzfälle, adversariale Fälle, seltene aber kostspielige Fehler.

Dokumentieren Sie: Zustand, Frage, erwartetes Verhalten, Jev-Antwort, Wahrscheinlichkeiten/Vertrauen, Anwendungsaktion, Ground-Truth-Ergebnis, wenn verfügbar.

Bewerten Sie das Systemverhalten, nicht nur, ob das oberste Label vernünftig aussah.

Messen Sie bei Systemen mit Schwellenwerten das Verhalten bei mehreren Schwellenwerten.

Messen Sie insbesondere: Abdeckung / Automatisierungsrate, Fehlalarmrate, Falsch-negativ-Rate, Menschliche-Überprüfungsrate, Fehlerkosten, Latenz, Kosten.

Stimmen Sie Schwellenwerte mit tatsächlichen Zieldomänendaten ab.

---

Schritt 12 – Zentralisieren Sie die Jev-Richtlinie

Halten Sie Jev-Fragen, Kriterien, Gewichte und Schwellenwertkonstanten leicht auffindbar und überprüfbar.

Bevorzugen Sie eine Struktur wie:

ai/
  jev/
    questions.*
    thresholds.*
    evaluation/
    client.*

oder die entsprechende für das Projekt geeignete Struktur.

Verteilen Sie keine semantische Richtlinie über Dutzende von Route-Handlern.

Menschliche Prüfer sollten in der Lage sein, Folgendes zu überprüfen:

• Was urteilt Jev?
• Welche Definitionen haben wir ihm gegeben?
• Welche Schwellenwerte verursachen Aktionen?
• Welche Aktionen sind umkehrbar?
• Was passiert, wenn das Vertrauen niedrig ist?

---

Schritt 13 – Bewahren Sie rohe Urteile auf

Wenn praktikabel, behalten Sie die nützlichen rohen Ausgaben getrennt von der daraus abgeleiteten Aktion.

Zum Beispiel:

refund_probability = 0.91
frustration_score = 1.72
topic = billing
topic_confidence = 0.88

anstatt nur priority = high zu speichern.

Dies ermöglicht die Neubewertung von Schwellenwerten, das Ändern von Gewichten, die Prüfung des Verhaltens, den Vergleich von Modellversionen, die Untersuchung von Fehlern und nachgelagerte Analysen.

Behalten Sie keine sensiblen Daten über die legitimen Anforderungen der Anwendung hinaus.

---

Schritt 14 – Suchen Sie nach Jev rund um generative KI

Jev ist oft wertvoll rund um ein LLM, anstatt es zu ersetzen.

Beispiele:

EINGABE → Jev-Schutzvorrichtung → LLM → Jev-Zitier-/Qualitätsprüfung → Code entscheidet, ob zurückgegeben wird

oder:

Abfrage → Abruf → Jev-Relevanz-/Injektionsurteile → ausgewählter Kontext → Reasoning-Modell

oder:

Benutzeranforderung → Jev-Absichts-/Funktionsauswahl → deterministische getippte Funktion → Ergebnis

Dies kann die Menge an Anwendungssteuerung reduzieren, die einem offenen generativen Modell anvertraut wird.

---

Architektur-Überprüfungsverfahren

Wenn Sie aufgefordert werden, ein bestehendes System auf Jev-Möglichkeiten zu überprüfen:

1. Kartieren Sie den Workflow

Identifizieren Sie: Eingaben, deterministische Schritte, semantische Entscheidungen, Modellaufrufe, Parser, Router, Werkzeugaufrufe, Nebeneffekte, menschliche Überprüfungspunkte.

2. Erstellen Sie eine Jev-Möglichkeitskarte

Notieren Sie für jeden Kandidaten:

• ORT: Aktueller Code/Modul/Workflow
• AKTUELLE METHODE: Wie das Urteil heute gefällt wird
• JEV-KANDIDAT: Ja / Nein / Vielleicht
• WARUM: Warum eine begrenzte semantische Entscheidung angemessen ist oder nicht
• ZUSTAND: Mindestens erforderliche Beweise
• PRIMITIVE: Choice / Score / Noul
• FRAGEN: Vorgeschlagene atomare Urteile
• ZUSAMMENSETZUNG: Wie Code sie verwenden sollte
• UNSICHERHEIT: Was passiert, wenn die Antwort unklar ist
• RISIKO: Konsequenz eines falschen Urteils
• BEWERTUNG: Wie man es validiert

3. Priorisieren Sie nach Hebelwirkung

Bevorzugen Sie Möglichkeiten, bei denen Jev fragilen semantischen Code, wiederholtes LLM-Parsing, teure triviale Reasoning-Aufrufe, unbegrenzte Agentenschleifen, duplizierte Klassifizierer oder manuelle Überprüfung offensichtlicher Fälle ersetzen könnte – während das Systemverhalten begrenzt und testbar bleibt.

4. Empfehlen Sie die kleinste Version

… [für die Übersetzung gekürzt]