Copilot Studio bez „wiedzy ogólnej”: jak wymusić odpowiedzi tylko z SharePoint i cytowania źródeł

Dlaczego Copilot potrafi odpowiadać „z głowy” mimo podpiętego SharePoint jako źródła wiedzy?

W Copilot Studio podpięcie SharePoint jako „źródła wiedzy” nie oznacza automatycznie, że model będzie korzystał wyłącznie z tych dokumentów. Domyślnie Copilot może łączyć odpowiedzi generowane na podstawie ogólnej wiedzy modelu z treściami odzyskanymi z podłączonych źródeł (mechanizm RAG). Jeśli zapytanie wygląda na takie, na które da się odpowiedzieć bez sięgania do dokumentów, albo gdy dopasowane fragmenty z SharePoint są zbyt słabe, zbyt ogólne lub nie zostały znalezione, model potrafi wypełnić lukę własną wiedzą językową.

Drugi typowy powód to brak „twardego” wymagania cytowania lub oparcia odpowiedzi na źródłach. Gdy agent nie ma ustawionych reguł, które wymuszają wykorzystanie treści z SharePoint (np. odpowiedź tylko, jeśli znaleziono pasujące fragmenty), Copilot może uznać, że bezpieczniej jest odpowiedzieć na podstawie tego, co „wie”, zamiast zwrócić komunikat o braku danych. W praktyce więc SharePoint działa jako dodatkowy kontekst, a nie jako jedyny dozwolony korpus odpowiedzi, dopóki nie zostanie to explicite ograniczone konfiguracją.

Jak skonfigurować źródła SharePoint, żeby odpowiedzi były oparte na właściwych bibliotekach i folderach?

Konfigurację zacznij od precyzyjnego wskazania lokalizacji w SharePoint, z których asystent ma pobierać treść. W praktyce oznacza to wybór konkretnych witryn oraz bibliotek dokumentów (a nie „całego SharePoint”), ponieważ to biblioteka jest podstawową granicą porządkowania i uprawnień. Jeżeli istotne jest zawężenie do wydzielonego zakresu w obrębie biblioteki (np. tylko dokumenty z konkretnego działu), jako źródło wskaż docelowy folder (lub ścieżkę folderu) zamiast całej biblioteki.

Żeby odpowiedzi rzeczywiście opierały się na „właściwych” zasobach, dopilnuj spójności trzech elementów: (1) zakresu źródła (wskazana witryna/biblioteka/folder), (2) uprawnień (asystent widzi wyłącznie to, do czego ma dostęp użytkownik i sama integracja), oraz (3) jakości i jednoznaczności struktury dokumentów. Jeśli w tej samej bibliotece znajdują się podobne dokumenty dla różnych odbiorców, najbezpieczniej rozdzielić je na osobne foldery i wskazać tylko ten folder, który ma być bazą odpowiedzi.

Po dodaniu źródła zweryfikuj konfigurację testami kontrolnymi: zadaj pytania, na które odpowiedź powinna pochodzić wyłącznie z danego folderu (np. o unikatowe sformułowania lub nazwy występujące tylko w tych plikach). Jeżeli asystent cytuje dokument spoza oczekiwanego zakresu, oznacza to, że źródło jest zbyt szerokie (np. cała biblioteka zamiast folderu) albo dokumenty są przemieszane w lokalizacji, która została dołączona do źródeł.

Jak ograniczyć model do odpowiedzi wyłącznie na podstawie dokumentów i co zrobić, gdy źródła nie wystarczają?

Ograniczenie odpowiedzi „tylko na podstawie dokumentów” wymaga ustawienia trybu działania tak, aby model nie korzystał z wiedzy ogólnej ani nie dopowiadał brakujących informacji. W praktyce oznacza to, że odpowiedź ma powstawać wyłącznie z treści pobranej z podpiętych źródeł (np. SharePoint) i być możliwa do zweryfikowania przez wskazane cytaty. Kluczowe są dwie rzeczy: instrukcja systemowa/konwersacyjna wymuszająca „odpowiadaj tylko, jeśli informacja znajduje się w źródłach” oraz włączenie cytowań w odpowiedziach, żeby użytkownik widział, z jakich fragmentów dokumentów wynikają twierdzenia.

