Atelier FineWeb : streaming, filtrage, déduplication, tokenisation et analyse de corpus web à grande échelle

Meta et Stanford présentent Fast Byte Latent Transformer : 50% de bande passante mémoire en moins, sans tokenisation

Des chercheurs de Meta, de Stanford University et de l'Université de Washington ont présenté trois nouvelles méthodes pour accélérer significativement le Byte Latent Transformer (BLT), une architecture de modèle de langage qui traite directement le texte en octets bruts plutôt qu'en tokens. La contribution principale s'appelle BLT Diffusion (BLT-D) et s'attaque à un problème central du BLT : son décodeur local génère les octets un à un, de manière autoregressive, ce qui implique plusieurs passes mémoire là où un modèle tokenisé n'en nécessite qu'une seule. Sur les serveurs modernes de LLM, le goulot d'étranglement n'est pas la puissance de calcul brute mais la bande passante mémoire, c'est-à-dire le coût répété de charger les poids du modèle et les caches KV depuis la mémoire. La solution proposée remplace ce décodage octet par octet par une diffusion discrète par blocs : au lieu de prédire un seul octet à la fois, le modèle génère simultanément des blocs de 4, 8 ou 16 octets en démasquant progressivement les positions les plus certaines à chaque étape, selon deux stratégies, l'une basée sur un seuil de confiance, l'autre sur une contrainte d'entropie cumulative. L'enjeu pratique est considérable. Selon les chercheurs, ces méthodes permettent de réduire la bande passante mémoire à l'inférence de plus de 50%, ce qui se traduit directement par une accélération de la génération de texte. Pour les entreprises qui déploient des LLM à grande échelle, où le coût d'inférence est un facteur économique déterminant, ce gain représente une réduction significative de la latence et des coûts opérationnels. Au-delà de la vitesse, les modèles octet-niveau comme BLT présentent des avantages intrinsèques que les architectures tokenisées peinent à égaler : meilleure gestion du texte multilingue, robustesse accrue face au bruit dans les entrées, et traitement naturel du code, des chiffres et des caractères spéciaux, sans les artefacts produits par les tokenizers comme le byte-pair encoding (BPE). Le BLT avait déjà constitué une avancée notable en démontrant qu'un modèle opérant sur des octets bruts pouvait atteindre les performances des modèles tokenisés à grande échelle, grâce à une segmentation dynamique en patches de longueur variable pilotée par l'entropie locale du texte. Les régions difficiles à prédire reçoivent des patches courts, les passages plus prévisibles des patches plus longs, avec une taille moyenne de 4 octets et un maximum de 8. La majeure partie du calcul s'effectue sur des représentations latentes compressées via trois composants : un encodeur local, un Transformer global, et un décodeur local. Le principal frein à l'adoption industrielle de cette approche restait sa lenteur à l'inférence, rendue pénalisante par le nombre élevé de passes décodeur nécessaires. Les trois techniques introduites dans ce nouveau travail visent directement ce verrou, ouvrant concrètement la voie au déploiement des modèles octet-niveau dans des environnements de production exigeants, où vitesse et coût ne sont pas négociables.

PixelRAG surpasse les analyseurs de texte en précision et réduit de 10 fois le coût en tokens des agents IA

