Copilot Studio – jak budować agentów AI wykorzystujących firmową bazę wiedzy

Wprowadzenie: agenci w Copilot Studio i rola firmowej bazy wiedzy

Pracownik pytający o zasady rozliczenia delegacji zwykle nie potrzebuje listy dokumentów. Potrzebuje odpowiedzi: jakie wydatki może rozliczyć, co musi dołączyć i do kiedy powinien złożyć wniosek. Agent AI zbudowany w Microsoft Copilot Studio może pomóc przejść od szukania informacji w firmowych zasobach do rozmowy o konkretnej sprawie. Warunkiem jest jednak dostęp do wiedzy, która rzeczywiście opisuje zasady obowiązujące w organizacji.

Copilot Studio to platforma low-code służąca do tworzenia i rozwijania agentów AI — rozwiązań, które mogą odpowiadać na pytania, prowadzić użytkownika przez określony proces oraz, po odpowiednim skonfigurowaniu, wykonywać działania w połączonych systemach. Podejście low-code ogranicza potrzebę programowania, ale nie zastępuje decyzji projektowych: trzeba ustalić, komu agent ma pomagać, jakie zadania obsługiwać i na jakich informacjach się opierać.

W porównaniu z klasycznym chatbotem opartym na z góry ustalonych ścieżkach rozmowy agent może elastyczniej interpretować pytania i formułować odpowiedzi na podstawie dostępnych treści. Z kolei względem wyszukiwarki jego rolą nie jest wyłącznie wskazanie miejsca, w którym znajduje się dokument, lecz także przedstawienie informacji odpowiadających na pytanie użytkownika. Nie oznacza to pełnej autonomii: zakres działania agenta zależy od nadanych mu możliwości i przyjętych reguł.

Firmowa baza wiedzy dostarcza kontekstu, którego nie zapewnia sama ogólna wiedza modelu językowego. Obejmuje między innymi procedury, instrukcje, regulaminy, materiały produktowe i odpowiedzi na powtarzające się pytania. Nie musi być jednym repozytorium — może składać się z zasobów przechowywanych w różnych miejscach. Podłączenie takich materiałów nie jest tym samym co trenowanie modelu od nowa; pozwala agentowi korzystać z nich podczas przygotowywania odpowiedzi.

Typowe zastosowania obejmują wsparcie pracowników w sprawach HR, pomoc w rozwiązywaniu problemów IT czy udostępnianie zespołowi sprzedaży informacji o ofercie. Warto przy tym rozdzielić dwie funkcje: udzielanie informacji i wykonywanie czynności. Wyjaśnienie procedury zgłoszenia usterki wymaga odpowiedniej wiedzy, natomiast utworzenie zgłoszenia wymaga dodatkowo skonfigurowanej akcji lub integracji.

Punktem wyjścia powinien być zatem konkretny problem użytkownika, a nie chęć udostępnienia agentowi wszystkich firmowych dokumentów. Jasno określony zakres — na przykład pomoc w odnajdywaniu i rozumieniu wewnętrznych procedur — ułatwia ustalenie, jakiej wiedzy agent potrzebuje i czego użytkownicy mogą od niego oczekiwać.

Przygotowanie źródeł wiedzy: SharePoint, pliki i strony WWW — co wybrać i jak podłączyć

Źródło wiedzy warto wybrać według tego, gdzie firma utrzymuje informacje i jak często je zmienia. W Cognity często słyszymy pytania, jak praktycznie podejść do wyboru i podłączenia źródeł wiedzy w Copilot Studio — odpowiadamy na nie także na blogu. SharePoint będzie naturalnym wyborem dla wewnętrznej dokumentacji, pliki — dla zamkniętego zestawu materiałów, a publiczne strony WWW — dla treści udostępnianych klientom. W jednym agencie można łączyć te źródła, ale każde powinno wnosić potrzebny zakres informacji, zamiast powielać pozostałe.

SharePoint: wiedza utrzymywana wewnątrz organizacji

Jeżeli procedury, instrukcje i materiały działowe są już przechowywane w SharePoint, zwykle nie ma potrzeby eksportowania ich do osobnego pakietu plików. Podłączenie tego źródła pozwala wykorzystać istniejące miejsce pracy z dokumentacją. To dobry wybór zwłaszcza wtedy, gdy zespół regularnie aktualizuje materiały i chce nadal zarządzać nimi w firmowym repozytorium.

W edytorze agenta przejdź do obszaru Wiedza (Knowledge), wybierz Dodaj wiedzę (Add knowledge), a następnie SharePoint. Wskaż adres obsługiwanego zasobu lub wybierz dostępne materiały zgodnie z opcjami widocznymi w interfejsie. Podłączenie może wymagać zalogowania się i skonfigurowania połączenia. Nazwy opcji i przebieg dodawania zależą od wersji interfejsu oraz konfiguracji środowiska.

