Sześć koncepcji sztucznej inteligencji, które podpowiedzą ci, co sprawdzić przed zaufaniem odpowiedzi
Tokeny, okna kontekstowe, temperatura, halucynacje, RAG oraz agenci wyjaśnione jako narzędzia weryfikacyjne, które pomagają wykrywać błędy, kontrolować koszty oraz oceniać twierdzenia produktów AI.
Podajesz asystentowi AI raport i otrzymujesz dopracowany streszczenie, które zawiera wykres, którego nie można znaleźć nigdzie w dokumencie. Gdy o to pytasz, asystent przeprasza i proponuje inny wykres. Czy brakowało informacji, czy pomyślała się ich wyszukiwarka, czy też liczba została po prostu wymyślona? Sześć podstawowych koncepcji, rozumianych w kontekście decyzji, na które wpływają, pozwala zastąpić pytanie „dlaczego kłamie?” precyzyjnym pytaniem diagnostycznym, a także pomaga kontrolować koszty i oceniać twierdzenia dostawców.
Dlaczego sceptycyzm jest rozsądnym standardem
Niedowierzanie w wyniki generowane przez sztuczną inteligencję jest powszechne nawet wśród osób, które korzystają z niej codziennie. W ankiecie Stack Overflow Developer Survey z 2025 roku 46% respondentów na pytanie o dokładność stwierdziło, że nie ufa wynikom sztucznej inteligencji, podczas gdy 33% im ufało – to na podstawie 33 244 odpowiedzi (wyniki ankiety). Przeczytaj to uważnie: odnotowuje ono opinie programistów, a nie pomiar dokładności modelu, i nie stanowi reprezentatywnego przykładowej grupy ludności. Odzwierciedla jednak rzeczywiste napięcie – ludzie przyjmują te narzędzia, ale nadal nie wierzą we wszystko, co one mówią.
Najpierw zastosuj taką samą krytykę do nagłówków
Teksty o sztucznej inteligencji często obiecują, że poznanie kilku terminów pozwala być „przed 90% ludzi”. Brzmi to jak wynik badań, ale bez żadnego badania za tym stojącego jest to marketing w przebraniu statystyki. Należy zadać oczywiste pytania: przed kim, w jaki sposób, z jakimi uczestnikami i gdzie opublikowano wyniki? Brak oceny, próby badawczej czy danych oznacza, że ten procent nie ma żadnych podstaw. To nie sprawia, że wszystkie do niego odnoszone wyjaśnienia są błędne, ani nic nie mówi o intencjach kogokolwiek; po prostu oznacza, że ta liczba nie ma żadnej wagi.
Znajomość definicji to punkt wyjścia. Ich stosowanie, rozpoznawanie wyjątków oraz sprawdzanie rzeczywistych wyników to odrębne umiejętności, a żadna z nich nie jest mierzona pochlebnym procentem.
Ta sama dyscyplina dotyczy twierdzeń, że jeden prompt może zastąpić cały zespół lub że jakiś narzędzie dziesięciokrotnie zwiększa szybkość pracy wszystkich. Proszę o określenie konkretnego zadania, punktu odniesienia, sposobu jego pomiaru oraz ograniczeń. Jeden imponujący demo nie może dać ogólnego wyniku. Dobry nagłówek jest w porządku; problemy pojawiają się, gdy twierdzenie jest bardziej precyzyjne niż dowody na jego poparcie. Traktuj ten przewodnik według tych samych standardów.
1. Tokeny: rzeczywisty rozmiar zadania
Token to jednostka tekstu, którą faktycznie przetwarza model językowy. W zależności od tokenizera token może być całym słowem, fragmentem słowa, znakiem interpunkcyjnym lub inną częścią tekstu, a tokenizer przyporządkowuje każdą z tych części numerowemu identyfikatorowi.
Nie istnieje żadna sztywna zasada w rodzaju „jedno słowo równa się jednemu tokenowi”. Przegląd tokeryzatorów Hugging Face opisuje kilka podejść, w tym kodowanie par bajtowych, WordPiece oraz metody związane z SentencePiece, a ta sama zdanie może być rozdzielone zupełnie inaczej przez różne tokeryzatory. Języki inne niż angielski, kod oraz nietypowe formatowanie często wykorzystują więcej tokenów na słowo.
Znaczenie tego staje się jasne po zadaniu takiego pytania:
Które trzy skargi klientów pojawiały się najczęściej?
Samo pytanie jest bardzo krótkie. Ale jeśli jego odpowiedź wymaga przeczytania tysięcy wiadomości obsługi klienta, to pytanie stanowi błąd zaokrąglenia w całkowitej ilości danych wejściowych. Jako przykład orientacyjny, a nie dokładną miarę: 400 wiadomości po około 150 tokenach każda daje już 60 000 tokenów, zanim dodamy jakiekolwiek instrukcje lub inny kontekst.
Zatem istotne pytanie brzmi nie o to, jak długi jest twój prompt, ale ile materiału zadanie zmusza system do przetworzenia. Ponieważ ceny, opóźnienia i limity kontekstu są zwykle wyrażane w tokenach, to one również determinują koszt. Przed przetwarzaniem dużego dokumentu usuń powtarzające się podpisy e-maili, nieistotne załączniki oraz duplikaty rekordów, które nie dostarczają żadnych dowodów, zachowując jednocześnie wszystko, od czego rzeczywiście zależy odpowiedź.
2. Okno kontekstowe: co model może zobaczyć w jednej prośbie
Okno kontekstowe określa, ile materiału model może przetwarzać w jednej prośbie. Instrukcje systemu, historia rozmów, pobrane fragmenty oraz wszelkie inne dane zużywają ten budżet; sposób liczenia tokenów wyjściowych zależy od modelu i API. Dokumentacja Google dotycząca długiego kontekstu pokazuje, jak duże okna umożliwiają pracę z dużymi zbiorami tekstu i innych mediów.
Akceptacja dokumentu nie jest jednak tym samym co pewne wykorzystanie wszystkich istotnych informacji w nim zawartych. Badanie z 2023 roku „Lost in the Middle” badało możliwości odpowiadania na pytania w oparciu o kilka dokumentów oraz wyszukiwania informacji typu klucz-wartość i stwierdziło, że w przypadku analizowanych modeli dokładność często spadała, gdy istotne dane znajdowały się w środku długiego tekstu wejściowego, a nie blisko jego początku lub końca. Należy traktować to jako dowód historyczny dotyczący tych konkretnych eksperymentów, a nie jako wskaźnik dla dzisiejszych modeli, jednak zasada sprawdzania pozostaje aktualna.
Produkty do czatowania rzadko zachowują się tak, jak sugeruje ich interfejs. Gdy rozmowa przekracza rozmiar okna, aplikacja nie musi po prostu usuwać najstarszych wiadomości – może zamiast tego je streszczać, wybierać lub odwoływać się do wcześniejszych treści. To, co widzimy w historii czatów, nie jest wiarygodnym obrazem tego, co trafia do modelu przy każdym wezwaniu.
W praktyce:
- W przypadku zadań trwających długo należy przechowywać krótki, wyraźny opis obecnych wymagań i decyzji oraz ponawiać go w momentach, gdy jest to konieczne.
- Gdy wniosek zależy od jednego fragmentu tekstu, należy poprosić asystenta o przytoczenie lub znalezienie tego fragmentu przed wyciągnięciem wniosku.
Duże okno daje systemowi przestrzeń do działania; nie dowodzi to jednak, że system użył właściwych dowodów.
3. Temperatura: kontrola różnorodności, a nie prawdy
Na każdym etapie generowania model ocenia każdy możliwy następny token. Temperatura modyfikuje rozkład prawdopodobieństwa używany do wyboru tokenów na podstawie tych ocen: niskie wartości koncentrują prawdopodobieństwo na najbardziej prawdopodobnych opcjach, natomiast wysokie wartości rozpraszają je na większą liczbę opcji. Hugging Face dokumentuje temperaturę wraz z powiązanymi parametrami kontroli generowania, takimi jak top-p sampling i greedy decoding.
Kuszącym skrótem jest stwierdzenie, że „niska temperatura oznacza dokładność”. To nie jest prawda. Jeśli najbardziej prawdopodobna odpowiedź modelu jest błędna, zmniejszenie różnorodności nie dostarczy brakującego faktu; sprawi jedynie, że ten sam błąd będzie występował bardziej regularnie. Podobnie podwyższenie temperatury nie gwarantuje lepszych pomysłów, tylko bardziej zróżnicowanych.
Dwie przeciwstawne zadania pokazują tę różnicę. Tworzenie pięciu nazw dla fikcyjnej kawiarni korzysta z różnorodności. Wyodrębnianie numerów faktur wymaga spójnego formatowania, ale numery te muszą nadal odpowiadać rzeczywistym fakturom, a temperatura nie ma tu żadnego wpływu.
Rozpatruj temperaturę jako jeden z parametrów do eksperymentowania i oceniaj ją pod kątem tego, czego faktycznie wymaga zadanie. W przypadku wydobywania informacji licz błędne i brakujące pola; podczas burzy mózgów sprawdzaj, czy pomysły są zarówno przydatne, jak i rzeczywiście różne od siebie. Przewidywalność i poprawność wymagają odrębnych weryfikacji.
4. Halucynacje: wyniki wykraczające poza dostępne dowody
Tutaj halucynacją jest treść wygenerowana w sposób sfabrykowany, zawierająca błędy faktograficzne lub niepoparta materiałem, który rzekomo opisuje. Pewny ton utrudnia jej wykrycie, ale pewność siebie nie jest częścią definicji; zdanie zawierające ograniczenia może być równie bezpodstawne.
Oczywistym przykładem jest sfabrykowany artykuł naukowy. Subtelniejszym i częstszym przypadkiem jest prawdziwy artykuł cytowany w związku z wynikiem, którego nigdy nie przedstawił, a który przetrwa szybki przegląd właśnie dzięki temu cytowaniu.
Benchmark TruthfulQA wprowadził 817 pytań w 38 kategoriach, opracowanych wokół powszechnych błędnych przekonań. W pierwotnej ocenie najlepszy przetestowany model udzielał prawdziwych odpowiedzi w 58% przypadków, podczas gdy ludzie osiągali wynik 94%. Są to historyczne rezultaty badań z lat 2021 i 2022, nie stanowią one miary aktualnych chatbotów ani uniwersalnego wskaźnika halucynacji. Badania te pokazują, że modele potrafią wiernie odtwarzać fałszywe przekonania występujące w tekstach napisanych przez ludzi.
Gdy streszczenie zawiera zaskakującą liczbę, należy wyraźnie zapytać o jej źródło:
Należy wskazać fragment tekstu źródłowego, podać jego datę oraz populację, którą objął. Jeśli fragment nie potwierdza tej liczby, należy ją oznaczyć jako niesprawdzoną.
Następnie sprawdź odnośnik na własne oczy. Każda cytat produkcja modelu jest jedynie stwierdzeniem, dopóki nie potwierdzisz zarówno istnienia strony, jak i faktu, że rzeczywiście zawiera ona konkretny zdanie.
5. RAG: pobieranie dowodów przed odpowiadaniem
Retrieval-augmented generation łączy krok wyszukiwania z krokiem generowania. System znajduje istotne materiały w zewnętrznej bazie danych, przekazuje je modelowi i prosi go o udzielenie odpowiedzi na podstawie tych materiałów.
Wpływowy artykuł z 2020 roku na temat RAG połączył wcześniej przeszkolony generator z narzędziem do wyszukiwania w indeksie Wikipedii i po jego publikacji osiągnął najlepsze wyniki w trzech testach jakości pytania i odpowiedzi z otwartym domenem. Te wyniki opisują jeden system badawczy, a nie gwarancję jakości dla każdego produktu oznaczonego jako RAG.
Załóżmy, że pracownik pyta, ile dni ma na złożenie wniosku o zwrot kosztów. Dobry system pobiera aktualne zasady i na ich podstawie udziela odpowiedzi. Jeśli zamiast tego pobierze zasady z zeszłego roku, nawet dobrze napisany tekst nie naprawi błędu – odpowiedź będzie płynna, ale błędna. Dlatego błędy RAG są zazwyczaj łatwiejsze do zdiagnozowania na poszczególnych etapach niż poprzez analizę ostatecznej odpowiedzi; temat ten jest omówiony w ocenie RAG według etapu wystąpienia błędu.
Warto wyjaśnić dwa błędne przekonania:
- RAG nie wymaga posiadania specjalistycznego magazynu wektorowego. Krok wyszukiwania może polegać na klasycznym dopasowywaniu słów kluczowych, porównywaniu podobieństwa wektorowego lub na ich połączeniu, a przegląd RAG firmy Microsoft omawia te opcje wraz z znaczeniem przygotowania treści tak, aby można je było skutecznie wyszukiwać.
Aby ocenić dowolnego asystenta dokumentowego, należy zadać dwa oddzielne pytania: czy znalazł właściwy fragment tekstu i czy jego odpowiedź wiernie odzwierciedla ten fragment?
6. Agenci: systemy, które samodzielnie wybierają kolejny krok
Pojęcie „agent” jest używane w szerokim sensie, więc konkretne rozróżnienie jest pomocne. Przewodnik Anthropic dotyczący tworzenia skutecznych agentów opisuje workflow jako systemy, które podążają za z góry zdefiniowanymi ścieżkami kodu, podczas gdy agenci pozwalają modelowi dynamicznie kierować własnym procesem i wykorzystywaniem narzędzi.
Ustalony proces pracy może wyodrębniać pola z faktury, je sprawdzać i zapisywać rekord, zawsze w tej kolejności. Pracownik, który ma do czynienia z niekompletną fakturą, może samodzielnie postanowić otworzyć załącznik, znaleźć powiązany zamówienie i wysłać prośbę o brakujące dane.
Kluczowe pytanie brzmi zatem: jakie decyzje i działania może podjąć system? Sposobna odpowiedź oraz wypłacona zwrotka mają zupełnie różne konsekwencje. Pracownik potrzebuje jasno określonych uprawnień, widocznych rezultatów dla każdego działania oraz sposobu na zatrzymanie się, gdy nie może określić sensownego następnego kroku.
zrozumienie agentów AI: cele, narzędzia, pamięć i pętla agenta.Sześciostopniowa lista kontrolna dla rzeczywistych zadań
Każda koncepcja odpowiada pytaniu, które można zadać w odniesieniu do dowolnego rzeczywistego zadania:
- Tokeny: ile materiału faktycznie wymaga przetworzenia przez system w tym zadaniu i co można usunąć bez utraty dowodów?
- Okno kontekstowe: na który fragment tekstu opierała się odpowiedź i czy system rzeczywiście go wykorzystał?
- Temperatura: czy to zadanie dotyczy różnorodności, czy spójności, a czy poprawność i przewidywalność zostały sprawdzone oddzielnie?
- Hallucynacje: gdzie dokładnie znajduje się źródło każdego zaskakującego twierdzenia i czy potwierdza ono to, co mówi odpowiedź?
- RAG: czy został pobraany właściwy, aktualny dokument i czy był on przedstawiony dokładnie?
- Agenci: co system ma prawo robić i czy całe zadanie, włączając jego skutki uboczne, zostało wykonane prawidłowo?
Podsumowanie
Wypróbuj te pytania w ramach rzeczywistego zadań, takich jak streszczenie dokumentu, zmiana kodu lub odpowiedź w obsłudze klienta, z materiałem źródłowym otwartym obok siebie. Rozróżnij źródła, z których czerpało dane, wnioski, do których doszło samoistnie, oraz działania, które faktycznie zostały podjęte. Regularne stosowanie tego podejścia ujawnia więcej informacji na temat niezawodności narzędzia niż jakakolwiek prezentacja lub statystyka z nagłówków, a także przekształca nieokreślone wątpliwości w konkretne, rozwiązywalne problemy: nadmiernie rozbudowany wpis, pominięty fragment, niewłaściwy dokument, nieobsłużony wykres lub agent o zbyt dużych uprawnieniach.
Literatura pokrewna
- Piętnaście koncepcji LLM prześledzonych przez jedną prośbę botu podtrzymującego — Prześledź jedno pytanie klienta za pośrednictwem asystenta AI, aby dowiedzieć się, co tak naprawdę robią modele, tokeny, embeddingi, kontekst, RAG, agenci oraz metody oceny, i gdzie kończy się działanie każdego z nich.
- Następna pętla tokenów: model mentalny LLM przed zastosowaniem agentów — Dowiedz się, jak działają tokeny, okna kontekstowe, procesy próbkowania oraz pętla generacji, za pomocą prostych przykładów w Pythonie, które wyjaśniają, dlaczego istnieją RAG, ReAct i LangGraph.