# Limiter le coût d’un LLM qui explique chaque erreur remontée dans Sentry

> Snippet d'échantillonnage pour n'envoyer à un LLM que les erreurs les plus fréquentes plutôt que chaque occurrence, sur un site à fort trafic déjà instrumenté avec Sentry.

- Auteur : WordPress Développement
- Publié le : 2023-12-29
- Mis à jour le : 2023-12-29
- Catégorie : IA & MCP
- URL : https://www.wpmoderne.fr/ia-mcp/limiter-cout-llm-erreurs-sentry/

## L’essentiel

- Chaque occurrence d'erreur envoyée au LLM coûtait sans apporter d'information nouvelle
- Un échantillonnage par empreinte d'erreur a réduit la facture de 89 %
- Le regroupement natif de Sentry facilite ce filtrage

`event_count: 4 812` — ce chiffre, affiché dans le tableau de bord Sentry un matin de fin décembre, correspondait à une seule et même erreur PHP, survenue 4 812 fois en une nuit sur un pic de trafic inhabituel. Le hook connecté à un LLM pour expliquer chaque erreur en langage clair avait pourtant tenté de l'expliquer 4 812 fois, générant autant d'appels facturés à l'identique.

Ce billet propose un snippet d'échantillonnage pour éviter ce gaspillage, sans revenir sur la configuration initiale de Sentry, déjà en place sur ce site à fort trafic.

## Le problème du coût par occurrence

Le hook initial, branché sur l'événement `before_send` de Sentry côté PHP, envoyait systématiquement le message d'erreur et sa trace complète à un LLM pour en générer une explication en français, utile aux développeurs juniors de l'équipe. Cette explication était identique, mot pour mot, que l'erreur survienne une fois ou quatre mille fois dans la même heure — seul le contexte d'exécution changeait, rarement de façon significative.

Sur le mois de décembre, la facture du fournisseur de LLM a bondi de 340 % par rapport à la moyenne des mois précédents, entièrement imputable à ce pic d'erreurs répétitives plutôt qu'à une réelle augmentation du nombre de bugs distincts.

## Le principe de l'échantillonnage par empreinte

> L'essentiel à retenir : Chaque occurrence d'erreur envoyée au LLM coûtait sans apporter d'information nouvelle ; Un échantillonnage par empreinte d'erreur a réduit la facture de 89 % ; Le regroupement natif de Sentry facilite ce filtrage

Sentry regroupe déjà nativement les événements par empreinte (*fingerprint*), calculée à partir du message et de la trace d'appel. L'idée a été de s'appuyer sur ce regroupement natif plutôt que d'en recréer un manuellement : n'envoyer une erreur au LLM que pour la première occurrence d'une empreinte donnée sur une fenêtre de temps définie.

```
function envoyer_erreur_au_llm_si_nouvelle( $event, $hint ) {
    $empreinte = $event->getFingerprint()
        ? implode( '-', $event->getFingerprint() )
        : md5( $event->getMessage() );

    $transient_key = 'llm_explique_' . $empreinte;

    if ( false !== get_transient( $transient_key ) ) {
        return $event; // deja explique recemment, on ne rappelle pas le LLM
    }

    set_transient( $transient_key, true, HOUR_IN_SECONDS );

    demander_explication_llm( $event->getMessage(), $event->getExtra() );

    return $event;
}

add_filter( 'sentry_before_send', 'envoyer_erreur_au_llm_si_nouvelle', 10, 2 );
```

Le `transient` WordPress, avec une durée d'une heure, sert de verrou simple : tant qu'une empreinte d'erreur a déjà été expliquée récemment, aucun nouvel appel n'est déclenché, quelle que soit la fréquence de récurrence de l'erreur pendant cette fenêtre.

## Les résultats après un mois

| Indicateur | Avant échantillonnage | Après échantillonnage |
| --- | --- | --- |
| Appels au LLM par mois | 18 400 | 2 020 |
| Empreintes d'erreurs distinctes | 187 | 187 |
| Coût mensuel du LLM | 412 € | 46 € |

Le nombre d'empreintes distinctes réellement expliquées est resté strictement identique avant et après : aucune information utile n'a été perdue, seule la répétition inutile a été supprimée.

## Les ajustements complémentaires

- La fenêtre d'une heure a été portée à quatre heures pour les erreurs de faible gravité, moins urgentes à ré-expliquer.
- Un contournement manuel a été ajouté pour forcer une nouvelle explication en cas de modification du code source entre deux occurrences.
- Les erreurs critiques (niveau `fatal`) conservent un envoi systématique, sans échantillonnage, par prudence.

> Expliquer une erreur qui s'est déjà produite mille fois n'apporte rien de plus à la millième occurrence : le budget alloué au LLM doit suivre la nouveauté de l'information, pas sa fréquence brute.

## En résumé

Un LLM branché sur un flux d'erreurs à fort trafic doit systématiquement passer par un filtre d'échantillonnage avant tout appel facturé. S'appuyer sur le regroupement natif de Sentry par empreinte, plutôt que de recalculer une logique de déduplication maison, a suffi ici à réduire la facture de 89 % sans perte d'information utile pour l'équipe technique.

Ce type d'échantillonnage se généralise d'ailleurs bien au-delà du seul cas de Sentry : tout hook qui envoie systématiquement une donnée répétitive à un LLM (un log applicatif, un flux de commentaires similaires, une file d'événements redondants) gagne à passer par le même filtre avant appel. La règle reste identique : ne payer un appel de LLM que pour une information réellement nouvelle, jamais pour la répétition d'une information déjà traitée dans une fenêtre de temps raisonnable.