Obserwowalność LLM w wielomodelowej bramce API: ślady, księgi tokenów, analiza najemców i bezpieczne rejestrowanie monitów

Zagregowana liczba żądań i miesięczne wydatki nie wystarczą, gdy klient pyta, dlaczego jeden przepływ pracy stał się wczoraj wolniejszy, droższy lub mniej niezawodny. Brama interfejsu API obsługująca wiele modeli może odpowiedzieć na to pytanie, jeśli potraktuje obserwowalność jako część płaszczyzny kontroli: każde żądanie otrzymuje ślad, każde wywołanie modelu aktualizuje rejestr użytkowania, można przypisać każdego dzierżawcę i przepływ pracy, a poufna treść jest domyślnie chroniona.

W tym artykule opisano praktyczny projekt analizy wykorzystania sztucznej inteligencji i obserwowalności LLM w bramie łączącej wielu dostawców za pośrednictwem interfejsu API zgodnego z OpenAI. Wzorzec jest przydatny, nawet jeśli nie korzystasz z żadnego konkretnego dostawcy: instrumentuj raz na bramie, normalizuj dane telemetryczne modelu, zachowaj atrybucję rozliczeń i przechwytuj treści monitów tylko zgodnie z wyraźnymi zasadami.

Problem czytelnika: „Który najemca, model, monit lub ścieżka pobierania spowodowała zmianę?”

Większość zespołów w końcu staje przed tą samą luką w debugowaniu. Dzienniki aplikacji pokazują, że funkcja nie powiodła się. Pulpity dostawców pokazują, że wzrosło wykorzystanie tokenów. Finanse widzą rachunek. Żaden z tych widoków sam w sobie nie wyjaśnia pełnej ścieżki od żądania dzierżawcy do wywołania modelu do kontekstu pobierania w celu ponownej próby do naliczonego kosztu.

Celem nie jest kolejny pulpit nawigacyjny z całkowitą liczbą tokenów. Celem jest udzielenie odpowiedzi na pytania operacyjne, takie jak:

• Który najemca lub klucz interfejsu API spowodował wzrost wydatków?
• Czy opóźnienie wzrosło po zmianie aliasu modelu?
• Czy ponowne próby lub rozwiązania awaryjne naliczają koszty podwójnie?
• Która wersja podpowiedzi generuje najwięcej błędów?
• Czy przepływ pracy RAG stał się kosztowny, ponieważ podczas pobierania dodano zbyt wiele tokenów kontekstu?
• Czy można pomóc w debugowaniu incydentu bez czytania monitów prywatnych użytkowników?

Fakty, rekomendacje i przewidywania

Fakty: OpenTelemetry dokumentuje konwencje semantyczne i atrybuty generatywnej sztucznej inteligencji dla operacji modelowych, w tym nazwy operacji, takie jak chat, generate_content i text_completion. Ta sama dokumentacja ostrzega, że ​​atrybuty komunikatów wejściowych i wyjściowych GenAI mogą zawierać poufne informacje lub informacje umożliwiające identyfikację i mogą wymagać filtrowania lub obcięcia. Główni dostawcy modeli udostępniają również pulpity nawigacyjne użytkowania, interfejsy API lub eksporty, które mogą obsługiwać uzgadnianie po stronie dostawcy, chociaż szczegóły różnią się w zależności od dostawcy.

Zalecenia: użyj OpenTelemetry do śledzenia neutralnego dla dostawcy, ale zachowaj wymiary biznesowe należące do bramy we własnych atrybutach i księgach. Nie przechowuj domyślnie surowych podpowiedzi ani wyników. Najpierw przechowuj metadane, skróty, liczbę tokenów, identyfikatory szablonów podpowiedzi, nazwy schematów, klasy błędów i etykiety bezpieczeństwa. Dodaj przechwytywanie treści tylko jako opcjonalną funkcję debugowania z kontrolowanym dostępem i krótkim czasem przechowywania.

Przewidywanie: obserwowalność LLM w mniejszym stopniu będzie dotyczyć izolowanych pulpitów nawigacyjnych dostawców, a bardziej płaszczyzn kontroli między dostawcami. Zespoły będą oczekiwać jednego miejsca do badania opóźnień, kosztów, jakości, zdarzeń związanych z zasadami, zachowań najemców i różnic w rozliczeniach w różnych modelach.

Architektura referencyjna: obserwuj całą ścieżkę żądania