Na początek wybierz witrynę lub zestaw zasobów odpowiadający zadaniu agenta. Dla asystenta wspierającego obsługę zamówień bardziej uzasadnionym źródłem będzie dokumentacja tego procesu niż cały firmowy intranet.

Pliki: wybrany zestaw materiałów bez podłączania repozytorium

Bezpośrednie przesłanie plików sprawdza się przy prototypie lub agencie korzystającym z niewielkiego, jasno określonego pakietu dokumentacji. Mogą to być na przykład instrukcje produktów albo materiały referencyjne, których firma nie utrzymuje w SharePoint. Nie wymaga to wskazywania witryny ani publikowania treści w internecie.

W obszarze wiedzy wybierz dodawanie plików, wskaż dokumenty w obsługiwanym formacie i poczekaj na zakończenie ich przetwarzania. Następnie upewnij się, że pojawiły się na liście źródeł agenta. Przesłanie dokumentu nie tworzy stałego połączenia z jego lokalnym oryginałem: edycja pliku na komputerze nie aktualizuje automatycznie kopii dodanej do agenta. Jeśli materiały często się zmieniają, warto rozważyć źródło zarządzane centralnie.

Strony WWW: informacje dostępne publicznie

Publiczne witryny nadają się do udostępniania agentowi dokumentacji online, opisów usług czy odpowiedzi na najczęstsze pytania klientów. Ten typ źródła wybierz wtedy, gdy właściwa treść jest dostępna bez logowania. Nie zastępuje on połączenia z zamkniętym portalem pracowniczym.

Aby dodać witrynę, wybierz źródło typu Publiczna strona internetowa i podaj odpowiedni adres URL. Wskaż stronę lub obszar serwisu związany z przeznaczeniem agenta, zamiast automatycznie zaczynać od strony głównej. Przed dodaniem otwórz adres bez zalogowanej sesji i sprawdź, czy prowadzi do właściwych materiałów, a nie do formularza logowania lub strony przekierowującej.

Nazwij źródła zgodnie z ich przeznaczeniem

Przy dodawaniu źródeł uzupełnij ich nazwy i opisy, jeśli interfejs udostępnia takie pola. Opis powinien jasno wskazywać, jakie informacje zawiera dane źródło i przy jakich pytaniach będzie przydatne. Zamiast ogólnego „Dokumenty” lepiej zastosować nazwę opisującą rzeczywistą zawartość, na przykład „Instrukcje obsługi produktów”. Ułatwia to zarządzanie bazą wiedzy, szczególnie gdy agent korzysta z kilku różnych miejsc.

Higiena treści i standaryzacja: struktura dokumentów, wersjonowanie, metadane i jakość informacji

Podłączenie firmowej bazy wiedzy do Copilot Studio nie rozwiązuje problemów z jej zawartością. Jeśli dwie instrukcje opisują tę samą procedurę inaczej, agent może oprzeć odpowiedź na niewłaściwej wersji. Jeśli warunek zastosowania zasady znajduje się daleko od jej opisu, odpowiedź może go pominąć. Porządkowanie wiedzy powinno więc zacząć się od treści, a nie od ustawień agenta.

Warto rozdzielić cztery zadania: struktura dokumentu nadaje informacjom kontekst, wersjonowanie wskazuje obowiązującą treść, metadane opisują jej przeznaczenie, a przegląd merytoryczny potwierdza poprawność. Żadne z nich nie zastępuje pozostałych — dobrze oznaczony dokument nadal może zawierać nieaktualną instrukcję.

Struktura dokumentu: jedna sekcja, jedno zagadnienie

Dokument powinien mieć jednoznaczny tytuł i logiczną hierarchię nagłówków. Zamiast ogólnego „Informacje organizacyjne” lepiej zastosować tytuł wskazujący konkretny temat, na przykład „Zasady rozliczania krajowych podróży służbowych”. Poszczególne sekcje mogą odpowiadać na pytania pracowników: kto zatwierdza wyjazd, jakie dokumenty trzeba dostarczyć i kiedy należy to zrobić.

Każdy fragment opisujący zasadę powinien zawierać również najważniejsze warunki jej zastosowania. Zdanie „Wniosek należy złożyć w ciągu 14 dni” pozostaje niejednoznaczne bez informacji, o jaki wniosek chodzi i od jakiego zdarzenia liczy się termin. Czytelniejszy zapis to: „Wniosek o rozliczenie podróży służbowej należy złożyć w ciągu 14 dni od zakończenia wyjazdu” — oczywiście pod warunkiem, że taki termin rzeczywiście wynika z firmowych zasad.

