Vytváření pokročilých systémů rozšířené generace načítání

Předchozí článek se zabýval dvěma možnostmi vytvoření aplikace "chat přes data", jeden z premiérových případů použití pro generování umělé inteligence ve firmách:

• Načtení rozšířené generace (RAG), která doplňuje trénování modelu velkého jazyka (LLM) databází prohledávatelných článků, které lze načíst na základě podobnosti s dotazy uživatelů a předat LLM k dokončení.
• Vyladění, které rozšiřuje trénování LLM, aby lépe pochopili problémovou doménu.

V předchozím článku jsme se také zabývali, kdy použít jednotlivé přístupy, pro a con je každého přístupu a několik dalších aspektů.

Tento článek podrobněji zkoumá RAG, konkrétně veškerou práci potřebnou k vytvoření řešení připraveného pro produkční prostředí.

Předchozí článek znázorňuje kroky nebo fáze RAG pomocí následujícího diagramu.

Toto znázornění se označuje jako "naïve RAG" a je užitečným způsobem, jak porozumět mechanismům, rolím a zodpovědnostem potřebným k implementaci chatovacího systému založeného na rag.

Implementace v reálném světě má ale mnohem více kroků předběžného a následného zpracování pro přípravu článků, dotazů a odpovědí k použití. Následující diagram představuje realističtější znázornění RAG, někdy označovaného jako "advanced RAG".

Tento článek poskytuje koncepční rámec pro pochopení typů problémů před a po zpracování v chatovacím systému založeném na technologii RAG v reálném světě, který je uspořádaný takto:

• Fáze příjmu dat
• Fáze odvozování kanálu
• Fáze vyhodnocení

Jako koncepční přehled jsou klíčová slova a nápady poskytovány jako kontext a výchozí bod pro další zkoumání a výzkum.

Příjem dat

Příjem dat se primárně zabývá ukládáním dokumentů vaší organizace takovým způsobem, aby je bylo možné snadno načíst, aby odpovídaly na otázku uživatele. Výzvou je zajistit, aby se části dokumentů, které nejlépe odpovídají dotazu uživatele, nacházely a využívaly během odvozování. Porovnávání se dosahuje především vektorizovanými vkládáními a hledáním kosinusové podobnosti. Usnadňuje se ale pochopením povahy obsahu (vzorů, formulářů atd.) a strategie organizace dat (struktura dat při uložení v databázi vektorů).

Za tímto účelem musí vývojáři zvážit následující:

• Předběžné zpracování a extrakce obsahu
• Strategie vytváření bloků dat
• Uspořádání bloků dat
• Strategie aktualizace

Předběžné zpracování a extrakce obsahu

Čistý a přesný obsah je jedním z nejlepších způsobů, jak zlepšit celkovou kvalitu chatovacího systému založeného na RAG. Aby toho dosáhli, musí vývojáři začít analýzou tvaru a formy dokumentů, které se mají indexovat. Odpovídají dokumenty zadaným vzorům obsahu, jako je dokumentace? Pokud ne, na jaké typy otázek můžou dokumenty odpovědět?

Vývojáři by měli minimálně vytvořit kroky v kanálu příjmu dat, aby:

• Standardizace textových formátů
• Zpracování speciálních znaků
• Odebrání nesouvisejícího, zastaralého obsahu
• Účet pro obsah s verzí
• Účet pro prostředí obsahu (karty, obrázky, tabulky)
• Extrakce metadat

Některé z těchto informací (například metadata) můžou být užitečné uchovávat s dokumentem v vektorové databázi pro použití během procesu načítání a vyhodnocení v kanálu odvozování nebo v kombinaci s textovým blokem, aby přesvědčila vložení vektoru bloku.

Strategie vytváření bloků dat

