Inżynieria kontekstu: praca przed podpowiedzią
· 6 min read · Filippo Spinella · AI, Agents, Prompting, Developer Tools
Najważniejszym momentem w małym świecie agentów AI jest inżynieria kontekstu.
Wygląda na to, że to kolejna etykieta wymyślona po to, by sprzedawać coś, co już zrobiliśmy. Po części tak. Jednak, jak to często bywa, etykieta się przyjęła, ponieważ nadaje nazwę prawdziwemu bólowi.
Problem jest taki: modele nie ponoszą porażek tylko dlatego, że „nie myślą”. Często zawodzą, ponieważ wysyłamy ich do pracy w złym pomieszczeniu.
Dajemy im stare instrukcje. Ukrywamy przed nim ważne pliki. Przekazujemy im dokumenty, które są za długie i nie mówią, co jest istotne. Pokazujemy im logi bez priorytetu. Dajemy im dziesięć narzędzi, nie wyjaśniając, kiedy z nich korzystać. Wtedy jesteśmy zaskoczeni, jeśli agent porusza się jak osoba obudzona w nieznanym mieszkaniu.
Podpowiedź to zdanie, które do niej wypowiesz. Kontekst to świat, który wokół niego przygotowujesz.
Od szybkiej inżynierii po inżynierię kontekstową
Szybka inżynieria była często uważana za pisanie. Wybierz właściwe słowa, zapytaj we właściwy sposób, dodaj przykłady, określ format.
Inżynieria kontekstowa jest bliższa architekturze.
Nie pytasz po prostu: „Jak sformułować prośbę?”. Pyta:
- jakie informacje są naprawdę potrzebne?
- co to jest hałas?
- co trzeba odzyskać na bieżąco?
- o czym należy pamiętać?
- jakie narzędzia należy wyeksponować?
- które instrukcje są stabilne, a które zależne od zadania?
- jak sprawić, by agent zrozumiał, co jest autorytatywne?
To subtelna, ale ogromna zmiana. Ponieważ podczas pracy z agentami kontekst nie jest statycznym blokiem. Zmienia się na każdym kroku.
Agent otwiera plik, dowiaduje się czegoś, uruchamia test, otrzymuje błąd, aktualizuje plan, wywołuje narzędzie, odkrywa zależność. Na każdym okrążeniu musi decydować, co ze sobą zabrać, a co pominąć.
To jest inżynieria.
Kontekst to nie wysypisko śmieci
Szablony z dużymi oknami kontekstowymi dały nam pokusę: wrzućmy wszystko.
To zrozumiałe. Jeśli mam milion tokenów, dlaczego mam wybierać?
Bo nawet jeśli możesz włożyć wszystko, nie oznacza to, że wszystko pomaga. Rzeczywiście, hałas ma swoją cenę. Kosztuje tokeny, kosztuje uwagę, kosztuje opóźnienia, kosztuje jakość. Modelka może tak samo jak my zagubić się w nieistotnych szczegółach, gdy otworzymy dwadzieścia zakładek i nie będziemy już pamiętać dlaczego.
Dobry kontekst ma hierarchię:
- instrukcje i zasady systemu;
- cel szczegółowy;
- stan aktualny;
- odpowiednie dane;
- ograniczenia;
- dostępne narzędzia;
- śledzić już podjęte decyzje.
Nie ma potrzeby traktować wszystkiego na tym samym poziomie. Polecenie użytkownika jest warte więcej niż stara notatka. Nieudany test jest teraz wart więcej niż preferencja estetyczna sprzed trzech miesięcy. Polityka bezpieczeństwa jest warta więcej niż skrót produkcyjny.
Inżynieria kontekstu oznacza także nadawanie wag, a nie tylko danych.
Pamięć: pamiętaj mniej, pamiętaj lepiej
Pamięć u agentów to jeden z najbardziej śliskich tematów.
Jako użytkownik chcesz, aby agent Cię poznał. Chcesz, żeby zapamiętał ton, plan, konwencje i rzeczy już postanowione. Jako inżynier wiesz, że każda trwała pamięć to także ryzyko: może być błędna, stara, zbyt osobista, zbyt ogólna, niemożliwa do sprawdzenia.
Przydatna pamięć powinna mieć co najmniej trzy cechy:
- pochodzenie: skąd pochodzą te informacje?
- data: kiedy to było prawdą?
- cel: do jakiego rodzaju zadania ma być używany?
Bez tych trzech rzeczy pamięć staje się przesądem.
Lubię myśleć o pamięci agentycznej jak o zeszycie ćwiczeń, a nie o magicznym umyśle. Istnieją tymczasowe notatki, potwierdzone decyzje, preferencje stylistyczne, ograniczenia techniczne, linki do źródeł. Niektóre rzeczy wygasają. Niektóre trzeba napisać od nowa. Niektóre należy wyeliminować, ponieważ agent błędnie je wywnioskował.
Dobry system musi zapewniać normalną konserwację. Nie bohaterskie.
Odzyskiwanie i narzędzia to nie to samo
Kiedy mówimy o kontekście, często od razu trafiamy na RAG. Osadzanie, baza danych wektorowych, fragmentacja, reranking.
Wszystko przydatne. Jednak pobieranie to tylko jeden ze sposobów dostarczenia informacji do modelu. Nie jest jedyny.
Agent może uzyskać kontekst, czytając pliki, wysyłając zapytania do API, wywołując serwer MCP, otwierając przeglądarkę, uruchamiając testy, przeszukując Slack, patrząc na pulpit nawigacyjny, zadając pytanie człowiekowi.
Interesującą częścią jest podjęcie decyzji, której trasy użyć i kiedy.
Jeśli agent musi odpowiedzieć na pytanie historyczne, być może wystarczy samo odzyskanie informacji. Jeśli musi naprawić błąd, musi przeczytać prawdziwy kod. Jeśli chce zrozumieć przyczynę niepowodzenia wdrożenia, musi przejrzeć świeże dzienniki. Jeśli chcesz napisać do klienta, musisz uzyskać sygnał, historię i status zgłoszenia. Jeśli musi działać na produkcji, musi poprosić o pozwolenie.
Kontekst nie jest bazą danych. To przepływ pracy.
Dobry agent też wie, jak ignorować
Oznaką dojrzałości agenta będzie umiejętność powiedzenia: nie potrzebuję tej informacji.
Wydaje się to banalne, ale jest bardzo trudne. Kumuluje się wiele systemów agentowych. Każde wywołanie narzędzia dodaje tekst. Każdy błąd pozostaje w buforze. Każdy odczytany plik dodaje do stosu. W końcu model ma bardzo długą historię i nie ma mapy.
Potrzebna jest kompresja. Potrzebna jest synteza pośrednia. Trzeba to uporządkować.
Nie „to wszystko, co się wydarzyło”, ale:
- cel nadal aktualny;
- aktualna hipoteza;
- pliki już sprawdzone;
- podjęte decyzje;
- otwarte ryzyka;
- następna akcja.
Dzięki temu agent jest mniej teatralny i bardziej pomocny. Nie dlatego, że wydaje się mądrzejszy, ale dlatego, że pracuje przy czystym biurku.
Inżynieria kontekstowa dla zespołów, a nie dla szybkich artystów
Temat ten interesuje mnie dlatego, że przenosi on odpowiedzialność z jednostki na system.
W inżynierii szybkiej często wygrywa ten, kto najlepiej potrafi rozmawiać z modelem. W inżynierii kontekstowej wygrywa zespół, który najlepiej organizuje swoją pracę: dokumentacja, konwencje, problemy, logi, testy, własność, nazewnictwo, źródła.
Czyste repozytorium staje się lepszym kontekstem. Dobrze napisany numer staje się lepszym paliwem. Zaktualizowany element Runbook oszczędza tokeny i niepokoje. Przejrzysty dziennik zmian zmniejsza halucynacje.
To dobra i nieco niewygodna wiadomość. Piękne, bo nagradza dobre praktyki. Niewygodne, ponieważ nie da się rozwiązać wszystkiego sprytnym podpowiedzią.
Środki zwiększają higienę znalezionego systemu.
Jak zastosuję to jutro
Jeśli miałbym wprowadzić inżynierię kontekstową do prawdziwego projektu, zacząłbym od małych rzeczy:
- krótki i utrzymywany plik instrukcji projektu;
- dobre przykłady oczekiwanych wyników;
- listę dostępnych narzędzi i przypadków, w których można z nich skorzystać;
- decyzje architektoniczne zapisane w sposób umożliwiający cytowanie;
- problem z minimalnym obowiązkowym kontekstem;
- łatwe wyszukiwanie logów i testów;
- pamięć trwała, modyfikowalna przez człowieka.
Następnie zmierzyłbym prostą rzecz: ile razy agent musi prosić o wyjaśnienia lub podąża w złym kierunku?
Jeżeli zdarza się to często to nie dokładałbym od razu większego modelu. Spojrzałbym na kontekst.
Moja lektura
Tak, inżynieria kontekstu to trochę przesadzone słowo. Ale koncepcja jest słuszna.
Przypomina nam, że inteligencja agenta nie jest zawarta tylko w modelu. Leży w otoczeniu, które dla niego przygotowujemy: co widzi, co pamięta, co może zrobić, czego mu zabrania, jakie źródła uznaje za prawdziwe.
Ludzka część jest taka: dobre przygotowanie kontekstu jest formą troski. Mówi agentowi, ale także zespołowi: „Nie chcę, żebyś zgadywał, chcę, żebyś miał to, czego potrzebujesz”.
Mniej magii. Czystszy pokój. Agenci potrzebują tego tak samo jak my.