Arize Phoenix Assess

Überblick

Arize Phoenix ist ein offenes Observability- und Evaluation-Toolkit für LLM Traces, Embeddings und RAG-Quality-Metriken (Phoenix).

Assess bei Bedarf an einer selbst hostbaren Eval-UX ohne volles LangSmith-Commitment. Traces lassen sich per OpenTelemetry-Export in zentrale Dashboards integrieren.

Adoptionssignale

  • Aktives, viel genutztes Repository: 11.700 Stars und 1.200 Forks auf GitHub, Server-Release v20.16.0 vom 23. September 2026 (Phoenix GitHub, Phoenix Releases).
  • Das Server-Paket arize-phoenix kam im Monat bis 30. September 2026 auf 645.558 PyPI-Downloads (PyPI Stats); Arize selbst nannte im Februar 2025 mehr als zwei Millionen monatliche Phoenix-Downloads (Arize Series-C-Ankündigung).
  • Der Anbieter ist finanziell gut ausgestattet: Arize hat im Februar 2025 eine Series C über 70 Mio. US-Dollar unter Führung von Adams Street Partners abgeschlossen, beteiligt waren unter anderem M12 (Microsoft), Datadog und PagerDuty (Arize Series-C-Ankündigung).
  • Framework-Anbieter liefern Phoenix als Standardziel aus: LlamaIndex führt Phoenix unter „One-Click Observability“ über set_global_handler("arize_phoenix") (LlamaIndex Observability).
  • Die Instrumentierung ist ein eigenes Apache-2.0-Projekt, OpenInference, mit über 40 Python-Paketen sowie Instrumentierungen für JavaScript, Java (LangChain4j, Spring AI, Google ADK) und Go, nutzbar mit jedem OTel-Collector (OpenInference).
  • Der kostenlose Server bringt Enterprise-Zugriffskontrollen mit: OIDC (u. a. Microsoft Entra ID und Keycloak), LDAP/Active Directory mit Gruppen-zu-Rollen-Mapping sowie System- und User-API-Keys (Phoenix Authentication).

Risiken

  • Offen im Auslieferungszustand. Phoenix startet ohne Authentifizierung; wird sie später aktiviert, stoppt die Trace-Erfassung und der API-Zugriff ist blockiert, bis API-Keys ausgestellt sind. Das nachträgliche Einschalten unterbricht also die Ingestion eines laufenden Piloten (Phoenix Authentication).
  • Traces sind personenbezogene Daten. Spans enthalten Prompts, abgerufene Dokumente und Modell-Outputs, und die Standard-Aufbewahrung (PHOENIX_DEFAULT_RETENTION_POLICY_DAYS=0) hält sie unbegrenzt vor, solange keine globale oder projektbezogene Policy gesetzt ist (Phoenix Konfiguration).
  • Upgrade-Aufwand. Acht Major-Releases zwischen Februar und August 2026; v14 hat den Legacy-Client und den Endpunkt /v1/evaluations entfernt, v20 das session.id-Format des Assistenten geändert, wodurch gespeicherte Filter und Dashboards im Trace-Projekt des Assistenten neu angelegt werden müssen (Phoenix Migrationsleitfaden).
  • Wachsende eingebaute Agent-Funktionen. Die letzten Major-Versionen brachten Code-Evaluatoren in Sandboxes externer Anbieter wie E2B, Daytona, Vercel und Modal (v16), den In-App-Assistenten PXI (v17) und einen OAuth2-Authorization-Server mit Dynamic Client Registration, der bei aktivierter Authentifizierung automatisch läuft (v19). Für jede dieser Funktionen braucht es eine bewusste Entscheidung für Freigabe oder Abschaltung (Phoenix Migrationsleitfaden).
  • Lizenzgrenzen. Nach ELv2 ist es nicht erlaubt, Phoenix Dritten als gehosteten Dienst anzubieten; Beratungen und Konzern-IT, die rechtlich eigenständige Gesellschaften versorgen, sollten vor dem Aufbau eines gemeinsamen Dienstes eine rechtliche Prüfung einplanen (Phoenix Lizenz).

Vorteile & Nachteile

Vorteile

  • Die Instrumentierung basiert über die Apache-2.0-Konventionen von OpenInference auf OpenTelemetry, deckt Python, TypeScript, Java und Go ab und exportiert an jedes OTel-kompatible Backend; der Tracing-Code bleibt also auch ohne Phoenix nutzbar.
  • Self-Hosting ist kostenlos und ohne Feature-Grenzen, die Trace-Daten bleiben in der eigenen Infrastruktur, und mit PostgreSQL, Helm, OIDC- oder LDAP-Login sowie den Rollen Admin, Member und Viewer ist ein kontrollierter interner Betrieb möglich.
  • Tracing, LLM-as-Judge- und Code-Evaluations, Datasets, Experiments und Prompt-Versionierung liegen in einem Tool, und die Verbreitung ist breit: rund 646.000 PyPI-Downloads des Server-Pakets in den 30 Tagen bis 30. September 2026 und 11.700 GitHub-Stars.

Nachteile

  • Phoenix steht unter der Elastic License 2.0, keiner OSI-Open-Source-Lizenz, und darf Dritten nicht als Hosted oder Managed Service angeboten werden; das betrifft Dienstleister und gemeinsam genutzte Konzernplattformen.
  • Der Server hat zwischen Februar und August 2026 acht Major-Versionen (v13 bis v20) durchlaufen und dabei Clients und Endpunkte entfernt; Upgrades brauchen daher fixierte Versionen und Regressionstests.
  • Die Defaults sind auf schnellen Einstieg statt Kontrolle ausgelegt: Authentifizierung ist aus, Traces werden unbegrenzt aufbewahrt, und Code-Evaluatoren dürfen externe Sandbox-Anbieter nutzen, solange keine Allowlist gesetzt ist.

Empfehlung

Phoenix eignet sich im Assess-Ring als selbst gehostete Tracing- und Evaluation-Werkbank für eine einzelne RAG- oder Agent-Anwendung. Die Instrumentierung sollte über OpenInference laufen, damit dieselben Spans später auch an Langfuse, LangSmith, MLflow 3 oder ein zentrales OpenTelemetry-Backend gehen können (alle ebenfalls auf diesem Radar). Phoenix passt zu Teams, die Evals, Datasets und Experiments direkt neben ihren Traces haben wollen, ohne Daten an einen SaaS-Anbieter zu senden. Weniger sinnvoll ist es, wenn OpenTelemetry-GenAI-Telemetrie bereits in einer zentralen Plattform landet und nur Offline-Evals fehlen; das deckt eine Bibliothek wie DeepEval ab.

Vor den ersten echten Traces sollten PostgreSQL statt SQLite eingerichtet, die Authentifizierung mit dem vorhandenen OIDC- oder LDAP-Verzeichnis aktiviert, eine zur Datenschutz-Folgenabschätzung passende Aufbewahrungsfrist gesetzt, PHOENIX_ALLOWED_SANDBOX_PROVIDERS auf lokale Runtimes beschränkt und der PXI-Assistent abgeschaltet werden, falls dessen Modellanbieter nicht freigegeben ist. Die Server-Version wird fixiert und jedes Upgrade gegen den Migrationsleitfaden getestet. Ein Wechsel nach Trial setzt ein Quartal stabiler Upgrades voraus sowie Evaluation-Ergebnisse, die das Team tatsächlich als Release-Gate nutzt.

Quellen