Agent do researchu, który nie mieli tych samych źródeł: jak zbudować mały system agentowy z kontrolą jakości

Dlaczego agenty do researchu mają tendencję do powtarzania tych samych źródeł i jak temu zapobiec architektonicznie?

Powtarzanie tych samych źródeł wynika najczęściej z połączenia trzech mechanizmów: (1) ograniczonej i dość stabilnej przestrzeni wyników narzuconej przez wyszukiwarkę/API (ranking faworyzuje „zawsze te same” domeny dla popularnych zapytań), (2) zachowania modelu językowego, który preferuje rozwiązania o wysokiej przewidywalności (gdy ma zbudować odpowiedź „bez ryzyka”, wraca do wcześniej widzianych domen i wzorców cytowania), oraz (3) braku pamięci i kontroli różnorodności na poziomie systemu (agent nie ma formalnego bodźca ani ograniczenia, które zmuszałoby go do eksploracji poza pierwszą stronę wyników lub poza kilka znanych serwisów). Jeśli dodatkowo pipeline dopuszcza tylko jeden typ zapytania (np. jeden prompt/templatka) i jeden kanał pozyskiwania treści, agent naturalnie koncentruje się na wąskim wycinku sieci.

Architektonicznie zapobiega się temu nie „lepszym promptem”, tylko wbudowaniem warstwy sterowania eksploracją i walidacją źródeł. Kluczowe jest rozdzielenie ról: komponent wyszukiwania powinien generować kandydatów szeroko (różne warianty zapytania, synonimy, zawężenia/rozszerzenia, różne języki jeśli to dopuszczalne), a komponent selekcji powinien działać z twardymi ograniczeniami na powtórki. W praktyce oznacza to, że system utrzymuje rejestr już użytych domen/URL-i (na poziomie zadania oraz globalnie w oknie czasowym) i traktuje je jako „koszt” lub wręcz blokadę w kolejnych iteracjach, dopóki nie zostanie spełniony wymóg różnorodności.

Drugim elementem jest świadome wymuszanie dywersyfikacji na etapie pobierania materiału, a nie dopiero przy pisaniu. Jeśli agent wybiera źródła dopiero z tego, co wcześniej pobrał, to różnorodność musi być zagwarantowana przed pobraniem: przez limity per domena, minimalną liczbę unikalnych domen, oraz strategię „explore-then-exploit” (najpierw szeroki przegląd, dopiero potem pogłębienie wybranych wątków). Trzeci element to niezależny „audytor źródeł” (osobny krok w grafie agentowym), który ocenia pokrycie tematu i wykrywa nadreprezentację jednego typu serwisów; jeśli wykryje monotonię, zwraca do wyszukiwania z konkretną dyrektywą: jakich klas źródeł brakuje (np. publikacje naukowe, dokumenty normatywne, raporty instytucji publicznych, dokumentacja techniczna).

Wreszcie potrzebny jest formalny kontrakt jakości: metryka różnorodności źródeł jako warunek przejścia. Bez tego agent „może” szukać szerzej, ale nie „musi”. Najprostsza kontrola to twarde progi (np. minimum N unikalnych domen, maksimum K materiałów z jednej domeny) oraz kara za ponowne użycie tej samej domeny w ramach jednego zadania. Taki projekt przenosi problem z poziomu zachowania modelu na poziom deterministycznych reguł systemu, dzięki czemu ograniczasz powtarzalność nawet wtedy, gdy model jest skłonny iść na skróty.

Jak zaprojektować pipeline pozyskiwania źródeł, żeby wymuszać różnorodność i aktualność?

Projekt zacznij od tego, żeby różnorodność i aktualność nie były „życzeniem”, tylko twardymi warunkami na danych. Pipeline powinien zwracać kandydatów (źródła) wraz z metadanymi potrzebnymi do oceny: domena/host, typ źródła (np. dokumentacja, publikacja, news, wpis blogowy), język, autor/instytucja (jeśli dostępne), data publikacji/aktualizacji, oraz sygnały jakości (np. cytowania, odwołania, spójność z innymi źródłami). Bez metadanych nie da się egzekwować ani różnorodności, ani świeżości, bo nie ma czego mierzyć.

