Mistral sort une nouvelle licence qui restreint l'utilisation commerciale de ses modèles.

Cette nouvelle licence est similaire à la Server Side Public Licence introduire par MongoDB et qui a pour but d'empêcher les cloud provider de fournir des produits Open Source sur étagère sans reverser des droits à la société qui édite ce produit.

Elle est cependant beaucoup plus restrictive car il est aussi interdit d'utiliser les produits utilisant cette nouvelle licence dans une application alors que la SSPL se borne à interdire la revente via un cloud.

Subject to the foregoing, You shall not supply the Mistral Models or Derivatives in the course of a commercial activity, whether in return for payment or free of charge, in any medium or form, including but not limited to through a hosted or managed service (e.g. SaaS, cloud instances, etc.), or behind a software layer.

Concrètement, seuls les usages non-commerciaux sont autorisés donc la recherche ou l'utilisation à des fins personnelles.

Mistral ouvre le fine-tuning de ses modèles.

Techniquement, c'est un fine tuning LoRa ou très peu de paramètres sont affectés. Ça réduit drastiquement les coûts tout en offrant de bonnes performances de génération (selon eux)

Bon alors techniquement c'était déjà possible vu que les modèles sont open source mais concrètement ils simplifient la tâches aux développeurs en proposant 3 services:

• mistral-finetune: open source et gratuit, c'est un repo qui contient le code nécessaire pour fine tuner un modèle Mistral
• Serverless fine-tuning: une API sur leur cloud pour fine-tuner les modèles sans se prendre la tête ($)
• Custom training service: une offre de service ou le fine tuning est pris en charge de A à Z par les équipes de Mistral ($$$)

Un article qui parle de techniques avancées pour améliorer les résultats d'un RAG.

• Query Expension: le but est d'améliorer le champ lexical de la requête pour retrouver plus de documents pertinents. On peut aussi parler de la méthode HyDE pour récupérer des documents en provenance de champs lexicaux différents.

• Self Query: c'est ce que j'appelle l'extraction de facettes, en gros ça consiste à extraire du texte brut les filtres que l'on a définit dans son moteur de recherche (couleur, poids, etc)

• Hybrid & Filtered vector search: cette étape je conseille de la faire exclusivement avec un vrai moteur de recherche comme Elasticsearch en utilisant les query avancées et le scoring

• ReRanking: après la récupération des documents potentiellement pertinents (disons 50), on refait une passe en demandant à un LLM de choisir les documents contenant réellement des informations pour répondre à la demande de l'utilisateur.

Mistral sort un modèle spécialisé dans la génération de code.

Côté Open Source, il offrirait les meilleurs performances pour le moment avec de meilleurs résultats que CodeLlama et DeepSeek Coder (le précédent SOTA).

Il est disponible dans le cloud de Mistral (La Plateforme) et une intégration est prévue avec TabNine par exemple.

Niveau Open Source, il y a du nouveau avec une release sous la nouvelle licence Mistral AI Non-Production License qui restreint le modèle à une utilisation non commerciale.

Concrètement, Codestral sera payant si vous comptez l'utiliser dans un produit que vous revendez à des utilisateurs.

Un framework Python pour intégrer des LLMs dans son code.

Je trouve la DX bien pensée par rapport à Langchain (pas difficile de faire mieux niveau DX)

On y retrouve simplement les fonctionnalités essentielles pour faire du LLM Engineering:

• choix du modèle, des paramètres
• intégration facile de l'historique de messages
• utilisation de fonctions par le modèle (Function Calling )
• chaines de prompt et sous prompt (vraiment bien foutu je trouve!)
• extraction de données structurées

Il ne manque que la validation et la possibilité de spécifier un format de sortie structuré pour chaque prompt. C'est du super boulot.

(Dommage que ce soit en Python)

Une queue de message construite avec Postgres.

Projet prometteur mais assez récent donc à utiliser avec précaution.

Tout se fait en SQL:

-- creates the queue
SELECT pgmq.create('my_queue');

-- messages are sent as JSON
SELECT * from pgmq.send('my_queue', '{"foo": "bar1"}');

SELECT * FROM pgmq.read('my_queue', 30, 2);
-- or
SELECT pgmq.pop('my_queue');

OpenAI partage des technique pour réduire la latence des LLMs.

C'est toujours bon à prendre car le paradigme de latence des LLMs est assez inédit dans le mode du Software Engineering ou on optimise à la dizaine de micro-seconde.

• Taille du modèle: plus petit = plus rapide mais surtout moins performance. Si vous n'êtes pas capable de mesurer la performance alors il vaut peut-être mieux ne pas risquer un autre modèle que ceux de la gamme GPT4.

• Générer moins de tokens: les tokens de sortie sont long à générer et en plus coûtent 2x plus cher. Je partage une de mes technique pour Modifier efficacement un texte avec un Agent LLM par exemple

• Utiliser moins de tokens en entrée: rien à redire ici

• Faire moins de requêtes: regrouper les requêtes dans le même prompt réduit la latence mais fait baisser les performances (J'en parle dans Spécialisez vos Agents LLM pour de meilleures performances

• Paralléliser les requêtes: basic software engineering

• Montrer la progression à l'utilisateur: basic user experience

• Ne pas utiliser des LLMs partout: cela ne sert à rien de taper sur une vis avec un marteau

Cette fiction de Amnesty International sur la reconnaissance facile rendue possible grâce à l'IA est à glacer le sang.

Une piqûre de rappel sur la vigilance autour des outils IA qui peuvent être utilisé à des fins néfastes pour la population.

Un article très intéressant sur le caractère probabiliste des LLMs.

En gros, les GPU ont des architectures internes différente, notamment sur la manière de programmer les tâches en parallèle et du à la non associativité de certaines opérations cela cause des infimes différences de calcul qui finissent par affecter significativement le résultat final.

Cela me fait penser à la théorie du chaos ou des différences infimes dans l'état initial amène à des évolutions complètement différentes d'un système.

Toujours intéressant de savoir que ces concepts existent ainsi que de connaitre leur utilité :-)

• LoRa (Low-Rank Adaptation) : une technique pour spécialiser des modèles afin de les rendre plus performant (en temps) et de "guider" leur génération. C'est par exemple ce qu'on utilise avec StableDiffusion pour forcer la génération dans un style particulier ne faisant pas partie des données d'entrainement

• PEFT (Parameter-Efficient Fine-Tuning): cette technique permet de fine-tuné uniquement une partie des paramètres du modèle pour réduire les coût. Par exemple, on utilise ça avec LoRa justement car les modèles d'image sont très gros et très cher à fine tuner

• RAG (Retrieval-Augmented Generation): cette technique permet "d'interroger" des connaissances ne faisant pas partie des données d'entrainement d'un modèle comme les documents internes d'une entreprise par exemple (J'en parle tout le temps)

• MoE (Mixture of Experts): une architecture de LLM ou le modèle est composé de "sous modèles" ayant été entrainés et spécialisé dans des domaines différents

• Quantization: cette technique réduit la précision des nombres utilisés pour stocker les paramètres d'un modèle afin d'augmenter la vitesse et le coût au détriment de la performance de génération