Home • Blog • RAG dla chatbota na przykładzie CrewAI – notatki z TTMS Tech Talk

RAG dla chatbota na przykładzie CrewAI – notatki z TTMS Tech Talk

Marcin Kapuściński

24 września 2026

Spis treści

    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.

    RAG AI

    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.

    RAG AI business

    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.

    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.

    Polecane wpisy

    10 najczęstszych problemów w małych firmach. Zobacz, jak skutecznie możesz je rozwiązać
    Akademia Salesforce, czyli jak się załapać do orkiestry
    AEM Tech Talk w TTMS Poznań
    5 mitów reportingu okiem architekta Business Intelligence

    TTMS blog – świat IT oczami ekspertów

    RAG dla chatbota na przykładzie CrewAI – notatki z TTMS Tech Talk

    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 więcej
    Wdrożyłeś Moodle. Jak zaimportować pierwsze materiały szkoleniowe?

    Wdrożyłeś Moodle. Jak zaimportować pierwsze materiały szkoleniowe?

    Zainstalowana i skonfigurowana platforma Moodle to dopiero połowa drogi do uruchomienia szkoleń w firmie. Kolejnym krokiem jest przeniesienie do niej realnej zawartości: kursów z poprzedniego systemu, gotowych pakietów SCORM albo listy pracowników, którzy mają z platformy korzystać. W tym artykule pokazujemy, jak wygląda ten proces krok po kroku – i co zrobić, jeśli materiałów szkoleniowych jeszcze w ogóle nie macie. 1. Zanim zaczniesz: sprawdź jaki jest Twój punkt wyjścia importu do Moodle Sposób importu zależy od tego, co dokładnie chcesz przenieść do Moodle. W praktyce firmy trafiają w jedną z trzech sytuacji: Macie już gotowy kurs w formacie SCORM – wyprodukowany wcześniej, kupiony u zewnętrznego dostawcy albo wyeksportowany z innego systemu LMS. W takim wypadku wystarczy go zaimportować jako aktywność w kursie. Macie pełną kopię zapasową kursu z innej instancji Moodle (plik .mbz) – np. z environmentu testowego, z poprzedniego wdrożenia albo od firmy, która wcześniej obsługiwała waszą platformę. Wtedy importujecie cały kurs razem ze strukturą. Nie macie jeszcze żadnego z powyższych – macie za to prezentacje, procedury PDF, nagrania onboardingowe albo po prostu wiedzę w głowach pracowników, którą trzeba dopiero zamienić w kurs. To najczęstsza sytuacja zaraz po wdrożeniu i wymaga innego podejścia, o którym piszemy w ostatniej sekcji. Poniższe instrukcje dotyczą dwóch pierwszych przypadków. Nazwy opcji i ich umiejscowienie mogą się nieznacznie różnić w zależności od wersji Moodle, jednak główne etapy procesu pozostają podobne. Dla pewności warto również zapoznać się z aktualną oficjalną dokumentacją Moodle. Linki do odpowiednich materiałów znajdziesz w dalszej części artykułu. 2. Import całego kursu z pliku kopii zapasowej (.mbz) Jeśli dysponujecie plikiem .mbz – czyli pełnym backupem kursu wraz ze strukturą sekcji, aktywnościami i (opcjonalnie) plikami – proces wygląda następująco: Zaloguj się do Moodle z uprawnieniami nauczyciela lub managera i wejdź do kursu, do którego chcesz wgrać zawartość (może to być nowo utworzony, pusty kurs). Z menu kursu wybierz Więcej → Wykorzystanie kursu (Course reuse) → Przywróć (Restore). Wskaż plik .mbz – możesz go wgrać z dysku lub wskazać plik już umieszczony w obszarze plików kursu. Moodle przeprowadzi Cię przez kilka ekranów: potwierdzenie pliku, ustawienia przywracania (czy scalić zawartość z istniejącym kursem, czy nadpisać go w całości) oraz wybór, które elementy mają zostać przywrócone. Na etapie przeglądu zobaczysz pełną listę tego, co zostanie zaimportowane. To ostatni moment, żeby cofnąć się i coś poprawić. Po zatwierdzeniu proces przywracania działa w tle – w zależności od wielkości kursu może to potrwać od kilkudziesięciu sekund do kilku minut. Ważna uwaga: pełny backup zwykle nie zawiera danych użytkowników takich jak wyniki quizów czy wpisy na forum, o ile świadomie nie zaznaczono tej opcji przy tworzeniu kopii. To zabezpieczenie, które chroni przed przypadkowym przeniesieniem danych osobowych między środowiskami. Więcej informacji o tworzeniu kopii zapasowych i przywracaniu kursów znajdziesz w oficjalnej dokumentacji Moodle. Szczegółowy opis procesu jest dostępny w materiałach. 3. Import pojedynczych elementów z innego kursu Jeśli nie potrzebujecie całego kursu, a tylko wybranych materiałów – np. jednego modułu, quizu albo zestawu plików – Moodle oferuje osobną funkcję Import, dostępną w tym samym miejscu co Przywracanie: Wejdź do kursu docelowego i wybierz Więcej → Wykorzystanie kursu → Import. Wyszukaj kurs źródłowy (musisz mieć w nim uprawnienia edycyjne). Zaznacz, które typy elementów chcesz przenieść: aktywności, bloki, filtry. Na kolejnym ekranie zaznacz konkretne pozycje – możesz wybrać pojedynczy quiz czy plik, zamiast całej sekcji. Zatwierdź import i poczekaj na komunikat o zakończeniu operacji. Ta metoda jest wygodna, gdy budujecie kilka podobnych kursów (np. dla różnych działów) i chcecie ponownie wykorzystać część wspólnych materiałów, zamiast tworzyć je od nowa za każdym razem. 4. Import pakietu SCORM jako aktywności kursu Pakiet SCORM to najpopularniejszy format gotowego kursu e-learningowego – niezależnie od tego, czy powstał u zewnętrznego dostawcy, w narzędziu autorskim, czy w wyniku eksportu z innego systemu. Import wygląda inaczej niż w przypadku backupu kursu, bo SCORM jest tu jedną aktywnością wewnątrz kursu, a nie całym kursem: Wejdź do kursu, w którym ma się pojawić szkolenie, i włącz tryb edycji. W wybranej sekcji kliknij Dodaj aktywność lub zasób i z listy wybierz Pakiet SCORM. Wgraj plik .zip zawierający pakiet SCORM. Skonfiguruj podstawowe ustawienia: sposób oceniania (np. na podstawie najwyższego wyniku czy ostatniej próby), liczbę dozwolonych podejść oraz sposób wyświetlania treści (w nowym oknie czy w ramach strony kursu). Zapisz i wróć do kursu – zobaczysz nową aktywność, gotową do otwarcia przez użytkowników. Warto przetestować pakiet z poziomu konta testowego przed udostępnieniem go docelowej grupie – zwłaszcza jeśli pakiet SCORM pochodzi z zewnętrznego źródła i nie macie pewności co do jego zgodności z wersją Moodle. 5. Import listy użytkowników i przypisanie ról Materiały to jedna strona równania – druga to ludzie, którzy mają z nich korzystać. Zamiast dodawać każdego pracownika ręcznie, można zaimportować listę zbiorczo: Przygotuj plik CSV z kolumnami takimi jak imię, nazwisko, adres e-mail i nazwa użytkownika (dokładny wymagany format zależy od konfiguracji platformy). Przejdź do Administracja witryny → Użytkownicy → Prześlij użytkowników. Wgraj plik CSV i przejrzyj podgląd – Moodle pokaże, jak zinterpretuje poszczególne kolumny i czy nie ma błędów w danych. Zatwierdź import. Nowe konta zostaną utworzone automatycznie, a jeśli plik zawierał odpowiednie kolumny, użytkownicy mogą zostać od razu zapisani na wskazane kursy. Osobno przypisz role (np. nauczyciel, uczestnik, menedżer) w kursach lub na poziomie kategorii, jeśli nie zrobił tego import. Jeśli firma korzysta z logowania SSO (np. przez Azure AD lub Microsoft 365), część tego procesu może być zautomatyzowana przez synchronizację kont – to jednak osobny temat, wykraczający poza ręczny import. Więcej informacji o opisanych funkcjach znajdziesz w oficjalnej dokumentacji Moodle: Import course data opisuje przenoszenie wybranych aktywności i zasobów między kursami, SCORM settings wyjaśnia dodawanie i konfigurację pakietów SCORM, a Upload users przedstawia zbiorcze tworzenie kont i zapisywanie użytkowników do kursów za pomocą pliku CSV. Informacje dotyczące integracji i synchronizacji użytkowników z Microsoft 365 opisano również w Microsoft 365 integration. 6. Co zrobić, gdy nie masz jeszcze żadnych materiałów do zaimportowania To najczęstszy scenariusz zaraz po wdrożeniu: platforma działa technicznie poprawnie, ale nie ma jeszcze co do niej wgrać. Firma dysponuje wiedzą – procedurami, prezentacjami, nagraniami – ale nie w formacie, który Moodle rozumie jako gotowy kurs. W takiej sytuacji są dwie drogi: Przygotowanie treści samodzielnie, z pomocą narzędzia AI4E-learning. Zespół wskazuje cel szkolenia i przekazuje posiadane materiały źródłowe (dokumenty, prezentacje, nagrania), a narzędzie generuje z nich strukturę kursu wraz z narracją audio i quizami, eksportując gotowy pakiet SCORM – dokładnie w formacie, który można zaimportować metodą opisaną wyżej. Zlecenie produkcji kursu zespołowi TTMS. Jeśli potrzebujecie pełnej oprawy graficznej, animacji czy wersji językowych, produkcja na zamówienie obejmuje cały proces: od scenariusza, przez grafikę i interakcje, po eksport i testy na platformie. Obie ścieżki prowadzą do tego samego efektu końcowego: pakietu gotowego do wgrania na platformę, którą już macie skonfigurowaną.  7. Podsumowanie Uruchomienie Moodle to ważny krok, ale dopiero wtedy zaczyna się praktyczna część całego procesu: przeniesienie istniejących kursów, uporządkowanie użytkowników i wypełnienie platformy treściami, z których pracownicy rzeczywiście będą korzystać. Punkt wyjścia w każdej organizacji może być inny. Czasem są to gotowe pakiety SCORM i kursy z poprzedniego LMS, a czasem prezentacje, dokumenty, procedury i wiedza ekspertów, które dopiero trzeba zamienić w szkolenia. Dlatego warto spojrzeć na Moodle jako na część większego ekosystemu nauki w organizacji. TTMS może wesprzeć cały proces: od analizy potrzeb, wdrożenia i konfiguracji Moodle, przez migrację oraz integracje, aż po przygotowanie i uruchomienie treści szkoleniowych. Jeśli materiały źródłowe już istnieją, AI4E-learning może dodatkowo pomóc przekształcić je w gotowe kursy i znacząco skrócić drogę od firmowej wiedzy do szkolenia dostępnego dla pracowników. Jeśli właśnie zastanawiacie się, jak przejść od wdrożonej platformy do działającego środowiska szkoleniowego, porozmawiajmy o Waszym punkcie wyjścia. Pomożemy dobrać zakres wdrożenia i kolejne kroki do materiałów, systemów oraz potrzeb Waszej organizacji. FAQ Czy import kursu do Moodle przenosi też wyniki i historię użytkowników? To zależy od sposobu przenoszenia kursu. Import treści z innego kursu Moodle nie obejmuje danych użytkowników, takich jak posty na forum. W przypadku przywracania kursu z kopii zapasowej zakres przenoszonych informacji zależy od zawartości backupu oraz dostępnych uprawnień. Jaki jest maksymalny rozmiar pliku SCORM, który można wgrać do Moodle? Zależy to od ustawień konkretnej instalacji – limitu wielkości przesyłanych plików skonfigurowanego na serwerze oraz w samym Moodle. W razie potrzeby limit ten można podnieść na poziomie konfiguracji platformy. Czy mogę zaimportować kurs z zupełnie innego systemu LMS, a nie tylko z Moodle? Zależy to od tego, w jakim formacie system źródłowy eksportuje dane. Jeśli udostępnia pakiet SCORM, można go zaimportować jako aktywność w kursie Moodle. Pełne przeniesienie struktury kursu, ról i danych z innego LMS to zwykle osobny projekt migracyjny, wymagający wcześniejszego ustalenia zakresu. Co zrobić, jeśli import kończy się błędem? Przyczyn może być wiele, od limitów wielkości plików i konfiguracji środowiska po problemy ze zgodnością przy przywracaniu kopii kursów. W takim przypadku warto przeanalizować konkretny komunikat błędu i konfigurację środowiska Moodle. Czy zaimportowany pakiet SCORM da się później edytować bezpośrednio w Moodle? Nie – pakiet SCORM jest zamkniętą paczką treści i Moodle traktuje go jako gotowy plik do odtworzenia, a nie edytowalny materiał. Aby wprowadzić zmiany, trzeba zmodyfikować kurs w narzędziu, w którym powstał (np. w AI4E-learning albo innym autorskim narzędziu), wyeksportować go ponownie i zastąpić poprzednią wersję aktywności w Moodle.

    Czytaj więcej
    ChatGPT dla usług finansowych: co daje połączenie GPT z profesjonalnymi źródłami danych?

    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 więcej
    Jak automatyzować testy – najlepsze praktyki w 2026 roku

    Jak automatyzować testy – najlepsze praktyki w 2026 roku

    Cykl życia oprogramowania stale przyspiesza. Zespoły deweloperskie wdrażają zmiany coraz częściej, a od QA oczekuje się szybkiego dostarczania informacji zwrotnej bez kompromisów w obszarze jakości. W takich realiach automatyzacja testów nie jest już przewagą konkurencyjną, lecz standardowym elementem procesu wytwarzania oprogramowania. Sama liczba testów automatycznych nie gwarantuje jednak lepszego pokrycia, szybszych wdrożeń ani większej stabilności produktu. Wiele organizacji przekonuje się, że rozbudowywanie zestawów testowych bez odpowiedniej strategii prowadzi do rosnących kosztów utrzymania, problemów z niezawodnością oraz coraz wolniejszego procesu dostarczania zmian. Najbardziej efektywne zespoły traktują automatyzację jako integralną część procesu QA i software delivery. Obejmuje to nie tylko tworzenie testów, ale również ich odpowiednią selekcję, wybór narzędzi i frameworków, integrację z CI/CD, regularne utrzymanie oraz świadome zarządzanie kodem automatyzacji. W tym artykule przedstawiamy najważniejsze praktyki, które pomagają budować skalowalną i łatwą w utrzymaniu automatyzację testów w 2026 roku. 1. Dlaczego najlepsze praktyki automatyzacji testów mają kluczowe znaczenie w 2026 roku? Współczesne aplikacje coraz częściej opierają się na zintegrowanych usługach, dynamicznie zmieniających się interfejsach oraz coraz krótszych cyklach delivery. Testy automatyczne obejmują dziś nie tylko aplikacje webowe, ale również aplikacje mobilne, API, integracje oraz krytyczne ścieżki użytkownika. W efekcie równie ważne jak liczba testów w suite staje się sposób planowania, budowania i utrzymywania automatyzacji. Bez jasno określonych standardów automatyzacja bardzo szybko może stać się dodatkowym źródłem problemów zamiast wsparciem dla procesu delivery. Niestabilne testy spowalniają pipeline’y CI/CD, nieaktualne skrypty przestają odzwierciedlać bieżące wymagania biznesowe, a duplikowanie pokrycia testowego zwiększa czas wykonywania testów i koszty utrzymania bez realnej poprawy jakości. Jak opisaliśmy w naszym artykule o AI end-to-end testing, skuteczna i skalowalna automatyzacja wymaga jasno określonej odpowiedzialności za testy, pełnej traceability, regularnego utrzymania oraz świadomego powiązania wymagań biznesowych z celami testów, ich wykonaniem i uzyskiwanymi wynikami. To właśnie te elementy pozwalają budować automatyzację, która wspiera rozwój produktu zamiast generować dodatkowy dług technologiczny. 2. Jak decydować, które testy warto automatyzować? Nie każdy test powinien trafić do zestawu testów automatycznych. Skuteczna automatyzacja wymaga uporządkowanego podejścia, które pozwala identyfikować scenariusze przynoszące realną wartość biznesową, zamiast generować dodatkowe koszty utrzymania. 2.1 Oceniaj testy pod kątem częstotliwości, stabilności i kosztów Praktycznym sposobem wyboru testów do automatyzacji jest ocena każdego scenariusza pod kątem kilku kluczowych kryteriów: częstotliwości wykonywania, stabilności testowanej funkcjonalności, znaczenia biznesowego oraz nakładu pracy potrzebnego do wdrożenia i utrzymania automatyzacji. Najlepszymi kandydatami są zwykle powtarzalne scenariusze z jasno określonym oczekiwanym wynikiem, stabilnymi warunkami początkowymi, wiarygodnymi danymi testowymi oraz istotnym wpływem na jakość wydań. Sam fakt częstego wykonywania testu nie jest jednak wystarczającym argumentem. Warto również ocenić, czy scenariusz można wykonywać w sposób powtarzalny oraz czy jego rezultat można zweryfikować bez subiektywnej oceny. 2.2 Testy wymagające oceny człowieka pozostaw manualne Exploratory testing, ocena pierwszych doświadczeń użytkownika, analiza aspektów wizualnych czy scenariusze wymagające interpretacji ze strony testera zwykle lepiej sprawdzają się jako testy manualne. Próba ich automatyzacji często eliminuje elastyczność i obserwacje, które stanowią ich największą wartość. Jednocześnie rzadkie występowanie danego scenariusza nie oznacza automatycznie, że nie warto go automatyzować. Jeśli ewentualna awaria mogłaby zakłócić krytyczny proces biznesowy, zagrozić integralności danych lub generować wysokie ryzyko operacyjne, automatyzacja może być w pełni uzasadniona. Ostateczna decyzja powinna uwzględniać zarówno częstotliwość wykonywania testu, jak i jego wpływ na biznes. 2.3 Priorytetowo traktuj krytyczne ścieżki użytkownika Po odrzuceniu scenariuszy, które nie nadają się do automatyzacji, warto uszeregować pozostałe testy według ich znaczenia biznesowego oraz ryzyka regresji. Najczęściej priorytet otrzymują procesy związane z logowaniem, realizacją zakupów, dostępem do kont użytkowników, akceptacjami oraz kluczowymi procesami transakcyjnymi. Problemy w tych obszarach mogą bezpośrednio uniemożliwić użytkownikom korzystanie z najważniejszych funkcji systemu. Rozpoczęcie automatyzacji od takich scenariuszy pozwala zabezpieczyć najbardziej krytyczne elementy aplikacji już na wczesnym etapie. Testy dotyczące mniej istotnych funkcjonalności można dodawać stopniowo, gdy korzyści wynikające z automatyzacji uzasadniają koszty ich wdrożenia i późniejszego utrzymania. 3. Dopasuj strategię automatyzacji do aplikacji i kompetencji zespołu Po wytypowaniu testów, które warto zautomatyzować, kolejnym krokiem jest wybór podejścia najlepiej dopasowanego do aplikacji, sposobu dostarczania oprogramowania oraz kompetencji zespołu. Decyzja powinna uwzględniać nie tylko szybkość wykonywania testów, ale również łatwość utrzymania, poziom kontroli technicznej, dostępność rozwiązania dla zespołu QA oraz sposób integracji automatyzacji z istniejącym procesem developmentu. 3.1 Korzystaj z Test Pyramid, aby zachować równowagę między szybkością i pokryciem testowym Test Pyramid nadal pozostaje jednym z najskuteczniejszych modeli projektowania automatyzacji. Jej podstawę stanowią szybkie unit tests, wyższy poziom zajmują integration tests oraz service-level tests, a na szczycie znajduje się mniejsza liczba end-to-end tests weryfikujących kompletne ścieżki użytkownika. Dokładne proporcje pomiędzy poszczególnymi warstwami powinny wynikać z architektury aplikacji oraz obszarów największego ryzyka. System oparty na wielu usługach może wymagać większego nacisku na testy integracyjne, podczas gdy aplikacja biznesowa często potrzebuje szerszego pokrycia kluczowych procesów za pomocą testów end-to-end. Celem jest wykrywanie problemów na możliwie najniższym poziomie przy jednoczesnym zachowaniu wystarczającej liczby testów end-to-end, które potwierdzają poprawne działanie najważniejszych ścieżek użytkownika. 3.2 Wybierz między code-based, codeless i podejściem hybrydowym Code-based automation zapewnia pełną kontrolę nad architekturą testów, integracjami, reużywalnymi komponentami oraz standardami obowiązującymi w repozytorium. Takie podejście najlepiej sprawdza się w zespołach posiadających silne kompetencje techniczne, bardziej złożone wymagania testowe lub rozwinięte frameworki automatyzacji. Codeless oraz low-code automation ograniczają ilość kodu potrzebnego do definiowania typowych scenariuszy testowych. Dzięki temu automatyzacja staje się bardziej dostępna dla testerów manualnych i ekspertów biznesowych. Warto jednak zwrócić uwagę na to, jak dana platforma radzi sobie z bardziej złożoną logiką, utrzymaniem testów, version control oraz ownership automatyzacji. Coraz więcej organizacji wybiera model hybrydowy, który łączy prostotę definiowania testów z elastycznością klasycznej automatyzacji. Testerzy QA mogą definiować i weryfikować założenia testów, podczas gdy Automation Engineerowie odpowiadają za standardy techniczne oraz utrzymanie generowanego kodu. Takie podejście ogranicza liczbę przekazań pomiędzy zespołami bez zamykania się na jedno, proprietarne rozwiązanie. 3.3 Oceń dopasowanie technologiczne i długoterminowe utrzymanie Wybór odpowiedniej metodologii powinien wynikać z charakteru testowanego systemu oraz tego, kto będzie odpowiadał za utrzymanie automatyzacji w dłuższej perspektywie. Złożone procesy backendowe i integracje usług często wymagają pełnej kontroli technicznej, podczas gdy powtarzalne ścieżki użytkownika w aplikacjach webowych mogą być dobrym kandydatem do wykorzystania codeless automation. Warto również odpowiedzieć sobie na kilka praktycznych pytań: Gdzie będą uruchamiane wygenerowane testy? Czy ich kod będzie dostępny w istniejącym repozytorium? W jaki sposób wyniki testów wrócą do procesu QA? Czy wybrane rozwiązanie spełnia wymagania organizacji dotyczące bezpieczeństwa i deploymentu? Popularność narzędzia ma znacznie mniejsze znaczenie niż jego dopasowanie do architektury aplikacji, kompetencji zespołu, modelu governance oraz kosztów długoterminowego utrzymania automatyzacji. 4. Projektuj automatyzację z myślą o łatwym utrzymaniu Sposób projektowania testów i frameworków ma ogromny wpływ na długoterminową stabilność automatyzacji, niezależnie od wykorzystywanych narzędzi. Dobrze zaprojektowana automatyzacja oddziela warstwę techniczną od logiki biznesowej testu, wykorzystuje spójne standardy pracy z repozytorium i ułatwia analizę oraz naprawę błędów. 4.1 Korzystaj ze stabilnych locatorów Locatory bazujące na pozycji elementu na stronie, dynamicznie generowanych identyfikatorach lub rozbudowanych ścieżkach DOM często prowadzą do niestabilnych testów po zmianach w interfejsie. Tam, gdzie to możliwe, warto wykorzystywać selektory oparte na stabilnych atrybutach, takich jak dedykowane identyfikatory testowe, role dostępności (accessibility roles), etykiety lub inne elementy odpowiadające rzeczywistym interakcjom użytkowników z aplikacją. Dobry locator powinien być zarówno stabilny, jak i wystarczająco precyzyjny, aby jednoznacznie wskazywać właściwy element. Celem nie jest całkowite wyeliminowanie maintenance, ale ograniczenie błędów wynikających ze zmian technicznych niezwiązanych z faktycznie testowaną funkcjonalnością. 4.2 Wykorzystuj reużywalne wzorce projektowe Wzorce takie jak Page Object Model (POM) pozwalają oddzielić interakcje z aplikacją od logiki biznesowej weryfikowanej przez testy. Dzięki temu zmiana elementu interfejsu wymaga aktualizacji jednego komponentu zamiast modyfikacji dziesiątek testów. W zależności od projektu warto również korzystać z takich elementów jak component objects, współdzielone fixtures, funkcje pomocnicze, reużywalne akcje czy własne warstwy abstrakcji. Kluczowe znaczenie ma konsekwentne stosowanie wybranych wzorców w całym repozytorium. 4.3 Twórz jednoznaczne asercje Każdy test automatyczny powinien zawierać jasno określony i możliwy do zweryfikowania oczekiwany rezultat. Scenariusz, który wykonuje serię kroków bez sprawdzenia efektu końcowego, może zakończyć się statusem „passed”, mimo że testowany proces biznesowy nie działa poprawnie. Asercje powinny potwierdzać oczekiwane zachowanie aplikacji, a nie przypadkowe szczegóły implementacji. Jasno zdefiniowane oczekiwane rezultaty ułatwiają również review testów, diagnostykę błędów oraz traceability względem wymagań biznesowych. 4.4 Traktuj test data management jako osobny obszar Dane testowe powinny mieć jasno określonego właściciela oraz powtarzalny proces przygotowania. Tworzenie, inicjalizacja, współdzielenie, zabezpieczanie i czyszczenie danych testowych warto zaplanować już podczas projektowania testów, a nie dopiero po stworzeniu skryptów. Zespoły powinny również unikać ukrytych zależności od danych pozostawionych przez wcześniejsze wykonania testów. Przewidywalne dane testowe ułatwiają odtwarzanie błędów oraz ograniczają liczbę fałszywych wyników wynikających z nieaktualnych, niekompletnych lub niespójnych rekordów. 4.5 Dbaj o niezależność testów Testy automatyczne nie powinny zależeć od kolejności wykonywania innych testów. Każdy scenariusz powinien rozpoczynać się od znanego stanu systemu i samodzielnie przygotowywać warunki niezbędne do wykonania testu. Izolację można osiągnąć między innymi poprzez użycie fixtures, kontrolowane przygotowanie danych testowych, oddzielne konteksty przeglądarki, przygotowanie danych przez API, reset środowiska lub procedury cleanup. Awaria pojedynczego testu nie powinna powodować błędnych wyników w innych częściach test suite. 4.6 Stosuj spójne standardy repozytorium Kod automatyzacji powinien podlegać tym samym standardom jakościowym co pozostała część projektu. Spójne nazewnictwo, struktura katalogów, sposób wykorzystania fixtures, helperów, hooków, obsługa błędów, formatowanie kodu oraz zasady code review sprawiają, że zarówno ręcznie tworzone, jak i generowane testy są łatwiejsze do zrozumienia i utrzymania. Ma to szczególne znaczenie w projektach, w których część kodu automatyzacji jest generowana automatycznie. Wygenerowany kod powinien wpisywać się w istniejący framework i standardy repozytorium, zamiast tworzyć równoległą strukturę, którą zespół będzie musiał utrzymywać oddzielnie. 5. Integruj odpowiednie testy na właściwym etapie CI/CD Testy automatyczne przynoszą największą wartość wtedy, gdy są częścią pipeline’u CI/CD i dostarczają szybką oraz użyteczną informację zwrotną osobom odpowiedzialnym za wdrażane zmiany. Celem nie jest uruchamianie wszystkich testów po każdej modyfikacji kodu, lecz dopasowanie zakresu testowania do konkretnego etapu procesu delivery. 5.1 Dopasuj zakres testów do etapu pipeline’u Dobrze zaprojektowany pipeline pozwala zachować równowagę pomiędzy szybkością feedbacku a głębokością walidacji. Na wczesnych etapach zmianę mogą weryfikować szybkie unit tests oraz statyczna analiza kodu. Na etapie pull requestów lub merge requestów warto uruchamiać integration tests oraz odpowiednio dobrany fragment regression suite, który pozwala ocenić wpływ zmiany na szerszy obszar aplikacji. Bardziej rozbudowane testy regresyjne mogą być wykonywane po połączeniu zmian z główną gałęzią, przed wdrożeniem, według harmonogramu lub w sytuacjach, gdy poziom ryzyka uzasadnia szerszą walidację. Smoke tests pełnią inną funkcję. Ich zadaniem jest szybkie potwierdzenie, że wdrożona aplikacja działa, jest dostępna dla użytkowników i obsługuje najbardziej krytyczne ścieżki biznesowe. Powinny one uzupełniać testy regresyjne, a nie je zastępować. Struktura pipeline’u i oczekiwany czas wykonywania testów powinny być dostosowane do architektury aplikacji, infrastruktury, częstotliwości wydań oraz poziomu ryzyka biznesowego. Każdy zespół powinien zdefiniować własne quality gates, określające, jakie dowody jakości są wymagane przed przejściem do kolejnego etapu procesu. 5.2 Dobieraj testy na podstawie zmian i poziomu ryzyka Uruchamianie pełnego test suite po każdej zmianie w kodzie z czasem zaczyna wydłużać proces delivery. Bardziej efektywne podejście polega na wybieraniu testów na podstawie komponentów objętych zmianą, powiązanych wymagań biznesowych, krytycznych procesów, historii wcześniejszych uruchomień oraz znanych obszarów ryzyka. Proces selekcji testów powinien być transparentny. Zespół powinien rozumieć, dlaczego dany test został uwzględniony lub pominięty, a także mieć możliwość rozszerzenia zakresu walidacji, jeżeli analiza wpływu zmiany okaże się niepełna lub pojawią się nowe ryzyka. Ta warstwowa, oparta na ryzyku struktura jest też fundamentem, na którym opiera się selekcja i priorytetyzacja testów wspierana przez AI. Jeśli interesuje Cię, jak AI wpisuje się właśnie w ten etap pipeline’u, sprawdź nasz przewodnik AI w automatyzacji testów oprogramowania: przewodnik 2026. 5.3 Dostarczaj wyniki, które pomagają podejmować decyzje Wyniki testów powinny dostarczać znacznie więcej informacji niż jedynie status „passed” lub „failed”. Raport powinien wskazywać, który scenariusz zakończył się błędem, zawierać dane pozwalające przeprowadzić analizę problemu oraz zachowywać powiązanie z wymaganiem biznesowym, przypadkiem testowym, zmianą w kodzie i historią wykonania testu. Prezentowanie wyników bezpośrednio w pull requestach lub merge requestach pozwala zespołom developerskim analizować rezultaty automatyzacji równocześnie ze zmianami w kodzie. Z kolei przekazywanie wyników do narzędzi QA i systemów zarządzania wymaganiami zapewnia pełną traceability od wymagania biznesowego, przez implementację testu, aż po jego wykonanie. Takie podejście zamyka pętlę feedbacku i pozwala podejmować decyzje release’owe w oparciu o rzetelne dane, a nie domysły. 6. Traktuj utrzymanie testów jako ciągły proces Flaky tests mogą bardzo szybko podważyć zaufanie do automatyzacji. Gdy ten sam test raz przechodzi, a raz kończy się niepowodzeniem bez żadnej istotnej zmiany w aplikacji, zespoły zaczynają traktować wyniki jako szum informacyjny. Ponowne uruchomienie testu może tymczasowo odblokować pipeline, ale nie rozwiązuje rzeczywistego problemu. 6.1 Analizuj źródło problemu, a nie objawy Przyczyna występowania flaky tests może leżeć w kodzie testów, samej aplikacji, danych testowych, środowisku wykonawczym lub zewnętrznych zależnościach. Do najczęstszych powodów należą sztywne opóźnienia (fixed delays), brak odpowiedniej synchronizacji, niestabilne locatory, współdzielony stan pomiędzy testami, konfliktujące dane testowe, asynchroniczne działanie aplikacji, zmienność połączeń sieciowych oraz ograniczenia zasobów środowiska wykonawczego. Sposób rozwiązania problemu powinien odpowiadać jego źródłu. Problemy związane z timingiem często wymagają zastosowania warunkowych mechanizmów oczekiwania zamiast wydłużania opóźnień. Błędy wynikające ze współdzielonego stanu wymagają lepszej izolacji i kontrolowanego przygotowania danych testowych. Problemy z selektorami mogą wymagać bardziej stabilnych locatorów lub dodatkowych warstw abstrakcji. Natomiast błędy powodowane przez zależności zewnętrzne mogą wymagać wykorzystania mocków, kontrolowanych środowisk testowych lub innych metod ograniczających niepotrzebną zmienność. Zespoły powinny również gromadzić wystarczającą ilość informacji pozwalających odróżnić defekt aplikacji od błędu testu lub problemu środowiskowego. Trace execution, logi, screenshoty, nagrania, informacje o ruchu sieciowym, szczegóły środowiska oraz wskazanie kroku, na którym wystąpił błąd, znacząco ułatwiają analizę i odtwarzanie problemów występujących nieregularnie. 6.2 Regularnie przeglądaj i porządkuj test suite Testy automatyczne powinny być oceniane przez cały cykl życia produktu. Zmiany w aplikacji mogą sprawiać, że niektóre testy stają się zbędne, duplikują istniejące pokrycie lub tracą wartość biznesową. Utrzymywanie wszystkich testów bez wyjątku zwiększa czas wykonywania test suite i nakład pracy związany z maintenance, niekoniecznie poprawiając jakość release’ów. Dobrze zdefiniowany proces maintenance powinien obejmować przegląd flaky tests, usuwanie nieaktualnych scenariuszy, eliminowanie zduplikowanego pokrycia oraz ponowną ocenę testów, których wartość biznesowa lub stabilność techniczna uległy zmianie. Częstotliwość takich przeglądów powinna być dostosowana do wielkości test suite, częstotliwości wydań, poziomu ryzyka i skali zmian w produkcie. Każdy test po przeglądzie powinien mieć jasno określony dalszy los. Może zostać naprawiony, przepisany, przeniesiony do bardziej odpowiedniej warstwy testowania, czasowo wyłączony z przypisanym właścicielem lub usunięty, jeśli nie dostarcza już wartościowych informacji. 6.3 Monitoruj kondycję automatyzacji i koszty utrzymania Sam pass rate nie wystarczy, aby ocenić kondycję automatyzacji. Zespoły powinny monitorować również powtarzalność błędów, częstotliwość ponownych uruchomień testów, czas wykonywania test suite, nakład pracy związany z maintenance, liczbę nieaktualnych testów, poziom zduplikowanego pokrycia oraz czas potrzebny na analizę i naprawę błędów. Takie wskaźniki pomagają odróżnić rozrastający się zestaw automatyzacji od automatyzacji, którą można skutecznie utrzymywać w długim okresie. Dodawanie kolejnych testów zwiększa wartość tylko wtedy, gdy zespół rozumie wyniki, potrafi utrzymywać testy i ufa informacjom dostarczanym przez każde wykonanie. Równie ważna jest traceability zmian w automatyzacji. Zespół powinien mieć wgląd w to, co zostało zmienione, dlaczego test został zaktualizowany, jak przebiegał proces review oraz czy zmodyfikowany test nadal weryfikuje pierwotne wymaganie biznesowe. Podejście oparte na zarządzaniu pełnym cyklem życia automatyzacji opisaliśmy szerzej w naszym przewodniku dotyczącym najlepszych praktyk QA w testowaniu oprogramowania. 7. Traktuj kod automatyzacji tak jak kod produkcyjny Kod testów automatycznych powinien podlegać tym samym standardom co kod aplikacji. Testy wymagają jasno określonego ownership, kontroli wersji, spójnych zasad organizacji repozytorium, procesu review oraz quality gates. Bez tych praktyk automatyzacja z czasem staje się coraz trudniejsza do zrozumienia, rozwijania i utrzymywania. Ownership powinien obejmować zarówno warstwę biznesową, jak i techniczną. Specjaliści QA mogą odpowiadać za definiowanie scenariuszy, oczekiwanych rezultatów i zakresu pokrycia testowego, natomiast Automation Engineers lub developerzy powinni weryfikować, czy kod testów jest zgodny ze standardami projektu i może być utrzymywany w ramach istniejącego frameworka. Niezależnie od tego, czy testy są tworzone ręcznie, czy generowane przy wsparciu narzędzi automatyzujących, powinny trafiać do repozytorium poprzez standardowy proces pull request lub merge request. Osoby przeprowadzające review powinny mieć możliwość sprawdzenia, co dokładnie weryfikuje dany test, w jaki sposób komunikuje się z aplikacją, z jakich komponentów współdzielonych korzysta oraz czy nie wprowadza niestabilnych zależności lub zduplikowanego pokrycia testowego. Gdy dla organizacji istotne są kwestie ownership i przenośności rozwiązań, wygenerowane testy nie powinny pozostawać wyłącznie w zamkniętym, proprietarnym środowisku wykonawczym. Przechowywanie automatyzacji w repozytorium klienta zapewnia pełną widoczność zmian, możliwość przeprowadzenia review oraz objęcie testów tymi samymi zasadami governance, które obowiązują pozostałe zasoby projektu. Zespoły powinny również jasno określić, kto odpowiada za reakcję na sytuację, w której test staje się niestabilny lub nieaktualny. Wyraźnie zdefiniowany ownership pozwala uniknąć sytuacji, w której błędne testy pozostają nierozwiązane, ponieważ zespoły QA, developmentu i automatyzacji zakładają, że odpowiedzialność spoczywa po stronie kogoś innego. 8. Gdzie w tym procesie wpisuje się AI AI coraz częściej wspiera te praktyki — pomagając tworzyć przypadki testowe na podstawie wymagań, weryfikować proponowaną ścieżkę przed wygenerowaniem kodu czy wskazywać testy, które prawdopodobnie staną się niestabilne. To zagadnienie wykracza poza zakres praktyk opisanych powyżej i dotyczy raczej strategii, doboru narzędzi oraz governance, dlatego omawiamy je szczegółowo w osobnym artykule: AI w automatyzacji testów oprogramowania: przewodnik 2026. 9. Najczęstsze błędy w automatyzacji testów, których warto unikać Nawet dobrze zaprojektowana automatyzacja może z czasem tracić swoją wartość, jeśli zespoły podejmują niewłaściwe decyzje dotyczące zakresu testów, ownership czy utrzymania. Do najczęstszych błędów należą: Automatyzowanie wszystkich możliwych scenariuszy zamiast skupienia się na testach powtarzalnych, stabilnych i krytycznych z punktu widzenia biznesu. Traktowanie ponownego uruchamiania testów jako stałego rozwiązania problemu flaky tests zamiast analizowania rzeczywistych przyczyn ich niestabilności. Pozostawianie w test suite nieaktualnych lub zduplikowanych testów bez regularnych przeglądów. Wybór narzędzia wyłącznie na podstawie liczby funkcji, bez uwzględnienia integracji, utrzymania, wdrożeń, ownership kodu oraz dopasowania do kompetencji zespołu. Generowanie automatyzacji bez wcześniejszej weryfikacji, czy dany scenariusz faktycznie działa w testowanej aplikacji. Akceptowanie wygenerowanych testów bez sprawdzenia, czy odzwierciedlają rzeczywiste wymagania i oczekiwane zachowanie biznesowe. Przechowywanie automatyzacji wyłącznie w zamkniętym, proprietarnym środowisku, gdy organizacja wymaga przenośnego i podlegającego review kodu we własnym repozytorium. Zarządzanie testami poza standardowymi procesami version control, code review i quality gates w CI/CD. Brak jasno określonej odpowiedzialności za cel testu, jakość kodu oraz bieżące utrzymanie automatyzacji. Unikanie tych błędów wymaga czegoś więcej niż wdrożenia kolejnych narzędzi lub napisania większej liczby skryptów. Skuteczna automatyzacja opiera się na kontrolowanym procesie, który łączy wymagania biznesowe, projektowanie testów, wyniki wykonania, kod automatyzacji, review oraz maintenance w jeden spójny workflow. 10. Jak Qatana wykorzystuje najlepsze praktyki automatyzacji testów? Qatana łączy opisane wcześniej praktyki w ramach agentowej platformy do automatyzacji testów. Rozwiązanie przekształca wymagania zapisane w Jira lub GitLab w gotowe do automatyzacji przypadki testowe, weryfikuje proponowaną ścieżkę użytkownika poprzez wykonanie testu w Playwright, a następnie generuje standardowy kod Playwright dostarczany w formie gotowego do review merge requestu. Zespół QA zachowuje kontrolę nad celem i zakresem testu, podczas gdy część techniczna może zostać zweryfikowana przez inżynierów w ramach istniejącego procesu merge request review. Wyniki wykonania testów pozostają powiązane z wymaganiem, przypadkiem testowym oraz kodem, zapewniając pełną traceability w całym workflow. Qatana działa w pełni on-premise i wspiera wykorzystanie wybranego przez organizację modelu LLM, dzięki czemu kontekst projektu, wygenerowany kod oraz dane testowe pozostają w środowisku klienta. Umów demo i zobacz, jak Qatana zamienia wymagania biznesowe w automatyzację opartą na Playwright. 11. FAQ – Najczęściej zadawane pytania Jaką część test suite warto zautomatyzować? Nie istnieje jeden uniwersalny wskaźnik. W pierwszej kolejności warto automatyzować scenariusze stabilne, powtarzalne i krytyczne biznesowo, pozostawiając exploratory testing oraz testy wymagające oceny człowieka w obszarze testów manualnych. Jaka jest różnica między strategią automatyzacji a frameworkiem? Strategia automatyzacji określa, co, dlaczego i w jaki sposób powinno zostać zautomatyzowane oraz jak będzie mierzony sukces tych działań. Framework stanowi natomiast techniczną podstawę służącą do tworzenia, uruchamiania i utrzymywania testów automatycznych. Jak ocenić, czy ROI z automatyzacji jest dodatnie? Warto porównać czas i koszty zaoszczędzone dzięki automatyzacji z kosztami jej wdrożenia, wykonywania i utrzymania. Jeżeli nakład pracy związany z maintenance regularnie przewyższa uzyskiwane korzyści, należy ponownie ocenić dobór testów oraz przyjęte podejście do automatyzacji. Jaka jest najczęstsza przyczyna tego, że program automatyzacji „utyka” po pierwszym pilotażu? Zwykle nie jest to problem narzędziowy, tylko brak ciągłego ownership. Zespoły z sukcesem automatyzują pierwszą partię testów, ale bez zdefiniowanego cyklu utrzymania, jasno przypisanej odpowiedzialności za kod oraz procesu review w repozytorium, suite szybciej obrasta w niestabilne i nieaktualne testy, niż ktokolwiek zdąży je naprawić — a zaufanie do wyników automatyzacji spada.

    Czytaj więcej
    ChatGPT, zintegrowany LLM, SLM czy automatyzacja? Jak dobrać AI do procesu biznesowego

    ChatGPT, zintegrowany LLM, SLM czy automatyzacja? Jak dobrać AI do procesu biznesowego

    W 2025 roku sztucznej inteligencji używało 20% przedsiębiorstw w Unii Europejskiej, wobec 13,5% rok wcześniej. W Polsce odsetek ten wynosił 8,4%. Najczęstszym zastosowaniem była analiza języka pisanego, z której korzystało 11,8% firm objętych badaniem. Autorzy badania opublikowanego w 2026 roku w Organization Science opisali to zjawisko jako „jagged technological frontier”, czyli nierównomierną granicę możliwości AI: zadania o podobnym poziomie trudności dla człowieka mogą sprawiać modelowi zupełnie różne trudności. Kolejny etap wymaga odpowiedzi na bardziej precyzyjne pytanie: jaka forma AI pasuje do konkretnego zadania? W eksperymencie przeprowadzonym wśród 758 konsultantów osoby korzystające z GPT-4 wykonały 12,2% więcej zadań i ukończyły je średnio o 25,1% szybciej, gdy zadania mieściły się w zakresie możliwości modelu. Przy złożonym zadaniu wykraczającym poza ten zakres prawdopodobieństwo poprawnego rozwiązania spadło o 19 punktów procentowych. Autorzy badania opublikowanego w 2026 roku w Organization Science nazwali tę nieregularną granicę możliwości AI „jagged technological frontier”. Efektywność wynika więc z dopasowania technologii do zadania, danych, ryzyka i sposobu kontroli wyniku. Dla jednego procesu właściwym rozwiązaniem będzie firmowy asystent LLM. Drugi będzie wymagał aplikacji połączonej z CRM, bazą wiedzy i systemem uprawnień. W trzecim sprawdzi się niewielki model działający lokalnie. Operacje o jednoznacznych regułach można powierzyć kodowi, silnikom reguł lub robotyzacji procesów biznesowych (RPA). Klasyczne uczenie maszynowe sprawdza się między innymi w prognozowaniu i klasyfikacji danych. 1. LLM i SLM w firmie: wybór modelu, integracji i miejsca przetwarzania danych Określenia „LLM”, „wdrożony LLM” i „zamknięty SLM” łączą kilka warstw technologii. W praktyce biznesowej warto rozdzielić cztery decyzje: Sposób pracy: czy pracownik rozmawia z gotowym asystentem, czy proces uruchamia się automatycznie? Zakres integracji: czy rozwiązanie pracuje na materiałach przekazanych przez użytkownika, czy pobiera dane i wykonuje działania w systemach firmy? Klasa modelu: czy zadanie wymaga szerokich możliwości dużego modelu językowego, czy wystarczy wyspecjalizowany SLM? Miejsce przetwarzania: czy model działa jako usługa chmurowa, w wydzielonym środowisku, w prywatnej chmurze, lokalnie albo bezpośrednio na urządzeniu? Skrót SLM (Small Language Model) oznacza mały model językowy, zwykle wymagający mniej zasobów obliczeniowych. Określenie „system zamknięty” wymaga doprecyzowania: może odnosić się do ograniczonego dostępu, odizolowanego środowiska lub przetwarzania danych we własnej infrastrukturze. Duży LLM może działać w środowisku prywatnym, a SLM może być udostępniany przez publiczne API. Sama wielkość modelu nie określa warunków bezpieczeństwa danych. 2. Sześć sposobów wykorzystania AI w procesach biznesowych Wariant Jak działa Najlepsze dopasowanie Główny miernik Firmowy asystent LLM Pracownik zleca zadanie i sprawdza wynik w zatwierdzonym środowisku, np. ChatGPT Business lub Enterprise Analiza, redagowanie, podsumowanie, przygotowanie wariantów, praca ad hoc Oszczędność czasu na zadanie po uwzględnieniu weryfikacji i poprawek Zintegrowana aplikacja LLM lub RAG Model korzysta z firmowych źródeł, reguł, uprawnień i integracji Powtarzalne procesy oparte na dokumentach, wiedzy i danych z systemów Koszt poprawnie zakończonej sprawy Agent AI Rozwiązanie planuje kolejne kroki, wybiera narzędzia i realizuje cel w określonym zakresie Wieloetapowe procesy z wyjątkami i dynamiczną ścieżką Odsetek poprawnie wykonanych zadań SLM Mniejszy model obsługuje wąski zakres zadań w chmurze, na serwerze firmy, na edge albo na urządzeniu Duża liczba zadań, stały zakres tematyczny, krótki czas odpowiedzi, praca offline Jakość w porównaniu z LLM przy określonym koszcie i limicie czasu odpowiedzi p95 Prywatne lub lokalne wdrożenie LLM albo SLM działa w kontrolowanym środowisku, prywatnej chmurze, sieci firmy lub na urządzeniu Wymogi lokalizacji danych, ciągłości działania, łączności, infrastruktury lub polityki bezpieczeństwa Zgodność z wymaganiami, jakość, dostępność i całkowity koszt posiadania i użytkowania rozwiązania (TCO) Reguły, RPA lub klasyczne ML Przebieg procesu jest zapisany w kodzie, warunkach, modelu predykcyjnym lub maszynie stanów Obliczenia, transakcje, stałe ścieżki i jednoznaczne decyzje Dokładność, powtarzalność i kompletność śladu audytowego W dojrzałym wdrożeniu warianty te często współpracują. Model językowy interpretuje wiadomość, reguły sprawdzają warunki, aplikacja pobiera dane, człowiek zatwierdza działanie, a system transakcyjny zapisuje wynik. 3. Do jakich zadań wykorzystać ChatGPT lub innego asystenta LLM? Gotowy asystent LLM dobrze wspiera zadania, w których pracownik odpowiada za sprawdzenie i wykorzystanie wyniku. Użytkownik inicjuje pracę, przekazuje kontekst, ocenia odpowiedź i decyduje o jej wykorzystaniu. Wynik ma formę projektu, rekomendacji, analizy lub materiału roboczego. Do tej grupy należą między innymi: przygotowanie pierwszej wersji raportu, wiadomości, prezentacji lub artykułu, streszczenie dokumentów i korespondencji, porównanie kilku materiałów dostarczonych przez użytkownika, tworzenie pytań, scenariuszy i wariantów rozwiązania, tłumaczenie treści przeznaczonych do dalszej kontroli, eksploracyjna analiza danych i wyjaśnianie wyników, porządkowanie notatek ze spotkania, przygotowanie projektu procedury lub planu działania. Taki sposób pracy sprawdza się w procesach, gdy każda odpowiedź przechodzi kontrolę człowieka, rezultat można łatwo poprawić lub wycofać, a zadanie nie wymaga automatycznego zapisu w systemie krytycznym. Duża zmienność materiału i potrzeba pracy językowej dodatkowo zwiększają użyteczność LLM. Bezpieczeństwo zależy od zatwierdzonego produktu i konfiguracji. OpenAI deklaruje, że dane z ChatGPT Business, ChatGPT Enterprise i API nie są domyślnie wykorzystywane do trenowania modeli. Dokumentacja kontroli danych API opisuje również oddzielne zasady retencji, w tym standardowe rejestry służące monitorowaniu nadużyć oraz opcję Zero Data Retention dla klientów spełniających określone warunki. Przed rozpoczęciem pracy organizacja powinna sprawdzić klasyfikację danych, umowę, region przetwarzania, retencję, uprawnienia administratorów i zasady korzystania z połączonych aplikacji. Więcej przykładów takiej pracy zawiera zestawienie 15 integracji ChatGPT z aplikacjami biznesowymi. 3.1 Jak mierzyć oszczędność czasu i jakość pracy z LLM? Badanie pracowników wyłącznie za pomocą ankiety może zawyżać efekt. W eksperymencie METR doświadczeni programiści wykonywali badane zadania z narzędziami AI o 19% dłużej, a po eksperymencie nadal oceniali, że AI przyspieszyła ich pracę o 20%. Badanie obejmowało 16 osób i 246 rzeczywistych zadań w znanych im repozytoriach, więc jego wynik dotyczy tego konkretnego środowiska. Metodologiczny wniosek ma szersze zastosowanie: przed wdrożeniem trzeba zmierzyć rzeczywisty czas i jakość. Dla asystenta LLM warto monitorować medianę czasu wykonania zadania, udział wyników zaakceptowanych bez zmian, średni czas poprawek, jakość ocenianą według jednolitych kryteriów, częstotliwość użycia oraz liczbę przypadków, w których użytkownik wrócił do poprzedniej metody pracy. 4. Kiedy zintegrować LLM z systemami firmy, a kiedy wdrożyć agenta AI? Integracja staje się uzasadniona, gdy wartość procesu zależy od aktualnych danych firmy, powtarzalnego przebiegu i współpracy kilku systemów. Model otrzymuje wtedy kontrolowany dostęp do dokumentów, bazy wiedzy, CRM, ERP, systemu zgłoszeń albo poczty. Aplikacja weryfikuje tożsamość użytkownika, kontroluje zakres udostępnianych danych, ustala format odpowiedzi, sprawdza wyniki, rejestruje działania i kieruje wybrane operacje do zatwierdzenia. Typowa zintegrowana aplikacja AI obejmuje pięć warstw: Wejście: wiadomość, dokument, formularz, zdarzenie systemowe lub rekord. Kontekst: dane pobrane zgodnie z uprawnieniami, często z wykorzystaniem RAG. Model: LLM albo SLM dobrany do konkretnego etapu. Walidacja: reguły, kontrola kompletności, sprawdzenie źródeł, klasyfikacja ryzyka. Wynik: odpowiedź dla człowieka, projekt rekordu albo zatwierdzone działanie w systemie. Takiej architektury wymagają między innymi wyszukiwanie odpowiedzi w wewnętrznej bazie wiedzy, analiza umów według firmowej listy ryzyk, przygotowanie oferty na podstawie CRM i cennika, klasyfikowanie zgłoszeń, wdrażanie nowych pracowników, weryfikacja dokumentów zakupowych oraz tworzenie odpowiedzi na podstawie historii klienta. Mechanizm RAG pozwala pobierać aktualne fragmenty zatwierdzonych źródeł i dołączać je do kontekstu odpowiedzi. Agent AI jest kolejnym poziomem integracji. Otrzymuje cel, dobiera narzędzia i planuje sekwencję działań. Według aktualnych wytycznych Google Cloud dotyczących architektury agentowej agenci pasują do otwartych, wieloetapowych problemów wymagających użycia danych zewnętrznych i pewnego zakresu autonomii. Do przygotowania pojedynczego streszczenia lub tłumaczenia zwykle wystarcza aplikacja o z góry ustalonej sekwencji działań. Rolę zaawansowanego modelu jako warstwy wnioskowania połączonej z narzędziami, danymi i uprawnieniami szerzej opisujemy w artykule GPT-5.5 dla biznesu: nowa era agentów AI. Zakres samodzielnych działań agenta można rozszerzać, gdy wyniki testów potwierdzają wymaganą skuteczność i bezpieczeństwo. Uprawnienia agenta warto ograniczyć do funkcji potrzebnych w danym procesie, rozdzielić odczyt od zapisu i wprowadzić zatwierdzenie działań o istotnych skutkach dla firmy lub klienta. OWASP określa nadmierną funkcjonalność, zbyt szerokie uprawnienia i nadmierną autonomię jako trzy główne źródła ryzyka Excessive Agency. Zasada najmniejszych uprawnień ogranicza skutki błędnej interpretacji, wygenerowania nieprawdziwej informacji lub ataku polegającego na podsunięciu modelowi złośliwych instrukcji (prompt injection). 5. Do jakich procesów biznesowych sprawdzi się mały model językowy SLM? Small Language Model wykorzystuje mniej parametrów i zasobów obliczeniowych niż duży model językowy. Według Microsoft Azure sprzyja to krótszemu czasowi odpowiedzi, niższemu zapotrzebowaniu na infrastrukturę oraz przetwarzaniu danych blisko miejsca ich powstawania (edge computing), np. na urządzeniach przemysłowych. Wyspecjalizowany SLM może sprawdzić się w zadaniach o stałej tematyce, przewidywalnych danych wejściowych i jasno określonym wyniku. Warto przetestować SLM, gdy proces spełnia kilka z poniższych warunków: stały zestaw kategorii, intencji, pól albo typów odpowiedzi, wysoki i przewidywalny wolumen wywołań, krótki wymagany czas reakcji mierzony jako p95, czyli wartość, której nie przekracza 95% czasów odpowiedzi, ograniczone zasoby sprzętowe, potrzeba pracy offline lub bezpośrednio na urządzeniu, dostęp do danych z danego obszaru działalności oraz zestawu wzorcowych odpowiedzi, możliwość przekazywania trudnych przypadków do większego modelu lub człowieka. Przykładem może być klasyfikacja zgłoszeń według 30 stałych kategorii, rozpoznawanie intencji rozmówcy, odczytywanie wartości pól z jednego typu dokumentu, generowanie krótkich odpowiedzi w ściśle określonym zakresie tematycznym albo lokalna analiza komunikatów na urządzeniu przemysłowym. O wyborze decyduje wynik testu na danych firmy. SLM powinien osiągnąć wymagany poziom jakości, czasu odpowiedzi i kosztu poprawnie obsłużonej sprawy. Firma może przykładowo wymagać, aby mniejszy model utrzymywał co najmniej 98% jakości referencyjnego LLM, obniżał koszt poprawnego wyniku o co najmniej 20% i mieścił się w limicie p95. Są to przykładowe progi decyzyjne, które właściciel procesu ustala przed pilotażem. 5.1 Kiedy wdrożyć LLM lub SLM lokalnie albo w prywatnej chmurze? Prywatne lub lokalne wdrożenie może wynikać z wymagań dotyczących suwerenności danych, polityki bezpieczeństwa, ciągłości pracy, opóźnień sieciowych albo środowiska bez dostępu do internetu. Takie wdrożenie może wykorzystywać SLM lub większy model. Równocześnie firmowa aplikacja może korzystać z zarządzanego API z szyfrowaniem, kontrolą retencji, odpowiednim regionem i umową dotyczącą danych. Najbardziej efektywna bywa architektura kaskadowa. Microsoft opisuje model hybrydowy, w którym SLM obsługuje typowe zapytania i przekazuje bardziej złożone przypadki do LLM. W środowisku biznesowym do tej kaskady warto dodać trzecią ścieżkę: przekazanie sprawy pracownikowi, gdy wynik budzi wątpliwości, ryzyko jest wysokie lub brakuje wymaganych danych. 6. Które procesy zautomatyzować za pomocą reguł, RPA lub uczenia maszynowego? Procesy o stałych regułach wymagają jasno określonej kolejności działań i warunków ich wykonania. Dokumentacja AWS dotycząca orkiestracji rozdziela przepływy regułowe, w których kolejne stany i przejścia są jawnie zapisane, oraz orkiestrację agentową, w której model interpretuje cel i dynamicznie wybiera narzędzia. Obie warstwy mogą działać w jednej aplikacji. Proces Rekomendowany mechanizm Rola modelu językowego Naliczenie podatku, wynagrodzenia lub rabatu Kod i silnik reguł Wyjaśnienie wyniku lub interpretacja zapytania użytkownika Wykonanie płatności, zwrotu lub zmiany limitu Proces transakcyjny z kontrolą uprawnień Rozpoznanie intencji i przygotowanie danych do zatwierdzenia Nadanie lub odebranie uprawnień IAM, reguły ról i zatwierdzenia Obsługa zgłoszenia w języku naturalnym Sprawdzenie kompletności wymaganych pól Walidator schematu Ekstrakcja pól z nieustrukturyzowanego dokumentu Prognoza rezygnacji klienta lub popytu Klasyczne uczenie maszynowe Opis czynników i przygotowanie komunikacji Interpretacja dowolnie sformułowanej wiadomości LLM lub SLM Klasyfikacja intencji i przekazanie danych do kontrolowanego workflow W procesie finansowym LLM może odczytać wiadomość, rozpoznać żądanie i przygotować propozycję. Reguły sprawdzają saldo, limity, status klienta i wymagane zgody. System transakcyjny wykonuje operację po spełnieniu warunków. Każda warstwa realizuje zadanie, dla którego można określić jasne kryteria poprawności. 7. Jak dobrać AI do procesu? Cztery kryteria oceny Wstępną kwalifikację można przeprowadzić w czasie krótkiego warsztatu. Osoba odpowiedzialna za proces ocenia go w czterech obszarach, przyznając od 0 do 3 punktów w każdym z nich. Poszczególne oceny pomagają określić wymagania wobec modelu, integracji, zabezpieczeń i infrastruktury. Oś 0 1 2 3 Złożoność interpretacji treści Stałe pola i reguły Stały zestaw kategorii Interpretacja kontekstu Łączenie informacji i wnioskowanie na podstawie wielu źródeł Integracja i autonomia Brak dostępu do systemów Odczyt jednego źródła Odczyt wielu źródeł lub przygotowanie danych do zapisania w systemie Transakcje i dynamiczny wybór narzędzi Skutek błędu Łatwo odwracalny Ograniczony koszt operacyjny Istotny skutek finansowy, prawny lub wizerunkowy Skutek krytyczny, nieodwracalny lub dotyczący praw i bezpieczeństwa Wymagania dotyczące infrastruktury i danych Zarządzana chmura spełnia wymagania Wymagany region lub określona retencja Prywatna sieć albo ścisły limit opóźnienia Praca offline, w środowisku odizolowanym od sieci, na edge lub bezpośrednio na urządzeniu Wyniki można czytać w następujący sposób: Złożoność semantyczna 0-1 i stabilne reguły: kod, workflow, RPA albo klasyczne ML. Złożoność 2-3, integracja 0-1 i skutek błędu 0-1: firmowy asystent LLM z kontrolą użytkownika. Złożoność 2-3 oraz integracja 2-3: zintegrowana aplikacja LLM, RAG lub agent. Złożoność 1-2, wąska domena i presja infrastrukturalna 2-3: SLM jako rozwiązanie do uwzględnienia w testach porównawczych. Skutek błędu 2-3: zatwierdzenie przez uprawnioną osobę, zabezpieczenia oparte na z góry ustalonych regułach i pełny rejestr działań, niezależnie od klasy modelu. Tabela pomaga wybrać rozwiązania do pilotażu. Ostateczną decyzję podejmuje się po porównaniu ich wyników na tym samym zbiorze rzeczywistych przypadków. 8. ChatGPT, zintegrowany LLM, SLM i automatyzacja: przykłady zastosowań w firmie Przykładowy proces Rekomendowana architektura Najważniejszy KPI Kontrola człowieka Pierwsza wersja treści marketingowej Firmowy asystent LLM Mediana oszczędności czasu i odsetek zaakceptowanych wyników Akceptacja każdej publikacji Podsumowanie spotkania i lista działań Firmowy asystent z dostępem do zatwierdzonego źródła Kompletność zadań i liczba korekt Weryfikacja właścicieli i terminów Odpowiedzi na pytania o procedury wewnętrzne Zintegrowany LLM z RAG i cytowaniem źródeł Odsetek odpowiedzi opartych na źródłach i poprawność odwołań do źródeł Eskalacja przy braku źródła Klasyfikacja zgłoszeń do stałych kolejek SLM lub klasyfikator, LLM dla wyjątków Macro-F1 i odsetek wykrytych zgłoszeń priorytetowych Weryfikacja przypadków budzących wątpliwości Analiza umów według firmowej listy ryzyk Zintegrowany LLM z RAG, regułami i logami Odsetek wykrytych oraz przeoczonych klauzul ryzykownych Decyzja prawnika Ekstrakcja pól z jednego typu faktury OCR, klasyczne ML lub SLM oraz walidator reguł Dokładność na poziomie pola i koszt przetworzenia dokumentu Kontrola wyjątków Przygotowanie oferty na podstawie CRM i cennika Zintegrowany LLM, RAG i pobieranie cen według z góry ustalonych reguł Czas przygotowania i odsetek korekt handlowych Akceptacja ceny i warunków Sprawdzenie prawa do zwrotu Reguły procesu Zgodność z polityką i czas decyzji Obsługa wyjątków Wykonanie zwrotu pieniędzy Workflow transakcyjny i autoryzacja 100% zgodności księgowej i pełny audyt Zależna od kwoty i ryzyka Lokalna analiza komunikatów maszyny SLM lub model specjalistyczny na edge Czas odpowiedzi p95, odsetek wykrytych alarmów i dostępność bez połączenia z internetem Eskalacja alarmów krytycznych Odebranie dostępu odchodzącemu pracownikowi IAM i deterministyczny workflow Kompletność odebranych uprawnień Zatwierdzenie według polityki Wieloetapowa obsługa sprawy klienta Agent AI z ograniczonym zestawem narzędzi Skuteczność realizacji zadań, poprawność użycia narzędzi i odsetek spraw przekazanych pracownikowi Punkty zatwierdzenia dla działań o wysokim wpływie 9. Jak mierzyć efekty wdrożenia AI? Wskaźniki jakości, czasu i kosztów Pomiar zaczyna się od obecnego procesu. Badanie Generative AI at Work, obejmujące 5 179 pracowników obsługi klienta, wykazało średni wzrost liczby rozwiązanych spraw na godzinę o 14%. Największą poprawę odnotowano u osób mniej doświadczonych. Tak zdefiniowana produktywność ma jasny licznik, mianownik i grupę odniesienia. Podobnej precyzji potrzebuje firmowy pilotaż. Obszar Wskaźnik Sposób pomiaru Skala Wolumen spraw Liczba przypadków miesięcznie, sezonowość i okresy największego obciążenia Czas Czas obsługi sprawy Średnia, mediana i p90 przed wdrożeniem oraz po nim Jakość Task success rate Odsetek przypadków spełniających wszystkie kryteria poprawnego wykonania zadania Użyteczność Odsetek wyników przyjętych bez zmian merytorycznych Odsetek wyników przyjętych bez zmiany merytorycznej Kontrola Odsetek decyzji AI zmienionych przez pracownika Odsetek decyzji lub propozycji zmienionych przez pracownika Ryzyko Częstotliwość błędów krytycznych Liczba błędów krytycznych na 1 000 lub 10 000 przypadków Klasyfikacja Precyzja, czułość i miara F1 Osobno dla każdej ważnej klasy, zwłaszcza rzadkich zdarzeń RAG Zgodność odpowiedzi ze źródłami Odsetek twierdzeń wspartych wskazanym, aktualnym źródłem Agent Poprawność wyboru narzędzi i przekazywanych parametrów Poprawny wybór narzędzia oraz poprawność przekazanych parametrów Automatyzacja Odsetek spraw obsłużonych w pełni automatycznie Odsetek spraw zakończonych bez ręcznej interwencji Wydajność Czas od rozpoczęcia zadania do uzyskania ostatecznego wyniku p50 i p95 od rozpoczęcia do ostatecznego wyniku Ekonomia Koszt poprawnie zakończonego zadania Pełny koszt podzielony przez liczbę poprawnych rezultatów Stabilność Zmiany jakości działania systemu w czasie Zmiana jakości według czasu, języka, kategorii i typu użytkownika Google Cloud wskazuje koszt poprawnie zakończonego zadania jako kluczowy miernik agentów AI działających w rzeczywistych procesach biznesowych. Model kosztujący 0,10 USD na uruchomienie i osiągający 50% skuteczności generuje sam koszt wywołań na poziomie 0,20 USD na poprawny wynik. Do rachunku dochodzą weryfikacja przez pracownika, ponowne próby, integracje, monitoring oraz koszt błędów. 10. Jak obliczyć ROI wdrożenia LLM lub SLM? Pełny koszt rozwiązania powinien obejmować budowę i integrację, model lub API, infrastrukturę, monitoring, aktualizacje, weryfikacja przez pracownika, poprawki oraz oczekiwaną stratę wynikającą z błędów. Koszt poprawnie zakończonego zadania: C_success = (koszt budowy przypisany do okresu + model/API + infrastruktura + monitoring + kontrola człowieka + poprawki + oczekiwana strata błędów) / liczba poprawnie zakończonych zadań Roczna korzyść: Korzyść = oszczędzony czas pracy + uniknięte poprawki i błędy + dodatkowa marża + uniknięte kary SLA ROI: ROI = (Korzyść – TCO rozwiązania AI) / TCO rozwiązania AI × 100% Załóżmy, że zespół klasyfikuje 20 000 zgłoszeń miesięcznie. Jedno zgłoszenie zajmuje średnio 4 minuty, a pełny koszt godziny pracy wynosi 120 zł. Miesięczny koszt ręcznej klasyfikacji wynosi około 160 000 zł. W pilotażu system osiąga 88% wyników zaakceptowanych bez korekty, weryfikacja jednego wyniku trwa średnio 45 sekund, poprawa pozostałych przypadków zajmuje 3 minuty, a miesięczne koszty modelu, infrastruktury, utrzymania i amortyzowanego wdrożenia wynoszą 51 000 zł. przegląd wszystkich przypadków: około 30 000 zł, poprawa 12% przypadków: około 14 400 zł, model, infrastruktura, utrzymanie i wdrożenie: 51 000 zł, łączny koszt procesu po wdrożeniu: około 95 400 zł, miesięczna różnica kosztu: około 64 600 zł, czyli 40,4%. To przykład metodologiczny z założonymi wartościami. W analizie opłacalności rzeczywistego wdrożenia trzeba uwzględnić zmianę kosztu błędów, sezonowość, czas przestojów, koszt obsługi wyjątków oraz tempo, w jakim pracownicy zaczynają korzystać z rozwiązania. Dla procesu generującego przychód rachunek powinien uwzględniać również zmianę marży, współczynnika konwersji albo wskaźnika utrzymania klientów 11. Jak przeprowadzić mierzalny pilotaż LLM lub SLM? Zapisz punkt odniesienia. Zmierz wolumen, czas, jakość, błędy, eskalacje i koszt obecnej metody przez co najmniej jeden pełny cykl biznesowy. Przygotuj zestaw przypadków testowych. Uwzględnij typowe zadania, trudne i rzadkie sytuacje, przypadki na granicy dopuszczalnych warunków oraz próby celowego wprowadzenia systemu w błąd. Google Cloud zaleca własny zbiór odzwierciedlający pełne spektrum użycia. Ustal progi przed testem. Zapisz minimalną jakość, maksymalny koszt, dopuszczalną latencję, limit błędów krytycznych i zasady eskalacji. Porównaj kilka wariantów. Uwzględnij obecny proces, mocny LLM, mniejszy model oraz architekturę hybrydową. Uruchom system w trybie obserwacyjnym (shadow mode). AI przygotowuje wyniki równolegle do dotychczasowego procesu. Decyzje i działania nadal przebiegają według obowiązujących zasad. Pozwala to wykryć błędy przed dopuszczeniem AI do obsługi rzeczywistych operacji. Uruchom system w ograniczonym zakresie. Rozpocznij od propozycji i zatwierdzeń. Zakres automatycznych działań rozszerzaj na podstawie wyników. Monitoruj jakość działania. Ponawiaj testy po zmianie modelu, instrukcji dla AI, narzędzi, źródeł danych, reguł lub rodzaju przetwarzanych materiałów. 11.1 Ile przypadków testowych potrzeba do oceny LLM lub SLM? Dla wskaźnika wyrażonego jako odsetek, przy poziomie ufności 95% i marginesie błędu +/-5 punktów procentowych, konserwatywna wielkość próby wynosi około 385 niezależnych przypadków. Margines +/-3 punkty procentowe wymaga około 1 068 przypadków. Próba reprezentatywna powinna zostać uzupełniona osobnym zestawem przypadków krytycznych i brzegowych. Przy rzadkich błędach istotna jest tak zwana reguła trzech. Jeżeli w 300 testach nie pojawi się żaden błąd krytyczny, przybliżona górna granica jego rzeczywistego prawdopodobieństwa na poziomie ufności 95% nadal wynosi około 1%. Zero błędów w 3 000 testów obniża tę granicę do około 0,1%. W procesach wysokiego ryzyka potrzebne są więc znacznie większe zbiory oraz testy ukierunkowane na konkretne zagrożenia. 11.2 Kiedy zakończyć pilotaż AI i uruchomić system w firmie? Przykładowe kryteria Proces Przykładowe kryteria przejścia do produkcji odsetek przypisań zmienionych przez pracownika do 8% Macro-F1 co najmniej 0,90; recall zgłoszeń priorytetowych co najmniej 0,99; override rate do 8%; p95 do 2 sekund Wewnętrzna baza wiedzy Acceptance rate co najmniej 85%; poprawność cytowań co najmniej 98%; brak niepopartych twierdzeń w zestawie krytycznym; p95 do 8 sekund Projekt oferty Mediana czasu niższa o co najmniej 30%; co najmniej 75% materiałów przyjętych z drobnymi zmianami; 100% cen pobranych z autoryzowanego źródła; zatwierdzenie człowieka dla każdej oferty Podane wartości są przykładem konstrukcji kryteriów. Właściciel procesu ustala progi zgodnie z kosztem błędu, wymaganą jakością i tolerancją ryzyka organizacji. 12. Jak dobrać zakres nadzoru człowieka do ryzyka związanego z AI? NIST definiuje ryzyko jako połączenie prawdopodobieństwa zdarzenia i skali jego konsekwencji. Ta zasada pozwala przełożyć ogólne obawy związane z AI na mierzalny model: częstotliwość błędów, wartość środków lub zasobów narażonych na stratę, możliwość cofnięcia działania, czas wykrycia błędu i koszt jego naprawy W skonsolidowanym tekście unijnego AI Act wymagania dla systemów wysokiego ryzyka obejmują ciągłe zarządzanie ryzykiem, odpowiedni poziom dokładności, odporności i cyberbezpieczeństwa oraz skuteczny nadzór człowieka. Środki nadzoru mają być proporcjonalne do ryzyka, poziomu autonomii i kontekstu użycia. Testy powinny korzystać z uprzednio zdefiniowanych metryk i progów właściwych dla zamierzonego zastosowania. W praktyce biznesowej oznacza to przypisanie konkretnej osoby do zatwierdzania, monitorowania i reagowania. Interfejs powinien pokazywać źródła, wykonane działania i poziom niepewności, a użytkownik musi mieć możliwość zatrzymania procesu. Ryzyko poważnych konsekwencji błędu uzasadnia ograniczenie uprawnień modelu, dodatkowe sprawdzanie wyników i dłuższe testy w trybie obserwacyjnym. Klasyfikację regulacyjną należy ustalić osobno dla zamierzonego zastosowania i roli organizacji. 13. Jak połączyć LLM, SLM i reguły w jednym procesie biznesowym? Połączenie kilku technologii pozwala dopasować sposób obsługi do poszczególnych etapów procesu. Przykładowo SLM rozpoznaje temat zgłoszenia klienta, a LLM przygotowuje odpowiedź na podstawie historii kontaktu i dokumentów pobranych przez RAG. Gdy sprawa dotyczy zwrotu pieniędzy, system sprawdza warunki i limity zgodnie z ustalonymi regułami, a następnie kieruje operację do realizacji lub zatwierdzenia przez uprawnionego pracownika. Tak zaprojektowana obsługa łączy automatyzację z kontrolą decyzji mających skutki finansowe. W TTMS pomożemy Ci ocenić, gdzie podobne rozwiązanie przyniesie największą korzyść. Zaczniemy od zadań, które pochłaniają najwięcej czasu: powtarzalnych czynności, wyszukiwania informacji czy poprawiania błędów. Podczas konsultacji przeanalizujemy przebieg pracy, dostępne dane i wykorzystywane systemy. Na tej podstawie zaproponujemy technologię i zakres pilotażu, a wspólnie z Tobą ustalimy oczekiwane efekty oraz sposób pomiaru jakości, czasu i kosztów. Chcesz wybrać pierwszy proces do usprawnienia? Umów się z nami na konsultację dotyczącą wdrożenia AI. Źródła Eurostat, 20% of EU enterprises use AI technologies, 11 grudnia 2025. Fabrizio Dell’Acqua et al., Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of Artificial Intelligence on Knowledge Worker Productivity and Quality, Organization Science. Erik Brynjolfsson, Danielle Li, Lindsey Raymond, Generative AI at Work, NBER Working Paper 31161, 2023. Joel Becker, Nate Rush, Beth Barnes, David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR, 10 lipca 2025. Microsoft Azure, What Are Small Language Models (SLMs)?. Microsoft Azure, Boost processing performance by combining AI models, 8 stycznia 2025. OpenAI, Enterprise privacy at OpenAI. Google Cloud, The KPIs that actually matter for production AI agents, 26 lutego 2026. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, lipiec 2024. Unia Europejska, Rozporządzenie (UE) 2024/1689, tekst skonsolidowany z 27 lipca 2026. OWASP GenAI Security Project, LLM06:2025 Excessive Agency, 2025. FAQ Czy do pracy na danych firmowych trzeba uruchamiać własny model AI? Własny model jest jednym z dostępnych wariantów. Firmy mogą korzystać z zatwierdzonego środowiska biznesowego, zarządzanego API, prywatnej chmury, wydzielonej infrastruktury lub modelu działającego lokalnie. Wybór zależy od klasy danych, lokalizacji przetwarzania, retencji, szyfrowania, tożsamości użytkowników, wymogów branżowych i umowy z dostawcą. Przykładowo OpenAI deklaruje brak domyślnego trenowania na danych klientów biznesowych i oferuje dodatkowe mechanizmy kontroli retencji dla kwalifikujących się klientów API. Organizacja powinna udokumentować przepływ danych dla konkretnej konfiguracji, ponieważ nazwa modelu nie opisuje całej architektury bezpieczeństwa. Czy RAG może zastąpić fine-tuning modelu na danych firmy? RAG i fine-tuning rozwiązują różne problemy. RAG pobiera aktualne informacje z kontrolowanego źródła w momencie tworzenia odpowiedzi, dzięki czemu dobrze pasuje do baz wiedzy, procedur, dokumentacji i treści często aktualizowanych. Fine-tuning dostosowuje zachowanie modelu do przykładów, stylu, formatu albo wyspecjalizowanego zadania. Dokumentacja AWS porównująca RAG i fine-tuning rekomenduje rozpoczęcie systemu pytań i odpowiedzi na własnych dokumentach od RAG, zwłaszcza gdy ważne są aktualność i odwołania do źródeł. Oba mechanizmy mogą działać razem, jeśli proces wymaga zarówno aktualnej wiedzy, jak i stabilnego zachowania domenowego. Czy jeden proces może korzystać jednocześnie z LLM i SLM? Tak. Router może kierować typowe, dobrze rozpoznane sprawy do SLM, a przypadki złożone do większego LLM. Trzecia ścieżka prowadzi do człowieka, gdy system wykryje brak danych, niską pewność albo wysoki poziom ryzyka. Innym wariantem jest podział procesu według funkcji: SLM klasyfikuje dokument, LLM przygotowuje wyjaśnienie, kod oblicza wartości, a workflow zapisuje zatwierdzoną decyzję. Taki układ pozwala kontrolować koszty i czas reakcji przy zachowaniu dostępu do większych możliwości w trudniejszych sprawach. Ile przykładów potrzeba do pilotażu LLM lub SLM? Liczba zależy od oczekiwanej precyzji pomiaru i rzadkości błędów. Dla odsetka skutecznych odpowiedzi próba około 385 niezależnych przypadków daje przybliżony margines +/-5 punktów procentowych przy poziomie ufności 95% w wariancie konserwatywnym. Margines +/-3 punkty wymaga około 1 068 przypadków. Losowa próba powinna odzwierciedlać rzeczywisty wolumen, języki, kanały i typy użytkowników. Osobny zestaw powinien obejmować przypadki krytyczne, brzegowe, rzadkie oraz próby manipulacji systemem. Jak często trzeba ponownie testować aplikację opartą na modelu językowym? Pełna ewaluacja powinna zostać uruchomiona po zmianie modelu, wersji promptu, narzędzia, uprawnień, źródła danych, reguł biznesowych lub formatu wejścia. Produkcja wymaga również ciągłego monitorowania najważniejszych KPI oraz cyklicznego testu regresji. Częstotliwość zależy od ryzyka i tempa zmian procesu. Aplikacja obsługująca treści marketingowe może mieć inny harmonogram niż system wspierający decyzje finansowe. Praktycznym rozwiązaniem jest automatyczny test przy każdej zmianie technicznej, miesięczny przegląd trendów oraz kwartalna ewaluacja biznesowa, z krótszym cyklem dla zastosowań wysokiego ryzyka.

    Czytaj więcej
    Jak przygotować dane do Copilota w Power BI i zbudować model semantyczny gotowy na AI

    Jak przygotować dane do Copilota w Power BI i zbudować model semantyczny gotowy na AI

    Copilot może przyspieszyć analizę danych, tworzenie wizualizacji i pracę z modelem semantycznym. Nie zastępuje jednak uporządkowanych źródeł, prawidłowych relacji ani uzgodnionych definicji wskaźników. Jeżeli model zawiera kilka podobnych miar sprzedaży, techniczne nazwy kolumn i niejednoznaczne relacje, asystent AI otrzymuje ten sam problem, z którym wcześniej mierzyli się użytkownicy raportów. Różnica polega na tym, że odpowiedź wygenerowana w naturalnym języku może brzmieć przekonująco nawet wtedy, gdy została oparta na niewłaściwej metryce. Dlatego przygotowanie danych do Copilota w Power BI powinno być traktowane jako praca nad jakością modelu, kontekstem biznesowym i zasadami korzystania z danych. Samo udostępnienie funkcji Copilot nie sprawi, że niespójny model stanie się jednoznaczny. Potrzebne są czytelne nazwy, zweryfikowane miary, kontrolowany zakres danych, odpowiednie uprawnienia oraz zestaw testów odpowiadających rzeczywistym pytaniom użytkowników. W tym artykule wyjaśniamy, jak przygotować dane i model semantyczny Power BI do pracy z Copilotem, jak korzystać z funkcji Prep data for AI oraz jak ocenić gotowość rozwiązania przed udostępnieniem go pracownikom. Materiał koncentruje się na wdrożeniu i utrzymaniu jakości. Ogólne możliwości asystenta opisuje odrębny artykuł TTMS poświęcony AI i Copilotowi w Power BI. 1. Power BI gotowy na AI Model gotowy na AI pozwala użytkownikowi zadawać pytania w języku biznesowym bez konieczności znajomości technicznych nazw tabel i kolumn. Nie oznacza to, że Copilot zna organizację lub sam odkryje wszystkie reguły obowiązujące w firmie. Potrafi korzystać z informacji udostępnionych przez model, jego metadane, konfigurację funkcji AI oraz kontekst raportu. Jakość tej warstwy wpływa na to, czy pytanie o „sprzedaż” zostanie powiązane z oficjalną miarą przychodu netto, wartością zamówień czy innym polem o podobnej nazwie. Gotowość modelu należy oceniać w pięciu obszarach: jakość i aktualność danych źródłowych; poprawność oraz prostota modelu semantycznego; jednoznaczność pojęć, nazw i miar biznesowych; bezpieczeństwo, uprawnienia i odpowiedzialność za dane; powtarzalny proces testowania odpowiedzi Copilota. Jeżeli któryś z tych obszarów nie został przygotowany, samo dopracowywanie promptów przyniesie ograniczony efekt. Użytkownik może dokładniej sformułować pytanie, ale nadal nie wie, która z trzech miar marży jest oficjalna ani dlaczego jedna tabela używa daty zamówienia, a inna daty faktury. 2. Dlaczego model semantyczny decyduje o jakości odpowiedzi Model semantyczny stanowi warstwę pomiędzy danymi źródłowymi a użytkownikiem raportu. Zawiera tabele, kolumny, miary, relacje, formaty, hierarchie i reguły bezpieczeństwa. Dla Copilota jest podstawowym źródłem informacji o tym, jak dane są zorganizowane i jak należy je interpretować. Asystent może wykorzystać między innymi schemat modelu, relacje, właściwości obiektów, typy danych, formaty oraz wybrane metadane. Nie powinien jednak zgadywać definicji, które w organizacji mają szczególne znaczenie. Jeżeli „aktywny klient” oznacza klienta, który dokonał zakupu w ciągu ostatnich 90 dni, definicja powinna być zapisana w modelu i używana przez oficjalną miarę. Pozostawienie kilku możliwych interpretacji zwiększa ryzyko wyboru niewłaściwej. 2.1 Przykład niejednoznacznego modelu Załóżmy, że w modelu znajdują się miary „Sales”, „Total Sales”, „Net Sales” i „Sales Adjusted”. Dla analityka, który zna projekt, różnice mogą być oczywiste. Użytkownik biznesowy i Copilot widzą natomiast cztery prawdopodobne odpowiedzi na pytanie „Jaka była sprzedaż w ubiegłym kwartale?”. Naprawa nie polega jedynie na dopisaniu instrukcji, że Copilot ma wybierać jedną z miar. Najpierw warto ustalić oficjalną definicję, nadać jej czytelną nazwę, opisać sposób liczenia, ukryć pola techniczne i usunąć nieużywane obiekty. Instrukcja AI może następnie doprecyzować kontekst, ale nie powinna zastępować porządku w modelu. 3. Wymagania techniczne przed rozpoczęciem pracy Przed przebudową modelu należy sprawdzić, czy środowisko spełnia aktualne wymagania Microsoftu. Dostępność Copilota zależy od ustawień dzierżawy, uprawnień, obszaru roboczego oraz przypisanej pojemności. Wymagania mogą różnić się między Power BI Desktop, usługą Power BI i poszczególnymi doświadczeniami Copilot. Na dzień przygotowania artykułu dokumentacja Microsoft dotycząca wymagań Copilota w Power BI wskazuje między innymi na potrzebę włączenia odpowiedniego ustawienia dzierżawy oraz korzystania z obsługiwanej płatnej pojemności Fabric albo Power BI Premium. Autor modelu potrzebuje również właściwych uprawnień do obszaru roboczego i modelu semantycznego. Prep data for AI jest obecnie funkcją w wersji zapoznawczej. Przed jej wdrożeniem trzeba uwzględnić aktualne ograniczenia, w tym wymaganie włączenia Power BI Q&A oraz obsługiwane typy połączeń w Power BI Desktop. Obszar Co trzeba sprawdzić Dlaczego ma to znaczenie Pojemność Czy obszar roboczy korzysta z obsługiwanej płatnej pojemności Fabric lub Power BI Premium Bez właściwej pojemności wybrane doświadczenia Copilot mogą być niedostępne Ustawienia dzierżawy Czy administrator włączył korzystanie z Copilota i funkcji opartych na Azure OpenAI dla odpowiednich grup Dostęp powinien być nadany świadomie i zgodnie z polityką organizacji Uprawnienia Czy autor ma prawa do edycji modelu i publikacji w docelowym obszarze roboczym Konfiguracja modelu wymaga uprawnień odpowiednich dla danego środowiska Typ połączenia Czy sposób połączenia jest obsługiwany przez używaną funkcję w Desktop lub usłudze Zakres obsługi różni się między narzędziami i może się zmieniać Power BI Q&A Czy funkcja Q&A jest włączona dla modelu Jest to obecnie jedno z wymagań funkcji Prep data for AI Wymagań licencyjnych i funkcjonalnych nie należy utrwalać w wewnętrznej instrukcji raz na zawsze. Microsoft rozwija Copilota i zmienia dostępność poszczególnych doświadczeń. Przed wdrożeniem warto sprawdzić aktualną dokumentację oraz ustawienia własnej dzierżawy. 4. Przygotowanie danych do Copilota w Power BI Dane powinny być wiarygodne jeszcze przed załadowaniem ich do modelu. Copilot nie naprawi brakujących rekordów, błędnego mapowania klientów ani niespójnych kodów walut. Może natomiast wykorzystać te dane do wygenerowania odpowiedzi, która ukryje problem pod poprawnie brzmiącym opisem. 4.1 Jakość danych źródłowych Pierwszy etap obejmuje profilowanie i kontrolę danych. Należy sprawdzić kompletność, unikalność, spójność, aktualność i zgodność wartości z regułami biznesowymi. Kontrole powinny być powtarzalne, a nie wykonywane wyłącznie przed pierwszą publikacją. W praktyce oznacza to między innymi: identyfikację brakujących kluczy oraz rekordów osieroconych; kontrolę duplikatów w tabelach wymiarów; uzgodnienie stref czasowych, kalendarzy, walut i jednostek; sprawdzenie, czy wartości statusów mają wspólne znaczenie we wszystkich systemach; określenie właściciela danych i sposobu obsługi błędów jakościowych; monitorowanie świeżości danych oraz nieudanych odświeżeń. Każda oficjalna metryka powinna mieć określone źródło, właściciela, częstotliwość aktualizacji i regułę obliczeniową. Dzięki temu odpowiedź Copilota można porównać z wartością referencyjną, zamiast oceniać ją wyłącznie na podstawie tego, czy brzmi logicznie. 4.2 Przyjazne nazwy i stabilne definicje Nazwy techniczne, takie jak „fct_sales_hdr”, „cust_id” czy „rev_net_adj”, zwiększają koszt korzystania z modelu przez człowieka i utrudniają interpretację intencji pytania. W warstwie semantycznej warto stosować nazwy odpowiadające językowi organizacji, na przykład „Sprzedaż”, „Klient”, „Przychód netto” i „Region sprzedaży”. Sama czytelność nie wystarcza. Nazwa „Marża” nadal jest niejednoznaczna, jeżeli firma używa marży kwotowej, procentowej, planowanej i skorygowanej. Każda z tych miar powinna mieć precyzyjną nazwę i definicję. Jeżeli jedna miara ma status oficjalnej, model powinien to odzwierciedlać przez nazewnictwo, opis, organizację folderów oraz ograniczenie widoczności pól pomocniczych. 4.3 Poprawne typy danych i formaty Typ danych informuje model, czy wartość jest datą, liczbą, tekstem lub kategorią. Format wskazuje sposób prezentacji, na przykład walutę, procent albo liczbę dziesiętną. Błędny typ może uniemożliwić prawidłowe grupowanie i obliczenia, a niejednoznaczny format może prowadzić do błędnej interpretacji wyniku przez użytkownika. Warto również wskazać kategorie danych tam, gdzie mają znaczenie, na przykład dla adresów, miast i kodów geograficznych. Model powinien jasno rozróżniać datę zamówienia, wystawienia faktury, wysyłki i płatności. Jedna oznaczona tabela kalendarza oraz jawne miary ograniczają liczbę przypadkowych interpretacji. 5. Model semantyczny zrozumiały dla Copilota Samouczek Microsoft dotyczący przygotowania modelu semantycznego dla AI zaleca między innymi stosowanie schematu gwiazdy, czytelnych nazw i ograniczanie złożoności. Nie oznacza to, że każdy model musi wyglądać identycznie. Chodzi o to, aby relacje, role tabel i definicje miar były jednoznaczne. 5.1 Schemat gwiazdy W schemacie gwiazdy tabele faktów przechowują zdarzenia lub wartości liczbowe, a tabele wymiarów opisują kontekst, taki jak klient, produkt, czas i region. Taka struktura ułatwia użytkownikowi oraz mechanizmom AI odróżnienie tego, co jest mierzone, od sposobu podziału wyniku. Rozbudowany model płatka śniegu, wiele tabel pomocniczych i kilka możliwych ścieżek filtrowania mogą być uzasadnione technicznie, ale zwiększają złożoność interpretacji. Jeżeli nie można uprościć modelu fizycznie, warto ograniczyć zakres udostępniany Copilotowi przez AI data schema. 5.2 Relacje i kierunki filtrowania Relacje powinny odwzorowywać rzeczywistą logikę danych. Należy zweryfikować ich kardynalność, aktywność i kierunek filtrowania. Relacje dwukierunkowe oraz wiele alternatywnych ścieżek mogą prowadzić do nieoczekiwanych wyników, zwłaszcza gdy pytanie nie określa szczegółowego kontekstu. Nieaktywne relacje i specjalne reguły stosowane w wybranych miarach należy dokumentować. Jeżeli analiza sprzedaży według daty wysyłki wymaga innej logiki niż analiza według daty zamówienia, użytkownik powinien wiedzieć, jak sformułować pytanie, a model powinien oferować jednoznaczne miary. 5.3 Jawne miary DAX Jawne miary DAX pozwalają zapisać zatwierdzoną logikę biznesową w jednym miejscu. Są bezpieczniejszą podstawą odpowiedzi niż przypadkowe agregowanie kolumn liczbowych. Miara powinna mieć czytelną nazwę, prawidłowy format, opis i właściciela biznesowego. Przed udostępnieniem modelu Copilotowi warto sprawdzić: czy oficjalne wskaźniki są zdefiniowane jako miary; czy nie występują duplikaty o podobnych nazwach; czy format wyniku odpowiada znaczeniu biznesowemu; czy miary działają prawidłowo dla różnych filtrów i poziomów agregacji; czy pola techniczne oraz miary pomocnicze są ukryte przed użytkownikami; czy wyniki zostały uzgodnione z raportami referencyjnymi. 6. Funkcja Prep data for AI w Power BI Prep data for AI jest zestawem narzędzi zapisujących konfigurację na poziomie modelu semantycznego, a nie pojedynczego raportu. To istotne, ponieważ jeden model może zasilać wiele raportów. Zmiana schematu AI lub instrukcji może więc wpływać na więcej niż jeden scenariusz użycia. Microsoft opisuje cztery elementy przygotowania modelu do przetwarzania języka naturalnego: AI data schema (schemat danych AI), verified answers (zweryfikowane odpowiedzi), AI instructions (instrukcje AI) oraz opisy. Poszczególne elementy nie działają jednak identycznie we wszystkich doświadczeniach Copilot. Dlatego konfigurację trzeba testować w tych samych miejscach, w których będą pracowali użytkownicy. Mechanizm Zastosowanie Kiedy jest szczególnie potrzebny Czego nie zastępuje AI data schema Określa podzbiór tabel, kolumn i miar przekazywany Copilotowi Gdy model jest duży lub zawiera pola techniczne i podobne miary Porządkowania danych oraz poprawnych relacji Verified answers Łączy zatwierdzoną wizualizację z frazami uruchamiającymi Dla częstych lub niejednoznacznych pytań wymagających spójnej interpretacji Testowania danych źródłowych i kontroli dostępu AI instructions Przekazuje reguły, definicje i kontekst biznesowy Gdy organizacja używa pojęć, których znaczenia nie da się wywnioskować z nazw pól Oficjalnych miar i jednoznacznego modelu Opisy Dokumentują znaczenie tabel, kolumn i miar Gdy nazwa obiektu nie wyjaśnia w pełni jego zastosowania Instrukcji obejmujących reguły całej domeny 6.1 AI data schema AI data schema ogranicza część modelu, którą Copilot bierze pod uwagę podczas odpowiadania na pytania o dane. Nie należy automatycznie udostępniać całego schematu. Tabele techniczne, pola kluczy, nieużywane miary i obiekty przeznaczone wyłącznie do obsługi raportu zwiększają liczbę możliwych interpretacji. Dobrze zaprojektowany schemat AI powinien obejmować oficjalne wymiary, zatwierdzone miary i pola potrzebne do najczęstszych analiz. Zakres należy sprawdzić z właścicielami procesów biznesowych. Zbyt wąski schemat uniemożliwi odpowiedź na uzasadnione pytania, a zbyt szeroki może zwiększyć niejednoznaczność. 6.2 Zweryfikowane odpowiedzi Verified answers pozwalają powiązać zatwierdzoną wizualizację z określonymi frazami uruchamiającymi. Mechanizm jest przydatny, gdy użytkownicy często pytają o ten sam wskaźnik lub używają kilku określeń o podobnym znaczeniu. Przykładem może być pytanie o „sprzedaż według obszaru”. Dla jednej organizacji „obszar” oznacza region geograficzny, a dla innej grupę produktową. Zweryfikowana odpowiedź może skierować właściwe sformułowania do wcześniej sprawdzonej wizualizacji. Nie zwalnia to jednak z testowania samej miary, filtrów i uprawnień. Dla każdej zweryfikowanej odpowiedzi warto zapisać właściciela, obsługiwane pytania, źródło metryki i datę ostatniego przeglądu. Zmiana definicji wskaźnika albo struktury raportu powinna uruchamiać ponowną walidację. 6.3 Instrukcje AI AI instructions przekazują Copilotowi kontekst, którego nie da się łatwo wyrazić samą strukturą modelu. Mogą wyjaśniać terminologię organizacji, preferowane miary, reguły interpretacji okresów i powiązania pomiędzy pojęciami. Instrukcja może na przykład wskazywać, że „aktywny klient” oznacza klienta z zakupem w ostatnich 90 dniach, a „sezon wysoki” obejmuje miesiące od czerwca do sierpnia. Powinna używać konkretnych nazw obiektów modelu i krótkich, testowalnych reguł. Instrukcje nie są mechanizmem bezpieczeństwa i nie gwarantują bezwzględnego przestrzegania każdej reguły. Microsoft zaznacza, że model językowy interpretuje je jako wskazówki. Dlatego ważne definicje finansowe i operacyjne należy nadal implementować w miarach, relacjach i procesach zarządzania danymi. 6.4 Opisy tabel kolumn i miar Opisy powinny wyjaśniać znaczenie obiektu, sposób jego użycia oraz istotne ograniczenia. Zamiast „wartość sprzedaży” lepiej zapisać, że miara przedstawia przychód netto po rabatach i zwrotach, w walucie raportowej, według daty faktury. Według aktualnej dokumentacji Microsoftu opisy nie wpływają w jednakowy sposób na wszystkie możliwości Copilota. Są wykorzystywane między innymi w wybranych scenariuszach wyszukiwania i zapytań DAX. Mimo tego warto je uzupełniać, ponieważ poprawiają dokumentację modelu i przygotowują go do dalszego rozwoju funkcji AI. 7. Kontekst biznesowy dla Copilota Model może być technicznie poprawny, a mimo to nie odpowiadać językowi używanemu przez firmę. Dział sprzedaży może mówić o „kliencie aktywnym”, finanse o „przychodzie rozpoznanym”, a operacje o „zamówieniu zamkniętym”. Każde z tych pojęć wymaga definicji oraz właściciela. Dobrym punktem wyjścia jest słownik biznesowy obejmujący: nazwę pojęcia i jego dopuszczalne synonimy; definicję zaakceptowaną przez właściciela biznesowego; odpowiadającą tabelę, kolumnę lub miarę w Power BI; regułę czasu, waluty, zakresu i agregacji; wyjątki oraz przypadki, w których wskaźnika nie należy używać; osobę odpowiedzialną za zatwierdzanie zmian. Słownik nie powinien istnieć wyłącznie poza Power BI. Najważniejsze informacje trzeba przenieść do nazw, opisów, miar, AI instructions i verified answers. W przeciwnym razie użytkownicy i Copilot nadal będą pracowali z niepełnym kontekstem. 8. Bezpieczeństwo i governance danych Udostępnienie Copilota zwiększa łatwość zadawania pytań, ale nie zmienia podstawowej zasady: użytkownik powinien mieć dostęp wyłącznie do danych potrzebnych w jego roli. Należy sprawdzić uprawnienia do obszarów roboczych i modeli, role RLS, zabezpieczenia na poziomie obiektów, grupy Microsoft Entra oraz sposób udostępniania raportów i modeli. Przy projektowaniu kontroli warto odnieść się również do zasad prywatności, bezpieczeństwa i odpowiedzialnego korzystania z Copilota w Microsoft Fabric. Szczególnej uwagi wymagają uprawnienia do zapisu. W Power BI sposób egzekwowania zabezpieczeń na poziomie wiersza zależy między innymi od roli użytkownika i jego uprawnień do modelu. Testy powinny obejmować konta reprezentujące rzeczywiste role, a nie wyłącznie konto autora lub administratora. Warto również sprawdzić, czy nazwy obiektów, opisy i metadane raportu nie ujawniają informacji, których użytkownik nie powinien poznawać. Dokumentacja Microsoftu dotycząca korzystania z Copilota z modelami semantycznymi wskazuje, że w Power BI Desktop metadane bieżącej strony raportu mogą w określonych sytuacjach służyć jako dane ugruntowujące i zawierać wartości danych. Ocena bezpieczeństwa powinna więc obejmować zarówno rekordy, jak i warstwę opisową modelu. Governance powinno określać: kto może przygotowywać model do użycia przez AI; kto zatwierdza definicje i zweryfikowane odpowiedzi; które modele mogą zostać oznaczone jako zatwierdzone dla Copilota; jak często przeprowadza się testy regresji; jak zgłaszane i analizowane są błędne odpowiedzi; kiedy zmiana modelu wymaga ponownego zatwierdzenia. 9. Testowanie odpowiedzi Copilota Test nie powinien polegać na zadaniu jednego przykładowego pytania. Potrzebny jest zestaw scenariuszy odzwierciedlających język i potrzeby użytkowników. Dla każdego pytania należy określić oczekiwaną miarę, zakres filtrów, źródło wartości referencyjnej oraz dopuszczalny sposób prezentacji. Rodzaj testu Przykład Co należy ocenić Pytanie podstawowe Jaka była sprzedaż netto w poprzednim miesiącu Dobór miary, okresu i formatu wartości Synonim Pokaż obrót według regionu Czy język użytkownika został poprawnie powiązany z oficjalnym pojęciem Pytanie niejednoznaczne Pokaż wynik dla obszaru Czy Copilot prosi o doprecyzowanie albo wybiera zatwierdzoną interpretację Filtry złożone Sprzedaż klientów z sektora produkcyjnego w Polsce w ostatnim kwartale Poprawność wszystkich filtrów i relacji Uprawnienia To samo pytanie zadane przez użytkowników z różnych regionów Czy każdy użytkownik widzi wyłącznie dozwolony zakres danych Odporność na zmianę Powtórzenie testów po zmianie miary lub relacji Czy aktualizacja nie pogorszyła wcześniejszych odpowiedzi Ocena powinna obejmować zarówno wynik liczbowy, jak i sposób dojścia do odpowiedzi. W dostępnych doświadczeniach warto korzystać z funkcji diagnostycznych, takich jak informacje o tym, jak Copilot utworzył odpowiedź. Nie należy jednak uznawać samego wyjaśnienia mechanizmu za dowód poprawności wyniku. Ostatecznym punktem odniesienia pozostaje zatwierdzona metryka i kontrolowany zestaw danych. Copilot generuje odpowiedzi niedeterministycznie. To oznacza, że ten sam prompt i te same dane mogą prowadzić do różniących się rezultatów. W niektórych doświadczeniach identyczne pytanie zadane w ciągu 24 godzin przy niezmienionym modelu może jednak zwrócić odpowiedź z pamięci podręcznej. Celem testów nie jest więc udowodnienie, że każda odpowiedź zawsze będzie identyczna. Testy mają wykazać, że model kieruje Copilota do właściwych danych, typowe pytania otrzymują poprawne odpowiedzi, a ryzyka i ograniczenia są znane użytkownikom. 10. Najczęstsze błędy podczas przygotowania Power BI do AI 10.1 Włączenie Copilota przed uporządkowaniem modelu Zespół koncentruje się na licencji i ustawieniach, ale nie przegląda nazw, relacji i miar. Copilot zostaje udostępniony na modelu, który już wcześniej sprawiał trudności analitykom. Efektem są niejednoznaczne odpowiedzi oraz szybka utrata zaufania użytkowników. 10.2 Udostępnienie całego schematu Do AI data schema trafiają wszystkie tabele i pola, w tym klucze techniczne, miary pomocnicze oraz obiekty nieużywane. Większa liczba elementów nie oznacza pełniejszego kontekstu. W rozbudowanym modelu może utrudnić wybór właściwego pola. 10.3 Traktowanie instrukcji AI jako zamiennika modelowania Instrukcje próbują wyjaśnić dziesiątki wyjątków, które powinny zostać zapisane w miarach i regułach modelu. Taki dokument jest trudny do testowania i utrzymania. Im ważniejsza reguła, tym bardziej powinna być egzekwowana przez model lub proces danych, a nie jedynie opisana językiem naturalnym. 10.4 Brak właścicieli metryk Analitycy przygotowują verified answers bez formalnego potwierdzenia, która definicja wskaźnika jest obowiązująca. W razie rozbieżności nie wiadomo, kto może zaakceptować zmianę ani jaka wartość stanowi punkt odniesienia. 10.5 Testowanie wyłącznie przez autorów Autor modelu zna nazwy i strukturę danych, dlatego formułuje pytania w sposób zgodny z projektem. Użytkownicy biznesowi używają skrótów, synonimów i niepełnych określeń. Testy powinny obejmować rzeczywiste pytania zebrane od przyszłych użytkowników. 10.6 Brak testów po zmianach Zmiana definicji miary, relacji, nazwy pola lub raportu może wpłynąć na wcześniejsze scenariusze. Bez testów regresji organizacja nie wie, czy model nadal jest gotowy do użycia przez Copilota. 11. Checklista gotowości modelu Power BI do Copilota [ ] Zidentyfikowaliśmy właścicieli danych, modeli i kluczowych metryk. [ ] Dane źródłowe przechodzą powtarzalne kontrole jakości i świeżości. [ ] Oficjalne wskaźniki mają jednoznaczne definicje oraz jawne miary DAX. [ ] Nazwy tabel, kolumn i miar odpowiadają językowi biznesowemu. [ ] Pola techniczne, nieużywane i pomocnicze są ukryte lub usunięte z zakresu AI. [ ] Typy danych, formaty, kategorie oraz tabela kalendarza są poprawnie skonfigurowane. [ ] Relacje mają właściwą kardynalność i nie tworzą niejednoznacznych ścieżek filtrowania. [ ] Zdefiniowaliśmy AI data schema obejmujący wyłącznie potrzebne obiekty. [ ] Najczęstsze i najbardziej niejednoznaczne pytania mają zweryfikowane odpowiedzi. [ ] AI instructions opisują terminologię i reguły, których nie da się odczytać ze struktury modelu. [ ] Tabele, kolumny i miary posiadają przydatne opisy. [ ] Zweryfikowaliśmy ustawienia dzierżawy, pojemność, licencje i aktualne ograniczenia funkcji. [ ] Przetestowaliśmy role RLS, uprawnienia i dostęp do modeli na kontach użytkowników testowych. [ ] Zestaw testów obejmuje pytania podstawowe, synonimy, niejednoznaczności i złożone filtry. [ ] Wyniki Copilota są porównywane z zatwierdzonymi raportami lub wartościami referencyjnymi. [ ] Określiliśmy proces zgłaszania błędnych odpowiedzi i ponownej walidacji modelu. [ ] Jeśli organizacja korzysta z dostępnego obecnie w wersji zapoznawczej ustawienia Approved for Copilot, model jest oznaczany dopiero po zakończeniu testów. 12. Jak przygotować organizację do korzystania z Copilota Gotowy model nie wystarczy, jeżeli użytkownicy nie wiedzą, jak interpretować odpowiedzi. Wdrożenie powinno obejmować krótkie szkolenie, przykładowe pytania, wyjaśnienie zakresu danych i zasady weryfikacji wyników. Należy jasno wskazać, które scenariusze mają charakter wspierający, a które wymagają kontroli analityka lub właściciela procesu. Dobrym rozwiązaniem jest pilotaż na jednym modelu o dobrze zdefiniowanym zakresie. Pozwala zebrać pytania użytkowników, ocenić niejednoznaczności i zbudować zestaw testów przed rozszerzeniem funkcji na kolejne obszary. Pilotaż powinien mieć kryteria zakończenia, na przykład poprawność najważniejszych scenariuszy, akceptację właścicieli metryk i brak krytycznych problemów z uprawnieniami. Po uruchomieniu warto monitorować wykorzystanie, koszt pojemności, zgłoszenia użytkowników oraz zmiany w dokumentacji Microsoftu. Gotowość modelu do pracy z AI wymaga stałego monitorowania i ponownych testów po istotnych zmianach. 13. Dlaczego TTMS Przygotowanie Power BI do pracy z Copilotem wymaga połączenia kompetencji z zakresu integracji danych, modelowania semantycznego, Power BI, Microsoft Fabric, bezpieczeństwa i adopcji użytkowników. Skupienie się wyłącznie na interfejsie Copilota nie rozwiązuje problemów znajdujących się w źródłach, transformacjach i definicjach biznesowych. Zakres współpracy z TTMS może obejmować ocenę gotowości istniejących modeli, uporządkowanie warstwy danych, przebudowę relacji i miar oraz przygotowanie testów. Konfigurację Prep data for AI warto poprzedzić potwierdzeniem wymagań środowiska i uzgodnieniem zakresu prac. Współpraca może dotyczyć pojedynczego modelu pilotażowego albo programu obejmującego wiele domen i zespołów. Praktyczny model współpracy może obejmować: Inwentaryzację źródeł, modeli, raportów i grup użytkowników. Ocenę jakości danych, architektury modelu oraz ryzyka niejednoznacznych odpowiedzi. Uzgodnienie oficjalnych wskaźników i słownika pojęć biznesowych. Optymalizację modelu semantycznego oraz konfigurację AI data schema, verified answers i AI instructions. Testy funkcjonalne, regresyjne, bezpieczeństwa i wydajności. Przygotowanie zasad governance, dokumentacji oraz materiałów dla użytkowników. Utrzymanie modeli i ponowną walidację po zmianach danych lub funkcji Microsoftu. Rezultatem powinien być model, którego struktura jest czytelna dla analityków i użytkowników biznesowych, a odpowiedzi Copilota można oceniać względem zatwierdzonych definicji. Celem jest ograniczenie niejednoznaczności i wprowadzenie procesu kontroli jakości. Nawet dobrze przygotowany model nie gwarantuje bezbłędnych odpowiedzi generatywnej AI. 14. Rozmowa o gotowości Power BI do AI Jeżeli Twoja organizacja korzysta z Power BI i planuje udostępnić Copilota, warto rozpocząć od przeglądu danych oraz modeli semantycznych. TTMS może pomóc określić zakres pilotażu, wskazać luki i przygotować roadmapę prac od źródeł danych do testów użytkowników. Skontaktuj się z TTMS, aby omówić przygotowanie środowiska Power BI i Microsoft Fabric do bezpiecznego wykorzystania funkcji AI. 15. FAQ Kto powinien być właścicielem modelu semantycznego przygotowanego dla Copilota? Model semantyczny powinien mieć jasno określonych właścicieli odpowiedzialnych za jakość danych, definicje wskaźników biznesowych oraz utrzymanie modelu. Dzięki temu zmiany w danych, procesach i raportowaniu mogą być kontrolowane, a odpowiedzi Copilota pozostają zgodne z aktualnymi definicjami biznesowymi. Jak duży powinien być AI data schema w Power BI? AI data schema powinien obejmować wyłącznie te tabele, kolumny i miary, które są potrzebne do realizacji najczęściej zadawanych pytań biznesowych. Zbyt szeroki zakres zwiększa ryzyko niejednoznacznych odpowiedzi, natomiast zbyt wąski może ograniczyć możliwości Copilota i uniemożliwić analizę części danych. Czy Copilot może rozumieć pojęcia biznesowe, których nie ma bezpośrednio w modelu danych? Tak, częściowo. Kontekst można przekazywać za pomocą opisów, AI instructions, verified answers i odpowiednio nazwanych miar. Najważniejsze pojęcia biznesowe powinny jednak być odwzorowane bezpośrednio w modelu semantycznym, ponieważ zwiększa to dokładność interpretacji i zmniejsza ryzyko błędnych odpowiedzi. Kiedy należy ponownie zweryfikować model Power BI pod kątem Copilota? Model warto ponownie zweryfikować po każdej istotnej zmianie dotyczącej źródeł danych, definicji KPI, relacji, uprawnień, konfiguracji AI lub funkcji Microsoft Copilot. Regularne testy regresji pomagają potwierdzić, że wcześniej poprawne scenariusze nadal działają zgodnie z oczekiwaniami. Czy użytkownicy powinni bezwarunkowo ufać odpowiedziom Copilota? Nie. Odpowiedzi Copilota należy traktować jako wsparcie procesu podejmowania decyzji, a nie jako jedyne źródło prawdy. Kluczowe decyzje biznesowe powinny być weryfikowane w oparciu o zatwierdzone miary, raporty referencyjne oraz procedury governance obowiązujące w organizacji.

    Czytaj więcej
    Wiktor Janicki

    Transition Technologies MS świadczy usługi informatyczne terminowo, o wysokiej jakości i zgodnie z podpisaną umową. Polecamy firmę TTMS jako godnego zaufania i rzetelnego dostawcę usług IT oraz partnera wdrożeniowego Salesforce.

    Czytaj więcej
    Julien Guillot Schneider Electric

    TTMS od lat pomaga nam w zakresie konfiguracji i zarządzania urządzeniami zabezpieczającymi z wykorzystaniem różnych technologii. Ueługi świadczone przez TTMS są realizowane terminowo, i zgodnie z umową.

    Czytaj więcej

    Już dziś możemy pomóc Ci rosnąć

    Porozmawiajmy, jak możemy wesprzeć Twój biznes

    TTMC Contact person
    Monika Radomska

    Sales Manager