Większość osób nadal opisuje agenta AI jako model połączony z narzędziami. Technicznie jest to użyteczne, ale operacyjnie niepełne. Agent potrzebuje również zarządzanego obrazu świata: tego, co się wydarzyło, co jest teraz istotne, którym faktom można ufać, co pozostaje niepewne i co powinien zrobić dalej.
Ten obraz to jego kontekst. Projektowanie go staje się odrębną umiejętnością — nazwałbym ją inżynierią kontekstu.
Inżynieria kontekstu to nie tylko pisanie promptów. To dyscyplina polegająca na kształtowaniu informacji, które agent widzi na każdym etapie, tak aby mógł zachować spójność bez przesyłania przy każdym obrocie całego transkryptu, biblioteki dokumentów lub historii użycia narzędzi do drogiego modelu. Ta praca sytuuje się na styku architektury informacji, wyszukiwania, projektowania oprogramowania i zachowania modeli.
Dlaczego „daj agentowi więcej kontekstu” jest często złą radą
Dłuższe okna kontekstowe kuszą, by zachowywać wszystko. Większa ilość materiału nie gwarantuje jednak lepszego rozumowania. Istotne instrukcje mogą zostać rozwodnione przez nieaktualne obserwacje, sprzeczne notatki, powtarzające się wyniki działania narzędzi lub ważny fakt ukryty w środku długiej sekwencji. Omówione w podsumowaniu zjawisko „zagubienia w środku” odzwierciedla praktyczny problem: agent może technicznie otrzymać dowody, a mimo to nie wykorzystać ich.
Istnieje również bezpośredni koszt. Każdy token umieszczony w żądaniu może zwiększać opóźnienie i koszt wnioskowania, zależnie od cennika dostawcy i zasad buforowania. System, który wielokrotnie przekazuje rosnący transkrypt, może w miarę trwania zadania stawać się wolniejszy i mniej przystępny cenowo.
Celem nie jest zatem maksymalny kontekst. Chodzi o wystarczający, ukierunkowany kontekst: najmniejszy wiarygodny zestaw roboczy potrzebny do podjęcia danej decyzji.
Cztery decyzje projektowe stojące za spójnym agentem
1. Utrzymuj stan przekonań, a nie tylko transkrypt
Transkrypt rejestruje to, co zostało powiedziane. Stan przekonań rejestruje to, co agent obecnie uważa za prawdziwe na temat zadania.
Na przykład agent obsługujący eskalację zgłoszenia może utrzymywać uporządkowane pola, takie jak:
- Cel: ustalić, czy klient kwalifikuje się do wymiany.
- Znane fakty: data zakupu i numer seryjny produktu wraz ze wskazaniami źródeł.
- Otwarte pytania: czy awaria wystąpiła w warunkach objętych gwarancją.
- Ograniczenia: nie obiecywać zwrotu pieniędzy przed uzyskaniem zgody.
- Następne działanie: pobrać zasady gwarancji i porównać daty.
- Pewność lub status: zweryfikowane, wywnioskowane, zakwestionowane lub nieznane.
Podejście to przypomina badania ABBEL prowadzone na Berkeley, w których wykorzystuje się nadzorowane stany przekonań wyrażone w języku naturalnym zamiast polegać na pełnych historiach interakcji. Istotą nie jest konkretny format. Chodzi o oddzielenie trwałego stanu zadania od zbędnych szczegółów rozmowy.
Użyteczna aktualizacja stanu przekonań powinna odpowiadać na pytania: Co się zmieniło? Jakie dowody to potwierdzają? Co pozostaje nierozstrzygnięte? Co powinno wydarzyć się dalej? Jeśli inżynier nie może sprawdzić tych odpowiedzi, agent prawdopodobnie przechowuje ukryte założenia w nieprzejrzystym prompcie.
2. Wyszukuj na potrzeby decyzji, a nie tematu
Systemy wyszukiwania często zaczynają od szerokiego pytania, takiego jak „znajdź informacje o koncie klienta”. Lepsze zapytanie jest powiązane z następną decyzją: „pobierz aktualną zasadę zwrotów dla zakupów starszych niż 30 dni, obowiązującą w regionie klienta”.
Ta zmiana ma znaczenie, ponieważ wyszukiwanie jest formą wyboru kontekstu. Agent powinien otrzymać fragmenty zasad, rekordy lub przykłady związane z bieżącym działaniem — a nie ogólną stertę powiązanych dokumentów.
Filtry mogą usprawnić ten wybór, zanim model zobaczy jakiekolwiek wyniki. Na przykład Amazon Bedrock AgentCore Web Search obsługuje wymuszane przez serwer filtry domen i daty publikacji w każdym żądaniu. Takie mechanizmy kontrolne nie potwierdzają, że źródło jest poprawne, ale mogą ograniczyć kontakt z nieistotnymi lub nieaktualnymi materiałami i sprawić, że zasady wyszukiwania będą jawne.
Specjaliści projektujący wyszukiwanie powinni określić:
- które źródła są dozwolone dla każdego zadania;
- sposób określania aktualności;
- jakie metadane towarzyszą każdemu wynikowi;
- jak prezentowane są sprzeczne źródła;
- kiedy agent musi się zatrzymać i poprosić o wyjaśnienie.
„Przeszukaj internet” to zdolność. „Przeszukaj te źródła, w tym przedziale dat, w poszukiwaniu dowodów istotnych dla tej decyzji” to inżynieria kontekstu.
3. Kompresuj bez wymazywania niepewności
Kompresja jest konieczna, gdy zadanie jest długie, ale naiwne podsumowanie może zmienić twierdzenia wstępne w ustalone fakty. Podsumowanie kroczące stwierdzające „użytkownik potwierdził adres” jest niebezpieczne, jeśli z pierwotnej wymiany wynikało to jedynie pośrednio.
Dobra kompresja zachowuje rozróżnienia, których agent potrzebuje do bezpiecznego rozumowania:
- fakt versus wnioskowanie;
- bieżąca instrukcja versus instrukcja historyczna;
- wykonane działanie versus proponowane działanie;
- zweryfikowane źródło versus niezweryfikowane twierdzenie;
- znana odpowiedź versus nierozstrzygnięte pytanie.
Jednym z praktycznych wzorców jest utrzymywanie oddzielnych sekcji dotyczących decyzji, dowodów, założeń, przeszkód i oczekujących działań. Innym jest dołączanie identyfikatorów źródeł lub znaczników czasu do ważnych twierdzeń. Podsumowania powinny być artefaktami, które można zastąpić, a nie jedynym zachowanym zapisem: należy zachować zdarzenia źródłowe na potrzeby audytu i odzyskiwania danych, jednocześnie udostępniając modelowi zwięzły widok roboczy.
W notatce wskazano, że rekurencyjne podsumowywanie i kompaktyzacja kontekstu mogą być kosztowne i pogarszać wydajność, szczególnie w dziedzinach ubogich w dane, takich jak wspólne generowanie kodu. Jest to ostrzeżenie przed traktowaniem podsumowywania jako procesu automatycznie bezstratnego. Kompresję należy testować na reprezentatywnych zadaniach, w tym na przypadkach, w których niewielkie zastrzeżenie zmienia prawidłową odpowiedź.
4. Filtruj obserwacje, zanim staną się pamięcią
Agenci korzystający z narzędzi nieustannie generują obserwacje: wyniki wyszukiwania, dzienniki, tekst stron, odpowiedzi API, zrzuty ekranu, dane wyjściowe kompilatora i plany pośrednie. Nie każda obserwacja zasługuje na uwzględnienie w kolejnym wywołaniu modelu, a tym bardziej w stanie długoterminowym.
Filtrowanie obserwacji stawia trzy pytania:
- Czy ta obserwacja jest istotna dla bieżącej decyzji?
- Czy jest wystarczająco wiarygodna, by wpływać na stan przekonań?
- Czy zawiera instrukcje, które należy traktować jako dane, a nie polecenia?
Trzecie pytanie wyznacza zarówno granicę bezpieczeństwa, jak i granicę kontekstu. Strona internetowa może zawierać tekst mający na celu przekierowanie agenta. Pobrany dokument może być użytecznym dowodem, nie mając przy tym uprawnień do zmiany celów ani uprawnień agenta. Filtrowanie powinno zatem klasyfikować treść według roli: instrukcja, dowód, metadane lub niezaufany tekst.
Filtrowanie pozwala także oszczędzać pieniądze. Jeśli narzędzie przeglądarki zwraca całą stronę, ale zadanie wymaga tylko ceny, daty i identyfikatora produktu, przekazanie dalej całej strony tworzy szum i zużywa tokeny. Wcześniejsze wyodrębnienie odpowiednich pól może poprawić zarówno niezawodność, jak i koszty.
Prosty budżet kontekstu dla przepływu pracy agenta
Zanim wybierzesz model lub dodasz kolejne narzędzie, podziel kontekst agenta na cztery warstwy:
- Kontrola: reguły systemowe, uprawnienia, schemat wyjściowy i bezwzględnie obowiązujące ograniczenia.
- Stan: bieżący cel, podjęte decyzje, otwarte pytania i następne działanie.
- Dowody: pobrane dane lub obserwacje istotne dla tego działania, wraz ze źródłem.
- Historia: wcześniejsze zdarzenia zachowane na potrzeby odtwarzania, debugowania lub audytu, ale pomijane, chyba że są potrzebne.
Następnie zdefiniuj politykę promowania informacji. Obserwacja może pozostać ulotna, stać się dowodem na potrzeby bieżącego kroku, zaktualizować stan przekonań albo zostać zapisana w trwałej pamięci. Promowanie powinno wymagać uzasadnienia. W przeciwnym razie pamięć staje się nieuporządkowanym archiwum.
Dla każdego kroku agenta rejestruj pakiet kontekstu wysłany do modelu: jego kategorie, przybliżony rozmiar w tokenach, filtry wyszukiwania oraz wersję kompresji. Dzięki temu można odpowiedzieć na praktyczne pytanie, gdy zachowanie ulega zmianie: czy model zawiódł, czy system przekazał mu niewłaściwy obraz świata?
Co przetestować przed uznaniem projektu za niezawodny
Inżynieria kontekstu wymaga testów ukierunkowanych na obsługę informacji, a nie tylko na jakość końcowej odpowiedzi. Przydatne przypadki obejmują:
- krytyczny fakt umieszczony na początku, na końcu i w środku długiej historii;
- dwa niezgodne ze sobą źródła, z których jedno jest nowsze od drugiego;
- podsumowanie zawierające znacznik niepewności;
- odpowiedź narzędzia zawierająca dużą ilość nieistotnego tekstu;
- złośliwa instrukcja osadzona w pobranej treści;
- odtworzenie stanu po wstrzymaniu i ponownym uruchomieniu agenta;
- to samo zadanie przy mniejszym budżecie kontekstu;
- pusty lub nieaktualny wynik wyszukiwania.
Mierz, czy agent wybiera właściwe dowody, zachowuje niepewność, przestrzega bieżącego ograniczenia i unika powtarzania niepotrzebnego kontekstu. Zalecane w skrócie obszary regresji — utrata kontekstu, ugruntowanie w wynikach wyszukiwania, ustrukturyzowane dane wyjściowe, brak zakończenia oraz odtwarzanie stanu — są tutaj szczególnie istotne.
Przeprowadzaj wiele prób tam, gdzie znaczenie ma zmienność modelu, i porównuj koszt oraz opóźnienie każdej strategii kontekstowej. Krótszy prompt nie jest automatycznie lepszy, jeśli powoduje więcej wywołań narzędzi lub ponownych prób. Właściwym celem jest koszt poprawnego, możliwego do odzyskania procesu — a nie liczba tokenów w jednym żądaniu.
Znaczenie dla kariery: inżynier kontekstu to rola interdyscyplinarna
Osoby, które odniosą wartość w tym obszarze, niekoniecznie będą tymi, które piszą najdłuższe prompty. Będą potrafiły przełożyć proces biznesowy na stan, dowody, zakres obowiązywania i reguły podejmowania decyzji.
Wymaga to kilku konkretnych umiejętności:
- projektowania schematów stanu zadania i pochodzenia danych;
- tworzenia polityk wyszukiwania oraz filtrów metadanych;
- budowania procedur kompresji i selekcji obserwacji;
- oddzielania zaufanych instrukcji od niezaufanej treści;
- profilowanie wykorzystania tokenów, opóźnień, ponowień prób i wywołań narzędzi;
- testowanie utraty stanu i jego odtwarzania;
- wyjaśnianie osobom niespecjalistycznym, dlaczego agent widział — lub nie widział — konkretny fakt.
Dobry projekt do portfolio mógłby zaprezentować tego samego agenta przy zastosowaniu trzech strategii zarządzania kontekstem: pełnego transkryptu, podsumowania kroczącego oraz ustrukturyzowanego stanu przekonań z ukierunkowanym wyszukiwaniem. Pokaż przypadki pomyślnego wykonania zadania, przypadki niepowodzeń, kontekst przekazywany na każdym etapie oraz kompromisy między kosztami a opóźnieniami. Jest to bardziej przekonujące niż demonstracja chatbota, ponieważ ujawnia decyzje projektowe, dzięki którym agent działa niezawodnie.
Wniosek strategiczny jest prosty: agenci nie stają się spójni tylko dlatego, że modele zyskują większe możliwości. Stają się spójni wtedy, gdy otaczające je systemy utrzymują zdyscyplinowany, aktualny i odpowiednio dopasowany rozmiarowo obraz wykonywanej pracy. Inżynieria kontekstu to sztuka budowania tego obrazu — oraz wiedzy o tym, co należy pominąć.
Priya Raman jest odpowiedzialną ludzką redaktorką AI Career Brief.