Brama może zobaczyć pełny cykl życia żądań bez konieczności tworzenia przez każdy zespół aplikacji niestandardowej telemetrii. Przydatny model śledzenia zaczyna się od jednego zakresu nadrzędnego dla przychodzącego żądania klienta i zakresów podrzędnych dla kroków wpływających na koszt, opóźnienia i jakość.

Zalecana struktura przęsła

• Zakres żądań bramy: żądanie zaakceptowane, uwierzytelnione, autoryzowane, z ograniczoną szybkością i przekierowane.
• Zakres wywołań modelu: dostawca, model, operacja, użycie tokena, stan odpowiedzi i opóźnienie.
• Zakres pobierania: zapytanie do indeksu, identyfikatory dokumentów lub identyfikatory zahaszowane, liczba fragmentów, opóźnienie pobierania i udział tokenu kontekstu.
• Zakres wywołań narzędzia: nazwa narzędzia, stan, opóźnienie, klasa błędu i klasyfikacja skutków ubocznych.
• Czas ponawiania prób: powód ponawiania prób, numer próby, stan dostawcy i koszt przyrostowy.
• Zakres awaryjny: model oryginalny, model awaryjny, wyzwalacz, zasady zgodności i wynik końcowy.
• Zakres ochronny lub moderacja: przywołana zasada, decyzja, etykiety oraz to, czy dane wyjściowe zostały zablokowane lub przekształcone.
• Zakres przetwarzania końcowego: weryfikacja JSON, naprawa schematu, sprawdzanie cytatów lub ostateczne formatowanie.

Rozpiętość nadrzędna powinna zawierać stabilne identyfikatory korelacji. Przęsła podrzędne powinny posiadać znormalizowane atrybuty techniczne. Księga użytkowania powinna zawierać trwałe zapisy rozliczeniowe i analityczne. Unikaj umieszczania wszystkich informacji na etykietach metryk; wartości o dużej kardynalności, takie jak identyfikatory dzierżaw, skróty podpowiedzi i identyfikatory dokumentów, są lepiej przechowywane w śladach, dziennikach lub tabelach księgowych, a następnie agregowane w pulpitach nawigacyjnych.

Normalizuj metadane przechwytywane podczas każdego połączenia LLM

Każde żądanie modelu powinno generować spójny rekord, niezależnie od dostawcy. Dokładny schemat będzie się różnić, ale praktyczne minimum wygląda tak:

