Agent AI i cała baza: jak sprawdzić kompletność odczytu

W raporcie jest 30 sprawdzonych opisów i zdanie: „Przejrzałem cały katalog”. W odpowiedzi narzędzia, kilka wierszy wyżej, został link do następnej strony. Asystent pożegnał się z bazą, chociaż baza miała mu jeszcze sporo do powiedzenia.

Przyjrzyjmy się fikcyjnej wypożyczalni wyposażenia. Zleciła agentowi ocenę opublikowanych polskich opisów. Do uzgodnionego zakresu należy 245 rekordów, których identyfikatory firma zachowała w eksporcie odniesienia. Agent otrzymał pierwszą trzydziestkę i ocenił ją całkiem sensownie. Problem leży przed oceną: pozostałych 215 opisów w ogóle nie pobrał. Lepszy prompt o staranności nie sprawi, że niewysłane żądanie samo poleci do serwera.

„Cały” musi mieć adres i warunki

Zanim zaczniesz liczyć strony, zapisz, co ma zostać pobrane. W naszej wypożyczalni chodzi o publiczne opisy w języku polskim z jednego katalogu, w uzgodnionym stanie. Archiwum wycofanego sprzętu oraz szkice nowych pozycji pozostają poza zleceniem. Licznik wszystkich rekordów w panelu administratora może więc pokazywać inną wartość niż lista dostępna agentowi.

Nie próbuj wyrównać tych liczb przez poszerzanie uprawnień. Najpierw porównaj definicje zbiorów. Jeśli agent miał przeczytać publiczne opisy, brak dostępu do prywatnych szkiców jest zgodny z zadaniem. Jeżeli ktoś oczekiwał również szkiców, potrzebna jest nowa decyzja o zakresie i dostępie. Szersze uprawnienia nie doprecyzują zlecenia.

W rejestrze przepływu danych AI zapisz źródło odczytu i używaną rolę. Do raportu z tego zadania wystarczy wskazanie projektu, języka, statusu i sposobu wyznaczenia stanu odniesienia. Nie kopiuj wartości klucza dostępu ani danych uwierzytelniających do tabeli kontrolnej. Osoba odbierająca potrzebuje odtworzyć zakres, a nie odziedziczyć sekret.

Sprawdź także, co zwraca API — interfejs, przez który program pobiera dane. Lista tytułów i identyfikatorów może być kompletnym indeksem, lecz nadal nie zawierać opisów potrzebnych do oceny. Wtedy zadanie ma dwa odczyty: zebranie właściwych pozycji oraz pobranie treści każdej z nich. Nie zamieniaj pierwszego w dowód wykonania drugiego.

W naszym przykładzie eksport odniesienia zawiera identyfikatory 245 opisów. Po pobraniu agent ma wykazać zgodność tego zestawu z otrzymanymi identyfikatorami, a przy każdym opisie zachować oznaczenie wersji. Zestawienie nazw produktów byłoby za słabe: dwie pozycje mogą mieć podobną nazwę, a jeden produkt może ją zmienić podczas pracy.

Jeśli system nie udostępnia wiarygodnej liczby całkowitej ani eksportu, nazwij tę granicę. Można potwierdzić przejście udokumentowanej drogi stronicowania do końca. To inny dowód niż porównanie z niezależnie ustalonym zestawem. Raport powinien wyjaśniać, który z nich rzeczywiście istnieje, zamiast dobierać najładniejszą liczbę dostępną na ekranie.

Koniec strony nie oznacza końca katalogu

Dokumentacja stronicowania GitHub REST API opisuje nagłówek Link z adresami kolejnych stron. Zwraca też uwagę, że zbyt wysoka wartość per_page może zostać obniżona do dopuszczalnego maksimum bez błędu żądania. Samo zażądanie ogromnej paczki nie potwierdza więc jej otrzymania.

Własna integracja powinna korzystać ze sposobu kontynuacji podanego przez konkretny system. Może to być link, numer strony albo kursor — otrzymane oznaczenie miejsca dalszego odczytu. Nie zakładaj, że dwa API używają tych samych pól. Jeśli odpowiedź zawiera adres następnej strony, agent powinien go zauważyć i obsłużyć, zamiast uznać wygodną długość listy za decyzję serwera o zakończeniu.

Google w wytycznych AIP-158 dopuszcza stronę krótszą od żądanej, nawet pustą, mimo że zbiór jeszcze się nie skończył. O końcu informuje brak kolejnego tokenu. Dokument rozróżnia też token kontynuacji i uprawnienie: każde żądanie nadal wymaga autoryzacji.

