Multi-agent pipeline researchu statystycznego. 8 agentów AI bez halucynacji liczb

W marcu sprawdziłem prosty test. Zapytałem Claude Opus 4.7: „Ilu turystów rocznie odwiedza Szklarską Porębę?”. Dostałem natychmiastową odpowiedź: „około 2,1 mln rocznie według danych GUS”.

Brzmi konkretnie. Cytuje źródło. Wygląda jak research.

Sprawdziłem to. GUS Bank Danych Lokalnych w ogóle nie publikuje liczby turystów dla pojedynczej gminy Szklarska Poręba. Ze względu na tajemnicę statystyczną dane są agregowane minimum na poziomie powiatu. Cytat z GUS to halucynacja maskowana wiarygodną referencją.

To jest klasa błędu, na którą żaden pojedynczy LLM nie ma odporności. Model jest trenowany na statystycznym przewidywaniu tokenów. „Według GUS” to wzorzec, który dobrze pasuje do prozy o danych ekonomicznych. Model nie sprawdza, czy GUS rzeczywiście to publikuje. Generuje liczbę dopasowaną stylistycznie do kontekstu.

Dla marketera czytającego raport to katastrofa. Cytaty wyglądają wiarygodnie. Połowa jest prawdziwa. Druga połowa jest fikcją, na której opiera się decyzja o budżecie kampanii albo pozycjonowaniu produktu.

Konkretny przykład z mojego test suite. Pipeline w pierwszym cyklu policzył średnią cenę biletu do parku rozrywki na podstawie czterech źródeł. Jedno z nich, Dinolandia, było zacytowane jako „100 zł”. Faktyczna oficjalna cena na stronie parku - 75 zł. Różnica 33 procent. Marketer planujący kampanię pozycjonowania cenowego z benchmarkiem 218 zł średniej rynkowej skomunikowałby ofertę „premium powyżej średniej” przy faktycznej średniej 205 zł. Cały komunikat strategiczny oparty na fikcji jednej liczby.

Zbudowałem multi-agent pipeline, który tę klasę błędu eliminuje architektonicznie. Nie poprzez lepszy prompt. Poprzez ośmiu wyspecjalizowanych agentów, dziesięć bramek jakości i cold-blind weryfikatora w git worktree, który niezależnie replayuje każdy URL i porównuje sha256 odpowiedzi.

Architektura jest siostrzanym pipelinem do tego, który opisałem w artykule Dziewięciu agentów AI rozwiązuje Olimpiadę Matematyczną na maksimum punktów. Olimpiada matematyczna to dowód, że wzorzec działa na zadaniach deterministycznych, gdzie poprawność jest binarna. Tutaj pokazuję, że ten sam szkielet przenosi się na domeny, gdzie „prawda” jest rozproszona po dziesiątkach źródeł o różnej wiarygodności i częstotliwości aktualizacji. Czyli na codzienność researchu marketingowego.

Dlaczego pojedynczy LLM nie nadaje się do researchu statystycznego

Trzy problemy strukturalne, których nie da się rozwiązać lepszym promptem.

Te trzy ograniczenia projektują architekturę. Specjalizacja agentów. Wymuszone definicje. Hash-based replay URL przez niezależnego weryfikatora.

Architektura w jednym slajdzie

Pipeline ma 8 agentów pogrupowanych w siedem warstw funkcjonalnych.

Przepływ pracy dla pojedynczego zapytania:

PYTANIE  ────►  stat-orchestrator
                    │
                    ├──► stat-router          GATE R (domena z confidence)
                    │
                    ├──► stat-clarifier        GATE D_definitions
                    │   (mode=detect)         PAUZA - użytkownik odpowiada
                    │   (mode=integrate)      Definicje wpisane do query.md
                    │
                    ├──► stat-strategist-     GATE A_plan
                    │   {bdl, branzowy}       (DAG nodów ze schemą)
                    │
                    ├──► stat-prover           GATE B_fetch
                    │   (per node)            (URL + sha256 + value/value_array)
                    │
                    ├──► stat-drafter          report.md + spec.json + charts/
                    │
                    ├──► 4 BRAMKI MASZYNOWE
                    │   CITATION + FRESHNESS + REPRODUCIBILITY + RANGE_SANITY
                    │
                    └──► stat-verifier (worktree)  GATE C_verifier
                                │              cold-blind, 2 pliki referee
                                ▼              niezależny replay URL, rubryka 0-7
                        Akceptacja ≥ 6/7 → render HTML + scoreboard
                        Odrzucenie → cycle++ (max 4), spec update memory

