RAG nebo fine tuning je volba založená na tom, co má váš asistent dělat. RAG, zkratka pro retrieval-augmented generation, poskytuje při odpovídání modelu relevantní zdrojový materiál. Fine tuning znamená další trénování modelu na příkladech. Začněte testem jasného zadání úkolu neboli promptu. Podle výsledku pak rozhodněte, zda před objednáním další práce prozkoumáte chybějící zdrojový materiál, nekonzistentní výstup, nebo obojí.
Jeden dodavatel navrhuje natrénovat AI systém pro vaši firmu, zatímco jiný navrhuje prohledávatelnou znalostní bázi. Tyto popisy neurčují úkol, který musí hotový systém plnit, ani to, co se bude považovat za neúspěšný výsledek. My začínáme písemným zadáním. Až nabídky dorazí, poskytne vám konkrétní základ pro jejich porovnání.
Co mění RAG nebo fine tuning?
RAG mění materiál dodaný pro odpověď. Fine tuning mění model pomocí tréninku. Průvodce přesností od OpenAI rozlišuje mezi nedostatkem kontextu a nekonzistentním chováním. Pro kupujícího je to užitečné počáteční rozlišení, pokud ponechá prostor pro překrývající se potřeby. Asistent pracující s dokumenty může zároveň potřebovat konzistentní způsob formulování odpovědi.
Podle vysvětlení znalostních bází Amazon Bedrock vyhledávání vybírá relevantní materiál a zahrnuje ho do vstupu pro generování. U navrhovaného asistenta, který odpovídá na otázky o pravidlech vracení zboží, si nechte ukázat, která schválená pasáž odpověď podporuje. Odkaz na zdroj je přesto nutné porovnat s tím, co odpověď uvádí.
Fine tuning používá příklady k dalšímu trénování modelu v tom, jak má odpovídat. Průvodce OpenAI jej popisuje jako možnost zlepšení chování při určitém úkolu. Představte si požadovaný záznam pro předání s dohodnutou strukturou: dodavatel potřebuje příklady přijatelných záznamů a vstupy, z nichž vycházejí. Jde o jinou dodávku než složku dokumentů s firemními pravidly.
Ani jeden název vám neřekne, zda ukázka splňuje vaše požadavky. Požádejte dodavatele, aby určil, co navrhovaná součást mění, ukázal používaný materiál a vysvětlil, jak výsledek ověříte. Diskusi držte u skutečné práce, kterou kupujete.
Začněte úkolem a jednodušší ukázkou
Než zvolíte přístup, popište vstup a přijatelný výstup. Průvodce tvorbou promptů od Anthropicu začíná jasnými kritérii úspěchu, testem s příklady a návrhem promptu. Toto pořadí používáme při přípravě zadání pro nákup: napište instrukci, dodejte schválený materiál a prověřte, co dokáže nejjednodušší navrhované řešení. Jde o námi navrhovanou metodu hodnocení, nikoli o zveřejněný srovnávací test.
U ilustrativního asistenta pro vracení zboží by vstupem mohla být otázka zákazníka a příslušná pravidla. Přijatelný návrh odpoví pouze na to, co pravidla podporují, a výjimky předá člověku. U ilustrativního předání prodeje by vstupem mohla být poptávka a schválený formát záznamu. Výstup by měl zachovat význam poptávky a chybějící údaje nechat nevyplněné.
Nechte vlastníka procesu sepsat, co činí každý výstup přijatelným. Zahrňte požadavek, který by měl asistent odmítnout nebo předat člověku. Používejte materiál, který smíte sdílet, a odstraňte nepotřebné osobní údaje. Ukázka závislá na informacích, které nemůžete poskytnout, zatím není proveditelným návrhem.
Pokud již máte asistenta, který podává nespolehlivé odpovědi, použijte před rozhodnutím o objednávce samostatného průvodce ověřením příčin nesprávných odpovědí AI.
Další test zvolte podle zbývajícího nedostatku
Podle pozorovaného selhání zvolte, co otestujete dál. AWS doporučuje začít vyhledáváním u otázek, které odkazují na vlastní dokumenty, a upozorňuje na obtížnost udržování tréninku v souladu s často měněným materiálem. Připouští také společné použití vyhledávání a fine tuningu. Následující tabulka navrhuje další test pro nedostatek zjištěný v ukázce.
| Co ukázce stále chybí | Co otestovat dále |
|---|---|
| Informace ze schválených a měnících se dokumentů | Vyhledávání, které dodá relevantní aktuální materiál |
| Opakovatelný výstup, který zůstává nekonzistentní i po jasnějších instrukcích a příkladech | Trénink na přijatých příkladech, pokud ho zvolený model podporuje |
| Zdrojový materiál a konzistentnější odpověď | Kombinované řešení s kontrolou každého požadavku |
Pokud jednodušší ukázka již požadavky splňuje, ponechte tuto možnost v porovnání. Ptejte se, jaký další problém by navrhovaný trénink nebo vyhledávací systém vyřešil. Volba může také zůstat otevřená, zatímco připravujete chybějící vstupy.
AWS upozorňuje, že fine tuning není dostupný pro každý model. Požádejte dodavatele, aby jmenoval poskytovatele a model, vysvětlil, kde a jak bude systém fungovat, a potvrdil aktuální podporu navrhovaného tréninku a nasazení.
Kdo bude systém po spuštění udržovat?
Porovnejte povinnosti, které jednotlivé návrhy ponechávají vašemu týmu. Pro vyhledávání určete osobu, která schvaluje zdrojové dokumenty a kontroluje, zda se jejich aktualizace dostanou k asistentovi. Pro trénink určete, kdo připravuje přijaté příklady a kontroluje pozdější změny. Zaznamenejte, kdo uděluje přístup, kdo řeší selhání a jak pracovníci vrátí úkol do ručního procesu, když systém není vhodný.
Tyto otázky zařazujeme do plánování implementace AI před výběrem součástí. Užitečné zadání zaznamenává:
- Úkol, povolené vstupy a očekávaný výstup.
- Autoritativní zdroje, jejich vlastníka a proces aktualizace.
- Příklady přijatelné práce a nepřijatelných vynechání nebo doplnění.
- Podmínky odmítnutí požadavku nebo jeho předání člověku.
- Přejímací kontroly, hodnotitele a materiál, který má být předán.
U práce zahrnující aktivní objednávku nebo záznam kontaktu se ptejte, jak navrhovaný systém získá povolený aktuální záznam. Tento požadavek zahrňte do části zadání o integraci CRM. Návrh na trénování s exportovanými záznamy stále potřebuje vysvětlení, jak se budou řešit pozdější změny.
Ptejte se, kde budou uloženy dokumenty, prohledávatelné kopie, příklady a výstupy, kdo k nim může přistupovat a jak se řeší odstranění. Odpovědi zaznamenejte pro skutečné nasazení. Název žádné z architektur nepovažujte za rozhodnutí o hostingu nebo oprávněních.
Ověřte návrh na dosud neviděných požadavcích
Testovací požadavky nezahrnujte do materiálu použitého ke konfiguraci nebo trénování navrhovaného systému. Požádejte každého dodavatele, aby tyto požadavky zpracoval podle stejných přejímacích kritérií. Vlastník procesu by měl zkontrolovat výstupy, vstupy použité k jejich vytvoření a potřebné opravy. Tím ověříte návrh na svém úkolu. Neprokazuje to výkon u každého budoucího požadavku.
- Uchovejte výchozí stav. Uložte výsledky ručního procesu a jednoduššího promptu spolu s jejich vstupy a poznámkami z kontroly.
- Ověřte aktualizaci zdroje. Změňte schválený testovací dokument a zopakujte dotčenou otázku. Požádejte dodavatele, aby ukázal použitou verzi a způsob, jakým se aktualizace dostala do systému.
- Ověřte pravidla výstupu. Přeformulujte požadavek a některé informace vynechte. Zkontrolujte, zda záznam zachovává požadovanou strukturu, aniž by si vymýšlel podrobnosti.
- Otestujte přístup a rozsah. Vyzkoušejte požadavek mimo dohodnutý rozsah a uživatele, který by neměl obdržet dokument s omezeným přístupem. Zkontrolujte skutečné odmítnutí nebo předání.
- Zaznamenejte práci, kterou váš tým musí nadále vykonávat. Poznamenejte si opravy, čas na kontrolu a osobu odpovědnou za údržbu materiálů. Před rozšířením práce je porovnejte s výchozím stavem.
Když kontrola selže, zaznamenejte nesplněný požadavek a vyžádejte si upravenou ukázku. Neplaťte za složitější přístup jen proto, že jeho název zní schopněji. Přijměte rozsah, který můžete ověřit, nebo ponechte úkol lidem, dokud nebudou vyřešeny chybějící podmínky.
Jak pomáháme
Začínáme společným sepsáním úkolu, povolených dat a přejímacích kontrol. Poté porovnáme navrhované přístupy s tímto zadáním a zdokumentujeme, kdo bude udržovat zdroje, příklady a hodnocení. Užitečným prvním krokem je napsat skutečný požadavek a schválit příklad výsledku, který potřebujete.