Procedury warto przedstawiać jako uporządkowane kroki, a dane porównawcze jako proste tabele z opisanymi kolumnami. Kluczowe ustalenia nie powinny istnieć wyłącznie na zrzucie ekranu, w kolorystycznym wyróżnieniu lub pod nieprecyzyjnym odwołaniem „jak wyżej”. Skróty branżowe i wewnętrzne należy rozwinąć przy pierwszym użyciu oraz stosować konsekwentnie w całej bazie.

Wersjonowanie: jedna obowiązująca odpowiedź

Historia zmian pozwala odtworzyć wcześniejsze ustalenia, ale sama nie wskazuje, która treść powinna być podstawą bieżących odpowiedzi. Dla każdego zagadnienia należy wyznaczyć jedno źródło obowiązujące. Kopie robocze, dokumenty archiwalne i materiały zastąpione nową instrukcją nie powinny funkcjonować jako równorzędne źródła aktualnych zasad.

Warto odróżniać datę ostatniej edycji od daty wejścia w życie. Poprawienie literówki nie oznacza zmiany procedury, a opublikowanie nowego regulaminu nie musi oznaczać, że już obowiązuje. Przy istotnych aktualizacjach dokument powinien jasno wskazywać datę obowiązywania oraz materiał, który zastępuje. Nazwy plików w rodzaju „procedura_final_poprawiona_2” nie zastąpią takiego porządku.

Metadane: opis znaczenia i odpowiedzialności

Spójny zestaw metadanych ułatwia utrzymanie bazy, wyszukiwanie materiałów wymagających przeglądu oraz rozróżnianie podobnych instrukcji. Na początek wystarczy kilka pól:

• Właściciel merytoryczny — rola lub zespół odpowiedzialny za poprawność treści.
• Status — na przykład roboczy, zatwierdzony albo archiwalny.
• Data obowiązywania i termin przeglądu — informacja, od kiedy stosować zasady i kiedy ponownie je zweryfikować.
• Zakres zastosowania — proces, jednostka organizacyjna, kraj lub grupa odbiorców, których dotyczy dokument.

Nazwy pól i ich wartości powinny być ujednolicone. „Kadry”, „HR” i „Dział personalny” używane zamiennie jako kategorie utrudniają utrzymanie spójności. Nie należy też zakładać, że każde pole metadanych zostanie automatycznie wykorzystane przez agenta — zależy to od sposobu udostępnienia źródła. Informacje niezbędne do interpretacji zasad warto umieścić również w treści dokumentu.

Jakość informacji: przegląd przed publikacją

Przegląd merytoryczny powinien wychwytywać sprzeczności, nieaktualne odwołania, brakujące wyjątki i niejasne sformułowania. Szczególnej uwagi wymagają zwroty takie jak „standardowo”, „w uzasadnionych przypadkach” czy „po uzyskaniu zgody”, jeśli dokument nie wyjaśnia, co oznaczają i kto podejmuje decyzję.

Duplikaty najlepiej zastępować odwołaniem do źródła obowiązującego, zamiast utrzymywać kilka niezależnie edytowanych opisów. Za zatwierdzenie zmian powinien odpowiadać właściciel merytoryczny. Dzięki temu aktualizacja zasad staje się kontrolowaną zmianą w bazie wiedzy, a nie kolejnym plikiem pozostawionym obok poprzednich wersji.

Uprawnienia i bezpieczeństwo: dostęp, dziedziczenie, dane wrażliwe i zgodność

Agent korzystający z firmowej bazy wiedzy nie powinien poszerzać dostępu do informacji tylko dlatego, że ułatwia ich odnalezienie. W Copilot Studio trzeba rozdzielić trzy kwestie: kto może używać agenta, do jakich danych agent ma dostęp oraz w czyim imieniu pobiera informacje lub wykonuje działania. Udostępnienie agenta pracownikowi nie jest równoznaczne z nadaniem mu uprawnień do wszystkich źródeł. Z kolei samo wymaganie logowania nie gwarantuje, że każde połączenie będzie respektowało uprawnienia tego pracownika.

Tożsamość użytkownika a uprawnienia połączenia

W zastosowaniach wewnętrznych podstawą jest uwierzytelnianie, na przykład za pomocą Microsoft Entra ID. Pozwala ono ustalić tożsamość rozmówcy, ale sposób autoryzacji dostępu do danych zależy również od źródła, konfiguracji połączenia i kanału publikacji.

Najważniejsze rozróżnienie dotyczy pobierania danych w kontekście użytkownika oraz korzystania z poświadczeń zapisanych w połączeniu. W pierwszym modelu dostęp może być ograniczony uprawnieniami osoby prowadzącej rozmowę. W drugim zakres danych lub działań może wynikać z uprawnień konta użytego do skonfigurowania połączenia. Ma to szczególne znaczenie przy narzędziach i przepływach uruchamianych przez agenta: nie należy zakładać, że automatycznie działają one jako aktualny rozmówca. W Cognity omawiamy to rozróżnienie zarówno od strony technicznej, jak i praktycznej – zgodnie z realiami pracy uczestników.

