W zeszłym tygodniu budowałem AI content engine dla mojego Substacka i LinkedIna. System, który zbiera mój dyktowany tekst, robi research, pisze drafty, przygotowuje treści do mojego reviewu, zanim cokolwiek wyjdzie. W ciągu 48 godzin trzy razy złapałem ten sam typ błędu. Nie chodziło o to, że model się pomylił co do faktów. Chodziło o coś innego: model halucynował atrybucję. Cytował prawdziwe URL-e, ale przypisywał im twierdzenia, których tam nie ma.
To inna kategoria błędu AI niż zwykle pisze się w internecie. I jest ważniejsza niż brzmi, bo jest niewidoczna, dopóki ktoś faktycznie nie otworzy linka.
Pokażę dokładnie, co się stało, z dowodami w środku.
Case 1: statystyka 58% quoty
Poprosiłem research agenta (Perplexity Sonar-Pro) o kontekst do artykułu o Claude Design. W jednej z odpowiedzi pojawił się ostry data point: "dwie sesje designu mogą zużyć około 58% tygodniowej quoty użytkownika Pro". Cytat przypisany do strony intuitionlabs.ai.
Czysta statystyka. Konkretna liczba. Wiarygodne źródło. Idealny argument do sekcji "pricing to realny problem" w moim artykule.
Otworzyłem URL przed publikacją. Strona istnieje. Omawia szczegółowo pricing Claude. Ale liczby 58% nigdzie tam nie ma. Ani dosłownie, ani parafrazą. Liczba została wymyślona i przypisana do prawdziwego artykułu, który mówi o właściwym temacie, ale nigdy nie formułuje takiego twierdzenia.
Wyciąłem statystykę, zastąpiłem ją własnym obserwacyjnym data pointem z tamtego tygodnia.
Case 2: cytat Patricka Schabera
Ten sam artykuł, inne źródło. Agent zacytował post Substack porównujący Claude w PowerPoincie z Gammą. Twierdzenie: "Gamma is far superior to Claude in PowerPoint." Jednoznaczne, ostre, wygodne do użycia.
Otworzyłem URL. Artykuł jest prawdziwy. Autor jest prawdziwy. Test, który zrobił, jest prawdziwy. Ale rzeczywista konkluzja jest niejednoznaczna, nie jednostronna: Gamma wygrywa na designie i estetyce. Claude wygrywa na instruction-following i precyzji treści, szczególnie przy deckach skrojonych pod konkretną branżę. Fraza "far superior" w artykule istnieje, ale tylko w kontekście jednego wymiaru.
Publikacja oryginalnego cytatu zniekształciłaby pracę reviewera, a do tego osłabiłaby mój własny argument bardziej niż musiała. Przepisałem tę sekcję używając bezpośrednich cytatów z prawdziwego artykułu. Nowa wersja jest jednocześnie uczciwsza i bardziej użyteczna dla audytorium procurement.
Case 3: trzy fakty z Anthropic Enterprise Guide
Pracując nad inną Notą, poprosiłem o dane na temat enterprise adoption AI. Agent zwrócił trzy konkretne fakty, wszystkie przypisane do jednego źródła: Enterprise AI Transformation Guide od Anthropica:
- przychody Anthropica skoczyły z $87 milionów na początku 2024 do ponad $5 miliardów do sierpnia 2025
- Deloitte uruchomił Claude Center of Excellence z 15 000 wytrenowanych praktyków
- CTO globalnej firmy fintech powiedział "Claude has become the default AI for our entire engineering and legal teams"
Otworzyłem źródło. Żaden z trzech faktów nie jest w tej publikacji. Strona jest prawdziwa. To rzeczywiście materiał enterprise od Anthropica. Tylko że nie zawiera trajektorii przychodów, nie wymienia Deloitte, nie zawiera żadnego external CTO quote'a. Fakty mogą być częściowo prawdziwe gdzie indziej: trajektoria przychodów jest aktualna co do kierunku (i już mocno nieaktualna co do liczb, dziś Anthropic robi około $30B annualized), claim o Deloitte nie udało mi się zweryfikować nigdzie, a CTO quote nie ma identyfikowalnego źródła.
Trzy cytowania jednego URL. Trzy zerowe trafienia.
Powód architektoniczny
Wszystkie trzy case'y mają ten sam mechanizm. Warto go zrozumieć, bo mówi nam, którym AI research tool’om można zaufać przy jakim typie pracy.
Większość nowoczesnych AI research tooli (włącznie z Perplexity) działa na czymś, co nazywa się retrieval-augmented generation (RAG) na zacacheowanym indeksie webu. Tool pobiera krótkie fragmenty tekstu (snippety) z wielu stron, wrzuca je do modelu językowego, a model syntezuje odpowiedź. Cytowania są generowane na końcu jako lista URL-i, które tool uznał za relevantne.
Zauważ, czego tu brakuje: model nigdy nie trzyma całego artykułu. Syntezuje przez dziesiątki snippetów, a potem decyduje, które URL-e wpisać jako "źródła". Model nie śledzi czysto, który snippet z którego URL-a pochodzi, kiedy synteza już rusza. Więc kiedy dostajesz piękny akapit z czterema cytowaniami, niektóre z tych cytowań są post-hoc dekoracjami: prawdopodobnie powiązane źródła, które były w batch'u retrieval'a, ale nie faktyczne pochodzenie konkretnego twierdzenia w zdaniu.
To nie jest specyficzny fail Perplexity. To strukturalna własność RAG opartego na snippetach. Fakty mogą być poprawne. URL-e mogą być prawdziwe. Powiązanie między nimi jest improwizowane.
Dlaczego to ma znaczenie dla każdego, kto robi B2B content
W konsumenckim kontekście (ktoś pyta "w którym roku odpalił X?") to jest ok. Odpowiedź jest albo poprawna, albo nie. Atrybucja jest dekoracyjna.
W B2B (plany kategorii, briefingi dla zarządu, artykuły z imiennymi cytatami, analizy procurement, które lądują na biurku CFO), atrybucja nie jest dekoracyjna. To mechanizm, którym czytelnik weryfikuje, czy mówisz prawdę. Cytowanie wskazujące na URL, który nie zawiera danego twierdzenia, jest gorsze niż brak cytowania. Wygląda jak dowód. Nim nie jest.
Każdy, kto puszcza AI tooling przy procesach procurement (spend classifier, supplier scorecard, contract summarizer), powinien o tym wiedzieć, bo ten sam strukturalny fail tu obowiązuje. Jeśli tool AI mówi "zgodnie z kontraktem dostawcy X, klauzula 4.2 wymaga 30-dniowych terminów płatności", a ty nie otworzysz tej klauzuli 4.2, to nie wiesz, czy 4.2 w ogóle istnieje, czy mówi 30 czy 60 dni, czy całe to cytowanie to pewna siebie halucynacja.
AI tools nie mają shieldu wiarygodności. Ty go masz. I w momencie, w którym przestajesz weryfikować, shield spada.
Fix: trzywarstwowy research stack
Po złapaniu trzeciej halucynacji przebudowałem swoją research architekturę. Wygląda teraz tak:
Primary research robi AI, z którym i tak rozmawiam (w moim przypadku Claude w środowisku build) plus bezpośredni fetch URL-i. Model czyta pełne strony, nie snippety, więc atrybucja zostaje czysta. To jest gratis: i tak część toola.
Quick discovery używa Perplexity, ale tylko jako pierwszy rekonesans ("co internet mówi szeroko o X?") i nigdy jako finalne źródło cytowanego twierdzenia. Każdy URL, który zwróci, traktuję jako lead, nie jako dowód.
Deep research dla flagowych artykułów to Gemini Deep Research (multi-step agent, który faktycznie otwiera i czyta strony). Nadaje się do miesięcznych market recapów, benchmarków, czy artykułów, gdzie 20+ źródeł trzeba zsyntezować. Wolniejszy, droższy, ale architektura pasuje do potrzeby.
Nienegocjowalny quality gate: każde cytowanie w finalnym draft'cie jest zweryfikowane otwarciem URL-a przed publikacją. Pięć minut weryfikacji złapało w tym tygodniu trzy błędy faktograficzne. I będzie łapać dalej.
Co praktycy procurement mogą z tym zrobić
Dwie rzeczy.
Po pierwsze, jeśli używasz AI do czegokolwiek, co dotyka danych zewnętrznych (analiza kontraktów, market research, supplier due diligence), załóż, że atrybucja jest dekoracyjna, dopóki nie udowodnisz inaczej. Wbij jeden krok weryfikacji w swój workflow, gdzie ktoś otwiera przynajmniej top 2-3 cytowane URL-e. Trwa minuty. Chroni cię przed pewną siebie pomyłką.
Po drugie, nie myl "model odpowiedział" z "model dał poprawną odpowiedź". Nowoczesne research tool’e są szybkie i mylą się w bardzo specyficzny sposób. Pomyłki mają kształt, nie są losowe. Mieszkają w atrybucji, w numerycznej specyficzności, i w syntezowanych cytatach. Naucz się, gdzie się chowają, a możesz dalej używać tych narzędzi bez bycia oparzonym.
Złapałeś AI cytując coś, czego nie ma, albo coś, co nie mówi tego, co AI twierdziło? Napisz, co znalazłeś. Zbieram przykłady. Im więcej wzorców widzimy, tym łatwiej budować workflow, który łapie je domyślnie.
Jeśli pracujesz w zakupach i myślisz o tym, jak wbudować takie verification gate w swój własny AI workflow (kontrakty, RFP, supplier intel), umów krótkie spotkanie. Pół godziny rozmowy często wystarcza, żeby zobaczyć, gdzie w obecnym setupie są dziury.