Vývojáři se musí rozhodnout, jak rozdělit delší dokument na menší bloky dat. To může zlepšit relevanci doplňkového obsahu odeslaného do LLM za účelem přesné odpovědi na dotaz uživatele. Vývojáři navíc musí zvážit, jak při načítání využívat bloky dat. Jedná se o oblast, ve které by návrháři systémů měli provádět průzkum technik používaných v oboru a provádět experimentování, a to i v omezené kapacitě ve své organizaci.

Vývojáři musí zvážit:

• Optimalizace velikosti bloků dat – Určete, jaká je ideální velikost bloku dat a jak určit blok dat. Podle oddílu? Podle odstavce? Podle věty?
• Překrývající se a posuvné bloky oken – Určete, jak rozdělit obsah na samostatné bloky dat. Nebo se bloky překrývají? Nebo obojí (posuvné okno)?
• Small2Big – Při vytváření bloků na podrobné úrovni, jako je jedna věta, bude obsah uspořádaný tak, aby bylo snadné najít sousední věty nebo obsahující odstavec? (Viz "Organizace bloků dat".) Načtení těchto dalších informací a jeho poskytnutí do LLM může poskytnout další kontext při odpovídání na dotaz uživatele.

Uspořádání bloků dat

V systému RAG je organizace dat v vektorové databázi zásadní pro efektivní načítání relevantních informací pro rozšíření procesu generování. Tady jsou typy strategií indexování a načítání, které můžou vývojáři zvážit:

• Hierarchické indexy – Tento přístup zahrnuje vytvoření několika vrstev indexů, kdy index nejvyšší úrovně (souhrnný index) rychle zúží vyhledávací prostor na podmnožinu potenciálně relevantních bloků dat a index druhé úrovně (index bloků dat) poskytuje podrobnější ukazatele na skutečná data. Tato metoda může výrazně urychlit proces načítání, protože snižuje počet položek, které se mají prohledat v podrobném indexu filtrováním souhrnného indexu.
• Specializované indexy – Specializované indexy , jako jsou grafové nebo relační databáze, se dají použít v závislosti na povaze dat a vztazích mezi bloky dat. Například:
  • Indexy založené na grafech jsou užitečné, když bloky obsahují vzájemně propojené informace nebo vztahy, které můžou zlepšit načítání, jako jsou citační sítě nebo grafy znalostí.
  • Relační databáze můžou být efektivní, pokud jsou bloky dat strukturované v tabulkovém formátu, kde je možné použít dotazy SQL k filtrování a načítání dat na základě konkrétních atributů nebo relací.
• Hybridní indexy – Hybridní přístup kombinuje několik strategií indexování, které využívají silné stránky každého z nich. Vývojáři mohou například použít hierarchický index pro počáteční filtrování a index založený na grafu k dynamickému zkoumání vztahů mezi bloky dat během načítání.

Optimalizace zarovnání

Pokud chcete zvýšit význam a přesnost načtených bloků dat, může být užitečné je lépe sladit s typy otázek nebo dotazů, na které mají odpovědět. Jednou ze strategií, jak toho dosáhnout, je vygenerovat a vložit hypotetickou otázku pro každý blok dat, který představuje otázku, na kterou je blok bloků dat nejvhodnější pro odpověď. To pomáhá několika způsoby:

• Vylepšené porovnávání: Během načítání může systém porovnat příchozí dotaz s těmito hypotetickými otázkami a najít tak nejlepší shodu, což zlepšuje relevanci načtených bloků dat.
• Trénovací data pro modely strojového učení: Tyto párování otázek a bloků dat mohou sloužit jako trénovací data, aby se zlepšily modely strojového učení, které jsou základem systému RAG, a pomáhají tak zjistit, na jaké typy otázek jsou nejlépe zodpovězené, na které bloky dat.
• Přímé zpracování dotazů: Pokud skutečný uživatelský dotaz úzce odpovídá hypotetické otázce, může systém rychle načíst a použít odpovídající blok dat a zrychlit dobu odezvy.

