Une réponse correcte ne dit pas pourquoi le système a réussi. Phoenix collecte des traces OpenTelemetry enrichies par OpenInference afin de relier appels LLM, retrieval, outils, latence et consommation de tokens.
Lancer Phoenix localement
~~~bash python -m venv .venv source .venv/bin/activate pip install -U arize-phoenix arize-phoenix-otel openai openinference-instrumentation-openai phoenix serve ~~~
L’interface locale est accessible sur le port affiché au démarrage, généralement "http://localhost:6006". Pour Phoenix Cloud, définissez "PHOENIX_API_KEY" et "PHOENIX_COLLECTOR_ENDPOINT" selon l’espace créé.
Enregistrer l’instrumentation
Importez le module d’instrumentation avant de créer le client LLM :
~~~python from phoenix.otel import register
tracer_provider = register( project_name="assistant-support", auto_instrument=True, ) ~~~
"auto_instrument=True" détecte les instrumentations OpenInference installées. Après un appel OpenAI, ouvrez Phoenix et vérifiez la présence d’un span LLM avec modèle, durée, entrée, sortie et tokens.
Ajouter un span métier
~~~python from opentelemetry import trace from phoenix.otel import using_session, using_user
tracer = trace.get_tracer(__name__)
def answer(question: str, session_id: str, user_id: str) -> str: with using_session(session_id), using_user(user_id): with tracer.start_as_current_span("answer-support-question") as span: span.set_attribute("app.channel", "web") span.set_attribute("app.question_length", len(question)) response = call_llm(question) span.set_attribute("app.answer_length", len(response)) return response ~~~
Le span métier devient le parent des appels instrumentés. Une session regroupe les tours d’une conversation, tandis que le projet sépare les environnements ou applications.
Ce qu’il faut inspecter
Commencez par les traces lentes et en erreur. Vérifiez ensuite les prompts réellement envoyés, le contexte récupéré, les appels d’outils, les tokens et la réponse finale. Une hausse de latence peut venir du retrieval, du fournisseur LLM ou d’un outil : l’arbre de spans permet de les distinguer.
Éviter la fuite de données
Les traces peuvent contenir prompts, réponses et documents internes. Définissez avant le déploiement ce qui doit être masqué ou exclu. N’utilisez pas une trace brute comme journal d’audit. Restreignez l’accès à Phoenix, chiffrez le transport, configurez la rétention et séparez développement et production.
Production
Utilisez l’export par lots, un endpoint OTLP authentifié et un nom de projet stable. Ajoutez des attributs à faible cardinalité : version du prompt, version de l’application, route et fournisseur. Évitez d’utiliser un texte utilisateur comme nom de span ou étiquette de métrique.
Construisez ensuite des indicateurs : latence p50/p95, tokens par requête, erreurs par modèle, taux d’outil en échec et score de satisfaction. Une trace explique un incident ; une métrique montre qu’il devient systémique.
FAQ
Phoenix remplace-t-il les logs applicatifs ?
Non. Les traces montrent la causalité et les durées ; les logs restent utiles pour les événements détaillés et les erreurs système. Reliez-les avec un identifiant de trace.
Peut-on auto-héberger Phoenix ?
Oui. Le mode local convient au développement ; en production, ajoutez stockage durable, authentification, sauvegardes et politique de rétention.