Comment Mendral a réduit les coûts des LLM en passant à Opus : schéma de triage, accès SQL et architecture de sous-agent

Mendral a récemment publié des détails sur la façon dont ils ont amélioré leur système avec Opus 4.6 pour l'analyse des échecs CI tout en réduisant les coûts globaux d'IA générative par rapport à leur configuration précédente avec Sonnet 4.0. La clé réside dans une architecture qui sépare le triage de l'investigation et utilise des sous-agents peu coûteux pour le travail lourd.

Architecture : un trieur bon marché, un planificateur coûteux

Sur environ 4 000 échecs CI analysés, 3 187 étaient des doublons — un test instable connu, un problème d'infrastructure ou un incident réseau. Réveiller un modèle coûteux pour ceux-ci est un gaspillage. Mais la déduplication n'est pas déterministe : un même job peut échouer pour différentes raisons. Leur solution est un modèle de trieur :

• Un agent Haiku gère la tâche étroite : décider si un échec est déjà suivi. Il utilise la correspondance exacte et la recherche sémantique (pgvector) sur les messages d'erreur connus. Deux chaînes différentes comme operator does not exist bigint character varying et migration type mismatch on installation_id ont la même cause racine — la recherche sémantique les détecte.
• En cas de doute, Haiku escalade vers Opus 4.6. Un faux positif coûte peu ; un faux négatif laisse passer un vrai bug.
• 4 échecs sur 5 n'atteignent jamais Opus. Une correspondance du trieur coûte environ 25 fois moins qu'une investigation complète.

Laissez les agents récupérer le contexte, ne le poussez pas

Au lieu de bourrer les logs de 200 000+ lignes dans les prompts, les agents reçoivent une interface SQL vers ClickHouse. Il y a une table brute (github_logs, une ligne par ligne de log) et des vues matérialisées avec des données pré-agrégées : taux d'échec par workflow, temps d'exécution des jobs, nombre de résultats. La plupart des investigations commencent par les vues pour cibler, puis plongent dans les logs bruts. Si une requête renvoie trop de lignes, le système tronque et suggère une vue plus spécifique. Si les logs ne sont pas encore ingérés, les agents utilisent l'interface en ligne de commande GitHub.

Les modèles coûteux planifient, les modèles bon marché exécutent

Opus forme une hypothèse et génère des sous-agents Haiku limités à un niveau de profondeur — pas de ramification illimitée. Chaque sous-agent reçoit un prompt d'Opus : exactement quoi chercher et comment. Exemple d'un cas réel :

Trois jobs CI Storybook ont échoué sur le même commit, en plantant à pnpm install. Opus a envoyé un sous-agent pour récupérer les messages d'erreur de cette étape. ClickHouse n'avait pas encore les logs, donc le sous-agent a utilisé l'interface en ligne de commande GitHub et a renvoyé : gyp ERR! not found: make — [email protected] ne pouvait pas compiler car make n'était pas sur l'exécuteur. Opus a ensuite interrogé ClickHouse pour la tendance des échecs sur 14 jours, a trouvé le point d'inflexion et a escaladé. Les prompts des sous-agents sont explicites : "Récupérez les logs CI pour cette exécution. Renvoyez les messages d'erreur exacts de l'étape pnpm install, la sortie d'erreur complète, en particulier les 50 à 100 dernières lignes."

À qui cela s'adresse

Les équipes construisant des agents alimentés par l'IA pour le débogage CI ou toute tâche où la taille du contexte et le coût sont des préoccupations.