TTMS Blog
Świat okiem ekspertów IT
Wpisy autorstwa: Marcin Kapuściński
AI w środowisku GxP: od pilotażu do zwalidowanego wdrożenia
Błędnie przypisana kategoria dokumentu może sprawić, że ważny zapis trafi w niewłaściwe miejsce w systemie. W farmacji taki błąd ma znaczenie dla integralności danych i pracy z dokumentacją regulowaną. To jeden z przykładów, które podczas webinaru „Deploying AI in the GxP World” pokazały, jak wiele decyzji trzeba podjąć, zanim sztuczna inteligencja zacznie wspierać codzienną pracę w środowisku GxP. 13 października 2026 roku uczestniczyliśmy w webinarze „Deploying AI in the GxP World”, zorganizowanym przez ISPE Poland wspólnie z ProductLife Group (PLG). Podczas spotkania wystąpiły Naomi Ofili i Gabrièle Piaton z PLG. Omówiły ocenę ryzyka, walidację i zabezpieczenia potrzebne do przejścia od pilotażu AI do wdrożenia, którego działanie można udokumentować i poddać ocenie podczas inspekcji. Webinar był częścią cyklu związanego z konferencją AI in Pharma 2026. 1. Czym jest GxP i jak wpływa na wdrażanie AI w farmacji? GxP to zbiorcze określenie dobrych praktyk dotyczących m.in. wytwarzania produktów leczniczych, badań klinicznych i nadzoru nad bezpieczeństwem farmakoterapii. Jedną z głównych tez webinaru było to, że ocenę zastosowania AI należy rozpocząć od jego przeznaczenia i wpływu na konkretny proces. Ten sam model może wspierać zadania o bardzo różnym znaczeniu dla jakości produktu, bezpieczeństwa pacjenta i dokumentacji. Prelegentki wyjaśniły to na przykładzie tłumaczeń. Tłumaczenie korespondencji wewnętrznej oraz informacji o produkcie przekazywanych organom regulacyjnym wymagają odrębnej oceny. Podobnie jest z analizą literatury: zakres wymagań zależy od tego, czy wyszukiwanie służy obserwacji rynku, czy identyfikowaniu informacji o bezpieczeństwie leków. Znaczenie ma także dalsze wykorzystanie wyniku AI. Tekst, klasyfikacja lub metadane mogą stać się częścią dokumentacji regulowanej. Dlatego ocena powinna uwzględniać rolę rozwiązania w procesie, jego wpływ na zapisy GxP oraz konsekwencje błędu. Prelegentki zalecały przeprowadzenie tej analizy już przy opracowywaniu uzasadnienia biznesowego projektu, aby wcześniej określić zakres walidacji, potrzebne zasoby i koszty. 2. Walidację AI trzeba zaplanować na cały okres użytkowania Walidacja służy udokumentowanemu potwierdzeniu, że system nadaje się do zamierzonego zastosowania. Podczas webinaru wielokrotnie wracało pytanie, jak wykazać tę przydatność w przypadku AI. Prelegentki odwoływały się m.in. do podejścia opartego na ryzyku opisanego w GAMP 5 oraz wytycznych dotyczących sztucznej inteligencji. Wśród przywołanych materiałów znalazł się opublikowany w 2025 roku ISPE GAMP Guide: Artificial Intelligence, poświęcony systemom wykorzystującym AI w obszarach GxP. Punktem odniesienia był również dokument refleksyjny Europejskiej Agencji Leków dotyczący AI w cyklu życia produktu leczniczego. Praktyczne pytania dotyczyły danych i kryteriów oceny. Czy przykłady testowe odpowiadają rzeczywistym dokumentom i produktom? Czy zbiór testowy był niezależny od danych używanych do dostrajania rozwiązania? Jakie wyniki uznamy za akceptowalne i czy ustaliliśmy te kryteria przed rozpoczęciem testów? W przedstawionym podejściu uwzględniono również ograniczanie odpowiedzi bez oparcia w źródłach, ocenę stabilności zachowania, monitorowanie działania, odporność na nieprawidłowe dane wejściowe i wykrywanie stronniczości. Testy przed uruchomieniem łączyły się z kontrolą podczas użytkowania oraz oceną skutków zmian modelu. Pomocą są zestawy referencyjnych przypadków testowych przygotowane z ekspertami dziedzinowymi, określane podczas prezentacji jako golden sets. Powrót do tych samych przypadków przy kolejnych wersjach rozwiązania pozwala sprawdzić, czy zmiana nie pogorszyła wyników w ważnych dla organizacji zadaniach. Praktyczne możliwości wsparcia testów i dokumentacji jakościowej opisujemy w naszym porównaniu narzędzi AI dla QA w farmacji. 3. Nadzór człowieka obejmuje więcej niż zatwierdzenie odpowiedzi Naomi Ofili rozróżniła dwa poziomy udziału człowieka. Pierwszy to human-in-the-loop, czyli etap procesu, na którym ekspert zatwierdza, poprawia lub odrzuca wynik AI. Drugi to nadzór nad całym cyklem życia rozwiązania: monitorowanie, przeciwdziałanie bezkrytycznemu przyjmowaniu wyników automatyzacji oraz możliwość zatrzymania systemu. W opisanym przebiegu pracy wynik AI przechodził automatyczne kontrole, a następnie ocenę wskazanego eksperta. Zachowywano przy tym informacje o źródłach, instrukcjach przekazanych modelowi, jego wersji i zatwierdzeniu. Taki zapis pozwalał później odtworzyć, w jakich warunkach powstał wynik i kto zaakceptował jego wykorzystanie. Ekspert uczestniczył również w ustalaniu kryteriów akceptacji i tworzeniu przypadków testowych. Jego wiedza wpływała więc na projekt rozwiązania oraz sposób oceny jakości. Dla firmy planującej wdrożenie oznacza to potrzebę określenia odpowiedzialności i zapewnienia czasu na udział ekspertów już na początku projektu. 4. Co pokazały przykłady monitorowania literatury, tłumaczeń i migracji danych? Prelegentki zilustrowały omawiane zasady trzema przykładami z projektów zespołu PLG. Każdy z nich pokazywał inne wymagania dotyczące oceny wyników AI i ich dalszego wykorzystania. 4.1. Monitorowanie literatury w nadzorze nad bezpieczeństwem leków W pierwszym przykładzie AI wspierała przegląd publikacji naukowych na potrzeby farmakowigilancji. System proponował kategorię artykułu i uzasadnienie, które weryfikował ekspert. Gabrièle Piaton podkreśliła, że szczególnie wymagającym etapem było przełożenie sposobu oceny stosowanego przez specjalistów na uporządkowane drzewo decyzji. Ten przykład pokazał, jak istotne jest opisanie wiedzy eksperckiej i kryteriów klasyfikacji przed automatyzacją zadania. 4.2. Tłumaczenie dokumentacji regulowanej Drugi przykład dotyczył tłumaczeń z wykorzystaniem AI, weryfikowanych przez człowieka według kryteriów jakości dostosowanych do ryzyka związanego z dokumentem. Uwzględniono również odtwarzanie formatowania, aby ułatwić dalszą pracę tłumaczy. Ocena rozwiązania obejmowała więc jakość treści, sposób jej sprawdzania i przydatność dokumentu w dalszym obiegu. 4.3. Migracja danych i klasyfikacja dokumentów W trzecim przykładzie AI wspierała przypisywanie dokumentów do kategorii, wydobywanie metadanych i dopasowywanie danych do struktury systemu docelowego. Prelegentki wskazały na trudność rozróżniania podobnych klas dokumentów oraz konsekwencje błędnego przypisania. Podkreśliły potrzebę prześledzenia pochodzenia danych, wykonanych przekształceń i zatwierdzeń, a także weryfikacji ilościowej i jakościowej przed rozpoczęciem użytkowania danych po migracji. 5. Hosting i koszty warto uwzględnić przed pilotażem Osobną część webinaru poświęcono architekturze rozwiązania. Prelegentki proponowały, aby przed pilotażem ustalić, gdzie będą przetwarzane dane, jakie informacje trafią do rejestrów zdarzeń i czy można kontrolować wersję modelu. Wśród kryteriów wyboru środowiska wymieniły poufność, miejsce przetwarzania danych, zasady aktualizacji, możliwość odtworzenia działania systemu oraz koszt zmiany dostawcy. Poruszono również dobór modeli do poszczególnych zadań. Mniejsze, wyspecjalizowane modele mogą pomagać ograniczać koszty, jeśli spełniają ustalone wymagania jakościowe. Proponowana ocena ekonomiczna koncentrowała się na koszcie wykonania zadania i uzyskania oczekiwanego wyniku. Wskazano też możliwość ponownego wykorzystania komponentów odpowiedzialnych za wyszukiwanie informacji, testowanie, monitorowanie i zatwierdzanie wyników. Podział odpowiedzialności między firmę farmaceutyczną a dostawcę oraz kontrolę aktualizacji szerzej omawiamy w artykule o walidacji SaaS w farmacji i wymaganiach GxP. 6. Co pomaga przejść od pilotażu AI do codziennej pracy? W końcowej części spotkania prelegentki wskazały na współpracę zespołów technicznych, ekspertów dziedzinowych i klienta przy wspólnie uzgodnionej liście zadań. Istotne było również wskazanie właściciela biznesowego odpowiedzialnego za wykorzystanie rozwiązania i mierzenie jego efektów. Z przedstawionych doświadczeń wynikała kolejność działań: określenie zastosowania i odpowiedzialności, ocena ryzyka, zaprojektowanie kontroli, budowa i walidacja, a następnie utrzymanie rozwiązania. Decyzje dotyczące jakości danych, nadzoru człowieka i zarządzania zmianami wpływają na każdy z tych etapów. Dla firm przygotowujących wdrożenie oznacza to kilka ustaleń, które warto poczynić przed pilotażem: jakie zadanie ma wykonywać AI, kto będzie zatwierdzał wyniki, jak sprawdzimy ich jakość i co zrobimy, gdy zmieni się model lub źródło danych. Odpowiedzi pomagają zaplanować zarówno prace techniczne, jak i wymagania walidacyjne oraz późniejsze utrzymanie. 7. Jak TTMS wspiera wdrożenia w środowisku farmaceutycznym? Przełożenie tych ustaleń na wymagania, testy i dokumentację wymaga współpracy osób rozumiejących proces biznesowy, technologię oraz jakość. W TTMS łączymy rozwój i utrzymanie oprogramowania dla farmacji z kompetencjami TTMS Quality w zakresie walidacji systemów skomputeryzowanych. Nasze usługi walidacyjne obejmują przygotowanie planu walidacji, specyfikację i przegląd wymagań, opracowanie oraz realizację testów, a także ocenę wyników i raportowanie. Wykorzystujemy podejście oparte na ryzyku i przewodnik GAMP 5. Zakres prac dobieramy do przeznaczenia systemu i wymagań konkretnego procesu. Jeśli planujesz wykorzystanie AI w procesie farmaceutycznym lub przygotowujesz się do rozwinięcia pilotażu, porozmawiaj z naszymi specjalistami o wymaganiach, ryzyku i zakresie walidacji Twojego rozwiązania. Czy można rozpocząć pilotaż AI w farmacji na danych syntetycznych? Tak, dane syntetyczne mogą pomóc sprawdzić wstępną koncepcję bez wykorzystywania rzeczywistych danych pacjentów lub poufnej dokumentacji. Powinny jednak odzwierciedlać strukturę, różnorodność i trudności charakterystyczne dla planowanego zastosowania. Zbyt proste przykłady mogą dać mylący obraz jakości rozwiązania. Warto uwzględnić brakujące informacje, błędy i przypadki niejednoznaczne. Wyniki takiego pilotażu nie wystarczą do potwierdzenia przydatności systemu w rzeczywistym procesie GxP. Dalsza ocena wymaga reprezentatywnych danych testowych, uzgodnionych kryteriów akceptacji i kontroli odpowiednich do ryzyka. Co zrobić, gdy AI i ekspert inaczej oceniają ten sam dokument? Rozbieżność powinna trafić do przeglądu zgodnie z ustaloną procedurą. Warto zachować dokument źródłowy, wynik AI, wersję rozwiązania oraz ocenę eksperta z uzasadnieniem. Przyczyną może być błąd modelu, niejednoznaczna treść albo zbyt ogólne kryteria oceny. Takie przypadki pomagają sprawdzić, czy potrzebna jest zmiana instrukcji, zasad klasyfikacji lub testów. Poprawka eksperta nie powinna automatycznie prowadzić do aktualizacji modelu używanego w procesie regulowanym. Zmianę należy ocenić, przetestować i zatwierdzić, zachowując niezależny zbiór do sprawdzania jakości. Jak przygotować pracowników do korzystania z AI w procesach farmaceutycznych? Szkolenie powinno dotyczyć konkretnego zadania, danych i zakresu odpowiedzialności użytkownika. Pracownik musi wiedzieć, jakie informacje może przekazywać systemowi, jak sprawdzać wyniki i kiedy zgłaszać wątpliwości. Pomocne są ćwiczenia z odpowiedziami błędnymi, niepełnymi lub pozornie przekonującymi. Pozwalają sprawdzić, czy użytkownik potrafi zweryfikować wynik zamiast przyjmować go bezkrytycznie. Przydatne będą również instrukcje postępowania w razie awarii lub niedostępności rozwiązania. Przygotowanie zespołu warto uzupełnić oceną umiejętności oraz aktualizować po zmianach systemu lub procedur.
Czytaj
Case study: Jak usprawniliśmy chatbota RAG dla kandydatów do egzaminu?
Jak pomóc klientom znaleźć konkretną odpowiedź w dokumentacji liczącej kilkaset stron? Firma edukacyjna, z którą współpracujemy, planowała udostępnić klientom chatbota odpowiadającego na pytania o procedury egzaminacyjne. Zanim narzędzie trafiło do szerszego grona odbiorców, potrzebna była poprawa jakości odpowiedzi. Zespół TTMS usprawnił sposób korzystania z dokumentów, zwiększając dokładność odpowiedzi z około 70% do około 98% w wewnętrznym teście. Opracowanie przygotowaliśmy na podstawie prezentacji wewnętrznej oraz informacji o projekcie przekazanych przez Jakuba Kraśniewskiego, Senior AI Developera w TTMS. O kliencie: firma edukacyjna obsługująca kandydatów do egzaminu Nasz klient działa w sektorze edukacyjnym i obsługuje osoby przygotowujące się do egzaminu certyfikacyjnego. Kandydaci potrzebują informacji na różnych etapach: od zapisów, przez przebieg egzaminu, po odbiór wyników i ewentualne odwołanie od oceny. Firma udostępniała te informacje w dokumentach PDF liczących łącznie kilkaset stron, głównie w języku angielskim. Znalezienie właściwej odpowiedzi wymagało więc od klientów samodzielnego przeszukiwania obszernych materiałów. Chatbot miał ułatwić im załatwianie spraw związanych z egzaminem i odciążyć dział wsparcia. Wyzwanie: poprawić odpowiedzi przed udostępnieniem chatbota klientom Kandydat miał móc opisać swoją sprawę własnymi słowami i otrzymać zrozumiałą wskazówkę w ciągu około 4–5 sekund. Liczyła się też kompletność odpowiedzi. Jeśli dana procedura obowiązywała tylko pod określonymi warunkami, chatbot powinien je uwzględnić. Zadaniem TTMS było usprawnienie wyszukiwania informacji w istniejącym rozwiązaniu, zbudowanym z wykorzystaniem CrewAI, narzędzi do tworzenia systemów opartych na agentach AI. Chatbot korzystał z RAG (Retrieval-Augmented Generation), czyli przygotowywał odpowiedzi na podstawie wyszukanych fragmentów dokumentacji klienta. Analiza wykazała, że do modelu trafiały zbyt obszerne fragmenty tekstu, co utrudniało dopasowanie ich do pytania. Dodatkowym problemem był odczyt wielokolumnowych PDF-ów: treści z sąsiadujących kolumn mieszały się ze sobą. Usprawnienie chatbota wymagało więc przyjrzenia się temu, jakie informacje otrzymuje model i czy zachowują one sens dokumentu źródłowego. Rozwiązanie i realizacja: odpowiedź wraz z potrzebnym kontekstem Zmieniliśmy sposób podziału dokumentacji, zachowując powiązania między zdaniami, akapitami i stronami. Gdy system odnajdywał zdanie pasujące do pytania, mógł pobrać również otaczający je akapit lub całą stronę. Model otrzymywał dzięki temu informacje potrzebne do wyjaśnienia zasady wraz z warunkami jej stosowania. Takie podejście pozwoliło wykorzystać istniejące materiały klienta i pozostać przy klasycznym RAG. Według informacji przekazanych przez Jakuba koszt dodatkowego przechowywania i przetwarzania treści był akceptowalny przy tej wielkości dokumentacji. Efekty sprawdziliśmy na wewnętrznym zestawie pytań obejmujących cały zakres materiałów. Uwzględniliśmy także rzeczywiste pytania użytkowników, zebrane anonimowo podczas wcześniejszego uruchomienia prototypu. Pozwoliło to ocenić odpowiedzi również wtedy, gdy pytanie było sformułowane tak, jak zadałby je klient. Szczegóły zastosowanej metody opisujemy w artykule „RAG dla chatbota na przykładzie CrewAI – notatki z TTMS Tech Talk”. Rezultaty: około 98% dokładności odpowiedzi w wewnętrznym teście Według danych przekazanych przez Jakuba Kraśniewskiego dokładność odpowiedzi wzrosła z około 70% do około 98%, czyli o około 28 punktów procentowych. Rozwiązanie zachowało również krótki czas odpowiedzi. Wynik dotyczy wewnętrznego zestawu testowego przygotowanego na potrzeby projektu. Potwierdził poprawę jakości odpowiedzi i pozwolił przygotować narzędzie do kolejnego etapu: udostępnienia części klientów. Na tym etapie nie oceniano jeszcze rzeczywistego odciążenia działu wsparcia. Co dalej? Sprawdzenie chatbota w codziennej obsłudze kandydatów Po zakończeniu testów wewnętrznych firma planowała udostępnić chatbota części klientów. Pozwoli to sprawdzić, czy kandydaci otrzymują wystarczającą pomoc w swoich sprawach i rzadziej potrzebują kontaktu z konsultantem. Do oceny posłużą dane o korzystaniu z narzędzia oraz zgłoszeniach do działu wsparcia. Porozmawiajmy o chatbocie dla Twojej firmy Chcesz ułatwić klientom lub pracownikom korzystanie z firmowej dokumentacji? A może masz już chatbota, którego odpowiedzi wymagają poprawy? Porozmawiaj z zespołem TTMS. Przyjrzymy się Twoim materiałom i potrzebom użytkowników, aby zaproponować rozwiązanie dopasowane do Twojej firmy. Od czego zacząć projekt chatbota do obsługi klienta? Na początek warto przejrzeć zgłoszenia do działu wsparcia i sprawdzić, które pytania regularnie się powtarzają. Dobrymi kandydatami do pierwszego etapu są sprawy, dla których firma ma jednoznaczne, udokumentowane odpowiedzi. Następnie trzeba określić, komu chatbot ma pomagać i co użytkownik powinien móc załatwić dzięki rozmowie. Na tej podstawie łatwiej wybrać zakres pilotażu oraz ustalić sposób oceny jego wyników. Już wtedy warto zaangażować osoby zajmujące się obsługą klienta, ponieważ znają typowe nieporozumienia i sytuacje wymagające indywidualnej decyzji. Tak przygotowany zakres daje zespołowi wdrożeniowemu konkretny punkt wyjścia. Czy można poprawić istniejącego chatbota bez budowania go od nowa? W wielu przypadkach można usprawnić poszczególne elementy istniejącego rozwiązania, choć zakres zmian wymaga wcześniejszej analizy. Zespół powinien sprawdzić przykłady błędnych odpowiedzi i ustalić, na którym etapie pojawia się problem. Przyczyną może być sposób przygotowania dokumentacji, wyszukiwania informacji lub wykorzystania znalezionych treści przez model. Znaczenie mają również ograniczenia obecnej platformy i dostęp do jej konfiguracji. Przed podjęciem decyzji o przebudowie warto porównać efekty wybranych zmian na tym samym zestawie pytań. Pozwala to ocenić, czy dalszy rozwój obecnego narzędzia ma uzasadnienie. Od czego zależy koszt wdrożenia chatbota korzystającego z dokumentacji? Koszt zależy między innymi od stanu materiałów źródłowych, zakresu integracji i wymagań dotyczących działania narzędzia. Dokumenty o złożonym układzie lub niespójnej treści mogą wymagać więcej pracy przygotowawczej. Osobnym zadaniem jest połączenie chatbota z systemami firmy, zwłaszcza gdy ma udostępniać informacje zależne od uprawnień użytkownika. Budżet powinien obejmować również testy, obsługę po uruchomieniu i aktualizowanie bazy wiedzy. Na koszty bieżące wpływają liczba rozmów, wybrane modele oraz sposób przetwarzania pytań. Dlatego przy wycenie warto oddzielić koszt przygotowania rozwiązania od przewidywanych wydatków na jego utrzymanie. Jak przygotować pilotaż chatbota dla klientów? Pilotaż powinien obejmować jasno określony zakres spraw i grupę użytkowników, których pytania pomogą ocenić przydatność narzędzia. Przed uruchomieniem warto ustalić warunki rozszerzenia dostępu, takie jak oczekiwana jakość odpowiedzi, akceptowalny czas oczekiwania i sposób postępowania z błędami. Użytkownik musi mieć możliwość zgłoszenia problemu oraz przejścia do kontaktu z obsługą. W trakcie pilotażu zespół powinien analizować rozmowy zgodnie z przyjętymi zasadami ochrony danych i zbierać opinie klientów. Ważne jest sprawdzenie, czy odpowiedzi pomagają załatwić sprawę, także wtedy, gdy pytanie jest nieprecyzyjne. Wyniki pozwalają zdecydować, co poprawić przed udostępnieniem chatbota większej grupie. Jak ocenić, czy chatbot rzeczywiście odciąża dział obsługi klienta? Punktem odniesienia są dane sprzed uruchomienia chatbota: liczba zgłoszeń w wybranych sprawach, czas ich obsługi i częstotliwość ponownych kontaktów. Po wdrożeniu trzeba porównać te same wskaźniki, uwzględniając sezonowość oraz zmiany liczby klientów. Sam brak kontaktu z konsultantem po rozmowie z chatbotem nie potwierdza rozwiązania problemu, dlatego warto zbierać również opinie użytkowników. Może się zdarzyć, że do wsparcia trafia mniej prostych pytań, a większą część pracy stanowią sprawy złożone. Wtedy średni czas obsługi pojedynczego zgłoszenia może wzrosnąć mimo spadku łącznego obciążenia zespołu. Dopiero zestawienie tych informacji pozwala rzetelnie ocenić efekt biznesowy.
Czytaj
GPT-6.1 Sol dla firm: większe możliwości, niższe koszty
29 września 2026 roku podczas konferencji DevDay OpenAI zaprezentowało GPT-6.1 Sol, zaledwie tydzień po premierze GPT-6 Sol. Firma chciała zbliżyć Sol do możliwości GPT-6 Astra w programowaniu, analizie dokumentów i obsłudze aplikacji, utrzymując dotychczasowe podstawowe stawki za korzystanie z modelu. OpenAI utrzymało ceny GPT-6 Sol. Stawki wynoszą 2 USD za milion tokenów wejściowych i 10 USD za milion wyjściowych, czyli jedną piątą standardowych stawek Astry. Samą aktualizację OpenAI wiąże z rozwojem agentów AI, czyli programów wykonujących zadania w kolejnych krokach przy użyciu dostępnych narzędzi. Analiza dokumentacji, przygotowanie zmiany w kodzie i sprawdzenie jej działania mogą wymagać wielu kolejnych zapytań do modelu. Przy takiej pracy koszt narasta wraz z liczbą operacji. GPT-6.1 Sol ma pozwolić twórcom aplikacji wykonywać bardziej wymagające zadania w ramach tego samego budżetu. 1. Czym jest GPT-6.1 Sol i co zmienia względem GPT-6 Sol? GPT-6.1 Sol to rozwinięcie GPT-6 Sol, przeznaczone do złożonych zadań związanych z kodem, dokumentami i obsługą aplikacji. Dokumentacja OpenAI wskazuje również obsługę narzędzi, w tym wyszukiwania i wykonywania kodu. Model można wykorzystać w agencie AI połączonym z firmowymi źródłami danych i narzędziami. Agent mógłby odczytać zapytanie klienta, znaleźć właściwą specyfikację, porównać wymagania i przygotować propozycję odpowiedzi. Firma musi określić, z jakich danych agent może korzystać, jakie czynności może wykonywać samodzielnie i które wymagają zatwierdzenia przez pracownika. Podstawowe stawki za tokeny wejściowe i wyjściowe są takie same jak w GPT-6 Sol. Spada natomiast stawka za ponowne wykorzystanie danych z pamięci podręcznej: z 0,20 do 0,10 USD za milion tokenów. Firma korzystająca z GPT-6 Sol powinna przetestować obie wersje na tych samych zadaniach i porównać jakość wyników, liczbę ponownych prób oraz zużycie tokenów. 2. Co wyniki testów mówią o zastosowaniach biznesowych? OpenAI publikuje wyniki testów obejmujących analizę dokumentów i wykonywanie wieloetapowych zadań. Porównując wyniki, trzeba sprawdzić ustawiony poziom rozumowania. Wyższy poziom pozwala modelowi poświęcić więcej obliczeń na analizę zadania, co może zwiększać zużycie tokenów. Test Badany obszar Wynik podany przez OpenAI GDP.pdf Odpowiadanie na pytania na podstawie złożonych dokumentów PDF. Wyniki zbliżone do wyników Astry przy około pięciokrotnie niższym koszcie zadania. AutomationBench 1.0.6 Wieloetapowe zadania w aplikacjach biznesowych. Przewaga 4,8 punktu procentowego nad GPT-6 Sol przy średnim poziomie rozumowania. OSWorld 2.0 Obsługa aplikacji na komputerze. Wynik niższy od wyniku Astry o 2,1 punktu procentowego. Koszt zadania wynosi około jednej siódmej kosztu Astry. Oba modele testowano przy maksymalnym poziomie rozumowania. Każdy z przywołanych testów sprawdza inne umiejętności modelu, dlatego ich wyniki warto rozpatrywać osobno. GDP.pdf, opracowany przez Surge AI, sprawdza, czy model potrafi analizować dokumenty wykorzystywane w pracy i odpowiadać na pytania dotyczące ich treści. Model musi poprawnie odczytać także tabele, schematy i przypisy oraz powiązać informacje z różnych części dokumentu. Wynik pokazuje więc, jak radzi sobie z materiałami podobnymi do tych, które analizują działy zakupów czy zespoły techniczne. AutomationBench firmy Zapier ocenia wykonywanie zadań w symulowanych aplikacjach. Sprawdza, czy model rzeczywiście wprowadził wymagane zmiany, na przykład zaktualizował właściwy rekord i wykonał wszystkie polecone czynności. Dla firmy to istotne: deklaracja modelu, że zadanie zostało wykonane, powinna mieć potwierdzenie w danych zapisanych w systemie. OSWorld sprawdza obsługę komputera, w tym wykonywanie czynności w interfejsach aplikacji. Przywołany przez OpenAI wynik uwzględnia punkty za częściowe wykonanie zadania. Wysoka punktacja może zatem oznaczać, że model poprawnie wykonał większość kroków, ale pominął ostatni, na przykład zatwierdzenie formularza. Przy ocenie przydatności modelu do automatyzacji trzeba więc sprawdzić również, jak często kończy on całe zadanie. Wyniki tych testów pomagają wybrać zastosowania do firmowego pilotażu. Dopiero próby na własnych dokumentach i w używanych aplikacjach pokażą, czy model spełnia wymagania firmy oraz ile czasu zajmuje sprawdzanie i poprawianie jego pracy. 3. Ile kosztuje GPT-6.1 Sol i jak czytać cennik? W API, czyli interfejsie pozwalającym aplikacji korzystać z modelu, rozliczenie obejmuje tokeny – jednostki przetwarzanego tekstu, często odpowiadające fragmentom słów. Dane wejściowe to między innymi polecenia i dostarczone materiały. Do płatnych tokenów wyjściowych zaliczają się również tokeny używane do rozumowania, niewidoczne w treści odpowiedzi. Stawki w USD za milion tokenów w trybie Standard, dla zapytań zawierających do 272 tys. tokenów wejściowych: Model Wejście Odczyt z pamięci podręcznej Zapis do pamięci podręcznej Wyjście GPT-6 Sol 2,00 0,20 2,50 10,00 GPT-6.1 Sol 2,00 0,10 2,50 10,00 GPT-6 Astra 10,00 1,00 12,50 50,00 Porównanie dotyczy standardowego przetwarzania. Tryby przyspieszone i zapytania z większą ilością danych mają odrębne stawki, a przetwarzanie w wybranym regionie może wiązać się z dopłatą. Pamięć podręczna może obniżyć koszt kolejnych zapytań korzystających z tych samych instrukcji lub dokumentów. Oszczędności zależą od tego, ile danych można ponownie wykorzystać. Łączny koszt zadania obejmuje zużycie tokenów, opłaty za pamięć podręczną i używane narzędzia. 4. Przykład: ile można zaoszczędzić przy tysiącu zadań miesięcznie? Policzmy to na przykładzie: firma wykonuje miesięcznie 1000 zadań, a każde zużywa 20 tys. tokenów wejściowych i 3 tys. rozliczanych tokenów wyjściowych, łącznie z rozumowaniem. Zakładamy identyczne zużycie w obu modelach. Dla przejrzystości rachunku pomijamy odczyty i zapisy pamięci podręcznej, opłaty za narzędzia oraz dopłaty. W rzeczywistym wdrożeniu zużycie tokenów trzeba zmierzyć. Składnik kosztu miesięcznego GPT-6.1 Sol GPT-6 Astra 20 mln tokenów wejściowych 40 USD 200 USD 3 mln tokenów wyjściowych 30 USD 150 USD Łączny koszt tokenów 70 USD 350 USD Oszczędność na tokenach wynosi 280 USD miesięcznie. Teraz przyjmijmy dodatkowe założenie: godzina pracy osoby sprawdzającej wyniki kosztuje firmę 30 USD. Gdyby weryfikacja rezultatów Sol zajmowała średnio o minutę więcej na każde zadanie, miesięczny koszt pracy wzrósłby o 500 USD. W tym przykładzie korzystanie z Sol kosztowałoby firmę łącznie o 220 USD miesięcznie więcej niż korzystanie z Astry. Jeśli sprawdzanie wyników Sol zajmie tyle samo czasu co kontrola wyników Astry lub mniej, niższe wydatki na tokeny mogą obniżyć łączny koszt wykonania zadania. W pilotażu należy porównać jakość wyników, wydatki na model i czas poświęcony na kontrolę. Aby obliczyć koszt poprawnie wykonanego zadania, należy podzielić łączne koszty procesu przez liczbę zadań ukończonych zgodnie z przyjętymi wymaganiami. Do rachunku należy włączyć również nieudane próby, poprawki, obsługę wyjątków i utrzymanie rozwiązania. Koszty przygotowania danych i połączenia systemów należy rozłożyć na planowany okres korzystania z rozwiązania. 5. Które zastosowania GPT-6.1 Sol warto sprawdzić w firmie? Pilotaż może objąć porównywanie dokumentów i ofert, przygotowanie danych do obsługi klienta oraz opracowanie poprawek w kodzie. 5.1 Porównywanie dokumentów technicznych i ofert Dział zakupów otrzymuje oferty zawierające specyfikacje, tabele parametrów i warunki serwisu. Zadaniem systemu może być przygotowanie porównania według ustalonego zestawu wymagań. Przy każdej wartości powinien podać dokument i miejsce, z którego ją odczytał, oraz oznaczyć brakujące informacje. W zestawie testowym warto uwzględnić dwie wersje tej samej specyfikacji, parametry podane w różnych jednostkach oraz zastrzeżenie zapisane w przypisie. Osoba oceniająca sprawdzi, czy system wybrał aktualną wersję i prawidłowo odczytał zastrzeżenia. Łączny czas przygotowania i sprawdzenia zestawienia warto porównać z czasem wykonania tego zadania bez AI. 5.2 Przygotowanie danych do obsługi klienta w kilku systemach Po otrzymaniu zapytania handlowego agent mógłby odnaleźć historię współpracy, sprawdzić status wcześniejszych zgłoszeń i przygotować wpis w CRM, czyli systemie zarządzania relacjami z klientami. Warunkiem jest zapewnienie odpowiednich połączeń z aplikacjami oraz dostępu do potrzebnych danych. Pierwszy etap wdrożenia może kończyć się przedstawieniem pracownikowi propozycji zmian. Po zatwierdzeniu system zapisuje je i sprawdza rezultat. W testach warto uwzględnić dane różnych klientów o podobnych nazwach, aby sprawdzić, czy agent wybiera właściwego. Należy też ponownie zlecić mu to samo zadanie i sprawdzić, czy rozpoznaje wcześniejszy zapis oraz unika tworzenia duplikatu. 5.3 Diagnozowanie błędów i przygotowywanie zmian w oprogramowaniu Zespół IT może porównać modele przy analizie zgłoszeń, odtwarzaniu błędów i przygotowywaniu poprawek wraz z testami. Do testów warto wybrać rozwiązane już zgłoszenia, dla których znane są przyczyna błędu i wymagany sposób działania programu. Ocena powinna uwzględniać poprawność zmiany, wyniki testów oraz czas przeglądu przez programistę. Dodatkowo warto sprawdzić, czy model ograniczył modyfikacje do potrzebnego zakresu. Zbyt wiele zmian w kodzie może wydłużyć jego sprawdzanie i utrudnić ustalenie, które z nich usuwają zgłoszony błąd. 6. Jak porównać GPT-6.1 Sol z Astrą we własnym procesie? OpenAI zaleca w wytycznych doboru modeli porównanie Sol i Astry na tym samym zadaniu. W porównaniu trzeba uwzględnić jakość wyników, czas wykonania i koszt zadania w warunkach zbliżonych do planowanego zastosowania. Wybierz zadanie z jednoznacznym kryterium ukończenia. Może nim być porównanie wszystkich wymaganych parametrów oferty albo przygotowanie zmiany w kodzie, która przechodzi określone testy. Zbuduj zestaw przykładów z codziennej pracy. Uwzględnij typowe sprawy, niepełne dane i znane wyjątki. Oddziel materiały używane do dopracowania instrukcji od tych, na których ocenisz gotową konfigurację. Zapewnij porównywalne warunki. Modele powinny otrzymać te same materiały, narzędzia i uprawnienia. Zapisuj ustawienia rozumowania oraz limity. Następnie można dostosować ustawienia każdego modelu do tych samych wymagań jakościowych. Policz pełny koszt i sprawdź rezultat. Mierz poprawność, liczbę ponownych prób, czas pracy systemu i czas kontroli przez człowieka. Rejestruj także sprawy wymagające ręcznego dokończenia. Rozszerzaj zastosowanie po spełnieniu ustalonych warunków. Określ, które wyniki mogą być wykorzystywane od razu, które wymagają zatwierdzenia i kiedy sprawa powinna trafić do specjalisty. OpenAI zaleca testowanie systemów AI na zadaniach odpowiadających codziennej pracy i ocenianie wyników przez osoby znające daną dziedzinę. Testy warto powtarzać po zmianie modelu, instrukcji lub źródeł danych. Można też przetestować podział pracy między modele. Sol obsługiwałby sprawy, w których osiągnął wymagany poziom jakości, a Astra wybrane trudniejsze przypadki. Trzeba z góry określić, kiedy zadanie trafia do Astry, na przykład gdy Sol błędnie interpretuje dokumenty lub przygotowuje niepoprawną odpowiedź. Jeśli brakuje wymaganych danych, należy je uzupełnić przed ponowną analizą. Koszt ponownej analizy trzeba włączyć do rachunku. Ostateczny podział będzie zależał od rezultatów testów. 7. Porozmawiajmy o automatyzacji w Twojej firmie W TTMS pomagamy dobierać rozwiązania AI do konkretnych procesów i integrować je z firmowymi systemami. Jeśli rozważasz wykorzystanie GPT-6.1 Sol, skontaktuj się z nami. Wspólnie ustalimy, które zadania warto objąć pilotażem oraz jak ocenić jakość wyników i pełny koszt ich wykonania. Czy GPT-6.1 Sol można połączyć z firmową bazą wiedzy? Tak, aplikacja może udostępniać modelowi informacje wyszukane w zatwierdzonych materiałach firmy. Służą do tego między innymi mechanizmy wyszukiwania opisane w dokumentacji OpenAI. Podejście, w którym system najpierw pobiera odpowiednie fragmenty źródeł, a następnie wykorzystuje je do przygotowania odpowiedzi, określa się jako RAG — generowanie odpowiedzi wspomagane wyszukiwaniem. Przy jego wdrożeniu trzeba zadbać o aktualizację dokumentów, rozpoznawanie wersji i respektowanie uprawnień użytkowników. Dla osoby korzystającej z systemu przydatne będzie wskazanie źródła pozwalającego sprawdzić odpowiedź. Skuteczność należy oceniać również na pytaniach, dla których baza nie zawiera wystarczających informacji. Czy przejście z GPT-6 Sol na GPT-6.1 Sol wymaga zmian w aplikacji? Zakres zmian zależy od sposobu integracji. Zespół powinien sprawdzić dostępne interfejsy, ustawienia rozumowania, obsługę narzędzi i formaty odpowiedzi. Przykładowo karta GPT-6.1 Sol wskazuje, że korzystanie z narzędzi wymaga Responses API, a ustawienie rozumowania none nie jest obsługiwane. To może mieć znaczenie dla aplikacji przygotowanych pod poprzednią wersję. Po dostosowaniu konfiguracji potrzebne są próby na zapisanym zestawie zadań, obejmujące także obsługę błędów. Warto zachować możliwość powrotu do poprzedniej konfiguracji, jeżeli nowa nie spełni wymagań. OpenAI API Czy GPT-6.1 Sol sprawdzi się w pracy z dokumentami po polsku? Ocenę warto oprzeć na polskich materiałach używanych w danej organizacji. Przytoczone wyniki testów nie rozstrzygają, jak model poradzi sobie z konkretną dokumentacją branżową po polsku. W zestawie próbnym powinny znaleźć się skróty, odmienne formy nazw, odwołania do załączników oraz charakterystyczne dla firmy określenia. Osobnego sprawdzenia wymagają liczby z przecinkiem dziesiętnym, jednostki, daty i wartości odczytywane z tabel. Jeżeli odpowiedzi trafiają do klientów, należy ocenić także naturalność języka i spójność terminologii. Wyniki takich prób pozwolą ustalić, w jakich zadaniach rozwiązanie spełnia wymagania firmy.
Czytaj
GPT-6 Cyber: co model OpenAI do cyberbezpieczeństwa oznacza dla biznesu
Firma OpenAI wprowadziła GPT-6 Cyber, model AI przeznaczony do zadań związanych z cyberbezpieczeństwem. Firmom zarządzającym portalami dla klientów, usługami płatniczymi i platformami wewnętrznymi może on zapewnić szybsze badanie podatności, częstsze przeglądy bezpieczeństwa oraz lepsze wsparcie inżynierów przygotowujących i testujących poprawki. O jego praktycznej wartości zdecydują jakość wyników oraz czas, który pozwoli zaoszczędzić specjalistom. Czym jest GPT-6 Cyber? GPT-6 Cyber jest przedstawiany jako wyspecjalizowany model OpenAI do zadań związanych z cyberbezpieczeństwem. Przed jego wprowadzeniem serwis BusinessToday informował, że wybrani klienci testowali wersję alfa w ramach programu Daybreak Red. Według Investing.com, które powołuje się na magazyn „Fortune”, OpenAI opracowuje również osobny produkt, który ma pomóc klientom bezpiecznie wdrażać GPT-6 Cyber, automatyzować zadania związane z bezpieczeństwem i usuwać podatności. Produkt ten zapewniłby OpenAI większy nadzór nad sposobem wykorzystywania modeli firmy. Dla firm oznacza to praktyczne pytania o miejsce tej usługi w istniejących procesach bezpieczeństwa: jakie zadania mogłaby wykonywać, które działania wymagałyby zatwierdzenia oraz jakie informacje o jej wykorzystaniu otrzymywałoby OpenAI. Szczegóły te wpłynęłyby zarówno na koszty wdrożenia, jak i na ocenę, czy usługa może być wykorzystywana w pracy z wrażliwymi systemami firmowymi.OpenAI rozwijało narzędzia do cyberbezpieczeństwa jeszcze przed wprowadzeniem GPT-6 Cyber. Jego poprzednik, GPT-5.6 Cyber, został udostępniony uprawnionym użytkownikom prowadzącym zaawansowane badania podatności i testy bezpieczeństwa. Firma oferuje również Codex Security – agenta bezpieczeństwa aplikacji, który pomaga zespołom badać podatności i przygotowywać poprawki. Rozwiązania te pokazują dotychczasowy kierunek rozwoju oferty OpenAI w tym obszarze. Możliwości i skuteczność nowego GPT-6 Cyber wymagają jednak osobnej oceny. Firma rozważająca zakup powinna osobno przeanalizować trzy elementy rozwiązania AI do cyberbezpieczeństwa: Element rozwiązania Co określa Co powinna sprawdzić firma Model Możliwości analizy i wnioskowania dostępne podczas wykonywania zadania Skuteczność w przypadkach odpowiadających potrzebom firmy, ograniczenia i koszty Program dostępu Kto może korzystać z określonych możliwości i na jakich warunkach Kryteria dostępu, wymagane zgody i dozwolone działania Aplikacja i integracje Dane, które system może analizować, oraz działania, które może wykonywać Obsługiwane narzędzia, uprawnienia, mechanizmy kontroli i zatwierdzania oraz rejestry audytowe Przed zakupem dostępu należy sprawdzić, w jaki sposób rozwiązanie będzie łączyć się z firmowymi repozytoriami kodu, narzędziami monitorującymi oraz procesem zatwierdzania zmian. Dlaczego AI w cyberbezpieczeństwie ma znaczenie dla kadry zarządzającej? Zadania związane z bezpieczeństwem wymagają zaangażowania tych samych inżynierów, którzy utrzymują aplikacje i rozwijają nowe funkcje. Analiza podejrzanej zmiany w kodzie, sprawdzenie komunikatu dostawcy o zagrożeniu i weryfikacja poprawki pochłaniają czas całego zespołu. AI pozwala przenieść część prac badawczych i przygotowawczych do powtarzalnego procesu. Dzięki temu specjaliści mogą poświęcić więcej czasu na weryfikację wyników oraz podejmowanie decyzji dotyczących systemów produkcyjnych. Sprawniejsze wykonywanie zadań związanych z bezpieczeństwem może również pomóc firmom zachować ciągłość działania usług. Firma handlowa może potrzebować zabezpieczyć integrację z systemem płatności bez zakłócania sprzedaży. Producent może chcieć poznać konsekwencje aktualizacji oprogramowania powiązanego z procesami operacyjnymi. Firma świadcząca usługi finansowe może potrzebować jednoznacznych dowodów pokazujących, co sprawdzono i w jaki sposób rozwiązano problem. W każdym z tych przypadków automatyzacja musi uwzględniać procesy biznesowe związane z danym oprogramowaniem. Skala inwestycji OpenAI pokazuje, jak duże znaczenie firma przypisuje rozwojowi AI w cyberbezpieczeństwie. 3 września 2026 roku firma OpenAI ogłosiła zobowiązanie w wysokości miliarda dolarów, obejmujące dostęp do programu Daybreak na preferencyjnych warunkach, szkolenia, wsparcie techniczne i współpracę z organizacjami chroniącymi usługi kluczowe. Cztery biznesowe zastosowania GPT-6 Cyber, które warto ocenić Poniższe scenariusze przedstawiają naszą analizę obszarów, w których model wyspecjalizowany w cyberbezpieczeństwie mógłby przynieść firmom wymierne korzyści. Są to potencjalne zastosowania, których przydatność w przypadku GPT-6 Cyber należy potwierdzić w testach. Każdy z nich zależy od możliwości, narzędzi i uprawnień dostępnych w docelowym środowisku. 1. Badanie podatności w aplikacjach biznesowych Dobry pilotaż może objąć niewielki zestaw aplikacji, z których każda ma jasno określonego właściciela biznesowego. Model otrzymałby dostęp do kodu, którego analizę wcześniej zatwierdzono, oraz do informacji o architekturze, a następnie zostałby oceniony pod kątem tego, czy pomaga przeanalizować potencjalne podatności i wskazać dowody potrzebne do ich potwierdzenia. Zespół mógłby na przykład sprawdzić, czy portal klienta konsekwentnie egzekwuje uprawnienia dostępu we wszystkich powiązanych usługach. Korzyść dla firmy polegałaby na skróceniu czasu potrzebnego do potwierdzenia lub wykluczenia podatności. Przydatny wynik powinien wskazywać komponenty, których dotyczy problem, wyjaśniać warunki jego występowania oraz ułatwiać inżynierowi odtworzenie go w wyznaczonym do tego środowisku testowym 2. Przygotowywanie i testowanie poprawek bezpieczeństwa AI mogłaby pomóc w opracowaniu poprawki, wskazaniu powiązanych fragmentów kodu oraz zaproponowaniu testów dotyczących zarówno bezpieczeństwa, jak i prawidłowego działania aplikacji. Istniejąca dokumentacja Codex Security opisuje już procesy przeglądania zmian, potwierdzania ustaleń i przygotowywania poprawek. Jest to więc konkretny obszar, w którym można oceniać możliwości kolejnych modeli. Z biznesowego punktu widzenia sukces oznacza mniejszy nakład pracy inżynierów potrzebny do przygotowania każdej zweryfikowanej poprawki przy zachowaniu jakości kolejnej wersji oprogramowania. Przed wprowadzeniem zmiany w środowisku produkcyjnym inżynierowie nadal powinni ją przejrzeć i przeprowadzić odpowiednie testy. 3. Ustalanie priorytetów z uwzględnieniem kontekstu biznesowego Aktualne informacje o systemach i ich właścicielach oraz związana z nimi dokumentacja mogą pomóc AI łączyć ustalenia techniczne z konsekwencjami biznesowymi. Dzięki temu zespół mógłby łatwiej zdecydować, które podatności należy usunąć w pierwszej kolejności i kto powinien się nimi zająć. 4. Wsparcie zespołów podczas analizy incydentów bezpieczeństwa Kolejnym zastosowaniem wartym przetestowania jest tworzenie osi czasu incydentu na podstawie alertów bezpieczeństwa i logów systemowych, z uwzględnieniem wewnętrznych procedur prowadzenia analizy. W ramach testu można sprawdzić, czy model łączy swoje stwierdzenia z dowodami, odróżnia obserwacje od hipotez i wskazuje brakujące informacje. Scenariusz ten wymagałby odpowiednich integracji, dlatego nie należy zakładać, że stanowią one wbudowaną funkcję GPT-6 Cyber. Przydatny wynik mógłby ułatwić kolejnemu analitykowi kontynuowanie dochodzenia albo pomóc właścicielowi usługi zrozumieć, którego procesu biznesowego dotyczy problem. W przypadku decyzji takich jak wyłączenie kont, blokowanie ruchu lub izolowanie systemów trzeba jednoznacznie określić, kto może je podejmować, ponieważ mogą zakłócić prawidłowe działanie usług. Jak mogłoby to wyglądać w portalu klienta? Rozważmy przykład firmy przygotowującej nową wersję portalu klienta połączonego z systemem zarządzania zamówieniami. Podczas przeglądu bezpieczeństwa wykryto możliwą słabość w sposobie sprawdzania uprawnień dostępu do szczegółów zamówień. W ramach kontrolowanego pilotażu system AI otrzymałby odpowiedni kod, opis oczekiwanych uprawnień oraz konta testowe zawierające fikcyjne dane klientów. Zespół oceniłby, czy system pomaga prześledzić fragmenty kodu związane z problemem, przygotować zrozumiałe wyjaśnienie i zaproponować test potwierdzający występowanie podatności. Jeżeli podatność zostałaby potwierdzona, inżynierowie mogliby ocenić zaproponowaną poprawkę oraz dodatkowe testy regresji, które sprawdzają, czy po wprowadzeniu zmiany dotychczasowe funkcje nadal działają prawidłowo. Efektem powinny być sprawdzona zmiana i dokumentacja pokazująca, na czym polegał problem, co zmodyfikowano, które testy zakończyły się powodzeniem i kto zatwierdził wdrożenie. Wymagałoby to dostępu do odpowiedniego kodu, środowiska testowego oraz procesu przydzielania potwierdzonych problemów inżynierom odpowiedzialnym za ich usunięcie. Jak mierzyć wartość biznesową GPT-6 Cyber? W ramach pilotażu należy porównać proces wspierany przez AI z dotychczasowym sposobem pracy zespołu, wykorzystując porównywalne przypadki. Warto uwzględnić potwierdzone podatności, zgłoszenia uznane wcześniej za fałszywe alarmy oraz przypadki, w których dostępne dowody są niepełne. Należy rejestrować zarówno czas pracy analityka, jak i czas działania modelu. Do szybko wygenerowanej odpowiedzi należy doliczyć czas potrzebny na jej weryfikację. Praktyczną podstawę do podjęcia decyzji mogą zapewnić następujące wskaźniki: Wskaźnik Co należy rejestrować Dlaczego ma znaczenie Czas oceny podejrzewanej podatności Łączny czas i nakład pracy analityka potrzebne do potwierdzenia lub odrzucenia zgłoszenia Pokazuje, czy proces przyspiesza analizę Jakość wyników analizy Potwierdzone podatności, fałszywe alarmy i niewykryte problemy w referencyjnym zestawie testowym Pokazuje, czy pozornemu wzrostowi produktywności nie towarzyszy większa liczba błędów Czas przygotowania przetestowanej i zatwierdzonej poprawki Czas od potwierdzenia problemu do przetestowania i zatwierdzenia poprawki Pokazuje wpływ wsparcia AI na proces usuwania podatności Nakład pracy inżynierów Liczba godzin poświęconych na sprawdzanie, poprawianie, testowanie i dokumentowanie wyników Pokazuje koszty związane z nadzorem Całkowity koszt obsługi jednego przypadku Koszt użycia modelu, narzędzi, środowisk testowych, integracji i czasu pracowników Umożliwia realistyczną ocenę opłacalności rozszerzenia wdrożenia Jeżeli pilotaż skróci czas pracy analityków, ale przysporzy dodatkowych zadań programistom, w ocenie należy uwzględnić oba efekty. Jeżeli pozwoli wykryć więcej rzeczywistych podatności, organizacja będzie również potrzebowała zasobów, aby je usunąć. Dostęp, ceny i sposób wdrożenia – co powinna sprawdzić firma? Zgodnie z obecną dokumentacją programu Daybreak organizacja musi uzyskać odpowiednią zgodę i dostęp do projektu. Dokumentacja rozróżnia również dostęp do programu od dostępu do konkretnego modelu. W przypadku GPT-6 Cyber organizacje powinny bezpośrednio sprawdzić obowiązujące wymagania, w tym ustalić, czy dostęp ogranicza się do testów, czy obejmuje również planowane zastosowanie produkcyjne. Ocena warunków komercyjnych powinna obejmować ceny, limity wykorzystania, obsługiwane integracje oraz sposób przetwarzania danych firmowych. Zespoły powinny ustalić, jaki kod źródłowy, logi i informacje konfiguracyjne będą przetwarzane, gdzie będzie się to odbywać, jak długo dane będą przechowywane oraz jakie zabezpieczenia i warunki określa umowa. Dostępność za pośrednictwem określonego dostawcy chmury lub w ramach obecnej subskrypcji należy potwierdzić dla konkretnej oferty. Budżet pilotażu powinien uwzględniać koszty wdrożenia i weryfikacji, a także opłaty za korzystanie z modelu. Jak zachować kontrolę nad wykorzystaniem AI w cyberbezpieczeństwie? Firma powinna określić zakres wykorzystania AI w procesach bezpieczeństwa równie dokładnie jak zakres zewnętrznego audytu. Należy wskazać systemy, które rozwiązanie może analizować, informacje, do których może uzyskać dostęp, oraz działania, które wolno mu wykonywać. Uprawnienie do analizy problemu powinno być oddzielone od uprawnienia do wprowadzania zmian w działającej usłudze. Opublikowane przez OpenAI wytyczne dotyczące programu Daybreak zalecają korzystanie z odizolowanych środowisk, monitorowanie działań agentów oraz przestrzeganie wyznaczonego zakresu dozwolonych działań. W przypadku pierwszego pilotażu biznesowego przemawia to za wykorzystaniem kontrolowanego środowiska testowego, kont i uprawnień ograniczonych do niezbędnego zakresu, weryfikowaniem proponowanych zmian oraz prowadzeniem rejestrów pozwalających zespołowi odtworzyć przebieg działań. Należy również wyznaczyć osobę odpowiedzialną za nadzorowanie procesu. Osoba ta powinna sprawdzać nierozstrzygnięte zgłoszenia, decydować o potrzebie zebrania dodatkowych dowodów i zatrzymywać proces, jeśli system zachowuje się w nieoczekiwany sposób. Szkolenie powinno obejmować krytyczną ocenę wniosków wygenerowanych przez AI oraz rozpoznawanie sytuacji, w których system nie ma wystarczających informacji do kontynuowania pracy. Od czego powinny zacząć firmy? Najlepiej zacząć od jednej aplikacji i jednego powtarzalnego zadania związanego z bezpieczeństwem, takiego jak badanie podejrzewanych podatności lub testowanie poprawek. Należy wyznaczyć osobę odpowiedzialną za sprawdzanie wyników oraz ustalić sposób pomiaru ich trafności, zaoszczędzonego czasu i nakładu pracy inżynierów. Pilotaż o jasno określonym zakresie pomoże ustalić, czy rozwiązanie przynosi korzyści uzasadniające szersze wdrożenie. Rozważasz wykorzystanie AI w procesach bezpieczeństwa swojej firmy? Rozważasz wykorzystanie AI w procesach bezpieczeństwa swojej firmy? Skontaktuj się z TTMS i opowiedz nam o zadaniu, które chcesz usprawnić, wykorzystywanych systemach oraz wymaganiach dotyczących danych. Wspólnie możemy wybrać odpowiednie podejście i określić oczekiwane wyniki pilotażu. Czym GPT-6 Cyber różni się od modelu AI ogólnego zastosowania wykorzystywanego w cyberbezpieczeństwie? GPT-6 Cyber jest przedstawiany jako model wyspecjalizowany w cyberbezpieczeństwie, którego wczesną wersję testowano w ramach programu OpenAI Daybreak Red. Modele ogólnego zastosowania również mogą wspierać zadania związane z bezpieczeństwem, na przykład objaśniać kod, analizować dokumentację i sprawdzać dostarczone wyniki. Z perspektywy firmy najważniejsze jest to, czy model specjalistyczny zapewnia trafniejsze i bardziej użyteczne wyniki w zadaniach wykonywanych przez jej zespół. Sama nazwa modelu nie potwierdza takiej przewagi. Rzetelne porównanie powinno zapewnić obu modelom dostęp do tych samych informacji i narzędzi oraz podobny czas na wykonanie zadania. Wyniki powinni następnie ocenić specjaliści ds. bezpieczeństwa. Opublikowane testy mogą dostarczyć dodatkowych informacji, ale rezultatów osiągniętych przez inne modele nie należy przypisywać GPT-6 Cyber. Czy GPT-6 Cyber może zastąpić zespół ds. cyberbezpieczeństwa lub zewnętrznego dostawcę usług bezpieczeństwa? Firma nadal potrzebuje wykwalifikowanych osób odpowiedzialnych za ocenę ryzyka, potwierdzanie wykrytych problemów i zatwierdzanie zmian. Analiza przygotowana przez model zależy od udostępnionych mu informacji i narzędzi, dlatego może nie uwzględniać części wiedzy o systemach firmy. Specjaliści biorą również pod uwagę priorytety operacyjne, analizują niejednoznaczne dowody i koordynują działania w razie incydentu. AI może zmniejszyć nakład pracy potrzebny do wykonania określonych zadań, ale skalę tych oszczędności trzeba potwierdzić w praktyce. Firma korzystająca z usług zewnętrznego dostawcy powinna ustalić, w jaki sposób sprawdza on wyniki wygenerowane przez AI oraz czy zaoszczędzony czas przekłada się na jakość lub zakres świadczonej usługi. Odpowiedzialność za ochronę systemów i rozwiązywanie problemów musi pozostać jasno przypisana. Czy GPT-6 Cyber może być przydatny firmie, która korzysta głównie z oprogramowania zewnętrznych dostawców? Jego przydatność będzie zależała od tego, nad którymi elementami środowiska firma ma kontrolę i do jakich informacji może uzyskać dostęp. Organizacja korzystająca ze standardowych aplikacji chmurowych może mieć ograniczony wgląd w kod źródłowy dostawcy. Nadal odpowiada jednak między innymi za uprawnienia użytkowników, konfigurację, integracje i własne rozszerzenia. Są to potencjalne obszary analizy wspieranej przez AI, o ile pozwalają na to potwierdzone możliwości modelu i dostępne integracje. Przed rozpoczęciem testów należy ustalić, które systemy firma może samodzielnie analizować, a które działania wymagają udziału lub zgody dostawcy. Problemy dotyczące jego produktu powinny być zgłaszane zgodnie z obowiązującą procedurą bezpieczeństwa, aby mogły zostać zweryfikowane i usunięte. Czy brak wykrytych podatności podczas przeglądu wspieranego przez AI oznacza, że aplikacja jest bezpieczna? Nie. Przegląd może nie wykryć części podatności z powodu niepełnych informacji, ograniczonego zakresu testów lub błędów analizy. Raport, w którym nie wskazano żadnych problemów, powinien więc wyjaśniać, co sprawdzono, jakie testy wykonano i co pozostało poza zakresem badania. Analiza wybranych plików z kodem źródłowym nie potwierdza na przykład, że sprawdzono również konfigurację aplikacji w środowisku produkcyjnym i obowiązujące uprawnienia dostępu. Wynik należy oceniać razem z innymi dowodami, w tym rezultatami testów oraz opinią specjalistów dobranych odpowiednio do poziomu ryzyka aplikacji. Nierozstrzygnięte kwestie i ograniczenia analizy powinny zostać zapisane, aby raport bez wykrytych podatności nie dawał nieuzasadnionego poczucia bezpieczeństwa. Jak ocenić dostawcę oferującego usługi „oparte na GPT-6 Cyber”? Należy poprosić dostawcę o wskazanie używanego modelu, sposobu uzyskiwania do niego dostępu oraz elementów usługi, które rzeczywiście wykorzystują jego możliwości. Warto też poprosić o prezentację na przykładzie reprezentatywnego zadania, którego analizę wcześniej zatwierdzono, oraz o dowody potwierdzające przedstawione wyniki. Firma powinna ustalić, kto sprawdza rezultaty, kto wprowadza poprawki i jak wygląda postępowanie w przypadku błędnej lub niepełnej analizy. Opis usługi powinien również wyjaśniać, w jaki sposób przetwarzane są dane klienta i które działania wymagają jego zgody. Jeżeli dostawca zmieni model wykorzystywany do świadczenia usługi, powinien wykazać, że po tej zmianie nadal spełnia ona uzgodnione wymagania. Ofertę najlepiej oceniać na podstawie konkretnych rezultatów, takich jak potwierdzone podatności i przetestowane poprawki, oraz jasno przypisanej odpowiedzialności za poszczególne etapy pracy.
Czytaj
RAG dla chatbota na przykładzie CrewAI – notatki z TTMS Tech Talk
Tech Talk to wewnętrzny cykl spotkań technologicznych dla pracowników TTMS, podczas których dzielimy się wiedzą i doświadczeniami z projektów. Pokazujemy sprawdzone narzędzia, omawiamy napotkane problemy i rozwiązania, które pomogły nam w pracy. Tematy obejmują m.in. sztuczną inteligencję, analitykę danych, Salesforce, AEM i zarządzanie projektami. Po prezentacjach jest czas na pytania, dyskusję i wymianę pomysłów. Podczas spotkania „RAG dla chatbota na przykładzie CrewAI”, które odbyło się 17 września, Jakub Kraśniewski, Senior AI Developer w TTMS, opowiedział o usprawnieniu chatbota korzystającego z dokumentacji klienta. Przedstawił problemy z przygotowaniem i wyszukiwaniem informacji, zastosowane rozwiązanie oraz sposób sprawdzania jakości odpowiedzi. Projekt dotyczył firmy z sektora edukacyjnego, której klienci przygotowują się do egzaminu certyfikacyjnego. Chatbot miał pomagać im w uzyskiwaniu informacji o zapisach, przebiegu egzaminu, ocenianiu i odwołaniach, a tym samym odciążyć dział wsparcia. Korzystał z publicznie dostępnych dokumentów PDF obejmujących kilkaset stron, głównie w języku angielskim. Zespół potrzebował sposobu na trafne wyszukiwanie odpowiedzi w tych materiałach przy wymaganym czasie oczekiwania rzędu 4 do 5 sekund. 1. Jak RAG pomaga chatbotowi korzystać z wiedzy firmy? Na początku prezentacji Jakub wyjaśnił, jak działa RAG (Retrieval-Augmented Generation), czyli generowanie odpowiedzi z wykorzystaniem wyszukanych materiałów źródłowych. System odnajduje informacje związane z pytaniem użytkownika i przekazuje je modelowi językowemu jako kontekst odpowiedzi. W omawianym projekcie były to fragmenty dokumentacji opisującej zasady i procedury egzaminacyjne. Po odczytaniu tekstu z dokumentów system dzieli go na mniejsze fragmenty. Model embeddingowy (model AI przedstawiający cechy znaczeniowe tekstu w postaci liczb) przekształca je w wektory zapisywane w bazie. W ten sam sposób przetwarzane jest pytanie użytkownika. Porównanie tych reprezentacji pozwala wyszukać fragmenty powiązane znaczeniowo z pytaniem. Jakub podkreślał, że zespół odpowiada za jakość materiałów przekazywanych modelowi. Trzeba sprawdzić, czy tekst został poprawnie odczytany, czy podział zachował potrzebny kontekst i czy wyszukiwanie dostarcza informacje przydatne do odpowiedzi. Znaczenie tych etapów pokazały problemy, na które zespół natrafił w rozwiązaniu wykorzystującym CrewAI. 2. Co utrudniało wyszukiwanie informacji w projekcie z CrewAI? Po wyjaśnieniu podstaw RAG Jakub przeszedł do doświadczeń z projektu wykorzystującego CrewAI, zestaw narzędzi do budowania systemów opartych na agentach AI. Omówił trzy problemy napotkane w używanej konfiguracji: zbyt obszerne fragmenty tekstu, brak dodatkowej oceny trafności wyników oraz błędy w odczycie dokumentów PDF. 2.1 Zbyt obszerne fragmenty dokumentów W konfiguracji opisanej przez Jakuba tekst dzielono na fragmenty po 4000 znaków. Dla jednego pytania system pobierał pięć takich fragmentów, więc do modelu trafiało nawet około 20 000 znaków materiału źródłowego. Duży fragment może zawierać informacje dotyczące kilku różnych zagadnień, co utrudnia dopasowanie go do konkretnego pytania. Model generujący odpowiedź musi następnie wybrać potrzebne informacje spośród przekazanych treści. W tym projekcie sposób podziału dokumentów wymagał więc dostosowania do ich struktury i pytań użytkowników. 2.2 Brak dodatkowej oceny trafności wyników Jakub zwrócił uwagę, że w używanej konfiguracji brakowało rerankingu, czyli ponownej oceny i uporządkowania wyników wyszukiwania według ich przydatności do odpowiedzi na pytanie użytkownika. System może najpierw wyszukać większą liczbę fragmentów, a następnie poddać je dodatkowej ocenie, aby wybrać te najbardziej przydatne do przygotowania odpowiedzi. Jakub wskazał tę metodę jako możliwe usprawnienie, którego przydatność warto ocenić, sprawdzając zarówno jakość odpowiedzi, jak i czas oczekiwania na nią. 2.3 Błędna kolejność odczytu tekstu w wielokolumnowych PDF-ach Kolejny problem dotyczył odczytu dokumentów. Narzędzie pobierało tekst z wielokolumnowych PDF-ów wiersz po wierszu, łącząc treści z sąsiadujących kolumn. Zaburzało to kolejność zdań i utrudniało późniejsze wyszukiwanie informacji. Tak przetworzony tekst trafiał do dalszego podziału na fragmenty. Błąd powstawał więc już podczas przygotowania danych i wpływał na kolejne etapy pracy z dokumentacją. Ten przykład pokazał, dlaczego sprawdzanie jakości RAG warto rozpocząć od porównania odczytanego tekstu z dokumentem źródłowym. 3. Jak czas odpowiedzi wpływa na wybór między Classic RAG, Agentic RAG i Graph RAG? W projekcie istotnym wymaganiem była odpowiedź w czasie około 4 do 5 sekund. Jakub omówił trzy podejścia do RAG z perspektywy kosztu przygotowania danych, możliwości sprawdzania działania oraz czasu potrzebnego na obsługę pytania. Podejście Sposób działania omawiany na spotkaniu Co uwzględnić przy wyborze Classic RAG Wyszukiwanie fragmentów w bazie wiedzy, opcjonalny reranking i przekazanie kontekstu do modelu. Jakość podziału dokumentów, trafność wyszukiwania i objętość przekazywanego kontekstu. Agentic RAG Agent dobiera narzędzia i sposób wyszukiwania, a w razie potrzeby wykonuje kolejne zapytania. Możliwość dostosowania wyszukiwania do pytania oraz czas i koszt dodatkowych operacji. Graph RAG Wyszukiwanie wykorzystuje graf wiedzy opisujący obiekty występujące w materiałach oraz relacje między nimi. Nakład na budowę i utrzymanie grafu oraz przydatność relacji dla pytań użytkowników. W podejściu agentowym model może korzystać z kilku narzędzi, na przykład wyszukiwania wektorowego, wyszukiwania po słowach kluczowych lub filtrowania po metadanych opisujących dokument. Kolejne kroki pozwalają rozbudowywać poszukiwanie informacji, a ich liczba i kolejność wpływają na czas odpowiedzi. W przedstawionym podejściu grafowym część pracy wykonywana jest podczas budowania bazy wiedzy. Z tekstu wydobywa się obiekty i łączące je relacje. Taki mechanizm stanowi również podstawę GraphRAG opisanego przez Microsoft. Jakub zwracał uwagę na koszty tego przygotowania i trudność ręcznej analizy rozbudowanego grafu. W omawianym projekcie wymagany czas odpowiedzi przemawiał za rozwijaniem klasycznego RAG. Zespół skupił się na sposobie podziału dokumentów i doboru kontekstu. 4. Jak hierarchiczne dzielenie dokumentów pomaga zachować kontekst? Zastosowane rozwiązanie polegało na uporządkowaniu materiału na trzech powiązanych poziomach: strony, akapitu i zdania. System zachowywał informację o tym, do którego akapitu należy zdanie oraz na której stronie znajduje się akapit. Treść była reprezentowana w bazie wektorowej na różnych poziomach szczegółowości. Dzięki temu wyszukiwanie mogło odnaleźć zarówno konkretne zdanie, jak i większy fragment zawierający potrzebne informacje. Według relacji Jakuba dodatkowy koszt przechowywania i przetwarzania tych reprezentacji był akceptowalny przy skali materiałów w projekcie. Odnalezienie trafnego zdania pozwalało pobrać obejmujący je akapit i przekazać modelowi szerszy kontekst. W zależności od potrzeb można było sięgnąć również po całą stronę. Załóżmy, że użytkownik pyta o termin odwołania od wyniku egzaminu. System odnajduje zdanie określające ten termin, a następnie pobiera cały akapit, który wyjaśnia, od kiedy należy go liczyć i jak złożyć odwołanie. Dzięki temu model może uwzględnić te warunki w odpowiedzi. 5. Jak sprawdzać jakość RAG na własnych danych? W końcowej części prezentacji Jakub podkreślił znaczenie benchmarku, czyli zestawu testów pozwalającego porównywać warianty rozwiązania. Omówił sprawdzanie wyników wyszukiwania względem informacji oznaczonych przez człowieka oraz wykorzystanie modelu językowego do oceny odpowiedzi. W praktyce warto rozdzielić ocenę na dwa poziomy. Pierwszy dotyczy wyszukiwania: czy system dostarczył fragment zawierający potrzebną informację? Drugi obejmuje odpowiedź: czy model poprawnie wykorzystał otrzymany materiał? Taki podział pomaga ustalić, który etap wymaga poprawy. W dodatkowych informacjach przekazanych po spotkaniu Jakub doprecyzował sposób testowania i uzyskane wyniki. Zestaw testowy obejmował pytania z całego zakresu dokumentacji oraz rzeczywiste pytania użytkowników, zebrane anonimowo podczas uruchomienia prototypu na początku roku. Dokładność odpowiedzi wzrosła z około 70% do około 98%, czyli o około 28 punktów procentowych. Wynik dotyczy wewnętrznego testu przeprowadzonego w tym projekcie. Według relacji Jakuba rozwiązanie zachowało również szybki czas odpowiedzi. W chwili przekazania tych informacji chatbot miał za sobą testy wewnętrzne, a firma planowała udostępnić go części klientów. Odciążenie działu wsparcia i ułatwienie dostępu do informacji pozostawały celami wdrożenia. Ocena ich realizacji wymaga danych z użytkowania narzędzia. Osobnym obszarem oceny pozostaje model embeddingowy. Jakub wskazywał, że jego dobór powinien uwzględniać język materiałów i wyniki uzyskiwane na własnym zbiorze danych. Wybór tego modelu wpływa na to, jakie fragmenty system odnajdzie, zanim rozpocznie generowanie odpowiedzi. 6. Co z tych doświadczeń wynika dla firm wdrażających chatbota? Omówiony projekt pokazuje, jak konkretne wymagania porządkują pracę nad RAG. Oczekiwany czas odpowiedzi pomógł zawęzić wybór rozwiązania, analiza dokumentów ujawniła problemy z odczytem i podziałem treści, a wewnętrzny test pozwolił ocenić efekt zmian. Przy planowaniu podobnego wdrożenia warto uporządkować pięć kwestii: Materiały źródłowe: sprawdzić, czy odczyt dokumentów zachowuje sens i kolejność tekstu. Podział treści: dopasować wielkość fragmentów i powiązania między nimi do struktury materiałów. Pytania użytkowników: przygotować zestaw odzwierciedlający zadania, które chatbot ma obsługiwać. Czas odpowiedzi: ustalić oczekiwania i uwzględniać je podczas porównywania wariantów. Ocena jakości: sprawdzać zarówno trafność wyszukanych informacji, jak i sposób wykorzystania ich w odpowiedzi. Porozmawiajmy o AI w Twojej firmie W TTMS pracują eksperci, którzy tak jak Jakub łączą wiedzę technologiczną z doświadczeniem w projektach dla klientów. Podczas Tech Talków dzielą się rozwiązaniami sprawdzonymi w praktyce, a zdobytą wiedzę wykorzystują w kolejnych wdrożeniach. Planujesz chatbota korzystającego z firmowej dokumentacji lub chcesz poprawić jakość odpowiedzi istniejącego narzędzia? Zapraszamy do rozmowy. Przyjrzymy się Twoim materiałom, potrzebom użytkowników i celom biznesowym, aby zaproponować odpowiedni sposób wykorzystania AI. Skontaktuj się z zespołem TTMS! Jakie dokumenty mogą tworzyć bazę wiedzy chatbota z RAG? Chatbot z RAG może korzystać z firmowych polityk, instrukcji obsługi produktów, procedur, odpowiedzi na najczęściej zadawane pytania i innych materiałów zawierających informacje przydatne użytkownikom. W zależności od dostępnych integracji źródłami mogą być pliki PDF, dokumenty Word, treści stron internetowych i artykuły z bazy wiedzy. Zeskanowane dokumenty wymagają optycznego rozpoznawania znaków (OCR), które przekształca obraz tekstu w treść możliwą do przeszukiwania. Tabele, diagramy i złożone układy stron mogą wymagać dodatkowego przetwarzania, aby zachować ich znaczenie. Przed dodaniem dokumentów należy sprawdzić, czy są poprawne, aktualne i zatwierdzone do udostępnienia danej grupie odbiorców. Przejrzysta struktura materiałów pomaga systemowi wyszukiwać informacje i dostarczać kontekst potrzebny do odpowiedzi. Jak aktualizować bazę wiedzy chatbota z RAG? Utrzymanie aktualnej bazy wiedzy chatbota z RAG wymaga procesu wykrywania i przetwarzania zmian w materiałach źródłowych. W zależności od potrzeb firmy aktualizacje mogą odbywać się według harmonogramu lub po dodaniu, zmianie albo usunięciu dokumentu. System aktualizuje wówczas przeszukiwane treści oraz powiązane z nimi reprezentacje, takie jak embeddingi, czyli liczbowe reprezentacje cech znaczeniowych tekstu. Informacje o wersji i datach obowiązywania pomagają odróżnić aktualne wytyczne od starszych materiałów. Dokumenty usunięte lub zastąpione nowszymi wersjami należy również wycofać z aktywnych wyników wyszukiwania, a odpowiedzi zapisane w pamięci podręcznej mogą wymagać odświeżenia. Wyznaczenie osoby odpowiedzialnej za każdy obszar treści pomaga zadbać o jakość informacji wykorzystywanych przez chatbota. Czy chatbot z RAG może podawać źródła swoich odpowiedzi? Tak, chatbot z RAG może dołączać do odpowiedzi linki, tytuły dokumentów, numery stron lub cytowane fragmenty. Wymaga to zachowania informacji o źródłach podczas przetwarzania dokumentów i powiązania wyszukanych fragmentów z odpowiedzią. Przydatne odwołania pozwalają użytkownikowi otworzyć właściwy materiał i samodzielnie sprawdzić kontekst. System powinien również weryfikować, czy każde wskazane źródło potwierdza informację, do której się odnosi. Sam link do źródła nie gwarantuje, że odpowiedź poprawnie odzwierciedla treść dokumentu. Podczas testów należy sprawdzać zarówno jakość odpowiedzi, jak i poprawność odwołań, w tym możliwość otwarcia wskazanych materiałów przez użytkownika. Jak chatbot z RAG może uwzględniać uprawnienia dostępu do dokumentów firmowych? Chatbot z RAG może wykorzystywać tożsamość i uprawnienia zalogowanego użytkownika, aby określić, które dokumenty wolno mu przeszukiwać. Weryfikacja uprawnień powinna nastąpić, zanim treści objęte ograniczeniami dostępu trafią do modelu językowego. Te same zasady muszą obejmować podgląd dokumentów, odwołania do źródeł i odpowiedzi zapisane w pamięci podręcznej, jeśli zawierają chronione informacje. Zmiany uprawnień w systemie źródłowym powinny być również uwzględniane podczas wyszukiwania informacji przez chatbota. Zespół powinien przetestować rozwiązanie na kontach o różnych rolach, w tym z ograniczonym dostępem. Takie testy pomagają potwierdzić, że każda osoba otrzymuje odpowiedzi oparte na informacjach, do których ma uprawnienia. Co powinien zrobić chatbot z RAG, gdy nie znajdzie odpowiedzi? Gdy dostępne dokumenty zawierają zbyt mało informacji, chatbot z RAG powinien jasno poinformować, że na podstawie swoich źródeł nie może udzielić wiarygodnej odpowiedzi. Jeśli pytanie jest niejednoznaczne, może poprosić o doprecyzowanie lub wskazać powiązany dokument, który może pomóc użytkownikowi. W sprawach wymagających dalszej pomocy może skierować go do odpowiedniego zespołu lub kanału wsparcia. System potrzebuje jasno określonych zasad postępowania z informacjami niepełnymi, sprzecznymi lub brakującymi. Testy powinny obejmować pytania, na które baza wiedzy nie zawiera odpowiedzi, aby zespół mógł ocenić zachowanie chatbota w takich sytuacjach. Analiza pytań pozostawionych bez odpowiedzi może również ujawnić luki w dokumentacji firmy i pomóc ustalić priorytety kolejnych aktualizacji.
Czytaj
ChatGPT dla usług finansowych: co daje połączenie GPT z profesjonalnymi źródłami danych?
10 września 2026 r. OpenAI ogłosiło ChatGPT for Financial Services, rozwiązanie łączące GPT-6 Astra z profesjonalnymi źródłami danych finansowych i narzędziami do przygotowywania analiz. Produkt powstał we współpracy z Morgan Stanley i Evercore. Jest skierowany do instytucji finansowych, a na początek ma wspierać pracę w bankowości inwestycyjnej i analizie akcji. Zespoły analityczne mogą dzięki niemu wyszukiwać dane, wykonywać obliczenia i przygotowywać materiały dla klientów w jednym miejscu. To szansa na skrócenie czasu poświęcanego na zbieranie informacji i przenoszenie ich między narzędziami. Z tego artykułu dowiesz się: jakie dane i funkcje oferuje ChatGPT for Financial Services, jak może wyglądać przygotowanie analizy spółki z pomocą GPT, dlaczego trzeba sprawdzać sposób obliczania wskaźników i źródła danych, na których etapach potrzebna jest kontrola analityka, jak ocenić, czy wdrożenie opłaca się firmie. Jak ChatGPT for Financial Services wspiera pracę analityka? W materiałach OpenAI oraz dostawców danych opisano kilka konkretnych zastosowań: Porównywanie spółek. Daloopa (dostawca danych finansowych o spółkach) udostępnia wybrane dane i wskaźniki, które mogą posłużyć do zestawienia wyników przedsiębiorstw. Odwołania do źródeł pomagają sprawdzić pochodzenie liczb. Wyszukiwanie firm spełniających określone kryteria. Daloopa opisuje też wyszukiwanie spółek według rodzaju działalności lub obszaru geograficznego. Takie zestawienie może być punktem wyjścia do dalszej analizy rynku. Przygotowywanie materiałów dla klientów. OpenAI opisuje tworzenie modeli wyceny, not analitycznych i prezentacji z wykorzystaniem firmowych szablonów do programów Excel, Word i PowerPoint. W ChatGPT for Financial Services można korzystać z wybranych danych udostępnianych przez Daloopa, PitchBook, LSEG News i Crunchbase. OpenAI pracuje również nad integracjami, dzięki którym instytucje będą mogły korzystać z danych dostępnych w ramach już wykupionych abonamentów. Prace obejmują m.in. S&P Capital IQ, LSEG, MSCI, Dow Jones Factiva i Moody’s. Od danych do analizy spółki: pięć etapów pracy Prześledźmy przygotowanie porównania dwóch przedsiębiorstw przemysłowych przed spotkaniem z klientem. Analityk ma ocenić rentowność, wyjaśnić istotne różnice i przygotować krótką notę z tabelą wyników. Na fikcyjnych danych pokażemy, co warto sprawdzić podczas pilotażu: od doboru informacji po zatwierdzenie gotowego materiału. 1. Ustalenie pytania i zakresu porównania Najpierw ustalamy, jaki okres chcemy porównać: ostatni pełny rok, półrocze czy ostatnie dwanaście miesięcy. Sprawdzamy też, czy liczby dotyczą całej grupy kapitałowej, czy pojedynczej spółki, w jakiej walucie je podano i jak obliczono poszczególne wskaźniki. W naszym przykładzie korzystamy ze skonsolidowanych danych obu grup kapitałowych za ten sam rok kalendarzowy. Kwoty podajemy w milionach złotych. Przed porównaniem wyników trzeba sprawdzić daty rozpoczęcia i zakończenia okresów raportowania. Jedna firma może kończyć rok obrotowy w grudniu, a druga w marcu. Na takie różnice zwraca uwagę również dokumentacja bazy EDGAR prowadzonej przez amerykańską SEC. Analityk musi wtedy zdecydować, jak uwzględnić przesunięcie i czy potrzebuje dodatkowych danych. Przyjęte zasady warto zapisać w instrukcji dla AI i dołączyć do gotowej analizy. Dzięki temu model otrzyma jasne wytyczne, a osoba sprawdzająca wynik będzie wiedziała, jakie dane porównano i dlaczego. 2. Zebranie danych i wskazanie ich źródeł Przy każdej ważnej liczbie warto zapisać, jakiej spółki i okresu dotyczy, w jakich jednostkach ją podano oraz jak została obliczona. Do tego potrzebny jest odnośnik do konkretnej tabeli lub objaśnienia w raporcie. Zachowanie dokumentu źródłowego i daty jego pobrania ułatwi późniejsze sprawdzenie lub aktualizację analizy. Według opisu OpenAI ChatGPT for Financial Services pozwala dotrzeć do konkretnych tabel i fragmentów dokumentów, wyróżniając informacje wykorzystane w analizie. W naszym przykładzie porównujemy EBITDA, czyli wynik przed odsetkami, podatkiem dochodowym i amortyzacją. Osoba sprawdzająca analizę powinna móc przejść od podanej wartości do raportu spółki i sprawdzić sposób jej obliczenia. Dzięki temu sprawdzi również, czy wynik dotyczy właściwego okresu i części działalności. 3. Uzgodnienie definicji przed porównaniem marż Spółki mogą publikować skorygowaną EBITDA, przy której obliczaniu wyłączają wybrane koszty. Takie korekty zwiększają wartość wskaźnika. Dlatego przed porównaniem ich rentowności trzeba sprawdzić, jakie korekty zastosowano. Na różnice w sposobie obliczania wskaźników przez poszczególne firmy zwraca uwagę również amerykańska SEC. Przyjrzyjmy się dwóm fikcyjnym spółkom. Przyjmujemy, że obie spółki obliczają EBITDA przed korektami według tych samych zasad. Spółka A dodaje następnie do tego wyniku 20 mln zł kosztów, które wyłącza przy obliczaniu skorygowanej EBITDA. W rezultacie wskaźnik rośnie ze 120 do 140 mln zł. W spółce B takie koszty nie występują, więc wynik pozostaje bez zmian. Przykład ilustracyjny. Dane skonsolidowane za ten sam rok kalendarzowy. Kwoty podano w mln zł. Pozycja Spółka A Spółka B Przychody 1 000 800 EBITDA przed korektą 120 104 Koszty wyłączone przy obliczaniu skorygowanej EBITDA 20 0 Skorygowana EBITDA 140 104 Marża EBITDA przed korektą 12% 13% Marża skorygowanej EBITDA 14% 13% Po korekcie marża spółki A wynosi 14% i przewyższa marżę spółki B, która wynosi 13%. Przed korektą to spółka B ma wyższą marżę: 13% wobec 12%. W tym przykładzie sposób uwzględnienia kosztów decyduje o tym, która spółka ma wyższą marżę EBITDA. Analityk powinien więc sprawdzić, jakie koszty składają się na korektę w wysokości 20 mln zł i czy występowały również w poprzednich latach. Na tej podstawie ocenia, czy wyłączenie tych kosztów jest uzasadnione w przygotowywanej analizie. Może też pokazać oba warianty i wyjaśnić klientowi, skąd bierze się różnica. AI może pomóc zebrać dane i przeliczyć marże, a ekspert ocenia zasadność korekty i jej wpływ na wnioski. 4. Sprawdzenie obliczeń w arkuszu W naszym przykładzie wystarczy podzielić EBITDA przez przychody: 120 ÷ 1 000 daje marżę 12%, a 140 ÷ 1 000 daje 14%. Bardziej złożone analizy mogą wymagać przeliczenia walut, dopasowania okresów raportowania czy przygotowania kilku wariantów prognozy. Osoba sprawdzająca wynik powinna móc prześledzić każdy z tych kroków. Dlatego warto poprosić AI o arkusz, w którym dane źródłowe, założenia i formuły są wyraźnie rozdzielone. Analityk może wtedy sprawdzić rachunki i zobaczyć, jak zmiana jednej wartości wpływa na wynik. Aby sprawdzić działanie arkusza, można testowo zmniejszyć korektę z 20 do 10 mln zł. Skorygowana EBITDA spółki A powinna wtedy wynieść 130 mln zł, a odpowiadająca jej marża 13%. Po takiej zmianie trzeba również sprawdzić tabelę porównawczą i opis wyników. Obie spółki miałyby już taką samą marżę, więc wniosek o wyższej marży spółki A wymagałby aktualizacji. To prosty sposób, by ocenić, czy obliczenia i towarzyszący im tekst pozostają ze sobą zgodne. 5. Przygotowanie materiału dla klienta i sprawdzenie wniosków Gotową analizę można opracować w formacie używanym przez firmę. Według opisu OpenAI administrator może udostępnić zespołowi szablony do programów Excel, Word i PowerPoint, z których narzędzie korzysta przy tworzeniu dokumentów i prezentacji. W naszym przykładzie klient powinien otrzymać tabelę wyników oraz krótkie wyjaśnienie, jak korekta kosztów wpływa na porównanie marż. Ekspert sprawdzający materiał ocenia, czy wnioski zgadzają się z obliczeniami i odpowiadają na pytanie klienta. Jeśli coś wymaga doprecyzowania, może poprosić o dodatkowe wyjaśnienie lub kolejny wariant analizy. Pomiar czasu pracy powinien obejmować również sprawdzenie materiału i wprowadzenie poprawek przed jego zatwierdzeniem. Jak chronić dane i zachować historię pracy nad analizą? Przygotowując analizę dla klienta, zespół może korzystać z publicznych raportów, płatnych baz i poufnych dokumentów. Trzeba ustalić, kto ma dostęp do tych informacji, gdzie będą przechowywane i komu można przekazać gotowy materiał. Według dokumentacji bezpieczeństwa ChatGPT Work dane biznesowe są szyfrowane i domyślnie nie służą do trenowania modeli. Czas ich przechowywania, miejsce przetwarzania oraz zakres zapisywanej historii działań zależą od ustawień i podłączonych usług. Przed wdrożeniem trzeba sprawdzić, które działania użytkowników i narzędzi są zapisywane w rejestrach oraz które z tych zapisów można wyeksportować. Podczas pilotażu warto zachować dokumenty źródłowe, kolejne wersje arkusza oraz gotowy materiał z informacją, kto i kiedy go zatwierdził. Następnie trzeba sprawdzić, czy zgromadzona dokumentacja pozwala odtworzyć obliczenia i prześledzić zatwierdzenie analizy. Osobno trzeba zweryfikować, czy rejestry systemowe pozwalają prześledzić działania użytkowników i narzędzi w zakresie wymaganym przez firmę. Jak ocenić, czy wdrożenie się opłaca? Na początek warto wybrać zadanie, które zespół wykonuje regularnie, np. aktualizację porównania spółek po publikacji wyników kwartalnych. Przed testem trzeba zmierzyć czas wykonania takiej analizy dotychczasową metodą i ustalić wymagania dotyczące jej jakości. Te wyniki posłużą do porównania pracy z wykorzystaniem AI. Do czasu przygotowania analizy trzeba doliczyć czas potrzebny na jej sprawdzenie i wprowadzenie poprawek. OpenAI zwraca na to uwagę w materiale o ocenie korzyści z AI, zalecając również uwzględnienie kosztów wdrożenia i późniejszego korzystania z narzędzia. W praktyce warto porównać: Miernik Czego się dowiemy? Czas od rozpoczęcia zadania do zatwierdzenia analizy Czy klient szybciej otrzymuje gotowy materiał? Uwzględniamy też oczekiwanie między etapami. Łączny czas pracy analityka i osoby sprawdzającej Czy zespół poświęca mniej godzin na przygotowanie, kontrolę i poprawki? Liczba błędów wpływających na wynik lub wnioski Czy jakość analizy spełnia te same wymagania co przy dotychczasowym sposobie pracy? Poprawność i kompletność odwołań do źródeł Czy można sprawdzić pochodzenie najważniejszych liczb i informacji? Czas aktualizacji analizy Jak sprawnie można uwzględnić nowe dane i poprawić zależne od nich obliczenia oraz wnioski? Koszt jednej zatwierdzonej analizy Ile kosztuje gotowy materiał po uwzględnieniu pracy zespołu, narzędzia, danych oraz przypadającej na analizę części kosztów wdrożenia i utrzymania? Test powinien objąć kilka zadań o różnym poziomie trudności. Zasady oceny ustalamy przed jego rozpoczęciem. Osoba wykonująca tę samą analizę po raz drugi zna już dane i część odpowiedzi, co może skrócić czas pracy. Dlatego warto wykorzystać porównywalne zadania i zmieniać kolejność pracy z AI oraz dotychczasową metodą. Jeśli AI pozwoli zaoszczędzić czas, warto sprawdzić, jak zespół go wykorzystał. Być może przygotował więcej analiz, szybciej odpowiedział klientom lub ograniczył nadgodziny. W ocenie wdrożenia warto osobno pokazać, jak wykorzystano zaoszczędzony czas oraz czy i o ile zmniejszyły się wydatki firmy. Kiedy warto rozpocząć pilotaż? Pilotaż warto rozważyć, jeśli zespół regularnie zbiera dane z wielu źródeł i aktualizuje podobne analizy. Do testu można wybrać zadanie, które zajmuje analitykom dużo czasu, np. porównywanie danych z raportów spółek. Trzeba też wskazać osobę odpowiedzialną za pilotaż oraz ekspertów, którzy sprawdzą wyniki. Jeśli zespół sporadycznie analizuje kilka raportów rocznych, warto sprawdzić, czy wystarczą narzędzia już dopuszczone do użytku w firmie. Tam, gdzie pobieranie danych i obliczenia są zautomatyzowane, trzeba wskazać konkretne zadanie, które nowe narzędzie mogłoby usprawnić. OpenAI udostępnia produkt instytucjom finansowym spełniającym warunki dostępu i kieruje zainteresowane firmy do działu sprzedaży. Cenę, szczegółowe warunki oraz możliwość korzystania z usługi przez daną instytucję w Polsce trzeba potwierdzić u dostawcy. Informacje o dostępności. Decyzję o wdrożeniu warto oprzeć na wynikach pilotażu: jakości analiz, czasie ich przygotowania i sprawdzenia oraz całkowitym koszcie pracy. Test pokaże też, czy narzędzie zapewnia dostęp do danych potrzebnych zespołowi. Chcesz sprawdzić, gdzie AI może usprawnić pracę analityków w Twojej organizacji? Porozmawiaj z zespołem TTMS o wyborze zadania do pilotażu, połączeniu potrzebnych źródeł danych i sposobie oceny wyników. Czym ChatGPT for Financial Services różni się od analizowania raportów w ChatGPT? ChatGPT for Financial Services zapewnia dostęp do wybranych profesjonalnych danych finansowych bezpośrednio w narzędziu. Umożliwia też odwoływanie się do konkretnych tabel i fragmentów dokumentów oraz przygotowywanie materiałów według firmowych szablonów. Przy ocenie przydatności dla zespołu warto sprawdzić, czy dostępne źródła obejmują potrzebne spółki, okresy i wskaźniki. Czy ChatGPT for Financial Services wymaga osobnych abonamentów na dane finansowe? Możliwość przygotowania takiej analizy zależy od dostępności danych konkretnych spółek. Warto sprawdzić, czy narzędzie udostępnia ich sprawozdania, potrzebne wskaźniki i dane historyczne. Sam komunikat premierowy nie potwierdza pełnego pokrycia GPW. Przydatność rozwiązania najlepiej ocenić na kilku spółkach, które zespół regularnie analizuje. Co zrobić, gdy dane z ChatGPT różnią się od wartości w raporcie spółki? Najpierw trzeba porównać źródła, okresy raportowania, jednostki i definicje wskaźników. Różnica może wynikać np. z wykorzystania danych jednostkowych zamiast skonsolidowanych albo z uwzględnienia korekt EBITDA. Warto również sprawdzić, czy spółka opublikowała zaktualizowany raport. Analityk powinien wyjaśnić rozbieżność i zapisać, którą wartość przyjął oraz z jakiego powodu. Jak uzyskać dostęp do ChatGPT for Financial Services i sprawdzić jego cenę? OpenAI kieruje zainteresowane instytucje finansowe do działu sprzedaży lub opiekuna klienta. W rozmowie należy potwierdzić warunki dostępu, cenę, zakres danych oraz dostępność usługi dla danej instytucji w Polsce. Komunikat premierowy nie zawiera publicznego cennika.
Czytaj