Kontextové inženýrství: práce před výzvou
· 6 min read · Filippo Spinella · AI, Agents, Prompting, Developer Tools
Slovo okamžiku v malém světě agentů AI je kontextové inženýrství.
Zdá se, že další značka byla vynalezena, aby prodávala něco, co jsme již udělali. Částečně ano. Jak se však často stává, etiketa se chytne, protože dává jméno skutečné bolesti.
Bolest je tato: modelky neselžou jen proto, že „nemyslí“. Často selhávají, protože je posíláme do práce se špatnou místností.
Dáváme jim staré pokyny. Skrýváme před ním důležité soubory. Předáváme jim dokumenty, které jsou příliš dlouhé a neříkají, na čem záleží. Zobrazujeme jim protokoly bez priority. Dáváme jim deset nástrojů, aniž bychom jim vysvětlili, kdy je použít. Pak jsme překvapeni, když se agent pohybuje jako člověk probuzený v neznámém bytě.
Výzva je fráze, kterou jí řeknete. Kontext je svět, který kolem něj připravujete.
Od rychlého inženýrství po kontextové inženýrství
Pohotové inženýrství bylo často chápáno jako psaní. Vyberte správná slova, ptejte se správným způsobem, přidejte příklady, určete formát.
Kontextové inženýrství má blíže k architektuře.
Neptáte se jen „jak mám formulovat žádost?“. Ptá se:
- jaké informace jsou skutečně potřeba?
- co je hluk?
- co je třeba obnovit za běhu?
- co je třeba pamatovat?
- které nástroje by měly být vystaveny?
- které instrukce jsou stabilní a které závisí na úloze?
- jak přimět agenta, aby pochopil, co je směrodatné?
Je to jemná, ale obrovská změna. Protože když pracujete s agenty, kontext není statický blok. Mění se na každém kroku.
Agent otevře soubor, něco se naučí, spustí test, přijme chybu, aktualizuje plán, zavolá nástroj, objeví závislost. S každým kolem se musí rozhodnout, co si vzít s sebou a co vynechat.
To je strojírenství.
Kontext není skládka
Šablony s velkými kontextovými okny nám daly pokušení: pojďme všechno hodit dovnitř.
Je to pochopitelné. Když mám milion tokenů, proč bych si měl vybírat?
Protože i když do toho můžete dát všechno, neznamená to, že všechno pomáhá. Hluk skutečně něco stojí. Stojí to tokeny, stojí to pozornost, stojí to latence, stojí to kvalita. Model se může ztratit v nepodstatných detailech stejně jako my, když otevřeme dvacet záložek a už si nepamatujeme proč.
Dobrý kontext má hierarchii:
- systémové pokyny a zásady;
- specifický cíl;
- aktuální stav;
- relevantní údaje;
- omezení;
- dostupné nástroje;
- sledovat již učiněná rozhodnutí.
Není potřeba zacházet se vším na stejné úrovni. Uživatelský příkaz má větší cenu než stará poznámka. Neúspěšný test má nyní větší hodnotu než jen estetická preference z doby před třemi měsíci. Bezpečnostní politika má větší cenu než produkční zkratka.
Kontextové inženýrství také znamená dávat váhy, nejen data.
Paměť: pamatujte si méně, pamatujte si lépe
Paměť v agentech je jedním z nejkluzčích témat.
Jako uživatel chcete, aby vás agent znal. Chcete, aby si pamatoval tón, plán, konvence, věci, o kterých už bylo rozhodnuto. Jako inženýr víte, že každá trvalá paměť je také rizikem: může být chybná, stará, příliš osobní, příliš obecná, neověřitelná.
Užitečná paměť by měla mít alespoň tři vlastnosti:
- provenience: odkud tyto informace pocházejí?
- datum: kdy to byla pravda?
- účel: pro jaký typ úkolu by měl být použit?
Bez těchto tří věcí se paměť stává pověrou.
Rád přemýšlím o agentní paměti jako o pracovním sešitu, ne jako o magické mysli. Jsou zde dočasné poznámky, potvrzená rozhodnutí, preference stylu, technická omezení, odkazy na zdroje. Některé věci vyprší. Některé je třeba přepsat. Některé musí být odstraněny, protože je agent špatně odvodil.
Dobrý systém musí tuto údržbu zajistit běžnou. Ne hrdinské.
Vyhledávání a nástroje nejsou totéž
Když mluvíme o kontextu, často okamžitě skončíme na RAG. Vkládání, vektorová databáze, chunking, reranking.
Vše užitečné. Vyhledání je ale jen jeden způsob, jak do modelu přinést informace. Není jediný.
Agent může získat kontext čtením souborů, dotazem na API, voláním serveru MCP, otevřením prohlížeče, spuštěním testů, prohledáním Slacku, pohledem na řídicí panel, dotazem na člověka.
Zajímavou částí je rozhodování, jakou trasu použít a kdy.
Pokud agent potřebuje odpovědět na historickou otázku, stačí snad jen vyhledání. Pokud má opravit chybu, musí přečíst skutečný kód. Pokud potřebuje pochopit, proč se nasazení nezdaří, musí se podívat na čerstvé protokoly. Pokud potřebujete napsat zákazníkovi, musíte získat tón, historii a stav lístku. Pokud musí jednat o produkci, musí požádat o povolení.
Kontext není databáze. Je to pracovní postup.
Dobrý agent také ví, jak ignorovat
Známkou vyspělosti u agentů bude schopnost říci: Tyto informace nepotřebuji.
Zdá se to triviální, ale je to velmi obtížné. Akumuluje se mnoho agentních systémů. Každé volání nástroje přidává text. Každá chyba zůstává ve vyrovnávací paměti. Každý přečtený soubor se přidá do zásobníku. Nakonec má model velmi dlouhou historii a žádnou mapu.
Je potřeba komprese. Je nutná střední syntéza. Je potřeba to strukturovat.
Ne "to je vše, co se stalo", ale:
- cíl stále platný;
- současná hypotéza;
- soubory již zkontrolovány;
- učiněná rozhodnutí;
- otevřená rizika;
- další akce.
Tím je agent méně teatrální a užitečnější. Ne proto, že by se zdál chytřejší, ale proto, že pracuje s uklizeným stolem.
Kontextové inženýrství pro týmy, ne pro pohotové umělce
Důvod, proč mě toto téma zajímá, je ten, že přesouvá odpovědnost z jednotlivce na systém.
V pohotovém inženýrství často vyhrává ten, kdo umí s modelem nejlépe mluvit. V kontextovém inženýrství vítězí tým, který nejlépe organizuje svou práci: dokumentace, konvence, problémy, protokoly, testy, vlastnictví, pojmenování, zdroje.
Čisté úložiště se stává lepším kontextem. Dobře napsaný problém se stává lepším palivem. Aktualizovaný runbook šetří tokeny a úzkost. Přehledný seznam změn snižuje halucinace.
To je dobrá a poněkud nepříjemná zpráva. Krásné, protože odměňuje dobré postupy. Nepohodlné, protože vše nevyřešíte chytrou výzvou.
Agenti zesilují hygienu systému, který najdou.
Jak bych to použil zítra
Pokud bych měl zavést kontextové inženýrství do skutečného projektu, začal bych od malých věcí:
- krátký a udržovaný soubor s instrukcemi projektu;
- dobré příklady očekávaného výstupu;
- seznam dostupných nástrojů a případů, ve kterých je lze použít;
- architektonická rozhodnutí psaná citovatelným způsobem;
- problém s minimálním povinným kontextem;
- snadné načítání protokolů a testů;
- perzistentní paměť modifikovatelná lidmi.
Pak bych změřil jednoduchou věc: kolikrát musí agent žádat o vysvětlení nebo se vydá špatným směrem?
Pokud se to stává často, nepřidával bych hned větší model. Podíval bych se na kontext.
Moje čtení
Kontextové inženýrství je trochu nabubřelé slovo, to ano. Ale koncept je dobrý.
Připomíná nám to, že inteligence agenta není jen v modelu. Spočívá v prostředí, které mu připravujeme: co vidí, co si pamatuje, co může, co má zakázáno, které zdroje uznává za pravdivé.
Lidská část je taková: dobře připravit kontext je formou péče. Říká agentovi, ale také týmu: "Nechci, abyste hádali, chci, abyste měli, co potřebujete."
Méně magie. Čistší místnost. Agenti to potřebují stejně jako my.