Une équipe de chercheurs des universités UC Berkeley, Princeton et EPFL, en collaboration avec Databricks, a publié cette semaine un article présentant PixelRAG, un système de recherche augmentée par récupération (RAG) qui abandonne complètement l'étape de conversion en texte des pages web. Plutôt que de transformer le HTML en texte brut avant de l'indexer, PixelRAG prend des captures d'écran des pages, découpe ces images en tuiles de 1 024 pixels et les encode directement dans un index vectoriel interrogeable par un modèle de langage à vision. Le système a été testé sur 30 millions de tuiles couvrant l'intégralité des 7 millions d'articles de Wikipédia, et surpasse les pipelines RAG traditionnels sur six benchmarks distincts, avec un gain de précision allant jusqu'à 18,1 % par rapport aux approches textuelles. L'enjeu est considérable pour toutes les entreprises qui déploient des agents IA sur leurs bases documentaires internes ou sur le web ouvert. Les pipelines RAG actuels échouent pour trois raisons mesurables : la conversion HTML détruit 36,6 % des réponses avant même l'indexation, les infoboxes bourrées de mots-clés écrasent les paragraphes pertinents dans 55,2 % des cas, et les 8,2 % restants sont perdus lors de la lecture finale à cause d'une mise en forme aplatie. PixelRAG contourne ces trois problèmes d'un coup en conservant la hiérarchie visuelle, les tableaux, le gras et la mise en page, que les parseurs textuels éliminent irrémédiablement. Le système réduit également les coûts en tokens des agents IA d'un facteur 10, puisque les tuiles images sont bien plus compactes que les longues chaînes de texte nettoyé qu'un parseur produit habituellement. L'architecture repose sur quatre étapes entièrement visuelles : le rendu des pages via Playwright à une largeur fixe de 875 pixels, leur découpage en tuiles stockées localement hors ligne, leur encodage en vecteurs de 2 048 dimensions grâce au modèle Qwen3-VL-Embedding-2B dans un index FAISS d'environ 120 Go, et enfin la lecture par un modèle vision-langage capable d'interpréter simultanément contenu et mise en page. Le choix de cette approche reflète une conviction plus large des auteurs : améliorer les parseurs est une course sans fin, chaque site web exigeant un traitement sur mesure, alors que les modèles de vision récents permettent désormais de traiter directement la page rendue comme le ferait un humain. Yichuan Wang, doctorant à UC Berkeley et auteur principal, résume l'ambition : construire un système de récupération universel, sans ingénierie spécifique par site, en s'appuyant sur les progrès rapides des modèles multimodaux.

💬 Arrêter d'améliorer les parseurs et passer aux screenshots directement, c'est le genre de pivot qu'on n'ose pas faire parce que ça remet tout en question. Là, Berkeley, Princeton et l'EPFL montrent que ça marche vraiment, avec 18% de gain en précision et un facteur 10 sur les tokens. Reste à voir ce que ça donne à l'échelle d'une base documentaire d'entreprise, mais sur le principe, c'est du solide.

Implémentation de Microsoft OpenMementos : analyse des traces, compression de contexte et préparation des données d'affinage

Microsoft a publié OpenMementos, un jeu de données conçu pour entraîner des modèles de langage capables de raisonnement long, structuré et compressible. Le dataset, disponible sur HuggingFace sous l'identifiant microsoft/OpenMementos, organise chaque trace de raisonnement en une série de blocs délimités par des tokens spéciaux (<|blockstart|>, <|blockend|>) accompagnés chacun de leur résumé condensé, appelé memento, encadré par <|summarystart|> et <|summaryend|>. Un tutoriel technique détaillé, conçu pour fonctionner directement dans Google Colab, montre comment accéder au dataset en mode streaming sans le télécharger intégralement, analyser sa structure interne, mesurer les taux de compression bloc-par-bloc sur 500 exemples répartis selon le domaine et la source, puis préparer les données pour un fine-tuning supervisé. L'ensemble du pipeline repose sur des bibliothèques Python standard : HuggingFace Datasets, Transformers, Pandas et Matplotlib. La valeur centrale d'OpenMementos réside dans son architecture de compression. Chaque réponse longue d'un modèle de raisonnement est découpée en blocs discrets, puis chaque bloc est automatiquement réduit à un memento de quelques phrases. Le tutoriel mesure ce rapport de compression en caractères et en mots par domaine, révélant à quel point les mementos permettent de préserver l'essentiel du raisonnement avec une fraction du volume textuel. Cette structure est directement exploitable pour l'entraînement : plutôt que de forcer un modèle à reproduire intégralement des chaînes de pensée verbeuses, on peut l'entraîner à produire des résumés intermédiaires compacts, ce qui réduit les coûts de calcul à l'inférence tout en maintenant la cohérence logique sur des problèmes complexes. Ce travail s'inscrit dans une tendance de fond qui agite les laboratoires d'IA depuis fin 2024 : comment rendre les modèles de raisonnement économiquement viables. Les approches chain-of-thought et les architectures de type "thinking model", popularisées par OpenAI avec o1 puis par DeepSeek-R1 et Qwen-QwQ, génèrent des traces de raisonnement extrêmement longues et coûteuses à stocker, transmettre et inférer. Microsoft répond à ce défi avec une solution de compression supervisée des traces, en annotant explicitement les résumés intermédiaires au niveau des blocs. OpenMementos fournit ainsi une base d'entraînement structurée pour des modèles capables de "penser de façon compacte", une propriété qui pourrait devenir déterminante à mesure que les applications industrielles exigent des latences et des coûts d'inférence maîtrisés sur des tâches de raisonnement multi-étapes.

