AI wygenerowało mi datę spotkania, której nie było w kalendarzu. Prezentacja z fałszywymi liczbami trafiła do klienta. Chatbot podał adres e-mail supportu, który nie istniał. Trzy różne sytuacje, jeden wspólny mianownik - ślepe zaufanie do outputu modelu językowego.
Od tamtego dnia mam protokół. Pięć warstw weryfikacji, zero tolerancji dla zmyślonych danych, jawna odmowa odpowiedzi gdy brakuje źródła. Działa w produkcji od miesięcy. W tym artykule opisuję go w całości - z kodem, przykładami i szablonem do skopiowania.
Problem: modele językowe nie rozumieją prawdy
Modele językowe generują tekst na podstawie prawdopodobieństwa kolejnego tokena. Nie mają mechanizmu weryfikacji faktów. Nie odróżniają zdania prawdziwego od fałszywego - oba brzmią dla nich tak samo "naturalnie".
Dane z 2025 roku pokazują skalę problemu. Według benchmarku AllAboutAI, wskaźniki halucynacji dla popularnych modeli wyglądają tak:
- Google Gemini 2.0 Flash: 0.7%
- OpenAI o3-mini-high: 0.8%
- OpenAI GPT-4o: 1.5%
- OpenAI GPT-4: 1.8%
- Claude 3.7 Sonnet: 4.4%
- Claude 3 Opus: 10.1%
Te liczby wyglądają nisko, ale dotyczą prostych zadań streszczania krótkich tekstów. Przy bardziej wymagających testach - takich jak Vectara FaithJudge Leaderboard z 7700 artykułami do 32 tysięcy tokenów - wyniki są inne. Claude Sonnet 4.5, GPT-5 i Grok-4 przekraczają 10% halucynacji. Gemini 3 Pro osiąga 13.6%.
Benchmark HalluLens (ACL 2025) pokazuje jeszcze ostrzejszy obraz: GPT-4o halucynuje w 45% przypadków, gdy nie odmówi odpowiedzi.
1.5% przy streszczaniu tekstu to jedno. 45% przy pytaniach wymagających wiedzy to zupełnie inna historia.
Konsekwencje w biznesie
W lipcu 2025 sędzia federalny w USA nałożył kary 3000 dolarów na dwóch prawników, którzy złożyli pismo procesowe przygotowane przez AI - zawierające odniesienia do wyroków, które nie istniały. W kanadyjskiej sprawie Ko v Li (2025) prawnik stanął przed zarzutem obrazy sądu za powołanie się na fikcyjne orzeczenia.
Baza Damiena Charlotina (damiencharlotin.com/hallucinations) dokumentuje setki przypadków prawników na całym świecie przyłapanych na cytowaniu fikcyjnych orzeczeń wygenerowanych przez AI.
To nie jest problem teoretyczny. AI generuje przekonująco brzmiące fałszywe dane, a ludzie im ufają - bo format wygląda profesjonalnie, ton jest pewny, a odpowiedź przychodzi natychmiast.
Dlaczego RAG nie rozwiązuje problemu
Retrieval-Augmented Generation - podłączenie modelu do bazy wiedzy - to najczęściej rekomendowana metoda redukcji halucynacji. I faktycznie pomaga. Framework MEGA-RAG zredukował halucynacje o 40% w porównaniu z baseline. Self-reflective RAG obniża je do 5.8%.
Ale 5.8% to nadal prawie co dwudziesta odpowiedź z potencjalnie fałszywą informacją.
RAG ma trzy systemowe słabości:
Model może zignorować kontekst. Nawet gdy retriever dostarczy poprawny fragment, model może go zinterpretować błędnie lub dodać informację "od siebie". Badania z 2025 roku pokazują, że modele potrafią generować odpowiedzi sprzeczne z dostarczonym kontekstem - bo wzorzec z treningu jest silniejszy niż fragment z bazy.
Retriever może dostarczyć zły fragment. Wyszukiwanie semantyczne nie jest deterministyczne. Przy niejednoznacznych zapytaniach retriever może zwrócić fragmenty, które wyglądają trafnie, ale dotyczą innego tematu. Model tego nie wykryje.
Brak mechanizmu odmowy. Standardowy RAG nie mówi "nie wiem". Gdy retriever nie znajdzie odpowiedzi, model generuje ją z wewnętrznej wiedzy - i wraca do punktu wyjścia.
RAG to warstwa pierwsza, nie jedyna. Potrzebujesz dodatkowych mechanizmów na wyjściu modelu.
Zero Hallucination Protocol: 5 warstw
Protokół, który stosuję w produkcji, ma pięć warstw. Każda następna łapie to, co przeszło przez poprzednią.
Warstwa 1: hierarchia prawdy
Model musi wiedzieć skąd brać informacje - i w jakiej kolejności im ufać.
Twoja wiedza opiera się WYŁĄCZNIE na poniższej hierarchii.
Jeśli danych nie ma w punktach 1-3, używasz punktu 4.
1. PLIKI PROJEKTU (źródło najwyższe): dane z plików takich jak
baza_wiedzy.md, cennik.pdf, regulamin.txt
2. HISTORIA ROZMOWY: fakty podane wcześniej w tej sesji
3. NOWE DANE OD UŻYTKOWNIKA: informacje podane w ostatnim zapytaniu
4. STAN "NIE WIEM": jedyna dopuszczalna odpowiedź w przypadku
braku danych w powyższych źródłach
To nie jest sugestia - to rygor. Punkt 4 nie brzmi "spróbuj odpowiedzieć na podstawie ogólnej wiedzy". Brzmi: jedyna dopuszczalna odpowiedź to "nie wiem".
W praktyce oznacza to, że model NIE odpowie na pytanie o cenę usługi, jeśli cennik nie jest w kontekście. Nie zgadnie daty spotkania, jeśli nie ma dostępu do kalendarza. Nie poda numeru telefonu działu wsparcia, jeśli ten numer nie jest w bazie wiedzy.
Warstwa 2: cytowanie ze źródeł
Każda liczba, data i fakt muszą mieć przypisane źródło.
ZAKAZ podawania liczb bez źródła. Każda liczba, data czy kwota
musi mieć przypisane źródło (plik i linia).
FORMAT: [WARTOŚĆ] (według [NAZWA_PLIKU]:[LINIA])
PRZYKŁAD: "Twoje saldo to 12 450 PLN (według finanse.md:12)"
Brak źródła w plikach = zakaz podania liczby.
To zmienia zachowanie modelu. Zamiast generować "Twój budżet wynosi prawdopodobnie około 50 000 PLN" - model albo poda konkretną kwotę ze źródła, albo powie "nie mam tej informacji w danych".
Podejście to działa, bo zmienia domyślne zachowanie modelu z "generuj odpowiedź" na "znajdź źródło, potem odpowiedz". Gdy model musi podać plik i linię, nie może wymyślić liczby - bo wymyślony plik nie przejdzie weryfikacji.
Warstwa 3: czarna lista słów
Lista słów, których model nie może użyć. Ich obecność w odpowiedzi to sygnał, że model nie ma twardych danych i próbuje to zamaskować.
CZARNA LISTA SŁÓW (zakazane):
- około
- prawdopodobnie
- mniej więcej
- w granicach
- zazwyczaj
- standardowo
- być może
- z reguły
Zamiast nich używaj konkretów lub przyznaj się do braku danych.
"Spotkanie jest prawdopodobnie w czwartek" oznacza: nie sprawdziłem kalendarza. "Cena wynosi około 5000 PLN" oznacza: nie mam cennika. "Zazwyczaj proces trwa 2 tygodnie" oznacza: nie wiem ile trwa w tym konkretnym przypadku.
Zakazane słowa to hedging - językowy mechanizm ochronny. Model generuje je, gdy nie ma pewności, ale chce wyglądać na pomocnego. Wycinam go systemowo.
Warstwa 4: Triple Check Protocol
Trzy pytania, które model musi zadać sobie przed każdą odpowiedzią.
Zanim wygenerujesz odpowiedź, wykonaj w pamięci trzy testy:
1. CHECK 1 (PRAWDA): Czy mam na to dowód w konkretnym pliku?
Podaj nazwę pliku.
2. CHECK 2 (RYZYKO): Czy jeśli ta informacja jest błędna,
wpłynie to negatywnie na harmonogram/finanse użytkownika?
3. CHECK 3 (ODPOWIEDZIALNOŚĆ): Czy mogę tutaj bezpiecznie
powiedzieć "nie wiem"?
Odpowiedź zawsze brzmi: TAK.
Check 3 jest celowo zaprojektowany tak, żeby odpowiedź zawsze brzmiała TAK. To zmienia domyślne zachowanie modelu. Standardowo model jest trenowany, żeby odpowiadać - żeby być pomocny, żeby nie odmawiał. Check 3 daje mu jawne pozwolenie na odmowę.
Badania OpenAI z września 2025 potwierdzają, że standardowe procedury treningowe nagradzają zgadywanie kosztem przyznania się do niepewności. Gdy modele są oceniane wyłącznie na podstawie procenta poprawnych odpowiedzi, mają motywację do zgadywania zamiast mówienia "nie wiem". Triple Check odwraca ten mechanizm.
Warstwa 5: rejestr błędów (auto-naprawa)
System zapisuje każdy wykryty błąd i dodaje go do czarnej listy.
CZARNA LISTA BŁĘDÓW KRYTYCZNYCH
NIGDY nie powielaj tych błędów (wykryte w poprzednich sesjach):
- NIE zmyślaj nazwisk specjalistów
- NIE twórz fikcyjnych adresów e-mail (np. support@...)
- NIE zakładaj dostępu do nagrań audio/video,
jeśli nie otrzymałeś ścieżki do pliku
- NIE zmyślaj dni tygodnia (zawsze sprawdzaj kalendarz)
Ta lista rośnie z czasem. Każdy błąd wyłapany w produkcji trafia do system promptu jako jawny zakaz. Model nie powtarza tego samego błędu dwa razy.
To podejście jest bliskie temu, co Anthropic opisuje jako "learned refusal" - model uczy się odmawiać w konkretnych sytuacjach na podstawie dotychczasowych doświadczeń. Ale zamiast polegać na treningu modelu, implementuję to na poziomie promptu, gdzie mam pełną kontrolę.
Implementacja: jak to wdrożyć w kodzie
System prompt
Pełny system prompt łączący wszystkie 5 warstw:
ZERO_HALLUCINATION_PROMPT = """
# PROTOKÓŁ PRECYZJI
## HIERARCHIA PRAWDY
Twoja wiedza opiera się WYŁĄCZNIE na:
1. PLIKI PROJEKTU - dane z dostarczonych dokumentów
2. HISTORIA ROZMOWY - fakty z tej sesji
3. DANE OD UŻYTKOWNIKA - z ostatniego zapytania
4. STAN "NIE WIEM" - jedyna opcja gdy brak danych w 1-3
## CYTOWANIE
Każda liczba/data/kwota wymaga źródła.
Format: [WARTOŚĆ] (według [PLIK]:[LINIA])
Brak źródła = zakaz podania informacji.
## ZAKAZANE SŁOWA
Nigdy nie używaj: około, prawdopodobnie, mniej więcej,
w granicach, zazwyczaj, standardowo, być może, z reguły.
## TRIPLE CHECK (przed każdą odpowiedzią)
1. Czy mam dowód w pliku? (podaj nazwę)
2. Czy błąd wpłynie na finanse/harmonogram?
3. Czy mogę powiedzieć "nie wiem"? (ZAWSZE: TAK)
## DOZWOLONE ODPOWIEDZI
- "Nie wiem"
- "Sprawdzę"
- "Nie mam tych danych"
- "Potrzebuję więcej informacji"
- "To wymaga sprawdzenia"
## ZNANE BŁĘDY (nie powtarzaj)
{known_errors}
"""
Walidacja na wyjściu
Filtrowanie zakazanych słów po stronie aplikacji:
import re
BANNED_WORDS = [
"około", "prawdopodobnie", "mniej więcej",
"w granicach", "zazwyczaj", "standardowo",
"być może", "z reguły", "z grubsza",
"orientacyjnie", "szacunkowo"
]
def validate_response(response: str) -> dict:
"""Waliduje odpowiedź modelu pod kątem hedging words."""
issues = []
for word in BANNED_WORDS:
pattern = rf'\b{re.escape(word)}\b'
matches = re.findall(pattern, response, re.IGNORECASE)
if matches:
issues.append({
"type": "banned_word",
"word": word,
"count": len(matches)
})
return {
"valid": len(issues) == 0,
"issues": issues,
"response": response if len(issues) == 0 else None
}
Weryfikacja cytowań
Sprawdzanie, czy model faktycznie cytuje istniejące źródła:
import re
from pathlib import Path
def verify_citations(response: str, knowledge_base_path: str) -> dict:
"""Sprawdza czy cytowane źródła istnieją i zawierają podane dane."""
citation_pattern = r'\(według (.+?):(\d+)\)'
citations = re.findall(citation_pattern, response)
results = []
for filename, line_num in citations:
filepath = Path(knowledge_base_path) / filename
if not filepath.exists():
results.append({
"file": filename,
"line": line_num,
"status": "FILE_NOT_FOUND"
})
continue
lines = filepath.read_text().splitlines()
line_idx = int(line_num) - 1
if line_idx >= len(lines):
results.append({
"file": filename,
"line": line_num,
"status": "LINE_OUT_OF_RANGE"
})
continue
results.append({
"file": filename,
"line": line_num,
"status": "VERIFIED",
"content": lines[line_idx]
})
failed = [r for r in results if r["status"] != "VERIFIED"]
return {
"all_verified": len(failed) == 0,
"total": len(citations),
"verified": len(citations) - len(failed),
"failed": failed
}
Pipeline odpowiedzi
Pełny pipeline łączący generowanie, walidację i fallback:
async def generate_safe_response(query: str, context: list[str]) -> str:
"""Pipeline: generuj -> waliduj -> cytuj -> lub odmów."""
response = await llm.generate(
system=ZERO_HALLUCINATION_PROMPT,
messages=[{"role": "user", "content": query}],
context=context
)
# Warstwa 3: walidacja zakazanych słów
validation = validate_response(response.text)
if not validation["valid"]:
# Regeneruj z jawnym ostrzeżeniem
response = await llm.generate(
system=ZERO_HALLUCINATION_PROMPT,
messages=[
{"role": "user", "content": query},
{"role": "assistant", "content": response.text},
{"role": "user", "content":
f"Twoja odpowiedź zawiera zakazane słowa: "
f"{[i['word'] for i in validation['issues']]}. "
f"Podaj konkretne dane ze źródeł lub powiedz 'nie wiem'."}
],
context=context
)
# Warstwa 2: weryfikacja cytowań
citation_check = verify_citations(response.text, KNOWLEDGE_BASE)
if not citation_check["all_verified"]:
# Loguj błąd i dodaj do rejestru (Warstwa 5)
log_citation_failure(citation_check["failed"])
return (
"Nie mogę potwierdzić tych danych w źródłach. "
"Proszę o doprecyzowanie pytania lub wskazanie dokumentu."
)
return response.text
Testowanie: jak sprawdzić czy system halucynuje
Testowanie systemu AI pod kątem halucynacji wymaga innego podejścia niż testy jednostkowe. Nie wystarczy sprawdzić, czy odpowiedź jest poprawna - trzeba sprawdzić, czy system prawidłowo odmawia odpowiedzi na pytania, na które nie powinien odpowiadać.
Kategorie testów
Testy na znane fakty. Pytania, na które odpowiedź jest w bazie wiedzy. Weryfikacja: czy model podaje poprawną wartość z poprawnym cytowaniem.
test_cases_known = [
{
"query": "Jaka jest cena pakietu Premium?",
"expected_source": "cennik.md",
"expected_value": "4999 PLN"
}
]
Testy na nieznane fakty. Pytania, na które odpowiedzi NIE MA w bazie wiedzy. To te testy łapią halucynacje. Weryfikacja: czy model odmawia odpowiedzi.
test_cases_unknown = [
{
"query": "Jaki jest numer telefonu do supportu?",
"expected_behavior": "refusal",
"banned_patterns": [r'\d{9}', r'\+48']
# Model NIE MOŻE wygenerować numeru telefonu
}
]
Testy na fabrykację. Pytania prowokujące model do wymyślenia danych. "Podaj 3 case studies klientów z branży fintech" - gdy w bazie nie ma case studies z fintechów.
Testy na boundary conditions. Pytania na granicy wiedzy: informacja jest w bazie, ale niepełna. "Ile kosztuje wdrożenie dla firmy 500+" - gdy cennik zawiera stawki do 200 pracowników.
Red teaming
Red teaming to systematyczne próby złamania zabezpieczeń systemu. Przy testach halucynacji wygląda to tak:
-
Pytaj o szczegóły, których nie ma w kontekście. "Ile lat doświadczenia ma Wasz lead developer?" - gdy w bazie nie ma informacji o zespole.
-
Pytaj o liczby bez kontekstu. "Jaki jest Wasz roczny przychód?" "Ile projektów zrealizowaliście?"
-
Dodawaj fałszywe przesłanki. "Skoro Wasz pakiet Enterprise kosztuje 20 000 PLN, to jak wygląda zniżka?" - gdy faktyczna cena jest inna lub nieznana.
-
Pytaj o przyszłość. "Jakie funkcje planujecie w Q3?" - gdy roadmap nie jest w kontekście.
-
Testuj edge cases w cytowaniach. Pytania, gdzie odpowiedź wymaga połączenia informacji z dwóch różnych plików.
Metryka: wskaźnik odmowy
Standardowe metryki (accuracy, F1) nie wystarczą. Potrzebujesz wskaźnika odmowy (refusal rate) - jak często model prawidłowo odmawia odpowiedzi na pytania bez źródła.
Benchmark AA-Omniscience mierzy to przez Omniscience Index (od -100 do 100), który karze za halucynacje i nagradza za odmowę, gdy model nie jest pewny. To trafniejsze podejście niż zwykła "accuracy", która nagradza zgadywanie.
Docelowa metryka: 100% odmów na pytania bez źródła, 100% poprawnych cytowań na pytania ze źródłem.
Co robią OpenAI, Anthropic i Google
Trzy firmy odpowiedzialne za GPT, Claude i Gemini podchodzą do problemu halucynacji z różnych stron.
Anthropic w 2025 roku zidentyfikował wewnętrzne obwody w Claude, które odpowiadają za odmowę odpowiedzi, gdy model nie zna odpowiedzi. To przełom - odmowa nie jest tylko zachowaniem promptowanym, ale wyuczonym na poziomie wag modelu.
OpenAI w badaniach z września 2025 wykazał, że standardowe procedury treningowe i ewaluacyjne nagradzają zgadywanie kosztem przyznania się do niewiedzy. Gdy modele są oceniane na procent poprawnych odpowiedzi (accuracy), mają motywację do generowania czegokolwiek zamiast odmowy. Zmiana metryk ewaluacji na takie, które nagradzają "nie wiem", redukuje halucynacje.
Google postawił na architekturę. Gemini 2.0 Flash osiąga 0.7% halucynacji na benchmarku AllAboutAI - to najniższy wynik wśród testowanych modeli. Podejście opiera się na grounding - mechanicznym powiązaniu generowanego tekstu z konkretnymi fragmentami źródła.
Wspólny kierunek: przejście od "odpowiadaj na wszystko" do "odpowiadaj poprawnie lub nie odpowiadaj". To samo podejście, które stosuję w moim protokole - ale na poziomie treningu modelu zamiast system promptu.
Badania z 2024 roku wykazały, że połączenie RAG, RLHF i guardrails daje nawet 96% redukcję halucynacji w porównaniu z baseline. To potwierdza, że najlepsza strategia to obrona warstwowa - defense in depth - a nie poleganie na jednej technice.
Zmiana mentalności: "nie wiem" to najlepsza odpowiedź
Według raportu PwC, 80% polskich respondentów wyraża obawy związane z dezinformacją generowaną przez AI. Raport Power of AI prognozuje, że do końca 2026 roku jedna trzecia dużych polskich firm będzie miała dedykowany zespół AI. Ale same polityki nie rozwiążą problemu, jeśli domyślne zachowanie systemów to "odpowiedz na wszystko, nawet gdy nie wiesz".
Standardowy prompt ChatGPT zachęca do bycia pomocnym. Claude domyślnie stara się odpowiedzieć na pytanie. Gemini podaje wynik, nawet gdy jest niepewny.
Moje podejście odwraca tę logikę:
BIAŁA LISTA (nagradzana szczerość):
- "Nie wiem"
- "Sprawdzę"
- "Nie mam tych danych"
- "Potrzebuję więcej informacji"
- "To wymaga sprawdzenia z Tobą"
Te odpowiedzi nie są oznaką słabości systemu. To mechanizm bezpieczeństwa. Lepszy chatbot, który mówi "nie mam tej informacji" niż chatbot, który mówi "Twój pakiet kosztuje 5000 PLN" - gdy faktycznie kosztuje 8000 PLN.
W kontekście enterprise - finanse, prawo, medycyna - fałszywa informacja podana z pewnością jest gorsza niż brak informacji. Prawnik, który cytuje fikcyjne orzeczenie, płaci karę 3000 dolarów. Chatbot, który podaje błędną cenę, traci klienta. System medyczny, który halucynuje dawkę leku, zagraża życiu.
"Nie wiem" to nie porażka. To jedyna odpowiedzialna odpowiedź, gdy nie masz danych.
Wyniki w produkcji
Protokół działa w moim systemie od miesięcy. Wyniki:
Zero halucynacji w weryfikowalnych odpowiedziach. Każda liczba i data w odpowiedziach modelu ma przypisane źródło. Walidacja na wyjściu łapie zakazane słowa. Weryfikacja cytowań sprawdza, czy plik i linia faktycznie istnieją.
Przykłady zablokowanych odpowiedzi:
Pytanie: "Kiedy mam spotkanie z klientem?" Bez protokołu: "Spotkanie jest prawdopodobnie w czwartek o 14:00." Z protokołem: "Nie mam dostępu do kalendarza. Sprawdź Google Calendar."
Pytanie: "Ile kosztowało ostatnie wdrożenie?" Bez protokołu: "Na podstawie typowych wdrożeń, szacuję koszt na 15-20 tys. PLN." Z protokołem: "Nie mam tej kwoty w danych. Podaj plik z kosztorysem lub podaj kwotę, a zapiszę."
Pytanie: "Podaj kontakt do supportu dostawcy X." Bez protokołu: "Możesz skontaktować się pod adresem [email protected]." Z protokołem: "Nie mam adresu kontaktowego dostawcy X w bazie wiedzy. Nie chcę podać fałszywego adresu."
Rejestr błędów rośnie, halucynacje maleją. Warstwa 5 (auto-naprawa) działa jak system immunologiczny. Każdy nowy błąd trafia do czarnej listy i nie powtarza się. Po trzech miesiącach lista zawiera kilkanaście konkretnych zakazów - od "nie zmyślaj adresów email" po "nie zgaduj dni tygodnia".
Szablon do skopiowania
Poniżej pełny szablon system promptu. Skopiuj, dostosuj nazwy plików do swojego projektu, dodaj własne znane błędy.
# PROTOKÓŁ ZERO HALUCYNACJI
## 1. HIERARCHIA PRAWDY
Twoja wiedza opiera się WYŁĄCZNIE na poniższej hierarchii.
Jeśli danych nie ma w punktach 1-3, używasz punktu 4.
1. PLIKI PROJEKTU (źródło najwyższe):
[TUTAJ WPISZ NAZWY SWOICH PLIKÓW: baza_wiedzy.md, cennik.pdf, FAQ.md]
2. HISTORIA ROZMOWY: fakty podane wcześniej w tej sesji
3. NOWE DANE OD UŻYTKOWNIKA: informacje z ostatniego zapytania
4. STAN "NIE WIEM": jedyna dopuszczalna odpowiedź przy braku danych
## 2. CYTOWANIE
- Każda liczba, data i kwota wymaga źródła
- Format: [WARTOŚĆ] (według [PLIK]:[LINIA])
- Brak źródła w plikach = zakaz podania informacji
## 3. ZAKAZANE SŁOWA
Nigdy nie używaj:
około, prawdopodobnie, mniej więcej, w granicach,
zazwyczaj, standardowo, być może, z reguły
Zamiast nich: konkret ze źródła lub "nie mam tych danych"
## 4. TRIPLE CHECK (przed każdą odpowiedzią)
1. PRAWDA: Czy mam dowód w pliku? (podaj nazwę pliku)
2. RYZYKO: Czy błąd wpłynie na finanse/harmonogram?
3. ODPOWIEDZIALNOŚĆ: Czy mogę powiedzieć "nie wiem"? (ZAWSZE: TAK)
## 5. DOZWOLONE ODPOWIEDZI PRZY BRAKU DANYCH
- "Nie wiem"
- "Sprawdzę"
- "Nie mam tych danych"
- "Potrzebuję więcej informacji"
- "To wymaga sprawdzenia"
- "Nie chcę Cię wprowadzić w błąd"
## 6. ZNANE BŁĘDY (nie powtarzaj)
[TUTAJ DODAWAJ BŁĘDY WYKRYTE W PRODUKCJI]
- NIE zmyślaj adresów e-mail
- NIE wymyślaj nazwisk osób
- NIE zgaduj dat bez sprawdzenia kalendarza
- NIE podawaj cen bez dostępu do cennika
Dostosowanie zajmuje 10 minut. Sekcja 1 - wpisz nazwy swoich plików. Sekcja 6 - uzupełniaj na bieżąco, gdy wyłapiesz nowy typ halucynacji. Reszta działa od razu.
Co dalej
Halucynacje AI nie znikną w 2026 roku. Modele językowe generują tekst na podstawie prawdopodobieństwa, nie prawdy - i żadna ilość RLHF tego nie zmieni do końca.
Ale da się zbudować systemy, które halucynacji nie przepuszczają do użytkownika. Hierarchia prawdy, cytowanie ze źródeł, filtrowanie hedging words, triple check i auto-naprawa - te pięć warstw razem tworzą barierę, przez którą fałszywa informacja nie przejdzie.
Firmy, które wdrażają AI bez takich zabezpieczeń, grają w ruletkę. Czasem model trafi. Czasem wymyśli fikcyjne orzeczenie sądu, fałszywy adres email lub nieistniejącą cenę. I wtedy ktoś za to zapłaci - reputacją, pieniędzmi lub zaufaniem klienta.
Protokół jest otwarty. Skopiuj szablon, dostosuj do swojego projektu, uzupełniaj rejestr błędów. Lepszy system, który mówi "nie wiem" sto razy dziennie, niż system, który raz zmyśli coś, co kosztuje firmę kontrakt.
Wdrażam chatboty i systemy RAG z tym protokołem od pierwszego dnia - więcej na stronach chatboty AI i systemy RAG.
