TypeSafe AI (offiziell)

Mit TypeSafe bauen

TypeSafe macht KI-Intelligenz-Einheiten wie Programmierprimitiven nutzbar: kleine Urteile, die Sie zu größeren Fähigkeiten kombinieren können. Seine System-One-Modelle liefern schnelle, fokussierte Urteile, die Software direkt konsumieren kann. Jev ist TypeSafes Flaggschiff und erstes System-One-Modell. Es versteht natürliche Sprache und gibt typisierte Antworten und Wahrscheinlichkeiten zurück, anstatt Text oder Erklärungen zu generieren. Der Code besitzt den Workflow; das Modell liefert programmierbaren gesunden Menschenverstand, wo gewöhnlicher Code semantisches Verständnis benötigt.

Die Live-Dokumentation lesen

Die Live-TypeSafe-Dokumentation ist die Quelle der Wahrheit. Lesen Sie sie als Teil der Aufgabe. Diese Fertigkeit gibt eine Richtung vor; die Dokumentation enthält aktuelle Konzepte, Prompting-Anleitungen, API-Verträge, SDK-Nutzung, Modelle, Grenzen und ausgearbeitete Beispiele.

• Beginnen Sie mit dem Dokumentationsindex, um relevante Seiten und Kochbücher zu entdecken. Verwenden Sie gezielte Lektüre, anstatt die gesamte Website zu laden.
• Mintlify stellt Markdown bereit, indem es .md an einen Seitenpfad anhängt, zum Beispiel Wie man mit TypeSafe baut. Folgen Sie Links aus dem Index; konvertieren Sie gegebenenfalls Links zu Dokumentationsseiten ohne Erweiterung in .md. Lösen Sie relative Links relativ zu https://docs.typesafe.ai auf.
• Bevor Sie eine Integration schreiben, lesen Sie die aktuelle API- oder die gewählte SDK-Seite und die für das Design relevante Frageanleitung. Für einen neuen Workflow überprüfen Sie auch das nächstgelegene Kochbuch: Es zeigt oft eine bessere Zerlegung als ein generischer Klassifikator.
• Wenn der Index nicht verfügbar ist, verwenden Sie die direkten Links unten oder die Navigation der Seite. Wenn das Abrufen von Markdown fehlschlägt, versuchen Sie es mit der normalen Seite. Wenn der Live-Zugriff nicht verfügbar ist, verwenden Sie verfügbare lokale Dokumentationen oder installierte SDK-Typen, geben Sie diese Einschränkung an und vermeiden Sie es, versionsabhängige Details zu erfinden.

Aufgabe	Hier beginnen; den relevanten Details folgen
Das Programmiermodell verstehen	System One, Bauanleitung
Erkunden, was gebaut werden soll	Anwendungsfallkarte, dann relevante Kochbücher aus dem Index
Eingaben und Fragen vorbereiten	State, Primitive, dann die Seite des gewählten Primitivs
Entscheiden, wie mit Unsicherheit umgegangen werden soll	Konfidenz
API-Code schreiben	HTTP-API, Python-SDK oder JavaScript-SDK
Eine ältere Integration aktualisieren	Migrationsleitfaden und die aktuelle Referenz des installierten SDKs

Die nützliche Form finden

Beginnen Sie mit dem Verhalten, das der Benutzer wünscht: Was wird die Anwendung anzeigen, auswählen, ändern oder weiterleiten? Arbeiten Sie rückwärts zu den benötigten Urteilen. Behalten Sie bekannte Regeln, Berechnungen, exakte Nachschlagewerke und Ausführungen im Code. Bewahren Sie den gewählten Stack und Umfang des Benutzers; fügen Sie TypeSafe dort hinzu, wo semantisches Verständnis hilft.

Wenn Sie eine Architektur brainstormen oder auswählen, denken Sie über Klassifikation hinaus. Die folgenden Muster sind Ausgangspunkte: Kombinieren Sie Primitive um das Ziel des Benutzers herum, einschließlich Ideen, die nicht in ein etabliertes Rezept passen.

• Routen und füllen Sie bekannte Argumente. Eine Anfrage kann einen Handler und seine typisierten Parameter auswählen. Stellen Sie nützliche verzweigungsspezifische Fragen im Voraus und konsumieren Sie nur die relevanten Antworten. Erkunden Sie Funktionsaufruf und spekulative Aufteilung.
• Auswählen statt generieren. Finden Sie Kandidatenwerte oder Quellspannen im Code, verwenden Sie ein Urteil, um die beabsichtigte auszuwählen, und kopieren oder normalisieren Sie sie. Code kann auch Quelltext zu einem formatierten Dokument oder Leseleitfaden zusammenstellen. Erkunden Sie Werteextraktion und Strukturwiederherstellung.
• Beweise finden und bewerten. Rufen Sie Kandidaten ab, vergleichen Sie ihre Relevanz für eine Abfrage und wählen Sie nützlichen Kontext aus. Erkunden Sie Reranking und hierarchische Klassifikation.
• Urteile in wiederverwendbare Daten verwandeln. Bewerten Sie Dimensionen einmal, lassen Sie dann Code oder Benutzersteuerungen Gewichte, Schwellenwerte, Rangfolgen und Ansichten ändern. Mit beschrifteten Ergebnissen können diese Signale zu klassischen ML-Features werden. Erkunden Sie zusammengesetzte Bewertung und Feature-Discovery.
• Verifizieren und eskalieren. Überprüfen Sie bestimmte Behauptungen oder Felder anhand ihrer Beweise; senden Sie unsichere oder fehlschlagende Fälle an eine Person oder ein Reasoning-Modell. Erkunden Sie Zitierungsprüfungen und Extraktionskaskaden.
• Auf sich ändernde Zustände reagieren. Code kann Ziele und Beobachtungen behalten, während frische Urteile den nächsten begrenzten Schritt leiten. Halten Sie abgeleitete Zustände von beobachteten Fakten getrennt, und überprüfen Sie die Aktualität, bevor Sie ein Ergebnis auf eine veränderte Situation anwenden.

