Aller au contenu principal

LLM Analytics

Open in QuickMonitoring→ Sites → [Votre site] → Événements LLM

Si vous utilisez un LLM dans votre produit (via ChatGPT, Claude, Gemini ou toute autre API), QuickMonitoring peut enregistrer chaque paire prompt/réponse et vous fournir des analyses : consommation de tokens, latence, taux d'erreur, coût estimé et tendances d'utilisation. Le suivi s'active via le SDK QuickMonitoring en quelques lignes de code.

Ce que vous verrez​

Allez dans Sites → votre site → Événements LLM (barre latérale).

Le tableau de bord affiche :

  • Volume d'événements — nombre total d'appels LLM sur la période sélectionnée, avec graphique temporel
  • Tokens utilisés — tokens de prompt et tokens de complétion, ventilés par modèle
  • Latence moyenne — temps de réponse moyen de votre LLM, avec histogramme de distribution
  • Taux d'erreur — pourcentage d'appels ayant échoué ou dépassé le délai d'attente
  • Coût estimé — estimation du coût en dollars basée sur les tarifs connus du modèle utilisé
  • Liste des événements récents — journal détaillé avec, pour chaque appel : le prompt envoyé, la complétion reçue, le modèle utilisé, la latence, le nombre de tokens et le statut

Chaque événement est cliquable pour voir le détail complet du prompt et de la réponse.

Comment l'utiliser​

Étape 1 — Installer le SDK QuickMonitoring​

Si ce n'est pas encore fait, installez le SDK dans votre application :

npm install @quickmonitoring/sdk

Étape 2 — Initialiser le SDK​

import { QuickMonitoring } from '@quickmonitoring/sdk';

const qm = new QuickMonitoring({
  siteKey: 'votre-clé-de-site',
});

Étape 3 — Enregistrer les événements LLM​

Encapsulez vos appels LLM avec la méthode trackLLMEvent :

// Avant l'appel LLM
const startTime = Date.now();

const response = await openai.chat.completions.create({
  model: 'gpt-4o',
  messages: [{ role: 'user', content: userPrompt }],
});

// Après l'appel LLM
qm.trackLLMEvent({
  model: 'gpt-4o',
  prompt: userPrompt,
  completion: response.choices[0].message.content,
  promptTokens: response.usage.prompt_tokens,
  completionTokens: response.usage.completion_tokens,
  latencyMs: Date.now() - startTime,
  status: 'success',
});

Étape 4 — Gérer les erreurs​

try {
  const response = await openai.chat.completions.create({ ... });
  qm.trackLLMEvent({ status: 'success', ... });
} catch (error) {
  qm.trackLLMEvent({
    model: 'gpt-4o',
    prompt: userPrompt,
    status: 'error',
    errorMessage: error.message,
    latencyMs: Date.now() - startTime,
  });
}

Étape 5 — Consulter les données​

Une fois les événements envoyés, allez dans Sites → votre site → Événements LLM. Les données apparaissent en temps quasi-réel (délai de quelques secondes). Utilisez le sélecteur de période pour analyser les tendances sur 24 heures, 7 jours ou 30 jours.

Condition de réussite​

✅ Vous avez obtenu ce badge lorsque la section Événements LLM affiche au moins 1 événement enregistré avec un statut valide.

Problèmes fréquents​

  • Aucun événement ne s'affiche après intégration — Vérifiez que la clé de site utilisée dans le SDK correspond bien au site sur lequel vous consultez les données. Vérifiez également que les appels trackLLMEvent s'exécutent bien (ajoutez un console.log temporaire). Assurez-vous que l'initialisation du SDK se fait avec la bonne clé avant tout appel de tracking.

  • Les tokens s'affichent à 0 — Si votre fournisseur LLM ne retourne pas les statistiques d'utilisation (usage) dans la réponse, les tokens resteront à 0. Certaines configurations ou modèles ne renvoient pas ces données par défaut. Vérifiez les paramètres de votre requête API (ex. : stream: true désactive souvent les statistiques d'utilisation dans la réponse en streaming).

  • Le coût estimé semble incorrect — L'estimation de coût est basée sur les tarifs publics connus au moment du développement. Les prix changent fréquemment. Utilisez cette valeur comme indicateur d'ordre de grandeur, et vérifiez toujours votre facture directement auprès de votre fournisseur LLM.

  • La latence affichée est anormalement haute — La latence enregistrée est la latence de bout en bout mesurée dans votre code, pas la latence de traitement du LLM seul. Cela inclut le temps réseau, le traitement de votre serveur et l'envoi de la requête. C'est le comportement attendu.