Pracovní postupy LLMOps v Azure Databricks

Tento článek doplňuje pracovní postupy MLOps v Databricks přidáním informací specifických pro pracovní postupy LLMOps. Další podrobnosti najdete v tématu Velká kniha MLOps.

Jak se u LLM mění pracovní postup MLOps?

LLM jsou třída modelů zpracování přirozeného jazyka (NLP), které výrazně překročily velikost a výkon svých předchůdců v různých úlohách, jako jsou odpovědi na otevřené otázky, shrnutí a provádění instrukcí.

Vývoj a hodnocení LLM se liší některými důležitými způsoby od tradičních modelů ML. Tato část stručně shrnuje některé klíčové vlastnosti LLM a důsledky pro MLOps.

Klíčové vlastnosti LLM	Důsledky pro MLOps
LLM jsou k dispozici v mnoha formách. Obecné proprietární modely a modely operačního systému, ke kterým se přistupuje pomocí placených rozhraní API Běžně dostupné open source modely, které se liší od obecných po konkrétní aplikace. Vlastní modely, které byly jemně vyladěné pro konkrétní aplikace. Vlastní předem natrénované aplikace	Proces vývoje: Projekty se často vyvíjejí přírůstkově, počínaje stávajícími, externími nebo open source modely a končí vlastními jemně vyladěnými modely.
Mnoho LLM jako vstup bere obecné dotazy v přirozeném jazyce a pokyny. Tyto dotazy mohou obsahovat pečlivě zpracované výzvy k vyvolání požadovaných odpovědí.	Proces vývoje: Návrh textových šablon pro dotazování LLM je často důležitou součástí vývoje nových kanálů LLM. Balení artefaktů ML: Mnoho pipelinek LLM používá existující LLM nebo LLM pro obsluhu koncových bodů. Logika ML vyvinutá pro tyto datové toky se může soustředit na šablony výzev, agenty nebo řetězce namísto modelu samotného. Artefakty ML zabalené a povýšené do produkčního prostředí můžou být tyto pipeliny, nikoli modely.
Mnoho LLMů může být poskytnuto s různými příklady, kontextem nebo dalšími informacemi, které vám pomohou odpovědět na dotaz.	Obsluha infrastruktury: Při rozšiřování dotazů LLM s kontextem můžete k vyhledání relevantního kontextu použít další nástroje, jako jsou indexy vektorů.
Rozhraní API třetích stran poskytují proprietární a opensourcové modely.	zásady správného řízení rozhraní API: Použití centralizovaných zásad správného řízení rozhraní API umožňuje snadno přepínat mezi poskytovateli rozhraní API.
LLM jsou velmi velké modely hlubokého učení, často od gigabajtů až po stovky gigabajtů.	Obsluha infrastruktury: LLM můžou vyžadovat GPU pro obsluhu modelu v reálném čase a rychlé úložiště pro modely, které je potřeba načíst dynamicky. Kompromisy mezi náklady a výkonem: Vzhledem k tomu, že větší modely vyžadují větší výpočetní výkon a jsou dražší, mohou být vyžadovány techniky pro snížení velikosti modelu a výpočtu.
LLM se obtížně vyhodnocují pomocí tradičních metrik ML, protože často neexistuje jediná "správná" odpověď.	Lidská zpětná vazba: Lidská zpětná vazba je nezbytná pro vyhodnocení a testování LLM. Do procesu MLOps byste měli začlenit přímo zpětnou vazbu uživatelů, včetně testování, monitorování a dalšího vyladění.

Podobnosti mezi MLOps a LLMOps

Mnoho aspektů procesů MLOps se u LLM nemění. Například následující pokyny platí také pro LLM:

• Pro vývoj, přípravu a produkci používejte samostatná prostředí.
• Použijte Git pro správu verzí.
• Správa vývoje modelů pomocí MLflow a použití Modely v katalogu Unity ke správě životního cyklu modelu.
• Data můžete ukládat v architektuře lakehouse pomocí tabulek Delta.
• Vaše stávající infrastruktura CI/CD by neměla vyžadovat žádné změny.
• Modulární struktura MLOps zůstává stejná, s kanály pro featurizaci, trénování modelů, odvozování modelů atd.

