Prompt de façon plus structurée.
Si votre sortie est instable, le problème vient souvent d’un prompt trop vague, pas du framework.
Prompt vs Instructions
Les deux servent à guider le modèle, mais ils ne jouent pas le même rôle :
| Question | Prompt | Instructions |
|---|---|---|
| Quand ça change | À chaque requête | Quand le rôle ou la feature change |
| Ce que vous y mettez | La demande du moment, le contexte local, les variables UI | Le ton, le rôle, le format stable |
| Qui l’alimente | Souvent l’action utilisateur | Presque toujours votre code produit |
La forme la plus simple
- tester vite
- explorer un comportement
- valider une idée de fonctionnalité
Prompt pour construire une requête plus propre
Quand vous devez injecter du contexte, des variables ou des conditions, utilisez Prompt :
Ajouter des conditions
Ajouter du contexte sans bruit
Le bon réflexe est d’ajouter uniquement le contexte qui influence réellement la réponse. Exemple utile :- répéter des instructions déjà présentes dans la session
- injecter un long historique non utilisé
- mélanger plusieurs objectifs en une seule requête
Quelques règles qui améliorent presque toujours le résultat
- Dites ce que vous voulez obtenir, pas seulement le sujet.
- Donnez le niveau de détail attendu.
- Précisez le format de sortie si vous affichez directement le texte.
- Évitez les demandes trop larges si l’UI attend une réponse courte.
respond ou streamResponse
Pour un prompt donné, vous avez deux grandes options :
respond(to:)si vous attendez le résultat completstreamResponse(to:)si vous voulez afficher la réponse progressivement
Quand toucher aux GenerationOptions
Ne commencez pas par là. Touchez à GenerationOptions quand votre prompt est déjà correct et que vous voulez contrôler :
- la stabilité de la réponse
- sa longueur maximale
- son niveau de variation
sampling: .greedy et une température basse poussent vers une réponse plus prévisible. maximumResponseTokens évite qu’une réponse courte devienne un mini-article.
Comment lire les modes de sampling
.greedychoisit toujours le token le plus probable. C’est le mode le plus stable..random(top:seed:)pioche parmi un nombre fixe de tokens probables. C’est utile si vous voulez un peu de variété, mais garder une réponse cadrée..random(probabilityThreshold:seed:)pioche dans un ensemble de tokens dont la probabilité reste au-dessus d’un seuil. Le nombre de candidats varie selon le contexte.
streamResponse(to:options:).
Repère avancé : tokenCount(for:)
Apple documente aussi tokenCount(for:) sur SystemLanguageModel pour mesurer le poids d’instructions. C’est utile quand vous ajustez finement votre contexte, mais Apple l’indique en 26.4 beta.
Pour un premier design produit, ne basez pas votre feature sur ce point. Commencez par des prompts courts, puis mesurez seulement si vous avez un vrai problème de contexte.
Quand passer à la sortie structurée
Si votre app a besoin de champs stables comme :- un titre
- une liste
- une note
- un niveau de priorité