{
  "request_id": "req_01J...",
  "trace_id": "4bf92f3577b34da6a3ce929d0e0e4736",
  "ident_dzierżawcy": "dzierżawa_123",
  "id_zespołu": "zespół_456",
  "app_id": "support_bot",
  "gateway_key_id": "key_789",
  "operacja": "czat",
  "dostawca": "nazwa_dostawcy",
  "model": "identyfikator-modelu dostawcy",
  "model_alias": "czat szybkiego wsparcia",
  "prompt_template_id": "refund_policy_v5",
  "prompt_hash": "sha256:...",
  "response_schema": "support_answer_v2",
  „status”: „zakończony”,
  „klasa_błędów”: null,
  „opóźnienie_ms”: 1842,
  „tokens_wejściowy”: 2110,
  „tokeny_wyjściowe”: 384,
  „cached_input_tokens”: 1200,
  "estimated_cost_usd": "0,00492",
  "final_billed_cost_usd": null,
  „finish_reason”: „stop”,
  „liczba ponownych prób”: 0,
  „fallback_used”: fałsz,
  "content_capture_policy": "tylko metadane"

Oddziel dwie kwestie: telemetria wyjaśnia, co się stało, podczas gdy księga wykorzystania rejestruje, co należy naliczyć, uzgodnić i zgłosić. Odwołują się do siebie za pomocą identyfikatorów żądań i identyfikatorów śledzenia, ale nie muszą znajdować się w tym samym systemie przechowywania.

Zbuduj księgę tokenów i kosztów, a nie tylko liczniki

Liczniki tokenów są przydatne w przypadku wykresów, ale nie wystarczą do rozliczeń lub badania incydentów. Księga powinna reprezentować przejścia stanów. Utwórz wiersz, gdy brama zaakceptuje żądanie, a następnie zaktualizuj go w miarę postępu żądania.

Przydatne stany księgi

• zaakceptowano: pomyślnie weryfikowano uwierzytelnianie i przestrzeganie zasad.
• przekazany: żądanie zostało wysłane do dostawcy.
• streaming: dostawca zaczął zwracać tokeny.
• ukończono: odpowiedź zakończyła się pomyślnie.
• user_aborted: klient rozłączył się przed zakończeniem.
• próbowano ponownie: podjęto próbę dodatkowego dostawcy.
• fallback_used: po niepowodzeniu lub zgodności zasad wybrano inny model lub dostawcę.
• nie powiodło się: żądanie zakończyło się bez użytecznej odpowiedzi.
• uzgodnione: porównano i zastosowano dane dotyczące użytkowania lub kosztów po stronie dostawcy.

Ten model stanu pomaga wychwytywać typowe błędy rozliczeniowe i analityczne: przesyłane strumieniowo odpowiedzi w przypadku rozłączenia klienta, ponowne próby, za które dostawca pobiera opłatę, ale są ukryte przed użytkownikiem, ścieżki awaryjne, w przypadku których zliczany jest nieprawidłowy model, oraz różnice w rozliczaniu pamięci podręcznej u różnych dostawców.

Używaj konwencji OpenTelemetry GenAI, a następnie rozszerzaj je ostrożnie

Konwencje semantyczne OpenTelemetry GenAI zapewniają przenośny słownik do operacji na modelach. Używaj tych konwencji w przypadku typowych atrybutów, takich jak nazwa operacji, dostawca, model, parametry żądania, powody zakończenia odpowiedzi, użycie tokena i status błędu, jeśli mają one zastosowanie.

Jednak konwencje neutralne dla dostawców nie obejmą każdego wymiaru biznesowego bramy. Dodaj atrybuty lub kolumny księgi należące do bramy dla:

• identyfikator dzierżawy, identyfikator zespołu, identyfikator klienta sprzedawcy i identyfikator aplikacji;
• Identyfikator klucza API bramy i zakres klucza;
• plan rozliczeniowy, limit wydatków i zasady budżetu;
• Alias modelu i wersja zasad routingu;
• Identyfikator szablonu podpowiedzi i wersja podpowiedzi;
• nazwa przepływu pracy i etap przepływu pracy;
• szacunkowy koszt, ostateczny koszt naliczony i stan uzgodnienia.

Kompromisem jest liczność. Pola te są cenne do badań, ale mogą sprawić, że metryki będą drogie i zaszumione, jeśli będą wszędzie używane jako etykiety metryczne. Praktyczna zasada jest następująca: agregaty o niskiej liczności trafiają do metryk; identyfikatory o dużej kardynalności trafiają do śladów, dzienników i ksiąg.

Zaprojektuj bezpieczne rejestrowanie monitów i wyników

Pełne rejestrowanie monitów ułatwia debugowanie, ale zwiększa prywatność, zgodność, przechowywanie i narażenie na ryzyko wewnętrzne. Bezpieczniejszym rozwiązaniem domyślnym jest obserwowalność metadanych.

Domyślnie: tylko metadane

W przypadku większości ruchu produkcyjnego przechowuj:

• identyfikator i wersja szablonu podpowiedzi;
• hasze znormalizowanych podpowiedzi i wyników;
• liczba tokenów wejściowych, wyjściowych, buforowanych i kontekstowych;
• nazwa schematu odpowiedzi i wynik walidacji;
• etykiety bezpieczeństwa i decyzje polityczne;
• podsumowania błędów i klasy błędów dostawców;
• pobieraj metadane, a nie surowe dokumenty.

Wyrażenie zgody: kontrolowane przechwytywanie treści

Jeśli potrzebujesz surowej lub zredagowanej treści do głębokiego debugowania, wymagaj wyraźnych zasad. Dobre mechanizmy kontrolne obejmują listy dozwolonych środowisk, zgodę dzierżawcy, próbkowanie, maksymalną długość ładunku, automatyczną redakcję, krótkie okna przechowywania, szyfrowanie, dostęp oparty na rolach, dzienniki audytu i ścieżkę zatwierdzania po przekroczeniu szyby w przypadku poufnych incydentów.

Nie traktuj redakcji jako doskonałej. Zmniejsza ryzyko; nie eliminuje tego. W przypadku obciążeń regulowanych lub bardzo wrażliwych rozważ przechowywanie wyłącznie skrótów i odtwarzanie problemów w syntetycznej uprzęży z zatwierdzonymi danymi testowymi.

Dodaj obserwowalność RAG jako osobną warstwę

Generowanie wspomagane wyszukiwaniem może zmienić zarówno jakość, jak i koszty. Rejestrowanie tylko końcowego wywołania modelu ukrywa główną przyczynę, gdy moduł pobierający zwraca zbyt wiele fragmentów, nieaktualne dokumenty lub nieistotny kontekst.

Dla każdego etapu pobierania przechwyć:

• nazwa indeksu lub kolekcji;
• strategia wyszukiwania i model osadzania;
• identyfikatory dokumentów lub identyfikatory zahaszowane;
• liczba fragmentów i tokeny całkowitego kontekstu;
• opóźnienie pobierania;
• rozkład najlepszych wyników, jeśli jest dostępny;
• zasięg cytowań;
• czy w ostatecznej odpowiedzi użyto pobranego kontekstu.

Dzięki temu można odróżnić „model się pogorszył” od „aportera zaczął wysyłać niskiej jakości lub nadmierny kontekst”. Pomaga także zidentyfikować przepływy pracy, w których tokeny kontekstu dominują w całkowitym koszcie.

Uzgodnij użycie bramy z rozliczeniami z dostawcą

Szacunki dotyczące bramki są dostępne natychmiast. Dane rozliczeniowe po stronie dostawcy są zwykle wolniejsze, ale bardziej wiarygodne. Użyj obu.

Codzienne zadanie uzgadniania powinno porównywać wiersze księgi bramy z interfejsami API użycia dostawcy, interfejsami API kosztów, eksportami pulpitu nawigacyjnego lub eksportami faktur. Grupuj różnice według dostawcy, modelu, projektu i okna czasowego. Śledź różnice oddzielnie dla tokenów wejściowych, tokenów wyjściowych, tokenów w pamięci podręcznej, liczby żądań i kosztów.

Typowe różnice w zakresie uzgadniania

• Rozłączanie transmisji strumieniowej: brama może zobaczyć przerwanego klienta, podczas gdy dostawca nadal wystawia rachunki za wygenerowane tokeny.
• Ponowne próby: opłata może zostać naliczona za wiele prób, nawet jeśli zwrócona zostanie tylko jedna ostateczna odpowiedź.
• Szybkie buforowanie: dostawcy mogą w różny sposób udostępniać księgowanie za pomocą tokenów w pamięci podręcznej.
• Zaokrąglanie: niewielkie różnice w poszczególnych żądaniach mogą stać się widoczne na dużą skalę.
• Rabaty na partie lub poziomy: faktury dostawcy mogą obejmować ceny, których szacunki w czasie rzeczywistym nie były jeszcze znane.
• Zmiany po stronie dostawcy: ceny modeli, zachowanie tokenizacji lub eksport rozliczeń mogą z czasem się zmieniać.

Gdy podczas uzgadniania dojdzie do delty, unikaj cichego nadpisywania księgi. Zapisz oryginalne oszacowanie, wartość uzgodnioną z dostawcą, źródło uzgodnienia i kod przyczyny, jeśli jest znany.

Panele informacyjne odpowiadające na pytania operacyjne

Uruchamiaj pulpity nawigacyjne od problemów z czytnikiem, a nie od próżnych wskaźników. Przydatne widoki obejmują:

• koszt na dzierżawcę, zespół, aplikację i przepływ pracy;
• koszt udanego zadania, a nie tylko koszt żądania;
• Opóźnienie p50, p95 i p99 według dostawcy, modelu i aliasu modelu;
• wskaźnik powrotów i ponownych prób według trasy;
• Trendy współczynnika przekroczeń limitu czasu i klas błędów dostawcy;
• Współczynnik trafień w pamięci podręcznej i szacunkowe oszczędności w tokenie w pamięci podręcznej;
• wskaźnik niepowodzenia walidacji uporządkowanych wyników;
• najlepsze wersje monitów według błędu zużycia budżetu;
• Udostępnianie tokenu kontekstu RAG według przepływu pracy;
• blokady poręczy i trafienia klasyfikatora natychmiastowego wtrysku.

W celu ostrzegania połącz sygnały techniczne i biznesowe. Nagły wzrost wydatków najemców może być pilniejszy niż niewielki globalny wzrost opóźnień. Skok szybkości awaryjnej po zmianie aliasu modelu może wskazywać na problem ze zgodnością. Powtarzające się odpowiedzi 401, 429 lub 5xx mogą wskazywać na kluczowe problemy, wyczerpanie limitu lub niestabilność dostawcy.

Minimalny przebieg implementacji dla serwera proxy kompatybilnego z OpenAI

W przypadku serwera proxy /chat/completions przepływ może być prosty:

1. Odbierz żądanie i przypisz request_id oraz kontekst śledzenia.
2. Uwierzytelnij klucz bramy i określ dzierżawę, zespół, aplikację i zakres zasad.
3. Utwórz zakres bramy nadrzędnej.
4. Utwórz wiersz księgi ze stanem zaakceptowany.
5. Rozwiąż alias modelu zgodnie z modelem dostawcy i wersją zasad routingu.
6. Metadane rekordu: operacja, identyfikator szablonu podpowiedzi, nazwa schematu, skrót podpowiedzi i zasady przechwytywania treści.
7. Rozpocznij zakres wywołań modelu, używając atrybutów semantycznych GenAI, jeśli ma to zastosowanie.
8. Przekaż żądanie do wybranego dostawcy.
9. W przypadku przesyłania strumieniowego zaktualizuj stan po nadejściu pierwszej porcji i policz wykorzystanie tak dokładnie, jak pozwala na to odpowiedź dostawcy.
10. Po zakończeniu przeanalizuj użycie dostawcy, przyczynę zakończenia, stan i klasę błędu.
11. Zaktualizuj księgę o tokeny, szacunkowy koszt, szczegóły dotyczące ponownych prób/awarii i ostateczny stan żądania.
12. Emituj metryki z księgi i danych dotyczących zakresu.
13. Prowadź codzienne uzgadnianie i przechowuj koszty potwierdzone przez dostawcę oddzielnie od pierwotnych szacunków.

Lista kontrolna wdrożenia

• Zdefiniuj kanoniczne identyfikatory żądań i identyfikatory śledzenia.
• Zastosuj atrybuty OpenTelemetry GenAI na potrzeby telemetrii wspólnego modelu.
• Utwórz rejestr użytkowania bramy z żądaniami zmiany stanu.
• Normalizuj wymiary dostawcy, modelu, aliasu modelu, dzierżawy, aplikacji i przepływu pracy.
• Nie umieszczaj danych dochodzeniowych o dużej kardynalności w etykietach metryk.
• Domyślnie wyłącz nieprzetworzone monity i przechwytywanie danych wyjściowych.
• Dodaj wyraźne zasady dotyczące próbkowania, redagowania, przechowywania i kontroli dostępu.
• Przechwytuj metadane pobierania dla przepływów pracy RAG.
• Twórz pulpity nawigacyjne pod kątem kosztów, opóźnień, niezawodności, weryfikacji i zachowania najemców.
• Uzgodnij szacunki bramy z wykorzystaniem dostawcy i eksportem kosztów.
• Ostrzegaj o skokach wydatków, regresji opóźnień, skokach awaryjnych, błędach weryfikacji i zdarzeniach związanych z bezpieczeństwem.

Wniosek

Brama obsługująca wiele modeli to właściwe miejsce do wdrożenia obserwowalności LLM, ponieważ rozpoznaje żądania, zanim dotrą do dowolnego dostawcy, i może dołączyć kontekst biznesowy, którego dostawcy nie znają. Najsilniejszy projekt nie polega na „logowaniu wszystkiego”. Jest to model warstwowy: neutralne dla dostawcy śledzenie wykonania, trwały token i księga kosztów na potrzeby rozliczeń, analityka najemców na potrzeby zarządzania, metadane RAG zapewniające jakość wyszukiwania oraz szybkie rejestrowanie zapewniające prywatność w celu bezpiecznego debugowania.

Zacznij od metadanych, zmian stanu i uzgadniania. Dodawaj przechwytywanie treści tylko wtedy, gdy zasady, przechowywanie i kontrola dostępu są gotowe. Ta sekwencja zapewnia programistom dowody potrzebne do debugowania opóźnień, jakości i wydatków bez przekształcania obserwowalności w ryzyko narażenia nowych danych.

Powiązane lektury

• ponawianie prób i zachowanie awaryjne w routingu API LLM
• szybkie buforowanie i wzorce wsadowej kontroli kosztów
• zarządzanie kluczami API zespołu i limitami wydatków