Předpoklad: Shromáždění požadavků

Definování jasných a komplexních požadavků na případ použití je důležitým prvním krokem při vývoji úspěšné aplikace RAG. Tyto požadavky slouží ke dvěma primárním účelům. Za prvé pomáhají určit, jestli je RAG nejvhodnějším přístupem pro daný případ použití. Pokud je RAG skutečně vhodný, tyto požadavky řídí návrh, implementaci a hodnocení řešení. Investice času na začátku projektu ke shromáždění podrobných požadavků může zabránit významným výzvám a překážkám později v procesu vývoje a zajistit, aby výsledné řešení splňovalo potřeby koncových uživatelů a zúčastněných stran. Dobře definované požadavky poskytují základ pro následné fáze životního cyklu vývoje, které si projdeme.

Podívejte se na úložiště GitHub pro vzorový kód v této části. Kód úložiště můžete použít také jako šablonu, pomocí které můžete vytvářet vlastní aplikace AI.

Je případ použití vhodný pro RAG?

První věc, kterou je třeba stanovit, je, zda je rag dokonce správným přístupem pro váš případ použití. Vzhledem k hype kolem RAG, je lákavé si ji zobrazit jako možné řešení jakéhokoli problému. Existují však drobné odlišnosti, pokud je RAG vhodný versus ne.

RAG je vhodný v případech, kdy:

• Odůvodnění načtených informací (nestrukturovaných i strukturovaných), které se zcela nevejdou do kontextu LLM window
• Syntetizace informací z více zdrojů (například generování souhrnu klíčových bodů z různých článků v tématu)
• Dynamické načítání na základě uživatelského dotazu je nezbytné (například pro uživatelský dotaz určete, z jakého zdroje dat se má načíst).
• Případ použití vyžaduje generování nového obsahu na základě načtených informací (například odpovídání na otázky, poskytování vysvětlení, nabízení doporučení).

RAG nemusí být nejvhodnější, pokud:

• Úloha nevyžaduje načtení specifické pro dotazy. Například generování souhrnů přepisu volání; i v případě, že jsou v příkazovém řádku LLM poskytnuty jednotlivé přepisy jako kontext, zůstanou načtené informace pro každý souhrn stejné.
• Celá set informací, které se mají načíst, se může vejít do kontextu LLM window
• Vyžadují se extrémně nízké latence odpovědi (například když se vyžadují odpovědi v milisekundách).
• Jednoduché odpovědi založené na pravidlech nebo šablony jsou dostatečné (například chatovací robot zákaznické podpory, který poskytuje předdefinované odpovědi na základě klíčových slov).

Požadavky na zjišťování

Jakmile si ověříte, že rag je vhodný pro váš případ použití, zvažte následující otázky, abyste zachytili konkrétní požadavky. Požadavky jsou upřednostňovány následujícím způsobem:

🟢 P0: Před spuštěním poc je nutné tento požadavek definovat.

🟡 P1: Musí definovat před přechodem do produkce, ale může iterativní zpřesnit během POC.

⚪ P2: Pěkné mít požadavek.

Toto není vyčerpávající seznam list otázek. Měl by ale poskytnout pevný základ pro zachycení klíčových požadavků pro vaše řešení RAG.

Uživatelské prostředí

Definování způsobu interakce uživatelů se systémem RAG a očekávaného druhu odpovědí

🟢 [P0] Jak bude typický požadavek na řetězec RAG vypadat? Požádejte zúčastněné strany o příklady potenciálních uživatelských dotazů.

🟢 [P0] Jaký druh odpovědí budou uživatelé očekávat (krátké odpovědi, dlouhé vysvětlení, kombinace nebo něco jiného)?

🟡 [P1] Jak budou uživatelé pracovat se systémem? Prostřednictvím rozhraní chatu, vyhledávacího panelu nebo jiného způsobu?

🟡 [P1] Tón klobouku nebo stylu by měly generovat odpovědi? (formální, konverzační, technický?)

🟡 [P1] Jak by aplikace měla zpracovávat nejednoznačné, neúplné nebo irelevantní dotazy? Měla by být v takových případech poskytována nějaká forma zpětné vazby nebo pokynů?

⚪ [P2] Existují specifické požadavky na formátování nebo prezentaci pro vygenerovaný výstup? Měl by výstup obsahovat kromě odpovědi řetězu nějaká metadata?

Data

Určete povahu, zdroje a kvalitu dat, která budou použita v řešení RAG.

🟢 [P0] Jaké jsou dostupné zdroje, které se mají použít?

Pro každý zdroj dat:

• 🟢 [P0] Jsou data strukturovaná nebo nestrukturovaná?
• 🟢 [P0] Jaký je zdrojový formát načítaných dat (např. PDF soubory, dokumentace k obrázkům/tables, strukturované odpovědi rozhraní API)?
• 🟢 [P0] Where se tato data nacházejí?
• 🟢 [P0] Kolik dat je k dispozici?
• 🟡 [P1] Jak často se data aktualizují? Jak by se tyto aktualizace měly zpracovávat?
• 🟡 [P1] Existují nějaké známé problémy s kvalitou dat nebo nekonzistence pro každý zdroj dat?

Zvažte vytvoření inventáře table ke konsolidaci těchto informací, například:

Zdroj dat	Zdroj	Typy souborů	Velikost	frekvence Update
Zdroj dat 1	Svazek Catalog Unity	JSON	10 GB	Každý den
Zdroj dat 2	Veřejné rozhraní API	XML	NA (API)	V reálném čase
Zdroj dat 3	SharePoint	PDF, .docx	500 MB	měsíčně