Wymuszanie różnorodności realizuj jako etap selekcji po zebraniu większej puli wyników (over-retrieval). Najpierw zbierasz więcej kandydatów niż potrzebujesz, z kilku niezależnych strategii wyszukiwania (różne zapytania, różne źródła indeksów, różne synonimy), a potem stosujesz deduplikację i „dywersyfikację” opartą o reguły lub scoring. Deduplikacja powinna działać nie tylko po URL, ale też po domenie oraz po podobieństwie treści (żeby nie brać wielu kopii tej samej informacji z agregatorów). Dywersyfikacja to w praktyce limitowanie udziału jednego hosta/typu źródła oraz dobór wyników z różnych klastrów tematycznych (np. na podstawie embeddingów), tak aby w finalnym zestawie nie dominowało jedno miejsce ani jeden format.

Aktualność wymuszaj dwuetapowo: po pierwsze przez filtr „time window” adekwatny do tematu (np. ostatnie X miesięcy dla szybko zmieniających się obszarów), a po drugie przez ranking preferujący świeższe materiały, ale tylko tam, gdzie data jest wiarygodna. Kluczowe jest wykrywanie daty publikacji/aktualizacji z wielu sygnałów (metadane strony, znaczniki strukturalne, nagłówki, a w ostateczności heurystyki z treści) oraz odrzucanie przypadków niepewnych, jeśli świeżość jest krytyczna. Dodatkowo warto uwzględniać „freshness penalty” dla stron, które często republishują stare treści pod nową datą, co da się częściowo wykryć przez porównanie wersji/fragmentów treści w czasie.

Żeby te wymagania faktycznie działały, pipeline powinien mieć bramki (gates) na wyjściu: minimalną liczbę unikalnych domen, minimalny udział określonych typów źródeł oraz próg maksymalnego „stężenia” jednego hosta. Jeśli bramki nie są spełnione, system wraca do etapu zbierania kandydatów z inną strategią zapytań (np. rozszerza słowa kluczowe, zmienia język, sięga po inne repozytoria). To zapobiega sytuacji, w której agent „zadowala się” pierwszymi wynikami i mieli stale te same źródła.

Na koniec utrwal kontrolę przez pamięć operacyjną: przechowuj historię wykorzystanych domen/URL-i i nakładaj karę na źródła użyte w ostatnich N uruchomieniach albo w ramach jednego projektu. Taka „recency diversity” jest prostym, skutecznym mechanizmem przeciwko powtarzalności, o ile łączysz ją z twardymi metrykami świeżości i z zasadą over-retrieval + selekcja.

Jak deduplikować źródła po URL, domenie i podobieństwie treści, żeby nie cytować tego samego w kilku wersjach?

Deduplikację warto traktować jako proces wieloetapowy, bo te same materiały występują jako: identyczne URL-e w różnych wariantach, różne URL-e na tej samej domenie (np. wersje mobilne, AMP, parametry), oraz kopie lub przedruki na innych domenach. Celem jest sprowadzenie wielu rekordów do jednego „kanonicznego źródła” i pilnowanie, by cytowania odnosiły się do niego.

Na poziomie URL zacznij od normalizacji, czyli ujednolicenia adresów przed porównaniem. W praktyce usuwa się fragment po #, standaryzuje schemat i host (np. sprowadzenie do małych liter, ucięcie końcowego ukośnika), porządkuje parametry zapytania (sortowanie) oraz odfiltrowuje parametry śledzące i sesyjne (typowo UTM, gclid itp.). Jeśli masz łańcuch przekierowań, zapisuj URL po finalnym 3xx jako kandydata na kanoniczny, a pierwotny trzymasz tylko jako alias. Dobrą praktyką jest też odczytanie link rel="canonical" z HTML i traktowanie go jako preferowanego identyfikatora, o ile wskazuje na sensowny, publicznie dostępny dokument.

