Toto je zdaleka nejjednodušší a nejbezpečnější nastavení k údržbě. Toto je součástí probíhající série: viz první příspěvek . zde tady AI Princip II: Load Prompts Safe (pokud opravdu musíte) Chtěli byste, aby váš chatbot začal diskutovat o textech Taylor Swift místo poskytování technické podpory?To je to, co náš chatbot udělal, když jsme porušili výše uvedený princip. Kde uložit Prompts Skladujete své výzvy se zbytkem kódu? nebo je načtete z jiného zdroje? Možná kombinace obojího? Opce A - Ukládání příležitostí v Gitu První otázka, kterou byste se měli zeptat, je: Existuje přímý důvod pro ukládání poptávek odděleně od vašeho kódu? Pokud ne, nechte poptávky v Gitu se zbytkem databáze kódů, kam patří. Vraťme se k principu #1: . Ukládání částí vaší kódové databáze mimo Git je možné a někdy nutné, ale ne triviální. Prompts are Code Prompts jsou Kód Opce B - Load Prompts z platformy řízené verzemi Co když některé z vašich poptávek potřebují být upravovány jinými než inženýry?To se může stát, pokud je zapotřebí hluboké odborné znalosti v dané oblasti.Nebo pokud poptávku je třeba velmi často měnit a nemůžete čekat na inženýrské oddělení. V tomto případě budete muset načíst poptávku v době spuštění z zdroje řízeného verzí.Viděl jsem, že se Confluence a Google Docs úspěšně používají pro tento účel.Mnoho dalších verzí řízených, API přístupných platforem je také k dispozici. Při plánování logiky rychlého načítání nepodceňujte množství úsilí při přidávání této integrace.Budete muset zvládnout celou řadu chybových podmínek a scénářů, abyste měli důvěru ve svou aplikaci.Přístupová oprávnění musí být nakonfigurována a udržována a automatické testování a dodatečné sledování by mělo být rozšířeno, aby se chyby zachytily co nejdříve. Zde jsou některé scénáře, pro které potřebujete plánovat: Aplikace není schopna načítat výzvy v době spuštění. Zabíjíte nasazení? Přepněte na záložní verzi výzvy? Prompt syntax se po změně stává neplatnou a vrací nepoužitelné datové struktury. Automatizované testy selhaly při zjišťování problému, protože výzvy nebyly během provádění testu načteny. Jaký druh dodatečné testovací infrastruktury a monitorování je třeba přidat, aby se to zjistilo a minimalizoval dopad na zákazníka? Prompt musí být naléhavě přeložen zpět. Vyžaduje to nové nasazení kódu? Nebo vytváříte samostatné UI pro nasazení výzvy? Aplikace není schopna načítat výzvy v době spuštění. Zabijete nasazení? Přepněte na záložní verzi výzvy? Syntax přidaný do dokumentu platformami, jako je Confluence, může infiltrovat poptávku po spuštění, což negativně ovlivňuje jeho výkon. Pouze výzvy, jejichž funkčnost výslovně napodobuje modely strojového učení (např. klasifikace nebo skóre), by měly být externě hodnoceny. Prompt syntax se po změně stává neplatnou a vrací nepoužitelné datové struktury. Automatizované testy neprokázaly problém, protože během testování nebyly vyzvánky načteny. Jaký druh dodatečné testovací infrastruktury a monitorování je třeba přidat, aby se to zjistilo a minimalizoval dopad zákazníka? Prompt musí být naléhavě přeložen zpět. Vyžaduje to nové nasazení kódu? Nebo vytváříte samostatné uživatelské rozhraní pro okamžité nasazení? Všechny tyto problémy jsou 100% vyřešitelné. Ale je snadné se dostat do vzorce myšlení, že načtení poptávky z Google Doc je triviální operace, která nebude mít hluboký vliv na architekturu aplikací.Jak jsem ukázal výše, načtení externího poptávky je vážný obchod, který je třeba přistupovat s péčí pro aplikace s vysokou spolehlivostí. Opce C - Load Prompts z Non-Version-Controled Platform Toto je špatný nápad, a budete litovat. zdroj pravdy pro výzvy musí být verze-kontrolované, mají správné API a kontroly přístupu. Opce D - Hybridní přístup Hybridní přístup kombinuje ukládání některých upozornění přímo ve vaší kódové databázi a načítání jiných z externích zdrojů řízených verzemi.Zatímco udržování jednotného umístění pro všechny upozornění je často jednodušší a spolehlivější, existují scénáře, kdy hybridní strategie může nabídnout výhody. Zvažte přijetí hybridního přístupu za podmínek, jako jsou: Méně kritické poptávky, zejména ty, které podléhají častým úpravám, mohou bezpečně žít vně. Buď je uložíte do Git s vaším kódem nebo použijte nástroj třetí strany, jako je například . Logika Guardrail se příliš často nemění, takže tento přístup vás tolik nezpomalí. Pouze výzvy, jejichž funkčnost výslovně napodobuje modely strojového učení (např. klasifikační nebo skóre úkoly), by měly být externě vyhodnoceny. : Některé výzvy vyžadují časté aktualizace od odborníků na nekódování domén, takže externí načítání je praktické, zatímco jiné jsou měněny pouze inženýry. Smíšené použití : Kritické výzvy (např. gardrails) by měly být umístěny v hlavním úložišti pro maximální spolehlivost. Méně kritické výzvy, zejména ty, které podléhají častým úpravám, mohou bezpečně žít externě. Řízení rizik : Výzvy určené pro hodnocení ve stylu ML mohou být spravovány externě, aby se zjednodušila jejich integrace Flexibilita hodnocení : Některé výzvy vyžadují časté aktualizace od odborníků na domény bez kódování, takže externí načítání je praktické, zatímco jiné jsou měněny pouze inženýry. Smíšené použití Smíšené použití : Kritické poptávky (např. gardrails) by měly být umístěny v hlavním úložišti pro maximální spolehlivost. Řízení rizik Řízení rizik : Prompty určené pro hodnocení ve stylu ML lze spravovat externě, aby se zjednodušila jejich integrace s rámcem pro hodnocení. Evaluace Flexibilita Flexibilita hodnocení Závěsná dráha Guardrail poptávky (také známé jako cenzorové poptávky) jsou specializovány na kontrolu reakcí předtím, než se dostanou k uživatelům, což zajišťuje vhodné, bezpečné a kompatibilní výstupy.Guardrail slouží jako ochranný mechanismus, zejména v aplikacích, kde uživatelské interakce nesou významná právní nebo etická rizika. Fiddle Guardrails Fiddle Guardrails Používání gardrails je zásada sama o sobě, která bude diskutována mnohem podrobněji v budoucím příspěvku.Je to skvělý vzor, který zlepšuje bezpečnost vaší aplikace a pomáhá vám lépe spát v noci. Loading Prompts pro snadnější hodnocení Teams často načtou výzvy externě, aby je integrovaly s vyhodnocovacími motory, jako je například . Základním předpokladem této praxe je, že výzvy jsou podobné ML modelům a vyžadují oddělené statistické hodnocení. Připojíte výzvu, změřte skóre F1 na výstupu (nebo jakékoli metrice, kterou preferujete) a iterujte. ML Flow Přesun ML Tento přístup je někdy platný – například na klasifikačních poptávkách navržených tak, aby se chovaly jako modely ML. Ale většina poptávek je zásadně odlišná: jak je popsáno v principu #1: . Typické poptávky jsou více podobné aplikační logice než modelům ML. Jsou vhodnější pro hodnocení typu Pass-Fail spolu s okolním kódem, spíše než pro statistický přístup k hodnocení. LLM Prompts Are Code LLM Prompts Are Code Externí vyhodnocovací motory vám nepomohou s většinou poptávek. Místo toho byste měli použít automatizované testy řízené AI, podobné tradičním testům jednotek. Zvažte následující postupy: Udržujte většinu výzvy obchodní logiky v hlavní kódové databázi, přičemž použijte tradiční automatizované testovací přístupy podobné testování jednotky namísto ověřovacích technik ML. Kde je externí hodnocení oprávněné, izolujte pouze ty výzvy, pokud je to možné. Udržujte většinu obchodních logických poptávek v hlavní kódové databázi, přičemž použijte tradiční automatizované testovací přístupy podobné jednotkovému testování spíše než techniky validace ML. Kde je externí hodnocení oprávněné, izolujte pouze ty výzvy, pokud je to možné. Případová studie Ústředním problémem s poptávkami na načítání je dostupnost - co byste měli udělat, pokud se poptávka neukládá, když to očekáváte. Toto je to, co se nám stalo v příkladu Taylor Swift. Žádný z poptávek pro aplikaci technické podpory nebyl načten v důsledku problému s pověřeními Confluence, včetně poptávky na zábradlí. To nějak nezpůsobil žádné chyby v době spuštění a bot začal reagovat bez jakýchkoliv pokynů nebo vstupů (protože vstupní formátovací řetězec byl součástí poptávky). A s čím chce OpenAI LLM mluvit v nepřítomnosti vstupu? Proč k tomuto incidentu došlo? udělali jsme dvě chyby: Žádné kontroly nebyly provedeny, zda byly výzvy úspěšně načteny. Měla by se vyskytnout chyba hodená v době načtení výzvy, protože aplikace nemohla fungovat bez načtení výzvy. Závěsné výzvy byly načteny externě se zbytkem výzvy. To je jeden výzva, která by neměla být načtena tímto způsobem. Mělo by být uchováno v Gitu jako poslední linie obrany. Nebylo provedeno žádné ověření, že se výzvy úspěšně načítaly.Mělo by dojít k chybě hodené v okamžiku rychlého načítání, protože aplikace nemohla fungovat bez načtení výzvy. Závěsný signál byl naložen externě se zbytkem signálů.To je jeden signál, který by neměl být naložen tímto způsobem.Měl by být uložen v Gitu jako poslední obranná linie. Po incidentu byl výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstražný výstup. Závěrečná zpráva V tomto příspěvku jsem zkoumal klíčové úvahy týkající se rychlého ukládání a načítání v rámci aplikací umělé inteligence. výchozí praxí je ukládat vaše výzvy vedle vašeho kódu v repozitářích řízených verzemi. Odchýlit se od tohoto pouze tehdy, když existuje přesvědčivý důvod, jako je časté editaci non-inženýrů nebo specifické požadavky na vyhodnocení. Pokud musí být výzvy načteny externě, zvolte spolehlivé a přísně verzi řízené zdroje a přidejte testování a monitorování pro odolnost.Guardrail výzvy, vzhledem k jejich kritické roli v bezpečnosti aplikací, by měly zůstat ve vaší kódové základně, aby se zabránilo vážným rizikům spolehlivosti. Většina poptávek je přirozeně blíže k kódu než k modelům ML, takže použijte nástroje pro styl ML pouze tam, kde je potřebujete.Neskladujte všechny své poptávky externě jen proto, abyste zjednodušili integraci s nástrojem pro vyhodnocení několika z nich. Pokud se vám tento příspěvek líbil, sledujte sérii pro více informací.
