Implementieren der erweiterten Überwachung für Azure OpenAI in Foundry Models über ein Gateway

Azure KI Services

Azure OpenAI Service

Azure API Management

Microsoft Entra ID

Azure Monitor

Überwachungsworkloads, die Azure OpenAI in Foundry-Modellen enthalten, können so einfach sein, wie die Diagnose für Azure OpenAI und die Verwendung vorkonfigurierten Dashboards zu aktivieren. Diese Strategie erfüllt jedoch nicht mehrere allgemeine, komplexere organisatorische Überwachungsanforderungen für generative KI-Workloads, z. B.:

• Verfolgung der Nutzung nach Kunde und Modell, um Kontingente zu verwalten und Chargeback-Lösungen zu implementieren.

• Protokollieren von Modelleingaben und Modellausgaben für verschiedene Überwachungsanwendungsfälle und Überwachen der Modellleistung.

• Durchführung einer Überwachung nahezu in Echtzeit.

Hinweis

Weitere Informationen zum direkten Überwachen von Azure OpenAI finden Sie unter Überwachen von Azure OpenAI.

Das folgende Diagramm veranschaulicht die Überwachung von Azure OpenAI-Instanzen ohne Gateway. Für diese Topologie ist kein Gateway erforderlich. Die Entscheidung, ein Gateway einzuschließen, hängt davon ab, ob die skizzierten Überwachungsszenarien Teil Ihrer Anforderungen sind. In diesem Artikel werden die Herausforderungen untersucht, die jedes Überwachungsszenario adressiert, sowie die Vorteile und Kosten der Integration eines Gateways für jedes Szenario.

Ein Diagramm, das zwei Clients mit der Bezeichnung A und B zeigt, die direkt mit Modellbereitstellungen in zwei Azure OpenAI-Instanzen verbunden sind. Client A greift direkt auf eine gpt-35-turbo-Bereitstellung und eine gpt-4-o-Bereitstellung in derselben Azure OpenAI-Instanz zu. Client B greift auf die gpt-4o-Bereitstellung in der ersten Azure OpenAI-Instanz und auf eine gpt-4-Bereitstellung in einer zweiten Azure OpenAI-Instanz zu. Client B zeigt auch eine gestrichelte Linie an, die eine Verbindung mit einer gpt-4o-Instanz in der zweiten Azure OpenAI-Bereitstellung herstellt. Beide Azure OpenAI-Instanzen übergeben Azure OpenAI-Metriken und -Protokolle an Azure Monitor.

Nachverfolgen der Modellnutzung

Viele Workloads oder Organisationen müssen die Nutzung von Azure OpenAI-Modellen sowohl durch Clients als auch durch Modelle in allen Azure OpenAI-Instanzen nachverfolgen. Sie verwenden diese Informationen, um:

• Implementieren Sie ein Chargeback-System, bei dem die Nutzungskosten der entsprechenden Organisation oder dem entsprechenden Anwendungseigentümer zugewiesen werden.

• Budget und Prognose für die zukünftige Nutzung.

• Verknüpfen Sie die Kosten und die Nutzung des Verkehrsträgers mit der Modellleistung.

Sie können die systemeigene Azure OpenAI-Überwachungsfunktion verwenden, um Telemetrie des Diensts nachzuverfolgen, aber es gibt Herausforderungen.

• Für Chargebackmodelle müssen Sie in der Lage sein, die Azure OpenAI-Tokennutzungsmetriken einer Anwendung oder Geschäftseinheit zuzuordnen. Die Azure OpenAI-Telemetrie enthält eine aufrufende IP-Adresse, bei der das letzte Oktett maskiert ist. Diese Maskierung kann das Einrichten dieser Zuordnung zu einer Anwendung oder Geschäftseinheit erschweren.

• Azure OpenAI-Instanzen in verschiedenen Regionen zeichnen wahrscheinlich Protokolle in Azure Monitor-Instanzen in ihren jeweiligen lokalen Regionen auf. Für diesen Prozess müssen Sie Protokolle aus verschiedenen Azure Monitor-Instanzen aggregieren, um die Nutzung über alle Azure OpenAI-Instanzen hinweg nachzuverfolgen.

Einführung eines Gateways zum Nachverfolgen der Modellnutzung

