--- title: "Ocena proof of concept agenta AI przed skalowaniem" description: "Jak ocenić proof of concept agenta AI: kryteria sukcesu, zestawy testowe, koszt i opóźnienie, kontrola człowieka, granice danych i bezpieczeństwa, typy błędów." canonical: https://sdk.enterprises/pl/insights/evaluating-an-ai-agent-proof-of-concept language: pl --- # Ocena proof of concept agenta AI przed skalowaniem Zaktualizowano: 2026-09-26 > Proof of concept agenta AI ocenia się według kryteriów sukcesu spisanych przed jego zbudowaniem, na stałym zestawie prawdziwych przypadków, łącznie z trudnymi. Należy zmierzyć trafność, koszt jednego zadania i opóźnienie, sprawdzić, do jakich danych i narzędzi agent ma dostęp i w jaki sposób zawodzi, a skalować dopiero wtedy, gdy wyniki utrzymują się poza pokazem. ## Przekonujące demo to jeszcze nie dowód Demo pokazuje agenta AI z najlepszej strony, bo działa na przykładach wybranych i przećwiczonych przez jego twórców. Przed skalowaniem pytanie jest inne: jak często agent poprawnie wykonuje prawdziwą pracę, ile kosztuje każde zadanie i co się dzieje w dni, gdy się myli? Proof of concept warto traktować jak eksperyment zakończony decyzją: skalować, zmienić albo przerwać. Ta decyzja wymaga kryteriów spisanych, zanim pojawią się wyniki; w przeciwnym razie niemal każdy wynik można odczytać jako obiecujący. ## Kryteria sukcesu spisane przed budową agenta Najpierw trzeba określić, co dla firmy oznacza wystarczająco dobry wynik, a potem przełożyć to na mierzalne liczby. Dla agenta, który sortuje zgłoszenia do działu obsługi, może to być odsetek zgłoszeń skierowanych do właściwego zespołu, odsetek przypadków, których obsługi słusznie odmawia, oraz czas, jaki człowiek poświęca na sprawdzenie każdego z nich. - Odsetek poprawnie wykonanych zadań na realistycznych przypadkach, ze spisaną definicją poprawnego wyniku - Błędy, które można tolerować, i te, których nie można, na przykład błędna odpowiedź wysłana do klienta - Koszt jednego wykonanego zadania, łącznie z użyciem modelu i czasem osoby, która sprawdza pracę - Czas odpowiedzi dopasowany do procesu, w zależności od tego, czy ktoś czeka na odpowiedź - Punkt odniesienia: ile czasu zajmuje to zadanie ludziom dziś i jak często wykonują je poprawnie ## Testy na stałym zestawie ewaluacyjnym z prawdziwych przypadków Należy zebrać prawdziwe dane wejściowe z własnej historii, zapisać dla każdego poprawny wynik i nie zmieniać tego zestawu. Warto uwzględnić przypadki łatwe, niejednoznaczne, rzadkie i kilka takich, które agent powinien odrzucić. Mniejszy zestaw dobrze dobranych przypadków mówi więcej niż duży zestaw łatwych. Agenta uruchamia się na całym zestawie za każdym razem, gdy zmienia się prompt, model, narzędzia lub dane, i porównuje wyniki z poprzednim przebiegiem. Odpowiedzi modelu różnią się między uruchomieniami, więc każdy przypadek warto uruchomić więcej niż raz i patrzeć na powtarzalność, a nie tylko na najlepszą odpowiedź. Przypadki testowe nie mogą trafić do promptu ani do przykładów, które widzi agent, bo wynik będzie mu schlebiał. Trzeba też sprawdzić sam sposób oceniania. Automatyczne kontrole działają przy ustrukturyzowanych wynikach. Swobodny tekst zwykle wymaga człowieka albo drugiego modelu, którego oceny porównano na próbce z ocenami człowieka. ## Koszt i opóźnienie mierzone przy oczekiwanej skali Proof of concept, który obsługuje kilkadziesiąt zgłoszeń dziennie, może ukrywać koszty istotne przy tysiącach. Należy rejestrować wywołania modelu, tokeny i wywołania narzędzi dla każdego zadania oraz czas jego trwania. Agenci, którzy wpadają w pętle, ponawiają próby lub czytają długie dokumenty, przy niektórych danych wejściowych mogą kosztować znacznie więcej niż średnio, dlatego warto analizować najwolniejsze i najdroższe przypadki, a nie tylko średnią. Następnie trzeba oszacować koszt przy oczekiwanej skali i porównać go z tym, ile ta praca kosztuje dziś, łącznie z czasem, który ludzie nadal poświęcą na przegląd. Dla każdego zadania warto ustawić twarde limity kroków, tokenów i czasu, aby jedno złe wejście nie wygenerowało wysokiego rachunku. OWASP Top 10 for LLM Applications opisuje to ryzyko jako nieograniczone zużycie (unbounded consumption). ## Przemyślana kontrola człowieka, a potem jej pomiar Kontrola człowieka jest częścią projektu, a nie tymczasową siatką bezpieczeństwa. Trzeba zdecydować, które działania agent może podejmować samodzielnie, które tylko proponować, a których nigdy nie może podjąć. Wszystko, co nieodwracalne lub widoczne dla klientów, na przykład wysłanie wiadomości, zmiana rekordu czy wydanie pieniędzy, powinno czekać na zatwierdzenie przez człowieka, dopóki agent nie ma za sobą długiej historii poprawnej pracy. Mierzy się też sam przegląd: ile trwa, jak często osoby sprawdzające zmieniają wynik i jak często zatwierdzają go bez rzeczywistego sprawdzenia. Jeśli przegląd trwa niemal tyle, co samo zadanie, agent jeszcze nie oszczędza czasu. Jeśli dany przypadek użycia mógłby zostać uznany za system wysokiego ryzyka w rozumieniu unijnego AI Act, skuteczny nadzór człowieka jest wymogiem prawnym na podstawie art. 14, a nie kwestią projektową, dlatego warto wcześnie zaangażować doradców prawnych. ## Granice danych i bezpieczeństwa ustalone przed skalowaniem Skalowanie oznacza więcej danych, więcej użytkowników i więcej narzędzi, i właśnie wtedy słabe granice zaczynają mieć znaczenie. OWASP Top 10 for LLM Applications stawia na pierwszym miejscu prompt injection: tekst, który agent czyta, na przykład e-mail, zgłoszenie czy strona internetowa, może zawierać instrukcje, które zmieniają jego działanie. Wymienia też nadmierną sprawczość (excessive agency), czyli więcej funkcji, uprawnień lub autonomii, niż wymaga zadanie. Te kwestie trzeba rozstrzygnąć, zanim pilotaż się rozrośnie. - Jakie dane agent może czytać i czy dane osobowe lub poufne trafiają do dostawcy modelu, na podstawie jakiej umowy i z jakim okresem przechowywania - Jakie narzędzia może wywoływać, z najwęższymi uprawnieniami i osobnymi danymi uwierzytelniającymi dla każdego agenta - Co może zmieniać i czy każdą zmianę da się prześledzić i cofnąć - Co trafia do dziennika: każde wywołanie narzędzia z danymi wejściowymi i wyjściowymi, bez wycieku danych osobowych - Jak dane każdego klienta lub zespołu są oddzielone od danych pozostałych ## Analiza błędów, a potem decyzja Przed podjęciem decyzji warto przeczytać błędy, a nie tylko spojrzeć na wynik. Należy je pogrupować według rodzaju: pewne siebie błędne odpowiedzi, słuszne odmowy, pominięte kroki, złe użycie narzędzi, przekroczone limity czasu. Agenta, który w razie problemu prosi o pomoc, znacznie łatwiej wdrożyć niż takiego, który po cichu zawodzi, podając wiarygodnie brzmiącą odpowiedź. Potem przychodzi decyzja. Skalować, jeśli kryteria są spełnione na zestawie ewaluacyjnym, a pozostałe błędy proces jest w stanie wchłonąć. Zawęzić zakres, jeśli agent dobrze radzi sobie tylko z częścią zadania. Przerwać, jeśli nie wypada lepiej niż punkt odniesienia, i zachować zestaw ewaluacyjny na następną próbę. Nasze projekty agentów AI przebiegają w tej samej kolejności: jedno zadanie, prawdziwe przykłady, przegląd przez Państwa zespół i szerszy zakres dopiero wtedy, gdy agent zasłuży na zaufanie. Jeśli mają Państwo proof of concept do oceny, można go opisać w naszym formularzu „Rozpocznij projekt”. ## Najważniejsze wnioski - Kryteria sukcesu i punkt odniesienia trzeba spisać przed budową agenta, aby wynik dało się uczciwie ocenić. - Testy na stałym zestawie prawdziwych przypadków, łącznie z trudnymi i niejednoznacznymi, powtarza się po każdej zmianie. - Koszt zadania i opóźnienie mierzy się przy oczekiwanej skali, patrząc zarówno na najgorsze przypadki, jak i na średnią. - Kontrolę człowieka projektuje się świadomie i mierzy, ile trwa i co wyłapuje. - Granice danych, narzędzi i dzienników ustala się przed skalowaniem, bo prompt injection i nadmierna sprawczość to znane ryzyka. ## FAQ ### Ile przypadków potrzeba w zestawie ewaluacyjnym agenta AI? Nie ma stałej liczby. Zestaw musi pokrywać główne warianty zadania, przypadki trudne i niejednoznaczne oraz te, które agent powinien odrzucić. Warto zacząć od tego, co da się starannie opisać, i dodawać każdy prawdziwy błąd wykryty później. ### Czy inny model może oceniać wyniki agenta? Tak, przy wynikach w formie swobodnego tekstu, które trudno sprawdzić automatycznie, ale dopiero po porównaniu jego ocen z ocenami człowieka na próbce przypadków. Tę zgodność trzeba sprawdzać ponownie przy każdej zmianie modelu lub promptu. ### Kiedy przerwać proof of concept agenta AI? Gdy według przyjętych kryteriów sukcesu nie wypada lepiej niż obecny sposób wykonywania zadania albo gdy wymagany przegląd kosztuje tyle czasu, ile agent oszczędza. Jasna decyzja o przerwaniu to użyteczny wynik: warto zachować zestaw ewaluacyjny, bo nowszy model lub węższe zadanie może go później przejść. ## Zacznijmy od Państwa potrzeby - [AI dla MŚP](https://sdk.enterprises/pl/ai-for-smes) - [Bezpłatny audyt AI](https://sdk.enterprises/pl/free-ai-audit) ## Powiązane usługi - [Agenci AI](https://sdk.enterprises/pl/services/ai-agents) - [Bezpieczeństwo aplikacji](https://sdk.enterprises/pl/services/secure-systems) ## Warto przeczytać - [Agenci AI do code review, testów i wdrożeń: jak bezpiecznie](https://sdk.enterprises/pl/insights/ai-agents-engineering-workflows) - [Jak zabezpieczyć API z danymi wrażliwymi lub regulowanymi](https://sdk.enterprises/pl/insights/securing-regulated-data-apis)