Myslitelé

Agenti jsou vždy najímáni od prvního dne. Je čas, abychom to navrhli.

mm
Přidejte Unite.AI mezi své preferované zdroje na Google

Do roku 2027, 74 % firem se podle nedávné studie Deloitte očekává, že budou v nějaké míře používat agenty. Po léta jsme navrhovali a budovali software, který zlepšuje lidskou zkušenost při navigaci v našich aplikacích, webových stránkách, operačních systémech a dokumentech. Nyní už uživatel není vůbec člověk. To má širší důsledky než jen přechod od dashboardů a řízených pracovních toků, které vytváříme pro lidské úkoly. Nacházíme se v okamžiku, kdy musíme navrhovat provozní prostředí agentů, zatímco also navrhujeme lidské pracovní postupy, abychom v těchto prostředích efektivně řídili zkušenost agenta.

Stále jsme v počátcích našeho poznání toho, co agenti od nás skutečně potřebují, aby byli opakovatelně a spolehlivě úspěšní. Instinkt je považovat integraci agenta čistě za problém promptování nebo uživatelského rozhraní. Navrhovat dobře řízené vykonávací prostředí je pro nás jako kulturu nová oblast. Nicméně základní principy dobrého designu a dobrého řízení se nezměnily: dlužíme agentům jasný kontext, jednoznačný směr a explicitní záměr.

Kontext: Proč kódování přišlo jako první

Kontext je pravděpodobně nejdůležitějším vstupem, pokud chceme, aby agenti opakovaně dodávali na úrovni, kterou zamýšlíme. Vývoj softwaru má o něj zaznamenáno více než téměř jakékoli jiné pole: repozitáře, schémata API, vztahy mezi systémy, revize kódu a komunitní diskuze. Proto je logické, že laboratoře na špičce AI začaly s kódováním. Je to jedno z mála odvětví, kde je značná část kontextu již sepsána. 

Ale jak vám řekne jakýkoli nový člen vývojového týmu, i se všemi těmi daty agenti stále postrádají institucionální paměť zakotvenou v nepsaných pravidlech, která nikdo nikdy nezaznamenal. Tato mezera je rozšířená: 43 % vývojářů se obává, že nástroje AI postrádají dostatečný kontext o jejich konkrétním projektu nebo kódu. Tacitní znalosti zahrnují vše od každodenních konvencí, jako jsou preferované knihovny pro specifické úkoly, až po kritické operační duchy: noční oprava, která přetrvává navždy, nebo na první pohled prázdný sloupec v databázi, který tajně podporuje vlastní výkaz výnosů. Tento kontext žije v hlavě seniorního inženýra, v nedávném vlákně na Slacku nebo vůbec nikde. V kódu je jen zřídka.  

Pokud je to pravda v softwaru, jednom z nejlépe zdokumentovaných oborů, je snadné pochopit, proč agenti v mnoha dalších odvětvích bojují s efektivním výkonem od prvního dne. Ve zdravotnictví a právu je velká část institucionálního poznání, které formuje každodenní práci, získána a internalizována. Žije v zkušenostech lidí spíše než ve formální dokumentaci. Právní agent nemusí znát preferovanou strukturu, tón nebo argumentaci konkrétního partnera pro podání, zatímco zdravotnický agent nemusí rozumět místním pracovním tokům a eskalačním postupům, které zaneprázdněná klinika používá k podpoře triáže vedené klinickým lékařem. Pouhá dokumentace tuto mezeru nevyplní, protože výzvou není jen přístup k informacím; jde o přenos kontextu. Abychom agentům poskytli to, co potřebují k úspěchu, musíme je nasadit podobně jako nového zaměstnance.

Směr: Proč osmóza nefunguje

Zaškolení nového spoluhráče vyžaduje více než jen poskytnutí vhodných materiálů a přístupu. Když se zajímáme o úspěch lidí kolem nás, poskytujeme pevný směr ohledně toho, co s novými materiály a přístupem udělat: očekávání, jasnost toho, čeho se snažíme dosáhnout, a zpětnou vazbu během procesu. Tento samý přístup přenáším i na navrhování pro agenty. Dávám jasný, konkrétní směr (vztažený k aktuálnímu úkolu). To platí pro každého spoluhráče, bez ohledu na jeho dobu působení. Přesto v situaci nového najímání musí směr jít dál, protože ještě nemají žádný institucionální kontext.

Přemýšlejte o agentovi jako o novém najímání, které nikdy nepřestává být novým. Je dychtivý a schopný (a upřímně řečeno má nevyčerpatelnou energii), ale nedokáže nasbírat a udržet tolik nepsaných pravidel, kolik to člověk dokáže v průběhu času. Lidé se učí osmoticky a zkušenostmi, zatímco agenti se učí z architektury, která je explicitně zabudována do jejich pracovního prostředí.

U nového najímání můžete tuto mezeru postupně vyplnit pomocí otázek, zpětné vazby a nových poznatků, které získávají o procesech a preferencích organizace. Doslovné rozhovory u kávovaru nebo společné obědy. U agenta musíte vybudovat uzavírání této mezery přímo do návrhu. To může zahrnovat: 

  • Poskytnutí agentovi strukturovaného kontextového okna, které odděluje trvalá pravidla, úkolově specifické fakty a relevantní historii, místo aby mu byl nahodilý balík dokumentů.
  • Definování jeho oprávnění a rozhodovacích hranic předem: co může dělat samostatně, co vyžaduje schválení a co nesmí nikdy přistupovat.
  • Vložení několika konkrétních příkladů kvalitního výstupu přímo do prostředí, aby agent měl jasný model, jak má být práce vykonána.
  • Sdílení předchozích slepých uliček, na které jste narazili.