Ein Diagramm, das zwei mit A und B gekennzeichnete Clients zeigt, die direkt mit einem Gateway verbunden sind. Das Gateway verfügt über zwei Pfeile, die auf private Endpunkte verweisen. Der erste private Endpunkt weist zwei einfarbige Pfeile auf, die auf eine gpt-35-Turbo-Bereitstellung und eine gpt-4o-Bereitstellung in einer Azure OpenAI-Bereitstellung verweisen. Der zweite private Endpunkt verfügt über einen durchgezogenen Pfeil, der auf eine gpt-4-Bereitstellung zeigt, und eine gestrichelte Linie, die auf eine gpt-4o-Bereitstellung in einer zweiten Azure OpenAI-Instanz verweist. Beide Azure OpenAI-Instanzen übergeben Azure OpenAI-Metriken und -Protokolle an Azure Monitor. Das Gateway verfügt über einen Pfeil, der auf Azure Monitor verweist und anzeigt, dass es Nutzungsmetriken übergibt, einschließlich Client-IP-Adresse, Modell und Tokendaten.

Führen Sie ein Gateway in diese Topologie ein, um die vollständige Client-IP-Adresse, die Microsoft Entra ID (oder alternative Identität) des Clients oder einen benutzerdefinierten Bezeichner für eine Geschäftseinheit, einen Mandanten oder eine Anwendung an einem Ort zu erfassen. Sie können diese Daten dann verwenden, um eine Chargeback-Lösung für die Budgetierung und Prognose zu implementieren und Kosten-Nutzen-Analysen von Modellen durchzuführen.

Die folgenden Beispiele zeigen Verwendungsabfragen, die möglich sind, wenn Sie Azure API Management als Gateway verwenden.

Beispielabfrage für die Verwendungsüberwachung

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend modelkey = substring(parse_json(BackendResponseBody)['model'], 0, indexof(parse_json(BackendResponseBody)['model'], '-', 0, -1, 2))
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend completiontokens = parse_json(parse_json(BackendResponseBody)['usage'])['completion_tokens']
| extend totaltokens = parse_json(parse_json(BackendResponseBody)['usage'])['total_tokens']
| extend ip = CallerIpAddress
| summarize
    sum(todecimal(prompttokens)),
    sum(todecimal(completiontokens)),
    sum(todecimal(totaltokens)),
    avg(todecimal(totaltokens))
    by ip, model

Ausgabe:

Ein Screenshot, der die Ausgabe der Nutzungsüberwachung zeigt. Es wird eine Tabelle mit fünf Spalten und fünf Zeilen angezeigt. Die Spalten stellen die IP-Adresse, das Modell und drei Arten von Token dar. Bei diesen Token handelt es sich um die Gesamtzahl der Token, die in der Eingabeaufforderung verwendet werden, die Gesamtzahl der Token, die vom Modell als Antwort auf die Eingabeaufforderung generiert werden, und die kombinierte Summe von Eingabeaufforderungstoken und Abschlusstoken.

Beispielabfrage für die Überwachung der Eingabeaufforderungsverwendung

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend prompttext = substring(parse_json(parse_json(BackendResponseBody)['choices'])[0], 0, 100)

Ausgabe:

Ein Screenshot, der die Ausgabe der Nutzungsüberwachung zeigt. Sie zeigt eine Tabelle mit vier Spalten und sieben Zeilen. Die Spalten stellen die in UTC generierte Zeit, das Modell, die Eingabeaufforderungstoken und den Eingabeaufforderungstext dar.

Prüfen von Ein- und Ausgaben des Modells

Zentral für viele Überwachungsanforderungen für generative KI-Workloads ist die Überwachung der Eingabe und Ausgabe der Modelle. Möglicherweise müssen Sie wissen, ob eine Antwort aus einem Modell oder aus einem Cache stammt. Es gibt mehrere Anwendungsfälle für die Überwachung von Ein- und Ausgaben von Modellen. In den meisten Szenarien sollten Überwachungsregeln einheitlich auf alle Modelle angewendet werden, sowohl für Eingaben als auch für Ausgaben.

Die folgenden Anwendungsfälle dienen der Überwachung der Eingaben in Modelle.

• Erkennung von Bedrohungen: Analysieren Sie Eingaben, um potenzielle Sicherheitsrisiken zu identifizieren und zu mindern.

• Erkennung von Verstößen gegen die Nutzungsrichtlinien: Analysieren Sie Eingaben auf anstößige Sprache oder andere Nutzungsstandards, um sicherzustellen, dass das System professionell, sicher und unvoreingenommen ist.

• Leistung des Modells: Kombinieren Sie mit Modellausgaben, um die Leistung anhand von Metriken wie Groundedness und Relevanz zu bewerten. Sie können diese Informationen verwenden, um Leistungsprobleme mit dem Modell oder Eingabeaufforderungen zu beheben.

Im Folgenden sind einige der Anwendungsfälle für die Überwachung der Ausgaben für Modelle aufgeführt.