Referenční diagramy architektury

Tato část používá dvě aplikace založené na LLM k ilustraci některých úprav referenční architektury tradiční mlOps. Diagramy znázorňují produkční architekturu pro 1) aplikaci rag (retrieval-augmented generation) využívající rozhraní API třetí strany a 2) aplikaci RAG s využitím jemně vyladěného modelu v místním prostředí. Oba diagramy znázorňují volitelnou vektorovou databázi – tuto položku lze nahradit přímým dotazováním LLM prostřednictvím koncového bodu obsluhy modelu.

RAG s rozhraním LLM API třetí strany

Diagram znázorňuje produkční architekturu pro aplikaci RAG, která se připojuje k rozhraní LLM API třetí strany pomocí externích modelů Databricks.

RAG s jemně vyladěným opensourcovým modelem

Diagram znázorňuje produkční architekturu pro aplikaci RAG, která vyladí open-source model.

Změny prováděné LLMOps v produkční architektuře MLOps

Tato část popisuje hlavní změny referenční architektury MLOps pro aplikace LLMOps.

Centrum modelů

Aplikace LLM často používají existující předem natrénované modely vybrané z interního nebo externího centra modelů. Model se dá použít tak, jak je, nebo doladit.

Databricks zahrnuje výběr vysoce kvalitních předem natrénovaných základních modelů v katalogu Unity a na Webu Databricks Marketplace. Tyto předem natrénované modely můžete použít pro přístup k špičkovým funkcím umělé inteligence, což vám ušetří čas a náklady na vytváření vlastních modelů. Podrobnosti naleznete v tématu Přístup k generativním AI a LLM modelům z katalogu Unity.

Vektorový index

Některé aplikace LLM používají vektorové indexy k rychlému vyhledávání podobnosti, například k poskytování kontextových nebo doménových znalostí v dotazech LLM. Databricks poskytuje funkci integrovaného vektorového vyhledávání, která umožňuje použít libovolnou tabulku Delta v katalogu Unity jako vektorový index. Index vektorového vyhledávání se automaticky synchronizuje s tabulkou Delta. Podrobnosti najdete v tématu Vektorové vyhledávání.

Můžete vytvořit artefakt modelu, který zapouzdřuje logiku pro načtení informací z vektorového indexu a poskytuje vrácená data jako kontext LLM. Model pak můžete protokolovat pomocí typu modelu MLflow LangChain nebo PyFunc.

Doladění modelu LLM

Vzhledem k tomu, že modely LLM jsou nákladné a časově náročné na vytvoření od nuly, aplikace LLM často dolaďují stávající model, aby zlepšily jeho výkon v konkrétním scénáři. V referenční architektuře jsou vyladění a nasazení modelu reprezentovány jako jedinečné úlohy Lakeflow. Ověření jemně vyladěného modelu před nasazením je často ruční proces.

Databricks poskytuje jemné ladění základního modelu, které umožňuje přizpůsobit stávající LLM a optimalizovat jeho výkon pro vaši konkrétní aplikaci pomocí vlastních dat. Podrobnosti najdete v tématu Vyladění základního modelu.

Obsluha modelu

Ve scénáři RAG využívajícím rozhraní API třetí strany je důležitá změna architektury v tom, že potrubí LLM provádí externí volání rozhraní API z koncového bodu služby modelu k interním nebo API třetích stran LLM. To zvyšuje složitost, potenciální latenci a další správu přihlašovacích údajů.

Databricks poskytuje službu Mosaic AI Model Serving, která poskytuje jednotné rozhraní pro nasazování, spravování a dotazování modelů AI. Podrobnosti najdete v tématu O obsluhě modelu AI v systému Mosaic.

Lidská zpětná vazba při monitorování a hodnocení

Smyčky zpětné vazby pro člověka jsou nezbytné ve většině aplikací LLM. Lidská zpětná vazba by se měla spravovat stejně jako jiná data, ideálně začleněná do monitorování na základě streamování téměř v reálném čase.

Aplikace pro kontrolu agenta AI Mosaic vám pomůže shromáždit zpětnou vazbu od lidských recenzentů. Podrobnosti najdete v tématu Použití aplikace pro lidské hodnocení aplikace generativní AI (MLflow 2).