Les leçons d'une start-up sur l'usage de l'API OpenAI

Après 500 millions de tokens traités avec GPT-3.5 Turbo et GPT-4 via l’API OpenAI, une start-up américaine dresse un bilan.

GPT est-il « le Heroku de l’IA » ? Le CTO d’une start-up américaine utilise cette comparaison.

La réflexion lui a été inspirée par une remarque établissant un autre parallèle : ce qui se passe avec GPT, « c’est un peu comme avec le DevOps au début des années 2000 », au sens d’une simplification des processus d’implémentation.

Pour l’intéressé, la valeur première n’est effectivement pas dans le développement de nouveaux cas d’usage, mais dans l’abaissement massif des barrières à l’entrée. Le machine learning « traditionnel » revenait très cher pour produire quelque chose de valable, explique-t-il sur le fondement de son expérience dans sa précédente entreprise.

Il travaille désormais chez un éditeur de solutions de collecte de documents fiscaux. Ces solutions s’appuient sur GPT-3.5 Turbo et GPT-4 pour quatre types de tâches : classification, extraction, résumés court et long. Exclusivement sur du texte.

Les prompts les plus courts sont-ils les meilleurs ?

Le traitement d’« environ 500 millions de tokens » jusque-là via l’API OpenAI a permis de tirer quelques leçons. Dont, concernant les prompts, le fameux « less is more ». Constat : les demandes trop précises embrouillent les modèles GPT, inhibant leurs capacités de généralisation.

Exemple sur la classification d’un bloc de texte en fonction de l’État américain auquel il se rapporte. Les performances ont été (un peu) plus élevées sans communiquer explicitement la liste des États assortie d’identifiants spécifiques. Le CTO fait le lien avec la séniorité des ingénieurs, qui se traduit par une capacité croissante à répondre à des instructions « vagues ». Et à se révéler d’autant plus créatifs.

GPT, une confiance à maîtriser

Comment faire admettre aux LLM qu’ils ne savent pas sans pour autant les brider ? Leur instruire de produire une « réponse vide » s’ils ne trouvent rien a « probablement été la plus grosse source d’erreurs » dans les cas d’usage dont il est question. Souvent, les modèles « halluciner ». Ou, au contraire, perdent de la confiance…

Fenêtre de contexte : le goulet est en sortie

Ce qu’OpenAI met en avant comme « fenêtre de contexte » correspond au nombre de tokens que les modèles peuvent accepter en entrée. Pas au volume qu’ils peuvent produire. GPT-4, par exemple, a 128k en input… et 4k en output. Assez pour avoir, affirme le CTO, rencontré des limites dans la génération de multiples listes de tâches sous forme d’objets JSON. À moins de multiplier les prompts… éventuellement au prix d’outillage supplémentaire type Langchain.

Lire aussi : Un mode batch sur l’API OpenAI : ce qu’il faut savoir

Un cas d’usage inadapté au RAG

Le RAG à l’appui de bases vectorielles ne convainc pas non plus l’intéressé. Ses arguments, dans les grandes lignes :

– Risque d’intégrer des résultats non pertinents dans la récupération ; ou, au contraire, de louper des éléments intéressants, la faute à un algo trop prudent

– Possible perte de contexte si on stocke ses vecteurs dans une base spécifique séparée des autres données de l’entreprise

– Inadéquation de la recherche sémantique à l’expertise métier (« Les utilisateurs n’ont pas besoin que [le moteur] devine ce qu’ils ont voulu dire. »)

On le lui aura fait remarquer : cette démonstration n’a évidemment pas valeur universelle. En particulier lorsque les cas d’usage impliquent des tâches génératives. Par ailleurs, un RAG, quoique imprécis, finira par inclure les éléments pertinents si la fenêtre de contexte est suffisamment grande.