Równie istotne jest zdefiniowanie zachowania na wypadek braków w dokumentach. Jeśli wyszukiwanie nie zwraca wystarczających fragmentów albo są one niejednoznaczne, agent nie powinien zgadywać ani uogólniać. Poprawny wzorzec odpowiedzi to jawne stwierdzenie braku podstaw w źródłach (np. „nie znajduję w dokumentach informacji o…”) oraz wskazanie, jakich danych brakuje, aby odpowiedzieć (np. nazwa procedury, zakres dat, wersja dokumentu). Dopuszczalne jest również zadanie doprecyzowującego pytania, ale tylko wtedy, gdy po doprecyzowaniu nadal będzie można oprzeć odpowiedź na dokumentach.

Gdy źródła faktycznie nie wystarczają, rozwiązaniem nie jest „poluzowanie” ograniczeń, tylko poprawa bazy wiedzy lub jej indeksowania: uzupełnienie brakujących dokumentów, doprecyzowanie treści (np. dodanie definicji, reguł, wyjątków), uporządkowanie wersji i duplikatów oraz zadbanie o to, by kluczowe informacje znajdowały się w treści możliwej do przeszukania. Do czasu uzupełnienia źródeł agent powinien konsekwentnie odmawiać odpowiedzi, podając, że nie ma wystarczających podstaw w dokumentach, i opierać się wyłącznie na dostępnych cytowanych fragmentach.

Jak wymusić cytowanie źródeł i jaki format cytowań jest najbardziej użyteczny dla użytkownika?

Cytowania wymusza się na poziomie instrukcji dla modelu (system/prompt) oraz sposobu zwracania odpowiedzi: asystent ma zawsze dołączać źródła do każdej odpowiedzi opartej na dokumentach i traktować brak źródła jako sygnał „nie mam podstaw”. W praktyce oznacza to jednoznaczne polecenie typu: odpowiadaj wyłącznie na podstawie treści z podłączonych materiałów i zawsze podawaj cytowania; jeśli nie znajdujesz potwierdzenia w źródłach, powiedz, że nie ma informacji w dostępnych dokumentach. To podejście działa tylko wtedy, gdy kanał wiedzy (np. SharePoint) jest skonfigurowany tak, aby zwracał identyfikowalne fragmenty (snippety) wraz z metadanymi dokumentu, które można przedstawić użytkownikowi jako cytat.

Najbardziej użyteczny format cytowań dla użytkownika jest jednocześnie zwięzły i weryfikowalny: numerowane odnośniki przy zdaniach/akapitach oraz sekcja „Źródła” na końcu. Każda pozycja źródła powinna zawierać: tytuł dokumentu, lokalizację (link do pliku/strony SharePoint) oraz możliwie precyzyjne miejsce w dokumencie (np. nazwa sekcji lub numer strony, jeśli to PDF). Dzięki temu użytkownik może szybko ocenić wiarygodność odpowiedzi, a w razie potrzeby jednym kliknięciem przejść do materiału i sprawdzić kontekst.

Warto unikać cytowań „zbiorczych” (jedna lista źródeł bez przypisania do konkretnych twierdzeń), bo utrudniają weryfikację i sprawiają wrażenie, że model tylko „dokleił linki”. Lepsze jest mapowanie: każdy istotny fakt ma przypisane 1–2 cytowania, a powtarzające się źródła mogą występować wielokrotnie pod tym samym numerem.

Jak uprawnienia SharePoint wpływają na to, co agent może zwrócić i jak uniknąć nadmiarowego dostępu?

Agent korzystający z wiedzy z SharePoint nie „omija” modelu uprawnień — widoczność treści jest ograniczona tym, co dany kontekst dostępu ma prawo odczytać w SharePoint (na poziomie witryny, biblioteki, folderu, elementu oraz ewentualnie wersji/załączników). W praktyce oznacza to, że agent może zwrócić wyłącznie informacje z dokumentów, do których ma skuteczny dostęp odczytu; jeśli użytkownik nie ma uprawnień do pliku, a agent działa w jego kontekście, odpowiedź nie powinna ujawnić treści tego pliku. Natomiast jeżeli agent działa w kontekście konta/aplikacji o szerszych uprawnieniach (np. konto serwisowe użyte do połączenia), to zakres możliwych odpowiedzi poszerza się do wszystkich zasobów dostępnych dla tego konta, niezależnie od uprawnień konkretnego użytkownika.