Na poziomie domeny chodzi o to, by nie zaliczać tej samej publikacji jako „różnych źródeł” tylko dlatego, że jest dostępna pod innym subdomenowym lub technicznym adresem. Dlatego rozdziel dwa pojęcia: „domena do grupowania” (zwykle rejestrowalna domena, np. example.com) oraz „host” (np. m.example.com, amp.example.com). Deduplikacja domenowa to grupowanie rekordów w obrębie tej samej domeny-grupy i wybieranie jednej reprezentacji, gdy treść i metadane wskazują na to samo (np. wersja AMP vs. wersja standardowa). Jednocześnie nie należy deduplikować wyłącznie po domenie, bo różne artykuły na tej samej domenie muszą pozostać osobnymi źródłami.

Najtrudniejszy etap to deduplikacja po podobieństwie treści, bo różne URL-e (a nawet różne domeny) mogą zawierać ten sam tekst. Tu potrzebujesz stabilnej reprezentacji treści i miary podobieństwa. Najpierw wyekstrahuj „czysty” tekst (bez nawigacji, stopki, rekomendacji), ujednolić białe znaki i znormalizować cytowania/znaki specjalne. Następnie licz dwa typy sygnałów: (1) szybkie odciski palca do wykrywania prawie-identycznych kopii (np. hash po znormalizowanej treści albo techniki typu shingling/simhash), oraz (2) semantyczne podobieństwo dla parafraz i skrótów (embeddingi i porównanie cosinusowe). W praktyce łączy się je w regułę: najpierw tani filtr (hash/simhash) do wyłapania oczywistych duplikatów, a dopiero na kandydatach uruchamia się droższe porównanie semantyczne.

Gdy wykryjesz klaster duplikatów (kilka rekordów opisuje tę samą publikację), ustal zasady wyboru „źródła głównego”. Najbezpieczniej preferować wersję kanoniczną wskazaną przez rel="canonical" lub finalny URL po przekierowaniach, a gdy masz przedruk na innej domenie, wybierać publikację pierwotną (jeśli da się ją jednoznacznie rozpoznać po dacie, autorze i spójnych metadanych). Pozostałe wpisy oznacz jako duplikaty i mapuj je na identyfikator źródła głównego, tak aby system cytował i liczył źródła na poziomie klastra, a nie pojedynczych URL-i.

Kluczowe jest też ustawienie progów podobieństwa i kontrola fałszywych trafień. Zbyt agresywny próg spowoduje sklejanie różnych materiałów o podobnej strukturze (np. strony produktowe, szablony newsroomów), dlatego porównuj tylko fragmenty o wysokiej „informacyjności” (główna treść), a dodatkowo wymagaj zgodności sygnałów pomocniczych, takich jak bardzo podobny tytuł, zbliżona długość tekstu lub zgodne kluczowe cytaty. Dzięki temu nie tylko unikniesz wielokrotnego cytowania tej samej treści, ale też zachowasz rozdzielność faktycznie różnych źródeł.

Jak oceniać wiarygodność i „wagę” źródeł, żeby agent nie preferował łatwych, ale słabych materiałów?

Najpierw trzeba rozdzielić dwa kryteria, które agent ma optymalizować: wiarygodność (na ile informacja jest prawdopodobnie prawdziwa) oraz „wagę” (na ile źródło ma autorytet w danym kontekście i jest właściwym typem dowodu). Jeśli tego nie rozdzielisz, agent będzie wybierał „najłatwiej dostępne” treści (streszczenia, blogi, agregatory), bo często są czytelne i szybkie do przetworzenia, ale niekoniecznie niosą najmocniejszy dowód.

W praktyce działa podejście oparte o jawny scoring i kary. Każde źródło oceniasz w kilku stałych wymiarach, a wynik wpływa na to, czy agent może go użyć oraz jak „mocno” może się na nie powołać. Kluczowe jest, żeby scoring premiował jakość dowodu, a nie wygodę (np. krótkie artykuły bez metodologii nie mogą wygrywać tylko dlatego, że są proste).

Najczęściej wystarczą cztery wymiary oceny, które agent może w dużej części wywnioskować z metadanych i treści: (1) pierwotność (czy to źródło pierwotne, czy wtórne streszczenie), (2) kontrola jakości (recenzja naukowa, redakcja, standard raportowania, przejrzysta metodologia), (3) weryfikowalność (czy są dane, cytowania, możliwość odtworzenia rozumowania), (4) adekwatność (czy źródło dotyczy dokładnie tezy, czasu, jurysdykcji i definicji użytych w pytaniu). Do tego dodaj kary za ryzyko: brak autora/instytucji, brak daty, brak odnośników do materiału pierwotnego, tekst o charakterze opinii lub marketingu, wtórne kompilacje bez cytowań.