Hypotetická otázka každého bloku funguje jako druh "popisku", který vede algoritmus načítání, aby byl více zaměřený a kontextově vědomý. To je užitečné ve scénářích, kdy bloky dat pokrývají širokou škálu témat nebo typů informací.

Aktualizace strategií

Pokud vaše organizace potřebuje indexovat dokumenty, které se často aktualizují, je nezbytné udržovat aktualizovaný korpus, aby se zajistilo, že komponenta retrieveru (logika v systému zodpovědná za provádění dotazu na vektorovou databázi a vrácení výsledků) bude mít přístup k nejaktuálnějším informacím. Tady jsou některé strategie aktualizace vektorové databáze v takových systémech:

• Přírůstkové aktualizace:
  • Pravidelné intervaly: Naplánujte aktualizace v pravidelných intervalech (například denně, týdně) v závislosti na četnosti změn dokumentu. Tato metoda zajišťuje pravidelné aktualizace databáze.
  • Aktualizace založené na triggerech: Implementujte systém, ve kterém aktualizace aktivují opětovné indexování. Jakékoli úpravy nebo přidání dokumentu by například mohly automaticky zahájit přeindexování ovlivněných oddílů.
• Částečné aktualizace:
  • Selektivní opětovné indexování: Místo opětovného indexování celé databáze selektivně aktualizujte pouze části korpusu, které se změnily. To může být efektivnější než úplné opětovné indexování, zejména u velkých datových sad.
  • Rozdílové kódování: Ukládejte pouze rozdíly mezi existujícími dokumenty a jejich aktualizovanými verzemi. Tento přístup snižuje zatížení zpracování dat tím, že se vyhne nutnosti zpracovávat nezměněná data.
• Správa verzí:
  • Vytváření snímků: Udržujte verze korpusu dokumentu v různých časových bodech. Systém tak může v případě potřeby vrátit zpět předchozí verze nebo odkazovat na předchozí verze a poskytuje mechanismus zálohování.
  • Správa verzí dokumentu: K systémovému sledování změn v dokumentech používejte systém správy verzí. To pomáhá udržovat historii změn a zjednodušit proces aktualizace.
• Aktualizace v reálném čase:
  • Zpracování datových proudů: Využijte technologie zpracování datových proudů k aktualizaci vektorové databáze v reálném čase při změnách v dokumentech. To může být důležité pro aplikace, kde je nejdůležitější aktuálnostinformacích
  • Živé dotazování: Místo toho, abyste se museli spoléhat výhradně na předem indexované vektory, implementujte mechanismus pro dotazování na živá data pro nejaktuálnější odpovědi, což by mohlo být možné zkombinovat s výsledky uloženými v mezipaměti za účelem efektivity.
• Techniky optimalizace:
  • Dávkové zpracování: Shromážděte změny a zpracovávat je v dávkách, abyste optimalizovali používání prostředků a snížili režii způsobenou častými aktualizacemi.
  • Hybridní přístupy: Kombinování různých strategií, jako je použití přírůstkových aktualizací pro menší změny a úplné opětovné indexování hlavních aktualizací nebo strukturálních změn v souboru dokumentu.

Volba správné strategie aktualizace nebo kombinace strategií závisí na konkrétních požadavcích, jako je velikost korpusu dokumentu, frekvence aktualizací, potřeba dat v reálném čase a dostupnost zdrojů. Každý přístup má své kompromisy z hlediska složitosti, nákladů a latence aktualizací, takže je nezbytné tyto faktory vyhodnotit na základě konkrétních potřeb aplikace.

Kanál odvozování

Teď, když jsou články blokované, vektorizované a uložené v vektorové databázi, se fokus zaměřuje na výzvy při dokončení.