• Erkennung von Datenexfiltration: Analysieren Sie die Ausgaben, um sich vor unbefugter Übertragung vertraulicher Informationen zu schützen.

• Zustandsbehaftete Compliance: Überwachen Sie die Ausgaben mehrerer Interaktionen innerhalb derselben Konversation, um heimliche Lecks vertraulicher Informationen zu erkennen.

• Beachtung: Stellen Sie sicher, dass die Ergebnisse den Unternehmensrichtlinien und gesetzlichen Anforderungen entsprechen. Zwei Beispiele sind, dass Models keine Rechtsberatung anbieten oder finanzielle Versprechungen machen.

• Leistung des Modells: Kombinieren Sie mit Modelleingaben, um die Leistung anhand von Metriken wie Groundedness und Relevanz zu bewerten. Sie können diese Informationen verwenden, um Leistungsprobleme mit dem Modell oder Eingabeaufforderungen zu beheben.

Herausforderungen bei der Überwachung von Modelleingaben und Ausgaben direkt aus dem Modell

• Einschränkungen bei der Modellprotokollierung: Einige Dienste, z. B. Azure OpenAI, protokollieren keine Modelleingaben und -ausgaben.

• Cache: Komplexere Architekturen können Antworten aus dem Cache bereitstellen. In diesen Szenarien wird das Modell nicht aufgerufen und protokolliert die Ein- oder Ausgabe nicht.

• Zustandsbehaftete Unterhaltungen: Der Zustand einer Konversation mit mehreren Interaktionen kann außerhalb des Modells gespeichert werden. Das Modell weiß nicht, welche Interaktionen als Unterhaltung korreliert werden sollen.

• Architektur mit mehreren Modellen: Die Orchestrierungsschicht kann dynamisch mehrere Modelle aufrufen, um eine endgültige Antwort zu generieren.

Einführung eines Gateways für Überwachungsmodelleingaben und -ausgaben

Ein Diagramm, das zwei mit A und B gekennzeichnete Clients zeigt, die direkt mit einem Gateway verbunden sind. Das Gateway verfügt über zwei Pfeile, die auf private Endpunkte verweisen. Der erste private Endpunkt weist zwei einfarbige Pfeile auf, die auf eine gpt-35-Turbo-Bereitstellung und eine gpt-4o-Bereitstellung in einer Azure OpenAI-Bereitstellung verweisen. Der zweite private Endpunkt verfügt über einen durchgezogenen Pfeil, der auf eine gpt-4-Bereitstellung zeigt, und eine gestrichelte Linie, die auf eine gpt-4o-Bereitstellung in einer zweiten Azure OpenAI-Instanz verweist. Beide Azure OpenAI-Instanzen werden angezeigt, indem Azure OpenAI-Metriken und Protokolle an Azure Monitor übergeben werden. Das Gateway verfügt über einen Pfeil, der auf Azure Monitor verweist und anzeigt, dass Eingaben und Ausgaben übergeben werden.

Führen Sie ein Gateway in diese Topologie ein, um sowohl die ursprüngliche Eingabe direkt vom Client als auch die endgültige Ausgabe zu erfassen, die an den Client zurückgegeben wird. Da das Gateway eine Abstraktion zwischen dem Client und den Modellen ist und die Anforderung direkt von den Clients empfängt, befindet sich das Gateway in der Lage, diese unformatierte, unverarbeitete Anforderung zu protokollieren. Da das Gateway die Ressource ist, die die endgültige Antwort an den Client zurückgibt, ist es auch in der Lage, diese Antwort zu protokollieren.

Das Gateway verfügt über die einzigartige Fähigkeit, sowohl die Anforderung des Clients als auch die endgültige Antwort, die er erhalten hat, zu protokollieren. Diese Funktion gilt unabhängig davon, ob die Antwort direkt aus einem Modell stammt, aus mehreren Modellen aggregiert oder aus dem Cache abgerufen wurde. Wenn die Clients einen Unterhaltungsbezeichner übergeben, kann das Gateway diesen Bezeichner mit der Eingabe und Ausgabe protokollieren. Sie können diese Implementierung verwenden, um mehrere Interaktionen einer Konversation zu korrelieren.

Durch die Überwachung von Eingaben und Ausgaben am Gateway können Sie Überwachungsregeln einheitlich auf alle Modelle anwenden.

Überwachung nahezu in Echtzeit

