Les problèmes de Deep Research d’OpenAI

> « Le Deep Research d’OpenAI a été conçu pour moi, mais je ne peux pas l’utiliser. Cela ressemble à une démo impressionnante, mais au final, comme toujours, des problèmes apparaissent. Et la manière dont ils se manifestent est assez intéressante. » - Benedict Evans

• Mon travail consiste principalement à faire de la recherche et de l’analyse
  • Je cherche les données voulues, je les organise, je crée des graphiques, j’en tire des insights puis je les exprime sous forme de texte et de graphiques
  • Il s’agit ensuite d’en discuter avec d’autres personnes à partir de ces résultats
• Le Deep Research d’OpenAI ressemble à une solution qui automatise ce type de « travail de recherche »
  • Je voulais donc le tester pour voir si cet outil était réellement adapté
  • Justement, le sujet du rapport d’exemple fourni par Deep Research était le « marché des smartphones », un domaine que je connais bien
• Le tableau présenté dans le rapport d’exemple paraissait excellent au premier abord
  • Mais il faut d’abord poser une question fondamentale : « d’où viennent ces données ? »
  • Deep Research cite ‘Statista’ et ‘Statcounter’ comme sources, mais les deux posent problème
    • Statcounter produit des statistiques basées sur le trafic, avec une tendance à sur- ou sous-représenter certaines plateformes à cause des écarts d’usage des appareils
    • Statista réassemble d’autres sources en s’appuyant sur l’optimisation SEO, et la vraie source existe séparément
      • Cela revient à peu près à dire que « la source, c’est un résultat de recherche Google »
• Si l’on prend comme exemple les chiffres de part de marché iOS/Android au Japon, Deep Research avance « iOS 69 %, Android 31 % »
  • Statcounter lui-même n’a jamais publié un chiffre de 69 % au cours de l’année écoulée
  • La véritable source derrière Statista est Kantar Worldpanel, mais les chiffres fournis par Kantar sont presque à l’opposé (environ Android 63 %, iOS 36 %)
  • De son côté, un document d’un organisme public japonais (lien, page 25) indique « environ 53 % Android, 47 % iOS »
  • En outre, les chiffres de Kantar peuvent varier jusqu’à 20 points de pourcentage selon les mois, ce qui rend difficile de les considérer comme des données représentant le « taux réel d’installation du matériel »
• Pour vérifier toutes ces différences, il faut finalement revalider tous les chiffres du tableau
  • Dans ce cas, le principal intérêt de l’outil au départ, à savoir le gain de temps, disparaît en grande partie
  • Au final, il devient difficile de faire aveuglément confiance aux données mises dans le tableau par Deep Research
• Le vrai problème ici est que « un LLM n’est pas une base de données »
  • Les LLM excellent pour interpréter l’intention d’une question de manière probabiliste, mais sont faibles pour les tâches « déterministes » consistant à extraire des chiffres exacts depuis une source précise
  • Deep Research aurait dû comprendre correctement quel sens de la part de marché était recherché, puis aller chercher les bons chiffres dans des sources fiables, mais ce n’est pas ce qu’il a fait
• Cela illustre donc le phénomène suivant : « les LLM font bien ce que les ordinateurs font mal (comprendre le contexte), mais font mal ce que les ordinateurs font bien (extraire une information exacte) »
  • OpenAI essaie de confier au même système à la fois le rôle d’inférer l’intention de l’utilisateur et celui de collecter des informations exactes, mais dans l’état actuel il y a un décalage
  • Plus encore, des erreurs apparaissent alors même que cet exemple était un document promotionnel présenté par OpenAI
• Certaines personnes diront peut-être que « le modèle va s’améliorer progressivement, donc cela ira mieux »
  • Mais même si le tableau est correct à 85 %, les 15 % restants suffisent à faire chuter fortement la fiabilité globale
  • Il faudrait approcher les 100 % pour rendre possible une « recherche entièrement automatisée », et l’auteur reste sceptique sur le fait que ce seuil soit réellement atteignable
• Cela ne veut pas dire pour autant que cette technologie est totalement inutile
  • Si le sujet est bien connu de l’utilisateur, on peut gagner du temps en générant rapidement un rapport de 20 pages puis en corrigeant soi-même les erreurs
  • J’appelle les LLM un « stagiaire infini », car le brouillon rapporté par un stagiaire demande aussi une relecture et des corrections
  • En reprenant la formule de Steve Jobs sur l’ordinateur comme bicyclette pour l’esprit, il serait judicieux de l’utiliser comme un outil qui augmente les capacités humaines
• Mais, au fond, deux problèmes demeurent
  • On ne sait pas clairement s’il faut construire un produit en partant du principe que le modèle peut se tromper, ou supposer que le modèle lui-même deviendra suffisamment fiable
  • Des entreprises comme OpenAI ne disposent pas, au-delà des capitaux massifs, d’une barrière à l’entrée particulière ni de véritables capacités produit (hors domaines comme le code et le marketing)
    • Pour qu’une tentative comme Deep Research devienne un véritable « produit » allant au-delà de « textbox + API », il faut résoudre la gestion des erreurs et le contexte d’usage
    • Des concurrents comme Perplexity émergent aussi, et le scénario le plus probable est finalement celui d’autres logiciels, construits sur des API qui abstraient les LLM, chargés de gérer le taux d’erreur
• En conclusion, Deep Research est une tentative intéressante, mais il est encore difficile d’en garantir la fiabilité, et la direction que prendra le secteur reste incertaine