Żeby agent nie „uciekał” w słabsze materiały, ustaw progi użycia: źródła poniżej minimalnego wyniku mogą służyć co najwyżej jako wskazówki do dalszego szukania, ale nie jako podstawa wniosków. Dodatkowo wymuś regułę, że dla kluczowych tez agent musi mieć co najmniej jedno źródło o wysokiej wadze (np. dokument pierwotny, publikacja z metodologią, oficjalna statystyka) albo zgodność kilku niezależnych źródeł średniej wagi; pojedyncze, łatwe do znalezienia omówienie nie może zamykać sprawy.

Dobrym zabezpieczeniem jest też rozróżnienie „cytuję” vs „wspominam”: agent może cytować tylko źródła, które spełniają wymagania wagi i wiarygodności, a słabsze może jedynie wspomnieć jako kontekst lub trop, z jawnym zastrzeżeniem ograniczeń. Taka polityka sprawia, że nawet jeśli agent znajdzie łatwy materiał, nie opłaca mu się na nim opierać, bo nie przejdzie progu albo nie da mu punktów do spełnienia wymagań jakości.

Jak przechowywać pamięć researchu (notatki, cytaty) tak, by agent nie wracał do tych samych fragmentów?

Żeby agent nie „kręcił się” po tych samych źródłach, pamięć researchu musi być zapisana w postaci jednoznacznych, adresowalnych rekordów (atomowych notatek) oraz mieć mechanizm deduplikacji oparty o identyfikatory i odciski treści. Najważniejsze jest rozdzielenie: (1) surowych cytatów z dowodem (gdzie to było) oraz (2) syntetycznych wniosków (co z tego wynika), bo agent wraca zwykle do surowizny, gdy nie ma zaufanej, gotowej syntezy z przypisami.

W praktyce przechowuj każdy „znaleziony fakt/cytat” jako osobny rekord z minimalnym zestawem pól, które pozwalają wykryć, że to już było, i bezpiecznie zacytować bez ponownego otwierania źródła: źródło (URL lub identyfikator dokumentu), lokalizacja (np. sekcja/nagłówek, numer strony, timestamp), cytat (dokładny fragment), parafraza (1–2 zdania własnymi słowami), temat/tagi, data pozyskania. Kluczowe jest, aby lokalizacja była tak precyzyjna, by agent mógł uznać „to już mam” bez ponownego skanowania całości.

Następnie dodaj dwie warstwy kontroli powrotów:

• Rejestr odwiedzin źródeł: zapisuj per zadanie (lub per projekt) listę odwiedzonych URL-i wraz z datą, zakresem (co zostało przeczytane) i statusem (np. „przeczytane w całości”, „przeczytano sekcje X–Y”). Agent przed wejściem w link sprawdza rejestr i wraca tylko, gdy ma powód (np. brak wymaganej sekcji).
• Deduplikacja notatek: każdemu rekordowi nadaj stabilny identyfikator oraz odcisk treści (hash) liczony z kanonicznej postaci cytatu (np. po usunięciu nadmiarowych spacji, normalizacji znaków). Przy zapisie sprawdzaj, czy identyczny (hash) lub niemal identyczny fragment już istnieje; jeśli tak, zamiast tworzyć nową notatkę, dopisz tylko dodatkowy kontekst (np. nowy tag) lub wskaż, że to to samo znalezisko.

Na koniec zadbaj, aby agent pracował na pamięci, a nie na „pełnym tekście”: w promptach i narzędziach powinien najpierw pobierać istniejące rekordy po temacie/tagach i dopiero gdy pamięć nie pokrywa pytania, uruchamiać kolejne przeszukiwanie źródeł. Taki układ (atomowe rekordy + precyzyjne lokalizacje + rejestr odwiedzin + hash do deduplikacji) minimalizuje ponowne czytanie tych samych fragmentów i ułatwia ponowne użycie raz zebranych cytatów.

