Kontextové knihovny pro AI agenty: čtyři lekce z výzkumu NN/g

Při práci s AI agentem nebývá nejtěžší vymyslet jeden dokonalý prompt. V terénním výzkumu Nielsen Norman Group (NN/g) věnovali zkušení uživatelé Claude více úsilí budování a údržbě kontextových knihoven než samotnému promptování. Často přitom zadání jen nadiktovali běžným jazykem a spoléhali na to, že potřebná pravidla, znalosti a historie už v systému jsou.

To funguje jen do chvíle, než se kontext rozroste, zastará nebo začne prosakovat mezi projekty. Článek NN/g proto není návodem na jednu správnou strukturu. Je spíš souborem varování z praxe: kontext je potřeba udržovat, umět dohledat a načítat jen tam, kde opravdu patří.

Co je kontextová knihovna

NN/g tímto pojmem označuje institucionální nebo procesní znalosti uložené například v Markdownu či v externích službách, které může agent číst a někdy také upravovat. Autoři rozlišují tři role kontextu:

Globální kontext platí napříč úkoly. Patří sem například preference uživatele, obecná pravidla komunikace nebo firemní zásady.
Lokální kontext se vztahuje k určitému projektu, složce či konkrétní práci.
Ambientní kontext tvoří průběžně vznikající materiál: přepisy schůzek, e-maily, dokumenty nebo data z napojených služeb, v nichž agent hledá relevantní informace.

Rozdělení je důležité hlavně kvůli rozsahu. Pravidlo určené jednomu projektu může v globální vrstvě nechtěně ovlivnit úplně jinou práci. Naopak důležitá globální zásada uložená hluboko v jedné složce se k agentovi při jiném úkolu vůbec nemusí dostat.

1. Jednou napsaný kontext postupně stárne

Účastníci studie podle NN/g často vytvořili kontextový soubor jednorázově a později jej už nekontrolovali. Mezitím se změnily pracovní postupy, názvy souborů, priority i externí integrace. Automatizace pak dál vycházela z instrukcí, které už neodpovídaly skutečnosti.

Autoři doporučují požádat agenta, aby globální a lokální kontext porovnal s novějšími ambientními zdroji, například s posledními zápisy ze schůzek. Taková kontrola ale nemá být automatickým souhlasem se všemi změnami. Agent může odhalit rozpor, konečné rozhodnutí o tom, která informace platí, musí udělat člověk.

Pro praktický provoz z toho plyne jednoduché pravidlo: u důležitých souborů má být zřejmé, kdo je vlastní, kdy byly naposledy ověřeny a podle jakého zdroje se mají aktualizovat. U napojení na externí systémy je navíc potřeba hlídat, zda se nezměnila oprávnění, cesta k datům nebo samotné API.

2. Agent může knihovnu spravovat, změny je ale nutné kontrolovat

Téměř nikdo ze sledovaných uživatelů neupravoval kontextové soubory ručně. O změnu požádali Claude, někdy i velmi širokým příkazem pro celou knihovnu. Podle NN/g pak často nezkontrolovali, co přesně agent přepsal.

To šetří čas, ale zároveň umožňuje nenápadně měnit pravidla budoucího chování. U vývojářského týmu proto dává smysl ukládat důležité instrukce do verzovacího systému a změny posuzovat stejně jako úpravy kódu: zobrazit diff, ověřit důvod a teprve potom je přijmout. Ve studii přitom účastníci používali lokální soubory a zálohy na Google Drive; GitHub sice někteří zvažovali, ale nikdo jej pro svou knihovnu nepoužíval.

3. Problém není jen obsah, ale i dohledatelnost

Jeden z účastníků měl přes 2 700 kontextových souborů. Jiný při společném procházení objevil globální soubor s pravidly řízení, o kterém nevěděl. Pokud se v knihovně nevyzná její vlastník, těžko může posoudit, proč se agent chová určitým způsobem.

Užitečným vzorem z výzkumu byly malé indexové soubory CLAUDE.md v jednotlivých složkách. Neobsahovaly všechna pravidla, ale stručně vysvětlovaly, co je uvnitř a kdy má agent sáhnout po podrobnějších materiálech. Takový rozcestník snižuje potřebu načítat vše předem a zároveň pomáhá člověku pochopit strukturu knihovny.

Pro malý projekt může stačit jeden přehled. Ve větší knihovně se vyplatí indexovat každou hlavní oblast, pojmenovat vlastníka a uvést vazby na související soubory. Samotné množství dokumentů totiž není zárukou, že agent najde správný dokument ve správný okamžik.

4. Více kontextu neznamená automaticky lepší výsledek

Nejpropracovanější knihovna ve studii se snažila načíst vždy co nejméně informací. Její majitel používal pravidlo „nejdřív nahoru nebo dolů, teprve potom do strany“: agent měl hledat v aktuální složce, jejích rodičích a podřízených složkách, ne rovnou v sousedních projektech.

Důvodem nebyla jen úspora tokenů. NN/g popisuje i prosakování kontextu. Pokyny pro vizuální styl podcastu se například promítly do aplikace na evidenci knih. V jiném případě agent kvůli směsi zdrojů zaměnil uživatele za jeho obchodního partnera. Široký přístup tak může přidat informace, které jsou samy o sobě správné, ale pro daný úkol nepatří do hry.

Většina souborů sledovaných uživatelů měla nejvýše několik stovek řádků. Autoři ale nestanovují žádný magický limit. Podstatnější je jasný účel, vymezený rozsah a popis toho, kdy se soubor nemá použít.

Jak bych knihovnu nastavil v praxi

Pro první verzi není potřeba složitý systém. Začal bych několika kroky:

Rozdělit pravidla na globální a projektová a ambientní data nechat jako samostatné zdroje.
Do každé důležité složky přidat krátký index s popisem obsahu a hranic použití.
Kritické instrukce verzovat a změny navržené agentem vždy projít v diffu.
Pravidelně hledat zastaralé odkazy, nefunkční integrace a rozpory s novějšími dokumenty.
Při chybné odpovědi kontrolovat nejen prompt, ale také to, jaký kontext agent skutečně načetl.

Výzkum NN/g má omezený rozsah. Navazující studie sledovala sedm netechnických, ale velmi zkušených uživatelů Claude, převážně z prostředí designu, produktového vývoje a digitálních služeb. Jde o kvalitativní pozorování neobvyklé skupiny, ne o benchmark ani důkaz, že určitá struktura zlepší výkon každému týmu.

Přesto jsou popsané problémy prakticky užitečné. Kontextová knihovna není pasivní archiv. Je to součást chování agenta, a proto potřebuje vlastníka, dohledatelné změny a jasné hranice stejně jako jiná důležitá konfigurace systému.