Context Engineering: dlaczego się liczy i jak robić to dobrze
Context engineering kształtuje wszystko, co widzi model, nie tylko prompt. To właśnie czyni agentów wiarygodnymi.
Tłumaczenie wygenerowane automatycznie przez AI. Wersja niemiecka jest oryginałem zweryfikowanym redakcyjnie.
Niezawodność agenta AI zależy mniej od samego modelu, a bardziej od tego, co mu Państwo przedstawiają. Context engineering to praktyka kształtowania całej tej ilości informacji: prompt systemowy, pamięć, narzędzia i dane, które Państwo pobierają, a nie tylko samo pytanie. Z naszego doświadczenia wynika, że jest to największa pojedyncza dźwignia decydująca o tym, czy agent działa w produkcji, i jest to inna dyscyplina niż prompt engineering (Context Engineering 2.0).
01. POZA PROMPTEM
Prompt engineering dostraja pytanie. Context engineering kształtuje środowisko, w którym model podejmuje decyzje. Dla jednorazowego zadania wystarczy dobry prompt. Dla agenta, który działa przez wiele kroków, odczytuje narzędzia i niesie ze sobą pamięć, prompt to tylko niewielka część tego, co widzi model. Reszta, czyli to, co Państwo pobierają, co Państwo zapamiętują, jakie narzędzia i w jaki sposób Państwo udostępniają, to kontekst, i to on decyduje o wyniku w znacznie większym stopniu. Dlatego rozszerzanie agentycznego harnessu to w przeważającej mierze praca nad kontekstem.
02. CZTERY WZORCE AWARII, PRZED KTÓRYMI SIĘ PROJEKTUJE
Większość awarii agentów wynika z jednego z czterech problemów kontekstowych:
- Przeciążenie kontekstu. Zbyt wiele w oknie. Model gubi wątek, a koszty i opóźnienia rosną. Więcej kontekstu nie znaczy lepszego kontekstu.
- Zatrucie kontekstu. Do okna trafia błędny lub nieaktualny fakt, a model traktuje go jako prawdę. Jeden słaby pobrany fragment może wykoleić odpowiedź.
- Zarządzanie tokenami. Okno jest skończone. Bez planu, co zachować, a co odrzucić, ważny szczegół zostaje wyparty przez szum.
- Nieaktualna pamięć. Długo działające agenty gromadzą kontekst, który już nie obowiązuje, i działają na jego podstawie.
Nazwanie awarii to połowa rozwiązania. Każda z nich ma konkretny środek zaradczy.
03. PRAKTYKI, KTÓRE SIĘ SPRAWDZAJĄ
Kilka wzorców powraca w konfiguracjach, które pozostają niezawodne:
- Pobierać, nie zwalać w całości. Proszę pozyskiwać nieliczne istotne fragmenty za pomocą dobrego retrieval, zamiast kopiować wszystko naraz. To cały sens RAG, czyli context engineering zastosowany do danych.
- Przycinać na bieżąco. Proszę stosować w harnessie edycję opartą na regułach, aby okno pozostawało szczupłe: odrzucać to, czego dany krok już nie potrzebuje.
- Podsumowywać długie historie. Proszę zastępować długi zapis wiernym podsumowaniem, zanim wyprze on zadanie.
- Zaczynać prosto, skalować w razie potrzeby. Proszę dodawać pamięć i narzędzia tylko wtedy, gdy wymaga tego rzeczywista awaria, a nie domyślnie.
Instynkt dodawania kolejnych elementów to pułapka. Dyscyplina polega na pomijaniu.
04. DLACZEGO TO JEST PRAWDZIWY INŻYNIERING
Większy model rzadko rozwiązuje problem kontekstowy, po prostu zawodzi drożej. Praca, która przenosi agenta od demo do niezawodności, to niemal wyłącznie praca nad kontekstem: co on widzi, kiedy i co ma zapomnieć. Przy bardzo długich danych wejściowych liczy się także architektura modelu, i tu do gry wchodzą podejścia subkwadratowe, ale dla większości zespołów zysk tkwi w kontekście, a nie w parametrach.