Obowiązuje zasada najmniejszych uprawnień. Połączenie przeznaczone do odczytu procedur nie powinno umożliwiać modyfikowania dokumentów ani dostępu do całego repozytorium. Osobno warto ograniczyć prawo do edycji i publikowania agenta — jego twórca może zmienić źródła wiedzy, narzędzia oraz sposób udostępniania.

Dziedziczenie uprawnień: źródło źródłu nierówne

W przypadku SharePoint, przy prawidłowo skonfigurowanym uwierzytelnianiu i obsługiwanym dostępie w kontekście użytkownika, agent może korzystać z treści zgodnie z uprawnieniami rozmówcy. Znaczenie mają jednak rzeczywiste ustawienia witryn, bibliotek, folderów i dokumentów, w tym przerwane dziedziczenie oraz dostęp przyznany grupom. Agent nie naprawi zbyt szerokich uprawnień w repozytorium — może natomiast sprawić, że wcześniej trudno dostępne informacje staną się łatwe do odnalezienia.

Pliku przesłanego bezpośrednio do agenta nie należy traktować jak dokumentu nadal chronionego uprawnieniami pierwotnej lokalizacji. Samo wgranie kopii nie przenosi listy dostępu z SharePoint ani dysku sieciowego. Trzeba zakładać, że zawartość może być dostępna dla odbiorców agenta, i odpowiednio ograniczyć jego udostępnianie. Cofnięcie dostępu do oryginału nie jest też równoznaczne z usunięciem osobno przesłanej kopii.

Dane wrażliwe i kontrola przepływu informacji

Przed udostępnieniem wiedzy należy określić, jakich informacji agent rzeczywiście potrzebuje do realizacji swoich zadań. Dane kadrowe, informacje o zdrowiu, indywidualne wynagrodzenia czy tajemnice handlowe wymagają odrębnej oceny. Jeśli wystarcza ogólna procedura, nie ma uzasadnienia, by dołączać dokumenty zawierające dane konkretnych osób.

Polityki danych Power Platform, określane również jako DLP, mogą ograniczać użycie konektorów i przepływ danych między nimi. Nie zastępują jednak uprawnień do dokumentów ani analizy ich zawartości. Podobnie etykiety poufności i mechanizmy Microsoft Purview należy oceniać pod kątem obsługi w konkretnym źródle oraz scenariuszu — nie zakładać jednakowego działania we wszystkich integracjach.

Instrukcja „nie ujawniaj danych poufnych” nie jest mechanizmem kontroli dostępu. Ochrona musi wynikać z uwierzytelniania, autoryzacji i konfiguracji usług, a nie wyłącznie z treści poleceń przekazanych agentowi.

Zgodność obejmuje także historię rozmów

Ocena zgodności nie kończy się na bazie wiedzy. Użytkownicy mogą wpisywać dane osobowe i informacje poufne bezpośrednio w rozmowie. Należy więc ustalić, czy i gdzie zapisywane są transkrypcje, kto ma do nich dostęp, jak długo są przechowywane oraz jakie zasady obejmują diagnostykę i połączone usługi.

W kontekście RODO istotne są między innymi cel i podstawa przetwarzania, minimalizacja danych oraz retencja. Trzeba również zweryfikować wymagania dotyczące lokalizacji przetwarzania i warunki korzystania z integracji zewnętrznych. Dostępne zabezpieczenia platformy wspierają realizację tych obowiązków, ale nie stanowią automatycznego potwierdzenia zgodności konkretnego wdrożenia.

Wyszukiwanie i uziemianie odpowiedzi (grounding): konfiguracja, cytowania, ograniczanie halucynacji

Podłączenie firmowej bazy wiedzy nie oznacza jeszcze, że agent będzie poprawnie odpowiadał na jej podstawie. Musi najpierw odnaleźć informacje odpowiadające na pytanie, a następnie wykorzystać je bez dopisywania niepotwierdzonych szczegółów. Grounding, czyli uziemianie odpowiedzi, polega na oparciu generowanego tekstu na treści źródeł dostępnych w danym zapytaniu. Nie jest to trenowanie modelu na firmowych dokumentach — wiedza jest wyszukiwana i dostarczana jako kontekst odpowiedzi.

Wyszukiwanie a generowanie odpowiedzi