Decyzja architektoniczna 1: clarifier jako definitional gatekeeper

To jest najważniejsza decyzja w całym pipelinie i kluczowa różnica wobec naiwnego RAG-a.

Bez clarifiera pipeline produkuje raporty „technicznie poprawne, ale odpowiadające na inne pytanie niż użytkownik zadał”. Klasyczny przykład: zapytanie „ile średnio wydaje turysta na rozrywkę w Polsce” ma minimum pięć rozwidleń definicyjnych:

Każde z tych rozwidleń zmienia rząd wielkości lub strukturę odpowiedzi. Bez precyzji raport wygląda profesjonalnie, ale liczby nic nie znaczą.

Clarifier działa w dwóch trybach. W trybie detect czyta zapytanie i konsultuje wewnętrzną tabelę pułapek definicyjnych (turysta, wakacje, park rozrywki, bezrobotny, gospodarstwo domowe, przedsiębiorca, e-commerce, ośrodek narciarski). Generuje 3-8 pytań do użytkownika z priorytetami (blocker / important / optional). Każde pytanie ma 2-4 opcje plus rekomendowaną z uzasadnieniem.

Pipeline zatrzymuje się i czeka na odpowiedzi.

W trybie integrate clarifier czyta odpowiedzi użytkownika i wpisuje je do sekcji ## Definicje przyjęte w query.md. Stara wersja archiwizowana jako .query-v1.md. Bramka D_definitions sprawdza maszynowo, czy sekcja jest wypełniona dla każdego pojęcia bez placeholderów.

Decyzja architektoniczna 2: hash-based reprodukowalność

Każda liczba w raporcie ma URL. Każdy URL ma sha256 odpowiedzi API w momencie pobrania. Verifier niezależnie replayuje URL i porównuje hash.

Schema claima po wykonaniu provera:

{
  "claim_id": "n6",
  "status": "success",
  "value": 406000,
  "unit": "osoba",
  "metric": "turysci_korzystajacy_noclegow_ogolem",
  "geo": "Powiat karkonoski",
  "year_array": [2019, 2020, 2021, 2022, 2023, 2024],
  "source_url": "https://bdl.stat.gov.pl/api/v1/data/by-unit/030210106000?var-id=40909",
  "source_label": "GUS BDL P2017 var=40909",
  "fetched_at": "2026-05-18T09:30:00+00:00",
  "raw_response_hash": "sha256:7a3f...e8b2",
  "method": "api_direct"
}

Cztery anty-halucynacyjne reguły są egzekwowane architektonicznie:

Decyzja architektoniczna 3: dziesięć bramek przed publikacją

Pipeline ma dziesięć bramek. Osiem maszynowych skryptów Python, jedna schema JSON, jedna agentowa (weryfikator).

Trzy bramki niosą największy ciężar w wykrywaniu halucynacji: CITATION (każda liczba ma footnote), REPRODUCIBILITY (replay URL z porównaniem sha256), C_verifier (cold-blind sędzia z niezależnym replay). Reszta to deterministyczne sieci bezpieczeństwa. Wymusza to, że każda liczba w raporcie jest weryfikowalna przez audytora w dowolnym momencie po publikacji.

Decyzja architektoniczna 4: cold-blind verifier z niezależnym replay

To samo rozwiązanie, które opisałem w artykule o EuMO, tu działa identycznie. Verifier nie widzi planu researchu, klasyfikacji, definicji ani poprzednich werdyktów. Czyta wyłącznie dwa pliki: report.md i spec.json.

Fizycznie wymuszone przez git worktree. Narzędzie Agent w Claude Code z parametrem isolation: "worktree" tworzy oddzielną kopię repozytorium. Verifier nie ma dostępu do plików spoza tej kopii. Po werdykcie orchestrator kopiuje verification.md do głównego drzewa.

Workflow verifiera w 10 krokach:

1. Read report.md + spec.json
2. Niezależny re-fetch URL z spec.json/queries[] (curl + sha256, porównanie z zapisanym response_hash)
3. Walidacja cytatów: każda liczba w report.md (regex) ma [^N] w 120 znakach
4. Walidacja wartości: value w report == value w odpowiadającym claim
5. Arytmetyczna walidacja per-line (ratio, procent, mnożnik, suma)
6. Walidacja definicji: konsekwentne użycie pojęć zgodnie z sekcją Definicje przyjęte
7. Rozbieżności ujawnione? Jeśli claims pokazują >5% różnicy między źródłami, raport MUSI mieć sekcję „Rozbieżności”
8. Freshness: fetched_at < max_age kategorii
9. Range sanity: wartości w zdroworozsądkowych zakresach
10. Hand-waving detection: brak „około”, „szacuje się”, „prawdopodobnie” przy konkretnych liczbach