Azure Monitor ist aufgrund der inhärenten Latenz bei der Erfassung von Protokolldaten nicht für die Verarbeitung nahezu in Echtzeit optimiert. Wenn Ihre Lösung nahezu echtzeitbasierte Verarbeitung von Datenverkehr erfordert, können Sie ein Design in Betracht ziehen, in dem Sie Protokolle direkt in einem Nachrichtenbus veröffentlichen und eine Datenstromverarbeitungstechnologie wie Azure Stream Analytics verwenden, um Fenstervorgänge auszuführen.

Ein Diagramm, das zwei mit A und B gekennzeichnete Clients zeigt, die direkt mit einem Gateway verbunden sind. Das Gateway verfügt über zwei Pfeile, die auf private Endpunkte verweisen. Der erste private Endpunkt weist zwei einfarbige Pfeile auf, die auf eine gpt-35-Turbo-Bereitstellung und eine gpt-4o-Bereitstellung in einer Azure OpenAI-Bereitstellung verweisen. Der zweite private Endpunkt verfügt über einen durchgezogenen Pfeil, der auf eine gpt-4-Bereitstellung zeigt, und eine gestrichelte Linie, die auf eine gpt-4o-Bereitstellung in einer zweiten Azure OpenAI-Instanz verweist. Beide Azure OpenAI-Instanzen werden angezeigt, indem Azure OpenAI-Metriken und Protokolle an Azure Monitor übergeben werden. Das Gateway verfügt über einen Pfeil, der auf Azure Monitor verweist und anzeigt, dass Eingaben und Ausgaben übergeben werden. Das Gateway verfügt über einen weiteren Pfeil, der auf einen Nachrichtenbus zeigt. Der Nachrichtenbus verfügt über Pfeile, die auf Blob Storage und einen Streamprozessor verweisen.

Überlegungen bei der Einführung eines Gateways für die Überwachung

• Latenz: Die Einführung eines Gateways in Ihre Architektur erhöht die Latenz Ihrer Antworten. Sie müssen sicherstellen, dass die Vorteile der Beobachtbarkeit die Auswirkungen auf die Leistung überwiegen.

• Sicherheit und Datenschutz: Stellen Sie sicher, dass die Überwachungsdaten, die mithilfe des Gateways gesammelt werden, weiterhin den Datenschutzerwartungen der Kunden entsprechen. Beobachtbarkeitsdaten müssen den festgelegten Sicherheits- und Datenschutzerwartungen der Workload entsprechen und dürfen nicht gegen Datenschutzstandards der Kunden verstoßen. Behandeln Sie weiterhin alle vertraulichen Daten, die durch die Überwachung erfasst werden, als vertrauliche Daten.

• Zuverlässigkeit: Ermitteln Sie, ob die Überwachungsfunktion für die Funktionalität der Workload entscheidend ist. Wenn dies der Fall ist, sollte die gesamte Anwendung ausgefallen sein, wenn das Überwachungssystem nicht verfügbar ist. Wenn dies nicht entscheidend ist, sollte die Anwendung in einem nicht überwachten Zustand weiterhin funktionieren, wenn das Überwachungssystem ausgefallen ist. Verstehen Sie die Risiken des Hinzufügens eines neuen Single Point of Failure, entweder durch Dienstfehler oder von Menschen verursachte Konfigurationsprobleme im Gateway.

• Implementierung: Ihre Implementierung kann die Vorteile von sofort einsatzbereiten Gateways wie API Management nutzen, einschließlich aller erforderlichen Konfigurationen. Ein weiterer gängiger Ansatz ist die Implementierung einer Orchestrierungsschicht durch Code.

Gründe für die Vermeidung der Einführung eines Gateways für die Überwachung

Wenn eine einzelne Anwendung auf ein einzelnes Modell zugreift, überwiegt die zusätzliche Komplexität der Einführung eines Gateways wahrscheinlich die Vorteile der Überwachung. Der Client kann die Verantwortung für die Protokollierung von Ein- und Ausgaben übernehmen. Außerdem können Sie die nativen Protokollierungsfunktionen des Modells oder Diensts nutzen, den Sie verwenden. Das Gateway ist vorteilhaft, wenn Sie über mehrere Clients oder mehrere Modelle verfügen, die Sie überwachen müssen.

Nächste Schritte

Eine Gateway-Implementierung für Ihre Workload bietet Vorteile, die über die in diesem Artikel beschriebenen taktischen Vorteile des Multiple-Back-End-Routings hinausgehen. Weitere Informationen finden Sie unter Access Azure OpenAI und anderen Sprachmodellen über ein Gateway.

Verwandte Ressourcen

• Entwerfen einer gut gestalteten KI-Workload
• API-Gateway in API Management