Te dwa etapy rozwiązują różne problemy. Wyszukiwanie ma wskazać materiały istotne dla pytania użytkownika. Generowanie ma przekształcić odnalezioną treść w zrozumiałą odpowiedź. Jeżeli agent otrzyma fragment dotyczący innej procedury, nawet płynna i przekonująca wypowiedź może być błędna. Z kolei właściwy dokument nie gwarantuje poprawności, jeśli model wyciągnie z niego zbyt daleko idące wnioski.

Wyszukiwanie informacji nie musi opierać się wyłącznie na identycznym brzmieniu słów. Zależnie od źródła i mechanizmu wyszukiwania może uwzględniać również znaczenie pytania. Dzięki temu prośba o wyjaśnienie zasad pracy z domu może prowadzić do dokumentu o pracy zdalnej. Nie oznacza to jednak, że agent powinien samodzielnie rozstrzygać niejednoznaczności: jeśli odpowiedź zależy od rodzaju umowy lub kraju zatrudnienia, lepiej najpierw poprosić o doprecyzowanie.

Konfiguracja: określ, skąd agent ma czerpać odpowiedzi

W Copilot Studio wiedzę można udostępniać na poziomie agenta, a w kontrolowanych przepływach rozmowy korzystać z węzła odpowiedzi generatywnych (generative answers). Pierwsze podejście sprawdza się przy szerokim zakresie pytań. Drugie pozwala wskazać źródła dla konkretnego etapu rozmowy, na przykład odpowiedzi dotyczącej jednej procedury. Warto świadomie ustalić zakres wiedzy dla takiego węzła, zamiast zakładać, że zawsze korzysta on z identycznego zestawu materiałów jak cały agent.

Przy orkiestracji generatywnej znaczenie mają także opisy źródeł wiedzy: pomagają agentowi dobrać właściwe zasoby do zadania. Opis powinien wskazywać tematykę i zastosowanie źródła, a nie tylko powtarzać nazwę biblioteki. Przykładowo informacja, że źródło zawiera zasady rozliczania podróży służbowych, jest bardziej użyteczna niż ogólne określenie „dokumenty wewnętrzne”.

Jeżeli agent ma odpowiadać wyłącznie na podstawie firmowej wiedzy, wyłącz możliwość korzystania z wiedzy ogólnej modelu oraz nie włączaj wyszukiwania w publicznej sieci jako dodatkowej podstawy odpowiedzi. Dostępność i nazwy tych ustawień zależą od konfiguracji agenta. Instrukcja „korzystaj tylko z dokumentów” powinna uzupełniać konfigurację, a nie ją zastępować.

Cytowania: umożliwiaj sprawdzenie konkretnych twierdzeń

Odpowiedzi generatywne mogą zawierać cytowania wskazujące wykorzystane materiały. Ich dostępność i sposób prezentacji zależą między innymi od źródła, kanału oraz sposobu przekazania odpowiedzi użytkownikowi. Jeśli wynik jest przetwarzany w niestandardowym przepływie, należy zadbać, aby odwołania do źródeł nie zostały pominięte.

Cytowanie powinno wspierać konkretne twierdzenie, a nie jedynie prowadzić do dokumentu o podobnej tematyce. Gdy agent podaje termin złożenia wniosku, wskazany materiał musi rzeczywiście potwierdzać ten termin. Sam przypis nie dowodzi poprawności odpowiedzi. Nie należy też polecać modelowi dopisywania adresów lub tytułów źródeł, których nie otrzymał w wynikach wyszukiwania.

Jak ograniczać nieuzasadnione odpowiedzi

Instrukcje agenta powinny jasno określać zachowanie przy brakujących, niejednoznacznych i sprzecznych informacjach. Użyteczna reguła brzmi: „Odpowiadaj na podstawie odnalezionych materiałów. Jeśli nie potwierdzają odpowiedzi, powiedz o tym. Przy niejednoznacznym pytaniu poproś o doprecyzowanie. Nie uzupełniaj brakujących terminów, kwot ani warunków na podstawie przypuszczeń”.

Warto również odróżnić brak wyniku od potwierdzenia, że dana zasada nie istnieje. Komunikat „Nie znalazłem informacji o limicie” jest uczciwszy niż „Nie ma limitu”. Jeśli źródła podają różne wartości, agent powinien zasygnalizować rozbieżność zamiast samodzielnie wybierać jedną z nich bez podstawy. Grounding zmniejsza ryzyko halucynacji, lecz go nie usuwa — dlatego bezpieczna odpowiedź czasem oznacza wskazanie granicy dostępnej wiedzy, a nie udzielenie pozornie kompletnego wyjaśnienia.

6. Ograniczenia i typowe pułapki: zakres wiedzy, formaty, limity, wydajność i oczekiwania użytkowników