Omezení výkonu

Zachyťte požadavky na výkon a prostředky pro aplikaci RAG.

🟡 [P1] Jaká je maximální přijatelná latence pro generování odpovědí?

🟡 [P1] Jaká je maximální přijatelná doba pro první token?

🟡 [P1] Pokud se výstup streamuje, je přijatelná vyšší celková latence?

🟡 [P1] Jsou pro odvození výpočetních prostředků k dispozici nějaká omezení nákladů?

🟡 [P1] Jaké jsou očekávané vzory využití a zatížení ve špičce?

🟡 [P1] Kolik souběžnýchuživatelůch Databricks nativně zpracovává takové požadavky na škálovatelnost prostřednictvím možnosti automatického škálování pomocí služby Model Serving.

Hodnocení

Zjistěte, jak se bude řešení RAG vyhodnocovat a v průběhu času zlepšovat.

🟢 [P0] Jaký je obchodní cíl nebo klíčový ukazatel výkonu, který chcete ovlivnit? Jaká je základní hodnota a jaký je cíl?

🟢 [P0] Kteří uživatelé nebo účastníci budou poskytovat počáteční a průběžnou zpětnou vazbu?

🟢 [P0] Jaké metriky by se měly použít k vyhodnocení kvality vygenerovaných odpovědí? Mosaic AI Agent Evaluation poskytuje doporučenou sadu set metrik, které se mají použít.

🟡 [P1] Co je set otázek, které aplikace RAG potřebuje, aby šla do produkčního prostředí?

🟡 [P1] Existuje [vyhodnocení set] ? Je možné get provést vyhodnocení set uživatelských dotazů spolu s reálnými odpověďmi a (volitelně) správnými podpůrnými dokumenty, které by měly být načteny?

🟡 [P1] Jak se bude shromažďovat a začlenit zpětná vazba uživatelů do systému?

Zabezpečení

Identifikujte všechny aspekty zabezpečení a ochrany osobních údajů.

🟢 [P0] Jsou citlivá/důvěrná data, která je potřeba zpracovat opatrně?

🟡 [P1] Je nutné v řešení implementovat řízení přístupu (například daný uživatel může načíst pouze z omezených set dokumentů)?

Nasazení

Principy integrace, nasazení a údržby řešení RAG

🟡 Jak by se řešení RAG mělo integrovat se stávajícími systémy a pracovními postupy?

🟡 Jak by měl být model nasazen, škálován a správě verzí? V tomto kurzu se dozvíte, jak je možné zpracovat kompletní životní cyklus v Databricks pomocí MLflow, Unity Catalog, sady Agent SDK a obsluhy modelů.

Příklad

Jako příklad zvažte, jak tyto otázky platí pro tuto ukázkovou aplikaci RAG používanou týmem zákaznické podpory Databricks:

Plocha	Důležité informace	Požadavky
Uživatelské prostředí	- Způsob interakce. – Typické příklady uživatelských dotazů. - Očekávaný formát a styl odpovědi. - Zpracování nejednoznačných nebo irelevantních dotazů.	- Chat rozhraní integrované se Slack. – Příklady dotazů: "Návody zkrátit čas spuštění clusteru?" "Jaký druh plánu podpory mám?" - Jasné, technické odpovědi s fragmenty kódu a odkazy na relevantní dokumentaci where vhodné. – V případě potřeby poskytněte kontextové návrhy a eskalace technikům podpory.
Data	- Počet a typ zdrojů dat. - Formát a umístění dat. - Velikost dat a frekvence update. - Kvalita a konzistence dat.	– Tři zdroje dat. - Firemní dokumentace (HTML, PDF). – Vyřešené lístky podpory (JSON). - Příspěvky na komunitním fóru (Delta table) – Data uložená v Unity Catalog a aktualizují se každý týden. - Celková velikost dat: 5 GB. – Konzistentní datová struktura a kvalita udržovaná vyhrazenými dokumenty a týmy podpory.
Výkon	- Maximální přijatelná latence. - Omezení nákladů. – Očekávané využití a souběžnost.	– Požadavek na maximální latenci. - Omezení nákladů. - Očekávané zatížení ve špičce.
Hodnocení	– Dostupnost testovací datové sady. - Metriky kvality. - Shromažďování názorů uživatelů.	– Odborníci na danou problematiku z jednotlivých oblastí produktů pomáhají kontrolovat výstupy a upravovat nesprávné odpovědi pro vytvoření testovací datové sady. - Obchodní klíčové ukazatele výkonu. - Zvýšení rychlosti řešení lístků podpory. - Snížení času stráveného uživatelem na lístek podpory. - Metriky kvality. - Správnost odpovědí a relevanci s posouzením LLM. - LLM soudce načítá přesnost. - Upvote nebo downvote uživatelem. - Zpětná vazba. - Slack bude instrumentován tak, aby poskytoval palec nahoru / dolů.
Zabezpečení	- Zpracování citlivých dat. - Požadavky na řízení přístupu.	– Ve zdroji načítání by neměla být žádná citlivá zákaznická data. – Ověřování uživatelů prostřednictvím jednotného přihlašování komunity Databricks.
Nasazení	- Integrace se stávajícími systémy. – Nasazení a správa verzí.	- Integrace se systémem lístků podpory. – Řetězení nasazené jako koncový bod obsluhy modelu Databricks

Další krok

Get začal s krokem 1. Naklonujte úložiště kódu a vytvořte výpočetní.

< Předchozí: Vývoj řízený vyhodnocením

Další: Krok 1. Klonování úložiště a vytvoření výpočetních prostředků >