Aby uniknąć nadmiarowego dostępu, kluczowe jest dopasowanie uprawnień do rzeczywistego zakresu wiedzy, z którego agent ma korzystać. Najbezpieczniej jest utrzymywać źródła w dedykowanej lokalizacji (osobna witryna/biblioteka) i przyznać dostęp tylko tym grupom, które faktycznie mają widzieć te treści, zamiast dopinać agenta do szerokich witryn i liczyć na to, że „prompt” ograniczy odpowiedzi. Warto też unikać nadawania agentowi uprawnień typu „wszędzie w tenant” lub roli globalnego czytelnika, bo wtedy agent może cytować i streszczać treści spoza zamierzonego zakresu. Jeżeli musisz użyć konta technicznego do połączenia, jego uprawnienia powinny być minimalne (tylko odczyt i tylko do wskazanych bibliotek), a w SharePoint należy stosować separację treści (unikalne uprawnienia na bibliotekach/folderach) tam, gdzie w jednym miejscu współistnieją dane o różnej wrażliwości.

Jak testować, czy agent nie przemyca „wiedzy ogólnej” i nie halucynuje brakujących faktów?

Test sprowadza się do sprawdzenia, czy każda odpowiedź jest w pełni „udowadnialna” materiałem z SharePoint: każdy istotny fakt powinien mieć pokrycie w przytoczonym źródle (cytacie/odnośniku), a brak źródła oznacza, że agent najpewniej dopowiedział treść z „wiedzy ogólnej” albo halucynował. W praktyce weryfikujesz więc nie tylko brzmienie odpowiedzi, ale też jej ślad dowodowy: czy cytowania są obecne, czy prowadzą do właściwych dokumentów i czy fakty w odpowiedzi są literalnie lub jednoznacznie wywnioskowane z cytowanego fragmentu.

Żeby to przetestować systematycznie, użyj krótkiego zestawu prób (promptów), które prowokują model do dopowiadania. Każdy test oceniaj w trybie „zero tolerancji”: jeśli brakuje cytowania dla kluczowej tezy albo cytat nie pokrywa tezy, wynik traktuj jako niezaliczony.

• Test braku danych (negative test): zadawaj pytania o informacje, których na pewno nie ma w SharePoint (np. szczegółowe parametry, daty, nazwiska). Poprawna reakcja to odmowa/komunikat o braku podstaw oraz brak „strzałów”.
• Test precyzji cytowań: poproś o 2–3 konkretne fakty (liczby, limity, wymagania) i wymuś cytowania do każdego. Weryfikuj ręcznie, czy cytowany fragment rzeczywiście zawiera te fakty oraz czy agent nie dodał nic „pomiędzy”.
• Test parafrazy vs. dopowiedzenie: poproś o streszczenie procedury z dokumentu i sprawdź, czy nie pojawiają się kroki, wyjątki lub uzasadnienia, których nie ma w cytatach. To częsty punkt, gdzie „wiedza ogólna” wchodzi jako domyślne praktyki.
• Test kolizji źródeł: jeśli w SharePoint istnieją dwa dokumenty z różnymi wersjami zasad, zapytaj o aktualną regułę. Poprawna odpowiedź powinna oprzeć się na wskazanych dokumentach i nie „uzgadniać” różnic zmyśloną narracją; w razie niejednoznaczności agent powinien to nazwać.

Na końcu stosuj prostą regułę akceptacji: odpowiedź jest poprawna tylko wtedy, gdy (1) wszystkie kluczowe twierdzenia mają przypisane cytowania, (2) cytowania faktycznie je potwierdzają, (3) agent wprost sygnalizuje luki („nie ma w źródłach”) zamiast je wypełniać. To najszybszy sposób wykrycia zarówno „przemycania” wiedzy ogólnej, jak i halucynacji brakujących faktów.

Jak zaprojektować odpowiedź „brak danych w dokumentach”, żeby była pomocna zamiast frustrująca?

Odpowiedź „brak danych w dokumentach” powinna jednoznacznie komunikować, że asystent nie znalazł podstaw do odpowiedzi w dostępnych materiałach, a nie że „nie wie” albo „nie chce odpowiedzieć”. Kluczowe jest odróżnienie braku informacji w źródłach od ograniczeń funkcji: użytkownik ma zrozumieć, że wynik wynika z przeszukania dokumentów, a nie z błędu lub arbitralnej odmowy.

Żeby komunikat był użyteczny, podaj minimalny kontekst wyszukiwania: wskaż, że odpowiedź musi pochodzić wyłącznie z dokumentów (np. SharePoint) i że w danej chwili nie znaleziono fragmentów pasujących do pytania. Jeśli w Twoim rozwiązaniu są cytowania, to w scenariuszu „brak danych” pokaż brak cytowań wprost (np. „Nie mogę podać cytatów, bo nie znaleziono pasujących fragmentów”), zamiast pozostawiać użytkownika z domysłem, czy system w ogóle przeszukał źródła.