Agent w Copilot Studio może korzystać z firmowej bazy wiedzy, ale nie oznacza to, że przy każdej odpowiedzi analizuje całą jej zawartość. Wyszukuje informacje potrzebne do obsługi konkretnego pytania, a skuteczność tego procesu zależy m.in. od dostępności źródeł, sposobu zapisania treści oraz ograniczeń użytych mechanizmów. Podłączenie dokumentów nie jest równoznaczne z wytrenowaniem modelu na kompletnej wiedzy organizacji.

Zakres wiedzy nie jest zakresem kompetencji agenta

Agent może trafnie wyjaśnić procedurę opisaną w instrukcji, a jednocześnie nie znać aktualnego statusu sprawy, której ta procedura dotyczy. Dokumentacja procesu zakupowego pozwala odpowiedzieć, jak złożyć zamówienie, lecz nie zastępuje dostępu do systemu rejestrującego jego realizację. Podobnie materiały HR nie dają automatycznie dostępu do bieżącego salda urlopowego pracownika.

Warto rozdzielić trzy zastosowania: odpowiadanie na podstawie dokumentów, pobieranie aktualnych danych z systemów oraz wykonywanie operacji. Dwa ostatnie wymagają odpowiednich integracji i konfiguracji — samo dodanie źródła wiedzy ich nie zapewnia. Pułapką jest także traktowanie agenta jako narzędzia do kompletnego audytu repozytorium. Pytanie „wymień wszystkie wyjątki we wszystkich umowach” wymaga innego poziomu kompletności niż odnalezienie konkretnego zapisu.

Obsługiwany format nie gwarantuje poprawnego odczytu

Możliwość dodania pliku nie przesądza o tym, czy jego zawartość zostanie właściwie przetworzona. Znaczenie mają zarówno format i sposób podłączenia źródła, jak i układ informacji wewnątrz dokumentu.

Limity trzeba sprawdzać dla konkretnej konfiguracji

Nie istnieje jeden uniwersalny limit opisujący pojemność agenta. Ograniczenia mogą dotyczyć rozmiaru i liczby plików, poszczególnych źródeł, przetwarzania treści, częstotliwości wywołań oraz dostępnej pojemności rozliczeniowej. Zależą od funkcji, licencji i aktualnych zasad usługi. Dlatego wartości graniczne należy weryfikować w bieżącej dokumentacji Microsoft oraz w konfiguracji środowiska, zamiast przenosić je z innego wdrożenia.

Osobną kwestią jest aktualność informacji. Zmiana w źródle nie zawsze jest od razu widoczna w odpowiedziach. Zależnie od sposobu podłączenia może być potrzebne ponowne przetworzenie lub odświeżenie treści. Ma to szczególne znaczenie przy informacjach zmieniających się codziennie.

Wydajność i obietnice składane użytkownikom

Czas odpowiedzi obejmuje nie tylko generowanie tekstu, lecz także wyszukiwanie oraz ewentualne wywołania usług zewnętrznych. Wieloetapowe zadania, opóźnienia konektorów i ograniczenia przepustowości mogą wydłużać rozmowę. Większa liczba podłączonych źródeł nie oznacza automatycznie lepszych odpowiedzi — może również utrudnić odnalezienie właściwej informacji.

Użytkownik powinien wiedzieć, do czego agent służy, jakich danych nie posiada i czy potrafi wykonywać działania. Gdy brakuje podstaw do odpowiedzi, właściwym zachowaniem jest wskazanie ograniczenia lub drogi dalszego postępowania, a nie pewnie brzmiące przypuszczenie. Taka granica jest szczególnie ważna przy decyzjach finansowych, prawnych i kadrowych.

Testy jakości i ewaluacja: scenariusze, regresja, metryki, feedback i iteracyjne poprawki

Agent w Copilot Studio może płynnie odpowiadać na pytania, a mimo to nie pomagać w wykonaniu zadania. Dlatego przed udostępnieniem go pracownikom trzeba sprawdzić nie tylko poprawność pojedynczych odpowiedzi, lecz także ich kompletność, zgodność ze źródłami i użyteczność. Ewaluacja powinna odpowiadać na konkretne pytanie: czy użytkownik otrzymuje wiarygodną informację, na podstawie której może podjąć właściwe działanie?

Scenariusze testowe oparte na rzeczywistych potrzebach

Punktem wyjścia powinny być pytania, które pracownicy faktycznie zadają właścicielom procesów, działowi HR, wsparciu IT czy zespołom operacyjnym. Dla każdego scenariusza zapisz pytanie, oczekiwany rezultat, dokument stanowiący podstawę oceny oraz warunki zaliczenia testu. Warto określić również, czego agent nie powinien stwierdzić — na przykład podać terminu, którego nie ma w dokumentacji.

Zestaw testowy nie może obejmować wyłącznie prostych pytań z jednoznaczną odpowiedzią. Uwzględnij także:

• Różne sformułowania tej samej intencji — język potoczny, skróty i pytania bez słów występujących wprost w dokumencie.
• Pytania nieprecyzyjne — takie, przy których poprawnym zachowaniem jest doprecyzowanie potrzeby zamiast zgadywania.
• Rozmowy wieloetapowe — kolejne pytania nawiązujące do wcześniejszych odpowiedzi oraz zmianę tematu w trakcie rozmowy.
• Brak podstaw do odpowiedzi — zagadnienia nieobecne w bazie wiedzy, dla których agent powinien jasno wskazać ograniczenie.
• Przypadki o wysokich konsekwencjach błędu — odpowiedzi dotyczące obowiązkowych procedur, terminów lub warunków uzyskania uprawnień.

Nie oceniaj odpowiedzi przez dosłowne porównanie z jednym wzorcem. Agent może poprawnie przekazać tę samą informację innymi słowami. Kryteria powinny wskazywać wymagane fakty, istotne zastrzeżenia i niedopuszczalne błędy, a nie narzucać identyczne brzmienie.

Regresja: sprawdzanie, czy zmiana nie pogorszyła działania

Testy w panelu rozmowy Copilot Studio pomagają szybko sprawdzać poprawki podczas budowy agenta. Przed wdrożeniem potrzebna jest jednak również weryfikacja w docelowym kanale, na reprezentatywnych kontach użytkowników. Sam udany test wykonany przez twórcę nie wystarcza do oceny doświadczenia pracownika.

Testy regresyjne polegają na ponownym uruchamianiu stałego zestawu scenariuszy po zmianach. Wykonuj je po aktualizacji instrukcji agenta, konfiguracji lub istotnej części bazy wiedzy. Zapisuj datę, wersję konfiguracji, stan źródeł oraz wyniki, aby porównywać kolejne wydania. Jeśli zmieniła się sama procedura firmowa, zaktualizuj również oczekiwaną odpowiedź — dawny wzorzec nie może być miarą aktualnej poprawności.

Najważniejsze scenariusze warto uruchamiać wielokrotnie. Pojedyncza poprawna odpowiedź nie potwierdza stabilności, podobnie jak jednorazowy błąd nie wyjaśnia jeszcze jego przyczyny.

Metryki, które pokazują jakość odpowiedzi

Podstawową miarą jest odsetek scenariuszy spełniających ustalone kryteria. Uzupełnij go oceną poprawności merytorycznej, kompletności oraz zgodności twierdzeń z przywołanymi źródłami. Osobno mierz właściwe zachowanie przy braku wiedzy: odmowa zgadywania może być wynikiem poprawnym, a nie porażką agenta.

W eksploatacji przydatne są także czas uzyskania użytecznej odpowiedzi, liczba koniecznych doprecyzowań i deklarowane rozwiązanie sprawy. Interpretuj je łącznie: krótka rozmowa nie dowodzi sukcesu, ponieważ użytkownik mógł po prostu zrezygnować. Wyniki analizuj według kategorii pytań i wagi błędów. Wysoka średnia nie powinna przesłaniać powtarzalnych pomyłek w krytycznej procedurze. Progi akceptacji ustal z właścicielami procesów, zamiast przyjmować jeden poziom dla wszystkich zastosowań.

Feedback i poprawki oparte na przyczynach błędów

Sama ocena „pomocne” lub „niepomocne” rzadko wystarcza do naprawy problemu. W procesie zbierania feedbacku umożliwiaj wskazanie, czy odpowiedź była błędna, niepełna, nieaktualna, czy nie dotyczyła pytania. Analizuj zgłoszenia wraz z potrzebnym kontekstem rozmowy, ograniczając zbieranie danych osobowych i informacji wrażliwych.

Następnie ustal przyczynę: brak informacji w źródle, pominięcie właściwego dokumentu, błędną interpretację albo nieczytelną prezentację odpowiedzi. Dobierz poprawkę do rozpoznanego problemu i ponów test, a następnie regresję. Każdy potwierdzony, istotny błąd warto zamienić w trwały scenariusz testowy. W ten sposób doświadczenia użytkowników stają się podstawą kontroli jakości, a kolejne aktualizacje agenta można oceniać na podstawie porównywalnych wyników, nie samego wrażenia poprawy.

Utrzymanie bazy wiedzy i mierzenie skuteczności agenta: governance, monitoring, aktualizacje i KPI

Opublikowanie agenta w Copilot Studio nie kończy pracy nad firmową bazą wiedzy. Procedury się zmieniają, usługi zyskują nowe zasady, a część materiałów przestaje obowiązywać. Agent może więc działać poprawnie technicznie, lecz udzielać odpowiedzi nieprzydatnych biznesowo. Utrzymanie rozwiązania wymaga dwóch równoległych działań: nadzoru nad wiedzą oraz obserwacji, czy agent rzeczywiście pomaga użytkownikom.

