Największy błąd w rozmowie o halucynacjach AI polega na traktowaniu ich jak usterki, którą da się po prostu wyłączyć.
Nie da się.
Nie istnieje dziś wiarygodna metoda, która gwarantowałaby, że duży model językowy nigdy nie poda fałszywej informacji. Możemy budować lepsze modele, podłączać je do internetu, dawać im dokumenty, wymagać cytowań i kazać sprawdzać własne odpowiedzi. Ryzyko można w ten sposób mocno ograniczyć. Nie można go jednak sprowadzić do zera.
I właśnie dlatego najbardziej zaawansowane systemy AI coraz mniej przypominają samotny model odpowiadający na prompt.
Zaczynają przypominać cały proces kontroli informacji.
Model najpierw szuka danych. Następnie wybiera najbardziej wiarygodne fragmenty. Generuje odpowiedź na podstawie dowodów. Dołącza źródła. Osobny mechanizm sprawdza poszczególne twierdzenia. Jeżeli dowodów jest za mało, system powinien odmówić odpowiedzi albo skierować sprawę do człowieka.
W uproszczeniu wygląda to tak:
wyszukiwanie → selekcja źródeł → generowanie → cytowanie → weryfikacja → ocena niepewności → odpowiedź albo odmowa
To znacznie ważniejsza zmiana niż kolejna poprawa promptu.
Czym właściwie jest halucynacja AI?
Najprostsza definicja brzmi:
halucynacja występuje wtedy, gdy model przedstawia informację jako prawdziwą, mimo że jest ona fałszywa, niepotwierdzona albo sprzeczna z dostępnymi dowodami.
Problem jest jednak szerszy niż zwykłe wymyślenie faktu.
Model może:
• stworzyć nieistniejący wyrok, publikację albo osobę,
• podać liczbę inną niż ta znajdująca się w źródle,
• powołać się na prawdziwy artykuł, który wcale nie potwierdza danego wniosku,
• przedstawić nieaktualną informację jako bieżącą,
• poprawnie przytoczyć fakty, ale wyprowadzić z nich błędny wniosek,
• twierdzić, że coś sprawdził, mimo że narzędzie nie zostało uruchomione,
• wykorzystać starą lub błędną informację zapisaną wcześniej w pamięci agenta.
Ta ostatnia grupa błędów będzie coraz istotniejsza.
W przypadku prostego chatbota problem kończy się zwykle na niepoprawnej odpowiedzi. Agent AI może natomiast twierdzić, że wysłał wiadomość, sprawdził bazę, wykonał przelew, zmienił plik albo przeanalizował stronę internetową.
W takim systemie nie wystarcza już kontrolowanie tekstu.
Potrzebny jest także dowód wykonania operacji.
Dlaczego modele w ogóle halucynują?
Warto zacząć od jednej fundamentalnej rzeczy.
Klasyczny model językowy nie został pierwotnie wytrenowany do rozstrzygania, czy zdanie jest prawdziwe.
Jego podstawowe zadanie polega na przewidywaniu kolejnego fragmentu tekstu.
Jeżeli model dostaje:
Stolicą Francji jest…
bardzo prawdopodobnym następnym tokenem będzie „Paryż”.
Ale dokładnie ten sam mechanizm działa przy pytaniu o mało znaną publikację, niszowy przepis prawa, wynik badania albo wydarzenie, którego model nigdy nie widział.
Model nadal próbuje wygenerować najbardziej prawdopodobną kontynuację.
Płynność języka jest więc naturalnym skutkiem sposobu treningu.
Prawdziwość niekoniecznie.
Problem dodatkowo pogłębiają dane treningowe. Mogą być niekompletne, sprzeczne, nieaktualne albo bardzo nierównomiernie reprezentować poszczególne fakty.
Im rzadsza i bardziej zmienna informacja, tym gorszym pomysłem jest traktowanie pamięci modelu jak bazy danych.
Dlatego pytanie:
„Czy model zna odpowiedź?”
coraz częściej powinno zostać zastąpione pytaniem:
„Czy system potrafi znaleźć dowód potwierdzający odpowiedź?”
Sam prompt nie rozwiąże problemu
Jedna z najpopularniejszych metod ograniczania halucynacji wygląda mniej więcej tak:
Nie zgaduj. Jeżeli nie znasz odpowiedzi, napisz, że nie wiesz.
To sensowna instrukcja.
Ale jej skuteczność jest ograniczona.
Znacznie lepszy prompt zmienia cały kontrakt z modelem:
Korzystaj wyłącznie z dostarczonych źródeł.Dla każdego istotnego twierdzenia wskaż dowód.Jeżeli źródło nie potwierdza informacji, oznacz brak danych.Najpierw znajdź cytaty, dopiero później sformułuj wnioski.
Anthropic rekomenduje między innymi podejście polegające na wcześniejszym wydobyciu bezpośrednich cytatów z dokumentów i dopiero późniejszej syntezie odpowiedzi.
To bardzo dobry wzorzec.
Nadal jednak pracujemy z tym samym modelem.
Jeżeli system naprawdę ma być odporny na halucynacje, potrzebujemy zewnętrznego źródła prawdy.
RAG pomaga. RAG nie wystarcza
Przez ostatnie lata RAG, czyli Retrieval Augmented Generation, stał się niemal domyślną odpowiedzią na problem halucynacji.
Pomysł jest prosty.
Zamiast liczyć wyłącznie na wiedzę zapisaną w parametrach modelu, przed wygenerowaniem odpowiedzi wyszukujemy odpowiednie dokumenty i przekazujemy je do kontekstu.
To działa.
Ale nie tak niezawodnie, jak czasami sugeruje marketing.
RAG może zwrócić:
• niewłaściwy dokument,
• fragment podobny semantycznie, ale nieodpowiadający na pytanie,
• starą wersję informacji,
• kilka sprzecznych źródeł,
• zbyt dużo materiału naraz.
Nawet jeżeli retriever znajdzie prawidłowy fragment, model nadal może go źle zinterpretować albo dopisać informacje spoza dokumentu.
RAGTruth, zbiór niemal 18 tysięcy odpowiedzi wygenerowanych w systemach wykorzystujących retrieval, pokazuje właśnie ten problem. Sam fakt dostarczenia modelowi dokumentów nie gwarantuje, że późniejsza odpowiedź będzie wierna tym dokumentom.
Dlatego dojrzały system nie kończy się na:
wyszukaj → odpowiedz
Potrzebuje kolejnych etapów.
Reranking: mały element, który robi dużą różnicę
Wyobraźmy sobie, że wyszukiwarka znalazła 20 fragmentów.
Wszystkie są mniej więcej związane z pytaniem.
Tylko trzy rzeczywiście zawierają odpowiedź.
Wrzucenie wszystkich 20 fragmentów do kontekstu niekoniecznie poprawi wynik. Może wręcz zwiększyć szum.
Tu pojawia się reranker.
Jego zadaniem jest ponowne ocenienie znalezionych materiałów i wybranie tych, które najlepiej odpowiadają konkretnemu pytaniu.
W praktyce skuteczny pipeline wygląda więc raczej tak:
query → retrieval → reranking → evidence → generation
Corrective RAG rozwija tę koncepcję jeszcze dalej. System ocenia jakość znalezionych dowodów. Jeżeli są słabe, może zmienić strategię, rozszerzyć wyszukiwanie albo sięgnąć po zewnętrzne źródła.
To ważna zmiana filozofii.
Nie zakładamy już, że retrieval zadziałał.
Sprawdzamy, czy zadziałał.
Weryfikuj twierdzenia, a nie całą odpowiedź
To prawdopodobnie jeden z najważniejszych wniosków z ostatnich badań.
Nie wystarczy zapytać drugiego modelu:
Czy ta odpowiedź jest poprawna?
Długi tekst może zawierać dziesięć poprawnych informacji i jedną niebezpieczną halucynację.
Dlatego odpowiedź należy najpierw rozbić na atomowe twierdzenia.
Przykładowo zdanie:
Firma została założona w 2018 roku w Warszawie i zatrudnia obecnie 250 osób.
zawiera co najmniej trzy fakty:
- firma została założona w 2018 roku,
- została założona w Warszawie,
- zatrudnia 250 osób.
Każdy z nich może wymagać osobnego dowodu.
Na tej zasadzie działa FActScore.
Podobny kierunek rozwija SAFE od Google DeepMind. System rozbija długą odpowiedź na fakty, wyszukuje informacje potwierdzające i ocenia każdy fakt oddzielnie.
W badaniu obejmującym około 16 tysięcy faktów SAFE osiągał 72 procent zgodności z ludzkimi anotatorami. W ręcznej analizie 100 przypadków, w których człowiek i SAFE się nie zgadzali, dodatkowi sędziowie uznali ocenę SAFE za poprawną w 76 przypadkach.
Nie oznacza to, że automatyczny fact checking jest rozwiązanym problemem.
Pokazuje natomiast bardzo ważny kierunek:
kontrola powinna działać na poziomie pojedynczych twierdzeń, nie całych akapitów.
AI powinno umieć powiedzieć „nie wiem”
To brzmi banalnie, ale może być jednym z najważniejszych mechanizmów bezpieczeństwa.
Model, który odpowiada na 100 procent pytań, wcale nie musi być lepszy od modelu odpowiadającego na 90 procent.
Jeżeli te brakujące 10 procent stanowią przypadki, w których system nie posiada wystarczających dowodów, odmowa może być dokładnie tym, czego potrzebujemy.
Problem tkwi między innymi w sposobie oceniania modeli.
OpenAI zwróciło uwagę, że wiele benchmarków tworzy zachętę do zgadywania. Jeżeli brak odpowiedzi daje zero punktów i błędna odpowiedź również daje zero punktów, statystycznie opłaca się próbować odpowiedzieć.
R-Tuning pokazuje, że model można trenować inaczej.
Można nauczyć go rozpoznawania obszarów, w których wiedza jest niewystarczająca, i świadomego odmawiania odpowiedzi.
W produkcji oznacza to, że nie powinniśmy mierzyć wyłącznie accuracy.
Musimy uwzględniać kompromis między ryzykiem i coverage, czyli procentem pytań, na które system decyduje się odpowiedzieć.
System odpowiadający na 95 procent pytań z błędem 0,5 procent może być znacznie wartościowszy niż system odpowiadający zawsze, ale popełniający błędy w 4 procentach przypadków.
Confidence modelu nie oznacza prawdopodobieństwa prawdy
Modele potrafią brzmieć niezwykle pewnie również wtedy, gdy się mylą.
Dlatego tekst typu:
Jestem w 95 procentach pewny…
nie powinien być automatycznie interpretowany jako rzeczywiste 95 procent prawdopodobieństwa poprawności.
Potrzebujemy kalibracji.
Jedną z interesujących metod jest Semantic Entropy.
Zamiast patrzeć wyłącznie na prawdopodobieństwo poszczególnych słów, metoda generuje różne odpowiedzi i grupuje je według znaczenia.
Jeżeli model raz odpowiada A, drugi raz B, a trzeci raz C, mamy istotny sygnał niepewności.
Jeżeli dziesięć różnych stylistycznie odpowiedzi przekazuje dokładnie ten sam sens, sytuacja wygląda inaczej.
W badaniu opublikowanym w „Nature” Semantic Entropy osiągnęła średni AUROC około 0,790 w 30 kombinacjach modeli i zadań.
To nadal detektor ryzyka, nie maszyna do ustalania prawdy.
Może jednak powiedzieć systemowi:
„tu prawdopodobieństwo problemu jest na tyle wysokie, że lepiej przeprowadzić dodatkową kontrolę”.
Jak radzą sobie OpenAI, Anthropic, Google i Mistral?
Najciekawsze jest to, że liderzy rynku coraz częściej dochodzą do podobnego wniosku.
Nie wystarczy poprawiać sam model.
OpenAI
OpenAI łączy poprawę modeli z dostępem do narzędzi takich jak web search i file search, a także z osobnymi ewaluacjami factuality, odmowy odpowiedzi i zachowania agentów.
Szczególnie interesujący jest rozwój testów dotyczących fałszywego raportowania wykonanych operacji.
Agent nie powinien móc stwierdzić:
Sprawdziłem wyszukiwarkę.
jeżeli wyszukiwarka była niedostępna.
W takim przypadku źródłem prawdy powinien być log wywołania narzędzia.
Anthropic
Anthropic mocno stawia na provenance, czyli możliwość prześledzenia, skąd pochodzi informacja.
Claude może pracować na bezpośrednich cytowaniach, korzystać z web search i narzędzi, a dokumentacja wprost rekomenduje pozwolenie modelowi na stwierdzenie, że czegoś nie wie.
To pozornie mała decyzja projektowa.
W rzeczywistości oznacza odejście od założenia, że asystent musi zawsze mieć odpowiedź.
Google DeepMind
Google inwestuje mocno w grounding.
Model może być oparty zarówno na wynikach wyszukiwarki, jak i prywatnych źródłach przedsiębiorstwa.
Jednocześnie DeepMind rozwija benchmarki factuality.
W opublikowanym w grudniu 2025 roku zestawieniu FACTS Suite najlepszy wynik ogólny osiągał 68,8 procent, a wszystkie oceniane modele pozostawały poniżej 70 procent.
Nie jest to wynik opisujący cały rynek w 2026 roku, ani coś, co można bezpośrednio porównywać z innymi benchmarkami.
Pokazuje jednak skalę problemu.
Nawet najlepsze modele nadal nie są uniwersalnymi maszynami do generowania prawdy.
Mistral i open source
Mistral publikuje bardzo praktyczne wzorce obejmujące klasyczny RAG, adaptive RAG, wyszukiwanie internetowe, hybrid retrieval, reranking, Graph RAG i ewaluację faithfulness.
W świecie otwartych modeli pojawia się też inna przewaga.
Nie musimy mieć modelu z najniższym bazowym poziomem halucynacji.
Możemy za to zbudować znacznie bardziej kontrolowany system dla konkretnego zastosowania.
Własny retriever.
Własny reranker.
Własne źródła.
Własny detektor błędów.
Własny verifier.
Własne reguły odmowy odpowiedzi.
W wielu zastosowaniach firmowych taka kontrola może być ważniejsza niż kilka punktów przewagi modelu na ogólnym benchmarku.
Najlepsza architektura nie próbuje „zakazać halucynacji”
Jeżeli factuality rzeczywiście ma znaczenie, projektowałbym dziś system według następującego schematu:
1. Klasyfikacja pytania
Czy odpowiedź wymaga aktualnych albo specjalistycznych faktów?
Jeżeli nie, można korzystać z wiedzy modelu.
Jeżeli tak, uruchamiane są źródła zewnętrzne.
2. Retrieval
System przeszukuje dokumenty, bazę wiedzy, wyszukiwarkę, API albo inną autorytatywną bazę.
3. Ocena jakości źródeł
Nie każdy wynik wyszukiwania powinien być traktowany tak samo.
Liczą się między innymi aktualność, autorytet źródła i zgodność z pytaniem.
4. Reranking
Najbardziej przydatne fragmenty trafiają do właściwego kontekstu modelu.
5. Generowanie na podstawie dowodów
Model powinien wiedzieć, z jakich informacji wolno mu korzystać.
6. Atomizacja odpowiedzi
Gotowy tekst zostaje rozbity na pojedyncze twierdzenia.
7. Weryfikacja
Każde istotne twierdzenie jest porównywane ze źródłem.
8. Cytowania
Źródło powinno być przypisane do konkretnego twierdzenia, a nie jedynie wrzucone gdzieś pod odpowiedzią.
9. Ocena niepewności
System określa, czy jakość dowodów pozwala na udzielenie odpowiedzi.
10. Odmowa lub eskalacja
Jeżeli dowodów brakuje, system nie powinien uzupełniać luk wyobraźnią modelu.
W zastosowaniach krytycznych sprawa może trafić do człowieka.
To zupełnie inne podejście niż:
Weźmy najlepszy dostępny model i napiszmy mu w promptcie, żeby nie halucynował.
W prawie problem jest szczególnie niebezpieczny
Wyobraźmy sobie system analizujący stan prawny.
Model może poprawnie opisać ogólną zasadę, ale podać nieistniejącą sygnaturę.
Może znaleźć rzeczywiste orzeczenie, które dotyczy innego problemu.
Może przytoczyć przepis w wersji obowiązującej dwa lata wcześniej.
Może też poprawnie odczytać ustawę i wyprowadzić z niej niepoprawny wniosek.
Dlatego aplikacja prawna powinna kontrolować co najmniej:
• jurysdykcję,
• datę obowiązywania przepisu,
• źródło aktu,
• źródło orzeczenia,
• zgodność cytatu z oryginałem,
• powiązanie pomiędzy konkretnym twierdzeniem a podstawą prawną.
Sygnatury, numery artykułów czy cytaty nie powinny być swobodnie generowane.
Powinny pochodzić ze źródła i być programowo sprawdzalne.
Jeżeli podstawy prawnej nie uda się potwierdzić, poprawnym wynikiem systemu może być:
„brak wystarczających danych do odpowiedzi”.
To lepsze niż bardzo przekonująca fikcja.
Przy generowaniu kodu najlepszym fact checkerem jest wykonanie
W programowaniu problem wygląda nieco inaczej.
Model może wymyślić nieistniejącą metodę API.
Może wykorzystać funkcję usuniętą w aktualnej wersji biblioteki.
Może powiedzieć, że testy przeszły, mimo że ich nie uruchomił.
Tutaj najbardziej wiarygodnym weryfikatorem nie jest kolejny model.
Jest nim środowisko wykonawcze.
Dobry agent programistyczny powinien korzystać z:
• dokumentacji odpowiedniej wersji,
• repozytorium projektu,
• type checkera,
• kompilatora,
• lintowania,
• testów jednostkowych,
• testów integracyjnych,
• kontrolowanego sandboxa,
• logów wykonanych operacji.
Jeżeli agent twierdzi, że test przeszedł, powinniśmy móc zobaczyć wynik testu.
Jeżeli mówi, że plik został zmieniony, powinniśmy móc zobaczyć diff.
To ważna zasada, która będzie dotyczyć coraz większej części agentowego AI:
nie ufaj deklaracji modelu, jeżeli możesz sprawdzić stan świata.
Jak sprawdzić, czy nasz system rzeczywiście halucynuje mniej?
Tu firmy często popełniają kolejny błąd.
Wdrażają RAG albo nowy model, uruchamiają kilkadziesiąt przykładów i stwierdzają:
Wygląda lepiej.
To za mało.
Powinniśmy mierzyć kilka różnych rzeczy.
Factual precision
Jaki procent twierdzeń faktycznie jest poprawny?
Hallucination rate
Jaki procent odpowiedzi zawiera przynajmniej jedno niepoparte albo błędne twierdzenie?
Citation precision
Czy podane źródło rzeczywiście potwierdza zdanie, do którego zostało przypisane?
Citation completeness
Czy wszystkie istotne twierdzenia wymagające dowodu mają źródło?
Retrieval recall
Czy system w ogóle znalazł dokument potrzebny do odpowiedzi?
Risk at coverage
Jak często system się myli przy określonym procencie pytań, na które decyduje się odpowiedzieć?
Correct abstention
Czy odmawia odpowiedzi wtedy, gdy powinien?
Over refusal
Czy nie zaczyna odmawiać również w prostych przypadkach, które mógłby bezpiecznie obsłużyć?
Action groundedness
Czy deklarowane przez agenta działania rzeczywiście znajdują się w logach narzędzi?
Dopiero taki zestaw daje sensowny obraz.
Najlepszy eksperyment? Porównaj cały stos, nie tylko modele
Bardzo sensowny test produkcyjny można przeprowadzić etapami.
Wariant A: model i zwykły prompt
To baseline.
Wariant B: lepszy kontrakt epistemiczny
Dodajemy instrukcję niezgadywania, cytowania i możliwość odmowy odpowiedzi.
Wariant C: RAG
System otrzymuje dostęp do dokumentów.
Wariant D: zaawansowany grounding
Dochodzą query rewriting, hybrid retrieval, reranking oraz filtrowanie źródeł według jakości i aktualności.
Wariant E: pełna weryfikacja
Odpowiedź zostaje rozbita na twierdzenia, które sprawdza osobny verifier. Następnie działa mechanizm confidence gate, regeneracja albo odmowa.
W zastosowaniach o wysokiej odpowiedzialności można dodać jeszcze człowieka.
Najważniejsze, aby identyczne pytania przechodziły przez wszystkie konfiguracje.
Dzięki temu naprawdę sprawdzamy wpływ architektury, zamiast porównywać przypadkowe zestawy odpowiedzi.
Nie potrzebujemy AI, które „nigdy się nie myli”
To prawdopodobnie najważniejszy wniosek.
Cel „zero halucynacji” brzmi dobrze marketingowo, ale nie jest rozsądną specyfikacją systemu.
Znacznie lepiej powiedzieć:
Co najmniej 99,x procent krytycznych twierdzeń musi posiadać zweryfikowane źródło. Jeżeli dowodu nie ma, system powinien odmówić odpowiedzi albo przekazać przypadek do człowieka.
Takie wymaganie można zmierzyć.
Można je testować.
Można obserwować jego degradację w produkcji.
Można ustawić alert.
Można porównać kolejne wersje systemu.
To przejście od wiary w model do inżynierii niezawodności.
I prawdopodobnie właśnie w tę stronę będzie zmierzać dojrzałe wykorzystanie AI.
Najlepszy system nie będzie tym, który najrzadziej przyznaje, że czegoś nie wie.
Będzie tym, który potrafi znaleźć dowód, pokazać jego źródło, sprawdzić własne twierdzenia i zatrzymać się wtedy, gdy dowodu brakuje.
Przyszłość wiarygodnego AI nie polega więc na wyeliminowaniu możliwości popełnienia błędu. Polega na zamianie niekontrolowanego zgadywania w kontrolowany proces pozyskiwania dowodów, weryfikacji i bezpiecznej odmowy odpowiedzi.
Źródła
- OpenAI, Why language models hallucinate
https://openai.com/index/why-language-models-hallucinate/ - OpenAI, File search
https://developers.openai.com/api/docs/guides/tools-file-search - Sharma et al., Towards Understanding Sycophancy in Language Models
https://doi.org/10.48550/arXiv.2310.13548 - OpenAI, GPT-6 Astra System Card
https://deploymentsafety.openai.com/gpt-6-astra - Google DeepMind, The FACTS Grounding Leaderboard: Benchmarking LLMs’ Ability to Ground Responses to Long-Form Input
https://arxiv.org/abs/2501.03200 - Anthropic, Reduce hallucinations
https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/reduce-hallucinations - Chuang et al., DoLa: Decoding by Contrasting Layers Improves Factuality in Large Language Models
https://arxiv.org/abs/2309.03883 - Zhang et al., R-Tuning: Instructing Large Language Models to Say “I Don’t Know”
https://aclanthology.org/2024.naacl-long.394/ - Niu et al., RAGTruth: A Hallucination Corpus for Developing Trustworthy Retrieval-Augmented Language Models
https://aclanthology.org/2024.acl-long.585/ - MemGuard: Preventing Memory Contamination in Long-Term Memory Systems
https://arxiv.org/html/2605.28009v1 - Mistral AI, Concepts: a visual tour of the Mistral Search Toolkit
https://docs.mistral.ai/resources/cookbooks/mistral-rag-00-introduction-concepts - OpenAI, Web search
https://developers.openai.com/api/docs/guides/tools-web-search - Dhuliawala et al., Chain-of-Verification Reduces Hallucination in Large Language Models
https://arxiv.org/abs/2309.11495 - Wei et al., Long-form factuality in large language models
https://arxiv.org/abs/2403.18802 - Farquhar et al., Detecting hallucinations in large language models using semantic entropy, Nature
https://www.nature.com/articles/s41586-024-07421-0 - Yan et al., Corrective Retrieval Augmented Generation
https://arxiv.org/abs/2401.15884 - Min et al., FActScore: Fine-grained Atomic Evaluation of Factual Precision in Long Form Text Generation
https://arxiv.org/abs/2305.14251 - Google Cloud, Grounding with Elasticsearch
https://docs.cloud.google.com/vertex-ai/generative-ai/docs/grounding/grounding-with-elasticsearch - Google DeepMind, FACTS Benchmark Suite
https://deepmind.google/ - Meta AI, Llama 3.2
https://ai.meta.com/ - Mistral AI, Adaptive RAG with LangChain
https://docs.mistral.ai/resources/cookbooks/third_party-langchain-adaptive_rag_mistral - Asai et al., Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection
https://arxiv.org/abs/2310.11511 - OpenAI, GPT-5 System Card
https://deploymentsafety.openai.com/gpt-5/opqa - OpenAI, Evaluation best practices
https://developers.openai.com/api/docs/guides/evaluation-best-practices - OpenAI, Introducing SimpleQA
https://openai.com/index/introducing-simpleqa/
Dyskusja