Jak neztratit kontext: projektová paměť pro dlouhé práce s AI
Vestavěná paměť chatu pomáhá, ale při dlouhých projektech nestačí. Repo, handoff, rozhodovací log a pravidelné audity vytvoří systém, který přežije změnu konverzace i modelu.
Je vestavěná paměť důvěryhodným základem?
Co když model zapomne rozhodnutí, které platilo ještě včera? Diskutující si stěžovali na výpadky paměti, změny chování modelů a situace, kdy model přestal respektovat vlastní instrukce. Jeden z nich proto kombinuje vestavěnou paměť, předchozí konverzace, legacy paměť a Markdown soubory načtené na začátku nového chatu.
Vestavěná paměť ušetří čas, ale není spolehlivým zdrojem pravdy. Uživatel nepozná, co model právě zapomněl. Změna verze, naplnění kontextového okna nebo přechod na jiný model proto mohou tiše změnit výsledek.
Důležité dohody musí existovat i mimo konverzaci. Jinak se ztratí při prvním výpadku. Řešení není jeden univerzální prompt, ale soubor pravidel, která platí bez ohledu na aktuální chat. Projekty v ChatGPT pak slouží jako pracovní plocha, nikoli jako jediné úložiště informací.
Repo jako centrum projektu
Centrální repozitář funguje jako „uzel“ pro každý projekt i klienta. Obsahuje instrukce, stav projektu a odkazy na další zdroje informací. Pod ním mohou existovat samostatné repozitáře pro vývoj, data nebo analýzu.
Praktické uspořádání vypadá takto:
- hlavní repozitář s pravidly a aktuálním stavem,
- samostatné repozitáře pro jednotlivé typy práce,
- krátké stavové soubory průběžně doplňované během konverzace,
- sdílené výzkumy a studie oddělené od projektových zjištění.
Taková struktura usnadňuje orientaci. Repozitáře na GitHubu navíc nabízejí verzování: vidíte, kdy a proč se stav změnil.
Jenže uložený soubor sám o sobě nestačí. Model musí dostat správné soubory do kontextu. Soubor, který model nečte, se neliší od chybějícího. Úložiště tedy musí propojit s instrukcí, jaké dokumenty načíst a kdy je aktualizovat.
Handoff jako zápis pro další chat
Když se kontextové okno zaplní, osvědčil se postup, kdy model připraví handoff a pokračuje v novém úkolu. Několik diskutujících používá také průběžné zápisy do externího souboru, které shrnují dokončenou část práce.
Handoff má odpovědět na čtyři otázky:
- Co je cílem projektu?
- Co už bylo rozhodnuto a proč?
- Které kroky jsou hotové, co chybí a co je rozpracované?
- Které soubory a zdroje je potřeba otevřít před pokračováním?
Samotné shrnutí nestačí. Bez zdůvodnění rozhodnutí může nový chat navrhnout alternativu, která už byla jednou odmítnuta. Codex lze instruovat, aby handoff vytvořil v předem daném formátu a aby na něj v novém běhu navázal.
Šablona instrukce pro AI:
Před vyprázdněním kontextového okna vytvoř handoff projektu.
Zahrň: [cíl projektu], [dokončená práce], [rozhodnutí a jejich důvody], [otevřené otázky], [další kroky] a [soubory ke čtení].
Zachov přesné názvy, příkazy, omezení a nerozřešené podrobnosti.
Zapiš handoff do [soubor pro handoff] a pokračuj úkolem [další úkol].
Rozhodovací log v databázi
Jeden z diskutujících vede rozhodovací log v Supabase. Codex má v instrukcích určeno, co do logu zapisovat a jak starší záznamy dohledávat. Tento systém podle něj funguje několik měsíců a pomáhá také při návratu k projektu po týdnech.
Log ale nemusí zaznamenávat jen rozhodnutí. Užitečnější je evidovat i alternativy, důvod volby, důsledky a stav otevřených bodů. Struktura může vypadat takto:
- ID a datum rozhodnutí,
- oblast projektu,
- přijaté rozhodnutí,
- zdůvodnění,
- zamítnuté varianty,
- podmínky revize,
- odkaz na navazující úkol nebo soubor.
Databáze umožňuje dotazy napříč více projekty. Pro menší projekty může stačit Markdown v repozitáři. V obou případech zachovejte stejnou taxonomii a způsob zápisu. Jinak se log po několika měsících změní v další hromadu textu.
Audit odhaluje opomenuté body
Pravidelný audit zachycuje to, co průběžná práce nechala stranou. V diskuzi se objevují dva rytmy: ruční přenos stavu v pravidelných intervalech nebo průběžné zápisy po větších úsecích a audit otevřených otázek podle nastaveného tempa.
Audit nemusí znovu projít celou konverzaci. Větší smysl má pracovat s uloženým stavem a odpovědět na otázky:
- Které dohody nemají konkrétní výsledek?
- Které úkoly zůstaly nedokončené nebo čekají na odpověď?
- Kde se informace liší mezi repozitářem, logem a chatem?
- Které předpoklady je nutné ověřit před dalším krokem?
Rozdělte výstup auditu na uzavřené body, otevřené otázky a další kroky. Uzavřený bod bez odkazu na výsledek zůstává v diskuzi jen vzpomínkou.
Pět kroků pro kontinuitu
Pro práci s ChatGPT a Codexem stačí pět opakovatelných kroků:
- Jeden kořen kontextu: pravidla, cíl, definice pojmů a omezení v jednom souboru.
- Stav projektu: hotové kroky, otevřené body a odkazy na artefakty.
- Log rozhodnutí: rozhodnutí s důvodem a podmínkami revize.
- Handoff: povinný formát při přenosu do nového chatu.
- Periodický audit: kontrola otevřených bodů a nesouladů mezi zdroji.
Zvolte systém, který dokážete dlouhodobě udržovat. Slack může sloužit jako rozhraní pro upozornění na nové záznamy, ale samotné oznámení nestačí. Bez pravidelného auditu ztratí log a stavové soubory důvěryhodnost.
Co udělat prakticky
Používejte vestavěnou paměť jako doplněk, ne jako jediné úložiště kontextu. Zapište mimo chat důležité dohody i jejich důvody. Při zaplnění kontextu vytvořte handoff ve stabilním formátu a pokračujte v novém úkolu.
Rozhodovací log udržujte strukturovaný a pro jednotlivé projekty odděleně. Pravidelný audit otevřených otázek odhalí nesoulady dřív, než se promění v chybnou práci. Celý systém musí být jednoduchý natolik, aby se udržel dlouhodobě.