Überwachungsworkloads, die Azure OpenAI in Foundry-Modellen enthalten, können so einfach sein, wie die Diagnose für Azure OpenAI und die Verwendung vorkonfigurierten Dashboards zu aktivieren. Diese Strategie erfüllt jedoch nicht mehrere allgemeine, komplexere organisatorische Überwachungsanforderungen für generative KI-Workloads, z. B.:

• Verfolgung der Nutzung nach Kunde und Modell, um Kontingente zu verwalten und Chargeback-Lösungen zu implementieren.

• Protokollieren von Modelleingaben und Modellausgaben für verschiedene Überwachungsanwendungsfälle und Überwachen der Modellleistung.

• Durchführung einer Überwachung nahezu in Echtzeit.

Hinweis

Weitere Informationen zum direkten Überwachen von Azure OpenAI finden Sie unter Überwachen von Azure OpenAI.

Das folgende Diagramm veranschaulicht die Überwachung von Azure OpenAI-Instanzen ohne Gateway. Für diese Topologie ist kein Gateway erforderlich. Die Entscheidung, ein Gateway einzuschließen, hängt davon ab, ob die skizzierten Überwachungsszenarien Teil Ihrer Anforderungen sind. In diesem Artikel werden die Herausforderungen untersucht, die jedes Überwachungsszenario adressiert, sowie die Vorteile und Kosten der Integration eines Gateways für jedes Szenario.

Ein Diagramm, das zwei Clients mit der Bezeichnung A und B zeigt, die direkt mit Modellbereitstellungen in zwei Azure OpenAI-Instanzen verbunden sind. Client A greift direkt auf eine gpt-35-turbo-Bereitstellung und eine gpt-4-o-Bereitstellung in derselben Azure OpenAI-Instanz zu. Client B greift auf die gpt-4o-Bereitstellung in der ersten Azure OpenAI-Instanz und auf eine gpt-4-Bereitstellung in einer zweiten Azure OpenAI-Instanz zu. Client B zeigt auch eine gestrichelte Linie an, die eine Verbindung mit einer gpt-4o-Instanz in der zweiten Azure OpenAI-Bereitstellung herstellt. Beide Azure OpenAI-Instanzen übergeben Azure OpenAI-Metriken und -Protokolle an Azure Monitor.

Nachverfolgen der Modellnutzung

Viele Workloads oder Organisationen müssen die Nutzung von Azure OpenAI-Modellen sowohl durch Clients als auch durch Modelle in allen Azure OpenAI-Instanzen nachverfolgen. Sie verwenden diese Informationen, um:

• Implementieren Sie ein Chargeback-System, bei dem die Nutzungskosten der entsprechenden Organisation oder dem entsprechenden Anwendungseigentümer zugewiesen werden.

• Budget und Prognose für die zukünftige Nutzung.

• Verknüpfen Sie die Kosten und die Nutzung des Verkehrsträgers mit der Modellleistung.

Sie können die systemeigene Azure OpenAI-Überwachungsfunktion verwenden, um Telemetrie des Diensts nachzuverfolgen, aber es gibt Herausforderungen.

• Für Chargebackmodelle müssen Sie in der Lage sein, die Azure OpenAI-Tokennutzungsmetriken einer Anwendung oder Geschäftseinheit zuzuordnen. Die Azure OpenAI-Telemetrie enthält eine aufrufende IP-Adresse, bei der das letzte Oktett maskiert ist. Diese Maskierung kann das Einrichten dieser Zuordnung zu einer Anwendung oder Geschäftseinheit erschweren.

• Azure OpenAI-Instanzen in verschiedenen Regionen zeichnen wahrscheinlich Protokolle in Azure Monitor-Instanzen in ihren jeweiligen lokalen Regionen auf. Für diesen Prozess müssen Sie Protokolle aus verschiedenen Azure Monitor-Instanzen aggregieren, um die Nutzung über alle Azure OpenAI-Instanzen hinweg nachzuverfolgen.

Einführung eines Gateways zum Nachverfolgen der Modellnutzung

Ein Diagramm, das zwei mit A und B gekennzeichnete Clients zeigt, die direkt mit einem Gateway verbunden sind. Das Gateway verfügt über zwei Pfeile, die auf private Endpunkte verweisen. Der erste private Endpunkt weist zwei einfarbige Pfeile auf, die auf eine gpt-35-Turbo-Bereitstellung und eine gpt-4o-Bereitstellung in einer Azure OpenAI-Bereitstellung verweisen. Der zweite private Endpunkt verfügt über einen durchgezogenen Pfeil, der auf eine gpt-4-Bereitstellung zeigt, und eine gestrichelte Linie, die auf eine gpt-4o-Bereitstellung in einer zweiten Azure OpenAI-Instanz verweist. Beide Azure OpenAI-Instanzen übergeben Azure OpenAI-Metriken und -Protokolle an Azure Monitor. Das Gateway verfügt über einen Pfeil, der auf Azure Monitor verweist und anzeigt, dass es Nutzungsmetriken übergibt, einschließlich Client-IP-Adresse, Modell und Tokendaten.

