LLM 0.37 ajoute des embeddings multimodaux et intègre les correctifs de 12 contributeurs

Les outils en ligne de commande destinés à travailler avec des modèles rencontrent rapidement le même problème : chaque fournisseur exige une configuration distincte, alors que les données ne se limitent plus depuis longtemps au texte. Avec LLM 0.37, Simon Willison s’est attaqué aux deux aspects à la fois. Cette version simplifie la connexion aux API compatibles avec OpenAI et permet d’envoyer au système d’embeddings des objets de différents types : texte, audio, images et vidéos.

En pratique, cela signifie moins de code spécialisé autour des modèles. Si une équipe conserve des transcriptions d’appels, des photos de produits et des vidéos de formation, elle n’a plus besoin de faire comme si tout cela relevait d’un seul et même type de contenu. Chaque objet peut recevoir son propre content type, puis un modèle multimodal adapté peut en construire la représentation vectorielle.

Une interface unique pour différents fournisseurs

La nouvelle commande llm openai endpoint add est destinée aux services qui reproduisent le format de l’API OpenAI. Auparavant, le développeur devait configurer manuellement chaque modèle supplémentaire. La connexion dispose désormais de sa propre commande CLI.

Un scénario simple se présente ainsi : une équipe possède une passerelle interne ou fait appel à un fournisseur tiers doté d’une API compatible avec OpenAI. Le développeur ajoute son endpoint, indique un modèle disponible, puis l’appelle au moyen de l’interface LLM habituelle. Cette approche est particulièrement pratique pour les prototypes et les outils internes, où les modèles doivent être régulièrement remplacés ou comparés.

La version ajoute également la prise en charge de gpt-6.1-sol et gpt-6.1-terra. Pour les utilisateurs qui n’ont pas choisi leur propre modèle, gpt-6-luna devient le modèle par défaut. Selon Willison, il coûte deux fois moins cher que l’ancien modèle par défaut, gpt-5.6-luna. Ce changement ne modifie rien pour les installations existantes dans lesquelles un modèle a été explicitement défini.

Les embeddings ne se limitent plus au texte

La principale évolution architecturale concerne la prise en charge de différents types de contenus binaires lors de la création d’embeddings. Elle est nécessaire pour des modèles comme Gemini Embedding 2, capables de traiter non seulement du texte, mais aussi de l’audio, des images et des vidéos.

Prenons l’exemple d’une recherche dans une base de support. L’utilisateur saisit une question textuelle, mais la réponse pertinente peut se trouver dans une documentation, une capture d’écran de l’interface, l’enregistrement d’une conversation ou un extrait vidéo. Les embeddings multimodaux permettent de regrouper ces contenus dans un même espace de recherche. LLM 0.37 ne construit pas à lui seul un système de recherche prêt à l’emploi, mais il élimine un obstacle gênant : la bibliothèque n’impose plus de considérer tous les objets entrants comme identiques.

Il reste important de vérifier les capacités du fournisseur choisi. La prise en charge d’un format par la bibliothèque ne signifie pas que chaque modèle connecté sait traiter les quatre types de données. Les limites relatives à la taille des fichiers, au coût, aux formats et à la qualité de la recherche dépendent également du modèle utilisé.

Les pull requests générées avec l’IA comme rapports de bug détaillés

Willison a également décrit son expérience des contributions à un projet open source réalisées avec l’assistance de l’IA. La version intègre des correctifs provenant de 12 contributeurs, presque tous créés avec l’aide de l’IA. Plutôt que de faire automatiquement confiance aux patchs proposés, l’auteur a utilisé Opus 5.5 ou GPT-6 Astra pour effectuer un premier examen des propositions.

L’idée utile n’est pas d’accepter du code généré par l’IA sans le vérifier. Willison considère une telle pull request comme un rapport de bug accompagné d’un exemple reproductible et d’une solution possible. Parfois, le patch convient ; parfois, il est plus simple de corriger à nouveau le problème. Ce processus réduit le coût du tri initial, mais la responsabilité de l’architecture et du code final reste entre les mains de la personne qui maintient le projet.

Conclusion pratique : LLM 0.37 mérite l’attention des équipes qui passent d’un fournisseur à l’autre ou construisent des outils de recherche sur des données mixtes. Les propriétaires de dépôts open source peuvent également tirer parti de cette approche éditoriale : distinguer la valeur du problème identifié de la qualité du patch généré avec l’IA, puis vérifier les deux indépendamment.