TL;DR builders
Ce document est une traduction et adaptation d'un guide de prototypage inspiré par Interfaze (voir https://arxiv.org/abs/2602.04101). Message central du papier : traiter les applications LLM comme un problème de construction de contexte + exécution d'actions plutôt que comme le choix d'un modèle monolithique. L'architecture combine (faits rapportés) :
- Couche Perception : pile de DNN hétérogènes et petits LMs pour OCR, parsing de graphiques et ASR multilingue ;
- Couche Construction de Contexte : crawler, indexeur et parseur pour transformer pages web, code, PDFs en état structuré compact ;
- Couche Action : retrieval, exécution de code en sandbox, pilotage de navigateur headless ;
- Contrôleur léger : décide quels petits modèles/actions exécuter et forwarde le contexte distillé vers un LLM final via un endpoint unique.
Interfaze‑Beta atteint des scores rapportés dans le papier : MMLU 91.4%, MMLU‑Pro 83.6%, GPQA‑Diamond 81.3%, LiveCodeBench v5 57.8%, AIME‑2025 90.0%, MMMU (val) 77.3%, ChartQA 90.9% et Common Voice v16 90.8% (source : https://arxiv.org/abs/2602.04101).
Note méthodologique : conservez la reproductibilité et journalisez les entrées brutes à chaque étape pour un debugging déterministe.
Objectif et resultat attendu
Objectif principal (fait rapporté dans le papier) : fournir une API de bout en bout acceptant des requêtes multimodales (PDF, graphiques, pages web, audio), exécuter perception + actions, construire un contexte distillé compact, puis renvoyer une réponse produite par un LLM final — la majorité des requêtes doit être tenue par la pile de petits modèles/outils (voir https://arxiv.org/abs/2602.04101).
Résultats attendus pour l'équipe technique (propositions pratiques) :
- Prototype avec endpoint contrôleur unique et clients d'exemple ;
- Mesures : fraction de requêtes résolues sans LLM (objectif initial > 70%), latence moyenne E2E < 1 000 ms pour cas simples, coût estimé par 1 000 requêtes ;
- Banc d'essai : traces montrant proportion petits‑modèles vs escalades au LLM (objectif pilote = 1 000 requêtes pour évaluation).
Livrables de validation : harness de test, rapports de latence (p50, p95), estimation coût/1 000 requêtes (hypothèse opérationnelle).
(voir https://arxiv.org/abs/2602.04101)
Stack et prerequis
Composants logiques requis (faits rapportés dans le papier) :
- Perception : DNN hétérogènes + petits LMs pour OCR, parsing graphique, ASR ;
- Construction de contexte : crawler, indexeur, parseur ;
- Action : retrieve, browse, execute(code) sandbox ;
- Contrôleur léger : routing vers petits modèles/outils et forwarding du contexte distillé vers le LLM final (source : https://arxiv.org/abs/2602.04101).
Prérequis minimaux pour un prototype (propositions) :
- Repo structuré + CI ;
- GPU(s) pour inférences perception (recommandé pour OCR lourdes) ;
- Stockage pour artefacts parsés / embeddings (vector DB) ;
- Accès à un LLM (hôte ou self‑hosted) pour la génération finale.
Remarque : le papier décrit l'architecture et l'évaluation mais laisse les choix d'infra aux développeurs (voir https://arxiv.org/abs/2602.04101).
Implementation pas a pas
Les étapes ci‑dessous sont une proposition pratique d'implémentation inspirée par l'architecture décrite dans l'article (https://arxiv.org/abs/2602.04101).
- Scaffold du repo & endpoint API
# scaffold minimal
git clone https://example.com/your-interfaze-proto.git
cd your-interfaze-proto
mkdir infra src tests
python -m http.server 8000 &
- Modules de perception (OCR, parser graphique, ASR)
- Chaque module renvoie JSON structuré (champs, tables, blocs, timestamps). Tests : 10–50 entrées d'essai par module pour commencer.
- Construction de contexte
- Crawlez, parsez et indexez ; stockez embeddings et état compact dans une vector DB. Timeouts recommandés : perception 5 000 ms, action 15 000 ms.
- Couche d'action
- Interfaces : retrieve(document), browse(url), execute(code_snippet) en sandbox. Ajoutez quotas CPU/mémoire et timeouts.
- Contrôleur léger & routage
- Utiliser une table de décision pour composer pipelines perception/action et un seuil d'escalade vers LLM (ex. forward si confiance < 10%).
Exemple de config (routing) :
# routing.yaml
decision_table:
pdf: [perception.ocr, context.parse, index.store]
chart: [perception.chart_parser, context.parse]
webpage: [action.browse, context.parse, index.store]
audio: [perception.asr, context.parse]
timeouts:
perception: 5000 # ms
action: 15000 # ms
escalation:
llm_forward_threshold: 0.10 # forward to LLM if small-stack confidence < 10%
- Intégration LLM & prompts
- Forwarder uniquement le contexte distillé (faits compacts, citations). Le papier signale que le LLM opère sur ce contexte distillé (source : https://arxiv.org/abs/2602.04101).
- Tests & métriques
- Collecter : % de requêtes traitées par petits modèles, latence globale (p50, p95), coût par requête ($ estimation), taux d'escalade. Itérer la table de décision.
Architecture de reference
Schéma haut niveau (fait rapporté) : Perception -> Construction de contexte -> Action -> Contrôleur léger -> Endpoint LLM final (voir https://arxiv.org/abs/2602.04101).
Table de décision (exemple comparatif)
| Entrée | Pipeline suggéré | Seuil d'escalade | |--------------|------------------------------------------|------------------:| | PDF (scan) | ocr → parse → index | confiance < 0.10 | | Chart image | chart_parser → facts | confiance < 0.05 | | Web dyn. | browse → dom_parse → index | confiance < 0.15 | | Audio (mult) | asr → timestamps → index | confiance < 0.08 |
Exemples d'input->output : PDF→tables structurées ; graphique→données+labels ; page dynamique→DOM+texte ; audio→transcription+timestamps. Scores multimodaux reportés pour Interfaze‑Beta : MMMU (val) 77.3%, ChartQA 90.9% (source : https://arxiv.org/abs/2602.04101).
Vue fondateur: ROI et adoption
Argument stratégique présenté dans l'article : déplacer la charge de la majorité des requêtes vers des piles de petits modèles/outils réduit la dépendance aux LLM monolithiques coûteux tout en maintenant une précision élevée — le papier montre des scores tels que MMLU 91.4% (source : https://arxiv.org/abs/2602.04101).
Parcours d'adoption recommandé (proposition) :
- Piloter verticales à signal fort pour perception (ex. rapports financiers, PDFs techniques) ;
- KPIs : % de requêtes résolues sans LLM (cible > 70%), coût par 1 000 requêtes, TTFB (time‑to‑first‑answer), satisfaction utilisateur ;
- Calcul ROI : estimer coût/1 000 requêtes avec et sans la pile pour définir temps de retour.
Cibles de benchmark issues du papier (faits) : MMLU‑Pro 83.6%, GPQA‑Diamond 81.3%, LiveCodeBench v5 57.8%, AIME‑2025 90.0%, Common Voice v16 90.8% (voir https://arxiv.org/abs/2602.04101).
Pannes frequentes et debugging
Modes d'échec courants (déduits du design et de l'importance des logs indiquée dans l'article) :
- Erreurs de perception (OCR / parsing graphique) : journaliser entrées brutes et JSON parsé ; prévoir re‑essais et tests adversariaux (voir https://arxiv.org/abs/2602.04101).
- Indices obsolètes : monitorer fraîcheur (TTL) et reindexation périodique.
- Mauvais routage : log des décisions, scores de confiance et A/B routing pour affiner règles.
- Actions runaway : sandbox stricte, quotas, kill‑switch.
Checklist de debugging (exemples opérationnels) :
- [ ] Capturer l'entrée brute à la frontière perception ;
- [ ] Stocker la sortie parsée avec IDs de corrélation ;
- [ ] Enregistrer la trace de décision du contrôleur pour chaque requête ;
- [ ] Collecter prompts et réponses LLM pour un échantillon d'escalades.
Alerting recommandé (valeurs de départ) : erreurs > 3/min, latence p95 > baseline +50%, fraction d'escalade > 30%.
(voir https://arxiv.org/abs/2602.04101)
Checklist production
Avant le déploiement large, validez :
- [ ] Config de déploiement et tests de montée en charge (target tests : 10k requêtes/jour, spike test 1k rps) ;
- [ ] Plan de canary / feature flags prêt (ex. canary = 2% du trafic initial) ;
- [ ] Observabilité : traces, métriques (p50, p95), pipeline d'évaluation humaine échantillonnée ;
- [ ] Sécurité : filtrage à l'ingestion, chiffrement en transit/au repos, sandbox et politiques de rétention.
Hypotheses / inconnues
- Choix concrets d'implémentation (vector DB, technologie de sandbox, librairie headless, checkpoints des petits modèles) ne sont pas précisés dans le papier et doivent être validés en contexte ;
- Valeurs opérationnelles proposées (timeouts 5 000 ms / 15 000 ms, canary 2%, seuil d'escalade 10%, pilot 1 000 requêtes) sont des recommandations à tester en charge réelle ;
- Considérations locales (conformité GDPR UK, régions cloud, politiques de rétention) sont des exigences réglementaires hors scope du papier et à traiter dans votre PIA.
Risques / mitigations
- Risque : perception de faible confiance → Mitigation : re‑essai, routage vers LLM/humain ;
- Risque : sandbox compromise → Mitigation : liste blanche syscalls, quotas CPU/mémoire, kill‑switch ;
- Risque : index obsolète → Mitigation : TTL, triggers de reindexation, validation périodique ;
- Risque : coûts LLM imprévus → Mitigation : contrôles stricts d'escalade, quotas de tokens (ex. 2k tokens par requête), monitoring coût $/1k reqs.
Prochaines etapes
- Choisir infra concrète (vector DB, sandbox, fournisseur LLM) et lancer un pilote de 1 000 requêtes ;
- Instrumenter métriques clés : fraction traitée par la petite pile, latence E2E (p50/p95), coût par requête ;
- Itérer table de décision pour réduire la fraction d'escalade au LLM tout en maintenant les scores cibles ;
- Effectuer une privacy impact assessment avant collecte de données utilisateur en production.
Référence principale : Interfaze — “The Future of AI is built on Task‑Specific Small Models” — https://arxiv.org/abs/2602.04101