Führen Sie ein Gateway in diese Topologie ein, um die vollständige Client-IP-Adresse, die Microsoft Entra ID (oder alternative Identität) des Clients oder einen benutzerdefinierten Bezeichner für eine Geschäftseinheit, einen Mandanten oder eine Anwendung an einem Ort zu erfassen. Sie können diese Daten dann verwenden, um eine Chargeback-Lösung für die Budgetierung und Prognose zu implementieren und Kosten-Nutzen-Analysen von Modellen durchzuführen.

Die folgenden Beispiele zeigen Verwendungsabfragen, die möglich sind, wenn Sie Azure API Management als Gateway verwenden.

Beispielabfrage für die Verwendungsüberwachung

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend modelkey = substring(parse_json(BackendResponseBody)['model'], 0, indexof(parse_json(BackendResponseBody)['model'], '-', 0, -1, 2))
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend completiontokens = parse_json(parse_json(BackendResponseBody)['usage'])['completion_tokens']
| extend totaltokens = parse_json(parse_json(BackendResponseBody)['usage'])['total_tokens']
| extend ip = CallerIpAddress
| summarize
    sum(todecimal(prompttokens)),
    sum(todecimal(completiontokens)),
    sum(todecimal(totaltokens)),
    avg(todecimal(totaltokens))
    by ip, model

Ausgabe:

Ein Screenshot, der die Ausgabe der Nutzungsüberwachung zeigt. Es wird eine Tabelle mit fünf Spalten und fünf Zeilen angezeigt. Die Spalten stellen die IP-Adresse, das Modell und drei Arten von Token dar. Bei diesen Token handelt es sich um die Gesamtzahl der Token, die in der Eingabeaufforderung verwendet werden, die Gesamtzahl der Token, die vom Modell als Antwort auf die Eingabeaufforderung generiert werden, und die kombinierte Summe von Eingabeaufforderungstoken und Abschlusstoken.

Beispielabfrage für die Überwachung der Eingabeaufforderungsverwendung

ApiManagementGatewayLogs
| where tolower(OperationId) in ('completions_create','chatcompletions_create')
| extend model = tostring(parse_json(BackendResponseBody)['model'])
| extend prompttokens = parse_json(parse_json(BackendResponseBody)['usage'])['prompt_tokens']
| extend prompttext = substring(parse_json(parse_json(BackendResponseBody)['choices'])[0], 0, 100)

Ausgabe:

Ein Screenshot, der die Ausgabe der Nutzungsüberwachung zeigt. Sie zeigt eine Tabelle mit vier Spalten und sieben Zeilen. Die Spalten stellen die in UTC generierte Zeit, das Modell, die Eingabeaufforderungstoken und den Eingabeaufforderungstext dar.

Prüfen von Ein- und Ausgaben des Modells

Zentral für viele Überwachungsanforderungen für generative KI-Workloads ist die Überwachung der Eingabe und Ausgabe der Modelle. Möglicherweise müssen Sie wissen, ob eine Antwort aus einem Modell oder aus einem Cache stammt. Es gibt mehrere Anwendungsfälle für die Überwachung von Ein- und Ausgaben von Modellen. In den meisten Szenarien sollten Überwachungsregeln einheitlich auf alle Modelle angewendet werden, sowohl für Eingaben als auch für Ausgaben.

Die folgenden Anwendungsfälle dienen der Überwachung der Eingaben in Modelle.

• Erkennung von Bedrohungen: Analysieren Sie Eingaben, um potenzielle Sicherheitsrisiken zu identifizieren und zu mindern.

• Erkennung von Verstößen gegen die Nutzungsrichtlinien: Analysieren Sie Eingaben auf anstößige Sprache oder andere Nutzungsstandards, um sicherzustellen, dass das System professionell, sicher und unvoreingenommen ist.

• Leistung des Modells: Kombinieren Sie mit Modellausgaben, um die Leistung anhand von Metriken wie Groundedness und Relevanz zu bewerten. Sie können diese Informationen verwenden, um Leistungsprobleme mit dem Modell oder Eingabeaufforderungen zu beheben.

