À mesure que les grands modèles de langage (LLM) deviennent la colonne vertébrale des produits logiciels modernes, le défi de l'observabilité a basculé des métriques traditionnelles vers la compréhension sémantique. Les développeurs peinent souvent à déboguer pourquoi un modèle a halluciné ou pourquoi la latence a augmenté lors d'une inférence spécifique. OpenTelemetry (OTel), la norme de l'industrie pour l'observabilité, a évolué pour répondre à ces besoins uniques. En adoptant un cadre de traçage standardisé, vous pouvez obtenir des informations approfondies sur le cycle de vie de vos applications IA, de la construction du prompt à la génération des jetons.
Le passage aux conventions sémantiques
Historiquement, le traçage d'une application IA consistait à encapsuler les appels d'API externes avec des métriques HTTP génériques. Cependant, cela masque les détails critiques qui définissent les performances de l'IA : le nombre de jetons, les paramètres du modèle et les contextes des prompts. La Cloud Native Computing Foundation (CNCF) a récemment introduit des conventions sémantiques spécifiquement pour l'IA générative. Ces conventions définissent des attributs tels que gen_ai.system, gen_ai.request.model et gen_ai.response.token_count. En adhérant à ces normes, vos données d'observabilité deviennent portables et comparables entre différents back-ends, que vous utilisiez OpenAI, Anthropic ou des LLM locaux.
Instrumentation de vos appels LLM
Bien que des bibliothèques d'auto-instrumentation existent pour les frameworks populaires, l'instrumentation explicite offre un meilleur contrôle. Ci-dessous, un exemple pratique utilisant le SDK Python OpenTelemetry pour tracer une interaction LLM simple. Cette approche garantit que l'utilisation des jetons et les détails du modèle sont capturés sous forme de spans, vous permettant de corréler le coût avec des demandes utilisateur spécifiques.
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter
from opentelemetry.trace import Status, StatusCode
# Initialiser le fournisseur de traceurs
provider = TracerProvider()
provider.add_span_processor(BatchSpanProcessor(OTLPSpanExporter()))
tracer = trace.get_tracer(__name__)
def call_llm(prompt: str, model: str):
with tracer.start_as_current_span("llm.inference") as span:
span.set_attribute("gen_ai.system", "openai")
span.set_attribute("gen_ai.request.model", model)
span.set_attribute("gen_ai.prompt", prompt)
# Simuler l'appel LLM
response = "This is a simulated response."
input_tokens = len(prompt.split())
output_tokens = len(response.split())
# Enregistrer les métriques de jetons
span.set_attribute("gen_ai.usage.input_tokens", input_tokens)
span.set_attribute("gen_ai.usage.output_tokens", output_tokens)
span.set_attribute("gen_ai.response.text", response)
if "error" in response:
span.set_status(Status(StatusCode.ERROR, "LLM Error"))
else:
span.set_status(Status(StatusCode.OK))
return response
# Exemple d'utilisation
call_llm("Explain quantum entanglement simply", "gpt-4")
Agrégation des métriques pour le coût et les performances
Les traces montrent le parcours d'une seule requête, mais les métriques révèlent la santé de votre système au fil du temps. Vous devez agréger les comptes de jetons en données de séries temporelles. Cela vous permet de configurer des alertes pour les pics anormaux d'utilisation, qui indiquent souvent un bug dans votre ingénierie de prompts (par exemple, une boucle infinie ajoutant du contexte) ou une augmentation du trafic. En associant ces métriques à votre fournisseur de facturation, vous pouvez créer un tableau de bord des coûts en temps réel qui détaille les dépenses par modèle, fonctionnalité ou niveau d'utilisateur.
Déboguer le « Pourquoi »
Le véritable pouvoir d'OpenTelemetry dans l'IA réside dans sa capacité à lier cause et effet. Lorsqu'un utilisateur signale une mauvaise réponse, vous pouvez retracer la requête à travers la recherche dans la base de données vectorielle, la logique d'assemblage du prompt et enfin l'appel LLM. En incluant les scores de récupération et les versions des prompts en tant qu'attributs de span, vous pouvez déterminer si le modèle a échoué en raison d'une mauvaise qualité de récupération ou simplement d'un prompt ambigu. Ce niveau de granularité transforme le débogage d'un processus de conjecture en un processus axé sur les données.
Conclusion
L'intégration d'OpenTelemetry dans votre pile IA n'est plus optionnelle pour les systèmes de production. Elle fournit la transparence nécessaire pour surveiller les coûts, améliorer les performances des modèles et garantir la fiabilité. En tirant parti des conventions sémantiques, vous sécurisez l'avenir de votre stratégie d'observabilité, garantissant que, à mesure que les modèles d'IA évoluent, vos capacités de surveillance suivent le rythme. Commencez petit en instrumentant vos appels LLM principaux, puis élargissez progressivement pour inclure la recherche vectorielle et la logique des agents afin de construire une vue complète du comportement de votre application IA.