• Je dotaz uživatele napsaný takovým způsobem, aby získal výsledky ze systému, který uživatel hledá?
• Porušuje dotaz uživatele některou z našich zásad?
• Jak přepíšeme dotaz uživatele, abychom zlepšili jeho šance na nalezení nejbližších shod v vektorové databázi?
• Jak vyhodnocujeme výsledky dotazu, abychom zajistili, že bloky článků odpovídají dotazu?
• Jak vyhodnotíme a upravíme výsledky dotazu před jejich předáním do LLM, aby se zajistilo, že do dokončení LLM zahrneme nejdůležitější podrobnosti?
• Jak vyhodnotíme odpověď LLM, abychom zajistili, že dokončení LLM odpovídá původnímu dotazu uživatele?
• Jak zajistíme, aby reakce LLM odpovídala našim zásadám?

Jak vidíte, existuje mnoho úloh, které musí vývojáři vzít v úvahu, většinou ve formě:

• Předzpracování vstupů pro optimalizaci pravděpodobnosti získání požadovaných výsledků
• Výstupy následného zpracování pro zajištění požadovaných výsledků

Mějte na paměti, že celý kanál odvozování běží v reálném čase. I když neexistuje žádný správný způsob návrhu logiky, která provádí kroky předběžného a následného zpracování, je pravděpodobné, že se jedná o kombinaci programovací logiky a dalších volání LLM. Jednou z nejdůležitějších aspektů je pak kompromis mezi vytvořením nejpřesnějšího a vyhovujícího kanálu a náklady a latencí, které je potřeba k tomu, aby k tomu došlo.

Pojďme se podívat na jednotlivé fáze a identifikovat konkrétní strategie.

Kroky předběžného zpracování dotazu

Předběžné zpracování dotazu proběhne okamžitě po odeslání dotazu uživatelem, jak je znázorněno v tomto diagramu:

Cílem těchto kroků je zajistit, aby uživatel položil otázky v rámci našeho systému (a nepokouší se "jailbreak" systému, aby udělal něco nezamýšleného) a připravit dotaz uživatele na zvýšení pravděpodobnosti, že vyhledá nejlepší možné bloky článků pomocí kosinus podobnosti / "nejbližší soused" vyhledávání.

Kontrola zásad – Tento krok může zahrnovat logiku, která identifikuje, odebere, označí nebo odmítne určitý obsah. Mezi příklady patří odebrání identifikovatelných osobních údajů, odebrání expletiv a identifikace pokusů o jailbreak. Jailbreaking označuje metody, které mohou uživatelé použít k obcházení nebo manipulaci s integrovanými bezpečnostními, etickými nebo provozními pokyny modelu.

Opětovné psaní dotazů – může to být cokoli, od rozšíření zkratek a odebrání slangu, aby se otázka přepsala tak, aby se položil abstraktivněji, aby extrahovali koncepty a principy vysoké úrovně ("krok-back prompting").

Varianta výzvy k vrácení zpět je hypotetické vkládání dokumentů (HyDE), které používá LLM k zodpovězení otázky uživatele, vytvoří vložení pro tuto odpověď (hypotetické vložení dokumentu) a použije toto vkládání k provedení vyhledávání ve vektorové databázi.

Poddotazy

Tento krok zpracování se týká původního dotazu. Pokud je původní dotaz dlouhý a složitý, může být užitečné ho programově rozdělit na několik menších dotazů a zkombinovat všechny odpovědi.

Představte si například otázku týkající se vědeckých objevů, zejména v oblasti fyziky. Dotaz uživatele může být: "Kdo udělal významnější příspěvky do moderní fyziky, Albert Einstein nebo Niels Bohr?"

Tento dotaz může být složitý pro zpracování přímo, protože "významné příspěvky" můžou být subjektivní a vícestranné. Rozdělením do poddotazů se dá lépe spravovat:

1. Poddotaz 1: "Jaké jsou klíčové příspěvky Alberta Einsteina na moderní fyziku?"
2. Poddotaz 2: "Jaké jsou klíčové příspěvky Niels Bohr do moderní fyziky?"