Google AI publie Auto-Diagnose : un système basé sur des LLM pour diagnostiquer les échecs de tests d'intégration à grande échelle

Une équipe de chercheurs de Google a publié Auto-Diagnose, un outil basé sur le modèle Gemini 2.5 Flash qui analyse automatiquement les logs d'échecs de tests d'intégration, identifie la cause racine et poste un diagnostic structuré directement dans l'interface de revue de code interne de Google, appelée Critique. Évalué manuellement sur 71 pannes réelles couvrant 39 équipes distinctes, l'outil a correctement identifié la cause racine dans 90,14 % des cas. À grande échelle, il a déjà tourné sur 52 635 tests défaillants distincts, représentant 224 782 exécutions sur 131 130 changements de code écrits par 22 962 développeurs différents. Le taux de retours négatifs ("Not helpful") n'atteint que 5,8 %, tandis que 84,3 % des 517 retours reçus correspondent à des demandes "Please fix" de la part de reviewers, signe que les diagnostics sont jugés suffisamment fiables pour déclencher une action immédiate. L'enjeu est concret : diagnostiquer un échec de test d'intégration est structurellement plus difficile que de déboguer un test unitaire. Dans une enquête interne menée auprès de 116 développeurs Google, 38,4 % des échecs de tests d'intégration prenaient plus d'une heure à diagnostiquer, et 8,9 % plus d'une journée, contre respectivement 2,7 % et 0 % pour les tests unitaires. La raison est simple : les logs du pilote de test n'exposent généralement qu'un symptôme générique, un timeout ou une assertion échouée, tandis que l'erreur réelle est enfouie dans l'un des nombreux composants du système testé. Auto-Diagnose résout ce problème en agrégeant tous les logs, les triant par horodatage en un flux unique, puis en guidant le modèle via un protocole explicite étape par étape pour remonter à la source réelle de l'échec. Sur le plan technique, le système fonctionne sans fine-tuning : Gemini 2.5 Flash est appelé avec une température de 0,1 pour des résultats quasi-déterministes, à partir d'un prompt d'ingénierie pur incluant des contraintes négatives strictes, par exemple l'interdiction de tirer une conclusion si les logs du composant fautif sont absents. Chaque exécution consomme en moyenne 110 617 tokens en entrée et produit 5 962 tokens en sortie, avec une latence médiane de 56 secondes et un 90e percentile à 346 secondes, suffisamment rapide pour que le développeur voie le diagnostic avant de changer de contexte. Ce travail illustre une tendance plus large chez les grands groupes technologiques : utiliser les LLM non pas pour écrire du code, mais pour absorber la complexité observationnelle des systèmes distribués, là où l'humain peine à tenir l'ensemble des signaux en tête simultanément.