Automatyczny fact-check treści AI skraca czas weryfikacji o 62%, ale nie zastępuje człowieka. Zbadaliśmy 200 twierdzeń z 20 tekstów generowanych przez pięć modeli językowych. Pipeline rozbija tekst na atomowe twierdzenia, szuka źródeł na poziomie fragmentu (nie całego dokumentu), wykrywa sprzeczności i ocenia konsensus. 77% twierdzeń rozwiązał automat, ale 23% trafiło do kolejki ręcznej – głównie sprzeczne źródła, granice fakt-opinia i dane zmienne w czasie. W artykule pokazujemy pełną metodologię, wyniki per klasa twierdzeń, a jako case study – fact-check naszego własnego artykułu o consensus score, gdzie znaleźliśmy cztery błędy patentowe, które żaden automat nie wykrył.
Parametry badania
| Parametr | Wartość |
|---|---|
| Teksty źródłowe | 20 (5 modeli x 4 tematy) |
| Łączna liczba twierdzeń | 200 |
| Klasy twierdzeń | stabilne fakty (62), dane zmienne (48), porównania (41), rekomendacje (49) |
| Weryfikatorzy ręczni | 2 specjalistów SEO + 1 specjalista branżowy |
| Narzędzia automatyczne | answer_claim_factuality_audit, consensus_evidence_pack, consensus_detect_contradictions, accuracy_predict_answer, content_qa_gate_orchestrator (GSCGA MCP) |
| Okres | lipiec-sierpień 2026 |
| Modele generujące | GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro, Llama 3.1, Mistral Large (zanonimizowane w wynikach) |
Dlaczego model nie może sam zatwierdzić własnych faktów?
Model językowy generuje tekst na podstawie wzorców statystycznych wyuczonych z danych treningowych, nie na podstawie weryfikacji z aktualnym źródłem. Gdy poprosi się ten sam model o sprawdzenie własnego tekstu, odwołuje się do tych samych wzorców – nie do niezależnego źródła. To jak pytanie autora, czy jego własna książka jest bezbłędna.
Problem pogarsza się, gdy do weryfikacji użyje się drugiego modelu tego samego typu. W naszym teście poprosiliśmy Model B o sprawdzenie tekstu wygenerowanego przez Model A. W 89% przypadków Model B oznaczył tekst jako „poprawny”. Gdy następnie te same twierdzenia zweryfikowaliśmy ręcznie z pierwotnymi źródłami, okazało się, że 31% z „potwierdzonych” twierdzeń było niepoprawnych, niepełnych lub nieweryfikowalnych. To nie jest fact-check – to echo chamber.
Dlaczego modele zatwierdzają nawzajem swoje błędy? Trzy główne przyczyny:
Wspólne źródła treningowe. Modele trenowane na podobnych korpusach (Common Crawl, Wikipedia, Reddit) internalizują te same błędy – o wpływie spójności między modalitościami na wiarygodność piszemy w artykule o multimodalnej spójności tekst-obraz. Jeśli popularne źródło podaje nieprawdziwą statystykę, oba modele ją powtórzą i oba uznają za poprawną. W naszej próbie 14 z 18 fałszywie potwierdzonych twierdzeń dotyczyło statystyk, które krążą w internecie bez weryfikowalnego źródła pierwotnego.
Brak dostępu do aktualnych danych. Model nie sprawdza bieżącej ceny, daty publikacji ani statusu patentu w bazie USPTO. Generuje odpowiedź na podstawie tego, co „widział” w danych treningowych. Jeśli patent zmienił status z „Application” na „Granted” po dacie cutoff modelu, model nadal będzie twierdził, że to aplikacja – i drugi model to potwierdzi.
Tendencja do potwierdzania. Modele językowe mają udokumentowaną skłonność do zgadzania się z treścią podaną w kontekście (sycophancy bias). Gdy model otrzymuje tekst do „weryfikacji”, traktuje go jako kontekst i buduje odpowiedź potwierdzającą, zamiast aktywnie szukać sprzeczności.
Jak rozbić tekst na atomic claims?
Atomic claim to najmniejsze twierdzenie, które można zweryfikować niezależnie od reszty tekstu. Zdanie „Nasz produkt jest szybszy i tańszy od konkurencji” to dwa odrębne twierdzenia: (1) jest szybszy od X, (2) jest tańszy od X. Każde wymaga osobnego źródła i osobnej weryfikacji.
W naszym pipeline answer_claim_factuality_audit rozbija tekst na atomic claims automatycznie. Narzędzie klasyfikuje każde twierdzenie do jednej z czterech kategorii: stabilny fakt (definicja, stała fizyczna, standard), dana zmienna w czasie (cena, statystyka, status), porównanie (wymaga baseline) i rekomendacja (wymaga oznaczenia jako opinia). Automatyczna ekstrakcja wymaga jednak ręcznej korekty – w naszym teście 12% twierdzeń wymagało ponownego rozbicia lub reklasyfikacji.
Najczęstsze problemy podczas ekstrakcji atomic claims:
| Problem | Przykład | Korekta | Częstość |
|---|---|---|---|
| Zbyt szerokie twierdzenie | „SEO jest ważne dla e-commerce” | Rozbić na: (1) ruch organiczny stanowi X% ruchu e-commerce (kluczowe dla pozycjonowania sklepu internetowego) [źródło], (2) konwersja z organic wynosi Y% [źródło] | 34% |
| Ukryte porównanie | „Produkt X jest szybszy” | Szybszy od czego? Dodać baseline i metodę pomiaru | 22% |
| Brak zakresu czasowego | „Cena wynosi 299 zł” | Dodać datę: stan na [data]. Oznaczyć jako dane zmienne | 19% |
| Opinia jako fakt | „Najlepsze rozwiązanie na rynku” | Oznaczyć jako opinion/unverifiable. Nie weryfikować – usunąć lub przeformułować | 15% |
| Złożone zdanie warunkowe | „Jeśli wdrożysz schema, ruch wzrośnie o 20%” | Rozbić na: (1) schema wpływa na ruch [warunek], (2) wzrost o 20% [źródło, zakres, okres] | 10% |
Praktyczna wskazówka. Pierwsze przejście automatyczne generuje około 8-12 twierdzeń na 1000 słów tekstu. Drugie przejście (ręczne) eliminuje duplikaty, scala nadmiernie rozdrobnione twierdzenia i reklasyfikuje graniczne przypadki. Typowy artykuł blogowy o 3000 słów daje 25-35 atomic claims do weryfikacji po obu przejściach. Warto wcześniej sprawdzić, czy artykuł odpowiada na rzeczywiste pytania z treści widoczne w GSC.
Źródło bez fragmentu nie jest wystarczającą atrybucją
Link do 50-stronicowego PDF-a nie jest źródłem twierdzenia – jest adresem dokumentu. Źródło to konkretny fragment: strona, paragraf, tabela lub akapit, w którym twierdzenie jest potwierdzone. Patent US20250103640A1 (przyznany jako US12346366B2, data pierwszeństwa 2023-09-21) opisuje mechanizm cytowań do konkretnych fragmentów dokumentów w chmurze – system generuje odpowiedź z precyzyjnym odniesieniem do passage, nie do całego pliku.
W naszym teście 34% twierdzeń miało podane „źródło” w formie linku do strony głównej lub całego raportu. Po wymuszeniu fragment-level attribution (wymaganie wskazania konkretnego akapitu, tabeli lub sekcji) liczba twierdzeń z realnym potwierdzeniem spadła o 18%. Powód: link istniał, ale twierdzenie nie było w cytowanym dokumencie potwierdzone. Model „pamiętał”, że gdzieś widział tę informację, i podawał najbliższy tematycznie URL.
Rozróżnienie między atrybucją na poziomie dokumentu a atrybucją na poziomie fragmentu ma bezpośrednie konsekwencje dla jakości treści. Artykuł, który twierdzi „według raportu McKinsey…” i linkuje do strony głównej McKinsey, nie spełnia standardu cytowalności. Artykuł, który twierdzi „według raportu McKinsey Global Institute z marca 2025, tabela 3, strona 47…” i linkuje do tego raportu – tak. Ten standard atrybucji jest fundamentem skutecznego content marketingu SEO.
Test fragment-level attribution: wyniki
| Typ atrybucji | Liczba twierdzeń | Potwierdzone po weryfikacji | Wskaźnik |
|---|---|---|---|
| Link do strony głównej / home | 28 | 4 (14%) | Bardzo niski |
| Link do artykułu / raportu (bez fragmentu) | 40 | 22 (55%) | Średni |
| Link do sekcji / paragrafu | 68 | 56 (82%) | Wysoki |
| Link do fragmentu z cytatem | 64 | 62 (97%) | Bardzo wysoki |
Wyniki potwierdzają intuicję: im precyzyjniejsze wskazanie źródła, tym wyższe prawdopodobieństwo, że twierdzenie jest faktycznie potwierdzone. Atrybucja na poziomie strony głównej jest praktycznie bezwartościowa (14% potwierdzeń), podczas gdy fragment z cytatem osiąga 97%.
Konsensus, sprzeczność i abstention – trzy stany weryfikacji
Po ekstrakcji twierdzeń i przypisaniu źródeł następuje etap oceny konsensusu. Nie wystarczy znaleźć jedno źródło, które potwierdza twierdzenie – trzeba sprawdzić, czy potwierdzenie pochodzi z niezależnych źródeł (nie kopii tego samego tekstu). Więcej o metodologii pomiaru konsensusu w artykule o consensus score.
W pipeline HITL każde twierdzenie otrzymuje jeden z pięciu statusów:
| Status | Definicja | Działanie | Udział w próbie |
|---|---|---|---|
| Grounded | Min. 2 niezależne źródła potwierdzają z precyzją na poziomie fragmentu | Publikuj bez zmian | 41% |
| Partially grounded | Źródło potwierdza rdzeń twierdzenia, ale nie szczegóły (zakres, datę, wielkość) | Uzupełnij brakujące szczegóły lub dodaj zastrzeżenie | 21% |
| Contradicted | Min. 1 wiarygodne źródło podaje inną wartość, datę lub wniosek | Kolejka ręczna: rozstrzygnij, które źródło jest aktualne/wiarygodniejsze | 12% |
| Unverifiable | Brak niezależnego źródła; twierdzenie opiera się na primary research lub danych wewnętrznych | Oznacz źródło jako dane własne lub usuń | 13% |
| Opinion | Twierdzenie wyraża preferencję, rekomendację lub ocenę wartościującą | Oznacz jako opinię autora. Nie prezentuj jako faktu | 14% |
Kluczowa metryka: abstention rate. To odsetek twierdzeń, dla których system automatyczny odmawia wydania werdyktu i przekazuje decyzję do człowieka. W naszym teście abstention rate wyniósł 23% (46 z 200 twierdzeń). Zbyt niski abstention rate (poniżej 10%) sugeruje, że system jest zbyt pewny siebie i akceptuje twierdzenia bez wystarczających dowodów. Zbyt wysoki (powyżej 40%) oznacza, że automatyzacja nie przynosi istotnej oszczędności czasu.
Wyniki testu 200 twierdzeń – rozkład per klasa
| Status | Stabilne fakty (n=62) | Dane zmienne (n=48) | Porównania (n=41) | Rekomendacje (n=49) | Łącznie |
|---|---|---|---|---|---|
| Grounded | 48 (77%) | 19 (40%) | 12 (29%) | 3 (6%) | 82 (41%) |
| Partially grounded | 8 (13%) | 14 (29%) | 11 (27%) | 8 (16%) | 41 (21%) |
| Contradicted | 2 (3%) | 8 (17%) | 9 (22%) | 4 (8%) | 23 (12%) |
| Unverifiable | 3 (5%) | 5 (10%) | 7 (17%) | 11 (22%) | 26 (13%) |
| Opinion | 1 (2%) | 2 (4%) | 2 (5%) | 23 (47%) | 28 (14%) |
Stabilne fakty – najwyższy grounding, najniższe ryzyko
Definicje techniczne, stałe parametry fizyczne i standardy (np. „USB-C obsługuje transfer do 40 Gbps w wersji 4.0”) miały najwyższy wskaźnik grounding: 77%. Modele dobrze radzą sobie z reprodukcją faktów, które są powszechnie udokumentowane i rzadko się zmieniają. Dwa twierdzenia contradicted w tej klasie dotyczyły parametrów technicznych, które zmieniły się w nowszej wersji standardu (model znał wersję starszą).
Dane zmienne w czasie – strefa najwyższego ryzyka
Ceny, udziały rynkowe, statystyki branżowe i statusy prawne (np. „patent US20230342411A1 ma status Application”) miały grounding na poziomie 40%. Problem polega na tym, że model podaje wartość z danych treningowych, a rzeczywistość mogła się zmienić. W naszym teście 8 z 48 twierdzeń o danych zmiennych było contradicted – model podawał starą cenę, nieaktualny udział rynkowy lub status dokumentu, który się zmienił.
Przykład z naszego testu: Tekst generowany przez AI podawał, że pewien patent Google ma status „Application”. Weryfikacja na Google Patents wykazała, że patent został przyznany (granted) kilka miesięcy wcześniej. Model nie miał tej informacji w danych treningowych. Automatyczny fact-check również tego nie wykrył, bo nie miał dostępu do bazy USPTO w trybie real-time. Dopiero człowiek sprawdzający wpisy w rejestrze patentowym znalazł rozbieżność.
Porównania – źródło 22% contradicted
Porównania („X jest szybszy od Y”, „A kosztuje mniej niż B”) generowały najwyższy odsetek sprzeczności: 22%. Główna przyczyna: różne źródła używają różnych baseline, metodologii pomiaru lub wersji produktu. Twierdzenie „React jest szybszym frameworkiem od Angular” jest niemożliwe do zweryfikowania bez określenia: szybszy pod jakim względem (rendering, bundle size, time to interactive), w jakim scenariuszu, mierzony jaką metodą.
W 9 przypadkach contradicted w klasie porównań ręczna weryfikacja wykazała, że oba źródła mają rację – po prostu mierzą różne aspekty. To właśnie ten typ twierdzeń, w którym automat nie jest w stanie rozstrzygnąć bez kontekstu branżowego. Człowiek musi zdecydować: usunąć porównanie, dodać kontekst lub zmienić formulację na warunkową.
Rekomendacje – 47% to opinie
Klasa rekomendacji („Warto wdrożyć schema markup”, „Najlepsza strategia to…”) miała najniższy grounding: 6%. Ale to nie błąd modelu – rekomendacja z definicji jest opinią, nie faktem. W 47% przypadków system poprawnie oznaczył je jako opinion. Problem pojawił się, gdy rekomendacja była sformułowana w sposób sugerujący fakt: „Schema markup zwiększa CTR o 30%” (prezentacja opinii jako mierzalnego faktu bez źródła).
Co nadal musi sprawdzić człowiek?
Pipeline automatyczny (claim extraction, source matching, contradiction detection, consensus scoring) rozwiązał 77% twierdzeń bez udziału człowieka. Ale 23% twierdzeń (46 z 200) trafiło do kolejki ręcznej weryfikacji. Poniżej rozbijamy te 46 przypadków na kategorie z przykładami i decyzjami.
| Powód eskalacji | Liczba | % | Typowy przykład | Decyzja człowieka |
|---|---|---|---|---|
| Sprzeczne źródła bez rozstrzygnięcia | 14 | 30% | Źródło A podaje CTR 2.1%, źródło B podaje 3.8% | Sprawdzić metodologię obu źródeł. Wybrać bardziej aktualne lub dodać oba z kontekstem |
| Kontekst branżowy wymagany | 11 | 24% | „Czas ładowania powyżej 3s jest zły” – dla e-commerce tak, dla aplikacji SaaS niekoniecznie | Dodać kontekst branżowy lub ograniczyć zasięg twierdzenia |
| Primary research bez zewnętrznego źródła | 9 | 20% | „W naszym teście 17% miało prawdziwy konsensus” – to dane własne Semgence | Oznaczyć jako dane własne. Podać metodologię, okres, próbę |
| Granica fakt-opinia | 8 | 17% | „Warto zacząć od audytu technicznego” – opinia czy best practice? | Zdecydować: usunąć, oznaczyć jako opinię lub dodać „w naszym doświadczeniu” |
| Dane nieaktualne – źródło przestarzałe | 4 | 9% | Statystyka z 2023 roku cytowana jako aktualna | Sprawdzić bieżące dane. Zaktualizować lub dodać datę źródła |
Automatyczny system skrócił czas weryfikacji z ok. 4 min/twierdzenie do ok. 1,5 min/twierdzenie (redukcja 62%), ale nie wyeliminował potrzeby ludzkiej oceny. System jest przygotowaniem dowodów, nie sędzią.
Case study: fact-check artykułu o consensus score – jak wykryliśmy 4 błędy patentowe
Najlepszym dowodem na to, że human-in-the-loop jest niezbędny, jest nasz własny proces publikacji. W sierpniu 2026 opublikowaliśmy na Semgence.pl artykuł o consensus score. Tekst został wygenerowany z pomocą AI, przeszedł przez pipeline automatycznego fact-checku, a następnie został ręcznie zweryfikowany. Ręczna weryfikacja wykryła cztery błędy, których żaden etap automatyczny nie wychwycił.
Błąd 1: Patent przyznany, ale opisany jako „Application”
Twierdzenie w tekście: „US20230342411A1 – status: Aplikacja (Application).”
Rzeczywistość: Patent został przyznany jako US12248529B2 w dniu 11 marca 2025 roku. Data pierwszeństwa to 9 marca 2022, nie 2023 jak podawał tekst. Model nie miał tej informacji, bo przyznanie nastąpiło po jego dacie odcięcia danych treningowych. Automatyczny pipeline nie wykrył błędu, ponieważ nie odpytywał bazy USPTO w czasie rzeczywistym.
Jak wykryto: Weryfikator ręcznie otworzył rekord patentu na patents.google.com i porównał status. Czas: 2 minuty.
Kategoria błędu: Dane zmienne w czasie. Model nie kłamie – podaje informację aktualną na moment treningu, która przestała być prawdziwa.
Błąd 2: Patent o reklamach opisany jako „grounding threshold”
Twierdzenie w tekście: „EP4713828A1 – grounding i próg zgodności względem źródła.”
Rzeczywistość: Patent EP4713828A1 nosi tytuł „Generative digital component creation” i dotyczy generowania komponentów reklamowych (digital ads), nie progów zgodności treści ze źródłem. Model prawdopodobnie zinterpretował fragment o „specified source of online content” jako mechanizm grounding, podczas gdy w kontekście patentu chodzi o treść reklamową dopasowaną do strony docelowej.
Jak wykryto: Weryfikator przeczytał abstract i independent claims patentu. Okazało się, że cały dokument dotyczy generowania reklam, nie weryfikacji faktów. Czas: 5 minut.
Kategoria błędu: Błędna interpretacja kontekstu. Model wyciągnął fragment z patentu i nadał mu znaczenie zgodne z tematem artykułu, ale niezgodne z rzeczywistą treścią dokumentu. Prawidłowe przypisanie encji do kontekstu to fundament entity SEO. To najgroźniejszy typ błędu – twierdzenie brzmi wiarygodnie i jest poparte numerem patentu, ale opisuje coś zupełnie innego.
Błąd 3: Kolejny patent przyznany, ale oznaczony jako aplikacja
Twierdzenie w tekście: „US20250103640A1 – cytowania do konkretnych fragmentów dokumentów, status: Aplikacja.”
Rzeczywistość: Patent został przyznany jako US12346366B2 w dniu 1 lipca 2025 roku. Data pierwszeństwa to 21 września 2023, nie 2024 jak podawał tekst. Co więcej, patent dotyczy konkretnie dokumentów w chmurze (cloud storage), nie ogólnego mechanizmu cytowań – opis w artykule był nieprecyzyjny.
Jak wykryto: Ten sam weryfikator, ten sam proces: otwarcie rekordu na Google Patents. Czas: 2 minuty.
Błąd 4: Uproszczony opis patentu
Twierdzenie w tekście: „US20240289395A1 – ocena faktyczności z elementem weryfikacji przez człowieka.”
Rzeczywistość: Patent (przyznany jako US12204524B1) dotyczy konkretnie „oceny faktyczności odpowiedzi generowanych przez LLM na podstawie zakodowanych pasaży kontekstowych” – to znacznie węższy zakres niż ogólna „ocena faktyczności”. Opis w artykule sugerował, że patent dotyczy human-in-the-loop weryfikacji, podczas gdy mechanizm jest w pełni automatyczny (LLM sam ocenia zgodność odpowiedzi z zakodowanymi pasażami). Element ludzki nie wynika z patentu, lecz z naszego workflow.
Jak wykryto: Weryfikator przeczytał independent claims i porównał z opisem w artykule. Czas: 4 minuty.
Podsumowanie case study
| Błąd | Klasa | Automat wykrył? | Człowiek wykrył? | Czas weryfikacji |
|---|---|---|---|---|
| Status patentu nieaktualny | Dane zmienne | Nie | Tak | 2 min |
| Patent o reklamach opisany jako grounding | Błędna interpretacja | Nie | Tak | 5 min |
| Status + data pierwszeństwa nieaktualne | Dane zmienne | Nie | Tak | 2 min |
| Uproszczony opis mechanizmu | Imprecyzja | Nie | Tak | 4 min |
Łączny czas ręcznej weryfikacji czterech patentów: 13 minut. Bez tego kroku artykuł zawierałby cztery błędy, w tym jeden poważny (EP4713828A1 opisany jako mechanizm fact-checkingu, podczas gdy dotyczy generowania reklam). Automat nie wykrył żadnego z tych błędów, ponieważ: (a) nie miał dostępu do aktualnej bazy patentowej, (b) nie potrafił odróżnić uproszczonego opisu od nieprawdziwego, (c) model weryfikujący miał te same ograniczenia co model generujący.
Jak wygląda proces content → fact-check w praktyce?
Na podstawie doświadczeń z serią artykułów na Semgence.pl (14 tekstów opublikowanych w sierpniu 2026) wypracowaliśmy 6-etapowy workflow, który łączy generowanie treści z weryfikacją.
Etap 1: Generowanie draftu z AI
Model generuje pierwszą wersję artykułu na podstawie briefu (temat, teza, struktura H2, narzędzia GSCGA MCP do użycia). Draft celowo zawiera wszystkie twierdzenia, statystyki i odniesienia do patentów – nawet jeśli model nie jest pewien ich poprawności. Lepiej mieć kompletny tekst do weryfikacji niż bezpieczny, ale pusty.
Etap 2: Automatyczna ekstrakcja twierdzeń
Pipeline answer_claim_factuality_audit rozbija tekst na atomic claims. Typowy artykuł blogowy (3000-5000 słów) generuje 30-50 twierdzeń. Narzędzie automatycznie klasyfikuje je do kategorii (fakt stabilny, dana zmienna, porównanie, rekomendacja) i przypisuje wstępny poziom pewności.
Etap 3: Automatyczne szukanie źródeł i detekcja sprzeczności
consensus_evidence_pack szuka źródeł per twierdzenie. consensus_detect_contradictions porównuje wartości, daty i jednostki między źródłami. Na wyjściu każde twierdzenie ma status: grounded, partially grounded, contradicted, unverifiable lub opinion.
Etap 4: Ręczna weryfikacja kolejki „human review”
Twierdzenia ze statusem contradicted, unverifiable i graniczne partially grounded trafiają do redaktora. Redaktor sprawdza źródła, konsultuje się ze specjalistą branżowym (jeśli potrzeba) i podejmuje decyzję: poprawić, usunąć, przeformułować lub oznaczyć jako opinię. Ten etap trwa średnio 1,5 min per twierdzenie.
Etap 5: Weryfikacja patentów i danych zmiennych
Osobny krok dla artykułów zawierających odwołania do patentów, statystyk rynkowych lub danych cenowych. Weryfikator otwiera każdy numer patentu na patents.google.com i sprawdza: tytuł, status, datę pierwszeństwa, wnioskodawcę i abstract. Dla statystyk – sprawdza źródło pierwotne i datę publikacji. Analogiczny problem dotyczy danych z OCR opakowań, gdzie automatyczne odczyty wymagają ludzkiej weryfikacji. To etap, który wykrył wszystkie 4 błędy w naszym case study.
Etap 6: QA gate przed publikacją
content_qa_gate_orchestrator uruchamia końcowe sprawdzenie: czy wszystkie twierdzenia mają status, czy nie ma nierozwiązanych contradicted, czy opinie są oznaczone, czy linki wewnętrzne działają. Dopiero po przejściu gate artykuł trafia do publikacji.
Pomiar czasu per etap (średnia z 14 artykułów):
| Etap | Czas (artykuł 3000 słów) | Kto |
|---|---|---|
| 1. Generowanie draftu | 15-30 min | AI + redaktor |
| 2. Ekstrakcja twierdzeń | 2-3 min | Automat |
| 3. Source matching + contradiction detection | 5-10 min | Automat |
| 4. Ręczna weryfikacja kolejki | 15-25 min (10-15 twierdzeń x 1,5 min) | Redaktor |
| 5. Weryfikacja patentów/danych | 10-20 min (zależnie od liczby patentów) | Weryfikator |
| 6. QA gate | 3-5 min | Automat + redaktor |
| Łącznie | 50-90 min |
Dla porównania: pełna ręczna weryfikacja tego samego artykułu (bez automatycznego pipeline) zajmowała średnio 2,5-3,5 godziny. Oszczędność czasu to nie 62% na pojedynczym twierdzeniu, ale ok. 55-60% na pełnym procesie – bo etapy 1-3 i 6 są zautomatyzowane, a etapy 4-5 skracają się dzięki przygotowanemu evidence packowi.
Cztery wzorce błędów modeli – taksonomia z 200 twierdzeń
Analiza 200 twierdzeń ujawniła cztery powtarzalne wzorce błędów, które występują niezależnie od modelu generującego. Każdy wzorzec wymaga innej strategii naprawczej.
Wzorzec 1: Temporal decay – dane, które się zestarzały
Częstość: 12 z 200 twierdzeń (6%). Dotyczy: cen, statusów, udziałów rynkowych, statystyk.
Model podaje wartość prawdziwą na moment treningu, ale nieaktualną w momencie publikacji. To zjawisko przypomina component drift – stopniowe rozsynchronizowanie danych między źródłem a publikacją. Automat nie wykrywa tego błędu, chyba że ma dostęp do aktualnej bazy danych. Naprawienie: weryfikacja z bieżącym źródłem (rejestr patentowy, cennik, raport kwartalny). Dodanie daty „stan na [data]” do każdej danej zmiennej.
Wzorzec 2: Context hallucination – prawdziwy element w fałszywym kontekście
Częstość: 8 z 200 twierdzeń (4%). Dotyczy: patentów, badań naukowych, cytatów.
Model podaje prawdziwy numer patentu, ale przypisuje mu funkcję, której patent nie opisuje (jak EP4713828A1 opisany jako grounding threshold). Podaje prawdziwą nazwę badania, ale przypisuje mu inny wniosek. Ten wzorzec jest najgroźniejszy, bo twierdzenie wygląda na dobrze udokumentowane – ma numer, tytuł, link – ale treściowo jest nieprawdziwe. Naprawienie: przeczytanie abstract i independent claims każdego cytowanego patentu. Porównanie opisu w artykule z faktyczną treścią dokumentu.
Wzorzec 3: Baseline omission – porównanie bez punktu odniesienia
Częstość: 15 z 200 twierdzeń (7,5%). Dotyczy: porównań wydajności, kosztów, jakości.
Model pisze „szybszy”, „tańszy”, „lepszy” bez podania: od czego, mierzony jak, w jakich warunkach, w jakiej wersji. Czytelnik przyjmuje ogólne porównanie jako fakt. Naprawienie: dodanie baseline („szybszy od X w benchmarku Y, wersja Z, stan na [data]”) lub zmiana na formulację bezwzględną („czas renderingu wynosi 1,2 s”).
Wzorzec 4: Confidence bleed – pewność modelu zamiast pewności źródła
Częstość: 11 z 200 twierdzeń (5,5%). Dotyczy: rekomendacji, najlepszych praktyk, prognoz.
Model prezentuje opinię lub best practice z taką samą pewnością jak fakt empiryczny. „Warto wdrożyć schema markup, bo zwiększa CTR o 30%” – druga część zdania wymaga źródła, ale jest podana jako oczywistość. Naprawienie: rozdzielenie rekomendacji od danych. „Schema markup może wpływać na CTR – a nagłówek jako adres odpowiedzi bezpośrednio determinuje, czy AI zacytuje dany fragment (według [źródło], wzrost wyniósł X% w kontekście Y). Warto rozważyć wdrożenie.”
Porównanie trzech podejść: ręczne, hybrydowe i w pełni automatyczne
| Metryka | Tylko człowiek | Hybrid (HITL) | Tylko automat |
|---|---|---|---|
| Czas per twierdzenie | 4,0 min | 1,5 min (kolejka) / 0,3 min (auto) | 0,3 min |
| Czas per artykuł (3000 słów, 35 claims) | 140 min | 50-90 min | 10 min |
| Wykryte temporal decay | 12/12 (100%) | 12/12 (100%) | 0/12 (0%) |
| Wykryte context hallucination | 8/8 (100%) | 8/8 (100%) | 1/8 (13%) |
| Wykryte baseline omission | 15/15 (100%) | 15/15 (100%) | 6/15 (40%) |
| Wykryte confidence bleed | 11/11 (100%) | 11/11 (100%) | 3/11 (27%) |
| Łączna skuteczność | 100% | 100% | 22% |
| Skalowalność (artykuły/dzień) | 2-3 | 6-8 | 50+ |
Wyniki pokazują, dlaczego w pełni automatyczny fact-check jest niewystarczający: wykrywa tylko 22% błędów. Podejście hybrydowe osiąga 100% skuteczności (identyczną z podejściem ręcznym), ale przy 55-60% oszczędności czasu. Pełna automatyzacja ma sens tylko dla wstępnego przesiewu (podobnie jak w first-chunk commerce, gdzie pierwszy fragment odpowiedzi AI decyduje o zaufaniu) – identyfikacji twierdzeń, które na pewno są poprawne, żeby człowiek mógł skupić się na reszcie.
Gotowa checklista redakcyjna
| Krok | Narzędzie | Kto | Czas |
|---|---|---|---|
| 1. Rozbij tekst na atomic claims | answer_claim_factuality_audit | Automat | 2-3 min |
| 2. Klasyfikuj twierdzenia (fakt/dana zmienna/porównanie/rekomendacja) | answer_claim_factuality_audit | Automat + redaktor | 5 min |
| 3. Znajdź źródło per claim (fragment-level) | consensus_evidence_pack | Automat | 5-10 min |
| 4. Wykryj sprzeczności między źródłami | consensus_detect_contradictions | Automat | 2-3 min |
| 5. Oceń consensus score | consensus_score_passages | Automat | 2 min |
| 6. Przejrzyj kolejkę ręczną (contradicted, unverifiable) | – | Redaktor | 15-25 min |
| 7. Zweryfikuj patenty i dane zmienne z aktualnymi źródłami | Google Patents, bazy danych | Weryfikator | 10-20 min |
| 8. Sprawdź, czy porównania mają baseline | – | Redaktor | 5 min |
| 9. Potwierdź, że rekomendacje i opinie są oznaczone | – | Redaktor | 3 min |
| 10. Uruchom końcowy QA gate | content_qa_gate_orchestrator | Automat | 3 min |
Patenty przywołane w artykule
| Numer zgłoszenia | Numer grantu | Tytuł | Właściciel | Data pierwszeństwa | Związek z artykułem |
|---|---|---|---|---|---|
| US20240289395A1 | US12204524B1 | Method and system for electronic processing of user queries maintaining factual consistency during processing | Google LLC | 2023-02-28 | direct – mechanizm oceny faktyczności odpowiedzi LLM na podstawie zakodowanych pasaży kontekstowych |
| EP4713828A1 | – | Generative digital component creation | Google LLC | 2023-12-29 | context only – dotyczy generowania komponentów reklamowych, nie weryfikacji faktów. Przywołany jako przykład błędnej interpretacji patentu przez AI |
| US20250103640A1 | US12346366B2 | Answers with citations to document passages (cloud storage) | Google LLC | 2023-09-21 | supporting – cytowania do fragmentów dokumentów w chmurze jako wzorzec atrybucji |
| US20230342411A1 | US12248529B2 | Multi source extraction and scoring of short query answers | Google LLC | 2022-03-09 | supporting – wieloźródłowy konsensus jako wstęp do oceny, nie zastępstwo decyzji redaktora |
Zastrzeżenie dotyczące patentów
Patenty przywołane w tym artykule opisują problemy techniczne i proponowane sposoby ich rozwiązania. Samo zgłoszenie lub udzielenie patentu nie dowodzi, że opisany mechanizm działa obecnie w wyszukiwarce Google ani że jest bezpośrednim czynnikiem rankingowym. W tym materiale patenty służą do budowy testowalnych hipotez, które zestawiamy z własnymi danymi i obserwacją działania systemów. Patent EP4713828A1 jest przywołany wyłącznie jako przykład błędu interpretacyjnego wykrytego podczas fact-checku – nie jako mechanizm wspierający tezę artykułu.
Źródła i narzędzia
Dane z testu 200 twierdzeń z 20 tekstów generowanych przez modele AI, lipiec-sierpień 2026. Nazwy modeli i tematów zanonimizowane. Weryfikacja ręczna przez dwóch specjalistów z minimum 3-letnim doświadczeniem w content SEO (dobór kompetencji weryfikatorów jest częścią szerszego audytu SEO) i jednego specjalistę branżowego. Case study fact-checku artykułu o consensus score opiera się na rzeczywistym procesie redakcyjnym Semgence.pl.
Zagadnienie weryfikacji faktów łączy się z consensus score, evidence SEO i fact-checkiem danych produktowych. Jeśli planujesz audyt widoczności w AI lub wdrażasz pozycjonowanie AI, fact-check treści jest jednym z pierwszych kroków.
| Narzędzie GSCGA MCP | Zastosowanie w pipeline |
|---|---|
| answer_claim_factuality_audit | Rozbicie na atomic claims, klasyfikacja, wstępna ocena |
| consensus_evidence_pack | Zbieranie dowodów per twierdzenie (fragment-level) |
| consensus_detect_contradictions | Detekcja sprzeczności między źródłami |
| consensus_score_passages | Scoring konsensusu per twierdzenie |
| accuracy_predict_answer | Predykcja poprawności odpowiedzi |
| content_qa_gate_orchestrator | Końcowy gate jakościowy przed publikacją |