Test suite Q1-Q8: realne wyniki

Osiem zapytań badawczych przepuszczonych przez pipeline w okresie marzec-maj 2026. Pięć zakończonych publikacją na 7/7 punktów.

Trzy z pięciu raportów wymagały korekty po pierwszym cyklu. We wszystkich trzech przypadkach to cold-blind verifier wykrył błąd, którego żaden inny mechanizm nie złapał:

Bez cold-blind verifiera każdy z tych raportów trafiłby do klienta z błędem 5-33%.

Trzy realne scenariusze użycia w marketingu

Pipeline statystyczny był projektowany do raportów konsultanta. W codziennej pracy marketingowca pokrywa trzy konkretne zastosowania, w których ryzyko halucynacji liczb jest największe.

Scenariusz 1: sizing segmentu rynku przed launchem produktu

Pytanie biznesowe: ile gospodarstw domowych w Polsce miesięcznie wydaje powyżej 200 zł na rozrywkę poza miejscem zamieszkania? To realna decyzja go/no-go dla launchu subskrypcyjnej platformy z benefitami rozrywkowymi.

Jak działa pipeline:

1. Router klasyfikuje pytanie jako intent=sizing, geo_scope=PL_country, primary_strategist=stat-strategist-bdl
2. Clarifier pyta o pięć rozwidleń: definicja „gospodarstwa” (statystyczne GUS vs podatkowe), zakres „rozrywki” (COICOP 09.4 wąsko vs całe 09), liczenie „poza miejscem zamieszkania” (turystyka GUS vs wszystkie wydatki out-of-home), próg 200 zł (per gospodarstwo vs per osoba w gospodarstwie), zakres czasowy (2024 vs trend)
3. Strategist BDL planuje fetch z GUS BBGD (struktura wydatków per decyl dochodowy), Eurostat HBS (porównanie z UE), GUS BDL P25 (struktura wydatków rocznych)
4. Prover pobiera dane, każdy claim z sha256
5. Drafter komponuje raport: liczba gospodarstw w decylu, struktura wydatków, trend pięcioletni, sizing rynku w PLN
6. Verifier replayuje URL-e i sprawdza arytmetykę agregacji

Co marketer dostaje: liczba potencjalnych klientów per decyl, średnia i mediana wydatku, trend pięcioletni z wykresem, oszacowanie wartości rynku TAM w PLN. Każda liczba z footnote i URL do GUS BBGD strona X tabela Y.

Wartość biznesowa: decyzja go/no-go z empirycznymi danymi zamiast intuicji założycieli. Q2 z test suite to praktycznie ten scenariusz. Czas: 30-60 minut zamiast 2 dni researchera.

Scenariusz 2: audyt cen konkurencji

Pytanie biznesowe: jakie ceny biletów oferują parki rozrywki w Polsce w sezonie 2026?

Jak działa pipeline:

1. Router kieruje do stat-strategist-branzowy (cenniki w PDF i web, BDL nie ma)
2. Clarifier pyta: jakie parki w zakresie analizy (top 10 wg frekwencji vs wszystkie PKD 93.21), jaka cena (jednodniowa vs sezonowa vs grupowa), z sezonu wysokiego czy niskiego
3. Strategist branżowy planuje fetch z oficjalnych stron parków plus agregator parkmag.pl
4. Prover wykonuje WebFetch dla statycznych cenników, WebSearch dla JS-renderowanych (Energylandia, Legendia mają dynamiczne ceny)
5. Drafter komponuje raport z porównaniem cen, średnią, medianą i zakresem
6. Verifier replayuje oficjalne URL parków (niezgodność hash = źródło zmieniło ceny od pobrania)

Co marketer dostaje: tabela cen z datą pobrania per pozycja, średnia 218 zł, mediana 204 zł, zakres 125-374 zł, link do każdej oficjalnej strony.

Wartość biznesowa: Q6 z test suite to dokładnie ten scenariusz. Cykl 1 wykrył błąd 33% w cenie Dinolandii. Gdyby raport trafił do prezentacji klienta, kampania pozycjonowania cenowego oparta byłaby na nieprawdziwym benchmarku. Cykl 2 naniósł korektę, raport publikowalny.