Im Folgenden sind einige der Anwendungsfälle für die Überwachung der Ausgaben für Modelle aufgeführt.

• Erkennung von Datenexfiltration: Analysieren Sie die Ausgaben, um sich vor unbefugter Übertragung vertraulicher Informationen zu schützen.

• Zustandsbehaftete Compliance: Überwachen Sie die Ausgaben mehrerer Interaktionen innerhalb derselben Konversation, um heimliche Lecks vertraulicher Informationen zu erkennen.

• Beachtung: Stellen Sie sicher, dass die Ergebnisse den Unternehmensrichtlinien und gesetzlichen Anforderungen entsprechen. Zwei Beispiele sind, dass Models keine Rechtsberatung anbieten oder finanzielle Versprechungen machen.

• Leistung des Modells: Kombinieren Sie mit Modelleingaben, um die Leistung anhand von Metriken wie Groundedness und Relevanz zu bewerten. Sie können diese Informationen verwenden, um Leistungsprobleme mit dem Modell oder Eingabeaufforderungen zu beheben.

Herausforderungen bei der Überwachung von Modelleingaben und Ausgaben direkt aus dem Modell

• Einschränkungen bei der Modellprotokollierung: Einige Dienste, z. B. Azure OpenAI, protokollieren keine Modelleingaben und -ausgaben.

• Cache: Komplexere Architekturen können Antworten aus dem Cache bereitstellen. In diesen Szenarien wird das Modell nicht aufgerufen und protokolliert die Ein- oder Ausgabe nicht.

• Zustandsbehaftete Unterhaltungen: Der Zustand einer Konversation mit mehreren Interaktionen kann außerhalb des Modells gespeichert werden. Das Modell weiß nicht, welche Interaktionen als Unterhaltung korreliert werden sollen.

• Architektur mit mehreren Modellen: Die Orchestrierungsschicht kann dynamisch mehrere Modelle aufrufen, um eine endgültige Antwort zu generieren.

Einführung eines Gateways für Überwachungsmodelleingaben und -ausgaben

Ein Diagramm, das zwei mit A und B gekennzeichnete Clients zeigt, die direkt mit einem Gateway verbunden sind. Das Gateway verfügt über zwei Pfeile, die auf private Endpunkte verweisen. Der erste private Endpunkt weist zwei einfarbige Pfeile auf, die auf eine gpt-35-Turbo-Bereitstellung und eine gpt-4o-Bereitstellung in einer Azure OpenAI-Bereitstellung verweisen. Der zweite private Endpunkt verfügt über einen durchgezogenen Pfeil, der auf eine gpt-4-Bereitstellung zeigt, und eine gestrichelte Linie, die auf eine gpt-4o-Bereitstellung in einer zweiten Azure OpenAI-Instanz verweist. Beide Azure OpenAI-Instanzen werden angezeigt, indem Azure OpenAI-Metriken und Protokolle an Azure Monitor übergeben werden. Das Gateway verfügt über einen Pfeil, der auf Azure Monitor verweist und anzeigt, dass Eingaben und Ausgaben übergeben werden.

Führen Sie ein Gateway in diese Topologie ein, um sowohl die ursprüngliche Eingabe direkt vom Client als auch die endgültige Ausgabe zu erfassen, die an den Client zurückgegeben wird. Da das Gateway eine Abstraktion zwischen dem Client und den Modellen ist und die Anforderung direkt von den Clients empfängt, befindet sich das Gateway in der Lage, diese unformatierte, unverarbeitete Anforderung zu protokollieren. Da das Gateway die Ressource ist, die die endgültige Antwort an den Client zurückgibt, ist es auch in der Lage, diese Antwort zu protokollieren.

Das Gateway verfügt über die einzigartige Fähigkeit, sowohl die Anforderung des Clients als auch die endgültige Antwort, die er erhalten hat, zu protokollieren. Diese Funktion gilt unabhängig davon, ob die Antwort direkt aus einem Modell stammt, aus mehreren Modellen aggregiert oder aus dem Cache abgerufen wurde. Wenn die Clients einen Unterhaltungsbezeichner übergeben, kann das Gateway diesen Bezeichner mit der Eingabe und Ausgabe protokollieren. Sie können diese Implementierung verwenden, um mehrere Interaktionen einer Konversation zu korrelieren.

Durch die Überwachung von Eingaben und Ausgaben am Gateway können Sie Überwachungsregeln einheitlich auf alle Modelle anwenden.

Überwachung nahezu in Echtzeit