Governance: odpowiedzialność za wiedzę i działanie agenta

Governance to ustalone zasady zarządzania rozwiązaniem: kto podejmuje decyzje, kto odpowiada za treści i co dzieje się po wykryciu problemu. Warto rozdzielić odpowiedzialność właściciela biznesowego agenta, opiekunów poszczególnych obszarów wiedzy oraz zespołu utrzymującego konfigurację. Pierwszy określa cele i priorytety, drudzy potwierdzają aktualność informacji, a trzeci dba o ciągłość działania i wdrażanie uzgodnionych zmian. W mniejszej organizacji te role może pełnić mniej osób, ale zakres odpowiedzialności powinien pozostać jednoznaczny.

Potrzebna jest również prosta ścieżka obsługi zgłoszeń. Błędna informacja o świadczeniach pracowniczych powinna trafić do właściciela tej wiedzy, natomiast niedostępne źródło — do osoby odpowiedzialnej za jego podłączenie. Każde zgłoszenie powinno mieć opiekuna, priorytet i termin reakcji. Dzięki temu uwagi użytkowników nie pozostają wyłącznie w historii rozmów.

Aktualizacje powiązane ze zmianami w organizacji

Przeglądy kalendarzowe są potrzebne, lecz nie zastąpią aktualizacji uruchamianych konkretnym zdarzeniem. Zmiana regulaminu, wycofanie produktu czy wdrożenie nowej procedury powinny automatycznie oznaczać zadanie dla opiekuna odpowiedniego obszaru wiedzy. Częstotliwość dodatkowych przeglądów należy dopasować do tempa zmian i skutków udzielenia nieaktualnej odpowiedzi.

Publikacja poprawionego dokumentu nie powinna być traktowana jako dowód, że agent już korzysta z nowej treści. Sposób i czas uwzględniania zmian zależą od rodzaju źródła oraz konfiguracji. Proces utrzymania powinien obejmować potwierdzenie, że istotna aktualizacja jest dostępna dla agenta, a wycofana informacja nie stanowi już podstawy odpowiedzi. Przy zmianach o dużym znaczeniu warto także poinformować użytkowników, od kiedy obowiązują nowe zasady.

Monitoring: oddziel kondycję techniczną od wartości biznesowej

Monitoring operacyjny pozwala wychwycić niedostępność źródeł, błędy wywołań, wydłużony czas odpowiedzi czy wzrost zużycia zasobów. Monitoring biznesowy odpowiada na inne pytania: z czym użytkownicy przychodzą do agenta, które potrzeby pozostają nieobsłużone i gdzie nadal konieczna jest pomoc człowieka. Dane analityczne dostępne w Copilot Studio warto zestawiać z informacjami z procesu, który agent wspiera, na przykład ze zgłoszeniami do działu IT. Zakres dostępnych danych zależy od konfiguracji i wykorzystywanych kanałów.

KPI, które pomagają podejmować decyzje

Zamiast rozbudowanego panelu wskaźników lepiej zacząć od kilku miar powiązanych z celem wdrożenia:

• Potwierdzone rozwiązanie sprawy — udział rozmów zakończonych osiągnięciem celu użytkownika. Sam brak przekazania do konsultanta nie oznacza sukcesu.
• Ponowny kontakt w tej samej sprawie — pomaga ocenić, czy uzyskana pomoc była wystarczająca, o ile dostępne dane pozwalają wiarygodnie powiązać kontakty.
• Czas usunięcia luki w wiedzy — okres od zgłoszenia brakującej lub nieaktualnej informacji do udostępnienia poprawki agentowi.
• Terminowość przeglądów wiedzy — udział obszarów sprawdzonych przez właścicieli w ustalonym terminie.
• Koszt obsłużonej sprawy — koszt działania rozwiązania odniesiony do spraw faktycznie rozwiązanych, a nie wyłącznie liczby rozmów.

Dla każdego KPI trzeba ustalić definicję, źródło danych, okres pomiaru i osobę odpowiedzialną za reakcję. Wyniki warto analizować osobno dla najważniejszych zastosowań agenta, ponieważ średnia może ukrywać problemy w konkretnym obszarze. Wskaźnik ma wartość wtedy, gdy prowadzi do decyzji: uzupełnienia wiedzy, zmiany zakresu obsługi, poprawy działania rozwiązania albo skierowania użytkownika do właściwego zespołu. Jeśli chcesz przełożyć te zasady na praktyczne działania, w Cognity pokazujemy, jak to zrobić.

Power Query – jak łączyć dane z wielu plików i źródeł bez ręcznego kopiowania 02 października 2026

Power Query – jak automatyzować przygotowanie i porządkowanie danych 30 września 2026