Scenariusz 3: brief researchowy do prezentacji klientowi

Pytanie biznesowe: ile średnio wydaje Polak na rozrywkę poza miejscem zamieszkania w trakcie roku?

Jak działa pipeline:

1. Router: intent=lookup_single plus secondary trend, geo_scope PL_country
2. Clarifier pyta o pięć rozwidleń definicyjnych (krajowy vs zagraniczny, COICOP 09.4 vs 09 całość, per pobyt vs per dzień, średnia vs mediana, 2024 vs trend)
3. Strategist BDL: GUS BBGD (Badanie Budżetów Gospodarstw Domowych), Eurostat tour_dem_exp, struktura per decyl dochodowy
4. Prover pobiera 12-14 claimów
5. Drafter komponuje raport z trzema wykresami (poziom 2024, trend 2019-2024, decyle dochodowe) i bibliografią z pełnymi URL
6. Verifier z arytmetyczną walidacją (Q7 case - sprawdzenie ratio kategorii)

Co marketer dostaje: PDF gotowy do wstawienia jako slajdy w deck klienta. Każda liczba ma footnote z URL i datą pobrania. Manifest integralności pozwala klientowi niezależnie zweryfikować, że plik nie został zmodyfikowany po wygenerowaniu.

Wartość biznesowa: klient nie obali Twojej prezentacji jednym googlowaniem. Footnote wskazuje GUS BBGD strona 75, tabela 14, pobrano 2026-05-18. Drift danych przez 3-6 miesięcy od publikacji wykryty automatycznie przy następnej aktualizacji - zero ryzyka, że na spotkaniu CEO klient cytuje świeższą liczbę z portalu branżowego.

Pięć reguł projektowych dla każdego zespołu agentów AI

Niezależnie od domeny pipeline ma pięć decyzji, które robią różnicę między prezentacją a produkcją.

Stos techniczny w skrócie

Pipeline działa w Python 3.11+ z minimalną listą zależności. Stack zaprojektowany pod prostotę debugowania, nie pod modne frameworki.

Nie ma LangGraph, nie ma CrewAI, nie ma MCP. Dla ośmiu agentów wystarczy prosty Python z dispatch z głównej sesji Claude Code. Verifier dispatchowany jako sub-agent z isolation: "worktree".

Granice systemu

Pipeline nie zastępuje analityka. Pokrywa konkretną klasę zadań: research statystyczny z urzędowych źródeł i raportów branżowych, gdzie odpowiedź jest weryfikowalna przez replay URL.

Nie nadaje się do:

• Pytań wymagających pierwotnego badania ankietowego (focus group, badania jakościowe)
• Analiz wymagających dostępu do niepublicznych źródeł (CRM klienta, dane sprzedażowe ERP)
• Pytań strategicznych typu „czy uruchomić X” (pipeline dostarczy dane, decyzja należy do człowieka)

Dobrze nadaje się do:

• Sizingu rynków i segmentów (GUS BDL, Eurostat, NBP)
• Audytów cen i benchmarków konkurencji (oficjalne strony, agregatory branżowe)
• Briefingów researchowych do prezentacji (każda liczba z przypisem inline)
• Analiz trendów czasowych (time-series z BDL plus prognoza)
• Weryfikacji statystyk w komunikacji prasowej (replay-spec sprawdza drift)

Multi-agent systemy nie eliminują człowieka z procesu researchu. Eliminują klasę błędów, którą człowiek wykrywa dopiero po zauważeniu, że klient zadaje niewygodne pytanie o źródło. W researchu statystycznym ta klasa błędów to halucynacja maskowana wiarygodną referencją.

Z dziewięcioma maszynowymi bramkami plus cold-blind weryfikatorem ta klasa po prostu nie przechodzi.

Pipeline opisany w tym artykule działa w środowisku Claude Code z Claude Opus 4.7 jako głównym modelem rozumowania oraz Claude Sonnet 4.6 jako routerem, clarifierem i proverem. Repozytorium robocze: statystyka/ z 8 agentami w .claude/agents/stat-*.md, 8 skryptami bramek w scripts/, test suite Q1-Q8 i pełnym workflowem w README. Dostęp do kodu i specyfikacji agentów udostępniam na życzenie do wglądu. Napisz na ecommerce@gorskie-resorty.pl.