Azure Monitor ist aufgrund der inhärenten Latenz bei der Erfassung von Protokolldaten nicht für die Verarbeitung nahezu in Echtzeit optimiert. Wenn Ihre Lösung nahezu echtzeitbasierte Verarbeitung von Datenverkehr erfordert, können Sie ein Design in Betracht ziehen, in dem Sie Protokolle direkt in einem Nachrichtenbus veröffentlichen und eine Datenstromverarbeitungstechnologie wie Azure Stream Analytics verwenden, um Fenstervorgänge auszuführen.

Ein Diagramm, das zwei mit A und B gekennzeichnete Clients zeigt, die direkt mit einem Gateway verbunden sind. Das Gateway verfügt über zwei Pfeile, die auf private Endpunkte verweisen. Der erste private Endpunkt weist zwei einfarbige Pfeile auf, die auf eine gpt-35-Turbo-Bereitstellung und eine gpt-4o-Bereitstellung in einer Azure OpenAI-Bereitstellung verweisen. Der zweite private Endpunkt verfügt über einen durchgezogenen Pfeil, der auf eine gpt-4-Bereitstellung zeigt, und eine gestrichelte Linie, die auf eine gpt-4o-Bereitstellung in einer zweiten Azure OpenAI-Instanz verweist. Beide Azure OpenAI-Instanzen werden angezeigt, indem Azure OpenAI-Metriken und Protokolle an Azure Monitor übergeben werden. Das Gateway verfügt über einen Pfeil, der auf Azure Monitor verweist und anzeigt, dass Eingaben und Ausgaben übergeben werden. Das Gateway verfügt über einen weiteren Pfeil, der auf einen Nachrichtenbus zeigt. Der Nachrichtenbus verfügt über Pfeile, die auf Blob Storage und einen Streamprozessor verweisen.

Überlegungen bei der Einführung eines Gateways für die Überwachung

• Latenz: Die Einführung eines Gateways in Ihre Architektur erhöht die Latenz Ihrer Antworten. Sie müssen sicherstellen, dass die Vorteile der Beobachtbarkeit die Auswirkungen auf die Leistung überwiegen.

• Sicherheit und Datenschutz: Stellen Sie sicher, dass die Überwachungsdaten, die mithilfe des Gateways gesammelt werden, weiterhin den Datenschutzerwartungen der Kunden entsprechen. Beobachtbarkeitsdaten müssen den festgelegten Sicherheits- und Datenschutzerwartungen der Workload entsprechen und dürfen nicht gegen Datenschutzstandards der Kunden verstoßen. Behandeln Sie weiterhin alle vertraulichen Daten, die durch die Überwachung erfasst werden, als vertrauliche Daten.

• Zuverlässigkeit: Ermitteln Sie, ob die Überwachungsfunktion für die Funktionalität der Workload entscheidend ist. Wenn dies der Fall ist, sollte die gesamte Anwendung ausgefallen sein, wenn das Überwachungssystem nicht verfügbar ist. Wenn dies nicht entscheidend ist, sollte die Anwendung in einem nicht überwachten Zustand weiterhin funktionieren, wenn das Überwachungssystem ausgefallen ist. Verstehen Sie die Risiken des Hinzufügens eines neuen Single Point of Failure, entweder durch Dienstfehler oder von Menschen verursachte Konfigurationsprobleme im Gateway.

• Implementierung: Ihre Implementierung kann die Vorteile von sofort einsatzbereiten Gateways wie API Management nutzen, einschließlich aller erforderlichen Konfigurationen. Ein weiterer gängiger Ansatz ist die Implementierung einer Orchestrierungsschicht durch Code.

Gründe für die Vermeidung der Einführung eines Gateways für die Überwachung

Wenn eine einzelne Anwendung auf ein einzelnes Modell zugreift, überwiegt die zusätzliche Komplexität der Einführung eines Gateways wahrscheinlich die Vorteile der Überwachung. Der Client kann die Verantwortung für die Protokollierung von Ein- und Ausgaben übernehmen. Außerdem können Sie die nativen Protokollierungsfunktionen des Modells oder Diensts nutzen, den Sie verwenden. Das Gateway ist vorteilhaft, wenn Sie über mehrere Clients oder mehrere Modelle verfügen, die Sie überwachen müssen.

Nächste Schritte

Eine Gateway-Implementierung für Ihre Workload bietet Vorteile, die über die in diesem Artikel beschriebenen taktischen Vorteile des Multiple-Back-End-Routings hinausgehen. Weitere Informationen finden Sie unter Access Azure OpenAI und anderen Sprachmodellen über ein Gateway.

Verwandte Ressourcen

• Entwerfen einer gut gestalteten KI-Workload
• API-Gateway in API Management