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 představuje užitečný způsob, jak nejprve 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í kroky:

• 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í, aby se použily 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, zarovnejte je přesně s dotazem nebo typy 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 "popisek", 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 informačních témat nebo typů.

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 aktivačních událostech: Implementujte systém, kde aktualizace aktivují přeindexová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í: Namísto přeindexování celé databáze selektivně aktualizujte pouze změněné části korpusu. Tento přístup může být efektivnější než úplné přeindexová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 bodech v čase. Tato technika poskytuje mechanismus zálohování a umožňuje systému vrátit se zpět nebo odkazovat na předchozí verze.
  • Správa verzí dokumentu: Pomocí systému správy verzí můžete systematicky sledovat změny dokumentu pro udržování historie změn a zjednodušení procesu aktualizace.
• Aktualizace v reálném čase:
  • Zpracování datových proudů: Když je aktuálnost informací důležitá, využijte technologie zpracování datových proudů k aktualizacím vektorové databáze v reálném čase při změnách dokumentu.
  • Živé dotazování: Místo toho, abyste se museli spoléhat výhradně na předindexované vektory, implementujte mechanismus živého dotazu na data pro aktuální odpovědi, které by mohly být kombinovány s výsledky uloženými v mezipaměti za účelem efektivity.
• Techniky optimalizace:

  • Dávkové zpracování: Dávkové zpracování kumulovaných změn pro optimalizaci prostředků a snížení režijních nákladů místo častých aktualizací.

  • Hybridní přístupy: Kombinování různých strategií, například:

    • Použití přírůstkových aktualizací pro menší změny
    • Úplné přeindexování hlavních aktualizací
    • Zdokumentovat strukturální změny korpusu.

Volba správné strategie aktualizace nebo kombinace závisí na konkrétních požadavcích, jako jsou:

• Velikost korpusu dokumentu.

• Frekvence aktualizace

• Potřebuje data v reálném čase.

• Dostupnost prostředků.

• Tyto faktory vyhodnoťte na základě konkrétních potřeb aplikace, protože každý přístup má kompromisy mezi složitostí, náklady a latencí aktualizací.

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 k 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 vyhodnocujeme 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ředběžné zpracová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ů

Celý kanál odvozování běží v reálném čase. I když neexistuje žádný správný způsob návrhu kroků před a po zpracování, je to pravděpodobně kombinace 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 identifikovat konkrétní strategie v jednotlivých fázích.

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

Předzpracování dotazů 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, aby zvýšil pravděpodobnost, že vyhledá nejlepší možné bloky článků pomocí kosinus podobnosti / "nejbližší soused" vyhledávání.

Kontrola zásad – Tento krok zahrnuje logiku, která identifikuje, odebere, označí nebo odmítne určitý obsah. Mezi příklady patří odebrání osobních údajů, odebrání expletivních pokusů 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ů – tento krok může být cokoli od rozšíření zkratek a odebrání slangu, aby se otázka přepsala, aby se položil abstraktivněji, aby extrahovali koncepty a principy vysoké úrovně ("krok zpět výzvy").

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.

Například otázka týkající se vědeckých objevů ve fyzikě může být: "Kdo učinil významné příspěvky do moderní fyziky, Alberta Einsteina nebo Niels Bohru?"

Rozdělení složitých dotazů na poddotazy umožňuje jejich správu:

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 prozkoumávají vliv jednotlivých vědců na fyziku, například:

• Jak teorie Einsteina vedly k pokroku v kosmologii a kvantové teorii
• 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ěď, pokud jde o to, kdo výrazněji přispěl k moderní fyzikě na základě 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 okamžiku, kdy uživatel formuluje dotaz, ale před odesláním do 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:

Když jsou načtené bloky obsahu kandidáta, dalším postupem je ověřit užitečnost bloku článku při rozšiřování výzvy LLM před přípravou výzvy k zobrazení llm.

Vývojáři musí zvážit několik aspektů výzvy:

• Zahrnutí příliš mnoho doplňujících informací může vést k ignorování nejdůležitějších informací.
• irelevantní informace by mohly negativně 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 – před odesláním do LLM můžete komprimovat a sumarizovat několik bloků článků do jediné komprimované výzvy.

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:

K ověření přesnosti dochází po dokončení výzvy llm. Kanál zpracování po dokončení může zahrnovat následující kroky:

• Kontrola faktů – 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 dotazovat LLM v naději na lepší odpověď nebo vrátit uživateli chybovou zprávu.
• Kontrola zásad – poslední obranná linie, která zajistí, že odpovědi neobsahují škodlivý obsah, ať už pro uživatele nebo organizaci.

Hodnocení

Vyhodnocení výsledků nedeterministického systému není tak jednoduché jako 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ů nedeterministického systému, jako je systém RAG-chat, 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 nelidské 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í. Mezi příklady patří kvalitativní posouzení podporovaná daty, pokud jsou k dispozici.

4. Strategie zmírnění rizik: Nástroj navrhuje potenciální strategie zmírnění rizik po identifikaci a vyhodnocení škod. Mezi příklady patří změny návrhu systému, vyšší 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 vytváření sestav: Pro transparentnost a odpovědnost může nástroj usnadnit podrobné zprávy, které dokumentují proces posuzování škod, zjištění a potenciální opatření ke zmírnění rizik.

Tyto funkce by nejen pomohly identifikovat a zmírnit rizika, ale také pomoci při navrhování eičtějších a zodpově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.

Vývojáři musí pečlivě posoudit ochranu chatovacího systému založeného na rag v různých obecných scénářích, aby je mohli efektivně testovat a ověřovat. 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.