BlogUtrzymanie
Co zachować w śladzie wykonania AI
Dużą część debugowania agenta można zacząć od kształtu przebiegu zamiast od jego pełnej treści: który model i które narzędzia zostały wywołane, w jakiej kolejności, z jakim statusem, opóźnieniem i liczbą tokenów. Te metadane zachowuj rutynowo. Prompty i treść wywołań narzędzi przechwytuj tylko wtedy, gdy uzasadnia to określona potrzeba debugowania, przechowuj je osobno, z węższym dostępem i okresem przechowywania ustalonym przez właścicieli danych, a poświadczeń nie trzymaj w żadnym z tych miejsc.
Czego naprawdę używa się przy debugowaniu
Pierwsze pytania dyżurnego inżyniera dotyczą struktury: dlaczego agent wywołał to narzędzie, czemu przebieg trwał czterdzieści sekund, czemu kosztował trzy razy więcej niż zwykle, gdzie się wywrócił. Na większość odpowiada drzewo spanów z nazwami operacji, modelem żądanym i zwróconym, zużyciem tokenów, nazwami narzędzi, typami błędów i czasami trwania oraz identyfikatorem łączącym przebieg ze sprawą biznesową. Konwencje semantyczne OpenTelemetry dla generatywnej AI, wciąż oznaczone jako rozwojowe, definiują atrybuty dla większości tych danych. Pełna treść jest potrzebna do węższych zadań: odtworzenia błędnej odpowiedzi, oceny jakości wyniku i badania podejrzenia prompt injection.
Trzy poziomy danych śladu
- 1
Poziom 1: metadane operacyjne
Struktura spanów, nazwy modeli, liczby tokenów, nazwy narzędzi, statusy, czasy i pseudonimowe odwołanie do użytkownika. Bez treści wiadomości. Przechowywane zgodnie ze zwykłym okresem retencji logów operacyjnych.
- 2
Poziom 2: treść przechwytywana z decyzji
Prompty, instrukcje systemowe, wyniki, argumenty i wyniki narzędzi, pobrane fragmenty. Przechwytywane tylko dla określonej próbki, oznaczonych przebiegów albo ograniczonego w czasie dochodzenia, przechowywane osobno od poziomu 1, z węższym dostępem i krótszym okresem ustalonym przez właścicieli polityk.
- 3
Poziom 3: nigdy nie zapisywane
Tokeny dostępu, klucze API, hasła, ciągi połączeń i surowe identyfikatory sesji. OWASP Logging Cheat Sheet wymienia je wśród danych, które zwykle należy usunąć, zamaskować, zahashować lub zaszyfrować zamiast logować wprost.
Domyślnie trzymaj treść poza śladami
Konwencje OpenTelemetry dla generatywnej AI traktują instrukcje dla modelu, wiadomości użytkowników i wyniki jako wrażliwe. Mówią, że instrumentacja nie powinna ich domyślnie przechwytywać, ale powinna oferować opcję włączenia, a na produkcji zalecają przechowywanie treści na zewnątrz i zapisywanie w spanach tylko odwołań, by treść mogła mieć własne reguły dostępu. Biblioteki spoza OpenTelemetry mogą działać inaczej, a wytyczne OpenTelemetry dotyczące danych wrażliwych czynią sprawdzanie tego, co emituje twoja instrumentacja, twoim obowiązkiem. Sprawdź rzeczywiste wyjście każdej biblioteki w przebiegu testowym, zamiast polegać tylko na jej dokumentacji.
Redakcja jako druga linia obrony
OpenTelemetry Collector potrafi usuwać, hashować lub przepisywać atrybuty, odrzucać całe spany, a procesorem redaction usuwać atrybuty spoza allowlisty. Dla poziomu 1 używaj allowlisty, żeby nowy atrybut nie prześlizgnął się niezauważony. Nie polegaj na redakcji wolnego tekstu opartej na wzorcach: dane osobowe pojawiają się w promptach w formach, których żaden wzorzec nie przewiduje. OpenTelemetry ostrzega też, że zahashowanie małej lub przewidywalnej wartości, na przykład liczbowego identyfikatora użytkownika, może jej nie zanonimizować, bo hash da się odwrócić, sprawdzając wszystkie możliwe wartości.
Kto ustala okres przechowywania
To, jak długo przechowuje się każdy poziom, jest decyzją właścicieli ochrony danych, spraw prawnych i bezpieczeństwa, a nie domyślnym ustawieniem inżynierskim, i ten artykuł nie jest poradą prawną. OWASP Logging Cheat Sheet ujmuje zasadę wprost: dane z logów nie powinny być usuwane przed upływem wymaganego okresu ani przechowywane dłużej. Inżynieria sprawia, że tę decyzję da się wyegzekwować:
- Osobny magazyn dla każdego poziomu z wygasaniem skonfigurowanym w samym magazynie
- Usuwanie obejmujące też eksporty, kopie w zestawach ewaluacyjnych i kopie zapasowe
- Log dostępu do poziomu 2 przeglądany przez kogoś spoza zespołu, który go czyta
- Rejestr tego, co przechwytuje każda usługa, aktualizowany przy każdej zmianie instrumentacji
Jeśli ślady mogą pokazywać pracę konkretnych pracowników, wcześnie włącz osoby, które zajmują się danymi pracowniczymi.
Hipotetyczna sesja debugowania według tych zasad
Agent AI w dziale wsparcia podaje klientowi błędną kwotę zwrotu. Dyżurny otwiera ślad po numerze sprawy. Poziom 1 pokazuje, że agent wywołał wyszukiwanie zamówienia, a potem narzędzie do wyliczenia zwrotu, które zadziałało szybko i z normalną liczbą tokenów, więc błąd tkwi w danych wejściowych albo w logice. Argumenty narzędzia należą do poziomu 2 i nie zostały przechwycone. Inżynier prosi o ograniczone w czasie przechwytywanie dla tego jednego narzędzia, właścicielka danych się zgadza, a przebieg z syntetycznym zamówieniem na stagingu pokazuje, że kwota została przekazana bez waluty. Po poprawce przechwytywanie zostaje wyłączone, a zebrana treść wygasa w uzgodnionym terminie.
Pytania
Czy na stagingu możemy trzymać pełne prompty?
Jeśli staging działa na danych syntetycznych lub zamaskowanych, pełne przechwytywanie niesie tam niewielkie ryzyko i często jest najprostszą drogą do debugowania. Konwencje OpenTelemetry wskazują środowiska przedprodukcyjne jako przypadek, w którym zapisywanie treści w spanach może się sprawdzić, o ile wolumen jest do opanowania, a magazyn spełnia obowiązujące zasady prywatności.
Czy zestawy ewaluacyjne zbudowane ze śladów też się liczą?
Tak. Dziedziczą treść i związane z nią pytania o retencję. Przenoś przykłady do zestawu ewaluacyjnego tylko przez sprawdzony krok, który usuwa lub zastępuje dane osobowe, i zapisuj, skąd pochodzi każdy przykład.
A co z logami samego dostawcy modelu?
Są poza twoim magazynem śladów i podlegają warunkom dostawcy oraz twojej umowie. Uwzględnij je obok własnych poziomów w opisie przepływu danych, który przeglądają właściciele polityk.
Powiązane usługi
Inżynieria i architektura AI
Asystenci, interfejsy głosowe i agenci w produktach, które sprzedajesz, razem z serwowaniem modeli i wyszukiwaniem pod spodem.
Agenci AI i automatyzacja procesów
Agenci, którzy przejmują rutynowe kroki złożonych spraw i przekazują decyzje ludziom, z kosztem każdej obsłużonej sprawy.
Tworzenie serwerów MCP
Serwery MCP łączące zatwierdzone wewnętrzne API z asystentami AI, z wąskimi uprawnieniami, akceptacją zmian i testami.
Więcej z bloga
Runbooki dla funkcji AI
Co powinien zrobić dyżurny inżynier, gdy funkcja AI jest wolna, niedostępna, droga, błędna albo działa poza swoimi granicami: klasy objawów, wpisy runbooka, bezpieczne przełączniki i właściciele.
Sekrety i poświadczenia agentów
Gdzie powinny być przechowywane poświadczenia agentów i integracji z modelami, jak dać każdemu agentowi własną tożsamość, jak rotować je bez psucia trwających procesów i co zrobić po wycieku.
Granice wobec prompt injection
Jak ograniczyć szkody, gdy agent wykona polecenie ukryte w dokumencie, e-mailu lub wyniku narzędzia: zmapuj niezaufane wejścia na akcje, przetnij ścieżki i przetestuj granice.
Porozmawiaj z inżynierem
Przyjdź z jednym zadaniem, które chcesz usprawnić. Rozmowa trwa 30 minut i nie wymaga dostępu do twoich systemów ani danych.
Rezerwacja odbywa się w Kalendarzu Google.
Wolisz najpierw napisać? Zostaw adres e-mail i kilka zdań, a odpowiemy, proponując terminy.
Sprawdź wersję roboczą w swoim programie pocztowym
Wyślij ją stamtąd, a inżynier odpowie ci osobiście, proponując terminy 30-minutowej rozmowy. Jeśli wersja robocza się nie otworzyła, napisz do nas na adres miki@cloudsail.com.