Bieten Sie bei offenen Anfragen die wenigen Richtungen an, die das Ziel des Benutzers am besten bedienen, und empfehlen Sie einen Ausgangspunkt. Wählen Sie bei einer konkreten Anfrage das relevante Muster und bauen Sie es; ein Brainstorming ist kein obligatorischer Umweg.

Die Urteile entwerfen

Wählen Sie basierend darauf, was die Antwort bedeutet, und lesen Sie dann die relevante Primitivseite:

Bedarf	Primitiv	Wichtige Unterscheidung
Eines aus einer definierten Menge	Choice	Wählt eine Option aus; seine Verteilung vergleicht konkurrierende Optionen
Ob eine Bedingung gilt	Noul	Wahrscheinlichkeit für Ja; keine separate Konfidenz; verwenden Sie eines pro Label, wenn mehrere zutreffen können
Grad entlang einer beschriebenen Dimension	Score	Wahrscheinlichkeitsgewichtete Position auf geordneten Stufen; verwenden Sie vergleichbare Scores pro Element für abgestufte Rangfolge

Geben Sie jeder Frage genügend relevanten State zum Beantworten: Quelltext, Identitäten, Beziehungen, Richtlinien und aktuelle Fakten. Bevorzugen Sie benannte JSON-Felder, wenn der Kontext mehrere Teile hat. Setzen Sie das Urteil in instructions und definieren Sie seine möglichen Antworten in criteria. Fragen-IDs sind für Code und werden nicht an das Modell gesendet; schließen Sie die vollständige Bedeutung in die Frage ein. Verweisen Sie auf verschachtelten State mit Backtick-Pfaden wie ticket.messages[0].text.

Stellen Sie ein enges, kohärentes Urteil pro Frage. Teilen Sie unabhängig nützliche Dimensionen auf, ohne die bewertete Beziehung zu zerstören. Eine begrenzte Aktionsauswahl oder kontextuelle Interpretation ist zulässig; atomar bedeutet nicht wörtliche Faktenextraktion oder eine Ein-Satz-Grenze. Strings funktionieren für einfache Fragen. Verwenden Sie strukturierte Objekte oder Arrays, wenn Definitionen, Kontraste, Ausschlüsse oder Beispiele Anweisungen oder Kriterien klären. Score-Stufen müssen konkrete Situationen beschreiben und für sich allein stehen.

Halten Sie die benötigten Antworten verfügbar. Schließen Sie ein Nicht-Treffer-Ergebnis ein, wenn nichts passen könnte; verwenden Sie ein separates Präsenzurteil, wenn es unabhängig nützlich ist. Überprüfen Sie bei Quellwertauswahl die Kandidatenabdeckung: Das Modell kann einen weggelassenen Wert nicht auswählen.

Komponieren und verifizieren

Stellen Sie unabhängige Fragen zum selben State zusammen, einschließlich nützlicher spekulativer Fragen. Sie laufen parallel und können die Antworten der anderen nicht sehen. Geben Sie jede spekulative Prämisse explizit an; der Code konsumiert die zutreffenden Antworten. Eine zweite Anfrage ist gerechtfertigt, wenn eine frühere Antwort benötigt wird, um Beweise abzurufen, neuen State zu konstruieren oder die nächsten Optionen zu bestimmen. Zusätzliche Fragen verbrauchen trotzdem Tokens; messen Sie tatsächliche Anfragebudgets, Kosten und Ende-zu-Ende-Latenz.

Verwenden Sie Wahrscheinlichkeiten und Konfidenz, um das Verhalten zu steuern, mit Schwellenwerten, die anhand der Daten und Konsequenzen des Benutzers bewertet werden. Choice/Score-Konfidenz fasst die Verteilungskonzentration zusammen, nicht die allgemeine Workflow-Korrektheit oder die Erlaubnis zum Handeln. Ein Noul nahe 0.5 bedeutet ähnliche Wahrscheinlichkeit für Ja und Nein, nicht mittlere Intensität. Mehrere akzeptable Alternativen können ebenfalls die Wahrscheinlichkeit verteilen; niedrige Konfidenz muss nicht eine harmlose Präferenzauswahl ungültig machen. Ignorieren Sie Unsicherheit bei ungenutzten Verzweigungen.

Halten Sie Richtlinien explizit und rohe Urteile wiederverwendbar. Gewichtete Scores eignen sich für sich ausgleichende Präferenzen; eine Regel „irgendeine schwerwiegende Verletzung“ benötigt separate Bedingungen. Das Ändern eines Gewichts oder Anzeigefilters muss keine Inferenz erneut ausführen, wenn Beweise und Fragenbedeutungen unverändert sind. Typisierte Ausgabe garantiert die Schnittstelle, nicht die Wahrheit. System-One-Modelle sind für kalibrierte Entscheidungen trainiert; validieren Sie ihre Leistung in der Zieldomäne.

Testen Sie repräsentative Fälle und das resultierende Anwendungsverhalten. Überprüfen Sie bei Fehlern den genauen State, die Fragen, Kandidaten, Antworten, Zusammensetzung und das beobachtete Ergebnis. Trennen Sie fehlende Beweise, Modellfehler, Codefehler und Serviceausfälle. Behandeln Sie Kochbuch-Schwellenwerte und Demo-Ergebnisse als zu evaluierende Beispiele, nicht als universelle Regeln oder dauerhafte Modelleinschränkungen. Halten Sie API-Anmeldeinformationen serverseitig in Web-Apps.