Výsledky těchto poddotazů by podrobně popisovaly hlavní teorie a objevy každého fyzika. Příklad:

• Příspěvky mohou zahrnovat teorii relativity, fotoelektrický efekt a E=mc^2.
• Příspěvky bohru můžou zahrnovat jeho model atomu vodíku, jeho práci na kvantové mechanikě a jeho princip doplňkovosti.

Jakmile jsou tyto příspěvky popsány, můžete je posoudit a určit:

3. Poddotaz 3: "Jak mají teorie Einsteina vliv na vývoj moderní fyziky?"
4. Poddotaz 4: "Jak bohrovy teorie ovlivnily vývoj moderní fyziky?"

Tyto poddotazy by prozkoumaly vliv práce každého vědce na dané oblasti, jako je například to, jak teorie Einsteina vedly k pokroku v kosmologii a kvantové teorii a o tom, jak Bohrova práce přispěla k pochopení atomické struktury a kvantové mechaniky.

Kombinace výsledků těchto poddotazů může pomoci jazykovému modelu vytvořit komplexnější odpověď týkající se toho, kdo výrazněji přispěl k moderní fyzikě na základě rozsahu a dopadu jejich teoretického pokroku. Tato metoda zjednodušuje původní složitý dotaz tím, že pracuje s konkrétnějšími, srozumitelnějšími komponentami a následnou syntetizací těchto zjištění do koherentní odpovědi.

Směrovač dotazů

Je možné, že se vaše organizace rozhodne rozdělit obsah do více vektorových úložišť nebo celých systémů načítání. V takovém případě můžou vývojáři použít směrovač dotazů, což je mechanismus, který inteligentně určuje, které indexy nebo moduly načítání se mají použít na základě zadaného dotazu. Primární funkcí směrovače dotazů je optimalizace načítání informací výběrem nejvhodnější databáze nebo indexu, která může poskytnout nejlepší odpovědi na konkrétní dotaz.

Směrovač dotazů obvykle funguje v určitém okamžiku po vytvoření dotazu uživatelem, ale před odesláním do všech systémů načítání. Tady je zjednodušený pracovní postup:

1. Analýza dotazů: LLM nebo jiná komponenta analyzuje příchozí dotaz, aby porozuměl jeho obsahu, kontextu a typu informací, které jsou pravděpodobně potřeba.
2. Výběr indexu: Na základě analýzy směrovač dotazů vybere jeden nebo více z potenciálně několika dostupných indexů. Každý index může být optimalizovaný pro různé typy dat nebo dotazů – například některé můžou být vhodnější pro faktické dotazy, zatímco jiné můžou excelovat v poskytování názorů nebo subjektivního obsahu.
3. Odeslání dotazu: Dotaz se pak odešle do vybraného indexu.
4. Agregace výsledků: Odpovědi z vybraných indexů se načítají a dají se agregovat nebo dále zpracovat tak, aby vytvořily komplexní odpověď.
5. Generování odpovědí: Poslední krok zahrnuje generování koherentní odpovědi na základě načtených informací, případně integrace nebo syntetizace obsahu z více zdrojů.

Vaše organizace může pro následující případy použití použít více modulů pro načítání nebo indexů:

• Specializace datových typů: Některé indexy se mohou specializovat na články o zprávách, jiné v akademických dokumentech a další v obecném webovém obsahu nebo konkrétních databázích, jako jsou ty, které se týkají lékařských nebo právních informací.
• Optimalizace typu dotazu: Některé indexy můžou být optimalizované pro rychlé faktické vyhledávání (například data, události), zatímco jiné můžou být lepší kvůli složitým úlohám nebo dotazům vyžadujícím hluboké znalosti domény.
• Algoritmické rozdíly: Různé algoritmy načítání se můžou používat v různých modulech, jako jsou hledání podobnosti založené na vektorech, tradiční vyhledávání založená na klíčových slovech nebo pokročilejší sémantické principy modelů.