Dlatego reguła „otrzymano mniej niż 100, więc gotowe” wymaga podstawy w kontrakcie wybranego wejścia. Nie przenoś jej z innej usługi. W próbie kontrolnej zwróć krótszą stronę wraz z prawidłową kontynuacją. Następna pozycja powinna nadal trafić do zbioru. Jeśli agent kończy pracę, znaleziono konkretny błąd odbioru, zanim zaczęto oceniać jakość jego opinii o opisach.

Oddziel też koniec strony API od urwanego wyświetlenia odpowiedzi przez narzędzie. Serwer mógł odesłać całą stronę, a asystent zobaczyć tylko jej początek. Potrzebny jest odczyt brakującej części albo inna droga pobrania. Informacja o wywołaniu narzędzia nie dowodzi, że cała zwrócona treść znalazła się w materiale użytym do pracy.

To granica wcześniejsza niż wykorzystanie długiego kontekstu przez AI. Tam sprawdzamy, czy model użył przekazanego wyjątku. Tutaj pytamy, czy odpowiedni rekord w ogóle dotarł do dalszej oceny. Zmienianie modelu może pozostawić ten sam brak, jeżeli oba dostają identycznie obciętą listę.

Przy każdym kroku zachowaj oznaczenie wejściowego kursora, liczbę odebranych pozycji i informację o kontynuacji. Nie trzeba dołączać całej treści produktów do każdego wpisu dziennika. Przyda się natomiast wykrycie powtórzonego kursora: integracja krążąca po tej samej stronie nie powinna produkować coraz większego raportu o rzekomo rosnącej kompletności.

W naszym zadaniu język i status powinny pozostać takie same przez cały odczyt. Jeśli po trzeciej stronie ktoś zmieni filtr z polskich opisów na wszystkie języki, dalsza lista odpowiada już innemu pytaniu. Zapisany kursor nie powinien służyć do ukrycia tej zmiany. Gdy trzeba rozszerzyć zakres, rozpocznij odrębny przebieg i zachowaj jego warunki. Zespół będzie mógł porównać oba wyniki, zamiast odgadywać, od którego miejsca do zestawienia zaczęły wpadać inne rekordy.

Suma się zgadza, a czterdziestu pozycji nie ma

Dla sprawdzenia mechanizmu przygotowaliśmy odizolowaną próbę na 245 sztucznych identyfikatorach. Przy stronach po 40 pozycji poprawny przebieg obejmuje sześć pełnych stron i ostatnią z pięcioma rekordami. Nie są to dane klienta ani wynik testu konkretnej usługi. Taka mała baza pozwala ustalić z góry, co dokładnie ma wrócić.

W wadliwym wariancie trzecia odpowiedź zawiera ponownie drugą czterdziestkę. Pozostałe strony są poprawne. Surowa suma nadal wynosi 245 rekordów. Unikalnych identyfikatorów jest jednak 205, a czterdziestu oczekiwanych nie otrzymano. Dopóki odbiór sprawdza tylko długość listy, powtórzona strona może zastąpić brakującą bez naruszenia ulubionej liczby raportu.

Nie usuwaj duplikatów po cichu i nie ogłaszaj sukcesu na pozostałym materiale. Zapisz, które identyfikatory powtórzono, czego brakuje i przy jakim przejściu to nastąpiło. Jeżeli ponowienie pobrania jest dozwolone, wróć do właściwego punktu według zasad API. Nie dopisuj braków na podstawie podobnych tytułów ani domysłu, że to zapewne stare produkty.

Ten sam kontrolny zestaw może zawierać obcy identyfikator w miejsce oczekiwanego. Wtedy liczba odebranych i liczba unikalnych będą poprawne, lecz zestaw nadal inny. Dlatego porównujemy konkretne elementy z zakresem odniesienia. Dla zakresu 245 pozycji trzeba więc potwierdzić również ich tożsamość. Sama zgodność dwóch liczników ukryłaby podmianę.

Po kompletnym odczycie dopiero zaczyna się sprawdzenie, czy agent przypisał wynik do właściwej pozycji. Odbiór przetwarzania wsadowego obejmuje ten późniejszy etap. Można poprawnie pobrać 245 opisów i później zamienić ich oceny miejscami. Można również bezbłędnie ocenić 30 pobranych opisów i nigdy nie zobaczyć reszty. To różne usterki, z innymi miejscami naprawy.

Jeszcze inna liczba może pojawić się w końcowym raporcie: opisy wymagające poprawy. Załóżmy, że indeks zawiera wszystkie 245 pozycji, lecz pobranie treści dwóch zakończyło się błędem. Agent ocenił pozostałe 243 i wskazał 17 do przeredagowania. Te 17 może być poprawnym wynikiem analizy części zbioru. Nie potwierdza jednak, że dwa brakujące opisy są dobre. Osoba odbierająca powinna zobaczyć osobno zakres indeksu, zakres pobranej treści i zakres wykonanej oceny.

