3 września 2026 r. OpenAI opisało próbę, w której Legora wykorzystała GPT-6 Astra do przeglądu 41 dokumentów finansowych. Model w ciągu kilku minut wykrył wszystkie cztery celowo umieszczone błędy. OpenAI deklaruje też poprawę o blisko 40%, ale nie podaje, jaki miernik porównano ani względem jakiej linii bazowej.
Dla zespołu ofertowego w Polsce ten przypadek nie jest jeszcze dowodem skuteczności modelu na własnych dokumentach. Podpowiada jednak, jak sprawdzić AI przed wdrożeniem: przygotować zestaw ze znanymi odpowiedziami, umieścić w nim kontrolowane błędy i policzyć zarówno wykrycia, jak i fałszywe alarmy.
Co potwierdza przypadek Legory
Zestaw Legory obejmował 41 dokumentów finansowych. Umieszczono w nim cztery błędy, a GPT-6 Astra wykrył wszystkie. OpenAI określa czas przeglądu jako kilka minut i informuje o poprawie wyniku procesu o blisko 40%.
Komunikat nie wyjaśnia jednak, czego dotyczyło te 40%: czasu, dokładności, liczby wykrytych błędów czy oceny gotowego raportu. Nie podaje również liczby fałszywych alarmów ani szczegółów dotyczących porównywanego rozwiązania.
Wynik 4/4 mówi więc, że model poradził sobie z czterema przygotowanymi błędami w tym konkretnym zestawie. Nie pozwala ocenić jego skuteczności na innych dokumentach ani kosztu późniejszej kontroli wyników.
Dlaczego liczba wykrytych błędów nie wystarcza
Zespół sprawdzający AI powinien mierzyć dwa rodzaje wyników:
1. Odsetek wykrytych błędów pokazuje, ile celowo wprowadzonych niezgodności znalazł model.
2. Liczba fałszywych alarmów pokazuje, ile razy model wskazał problem w poprawnym fragmencie dokumentu.
Drugi wynik ma bezpośredni wpływ na czas pracy. Model może znajdować wszystkie zasiane błędy, a jednocześnie zgłaszać tyle nieistniejących problemów, że człowiek poświęci wiele godzin na ich sprawdzanie.
Komunikat OpenAI nie podaje liczby fałszywych alarmów w próbie Legory. Z tego powodu nie można ocenić pełnego bilansu między wykrywaniem błędów a dodatkową pracą weryfikacyjną.
Jak przygotować próbę na dokumentach ofertowych
Komunikat OpenAI nie opisuje całej metody Legory. Poniższe kroki są propozycją własnej próby dla zespołu ofertowego, a nie rekonstrukcją tego testu.
1. Ustal, co model ma sprawdzać
Zacznij od zamkniętej listy błędów. Mogą to być niezgodne kwoty, daty obowiązywania, warunki płatności, nazwy stron umowy albo rozbieżności między ofertą a załącznikiem.
Do każdego błędu przypisz prawidłową odpowiedź i wskaż fragment dokumentu, który ją potwierdza. Bez takiego wzorca nie da się jednoznacznie ocenić wyniku AI.
2. Przygotuj bezpieczne kopie dokumentów
Możesz wykorzystać zanonimizowane kopie wcześniejszych ofert lub dokumenty stworzone na potrzeby próby. Kontrolowane błędy wprowadzaj wyłącznie w kopiach, nigdy w plikach źródłowych.
Przed przesłaniem dokumentów do narzędzia sprawdź zasady przetwarzania, retencji i dostępu do danych. Więcej o takim ryzyku opisuje materiał o shadow AI i kontroli danych.
3. Dodaj dokumenty bez zasianych błędów
Część zestawu powinna pozostać poprawna. Dzięki temu sprawdzisz, czy model nie zgłasza problemów tam, gdzie ich nie ma.
Komunikat OpenAI nie mówi, czy próba Legory obejmowała takie dokumenty. We własnym procesie warto je uwzględnić, ponieważ ułatwiają ocenę fałszywych alarmów.
4. Zapisuj każde wskazanie modelu
Dla każdego zgłoszenia zanotuj:
- dokument i wskazany fragment;
- rodzaj zgłoszonego problemu;
- ocenę człowieka: prawidłowe wykrycie albo fałszywy alarm;
- czas potrzebny na sprawdzenie wyniku.
Nie zmieniaj kryteriów w trakcie próby. Jeśli poprawiasz instrukcję dla modelu, potraktuj kolejne uruchomienie jako osobny przebieg.
5. Porównaj AI z analizą ręczną
Sama szybkość działania modelu nie pokazuje oszczędności. Do czasu pracy z AI trzeba doliczyć przygotowanie plików, uruchomienie analizy i sprawdzenie wskazań przez człowieka.
Porównaj łączny czas takiego procesu z ręcznym przeglądem podobnego zestawu. W obydwu wariantach mierz te same typy błędów. Metodę szacowania kosztów i efektów opisuje również materiał o liczeniu ROI z AI.
Jak zapisać wynik próby
Karta oceny może obejmować pięć pozycji:
- liczba wszystkich zasianych błędów;
- liczba błędów wykrytych przez AI;
- liczba fałszywych alarmów;
- czas działania modelu i przygotowania plików;
- czas kontroli wyników przez człowieka.
Próg akceptacji ustal przed rozpoczęciem próby. Powinien zależeć od konsekwencji przeoczenia. Inne wymagania może mieć kontrola formatowania, a inne sprawdzanie ceny, terminu albo warunku płatności.
Jeśli model pomija błędy o istotnych skutkach lub generuje zbyt wiele fałszywych alarmów, zespół powinien poprawić instrukcję, ograniczyć zakres zadania albo zrezygnować z wdrożenia na tym etapie. Więcej o wyborze zadań, których nie warto automatyzować, znajduje się w materiale o granicach automatyzacji AI w sprzedaży.
Czego nadal nie wiadomo
Przypadek Legory opisuje jeden komunikat OpenAI, bez niezależnej walidacji. Nie znamy miernika stojącego za deklarowaną poprawą o blisko 40%, dokładnego czasu przeglądu, liczby fałszywych alarmów ani warunków porównania.
Źródło nie podaje też kosztu wdrożenia, czasu przygotowania procesu ani dostępności GPT-6 Astra dla firm działających w Polsce. Nie wiadomo również, jak model poradziłby sobie z dokumentami ofertowymi zamiast finansowych.
Wynik 4/4 warto więc potraktować jako opis jednego przypadku, a nie gotową prognozę dla własnego zespołu. Decyzję o wdrożeniu powinny poprzedzić wyniki uzyskane na dokumentach i błędach typowych dla konkretnego procesu.
Źródła
- OpenAI, Legora reviewed 41 documents in minutes with GPT-6 Astra, 3 września 2026 r.
