Context engineering: co widzi model i dlaczego

Context engineering to praktyka decydowania o wszystkim, co model językowy widzi, gdy odpowiada: nie tylko o pytaniu, które wpisujesz, ale też o instrukcjach wokół niego, dokumentach i wynikach narzędzi wstawionych do środka, zapisanej pamięci o użytkowniku i dotychczasowej rozmowie. Wszystko to dzieli jedno okno kontekstu, a model odpowiada na podstawie tego tekstu i niczego więcej. Termin upowszechnił się w 2025 roku, gdy coraz więcej produktów AI stawało się agentami, które większość kontekstu składają automatycznie.

Prompt engineering dotyczy głównie tego, jak sformułować prośbę. Context engineering dotyczy tego, co model powinien mieć przed sobą przy każdym wywołaniu i w jakiej kolejności.

Od promptu do kontekstu

W aplikacji czatowej większość kontekstu piszesz sam: aplikacja dodaje prompt systemowy i historię, a ty resztę. W aplikacji opartej na modelu proporcje się odwracają. Użytkownik wpisuje jedno zdanie, a kod wokół modelu dodaje instrukcje, profil użytkownika, trzy artykuły pomocy znalezione przez wyszukiwarkę, listę dostępnych narzędzi i wynik ostatniego wywołania narzędzia. Zdanie użytkownika może być niewielkim ułamkiem tego, co model czyta.

Gdy taki system odpowiada źle, poprawka rzadko leży w sformułowaniu. Zwykle przyczyną jest to, że model dostał niewłaściwy materiał: brakujący fakt, nieaktualny wynik narzędzia, nieistotny dokument, który wyszukiwarce wydał się trafny.

Co trafia do okna kontekstu

Typowe wywołanie w aplikacji AI zawiera część albo wszystkie z tych elementów, mniej więcej w tej kolejności:

• Instrukcje systemowe: rola, zasady i format odpowiedzi, zwykle stałe dla całej aplikacji. Zobacz prompty systemowe.
• Definicje narzędzi: nazwy, opisy i parametry narzędzi, które model może wywołać.
• Przykłady: kilka przykładowych wejść i wyjść pokazujących oczekiwane zachowanie.
• Pamięć: fakty zapisane z wcześniejszych sesji, na przykład plan, język albo preferencje użytkownika.
• Wyszukane dokumenty: fragmenty znalezione w bazie wiedzy dla tego pytania (retrieval-augmented generation, czyli RAG).
• Historia rozmowy: wcześniejsze tury, dosłownie albo w streszczeniu.
• Wyniki narzędzi: wyniki wyszukiwań, uruchomień kodu albo wywołań API wykonanych w trakcie zadania, jak w pętli ReAct.
• Bieżąca wiadomość: to, o co użytkownik właśnie zapytał.

Poniższy blok to jeden złożony kontekst dla asystenta wsparcia. Wyłączaj kolejne części po jednej. Bez części z kontekstem model nie może znać planu klientki; bez części z wejściem nie ma faktów o produkcie, a ograniczenia każą mu to powiedzieć zamiast zgadywać.

Kontekst dla asystenta wsparcia

EditCopy

PartsRoleConstraintsContextInputFormatTask

Role

Jesteś asystentem wsparcia Acme Notes, aplikacji do notatek.

Constraints

Odpowiadaj tylko na podstawie poniższych dokumentów. Jeśli nie obejmują pytania, powiedz to i zaproponuj połączenie klienta z człowiekiem. Nigdy nie zgaduj w sprawie funkcji ani cen.

Context

Pamięć o kliencie: imię Dana, plan Free, korzysta z aplikacji na Androida.

Input

<document source="help/offline-mode"> Tryb offline jest dostępny w planie Pro. Notatki utworzone offline synchronizują się, gdy urządzenie znów połączy się z siecią. Załączniki większe niż 20 MB nie są dostępne offline. </document> <document source="help/plans"> Plan Free: maksymalnie 3 urządzenia. Plan Pro: nieograniczona liczba urządzeń, tryb offline, 30 dni historii wersji. </document>

Format

Od dwóch do czterech zdań prostym językiem. Zwracaj się do klienta po imieniu.

Task

Pytanie klienta: Czy mogę używać aplikacji w samolocie bez internetu?