Navrhování dobře řízeného prostředí pro agenty nespočívá v usnadnění práce modelu. Jedná se o ochranu lidského inženýrského týmu před neviditelným technickým dluhem. Ale i dobře nasměrovaný agent může dokonale následovat instrukce a přesto nepochopit podstatu. Směr mu říká, co má dělat, ale neukazuje, jak vypadá „dobré“. Právě zde přichází na řadu záměr.

Záměr: Proč agenti sklouzávají k průměru

Je důležité si uvědomit, že agenti jsou stroje na shodu vzorů, trénované na obrovském množství znalostí a přirozeně nakloněné doručovat statistický průměr. Bez jasného, explicitního záměru je tento průměrný výstup přesně tím, co agent vrátí. Požádejte agenta, aby „přidal koncový bod uživatelské autentizace“, a vygeneruje učebnicovou Express trasu se základním hashováním hesel. Funguje, ale zcela ignoruje vlastní autentizační službu vašeho týmu, vynechává požadovanou telemetrii a rozbíjí vaše standardizované formátování chyb. Na papíře je to přijatelná funkce, ale v kontextu může být architektonickou chybou v praxi. Nelze přehánět, jak snadno jsou takové „chyby“ zaváděny.

Aby se tomu předešlo, směr musí být spojen s aktivním ověřováním záměru a protokolováním. Ochranné zábrany by neměly kontrolovat jen to, zda kód kompiluje, ač je to důležité. Musí výslovně vynucovat názorové standardy, pravidla pro okrajové případy a kontext domény, které pozvednou generický výstup na úroveň připravenou pro produkci. Pro nás lidi je logování indikátorem stavu systému. Tato sledovatelnost je zásadní pro důvěru. 

V lidských interakcích je spousta prostoru pro nejistotu. Někdo vám může předložit první verzi a společně můžete probrat, co je silné a co je třeba vylepšit. To funguje, protože nečekáme, že naši lidscí kolegové budou autonomní stroje. Abychom skutečně zachytili sílu a slib agenturních spolupracovníků (kteří musíme nechat pracovat autonomněji…), můžeme navrhnout mnoho těchto směrových kontrol. Zpětná vazba stále musí probíhat, ale nemůže být zcela na ruční úsilí. Předsunutím jasných kritérií přijetí a ověřovacích pravidel umožníte agentovi spouštět vlastní interní smyčky zpětné vazby. Designing for error prevention je další zvukový princip UX, který můžeme v tomto novém světě použít: dát agentům možnost označit nízkou důvěru před provedením akce, místo aby tiše předpokládali nejlepší odhad.

Kde metafora selhává

Rámec nového najímání funguje, dokud nefunguje. U lidského najímání zkušenost přináší kompetenci, která přináší úsudek. Sledujte, jak váš nový zaměstnanec internalizuje „proč“ za kontextem a směrem, a to buduje důvěru v průběhu času; obecně je to kumulativní. Agent nemá kde tuto zkušenost kumulovat a ukládat.

První týden a stovák nového zaměstnance vypadají odlišně. První úkol agenta a tisícátý vypadají identicky, pokud nenavrhnete a nevybudujete něco, co je odliší. To je naše nová výzva v designu.

Zodpovědnost agenta závisí na designu

Pokud nemůže odpovědnost žít v agentovi, musí žít v konstrukci kolem něj. Vše se točí kolem stejných tří otázek, které bych položil před předáním práce jakémukoli novému zaměstnanci: Jaký kontext má? Jaký směr jsem mu dal? Jaký je můj skutečný záměr?

Příště, když zadáte úkol agentovi, nezkontrolujte jen výstup. Nejprve zkontrolujte své vlastní vstupy. Dal jste mu kontext, který by nový zaměstnanec potřeboval od prvního dne? Byl váš směr dostatečně konkrétní, aby přežil doslovné interpretace? Byl váš záměr jasný natolik, že „průměrná odpověď“ nebyla nejlepší, jakou mohl udělat?

S tímto jasným vedením v ruce (v byte?), se stane něco zajímavého: agent nemusí mít dlouhou přistávací dráhu, aby se stal důvěryhodným. Kontext, směr a ověření, které vytvoříte dopředu, definují, jak bude operovat na každém úkolu. Nový zaměstnanec si získává vaši důvěru v průběhu času; agent ji musí získat pokaždé skrze systém, který jste navrhli. Odpovědnost není něco, do čeho roste, je vložena od samého začátku. Otázkou není, kdy bude váš agent připraven na větší odpovědnost. Je to, zda jste jej navrhli tak, aby si tuto odpovědnost zasloužil na každém jednotlivém úkolu.

Lauren Hanford je viceprezidentka pro produktové operace ve společnosti Sonar, globálním lídrovi v oblasti ověřování kódu AI a správy. Před Sonarem byla viceprezidentkou produktů ve společnosti Tidelift. Má zkušenosti v oblasti produktů, UX a vývoje. Svou jedinečnou kombinaci dovedností využívá k tomu, aby přistupovala k tvorbě technologií a organizací z uživatelsky orientovaného hlediska.