BRANDBUSTERS SIGNAL / 07 · AI I PRODUKTYWNOŚĆ
Prompt to dopiero początek. Jak projektować kontekst, aby AI działała lepiej i kosztowała mniej
Słaby wynik nie zawsze oznacza słaby model ani źle napisane polecenie. Częściej system nie otrzymał właściwych danych, zasad, przykładów, narzędzi albo informacji o aktualnym stanie zadania. Context engineering polega na dostarczeniu najmniejszego zestawu informacji, który pozwala AI wykonać konkretną pracę poprawnie, powtarzalnie i przy rozsądnym koszcie.
- 14 MIN CZYTANIA
- AI · CONTEXT · EFEKTYWNOŚĆ
- AKTUALIZACJA: PAŹDZIERNIK 2026
Firmy próbują naprawić wynik coraz dłuższym promptem.
Pierwsza wersja odpowiedzi jest zbyt ogólna, więc użytkownik dopisuje rolę, dodatkowe instrukcje, kolejne ograniczenia i całą historię problemu. Następnie wkleja prezentację, notatki ze spotkań, raport, dane z CRM i kilka przykładów.
Prompt rośnie, ale wynik nie zawsze staje się lepszy.
Model otrzymuje więcej informacji, lecz nadal nie wie:
- —które źródło jest najważniejsze;
- —które dane są aktualne;
- —jak rozstrzygać sprzeczności;
- —jaki standard oznacza dobry wynik;
- —których informacji nie wolno używać;
- —jaki format powinien zwrócić;
- —kiedy powinien poprosić człowieka o decyzję.
To nie jest już problem samego promptu. To problem architektury kontekstu.
Context engineering obejmuje nie tylko instrukcję użytkownika, ale cały zestaw informacji dostępnych systemowi w momencie wykonywania zadania: reguły, dane, przykłady, historię, pamięć, narzędzia, wyniki wcześniejszych kroków oraz wymagany format odpowiedzi.
Długi prompt może zawierać dużo tekstu i nadal dostarczać bardzo mało użytecznego kontekstu.
WIĘCEJ ≠ LEPIEJ
Dłuższy kontekst nie gwarantuje lepszej odpowiedzi. Nadmiar informacji może rozpraszać uwagę modelu i utrudniać odnalezienie właściwego sygnału.
Źródło: Anthropic, Effective Context Engineering for AI Agents ↗DO 95%
W obsługiwanych scenariuszach ponowne wykorzystanie tego samego prefiksu przez prompt caching może znacząco obniżyć koszt tokenów wejściowych. Rzeczywisty poziom zależy od modelu i konfiguracji.
Źródło: OpenAI, Prompt Caching ↗JAKOŚĆ / KOSZT / CZAS
Efektywne aplikacje AI powinny optymalizować nie tylko jakość odpowiedzi, lecz także koszt oraz opóźnienie całego procesu.
Źródło: Microsoft Research, Efficient AI Applications ↗Prompt engineering mówi modelowi, co ma zrobić. Context engineering decyduje, z czego może skorzystać.
PROMPT ENGINEERING
- —Formułuje zadanie.
- —Określa rolę i instrukcję.
- —Ustala format odpowiedzi.
- —Dodaje ograniczenia.
- —Pomaga wykonać pojedyncze zadanie.
CONTEXT ENGINEERING
- —Wybiera właściwe dane i źródła.
- —Określa ich priorytet oraz aktualność.
- —Dostarcza przykłady dobrego wyniku.
- —Zarządza historią, pamięcią i stanem procesu.
- —Udostępnia właściwe narzędzia.
- —Ogranicza niepotrzebne informacje.
- —Pozwala powtarzalnie obsługiwać cały proces.
Dobry prompt pozostaje ważny. Nie powinien jednak próbować zastępować bazy wiedzy, systemu uprawnień, historii klienta, danych operacyjnych, logiki procesu i mechanizmu kontroli jakości.
07 / CONTEXT ENGINEERING
Siedem warstw dobrego kontekstu
- 01
CEL
Jaki rezultat biznesowy i jaka decyzja mają powstać?
- 02
ZASADY
Jakie instrukcje, ograniczenia i priorytety są stałe?
- 03
WIEDZA
Które dane i dokumenty są potrzebne właśnie teraz?
- 04
PRZYKŁADY
Jak wygląda dobry wynik i jakie błędy są niedopuszczalne?
- 05
NARZĘDZIA
Co system może sprawdzić, obliczyć lub wykonać?
- 06
STAN I PAMIĘĆ
Co wydarzyło się wcześniej i co pozostaje aktualne?
- 07
WYNIK I OCENA
W jakim formacie ma powstać odpowiedź i jak sprawdzimy jej jakość?
Kontekst nie powinien być największy z możliwych. Powinien być najmniejszy z wystarczających.
Siedem warstw — od celu do oceny
- 01
Cel: zacznij od rezultatu, a nie od możliwości modelu.
Polecenie „przeanalizuj sprzedaż” nie określa, czy system ma znaleźć przyczynę spadku, przygotować komentarz do zarządu, przewidzieć wynik czy zaproponować działania.
To różne zadania, wymagające innych danych, metod i poziomu odpowiedzialności.
Kontekst powinien wskazywać:
- —użytkownika wyniku;
- —decyzję, którą wynik ma wspierać;
- —horyzont czasowy;
- —najważniejszy miernik;
- —granice odpowiedzialności systemu.
Pytanie
Jaka konkretna decyzja stanie się łatwiejsza dzięki odpowiedzi?
- 02
Zasady: oddziel to, co stałe, od tego, co zmienia się w każdym zadaniu.
Stały kontekst może obejmować definicje KPI, ton marki, politykę prywatności, reguły akceptacji, hierarchię źródeł i zasady eskalacji. Dane klienta, okres analizy, pytanie i bieżący stan są kontekstem dynamicznym.
Mieszanie wszystkiego w jednym długim promptcie utrudnia utrzymanie, testowanie i ponowne wykorzystanie.
W systemach korzystających z API stabilny początek kontekstu może również wspierać prompt caching, jeżeli model i konfiguracja obsługują taką możliwość.
Pytanie
Które instrukcje powinny być wspólne dla stu zadań, a które należą tylko do jednego przypadku?
- 03
Wiedza: nie wklejaj całej biblioteki, jeżeli potrzebujesz trzech właściwych stron.
Duże okno kontekstowe nie oznacza, że należy wypełnić je wszystkim, co może być potencjalnie przydatne.
Lepszym rozwiązaniem jest pobieranie informacji potrzebnych w danym kroku: odpowiedniego fragmentu dokumentu, właściwej wersji cennika, historii konkretnego klienta albo danych z wybranego okresu.
Kontekst powinien zachowywać:
- —źródło;
- —datę;
- —wersję;
- —właściciela informacji;
- —poziom zaufania;
- —ewentualne ograniczenia.
Pytanie
Jakiej najmniejszej porcji wiedzy system potrzebuje, aby wykonać ten krok poprawnie?
- 04
Przykłady: jeden dobry wzorzec może zastąpić stronę instrukcji.
Modele dobrze uczą się oczekiwanego zachowania na konkretnych przykładach. Warto pokazać zarówno dobry rezultat, jak i przypadek, który powinien zostać odrzucony lub przekazany człowiekowi.
Przykłady muszą być reprezentatywne. Dziesiątki podobnych przypadków zwiększają liczbę tokenów, ale niekoniecznie uczą system większej liczby zachowań.
Najlepszy zestaw pokazuje różnorodne, ważne sytuacje: przypadek standardowy, trudny, graniczny i taki, w którym system powinien odmówić albo eskalować.
Pytanie
Czy przykład pokazuje modelowi oczekiwany standard, czy jedynie kolejną wersję tego samego przypadku?
- 05
Narzędzia: system nie musi pamiętać danych, które może bezpiecznie sprawdzić.
Dobrze zaprojektowane narzędzie pozwala pobrać aktualny stan zamówienia, sprawdzić dostępność, wykonać obliczenie, wyszukać dokument lub zapisać wynik w odpowiednim systemie.
Lista narzędzi nie powinna być nieograniczona. Narzędzia o zbliżonym przeznaczeniu utrudniają wybór, zwiększają koszt i mogą prowadzić do błędnych działań.
Każde narzędzie powinno mieć:
- —jednoznaczną nazwę;
- —precyzyjny opis zastosowania;
- —minimalny zestaw parametrów;
- —przewidywalny format wyniku;
- —ograniczone uprawnienia;
- —obsługę błędów i eskalacji.
Pytanie
Czy człowiek potrafi jednoznacznie wskazać, kiedy należy użyć każdego narzędzia?
- 06
Stan i pamięć: historia rozmowy nie jest jeszcze pamięcią biznesową.
Długa konwersacja może zawierać decyzje, wersje robocze, błędy i nieaktualne informacje. Przekazywanie jej w całości do każdego kolejnego kroku zwiększa koszt i ryzyko wykorzystania niewłaściwego fragmentu.
System powinien rozróżniać:
- —bieżący stan zadania;
- —zatwierdzone decyzje;
- —trwałe preferencje;
- —robocze notatki;
- —informacje, które wygasły;
- —materiał źródłowy.
Pamięć powinna być selektywna, możliwa do aktualizacji i powiązana ze źródłem.
Pytanie
Które informacje mają przetrwać kolejne zadanie, a które powinny zostać zapomniane?
- 07
Wynik i ocena: odpowiedź bez kryterium jakości jest jedynie propozycją.
System musi wiedzieć, jaki format wyniku jest potrzebny: tabela, rekomendacja, projekt wiadomości, lista ryzyk, rekord CRM czy decyzja do zatwierdzenia.
Potrzebuje również kryteriów oceny. Mogą obejmować poprawność faktów, kompletność, zgodność ze stylem, wykorzystanie źródeł, koszt, czas, bezpieczeństwo oraz liczbę poprawek wymaganych przed użyciem.
Zmiana promptu, modelu, narzędzia lub źródła danych powinna zostać przetestowana na tym samym zestawie rzeczywistych przypadków.
Pytanie
Po czym niezależna osoba rozpozna, że wynik można przyjąć?
Różnica nie polega na długości promptu. Polega na jakości decyzji o kontekście.
PRZED
Zadanie
„Przeanalizuj wyniki sprzedaży i napisz rekomendacje.”
Dołączony materiał
- —cały raport roczny;
- —eksport CRM;
- —prezentacja marketingowa;
- —notatki z kilku spotkań;
- —brak definicji mierników;
- —brak wskazanego odbiorcy;
- —brak formatu wyniku.
Typowy rezultat
Ogólne podsumowanie, dużo obserwacji i brak decyzji.
PO
Cel
Wyjaśnij spadek marży kontrybucyjnej w ostatnich ośmiu tygodniach i wskaż trzy decyzje dla dyrektora komercyjnego.
Kontekst
- —definicja marży kontrybucyjnej;
- —dane sprzedaży według kanału, kategorii i promocji;
- —porównywalny okres;
- —zmiany cen oraz kosztów;
- —lista znanych zakłóceń;
- —trzy przykłady poprawnej analizy;
- —wymagane wskazanie źródła każdej tezy.
Format
- —główna przyczyna;
- —dowody;
- —alternatywne wyjaśnienia;
- —rekomendowane decyzje;
- —ryzyka;
- —brakujące dane.
Typowy rezultat
Materiał, który można zweryfikować i wykorzystać w rozmowie decyzyjnej.
Więcej jakości nie powstało dzięki bardziej efektownemu językowi. Powstało dzięki lepszemu wyborowi informacji i kryteriów.
Traktuj kontekst jak budżet, a nie jak bezpłatny magazyn.
Każdy dodatkowy fragment może pomóc, ale może również zwiększyć koszt, czas odpowiedzi, liczbę sprzeczności i trudność odnalezienia właściwego sygnału.
| # | Element | Zostaw w kontekście, gdy | Przenieś lub pobierz później, gdy |
|---|---|---|---|
| 01 | Instrukcja | Zostaw w kontekście, gdyJest potrzebna w każdym zadaniu. | Przenieś lub pobierz później, gdyDotyczy rzadkiego wyjątku. |
| 02 | Dokument | Zostaw w kontekście, gdyCałość jest niezbędna do porównania. | Przenieś lub pobierz później, gdyPotrzebny jest jeden rozdział lub fragment. |
| 03 | Historia | Zostaw w kontekście, gdyZawiera aktualną decyzję lub stan. | Przenieś lub pobierz później, gdyJest roboczym przebiegiem bez trwałej wartości. |
| 04 | Przykład | Zostaw w kontekście, gdyPokazuje odrębny ważny wzorzec. | Przenieś lub pobierz później, gdyPowtarza zachowanie już przedstawione. |
| 05 | Dane | Zostaw w kontekście, gdySą potrzebne do bieżącego obliczenia. | Przenieś lub pobierz później, gdyMożna je pobrać w chwili użycia. |
| 06 | Narzędzie | Zostaw w kontekście, gdyMa jednoznaczne zastosowanie w procesie. | Przenieś lub pobierz później, gdyDubluje funkcję innego narzędzia. |
Dobra architektura częściej pobiera właściwy kontekst na żądanie, niż przenosi całą dostępną wiedzę do każdego wywołania.
Dziewięć sposobów na lepszy wynik przy mniejszym zużyciu tokenów
- 01Oddziel stabilne instrukcje od dynamicznego zadania.
- 02Umieszczaj wspólny, niezmienny kontekst w stabilnym prefiksie, jeżeli wykorzystywana technologia wspiera caching.
- 03Pobieraj tylko potrzebne fragmenty źródeł zamiast całych dokumentów.
- 04Zastępuj długą historię zatwierdzonym stanem i krótkim podsumowaniem decyzji.
- 05Używaj kilku różnorodnych przykładów zamiast listy podobnych przypadków.
- 06Ogranicz liczbę narzędzi i usuń nakładające się funkcje.
- 07Proste, dobrze zdefiniowane zadania kieruj do modelu o odpowiednim koszcie i możliwościach.
- 08Zatrzymuj agentów po osiągnięciu wyniku albo przekroczeniu limitu kosztu, czasu lub liczby kroków.
- 09Mierz koszt zaakceptowanego wyniku, a nie wyłącznie koszt pojedynczego wywołania.
Nie skracaj kontekstu kosztem informacji niezbędnej do poprawnego lub bezpiecznego wykonania zadania. Celem nie jest minimalna liczba tokenów. Celem jest najwyższa wartość uzyskana z każdego użytego tokenu.
Osiem błędów context engineeringu
- 01Jeden gigantyczny prompt próbuje zawierać całą logikę firmy.
- 02System otrzymuje wszystkie dostępne dokumenty bez selekcji i hierarchii.
- 03Sprzeczne źródła są traktowane tak, jakby miały ten sam poziom wiarygodności.
- 04Historia rozmowy pełni jednocześnie funkcję instrukcji, pamięci i bazy wiedzy.
- 05Zespół dodaje kolejne wyjątki, ale nie usuwa nieaktualnych reguł.
- 06Agent otrzymuje zbyt wiele podobnych narzędzi i zbyt szerokie uprawnienia.
- 07Jakość jest oceniana na podstawie jednego efektownego przykładu.
- 08Firma zmienia model lub prompt bez ponownego uruchomienia testów na rzeczywistych przypadkach.
Kontekst, którego nikt nie utrzymuje, z czasem staje się zbiorem sprzecznych instrukcji.
Scorecard context engineeringu
| # | Miernik | Co pokazuje |
|---|---|---|
| 01 | Odsetek zaakceptowanych wyników | Co pokazujeJaka część odpowiedzi może zostać wykorzystana bez istotnej poprawki. |
| 02 | Poprawność faktów | Co pokazujeCzy wynik jest zgodny ze źródłami i aktualnymi danymi. |
| 03 | Kompletność | Co pokazujeCzy system uwzględnił wszystkie wymagane elementy. |
| 04 | Liczba korekt | Co pokazujeIle pracy człowieka wymaga wynik przed użyciem. |
| 05 | Tokeny na zaakceptowany wynik | Co pokazujeIle kontekstu i generowania potrzeba do uzyskania użytecznego rezultatu. |
| 06 | Koszt zaakceptowanego wyniku | Co pokazujeJaki jest pełny koszt modelu, narzędzi i ponownych prób. |
| 07 | Czas do wyniku | Co pokazujeIle trwa cały proces, a nie tylko wygenerowanie pierwszej odpowiedzi. |
| 08 | Liczba eskalacji | Co pokazujeCzy system rozpoznaje przypadki wymagające człowieka. |
| 09 | Cache hit rate | Co pokazujeJaka część stabilnego kontekstu jest ponownie wykorzystywana w obsługiwanych scenariuszach. |
Najtańsza odpowiedź nie jest najbardziej efektywna, jeżeli człowiek musi ją pisać od początku. Najdroższy model również nie jest najlepszy, jeżeli otrzymuje źle zaprojektowany kontekst.
Jak przejść od promptów do systemu w 30 dni
TYDZIEŃ 1
Wybierz jeden powtarzalny proces.
- Wybierz zadanie wykonywane regularnie i posiadające mierzalny wynik.
- Zbierz od 20 do 30 rzeczywistych przypadków.
- Zapisz obecny czas, koszt, jakość i liczbę poprawek.
- Wskaż przypadki, w których system powinien eskalować do człowieka.
TYDZIEŃ 2
Rozdziel warstwy kontekstu.
- Zdefiniuj cel i format wyniku.
- Oddziel stałe zasady od danych konkretnego przypadku.
- Ustal hierarchię źródeł.
- Wybierz kilka reprezentatywnych przykładów.
- Ogranicz zestaw narzędzi.
TYDZIEŃ 3
Uruchom kontrolowany test.
- Przetestuj ten sam zestaw przypadków.
- Zmierz jakość, koszt, tokeny, czas i korekty.
- Zapisz najczęstsze tryby błędów.
- Dodawaj kontekst wyłącznie w odpowiedzi na zaobserwowany problem.
TYDZIEŃ 4
Ustal standard operacyjny.
- Zatwierdź źródła, instrukcje i przykłady.
- Ustal właściciela kontekstu.
- Wprowadź wersjonowanie i datę przeglądu.
- Zdefiniuj limit kosztu, czasu oraz autonomii.
- Podejmij decyzję: skalujemy, poprawiamy albo zatrzymujemy.
Dziesięć pytań przed skalowaniem rozwiązania AI
- 01Jaki proces i wynik biznesowy poprawia rozwiązanie?
- 02Które informacje są naprawdę potrzebne w każdym zadaniu?
- 03Które dane powinny być pobierane dopiero w momencie użycia?
- 04Jak system rozstrzyga sprzeczne źródła?
- 05Kto odpowiada za aktualność instrukcji i wiedzy?
- 06Jakie przykłady definiują dobry wynik?
- 07Które narzędzia i uprawnienia są rzeczywiście konieczne?
- 08Po czym system rozpoznaje, że powinien poprosić człowieka?
- 09Ile kosztuje zaakceptowany wynik, a nie pojedyncza odpowiedź?
- 10Jak sprawdzimy, czy kolejna zmiana poprawiła jakość zamiast jej zaszkodzić?
Najlepszy system AI nie wie wszystkiego. Wie, czego potrzebuje właśnie teraz.
Context engineering przesuwa rozmowę z efektownych promptów na projektowanie rzeczywistego sposobu pracy.
Zamiast oczekiwać, że model sam odgadnie definicje, priorytety, aktualne dane i standard jakości, firma tworzy środowisko, w którym właściwa informacja trafia do właściwego zadania we właściwym momencie.
To poprawia nie tylko jakość odpowiedzi. Ułatwia kontrolę kosztów, aktualizację wiedzy, zarządzanie ryzykiem i skalowanie rozwiązania poza grupę najbardziej zaawansowanych użytkowników.
Nie pytaj, jak napisać idealny prompt. Zaprojektuj system, który dostarcza właściwy kontekst.
CHCESZ PRZEJŚĆ OD EKSPERYMENTÓW DO POWTARZALNEGO SYSTEMU AI?
Zaprojektujmy proces, kontekst, mierniki i kontrolę, zanim zaczniemy go skalować.
Możemy wybrać właściwy przypadek użycia, zbudować architekturę kontekstu, przygotować zestaw testowy i sprawdzić jakość oraz ekonomikę rozwiązania.