Następnie zaproponuj użytkownikowi najkrótszą drogę do uzyskania odpowiedzi bez „zgadywania” przez model: poproś o doprecyzowanie, które zwiększa szansę trafienia w treści dokumentów (np. nazwa procedury, numer dokumentu, dział, okres, użyte słownictwo), albo o wskazanie konkretnego pliku/lokalizacji, jeśli to możliwe. Ważne, aby sugestie były konkretne i ukierunkowane na odnalezienie informacji w dokumentach, a nie na „przekonanie” modelu do odpowiedzi.

Dobrą praktyką jest też zasygnalizowanie typowych przyczyn braku wyniku w sposób neutralny: informacja może nie istnieć w dokumentach, może być opisana innymi słowami, może znajdować się w dokumencie niedostępnym z powodu uprawnień albo w pliku, którego asystent nie indeksuje. Taki komunikat redukuje frustrację, bo użytkownik dostaje realne hipotezy i wie, co sprawdzić, zamiast traktować odpowiedź jako ślepą uliczkę.

Na koniec utrzymaj spójność z zasadą „bez wiedzy ogólnej”: nie dodawaj alternatywnej odpowiedzi z domysłów. Zamiast tego zaoferuj format, w jakim asystent odpowie, gdy użytkownik poda brakujący kontekst (np. „Jeśli wskażesz nazwę dokumentu lub fragment, mogę zacytować dokładny zapis i podać odpowiedź na tej podstawie”). Dzięki temu komunikat pozostaje rzetelny, a jednocześnie prowadzi użytkownika do kolejnego kroku, który faktycznie rozwiązuje problem.

Jak utrzymać jakość, gdy dokumenty w SharePoint często się zmieniają i mają różne wersje?

Kluczowe jest rozdzielenie „źródła prawdy” od dokumentów roboczych i konsekwentne wersjonowanie. Model oparty o SharePoint będzie korzystał z tego, co jest aktualnie dostępne i zindeksowane, więc jakość odpowiedzi zależy od tego, czy użytkownicy pytają o treści zatwierdzone oraz czy w bibliotece jednoznacznie da się odróżnić wersje obowiązujące od projektów.

W praktyce utrzymujesz jakość, gdy spełnione są trzy warunki: dokument ma stały adres (jeden plik zamiast wielu kopii), ma kontrolowany cykl publikacji (np. szkic → przegląd → zatwierdzone), a w treści lub metadanych jest jawnie określone, jaka wersja jest obowiązująca i od kiedy.

• Ustal jedno miejsce i jeden plik jako „single source of truth” dla procedur/polityk (bez duplikatów w różnych folderach). Zamiast tworzyć kopie, aktualizuj ten sam dokument, korzystając z historii wersji.
• Włącz i egzekwuj wersjonowanie oraz publikację: używaj wersji głównych dla treści zatwierdzonych, a robocze trzymaj jako wersje podrzędne lub w odrębnej przestrzeni/kanale pracy. To ogranicza ryzyko, że bot „zacytuje” fragment z niezatwierdzonego szkicu.
• Stosuj metadane i jasne oznaczenia wersji (np. „Status: Zatwierdzony”, „Właściciel”, „Data obowiązywania”, „Numer wersji” w nagłówku dokumentu). Dzięki temu użytkownik i system łatwiej weryfikują, czy cytowane źródło jest aktualne.
• Kontroluj dostęp i zakres źródeł: ogranicz, z jakich bibliotek/folderów bot może czerpać wiedzę (np. tylko repozytorium „Opublikowane”). Jeżeli bot ma dostęp także do obszarów roboczych, ryzyko niespójności rośnie wraz z liczbą równoległych wersji.

Dodatkowo warto pamiętać o opóźnieniach indeksowania: po dużych zmianach w plikach może istnieć krótki okres, w którym cytowania jeszcze odwołują się do wcześniejszej wersji. Proceduralnie minimalizuje się to przez publikowanie zmian w oknach czasowych i unikanie równoległego utrzymywania kilku „oficjalnych” wersji tego samego dokumentu.

Ewaluacja multimodalna: jak testować modele, które czytają obrazy, wykresy i skany umów 23 kwietnia 2026

Jak nie zepsuć korelacji: Pearson vs Spearman vs Kendall na przykładach biznesowych 21 kwietnia 2026