Představte si systém založený na RAG, který se používá v kontextu lékařského poradenství. Systém má přístup k více indexům:

• Index lékařského výzkumu optimalizovaný pro podrobné a technické vysvětlení.
• Index klinické případové studie, který poskytuje příklady příznaků a léčby z reálného světa.
• Obecný index informací o stavu pro základní dotazy a informace o veřejném stavu

Pokud se uživatel zeptá technické otázky týkající se biochemických účinků nového léku, může směrovač dotazů určit prioritu indexu lékařského výzkumného papíru kvůli jeho hloubkové a technické zaměření. Pro otázku o typických příznaky běžné nemoci, nicméně obecný zdravotní index může být zvolen pro jeho široký a snadno pochopitelný obsah.

Kroky následného zpracování

Zpracování po načtení probíhá po načtení komponenty retrieveru, která načte relevantní bloky obsahu z vektorové databáze, jak je znázorněno v diagramu:

Při načtení bloků obsahu kandidáta je dalším postupem ověření, že bloky článků budou užitečné při rozšiřování výzvy LLM a pak začnou připravovat výzvu k zobrazení LLM.

Vývojáři musí zvážit několik aspektů výzvy. Výzva, která obsahuje příliš mnoho doplňujících informací a některé (pravděpodobně nejdůležitější informace) by mohly být ignorovány. Podobně může výzva, která obsahuje irelevantní informace, neoprávněně ovlivnit odpověď.

Dalším aspektem je jehla v problému se sena , termín, který odkazuje na známou váze některých LLM, kde obsah na začátku a konci výzvy mají větší váhu pro LLM než obsah uprostřed.

Nakonec je potřeba zvážit maximální délku kontextového okna LLM a počet tokenů potřebných k dokončení mimořádně dlouhých výzev (zejména při práci s dotazy ve velkém měřítku).

Při řešení těchto problémů může kanál následného načítání zahrnovat následující kroky:

• Výsledky filtrování – V tomto kroku vývojáři zajistí, aby bloky článků vrácené vektorovou databází byly pro dotaz relevantní. Pokud ne, výsledek se při vytváření výzvy k LLM ignoruje.
• Opětovné hodnocení – Seřazení bloků článků načtených z úložiště vektorů za účelem zajištění toho, aby se relevantní podrobnosti zachytály poblíž okrajů (začátek a konec) výzvy.
• Komprese výzvy – Použití malého levného modelu navrženého ke kombinování a shrnutí několika bloků článků do jediné komprimované výzvy před odesláním do LLM.

Kroky zpracování po dokončení

Zpracování po dokončení probíhá po odeslání dotazu uživatele a všech bloků obsahu do LLM, jak je znázorněno v následujícím diagramu:

Jakmile LLM výzvu dokončí, je čas ověřit dokončení, aby se zajistilo, že je odpověď přesná. Kanál zpracování po dokončení může zahrnovat následující kroky:

• Kontrola faktů – Může to mít mnoho forem, ale záměrem je identifikovat konkrétní deklarace identity provedené v článku, které jsou prezentovány jako fakta, a pak zkontrolovat přesnost těchto faktů. Pokud se krok kontroly faktů nezdaří, může být vhodné znovu zadat dotaz na LLM v naději na lepší odpověď nebo vrátit uživateli chybovou zprávu.
• Kontrola zásad – toto je poslední obranná linie, která zajistí, že odpovědi neobsahují škodlivý obsah, ať už pro uživatele nebo organizaci.

Hodnocení

Vyhodnocení výsledků ne deterministického systému není tak jednoduché, jako jsou testy jednotek nebo integrace, které znáte většina vývojářů. Je potřeba vzít v úvahu několik faktorů:

• Jsou uživatelé spokojení s výsledky, které dostává?
• Získávají uživatelé přesné odpovědi na své otázky?
• Jak zaznamenáváme zpětnou vazbu uživatelů? Máme nějaké zásady, které omezují, jaká data můžeme shromažďovat o uživatelských datech?
• Pro diagnostiku nespokojených odpovědí máme přehled o všech pracích, které se dostaly do odpovědi na otázku? Uchováváme protokol každé fáze v kanálu odvozování vstupů a výstupů, abychom mohli provádět analýzu původní příčiny?
• Jak můžeme v systému provádět změny bez regrese nebo snížení výsledků?

Zachycení zpětné vazby uživatelů a jejich reakce

Jak už bylo zmíněno dříve, vývojáři možná budou muset spolupracovat s týmem organizace na ochranu osobních údajů, aby navrhli mechanismy zachycení zpětné vazby a telemetrii, protokolování atd. pro povolení forenzních a původních příčin analýzy v dané relaci dotazů.

Dalším krokem je vývoj kanálu posouzení. Potřeba kanálu posouzení vychází ze složitosti a časově náročné povahy analýzy doslovné zpětné vazby a původních příčin odpovědí poskytovaných systémem AI. Tato analýza je zásadní, protože zahrnuje zkoumání každé odpovědi, aby bylo možné pochopit, jak dotaz AI vytvořil výsledky, zkontrolovat vhodnost bloků obsahu použitých z dokumentace a strategie použité při dělení těchto dokumentů.

Kromě toho zahrnuje zvážení jakýchkoli dalších kroků předběžného nebo následného zpracování, které by mohly zlepšit výsledky. Toto podrobné zkoumání často odhalí mezery v obsahu, zejména pokud v reakci na dotaz uživatele neexistuje vhodná dokumentace.

Vytvoření kanálu hodnocení je proto nezbytné ke efektivní správě škálování těchto úloh. Efektivní kanál by využil vlastní nástroje k vyhodnocení metrik, které odpovídají kvalitě odpovědí poskytovaných AI. Tento systém by zjednodušil proces určení, proč byla konkrétní odpověď udělena na otázku uživatele, které dokumenty byly použity k vygenerování této odpovědi, a efektivitu kanálu odvozování, který zpracovává dotazy.

Zlatá datová sada

Jednou ze strategií pro vyhodnocení výsledků ne deterministického systému, jako je například chatovací systém RAG, je implementace "zlaté datové sady". Zlatá datová sada je kurátorovaná sada otázek se schválenými odpověďmi, metadaty (jako je téma a typ otázky), odkazy na zdrojové dokumenty, které můžou sloužit jako základní pravda pro odpovědi, a dokonce i varianty (různé formulace pro zachycení rozmanitosti způsobu, jakým se uživatelé mohou ptát na stejné otázky).

"Zlatá datová sada" představuje "nejlepší scénář" a umožňuje vývojářům vyhodnotit systém, aby viděli, jak dobře funguje, a provádět regresní testy při implementaci nových funkcí nebo aktualizací.

Posouzení škod

Modelování škod je metodologie zaměřená na předvídání potenciálních škod, zjišťování nedostatků v produktu, které mohou představovat rizika jednotlivcům, a vývoj proaktivních strategií pro zmírnění těchto rizik.

Nástroj navržený pro posouzení dopadu technologií, zejména systémů AI, by na základě principů modelování škod na základě zásad modelování škod, jak je uvedeno v poskytnutých zdrojích, by měly obsahovat několik klíčových součástí.

Mezi klíčové funkce nástroje pro vyhodnocení škod může patřit:

1. Identifikace zúčastněných stran: Nástroj by uživatelům pomohl identifikovat a kategorizovat různé zúčastněné strany ovlivněné technologií, včetně přímých uživatelů, nepřímo ovlivněných stran a dalších subjektů, jako jsou budoucí generace nebo nelidé faktory, jako jsou otázky životního prostředí (např.

2. Kategorie a popisy škod: Zahrnoval by komplexní seznam potenciálních škod, jako je ztráta soukromí, emocionální tíseň nebo ekonomické zneužití. Nástroj by mohl uživatele vést různými scénáři, které ilustrují, jak může technologie způsobit tyto škody, což pomáhá vyhodnotit zamýšlené i nezamýšlené důsledky.

3. Posouzení závažnosti a pravděpodobnosti: Nástroj by uživatelům umožnil posoudit závažnost a pravděpodobnost každé zjištěné škody, což jim umožní určit prioritu problémů, které se mají řešit jako první. To může zahrnovat kvalitativní posouzení a mohou být podporovány daty, pokud jsou k dispozici.

4. Strategie zmírnění rizik: Při identifikaci a vyhodnocení škod by nástroj navrhl potenciální strategie zmírnění rizik. To může zahrnovat změny návrhu systému, větší záruky nebo alternativní technologická řešení, která minimalizují zjištěná rizika.

5. Mechanismy zpětné vazby: Nástroj by měl zahrnovat mechanismy pro shromažďování zpětné vazby od zúčastněných stran a zajistit, aby proces vyhodnocování škod byl dynamický a reagoval na nové informace a perspektivy.

6. Dokumentace a hlášení: Nástroj by usnadnil vytvoření podrobných zpráv, které dokumentují proces posuzování škod, zjištění a opatření, která se provádějí ke zmírnění potenciálních rizik.

Tyto funkce by nejen pomohly identifikovat a zmírnit rizika, ale také pomoci při navrhování etičtějších a odpovědných systémů AI tím, že od počátku zvažují široké spektrum dopadů.

Další informace naleznete v tématu:

• Základy posuzování škod
• Typy škod

Testování a ověření bezpečnostních opatření

Tento článek popisuje několik procesů zaměřených na zmírnění možnosti, že chatovací systém založený na rag může být zneužit nebo ohrožen. Red-teaming hraje zásadní roli při zajištění účinnosti zmírnění rizik. Red-teaming zahrnuje simulaci akcí nežádoucích uživatelů zaměřených na aplikaci, aby odhalila potenciální slabá místa nebo ohrožení zabezpečení. Tento přístup je zvláště důležitý při řešení významného rizika jailbreaku.

Aby mohli vývojáři efektivně testovat a ověřovat záruky chatovacího systému založeného na rag, musí tyto systémy pečlivě posoudit v různých scénářích, kde by se tyto pokyny mohly testovat. To nejen zajišťuje odolnost, ale také pomáhá vyladit reakce systému na dodržování přísně definovaných etických norem a provozních postupů.

Konečné aspekty, které můžou ovlivnit rozhodnutí o návrhu aplikace

Tady je krátký seznam věcí, které je potřeba vzít v úvahu, a další poznatky z tohoto článku, které ovlivňují rozhodnutí o návrhu vaší aplikace:

• Berete na vědomí ne deterministický charakter generování umělé inteligence ve vašem návrhu, plánování proměnlivosti ve výstupech a nastavení mechanismů pro zajištění konzistence a relevance v odpovědích.
• Vyhodnoťte výhody předzpracování výzvy uživatelů proti potenciálnímu zvýšení latence a nákladů. Zjednodušení nebo úprava výzev před odesláním může zlepšit kvalitu odezvy, ale může zvýšit složitost a dobu odezvy.
• Prozkoumejte strategie paralelizace požadavků LLM za účelem zvýšení výkonu. Tento přístup může snížit latenci, ale vyžaduje pečlivou správu, aby se zabránilo zvýšené složitosti a potenciálním nákladům.

Pokud chcete začít experimentovat s vytvářením řešení generující umělé inteligence okamžitě, doporučujeme se podívat na začínáme s chatem pomocí vlastní ukázky dat pro Python. K dispozici jsou také verze tohoto kurzu v .NET, Javě a JavaScriptu.