Jak wymuszać cytowania i mapowanie twierdzeń do źródeł, żeby wynik był weryfikowalny?

Weryfikowalność uzyskasz dopiero wtedy, gdy każde zdanie o faktach da się jednoznacznie powiązać z konkretnym fragmentem materiału źródłowego (a nie tylko z „linkiem do strony”). W praktyce oznacza to dwa wymagania: (1) model ma obowiązek cytować dowód przy każdym twierdzeniu, (2) cytat musi być możliwy do odtworzenia (identyfikator źródła + lokalizacja w tekście, np. numer akapitu/sekcji lub zakres znaków) oraz dawać się sprawdzić bez interpretacji.

Najprościej wymusza się to przez kontrakt na format odpowiedzi: generowany tekst ma zawierać atomowe twierdzenia (po jednym fakcie na element), a do każdego elementu przypisane mają być cytaty w formie [S1#p3] lub [S2#sec4], gdzie Sx to stabilny identyfikator dokumentu z Twojej bazy/zeskanowanych stron, a #... to wskazanie miejsca. Jeżeli model nie potrafi wskazać lokalizacji, musi zwrócić „brak dowodu” zamiast dopowiadać.

Żeby „mapowanie twierdzeń do źródeł” było twardym wymaganiem, wprowadź reguły walidacji na wyjściu: wynik jest odrzucany, jeśli występuje twierdzenie bez cytatu, jeśli cytat wskazuje nieistniejący dokument/fragment, albo jeśli cytat nie zawiera tekstu wspierającego twierdzenie. To wymusza u agenta zachowanie: najpierw wyciągnij fragmenty z dokumentów, potem sformułuj twierdzenia dokładnie w granicach tego, co fragmenty mówią.

Kluczowy element techniczny to przygotowanie źródeł tak, by dało się je adresować. Dla HTML/PDF warto znormalizować treść do postaci „dokument → lista akapitów/segmentów”, gdzie każdy segment ma: doc_id, segment_id, treść segmentu oraz opcjonalnie metadane (tytuł sekcji, data, autor). Wtedy cytat typu [doc_id:segment_id] jest jednoznaczny, a weryfikacja może polegać na automatycznym sprawdzeniu, czy segment zawiera informację zgodną z twierdzeniem (co najmniej na poziomie dopasowania semantycznego lub ręcznej inspekcji).

W praktyce sprawdza się też rozdzielenie wyjścia na dwie części: (a) lista twierdzeń z cytatami, (b) syntetyczny akapit/sekcja złożona wyłącznie z twierdzeń, które mają pokrycie w (a). Dzięki temu nawet jeśli model „ładnie pisze”, nie da się przemycić nieudokumentowanej treści, bo generator ma budować narrację wyłącznie z zatwierdzonej listy twierdzeń.

Jak testować jakość researchu: pokrycie tematu, różnorodność źródeł i brak halucynacji?

Jakość researchu warto testować trzema niezależnymi kontrolami: (1) czy materiał pokrywa wszystkie wymagane aspekty tematu, (2) czy opiera się na zróżnicowanych i adekwatnych źródłach, oraz (3) czy każda istotna teza jest zakotwiczona w źródłach (brak halucynacji). Najlepiej robić to na poziomie „wymagań” (co research ma odpowiedzieć) i „dowodów” (na czym się opiera).

Pokrycie tematu testuj przez listę kryteriów/pytań kontrolnych (tzw. rubrykę pokrycia), przygotowaną przed researchem. Dla każdego kryterium sprawdź, czy w wyniku istnieje: jednoznaczna odpowiedź, wskazanie ograniczeń (kiedy odpowiedź nie obowiązuje) oraz odnośnik do źródła. Braki wykryjesz, gdy odpowiedź jest ogólna, nie zawiera warunków brzegowych albo nie da się wskazać, z czego wynika.

Różnorodność źródeł oceniaj nie liczbą linków, tylko pokryciem „typów dowodów” i niezależnością. Minimalnym testem jest sprawdzenie, czy kluczowe wnioski nie pochodzą z jednego łańcucha cytowań (A powołuje się na B, B na C) oraz czy są oparte o źródła pierwotne tam, gdzie to możliwe (np. standard, dokumentacja, publikacja, dane), a nie wyłącznie o streszczenia i wpisy wtórne. Dodatkowo porównaj, czy materiał uwzględnia odmienne perspektywy (np. podejście praktyczne vs. formalne) i czy jasno rozróżnia fakty od opinii.

Brak halucynacji weryfikuj przez audyt „claim–evidence”. Najpierw wyodrębnij zdania, które są weryfikowalne (definicje, liczby, zależności przyczynowe, stwierdzenia o stanie prawnym/technicznym). Następnie wymagaj, aby każde takie zdanie miało przypis do konkretnego fragmentu źródła; jeśli przypisu brak lub jest ogólny (np. tylko domena bez miejsca w tekście), traktuj to jako ryzyko halucynacji i żądaj doprecyzowania. Osobno oznacz tezy niepewne i interpretacje — powinny być opisane językiem niekategorycznym oraz z wyjaśnieniem, na czym opiera się wnioskowanie.

Praktyczna zasada domykająca te testy: jeśli nie da się wskazać, które zdanie w źródle uzasadnia daną tezę, to wynik nie spełnia kryterium jakości — niezależnie od tego, jak przekonująco brzmi.

Jakie proste mechanizmy kontroli kosztów i limitów zapytań chronią przed „runaway agent”?

„Runaway agent” to sytuacja, w której agent wpada w pętlę działań (np. kolejne wyszukiwania, ponowne próby, zbyt głębokie iteracje), generując nieproporcjonalnie duży koszt i liczbę zapytań w stosunku do wartości wyniku. Ochrona polega na wbudowaniu twardych limitów (budżetów) oraz warunków stopu, które nie wymagają skomplikowanej logiki, a skutecznie odcinają niekontrolowaną eskalację.

Najprostsza i najskuteczniejsza praktyka to wielowarstwowe „guardrails” liczone per zadanie i per sesja: limit liczby wywołań narzędzi (np. wyszukiwarki), limit liczby iteracji pętli planuj–wykonaj–oceń, limit czasu (timeout) oraz limit kosztu/zużycia tokenów. Limity powinny być egzekwowane przez kod orkiestrujący (nie przez sam model), a po ich osiągnięciu system ma zwrócić częściowy wynik z informacją, co zostało zrobione i dlaczego przerwano.

W praktyce chronią cztery proste mechanizmy: twarde budżety na zapytania i tokeny, throttling (ograniczenie tempa i równoległości), deduplikacja oraz „circuit breaker” na powtarzające się błędy. Budżety ustawiasz jako licznik: każde wywołanie narzędzia i każdy krok agenta zmniejsza pulę; gdy pula spadnie do zera, agent nie może już wykonywać kolejnych akcji. Throttling ogranicza liczbę równoległych zapytań i wymusza przerwy, co zapobiega gwałtownemu „wystrzałowi” kosztu przy błędnej strategii. Deduplikacja blokuje ponowne odpytywanie tych samych URL-i, zapytań lub identycznych parametrów narzędzia (w prostym wariancie wystarczy hash argumentów i pamięć „already seen”). Circuit breaker przerywa serię kolejnych nieudanych prób (np. 3–5 błędów sieciowych/HTTP z rzędu) zamiast pozwalać agentowi na bezkończone retry.

Kluczowe jest też rozdzielenie limitów na „twarde” i „miękkie”. Twarde (np. maks. 20 wywołań wyszukiwarki, 10 iteracji, 60 s czasu) są nieprzekraczalne. Miękkie (np. próg ostrzegawczy po 70% budżetu) mogą uruchamiać tryb oszczędny: agent kończy research wcześniej, przechodzi na syntezę z tego, co już ma, albo wymaga jawnego potwierdzenia człowieka na zwiększenie budżetu. Dzięki temu nawet przy błędnym planie agent nie „ucieka” kosztowo, a system pozostaje przewidywalny i audytowalny.

PowerApps: 9 antywzorców w formularzach, które niszczą jakość danych (i jak je naprawić regułami) 02 maja 2026

Excel + Power Automate: automatyczne wersjonowanie plików i blokada nadpisywania (wzorzec zespołowy) 30 kwietnia 2026