Raisonnement hybride : un seul modèle, deux régimes
RaisonnementArchitectureCoûtRoutage2025-02-2410 min
Le même modèle peut répondre en une seconde ou réfléchir pendant une minute. Décider quand, par règle plutôt qu'au cas par cas, est tout le travail.
La simplification que ça apporte
Un modèle unique capable des deux régimes supprime la gestion de deux intégrations distinctes, et rend le choix du régime réversible à chaque appel. C'est un gain d'architecture réel.
Avant, arbitrer entre rapidité et profondeur imposait deux modèles, donc deux jeux de paramètres, deux comportements à connaître, deux jeux de tests. Beaucoup d'équipes y renonçaient et gardaient un seul modèle, en payant soit la lenteur soit l'imprécision.
Avec un modèle hybride, le régime devient un paramètre de la requête. La bascule ne coûte rien, ce qui permet enfin de traiter la question comme un réglage plutôt que comme une décision structurante.

Décider par règle, jamais au cas par cas
Le régime doit être fixé par type d'appel dans le code, pas déduit à la volée par un modèle qui évaluerait la difficulté. Cette seconde option paraît élégante et coûte cher.
Faire évaluer la difficulté ajoute un appel, donc de la latence et une source d'erreur. Pire, elle rend le comportement du système imprévisible : la même question peut être traitée de deux façons selon des variations mineures de formulation, ce qui rend les incidents impossibles à reproduire.
La règle statique est plus simple et fonctionne mieux. Une recherche documentaire part toujours en régime direct. Un contrôle de conformité croisant plusieurs textes part toujours en régime réfléchi. La décision est écrite une fois, lisible, et modifiable.
Elle se révise au même rythme que le reste de la répartition, chaque trimestre, avec le jeu de tests, la discipline posée dans choisir le palier, pas le modèle.
Les quatre familles et leur régime
- Récupération et restitution documentaire : régime direct. Aucun raisonnement ne fait apparaître ce que la recherche n'a pas trouvé.
- Extraction et classification : régime direct, avec un petit modèle si possible. Voir le petit modèle change l'arbitrage.
- Contrôles croisant plusieurs règles : régime réfléchi, en traitement différé pour absorber la latence.
- Analyse de cohérence entre documents : régime réfléchi, avec un plafond de jetons par requête.
Le piège de la latence variable
Un système dont certaines réponses arrivent en une seconde et d'autres en quarante secondes est perçu comme cassé, même quand les deux comportements sont voulus. C'est un problème d'interface avant d'être un problème technique.
L'utilisateur n'a aucune information sur le régime employé. Il constate simplement que le système est parfois instantané et parfois figé, ce qu'il interprète comme une panne intermittente.
La correction est peu coûteuse : annoncer le régime avant de commencer. « Cette analyse demande une minute » transforme une attente subie en attente acceptée. Les travaux sur la perception des temps de réponse sont constants sur ce point depuis des décennies.
J'ajoute une règle pratique : au-delà de cinq secondes, il faut afficher une progression, même approximative. En dessous, un simple indicateur d'activité suffit. Ce détail décide d'une part importante de l'adoption, comme le montre la latence devient un critère de conception.
Ce que ça change pour le budget
Un régime réfléchi consomme des jetons de façon peu prévisible, ce qui impose un plafond par requête plutôt qu'une estimation moyenne. La prévision budgétaire change de nature.
Sur un régime direct, le coût se calcule à l'avance avec précision. Sur un régime réfléchi, une question difficile peut consommer dix fois la moyenne, et la moyenne cesse d'être un bon prédicteur.
La parade tient en deux réglages. Un plafond de jetons de réflexion par requête, appliqué par le système et non par une consigne. Et une surveillance au quantile élevé plutôt qu'en moyenne, pour repérer la dispersion avant qu'elle n'apparaisse sur la facture.
Ces deux réglages coûtent une heure et évitent l'incident classique : une poignée de requêtes pathologiques qui consomment l'essentiel du budget mensuel sans que personne ne comprenne pourquoi.
La règle de conception qui simplifie tout
Un régime par type d'appel, écrit dans le code, révisé chaque trimestre. Toute tentative de décider dynamiquement du régime ajoute un appel, une source d'erreur et une imprévisibilité qui rend les incidents irreproductibles.
Ce que le régime réfléchi ne corrige pas
Une mauvaise récupération, un corpus désordonné et un périmètre mal défini restent exactement aussi problématiques en régime réfléchi. C'est le rappel qui évite de dépenser pour rien.
Le schéma que je rencontre le plus souvent : un système donne des réponses insatisfaisantes, quelqu'un active le régime réfléchi, la facture triple et la qualité ne bouge pas. Le diagnostic était faux dès le départ.
La vérification à faire avant tout basculement tient en une question : l'information nécessaire figurait-elle dans le contexte fourni au modèle ? Si la réponse est non, aucun raisonnement ne la fera apparaître, et le travail est en amont, dans la récupération, le découpage ou le corpus lui-même.
Cette vérification prend dix minutes et évite des mois de dépense mal orientée. Elle relève du principe posé dans le corpus est le projet.
Questions fréquentes
- Faut-il laisser le modèle décider du régime ?
Non. Cela ajoute un appel, de la latence et une imprévisibilité qui rend les incidents irreproductibles. Le régime se fixe par type d'appel dans le code, et se révise chaque trimestre.
- Comment gérer une latence très variable ?
En l'annonçant avant de commencer. « Cette analyse demande une minute » transforme une attente subie en attente acceptée ; au-delà de cinq secondes, il faut afficher une progression.
- Comment budgéter un régime réfléchi ?
Avec un plafond de jetons par requête appliqué par le système, et une surveillance au quantile élevé plutôt qu'en moyenne, car une question difficile peut consommer dix fois la moyenne.
- Le régime réfléchi corrige-t-il de mauvaises réponses ?
Seulement si l'information nécessaire était présente dans le contexte. Neuf fois sur dix, le problème vient de la récupération, et le raisonnement supplémentaire triple la facture sans rien améliorer.