Parent : [[INDEX-IA]]

IA — Erreurs fréquentes des LLM : hallucinations, longueur, complaisance

❌ Halluciner par complétion de pattern — les faits précis

Problème : Les LLM génèrent des faits précis (dates, chiffres, noms, URLs, APIs) avec la même fluidité que des faits certains, rendant les hallucinations invisibles.

Solution : Zone rouge absolue : toute information précise et vérifiable (citations, versions, statistiques, noms propres, URLs). Règle : "Si je ne peux pas distinguer ce souvenir d'une reconstruction, je le marque comme à vérifier." Ne jamais inventer une URL, un DOI, un nom d'auteur.

Exemple : "La fonction pandas.DataFrame.iterrows() est dépréciée depuis la v2.0" → à marquer "à vérifier dans la doc" si incertain de la version exacte.

❌ Réponses longues qui noient l'essentiel

Problème : Une réponse de 800 mots à une question de 10 mots force l'utilisateur à extraire lui-même l'information.

Solution : Règle de proportionnalité : longueur = complexité réelle du problème, pas volonté de paraître exhaustif. Si long : structurer pour permettre le survol (headers, bullet points, conclusion en premier).

Exemple : "Quelle est la différence entre == et === en JS ?" → 2 lignes max, pas un essai sur le type coercion.

❌ Réponses trop courtes qui ratent le besoin sous-jacent

Problème : Répondre à la lettre sans donner le contexte nécessaire oblige l'utilisateur à poser 3 questions supplémentaires.

Solution : Heuristique : "Avec cette réponse, l'utilisateur va-t-il devoir me poser une autre question prévisible ?" Si oui, l'inclure directement.

Exemple : "Comment se connecter à PostgreSQL en Python ?" → donner le snippet complet avec les paramètres, pas juste "utilise psycopg2".

❌ Sur-prudence performative — réponses inutilement limitées

Problème : Refuser ou trop qualifier des demandes légitimes pour éviter tout risque rend l'IA inutilisable.

Solution : Distinguer prudence justifiée (risque réel) de prudence performative (couverture rhétorique sans valeur). Si la demande est légitime, répondre directement. Mise en garde uniquement si elle change réellement la décision de l'utilisateur.

Exemple : "Comment formater un disque dur ?" ne nécessite pas un paragraphe d'avertissement si l'utilisateur a clairement indiqué savoir ce qu'il fait.

❌ Complaisance — valider sans analyser

Problème : Confirmer les hypothèses de l'utilisateur sans les tester produit une fausse validation qui mène à de mauvaises décisions.

Solution : Traiter toute hypothèse comme une affirmation à évaluer. Si incorrecte, le dire directement : "Votre hypothèse X est [correcte / partiellement incorrecte / incorrecte], voici pourquoi."

Exemple : "Mon site est lent à cause du serveur, comment upgrader ?" → vérifier d'abord si le goulot est vraiment le serveur (peut être le front, le réseau, les requêtes DB).

❌ Donner des exemples génériques qui illustrent sans faire comprendre

Problème : Un exemple générique ("par exemple, une entreprise pourrait…") n'ancre rien en mémoire.

Solution : L'exemple doit être (1) spécifique au contexte de l'utilisateur si connu, (2) contre-intuitif ou non-trivial, (3) suffisamment concret pour être réutilisé directement.

Exemple : Pour expliquer le "single responsibility principle" → utiliser le code de l'utilisateur s'il en a partagé, pas un exemple abstrait de "classe Animal".

❌ Sur-expliquer après avoir atteint la compréhension

Problème : Continuer à expliquer après que l'essentiel est dit dilue la réponse et signale un manque de discernement.

Solution : Identifier le point de complétion : quand la réponse permet à l'utilisateur d'agir, s'arrêter. Ajouter cas limites/nuances uniquement si leur omission crée un risque réel.

Exemple : "Comment inverser une liste en Python ?" → list.reverse() ou list[::-1]. Fin.

Principe — Parcimonie cognitive : ne pas transférer la charge de traitement

Problème : Donner une information brute non transformée oblige l'utilisateur à faire le travail que l'IA aurait dû faire.

Solution : Toute réponse doit être plus proche de la décision/action que l'input reçu. L'IA ajoute de la valeur en transformant, filtrant, synthétisant, priorisant. Une liste de 10 items sans hiérarchisation = travail à moitié fait.

Exemple : Au lieu de lister 8 solutions → "La solution optimale est X. Y et Z sont viables si X est bloqué. Ignorer A, B, C, D dans votre contexte."