Ustal to przed uruchomieniem, szczególnie gdy odbiorca chce dostać wyłącznie listę problemów. W takim formacie nieobecność produktu w raporcie może znaczyć „sprawdzony, bez uwag”, „nie pobrano” albo „nie oceniono”. Każda odpowiedź prowadzi do innego działania. Wystarczy zachować zestawienie stanów poza zwięzłą listą zaleceń; nie trzeba dorzucać 245 pełnych opisów do maila. Zachowaj sposób odnalezienia dwóch nierozstrzygniętych pozycji, żeby wrócić właśnie do nich.

Nie zastępuj błędu pobrania pustym opisem. Taka zamiana zmieniłaby problem techniczny w pozorną ocenę treści produktu. Jeżeli firma zamierza zlecić poprawki na podstawie raportu, rekord bez odczytanej zawartości powinien najpierw trafić do wyjaśnienia. W przeciwnym razie autor dostanie zadanie poprawienia tekstu, którego recenzent nawet nie zobaczył.

Jedna lista potrzebuje jednego punktu w czasie

Podczas kolejnego odczytu zespół publikuje nowy opis i wycofuje stary. Liczba pozycji nadal wynosi 245. Jeżeli kolejne strony powstają z bieżącego stanu, agent może połączyć początek dawnego katalogu z końcem nowego. Nawet zgodność liczby unikalnych identyfikatorów nie rozstrzyga wtedy, czy odtworzono stan uzgodniony na początku.

Sprawdź, jakie zasady spójności oferuje konkretne API. Jeżeli pozwala czytać zamrożoną rewizję, kontynuuj w tej rewizji i odbierz oznaczenie każdej strony. Jeżeli wymaga restartu po zmianie, zachowaj niepełny przebieg oddzielnie i zacznij od nowa. Samo użycie kursora nie jest uniwersalną gwarancją niezmienności danych.

Gdy usługa nie oferuje takiej gwarancji, zespół może wybrać uzgodniony eksport albo ograniczyć wniosek do obserwacji z przedziału odczytu. Nie opisuj jej jako jednej dokładnej fotografii bazy. W przykładzie wypożyczalni porównanie z zachowanym eksportem pozwala rozpoznać różnicę, lecz nie nadaje serwerowi właściwości, których on nie ma.

Hash przekazanego pliku pomaga potwierdzić, że kolejne osoby użyły tego samego eksportu. Nie dowodzi jego kompletności względem systemu źródłowego. Do tej oceny nadal potrzebujesz sposobu utworzenia pliku, zakresu oraz rozpoznanej granicy czasowej. Dwa identyczne niepełne pliki pozostają zgodnie niepełne.

Przerwanie odczytu również powinno pozostać widoczne. Zalecenia GitHub dotyczące limitów API przewidują odczekanie czasu podanego w Retry-After, gdy taki nagłówek występuje, oraz ograniczone ponowienia. Odpowiedź o przekroczonym limicie nie jest pustą ostatnią stroną.

W naszym katalogu agent po błędzie na piątej stronie powinien zachować informację o nieukończonym pobieraniu. Może wznowić odczyt, jeśli nadal pozwalają na to token oraz spójność wersji. Jeżeli nie pozwalają, potrzebny jest nowy przebieg. Dalszy raport może opisywać już ocenione pozycje, ale nie powinien otrzymać etykiety kompletnego przeglądu.

Podobnie fragment odpowiedzi przesyłanej strumieniowo nie zastępuje potwierdzonego zakończenia. Przy liście odróżnij pobranie treści strony, rozpoznanie jej kontynuacji i zakończenie całego zakresu. Dzięki temu przerwany odczyt ma własny stan, zamiast znikać w ogólnym błędzie „AI odpowiedziała za krótko”.

Do rozmowy z Aeneia Audit przygotuj jedno zlecenie, opis wejścia API i niewielki dozwolony materiał odniesienia. Przegląd sposobu pracy agenta może wtedy pokazać, który dowód jest osiągalny, a gdzie trzeba ograniczyć wniosek. Nie wymaga to przenoszenia całej prawdziwej bazy do kolejnej rozmowy z modelem.

Osoba odbierająca powinna móc wskazać zakres, ostatni rozpoznany stan odczytu i zgodność otrzymanego zestawu. Jeśli agent dotarł tylko do trzydziestej pozycji, raport nadal może zawierać trzydzieści użytecznych ocen. Niech je odda pod właściwą nazwą. Katalog nie staje się krótszy dlatego, że asystent uznał akapit końcowy za dobry moment na zakończenie pracy.