Construire avec TypeSafe
TypeSafe rend les unités d'intelligence IA utilisables comme des primitives de programmation : de petits jugements que vous pouvez composer en capacités plus grandes. Ses modèles System One renvoient des jugements rapides et ciblés que le logiciel peut consommer directement. Jev est le modèle phare de TypeSafe et le premier modèle System One. Il comprend le langage naturel et renvoie des réponses typées et des probabilités plutôt que de générer du texte ou des explications de raisonnement. Le code possède le flux de travail ; le modèle fournit un bon sens programmable là où le code ordinaire a besoin de compréhension sémantique.
Lire la documentation en direct
La documentation en direct de TypeSafe est la source de vérité. Lisez-la dans le cadre de la tâche. Cette compétence donne une orientation ; la documentation contient les concepts actuels, les conseils d'invite, les contrats API, l'utilisation du SDK, les modèles, les limites et les exemples pratiques.
- Commencez par l'index de documentation pour découvrir les pages pertinentes et les cookbooks. Utilisez des lectures ciblées plutôt que de charger l'ensemble du site.
- Mintlify sert le Markdown en ajoutant
.mdau chemin d'une page, par exemple comment construire avec TypeSafe. Suivez les liens depuis l'index ; convertissez les liens de page de documentation sans extension en.mdlorsque cela est utile. Résolvez les liens relatifs par rapport àhttps://docs.typesafe.ai. - Avant d'écrire une intégration, lisez la page actuelle de l'API ou du SDK choisi et les conseils de question pertinents pour la conception. Pour un nouveau flux de travail, inspectez également le cookbook le plus proche : il montre souvent une meilleure décomposition qu'un classifieur générique.
- Si l'index est indisponible, utilisez les liens directs ci-dessous ou la navigation du site. Si la récupération Markdown échoue, essayez la page normale. Si l'accès en direct est indisponible, utilisez la documentation locale disponible ou les types SDK installés, indiquez cette limitation et évitez d'inventer des détails dépendant de la version.
| Tâche | Commencez ici ; suivez les détails pertinents |
|---|---|
| Comprendre le modèle de programmation | System One, guide de construction |
| Explorer quoi construire | Carte des cas d'utilisation, puis les cookbooks pertinents de l'index |
| Préparer les entrées et les questions | État, primitives, puis la page de la primitive choisie |
| Décider comment gérer l'incertitude | Confiance |
| Écrire du code API | API HTTP, SDK Python, ou SDK JavaScript |
| Mettre à jour une intégration plus ancienne | Guide de migration et la référence actuelle du SDK installé |
Trouver la forme utile
Partez du comportement souhaité par l'utilisateur : que va afficher, sélectionner, modifier ou déléguer l'application ? Remontez aux jugements dont elle a besoin. Gardez les règles connues, les calculs, les recherches exactes et l'exécution dans le code. Présélectionnez la pile et le périmètre choisis par l'utilisateur ; ajoutez TypeSafe là où la compréhension sémantique est utile.
Lors du brainstorming ou du choix d'une architecture, envisagez plus que la classification. Les modèles ci-dessous sont des points de départ : combinez les primitives autour de l'objectif de l'utilisateur, y compris des idées qui ne correspondent pas à une recette établie.
- Router et remplir les arguments connus. Une requête peut sélectionner un gestionnaire et ses paramètres typés. Posez des questions utiles spécifiques à la branche dès le départ et consommez uniquement les réponses pertinentes. Explorez l'appel de fonction et le fan-out spéculatif.
- Sélectionner au lieu de générer. Trouvez des valeurs candidates ou des plages source dans le code, utilisez un jugement pour sélectionner celle prévue, puis copiez-la ou normalisez-la. Le code peut également assembler le texte source dans un document formaté ou un guide de lecture. Explorez l'extraction de valeur et la récupération de structure.
- Trouver et évaluer des preuves. Récupérez des candidats, comparez leur pertinence par rapport à une requête et sélectionnez le contexte utile. Explorez le reranking et la classification hiérarchique.
- Transformer les jugements en données réutilisables. Notez les dimensions une fois, puis laissez le code ou les contrôles utilisateur modifier les pondérations, les seuils, les classements et les vues. Avec des résultats étiquetés, ces signaux peuvent devenir des fonctionnalités ML classiques. Explorez le scoring composite et la découverte de fonctionnalités.
- Vérifier et escalader. Vérifiez des affirmations ou des champs spécifiques par rapport à leurs preuves ; envoyez les cas incertains ou en échec à une personne ou à un modèle de raisonnement. Explorez les vérifications de citation et les cascades d'extraction.
- Répondre à un état changeant. Le code peut conserver les objectifs et les observations tandis que de nouveaux jugements guident la prochaine étape bornée. Gardez l'état inféré distinct des faits observés et vérifiez la fraîcheur avant d'appliquer un résultat à une situation modifiée.
Pour les requêtes ouvertes, proposez les quelques directions qui servent le mieux l'objectif de l'utilisateur et recommandez un point de départ. Pour une requête concrète, choisissez le modèle pertinent et construisez ; un brainstorming n'est pas un détour obligatoire.
Concevoir les jugements
Choisissez en fonction de ce que la réponse signifie, puis lisez la page de primitive pertinente :
| Besoin | Primitive | Distinction importante |
|---|---|---|
| Un parmi un ensemble défini | Choix | Choisit une option ; sa distribution compare les options concurrentes |
| Si une condition est vérifiée | Noul | Probabilité de oui ; pas de confiance séparée ; utilisez-en une par étiquette lorsque plusieurs peuvent s'appliquer |
| Degré le long d'une dimension décrite | Score | Position pondérée par probabilité sur des niveaux ordonnés ; utilisez des Scores comparables par élément pour un classement gradué |
Donnez à chaque question suffisamment d'état pertinent pour répondre : texte source, identités, relations, politiques et faits actuels. Préférez les champs JSON nommés lorsque le contexte a plusieurs parties. Mettez le jugement dans les instructions et définissez ses réponses possibles dans les critères. Les ID de question sont pour le code et ne sont pas envoyés au modèle ; incluez un sens complet dans la question. Référencez l'état imbriqué avec des chemins entre backticks comme ticket.messages[0].text.
Posez un jugement étroit et cohérent par question. Séparez les dimensions indépendamment utiles, sans détruire la relation jugée. Une sélection d'action bornée ou une interprétation contextuelle est valide ; atomique ne signifie pas extraction littérale de fait ou une limite d'une phrase. Les chaînes fonctionnent pour les questions simples. Utilisez des objets ou des tableaux structurés lorsque les définitions, les contrastes, les exclusions ou les exemples clarifient les instructions ou les critères. Les niveaux de Score doivent décrire des situations concrètes et se suffire à eux-mêmes.
Gardez les réponses nécessaires disponibles. Incluez un résultat d'absence de correspondance lorsque rien ne peut correspondre ; utilisez un jugement de présence séparé lorsqu'il est indépendamment utile. Pour la sélection de valeur source, vérifiez la couverture des candidats : le modèle ne peut pas choisir une valeur omise.
Composer et vérifier
Posez les questions indépendantes sur le même état ensemble, y compris les questions spéculatives utiles. Elles s'exécutent en parallèle et ne peuvent pas voir les réponses des unes des autres. Énoncez chaque prémisse spéculative explicitement ; le code consomme les réponses applicables. Une seconde requête est justifiée lorsqu'une réponse antérieure est nécessaire pour récupérer des preuves, construire un nouvel état ou déterminer les options suivantes. Les questions supplémentaires utilisent toujours des tokens ; mesurez les budgets de requête réels, le coût et la latence de bout en bout.
Utilisez les probabilités et la confiance pour guider le comportement, avec des seuils évalués sur les données et les conséquences de l'utilisateur. La confiance Choix/Score résume la concentration de la distribution, pas l'exactitude globale du flux de travail ou la permission d'agir. Un Noul proche de 0,5 signifie une probabilité similaire pour oui et non, pas une intensité moyenne. Plusieurs alternatives acceptables peuvent également répartir la probabilité ; une faible confiance n'a pas besoin d'invalider un choix de préférence inoffensif. Ignorez l'incertitude sur les branches inutilisées.
Gardez la politique explicite et les jugements bruts réutilisables. Les scores pondérés conviennent aux préférences compensatrices ; une règle de « toute violation grave » nécessite des conditions séparées. Changer un poids ou un filtre d'affichage n'a pas besoin de relancer l'inférence lorsque les preuves et la signification de la question sont inchangées. La sortie typée garantit l'interface, pas la vérité. Les modèles System One sont entraînés pour des décisions calibrées ; validez leurs performances dans le domaine cible.
Testez des cas représentatifs et le comportement résultant de l'application. En cas d'échec, inspectez l'état exact, les questions, les candidats, les réponses, la composition et le résultat observé. Séparez les preuves manquantes, les erreurs de modèle, les erreurs de code et les défaillances de service. Traitez les seuils des cookbooks et les résultats de démonstration comme des exemples à évaluer, pas comme des règles universelles ou des limitations permanentes du modèle. Gardez les informations d'identification API côté serveur dans les applications web.