Microsoft sort son un écosystème d'exécution d'Agents.

Vu le catalogue de Microsoft, c'est assez énorme avec plus de 1400 "connecteurs" (comprendre "API") disponibles sur étagère pour interagir avec les services Microsoft mais aussi des services externes comme Gmail, Twilio, MongoDB.

Ils ont aussi pas mal de choses assez exclusives sur étagère:

• un Code Interpreter Python
• recherche web avec Bing
• des jeux de données privés comme celui de Tripadvisor par exemple
• un moteur de conversation intégré

Bref, dans l'environnement Azure/Microsoft il y a toute une toolbox pour développer

Encore une étude sur les impact du prompt et du format de réponse sur la qualité de la génération.

Ils ont notamment testé les performances de génération en plusieurs formats de sortie:

• JSON (0.77)
• YAML (0.7)
• text (0.69)
• Markdown (0.35)

Dommage qu'ils n'aient pas inclus XML. (et j'ai vérifié cette fois, les prompts sont les mêmes entre chaque format)

Une autre conclusion est que le modèle GPT 3.5 est plus sensible aux variations de prompt que GPT 4.

C'est quelque chose que je remarque aussi, plus un modèle est performant et moins il est sensible aux subtilités du Prompt Engineering.

Le prompt système de Bolt est disponible sur Github et donne pas mal d'info sur la manière dont est organisé leur système:

• création/édition de code avec des GNU diff
• ça tourne dans des WebContainers
• ils contournent la limite de 8K tokens en output avec leur CONTINUE_PROMPT

Surtout je vois que tout est au format XML (ils utilisent Claude 3.5 Sonnet) plutôt que JSON.

J'aimerais bien savoir pourquoi, sachant que j'avais remarqué que le format XML présentait de meilleures performances de génération que le JSON il y a un an. Je me demande si ils sont arrivés aux mêmes conclusions.

Les gens de chez .txt (ce qui font Outlines) ont pris le temps de réfuter l'étude Let Me Speak Freely qui annonçait des performances moindre lorsque l'on utilisait un format contraint comme JSON.

Leurs résultats montrent que la génération structuré améliore un peu la performance de génération (ils ont utilisés les mêmes benchmark que l"étude)

Les erreurs faites dans l'étude:

• certains de leurs résultats présentaient déjà de meilleures performances en génération structurée
• les prompts n'étaient pas les mêmes entre génération structurée et non structurée
• le parsing des outputs était réalisé avec un autre LLM ce qui faussait les résultats

An apt analogy would be to programming language benchmarking: it would be easy to write a paper showing that Rust performs worse than Python simply by writting terrible Rust code.

Finalement c'est plutôt rassurant car il est difficile de se passer de la génération structurée aujourd'hui.

A noter qu'il faut bien faire la différence entre

• génération structurée: JSON-mode d'OpenAI ou lib Outlines qui garantissent le schéma des données en sortie
• génération JSON: on génère du JSON et on vérifie qu'il correspond à un schéma