Try it

Example replyReplies vary between models and runs.

Cześć, Dana! Tryb offline należy do planu Pro, a twoje konto jest obecnie w planie Free, więc w tej chwili ta funkcja nie jest dla ciebie dostępna. W planie Pro notatki tworzone podczas lotu synchronizują się automatycznie, gdy telefon znów połączy się z siecią. Jedno ograniczenie, o którym warto wiedzieć: załączniki większe niż 20 MB nie są dostępne offline.

Zauważ, że poprawna odpowiedź wymaga połączenia dwóch źródeł: pamięci (plan Free) i dokumentu (tryb offline tylko w Pro). Żadne z nich osobno nie wystarcza i to typowa sytuacja. Duża część context engineeringu polega na pilnowaniu, żeby elementy, które się nawzajem potrzebują, docierały razem.

Cztery sposoby, w jakie kontekst się psuje

1. Brakujące informacje. Model wypełnia luki wiarygodnymi domysłami i stąd bierze się wiele halucynacji. Dodaj brakujący fakt albo powiedz modelowi, co ma robić, gdy faktu brakuje.
2. Za dużo materiału. Każdy nieistotny akapit kosztuje tokeny i konkuruje o uwagę. Liu i współautorzy w pracy z 2023 roku "Lost in the Middle: How Language Models Use Long Contexts" wykazali, że badane modele pewniej korzystały z informacji z początku albo końca długiego wejścia niż z informacji w środku. Nowsze modele lepiej radzą sobie z długimi wejściami, ale wysłanie kilku fragmentów, które odpowiadają na pytanie, nadal jest tańsze i łatwiejsze do wykorzystania przez model niż wklejenie całej instrukcji obsługi.
3. Nieaktualne informacje. Wynik narzędzia sprzed dziesięciu kroków może opisywać plik albo saldo, które od tego czasu się zmieniło. Jeśli model widzi obie wersje, może użyć starej.
4. Konflikty. Dwa dokumenty sobie przeczą albo pamięć mówi jedno, a użytkownik drugie. Powiedz modelowi, które źródło wygrywa, na przykład "najnowsza wiadomość użytkownika ma pierwszeństwo przed zapisaną pamięcią".

Kolejność w kontekście

Kolejność zmienia zarówno wyniki, jak i koszt.

• Stałe elementy na początku. Instrukcje systemowe, definicje narzędzi i stały materiał referencyjny rzadko zmieniają się między wywołaniami. Kilku dostawców API oferuje prompt caching, czyli ponowne wykorzystanie przetworzenia identycznego początku wejścia, więc niezmienny prefiks sprawia, że powtarzane wywołania są tańsze i szybsze.
• Długi materiał przed pytaniem. Przy długim dokumencie albo dużym zbiorze fragmentów umieść najpierw materiał, a pytanie i końcowe instrukcje po nim. Na przykład przewodnik po promptach Anthropic zaleca tę kolejność przy długich wejściach, z pytaniem tuż przed miejscem, w którym model zaczyna pisać.
• Opisz każdy element. Otocz każde źródło tagami takimi jak <document>, <memory> albo <tool_result> z nazwą źródła. Etykiety pozwalają modelowi odróżnić dane od instrukcji, a tobie poprosić go o wskazanie, skąd pochodzi odpowiedź. Formaty opisują delimitery i tagi XML.

Przycinanie długiego kontekstu

Każda tura czatu wysyła ponownie całą historię, więc długie sesje rosną, aż coś trzeba usunąć. Zależnie od aplikacji może ona streszczać albo usuwać starsze wiadomości albo poprosić o rozpoczęcie nowego czatu. Lepsze wyniki daje świadome przycinanie.

• Zachowuj kilka ostatnich tur słowo w słowo, a starsze zastępuj streszczeniem.
• Gdy wynik narzędzia został już wykorzystany, zastąp go jednolinijkową notką o tym, co pokazał.
• W każdym streszczeniu zachowuj dokładne identyfikatory: nazwy plików, nazwy funkcji, ID, komunikaty błędów i liczby. Streszczenie, które mówi "plik konfiguracyjny" tam, gdzie historia mówiła settings.prod.yaml, gubi jedyny szczegół, który miał znaczenie.
• W aplikacji czatowej, gdy rozmowa odpływa od tematu, zacznij nowy czat z notatką przekazania. Poniższy prompt ją pisze.

