# Cache d’objet persistant pour une réponse de LLM : groupe et durée de vie

> Choisir le groupe de cache et la durée de vie adaptés pour éviter de rejouer un appel coûteux à une API de modèle de langage sur une page à fort trafic.

- Auteur : WordPress Développement
- Publié le : 2023-07-09
- Mis à jour le : 2023-07-09
- Catégorie : IA & MCP
- URL : https://www.wpmoderne.fr/ia-mcp/cache-objet-persistant-reponse-llm-ttl/

## L’essentiel

- Un appel de LLM répété pour un même contenu est une dépense évitable
- Le groupe de cache isole les clés sans risque de collision
- Le TTL dépend de la fréquence de mise à jour du contenu source

500 visites en une heure sur un article dont la description générée par un modèle de langage n'a pas changé depuis sa publication : combien de ces 500 visites déclenchent, sans cache, un nouvel appel identique à l'API du modèle ? Sur un code non protégé, la réponse est simple : autant que de visites, ce qui revient à payer plusieurs centaines de fois le même résultat.

Le cache d'objet persistant de WordPress, via les fonctions `wp_cache_get` et `wp_cache_set`, répond directement à ce problème, à condition de choisir correctement le groupe de cache et la durée de vie associée à la clé.

## Pourquoi ne pas se contenter d'une transient

Les transients, via `get_transient` et `set_transient`, offrent une API similaire mais persistent en base de données par défaut, en l'absence d'objet cache externe. Sur un site à fort trafic, cette persistance en base ajoute une charge d'écriture évitable, alors que le cache d'objet, lorsqu'il est soutenu par une extension comme Redis ou Memcached, reste en mémoire et se prête mieux à des lectures très fréquentes.

```
function obtenir_resume_ia( int $post_id ): ?string {
    $cle    = 'resume_' . $post_id;
    $groupe = 'mon_plugin_ia';

    $resume = wp_cache_get( $cle, $groupe );
    if ( false !== $resume ) {
        return $resume;
    }

    $resume = appeler_api_resume( $post_id );
    if ( null === $resume ) {
        return null;
    }

    wp_cache_set( $cle, $resume, $groupe, HOUR_IN_SECONDS * 6 );

    return $resume;
}
```

## Choisir un groupe de cache dédié

> L'essentiel à retenir : Un appel de LLM répété pour un même contenu est une dépense évitable ; Le groupe de cache isole les clés sans risque de collision ; Le TTL dépend de la fréquence de mise à jour du contenu source

Le troisième paramètre de `wp_cache_set`, le groupe, isole les clés du plugin de celles utilisées par le cœur ou par d'autres extensions. Sans groupe dédié, une clé nommée simplement `resume_42` pourrait entrer en collision avec une clé posée ailleurs dans le code, avec des conséquences difficiles à diagnostiquer.

```
add_action( 'init', function () {
    wp_cache_add_global_groups( array( 'mon_plugin_ia' ) );
} );
```

Déclarer le groupe comme global via `wp_cache_add_global_groups` a un sens particulier sur une installation multisite : le cache devient alors partagé entre les différents sites du réseau plutôt que dupliqué pour chacun, ce qui convient à un contenu qui ne dépend pas du site courant.

## Déterminer la durée de vie adaptée

Le choix du TTL dépend directement de la fréquence à laquelle le contenu source est susceptible de changer. Un résumé généré à partir du contenu d'un article ne devrait rester en cache que tant que l'article n'est pas modifié :

- Invalider explicitement la clé lors de la mise à jour de l'article, via `save_post`
- Fixer malgré tout un TTL de secours, pour couvrir les mises à jour effectuées hors du cycle normal de publication
- Éviter un TTL trop court qui annulerait le bénéfice du cache sans réduire significativement le risque d'un contenu périmé

```
add_action( 'save_post', function ( int $post_id ) {
    wp_cache_delete( 'resume_' . $post_id, 'mon_plugin_ia' );
} );
```

### Le cas des réponses à faible probabilité de répétition

Toutes les réponses de modèle de langage ne bénéficient pas également du cache. Une réponse générée à partir d'une saisie libre d'un visiteur, différente à chaque fois, n'a que peu de chances d'être redemandée à l'identique : mettre en cache ce type de réponse consomme de la mémoire sans bénéfice réel. Le cache trouve sa pertinence sur les contenus dérivés d'une source stable : un article, une fiche produit, une page.

> Un cache mal ciblé coûte de la mémoire sans réduire la dépense réelle : mieux vaut réserver le cache d'objet aux réponses dérivées d'un contenu qui change rarement.

## Vérifier la présence d'un objet cache persistant

Sur un hébergement sans extension de cache d'objet externe, `wp_cache_set` reste fonctionnel mais ne persiste qu'en mémoire pour la durée de la requête en cours, ce qui annule l'intérêt recherché ici. La fonction `wp_using_ext_object_cache()` permet de vérifier la présence d'un objet cache persistant avant de compter sur ce mécanisme pour réduire réellement les appels à l'API.

## En résumé

Le cache d'objet persistant réduit efficacement les appels redondants à une API de modèle de langage, à condition de choisir un groupe dédié, d'invalider explicitement la clé lors des mises à jour de contenu, et de réserver ce mécanisme aux réponses issues d'un contenu source suffisamment stable pour justifier la mise en cache.