Standard komunikacji i decyzji w sytuacjach niepewności: kiedy odpowiadać z cytowaniami, kiedy dopytać, a kiedy zastosować no‑answer i eskalację. Celem jest rzetelność, nie pozór.
Czas czytania: ~10 minAktualizacja: 2026-01-09
W skrócie
brak dowodu ≠ pewność
macierz decyzji: źródła × ryzyko
szablony no‑answer + eskalacja
Definicje
W ujęciu produkcyjnym rozróżniamy dwa stany, które w mowie potocznej bywają mieszane:
No‑Answer — model nie posiada wystarczających danych (brak źródeł, konflikt, niepewność) i jawnie tego nie ukrywa.
Odmowa — odpowiedź jest niepożądana (bezpieczeństwo, prawo, polityka organizacji) i należy ją zablokować.
Standard Luage: brak dowodu → brak pewności. W razie wątpliwości preferuj dopytanie lub eskalację, a nie „uprzejmą fikcję”.
Decyzja oparta na dowodach (źródła) i ryzyku: odpowiedź, dopytanie albo no‑answer + eskalacja.
Macierz decyzji
Sytuacja
Decyzja
Wymóg
Źródła dostępne, ryzyko niskie
Odpowiedz
Cytowania + minimalna niepewność
Źródła dostępne, ryzyko wysokie
Dopytaj lub eskaluj
Weryfikacja, approval, ścieżka audytu
Brak źródeł
No‑Answer (z opcją dopytania)
Jawne ograniczenia + propozycja kolejnego kroku
Źródła sprzeczne
No‑Answer + eskalacja
Wskazanie konfliktu + identyfikatory źródeł
Formuły językowe
No‑Answer nie jest „zbyciem”. Jest to kontrolowany komunikat wraz z propozycją działania.
Minimalny wzorzec:
1) Co wiem / czego nie wiem (jawnie).
2) Dlaczego (brak źródeł / konflikt / ograniczenia).
3) Co mogę zrobić teraz:
- dopytać, albo
- eskalować, albo
- wskazać bezpieczne źródła do dostarczenia.
Ton
spokojny, rzeczowy, bez absolutów („na pewno”, „100%”).
Przejrzystość
jeśli brak danych — mów o braku danych, nie „domykaj” historii.
Następny krok
konkret: pytanie, link do procesu, eskalacja.
Eskalacja i routing
Eskalacja powinna być technicznie prosta: generujemy trace_id, zapisujemy pakiet kontekstu i przekazujemy sprawę do właściciela.
W praktyce:
Compliance/Legal: tryb approval, obowiązkowa ścieżka audytu.
Wiedza/Docs: konflikt źródeł → zadanie aktualizacji dokumentacji.
Tryby pracy z narzędziami
Jeżeli model może wywoływać narzędzia (function calling), polityka no‑answer musi działać również wtedy, gdy narzędzie zawiedzie:
timeout → no‑answer + retry planowy (nie pętla)
error biznesowy → komunikat + eskalacja
brak uprawnień → komunikat + ścieżka dostępu
Testy i regresje
Politykę no‑answer warto ująć w golden set: te same pytania, różne stany dostępności źródeł, różne poziomy ryzyka.
To daje powtarzalność i chroni przed „dryfem uprzejmości”.
Biblioteka odpowiedzi
Poniżej: mini‑przełącznik scenariuszy. Po wdrożeniu można te wzorce wpiąć bezpośrednio do Engine jako szablony.
Wzorzec
Na ten moment nie mam wystarczających źródeł, aby odpowiedzieć rzetelnie.
Jeśli możesz, doprecyzuj: [pytanie 1] / [pytanie 2].
Alternatywnie mogę eskalować sprawę (trace_id) do właściciela wiedzy.
Wzorzec
W dostępnych źródłach występuje konflikt (doc_id: … vs doc_id: …),
więc nie mogę podać jednej wersji jako pewnej.
Zgłaszam eskalację do właściciela dokumentacji. Jeśli chcesz, wskaż preferowane źródło nadrzędne.
Wzorzec
To zagadnienie ma podwyższone ryzyko błędu.
Mogę przedstawić ogólne ramy i wskazać, jakie dane są potrzebne do decyzji,
ale rekomenduję tryb approval (weryfikacja człowieka) przed użyciem w praktyce.
Wzorzec
Żeby odpowiedzieć precyzyjnie, potrzebuję doprecyzowania:
(1) jaki jest cel, (2) jaki kontekst organizacyjny, (3) jakie ograniczenia.
Wybierz jedną z opcji: A / B / C — wtedy podam odpowiedź w formacie gotowym do użycia.
Checklist
No‑Answer ma być jawny, rzeczowy i zawierać następny krok.
Brak źródeł lub konflikt → dopytaj lub eskaluj, nie „domykaj” odpowiedzi.
Wysokie ryzyko → approval / HITL, ścieżka audytu.
Włącz golden set i testy regresji dla polityki no‑answer.