Skompresuj długi czat na nowy start

EditCopy

Fill inprojektsłowa

Ta rozmowa robi się długa. Napisz notatkę przekazania, którą mogę wkleić do nowego czatu, żeby dało się kontynuować pracę bez historii. Uwzględnij: 1. Cel refaktoryzacji formularza rejestracji, w jednym zdaniu. 2. Podjęte decyzje i powód każdej z nich. 3. Aktualny stan: co działa, a co jest niedokończone. 4. Dokładne nazwy, które mają znaczenie: pliki, funkcje, komunikaty błędów, liczby. Skopiuj je dokładnie. 5. Otwarte pytania i następny krok. Pomiń ślepe uliczki, chyba że wyjaśniają jakąś decyzję. Maksymalnie 200 słów.

Try it

Example replyReplies vary between models and runs.

Cel: zastąpić ręcznie pisane sprawdzenia w formularzu rejestracji jednym wspólnym schematem walidacji używanym przez przeglądarkę i serwer.

Decyzje

1. Jeden plik schematu, signupSchema.ts, importowany przez SignupForm.tsx i api/signup.ts, żeby oba zestawy reguł nie mogły się rozjechać.
2. Komunikaty błędów zostają słowo w słowo, bo cytuje je centrum pomocy.

Aktualny stan

1. Walidacja w przeglądarce korzysta ze schematu i SignupForm.test.tsx przechodzi.
2. Serwer nadal wywołuje stare validateSignup() w api/signup.ts.

Dokładne szczegóły: hasła muszą mieć co najmniej 8 znaków i jedną cyfrę. Treść błędu adresu e-mail: "Please enter a valid email address."

Następny krok: zastąpić validateSignup() schematem i uruchomić testy API.

Otwarte pytanie: czy już zarejestrowany adres e-mail ma zwracać 409 czy 400?

Pamięć między sesjami

Pamięć to kontekst, który przeżywa rozmowę: fakty zapisane na koniec jednej sesji i wczytane w następnej. Aplikacje czatowe oferują różne wersje tego mechanizmu, na przykład zapisane wspomnienia albo instrukcje projektu dodawane do każdego czatu w projekcie. We własnej aplikacji pamięć to tabela albo plik z notatkami, który twój kod odczytuje i wstawia. Dwie zasady sprawiają, że pozostaje użyteczna: przechowuj fakty, które pozostają prawdziwe (plan, język, preferowany stos technologiczny), a nie transkrypcje; i wczytuj tylko to, co dotyczy bieżącego zadania, bo pamięć konkuruje o to samo miejsce co wszystko inne.

Składanie kontekstu w kodzie

W aplikacji context engineering to zwykły kod. Ten szkic z Anthropic Python SDK umieszcza stałe zasady i pamięć w prompcie systemowym, zachowuje tylko najnowszą historię i stawia opisane etykietami dokumenty przed pytaniem.

import anthropic

client = anthropic.Anthropic()
MODEL = "your-model-id"  # e.g. from your provider's model list

def build_context(question, docs, history, memory, max_messages=6):
    documents = "\n".join(
        f'<document source="{d["source"]}">\n{d["text"]}\n</document>' for d in docs
    )
    system = (
        "You are the support assistant for Acme Notes. Answer only from the documents. "
        "If they do not cover the question, say so.\n"
        f"<memory>\n{memory}\n</memory>"
    )
    # history holds complete user/assistant pairs, so an even slice starts with a user turn
    recent = history[-max_messages:]
    user = f"<documents>\n{documents}\n</documents>\n\n{question}"
    return system, recent + [{"role": "user", "content": user}]

# question, docs, history and memory come from your application
system, messages = build_context(question, docs, history, memory)
response = client.messages.create(model=MODEL, max_tokens=1024, system=system, messages=messages)
print(response.content[0].text)

Każda decyzja w tej funkcji (które dokumenty, ile wiadomości, gdzie trafia pamięć) to wybór z zakresu context engineeringu i każdą warto przetestować na prawdziwych pytaniach, tak samo jak testujesz zmianę sformułowania.