Sdílet prostřednictvím

Vývojářský pracovní postup generování aplikací AI

  • Článek

Vývoj robustní aplikace generující umělé inteligence (aplikace Gen AI) vyžaduje záměrné plánování, smyčku rychlého vyhodnocení zpětné vazby a škálovatelnou produkční infrastrukturu. Tento pracovní postup popisuje doporučenou posloupnost kroků, která vás provede počátečním testováním konceptu (POC) až po produkční nasazení.

0. Požadavky

  • Shromážděte požadavky k ověření vhodnosti generativní AI a identifikujte omezení.
  • Navrhněte architekturu řešení.

1. Sestavení

  • Připravte zdroje dat a vytvořte potřebné nástroje.
  • Sestavení a ověření počátečního prototypu (POC)
  • Nasazení do předprodukčního prostředí

2. Vyhodnoťte & Iterace

  • Shromažďování názorů uživatelů a měření kvality
  • Opravte problémy s kvalitou upřesněním logiky agenta a nástrojů na základě vyhodnocení.
  • Zahrňte vstupy odborníků na danou problematiku (SME) pro průběžné zlepšování kvality systému pro agenty.

3. Produkční

  • Nasazení aplikace Gen AI do produkčního prostředí
  • Monitorujte výkon a kvalitu.
  • Udržujte a vylepšete na základě skutečného využití.

Tento pracovní postup by měl být iterativní: po každém cyklu nasazení nebo vyhodnocení se vraťte k dřívějším krokům, abyste upřesnili datové kanály nebo aktualizovali logiku agentů. Například monitorování v produkčním prostředí může odhalit nové požadavky, aktivovat aktualizace návrhu agenta a další kolo vyhodnocení. Systematicky sledovat tyto kroky a využívat trasování Databricks MLflow, rozhraní agenta a funkce hodnocení agentů, můžete vytvářet vysoce kvalitní generativní AI aplikace, které spolehlivě splňují potřeby uživatelů, respektují požadavky na zabezpečení a dodržování předpisů a v průběhu času se budou dál vylepšovat.

0. Požadavky

Než začnete s vývojem vaší aplikace generativní AI, nelze přeceňovat, jak důležité je věnovat čas správnému provedení následujícího: shromažďování požadavků a návrhu řešení.

požadavky na shromažďování zahrnují následující kroky:

  • Ověřte, jestli gen AI vyhovuje vašemu případu použití.
  • Definujte uživatelské prostředí.
  • Prozkoumání zdrojů dat
  • Nastavte omezení výkonu.
  • Zachyťte omezení zabezpečení.

návrh řešení zahrnuje následující:

  • Namapovat datové kanály.
  • Identifikujte potřebné nástroje.
  • Nastínit celkovou systémovou architekturu

Položením základů určíte jasný směr pro následující fáze Build, Evaluatea Production.

Shromáždit požadavky

Definování jasných a komplexních požadavků na případ použití je zásadním prvním krokem při vývoji vaší úspěšné generativní AI aplikace. Tyto požadavky slouží k těmto účelům:

  • Pomáhají určit, jestli je přístup genové umělé inteligence vhodný pro váš případ použití.
  • Řídí rozhodování o návrhu, implementaci a hodnocení řešení.

Investice času na začátku ke shromáždění podrobných požadavků může zabránit významným výzvá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 vaší aplikace.

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

Než se rozhodnete pro řešení generativní umělé inteligence, zvažte, zda jeho inherentní silné stránky odpovídají vašim požadavkům. Mezi příklady, ve kterých je vhodné použít řešení generující umělé inteligence, patří:

  • Generování obsahu: Úloha vyžaduje generování nového nebo kreativního obsahu, kterého nelze dosáhnout pomocí statických šablon nebo jednoduché logiky založené na pravidlech.
  • dynamické zpracování dotazů: dotazy uživatelů jsou otevřené nebo složité a vyžadují flexibilní odpovědi s podporou kontextu.
  • Syntéza informací: Případ použití přináší výhody kombinování nebo shrnutí různých zdrojů informací za účelem vytvoření koherentního výstupu.
  • Agent Systems: Aplikace vyžaduje více než jen generování textu v reakci na výzvu. Možná bude potřeba, aby byla schopná:
    • Plánování a rozhodování: Formulace strategie s více kroky k dosažení konkrétního cíle.
    • Provádění akcí: aktivace externích procesů nebo volání různých nástrojů k provádění úloh (například načítání dat, volání rozhraní API, spouštění dotazů SQL, spouštění kódu).
    • Udržování stavu: Sledování historie konverzací nebo kontextu úkolů napříč několika interakcemi, aby bylo možné zajistit kontinuitu.
    • Vytváření adaptivních výstupů: Generování odpovědí, které se vyvíjejí na základě předchozích akcí, aktualizovaných informací nebo měnících se podmínek.

Naopak přístup genové umělé inteligence nemusí být ideální v následujících situacích:

  • Úloha je vysoce deterministická a lze ji efektivně vyřešit pomocí předdefinovaných šablon nebo systémů založených na pravidlech.
  • Celá sada požadovaných informací je již statická nebo zapadá do jednoduché uzavřené architektury.
  • Odpovědi s extrémně nízkou latencí (v řádu milisekund) jsou vyžadovány a režijní náklady spojené s generativním zpracováním nelze přizpůsobit.
  • Jednoduché šablonované odpovědi jsou dostatečné pro zamýšlený případ použití.

Důležitý

Následující části používají popisky P0, P1a P2 označující relativní prioritu.

  • 🟢 [P0] položky jsou důležité nebo nezbytné. Tyto problémy musí být řešeny okamžitě.
  • 🟡 [P1] položky jsou důležité, ale mohou následovat po P0 požadavcích.
  • ⚪ [P2] položky jsou aspekty nebo vylepšení s nižší prioritou, které je možné řešit, pokud to čas a zdroje dovolí.

Tyto popisky pomáhají týmům rychle zjistit, které požadavky vyžadují okamžitou pozornost a které je možné odložit.

Uživatelské prostředí

Definujte, jak budou uživatelé pracovat s aplikací Gen AI a jaký druh odpovědí se očekává.

  • 🟢 [P0] Typický požadavek: Jak bude vypadat typický požadavek uživatele? Shromážděte příklady od zúčastněných stran.
  • 🟢 [P0] Očekávané odpovědi: Jaký typ odpovědí má systém generovat (například krátké odpovědi, dlouhé vysvětlení, kreativní vyprávění)?
  • 🟡 [P1] Způsob interakce: Jak budou uživatelé pracovat s aplikací (například chatovací rozhraní, panel hledání, hlasový asistent)?
  • 🟡 [P1] Tón, styl, struktura: Jaký tón, styl a struktura by generované výstupy měly mít (formální, konverzační, technické, odrážkové body nebo souvislý text)?
  • 🟡 [P1] zpracování chyb: Jak má aplikace zpracovávat nejednoznačné, neúplné nebo mimo-cílové dotazy? Má poskytnout zpětnou vazbu nebo požádat o objasnění?
  • ⚪ [P2] Požadavky na formátování: Existují nějaké konkrétní pokyny k formátování nebo prezentaci pro výstupy (včetně metadat nebo doplňkových informací)?

Data

Určete povahu, zdroje a kvalitu dat, která se použijí v aplikaci gen AI.

  • 🟢 [P0] Zdroje dat: Jaké zdroje dat jsou k dispozici?
    • Pro každý zdroj určete:
      • Jsou data strukturovaná nebo nestrukturovaná?
      • Jaký je zdrojový formát (například PDF, HTML, JSON, XML)?
      • Kde se data nacházejí?
      • Kolik dat je k dispozici?
      • Jak mají být data přístupná?
  • 🟡 [P1] Aktualizace dat: Jak často se data aktualizují? Jaké mechanismy se používají pro zpracování aktualizací?
  • 🟡 [P1] Kvalita dat: Existují známé problémy s kvalitou nebo nekonzistence?
    • Zvažte, jestli se bude vyžadovat monitorování kvality zdrojů dat.

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

Zdroj dat Zdroj Typy souborů Velikost Četnost aktualizací
Zdroj dat 1 Objem katalogu Unity JSON 10 GB Denně
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

Zachycení požadavků na výkon a prostředky pro aplikaci generativní umělé inteligence.

latence

  • 🟢 [P0] Čas k prvnímu tokenu: Jaká je maximální přijatelná prodleva před doručením prvního tokenu výstupu?
    • Poznámka: Latence se obvykle měří pomocí p50 (mediánu) a p95 (95. percentil) k zachycení průměrného i nejhoršího výkonu.
  • 🟢 [P0] Doba dokončení: Jaká je přijatelná doba odezvy (doba dokončení) pro uživatele?
  • 🟢 [P0] Latence streamování: Pokud se odpovědi streamují, je přijatelná vyšší celková latence?

Škálovatelnost

  • 🟡 [P1]souběžných uživatelů & požadavky: Kolik souběžných uživatelů nebo požadavků má systém podporovat?
    • Poznámka: Škálovatelnost se často měří z hlediska QPS (dotazů za sekundu) nebo QPM (dotazy za minutu).
  • 🟡 [P1] Vzorce použití: Jaké jsou očekávané vzorce provozu, špičky nebo špičky využití na základě času?

omezení nákladů

  • 🟢 [P0] Omezení nákladů na odvozování: Jaká jsou omezení nákladů nebo omezení rozpočtu pro odvozování výpočetních prostředků?

Vyhodnocení

Zjistěte, jak bude posuzována a v průběhu času zdokonalována aplikace generativní umělé inteligence.

  • 🟢 [P0] Klíčové ukazatele výkonu pro firmy: Který obchodní cíl nebo klíčový ukazatel výkonu by měly mít vliv na aplikaci? Definujte základní hodnoty a cíle.
  • 🟢 [P0] Zpětná vazba účastníků: Kdo poskytne počáteční a průběžnou zpětnou vazbu k výkonu a výstupům aplikace? Identifikujte konkrétní skupiny uživatelů nebo odborníky na doménu.
  • 🟢 [P0] Měření kvality: Jaké metriky (například přesnost, relevance, bezpečnost, lidské skóre) se použijí k vyhodnocení kvality vygenerovaných výstupů?
    • Jak se tyto metriky počítají během vývoje (například u syntetických dat, ručně kurátorovaných datových sad)?
    • Jak se bude kvalita měřit v produkčním prostředí (například protokolování a analýza odpovědí na skutečné dotazy uživatelů)?
    • Jaká je celková tolerance chyby? (například přijměte určité procento menších faktických nepřesností nebo vyžaduje téměř 100% správnosti pro kritické případy použití.)
    • Cílem je sestavit sadu hodnocení ze skutečných uživatelských dotazů, syntetických dat nebo kombinace obou. Tato sada poskytuje konzistentní způsob, jak vyhodnotit výkon při vývoji systému.
  • 🟡 [P1] Smyčky zpětné vazby: Jak by se měla shromažďovat zpětná vazba uživatelů (například palce nahoru/dolů, formuláře průzkumu) a používat k iterativním vylepšením?
    • Naplánujte, jak často bude zpětná vazba zkontrolována a začleněna.

Bezpečnost

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

  • 🟢 [P0] Citlivost dat: Existují citlivé nebo důvěrné datové prvky, které vyžadují zvláštní zpracování?
  • 🟡 [P1] Řízení přístupu: Potřebujete implementovat řízení přístupu, abyste omezili určitá data nebo funkce?
  • 🟡 [P1] Posouzení hrozeb & zmírnění rizik: Bude vaše aplikace muset chránit před běžnými hrozbami generativní umělé inteligence, jako jsou injektáž podnětů nebo škodlivé vstupy uživatelů?

Nasazení

Pochopte, jak bude generativní řešení AI integrováno, nasazeno, monitorováno a udržováno.

  • 🟡 [P1] Integrace: Jak by se řešení AI generátoru mělo integrovat se stávajícími systémy a pracovními postupy?
    • Identifikujte integrační body (například Slack, CRM, NÁSTROJE BI) a požadované datové konektory.
    • Určete, jakým způsobem budou požadavky a odpovědi proudit mezi aplikací generativní AI a podřízenými systémy (například rozhraní REST API, webhooky).
  • 🟡 [P1] Nasazení: Jaké jsou požadavky na nasazení, škálování a správu verzí aplikace? Tento článek popisuje, jak lze v Databricks zpracovávat kompletní životní cyklus pomocí MLflow, Unity Catalog, Agent Framework, Agent Evaluationa Služby modelů.
  • 🟡 [P1] Monitorování produkce & observability: Jak budete monitorovat aplikaci, jakmile bude v provozu?
    • Protokolování & stop: Zachycení úplných provozních stop.
    • Metriky kvality: Nepřetržitě vyhodnocujte klíčové metriky (například správnost, latence, relevance) pro živý provoz.
    • Výstrahy & řídicích panelů: Nastavte upozornění na kritické problémy.
    • Smyčka zpětné vazby: Zahrnout zpětnou vazbu uživatelů do procesu produkce (palce nahoru nebo dolů), abyste zachytili problémy včas a podpořili postupné zlepšování.

Příklad

Podívejte se například na to, jak tyto aspekty a požadavky platí pro hypotetickou aplikaci RAG, kterou používá tým zákaznické podpory Databricks:

Oblast Úvahy 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ů
  • Chatovací rozhraní integrované se Slackem.
  • Příklady dotazů: Jak zkrátit dobu spuštění clusteru? "Jaký druh plánu podpory mám?"
  • Jasné technické odpovědi s fragmenty kódu a odkazy na příslušnou dokumentaci, kde je to vhodné.
  • Poskytněte kontextové návrhy a v případě potřeby eskalujte záležitosti technikům podpory.
Logika agenta
  • Porozumění a klasifikace dotazů
  • Plánování a rozhodování ve více krocích.
  • Autonomní výběr a provádění nástrojů.
  • Správa stavu a kontextu napříč interakcemi
  • Zpracování chyb a záložní mechanismy
  • Plánování založené na LLM s deterministickými náhradními řešeními
  • Integrace se sadou předem definovaných nástrojů (jako je získávání dokumentů nebo nástroj pro získávání Salesforce).
  • Udržujte stav konverzace pro koherentní vícesměrné interakce a účinné zotavení z chyb.
Data
  • Počet a typ zdrojů dat
  • Formát a umístění dat.
  • Velikost dat a frekvence aktualizací
  • Kvalita a konzistence dat
  • Čtyři zdroje dat
  • Dokumentace společnosti (HTML, PDF).
  • Vyřešené lístky podpory (JSON).
  • Příspěvky komunitního fóra (tabulka Delta).
  • Konektor Salesforce
  • Data uložená v katalogu Unity a aktualizují se každý týden.
  • Celková velikost dat: 5 GB.
  • Konzistentní datová struktura a kvalita udržovaná oddělenou dokumentací 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.
Vyhodnocení
  • 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í zkontrolovat výstupy a upravit nesprávné odpovědi a vytvořit datovou sadu vyhodnocení.
  • Klíčové ukazatele výkonu firmy.
  • Zvýšení rychlosti řešení lístků podpory
  • Snížení času, který uživatel stráví na každý tiket podpory
  • Metriky kvality
  • Správnost a relevance odpovědí posouzená LLM.
  • LLM hodnotí přesnost vyhledávání.
  • Uživatel hlasuje pro nebo proti.
  • Kolekce zpětné vazby
  • Slack bude nastaven tak, aby umožňoval hodnocení palcem nahoru/dolů.
Bezpečnost
  • 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 s ticketovacím systémem podpory
  • Agent nasazený jako koncový bod obsluhy modelu Databricks

Návrh řešení

Zdroje dat a nástroje &

Při návrhu aplikace gen AI je důležité identifikovat a mapovat různé zdroje dat a nástroje potřebné k řízení vašeho řešení. To může zahrnovat strukturované datové sady, nestrukturované kanály zpracování dat nebo dotazování externích rozhraní API. Níže jsou uvedené doporučené přístupy pro začlenění různých zdrojů dat nebo nástrojů do aplikace Gen AI:

Strukturovaná data

Strukturovaná data se obvykle nacházejí v dobře definovaných tabulkových formátech (například v tabulce Delta nebo souboru CSV) a jsou ideální pro úlohy, ve kterých jsou dotazy předem definované nebo je potřeba generovat dynamicky na základě uživatelského vstupu. Doporučení k přidání strukturovaných dat do vaší generativní AI aplikace viz nástroje agenta strukturovaného načítání AI.

Nestrukturovaná data

Nestrukturovaná data zahrnují nezpracované dokumenty, soubory PDF, e-maily, obrázky a další formáty, které neodpovídají pevnému schématu. Tato data vyžadují další zpracování, obvykle prostřednictvím kombinace analýzy, segmentace a zapouzdření, aby byla efektivně dotazována a používána v generativní AI aplikaci. Podívejte se na nástroje agenta AI pro neorganizované vyhledávání pro doporučení ohledně přidání strukturovaných dat do vaší generativní AI aplikace.

Akce & externích rozhraní API

V některých scénářích může vaše aplikace AI založená na generativní technologii potřebovat interagovat s externími systémy k načítání dat nebo provádění akcí. V případech, kdy vaše aplikace vyžaduje vyvolání nástrojů nebo interakci s externími rozhraními API, doporučujeme následující:

  • Správa přihlašovacích údajů rozhraní API pomocí připojení ke kataloguUnity: K bezpečnému řízení přihlašovacích údajů rozhraní API použijte připojení katalogu Unity. Tato metoda zajišťuje, že tokeny a tajné kódy jsou centrálně spravované a řízené přístupem.
  • vyvolejte prostřednictvímDatabricks SDK:
    Odesílat požadavky HTTP externím službám pomocí funkce http_request z knihovny databricks-sdk. Tato funkce využívá připojení katalogu Unity k ověřování a podporuje standardní metody HTTP.
  • využití funkcí katalogu Unity:
    Zabalte externí připojení do funkce Katalogu Unity a přidejte vlastní logiku předběžného nebo následného zpracování.
  • nástroj exekutoru Pythonu:
    Pokud chcete dynamicky spouštět kód pro transformace dat nebo interakce rozhraní API pomocí funkcí Pythonu, použijte integrovaný nástroj exekutoru Pythonu.

Příklad :

Interní analytická aplikace načítá živá data trhu z externího finančního rozhraní API. Aplikace používá:

Přístup k implementaci

Při vývoji aplikace gen AI máte dvě hlavní možnosti pro implementaci logiky agenta: využití opensourcové architektury nebo vytvoření vlastního řešení pomocí kódu Pythonu. Níže je rozpis výhod a nevýhod pro každý přístup.

Použití architektury (například LangChain, LlamaIndex, CrewAI nebo AutoGen)

Výhody:

  • předdefinované komponenty: Frameworky obsahují připravené nástroje pro správu promptů, řetězení volání a integraci s různými zdroji dat, což může urychlit vývoj.
  • komunity a dokumentace: Využijte komunitní podporu, kurzy a pravidelné aktualizace.
  • běžných vzorů návrhu: rozhraní Framework obvykle poskytují jasnou modulární strukturu pro orchestraci běžných úloh, což může zjednodušit celkový návrh agenta.

Nevýhody:

  • Přidání abstrakce: Otevřené rámce často představují vrstvy abstrakce, které nemusí být nezbytné pro váš konkrétní případ použití.
  • Závislost na aktualizacích: Můžete být závislí na správcích architektury pro opravy chyb a aktualizace funkcí, což může zpomalit schopnost rychle se přizpůsobit novým požadavkům.
  • potenciální režie: Extra abstrakce může vést k problémům s přizpůsobením, pokud vaše aplikace potřebuje jemně odstupňovanou kontrolu.
Použití čistého Pythonu

Výhody:

  • flexibilita: Vývoj v čistém Pythonu umožňuje přizpůsobit implementaci přesně vašim potřebám, aniž by byla omezena rozhodnutími o návrhu architektury.
  • Rychlé přizpůsobení: Kód můžete rychle upravit a podle potřeby začlenit změny, aniž byste museli čekat na aktualizace z externí architektury.
  • Jednoduchost: Vyhněte se zbytečným vrstvám abstrakce, což může potenciálně vést ke štíhlému a výkonnějšímu řešení.

Nevýhody:

  • zvýšené úsilí o vývoj: vytváření od začátku může vyžadovat více času a odborných znalostí k implementaci funkcí, které by jinak mohl poskytnout specializovaný rámec.
  • Objevování již existujícího: Možná budete muset vyvíjet obvyklé funkce (jako je řetězení nástrojů nebo správa výzev) sami.
  • odpovědnost za údržbu: Všechny aktualizace a opravy chyb se stanou vaší zodpovědností, což může být pro složité systémy náročné.

V konečném důsledku by vaše rozhodnutí mělo být řízeno složitostí projektu, potřebami výkonu a úrovní kontroly, kterou potřebujete. Ani jeden přístup není ze své podstaty nadřazený; každá nabízí různé výhody v závislosti na vašich preferencích vývoje a strategických prioritách.

1. Vybudovat

V této fázi transformujete návrh řešení na funkční aplikaci AI gen. Místo toho, aby se všechno předem zdokonalovalo, začněte s minimálním testováním konceptu (POC), který je možné rychle testovat. To vám umožní co nejdříve nasadit do předprodukčního prostředí, shromažďovat reprezentativní dotazy od skutečných uživatelů nebo msp a upřesňovat na základě zpětné vazby z reálného světa.

vývojový diagram znázorňující kroky přípravy, sestavení a nasazení

Proces sestavení se řídí těmito klíčovými kroky:

a. Připravit data & nástroje: Ujistěte se, že jsou požadovaná data přístupná, zpracovaná a připravená k načtení. Implementujte nebo zaregistrujte funkce a připojení katalogu Unity, které bude váš agent potřebovat (například API pro získávání dat nebo volání externího rozhraní API). b. Agent sestavení: Orchestrujte základní logiku, začínaje jednoduchým přístupem proof of concept. c. Kontrola kvality: Před zveřejněním aplikace více uživatelům ověřte základní funkce. d. Nasazení předprodukčního agenta: Zpřístupnit POC testovacím uživatelům a odborníkům na danou problematiku na počáteční zpětnou vazbu. e. Shromáždit zpětnou vazbu uživatelů: Použití reálného světa k identifikaci oblastí zlepšování, dalších potřebných dat nebo nástrojů a potenciálních vylepšení pro další iteraci.

a. Příprava nástrojů & pro data

Ve fázi návrhu řešení budete mít počáteční představu o zdrojích dat a nástrojích potřebných pro vaši aplikaci. V této fázi nechte vše minimalistické: zaměřte se pouze na dostatek dat k ověření POC. Tím se zajistí rychlá iterace bez náročných počátečních investic do složitých kanálů.

Data

  1. cs-CZ: Identifikace reprezentativní podmnožiny dat
    • U strukturovaných datvyberte klíčové tabulky nebo sloupce, které jsou pro váš počáteční scénář nejrelevantní.
    • U nestrukturovaných daturčete prioritu indexování pouze podmnožině reprezentativních dokumentů. Použijte základní proces zpracování částí a vkládání s Mosaic AI vektorovým vyhledáváním, aby váš agent mohl v případě potřeby načíst relevantní textové úseky.
  2. Nastavení přístupu k datům
    • Pokud potřebujete, aby vaše aplikace volat externí rozhraní API, bezpečně ukládejte přihlašovací údaje pomocí připojení ke katalogu Unity.
  3. Ověření základního pokrytí
    • Ověřte, že zvolené podmnožina dat odpovídajícím způsobem řeší dotazy uživatelů, které chcete testovat.
    • Uložte všechny další zdroje dat nebo složité transformace pro budoucí iterace. Vaším aktuálním cílem by mělo být prokázání základní proveditelnosti a shromáždění zpětné vazby.

Nářadí

Po nastavení zdrojů dat je dalším krokem implementace a registrace nástrojů, které agent bude volat za běhu do katalogu Unity. Nástroj je funkce s jednou interakcí, jako je dotaz SQL nebo volání externího rozhraní API, které může agent vyvolat pro načtení, transformaci nebo akci.

nástroje pro načítání dat

  • Omezené dotazy na strukturovaná data: Pokud jsou dotazy pevné, zabalte je do funkce SQL katalogu Unity nebo do uživatelsky definované funkce v Pythonu. Díky tomu je logika centralizovaná a zjistitelná.
  • otevřené strukturované datové dotazy: Pokud jsou dotazy otevřené, zvažte nastavení prostoru Genie pro zpracování dotazů typu text-to-SQL.
  • pomocných funkcí nestrukturovaných dat: Pro nestrukturovaná data uložená ve službě Mosaic AI Vector Search vytvořit nestrukturovaný nástroj pro načítání dat, který agent může volat k načtení relevantních textových bloků dat.

nástroje pro volání API

Udržujte to jednoduché

  • Začít jenom se základními nástroji: Zaměřit se na jednu cestu načítání nebo omezenou sadu volání rozhraní API. Při iteraci můžete přidat další položky.
  • Ověřit interaktivně: každý nástroj testujte nezávisle (například v poznámkovém bloku), než ho začleníte do systému agentů.

Jakmile jsou prototypové nástroje připravené, pokračujte vytvořením agenta. Agent orchestruje tyto nástroje pro odpovědi na dotazy, načítání dat a provádění akcí podle potřeby.

b. Agent sestavení

Po nasazení dat a nástrojů můžete sestavit agenta, který reaguje na příchozí požadavky, jako jsou dotazy uživatelů. K vytvoření počátečního prototypu agenta použijte buď Python, nebo AI hřiště. Postupujte takto:

  1. Začněte jednoduše
    • Vyberte základní vzor návrhu: Pro POC začněte základním řetězem (například pevnou sekvencí kroků) nebo jedním agentem pro volání nástrojů (kde LLM může dynamicky volat jeden nebo dva základní nástroje).
      • Pokud váš scénář odpovídá některému z ukázkových poznámkových bloků uvedených v dokumentaci k Databricks, upravte tento kód jako kostru.
    • minimální výzvy: V tuto chvíli vzdorujte výzvě k překonstrukci. Udržujte pokyny stručné a přímo relevantní pro vaše počáteční úkoly.
  2. Začlenit nástroje
    • integrace nástroje : Pokud používáte vzor návrhu řetězu, budou kroky volající jednotlivé nástroje pevně zakódované. V agentu volajícím nástrojem zadat schéma, aby LLM věděl, jak funkci vyvolat.
      • Před začleněním nástrojů do systému agentů a kompletním testováním ověřte, že nástroje v izolaci fungují podle očekávání.
    • Ochranné mantinely: Pokud váš agent může upravovat externí systémy nebo spouštět kód, ujistěte se, že máte základní bezpečnostní kontroly a mantinely (například omezení počtu volání nebo omezení určitých akcí). Implementujte je do funkce Unity Catalog.
  3. Trasování a protokolování agenta pomocí MLflow
    • Trasování jednotlivých kroků: Použijte trasování MLflow k zachycení vstupů, výstupů a uplynulého času pro ladění problémů a měření výkonu.
    • Zaznamenat agenta: Použijte MLflow Tracking pro zaznamenání kódu a konfigurace agenta.

V této fázi dokonalost není cílem. Chcete jednoduchého funkčního agenta, který můžete nasadit pro včasné odeslání zpětné vazby od testovacích uživatelů a msp. Dalším krokem je spuštění rychlé kontroly kvality před tím, než ji zpřístupníte v předprodukčním prostředí.

c. Kontrola kvality

Než zpřístupníte agenta širšímu předprodukčnímu publiku, spusťte před nasazením do koncového bodu kontrolu kvality v offline režimu a zachyťte všechny hlavní problémy. V této fázi obvykle nebudete mít velkou, robustní hodnotící datovou sadu, ale přesto můžete rychle analyzovat, abyste zajistili, že se agent chová podle očekávání na několika příkladech dotazů.

  1. Testovat interaktivně v poznámkovém bloku
    • Ruční testování: Ručně kontaktujte agenta s reprezentativními požadavky. Věnujte pozornost tomu, zda načítá správná data, volá nástroje správně a dodržuje požadovaný formát.
    • Kontrola trasování MLflow: Pokud jste povolili trasování MLflow, projděte si podrobnou telemetrii. Ověřte, že agent správně vybere příslušné nástroje, zpracuje chyby a negeneruje neočekávané přechodné požadavky nebo výsledky.
    • Kontrola latence: Všimněte si, jak dlouho trvá spuštění jednotlivých požadavků. Pokud jsou doby odezvy nebo využití tokenů příliš vysoké, možná budete muset před dalším pokračováním vyříznout kroky nebo zjednodušit logiku.
  2. Kontrola atmosféry
    • To lze provést buď v poznámkovém bloku, nebo v AI Playground.
    • koherence & správnosti: Dává výstup agenta smysl pro dotazy, které jste testovali? Jsou některé nepřesnosti nebo chybějící podrobnosti?
    • Hraniční případy: Pokud jste vyzkoušeli několik netradičních dotazů, reagoval agent stále logicky, nebo alespoň elegantně selhal (například zdvořile odmítnout odpověď místo generování nesmyslných odpovědí)?
    • Dodržování výzvy: Pokud jste zadali pokyny vysoké úrovně, jako je požadovaný tón nebo formátování, řídí se nimi agent?
  3. Posuďte kvalitu jako "dostatečně dobrou"
    • Pokud jste v tuto chvíli omezeni na testovací dotazy, zvažte generování syntetickýchdatch Viz Vytvoření testovací sady.
    • Řešit hlavní problémy: Pokud zjistíte závažné nedostatky (například agent opakovaně volá neplatné nástroje nebo produkuje nesmyslné výstupy), opravte tyto problémy před tím, než je předáte širší veřejnosti. Viz Běžné problémy s kvalitou a jejich řešení.
    • Rozhodnutí o životaschopnosti: Pokud agent splňuje základní řadu použitelnosti a správnosti pro malou sadu dotazů, můžete pokračovat. Pokud ne, upřesněte výzvy, opravte problémy s nástroji nebo daty a znovu otestujte.
  4. Plánování dalších kroků
    • Vylepšení sledování: Zdokumentujte jakékoli nedostatky, které se rozhodnete odložit. Jakmile shromáždíte zpětnou vazbu z reálného světa v předprodukčním prostředí, můžete se k těmto informacím vrátit.

Pokud se zdá, že jsou splněny podmínky pro realizovatelné omezené zavedení, jste připraveni nasadit softwarového agenta do předprodukčního prostředí. Důkladný proces vyhodnocení proběhne v pozdějších fázích, zejména poté, co budete mít realnější data, zpětnou vazbu k msp a strukturovanou sadu hodnocení. Prozatím se zaměřte na to, aby váš agent spolehlivě prokazoval svou základní funkčnost.

d. Nasazení předprodukčního agenta

Jakmile váš agent splňuje prahovou hodnotu základní kvality, je dalším krokem jeho hostování v předprodukčním prostředí, abyste pochopili, jak se uživatelé dotázají na aplikaci, a shromážděte zpětnou vazbu, která vás provede vývojem. Toto prostředí může být vaše vývojové prostředí během fáze POC. Hlavním požadavkem je, aby prostředí bylo přístupné pro výběr interních testerů nebo odborníků na doménu.

  1. Nasazení agenta
    • Zalogování a registrace agenta: Nejprve zalogujte agenta jako model MLflow a zaregistrujte ho v katalogu Unity.
    • Nasazení pomocí rozhraní Agent Framework: Použít Agent Framework k převzetí registrovaného agenta a jeho nasazení jako koncového bodu obsluhy modelu.
  2. odvozovací tabulky
    • Agent Framework automaticky ukládá požadavky, odpovědi a trasování spolu s metadaty v tabulce inferenční v katalogu Unity pro každý obslužný koncový bod.
  3. Zabezpečte a nakonfigurujte
    • Řízení přístupu:Omezit přístup ke koncovým bodům na vaši testovací skupinu (malé a střední podniky, power users). Tím se zajistí řízené využití a zabrání neočekávaným expozicím dat.
    • ověřování: Ověřte, že jsou správně nakonfigurované všechny požadované tajné kódy, tokeny rozhraní API nebo připojení k databázi.

Teď máte řízené prostředí pro shromažďování názorů na skutečné dotazy. Jedním ze způsobů, jak s agentem rychle pracovat, je AI Playground, kde můžete vybrat nově vytvořený koncový bod obsluhy modelu a dotazovat se na agenta.

e. Shromažďování názorů uživatelů

Po nasazení agenta do předprodukčního prostředí je dalším krokem shromáždit zpětnou vazbu od skutečných uživatelů a msp, abyste odhalili mezery, zjistili nepřesnosti a dále upřesnili svého agenta.

  1. Použijte aplikaci pro hodnocení

    • Když nasadíte agenta s Agent Framework, vytvoří se jednoduchá aplikace ve stylu chatu Recenzní aplikace. Poskytuje uživatelsky přívětivé rozhraní, kde můžou testeři klást otázky a okamžitě hodnotit odpovědi agenta.
    • Všechny žádosti, odpovědi a zpětná vazba uživatelů (palec nahoru/dolů, zapsané komentáře) se automaticky zaprotokolují do tabulky odvozování, což usnadňuje pozdější analýzu.

  2. Použití uživatelského rozhraní monitorování ke kontrole protokolů

    • Sledujte hlasy pro/hlasy proti nebo textovou zpětnou vazbu v uživatelském rozhraní pro monitorování , abyste zjistili, které odpovědi testerům přišly zvlášť užitečné (nebo neužitečné).

  3. zapojit odborníky na doménu

    • Povzbuďte MSP, aby prošla typickými i neobvyklými scénáři. Znalosti domény pomáhají vynoření drobných chyb, jako jsou chybné interpretace zásad nebo chybějící data.
    • Udržujte zásobník úkolů, od drobných úprav zadání až po refaktoring větších datových toků. Rozhodněte se, které opravy by se měly prioritizovat před tím, než se přejde dále.

  4. Kurátorovat nová hodnotící data

    • Převést významné nebo problematické interakce do testovacích případů. V průběhu času tvoří základ robustnější vyhodnocovací datové sady.
    • Pokud je to možné, přidejte do těchto případů správné nebo očekávané odpovědi. To pomáhá měřit kvalitu v následných cyklech hodnocení.

  5. Iterujte na základě zpětné vazby

    • Použijte rychlé opravy, jako jsou malé úpravy nebo nová omezení, abyste vyřešili okamžité problémy.
    • V případě složitějších problémů, jako je vyžadování pokročilé logiky s více kroky nebo nových zdrojů dat, shromážděte před investováním do velkých změn architektury dostatek důkazů.

Díky využití zpětné vazby z revizní aplikace, protokolů inferenčních tabulek a přehledů SME pomáhá tato předprodukční fáze odhalit klíčové nedostatky a iterativně vylepšovat vašeho agenta. Interakce reálného světa shromážděné v tomto kroku tvoří základ pro vytvoření strukturované sady hodnocení, která umožňuje přechod z ad hoc vylepšení na systematičtější přístup k měření kvality. Po vyřešení opakovaných problémů a stabilizaci výkonu budete dobře připraveni na produkční nasazení s robustním vyhodnocením.

2. Vyhodnoťte & iteraci

Po otestování aplikace generativní AI v předprodukčním prostředí je dalším krokem systematicky měřit, diagnostikovat a zlepšit její kvalitu. Tato fáze vyhodnocení a iterace transformuje nezpracovanou zpětnou vazbu a protokoly do strukturované sady hodnocení, což vám umožní opakovaně testovat vylepšení a zajistit, aby vaše aplikace splňovala požadované standardy pro přesnost, relevanci a bezpečnost.

Tato fáze zahrnuje následující kroky:

  • Shromážděte skutečné dotazy z protokolů: Převeďte vysoce hodnotné nebo problematické interakce z vašich odvozovacích tabulek na testovací případy.
  • Přidat popisky odborníků: Pokud je to možné, připojte k těmto případům základní pravdy nebo pokyny pro styl a zásady, abyste mohli měřit správnost, opodstatněnost a další dimenze kvality objektivněji.
  • využít vyhodnocení agentaagenta: kvantifikovat kvalitu aplikace pomocí integrovaných porotců LLM nebo vlastních kontrol.
  • Iterace: Zlepšete kvalitu upřesněním logiky, datových kanálů nebo promptů vašeho agenta. Znovu spusťte vyhodnocení a ověřte, jestli jste vyřešili klíčové problémy.

Mějte na paměti, že tyto funkce fungují i když vaše aplikace generativní AI běží mimoDatabricks. Implementací kódu pomocí MLflow trasování můžete zachytit stopy z libovolného prostředí a sjednotit je v platformě Databricks Data Intelligence pro konzistentní vyhodnocení a monitorování. S tím, jak budete dál začlenit nové dotazy, zpětnou vazbu a přehledy SME, se vaše datová sada pro vyhodnocení stane živým prostředkem, který je základem cyklu průběžného vylepšování a zajišťuje, aby aplikace AI pro gen zůstala robustní, spolehlivá a sladěná s obchodními cíli.

vývojový diagram znázorňující kroky přípravy, sestavení, nasazení a opravy

a. Vyhodnocení agenta

Po spuštění vašeho agenta v předprodukčním prostředí je dalším krokem systematicky měřit jeho výkon nad rámec neformálních kontrol. cs-CZ: Hodnocení agenta Mosaic AI umožňuje vytvářet sady hodnocení, provádět kontroly kvality s integrovanými nebo vlastními porotci LLM a rychle iterovat na problémových oblastech.

Offline a online hodnocení

Při vyhodnocování aplikací genU AI existují dva hlavní přístupy: offline vyhodnocení a online hodnocení. Tato fáze vývojového cyklu se zaměřuje na offline hodnocení, které se týká systematického hodnocení mimo interakce živých uživatelů. Online vyhodnocení se probírá později, když se budeme zabývat monitorováním agenta v produkčním prostředí.

Týmy často příliš silně spoléhají na "subjektivní posouzení atmosféry" po příliš dlouhou dobu ve vývojářském pracovním postupu, kde neformálně zkoušejí několik dotazů a jejich subjektivním hodnocením posuzují, zda odpovědi vypadají rozumně. I když to představuje výchozí bod, chybí mu rigor a pokrytí potřebné k vytváření aplikací v produkční kvalitě.

Naproti tomu správný proces offline vyhodnocení provede následující:

  • Vytvoří standardní hodnoty kvality před širším nasazením a vytvoří jasné metriky, které se mají zaměřit na zlepšení.
  • Identifikuje konkrétní slabá místa, které vyžadují pozornost a přesahují omezení testování pouze očekávaných případů použití.
  • Zjistí regrese kvality při upřesňování aplikace tím, že automaticky porovnává výkon napříč verzemi.
  • Poskytuje kvantitativní metriky k předvedení vylepšení zúčastněným stranám.
  • Pomáhá odhalit hraniční případy a potenciální režimy selhání předtím, než to uživatelé dělají.
  • Snižuje riziko nasazení neefektivního agenta do produkčního prostředí.

Investice času do offline hodnocení platí významné dividendy za dlouhou dobu, což vám pomůže zajistit konzistentně vysoce kvalitní odpovědi.

Vytvoření testovací sady

Hodnotící sada slouží jako základ pro měření výkonu vaší aplikace s generativní umělou inteligencí. Podobně jako sada testů v tradičním vývoji softwaru se tato kolekce reprezentativních dotazů a očekávaných odpovědí stává vaším srovnávacím testem kvality a regresní testovací datovou sadou.

vývojový diagram zobrazující kroky přípravy, sestavení, nasazení a opravy pomocí sady vyhodnocení

Sadu vyhodnocení můžete vytvořit prostřednictvím několika doplňkových přístupů:

  1. Převést protokoly z tabulky odvozování na příklady hodnocení

    Nejužitečnější data hodnocení pocházejí přímo z reálného využití. Vaše předprodukční nasazení vygenerovalo protokoly tabulky odvození obsahující požadavky, odpovědi agenta, volání nástrojů a načtený kontext.

    Převod těchto protokolů na sadu hodnocení nabízí několik výhod:

    • pokrytí z reálného světa: nepředvídatelné chování uživatelů, které jste možná neočekávali, je zahrnuto.
    • Zaměřený na problémy: Můžete speciálně filtrovat negativní zpětnou vazbu nebo pomalé reakce.
    • Reprezentativní distribuce: Zaznamenává se skutečná frekvence různých typů dotazů.

  2. Generování syntetických dat vyhodnocení

    Pokud nemáte kurátorovanou sadu uživatelských dotazů, můžete automaticky vygenerovat syntetickou vyhodnocovací datovou sadu. Tato úvodní sada dotazů vám pomůže rychle posoudit, jestli agent:

    • Vrátí koherentní a přesné odpovědi.
    • Reaguje ve správném formátu.
    • Respektuje strukturu, tonalitu a zásady politiky.
    • Správně načte kontext (pro RAG).

    Syntetická data obvykle nejsou dokonalá. Představte si to jako dočasný krokovací kámen. Budete také chtít:

    • Požádejte malé a střední podniky nebo odborníky na domény, aby zkontrolovali a vyřešili všechny irelevantní nebo opakované dotazy.
    • Nahraďte ho nebo rozšiřte později pomocí protokolů využití z reálného světa.

  3. Ručně upravovat dotazy

    Pokud nechcete spoléhat na syntetická data nebo ještě nemáte protokoly odvozování, identifikujte 10 až 15 skutečných nebo reprezentativních dotazů a vytvořte z nich sadu vyhodnocení. Reprezentativní dotazy můžou pocházet z uživatelských pohovorů nebo debat vývojářů. Dokonce i krátký, kurátorovaný seznam může odhalit oslňující nedostatky v odpovědích vašeho agenta.

Tyto přístupy se vzájemně nevylučují, ale doplňují. Efektivní vyhodnocovací sada se v průběhu času vyvíjí a obvykle kombinuje příklady z více zdrojů, včetně následujících:

  • Začněte s ručně kurátorovanými příklady pro testování základních funkcí.
  • Volitelně můžete přidat syntetická data, která rozšíří pokrytí, než budete mít skutečná uživatelská data.
  • Postupně začleňovat skutečné protokoly, jakmile budou k dispozici.
  • Průběžně aktualizujte pomocí nových příkladů, které odrážejí změny vzorů použití.
Osvědčené postupy pro vyhodnocovací dotazy

Při vytváření testovací sady záměrně zahrňte různé typy dotazů, jako jsou například následující:

  • Očekávané i neočekávané vzory použití (například velmi dlouhé nebo krátké požadavky)
  • Potenciální pokusy o zneužití nebo útoky prostřednictvím injekce příkazů (například pokusy o odhalení systémového příkazu)
  • Složité dotazy vyžadující několik kroků zdůvodnění nebo volání nástrojů
  • Hraniční případy s minimálními nebo nejednoznačnými informacemi (jako jsou chybně napsané nebo vágní dotazy).
  • Příklady představující různé úrovně dovedností a pozadí uživatelů
  • Dotazy, které testují potenciální předsudky v odpovědích (například "compare Company A vs Company B").

Nezapomeňte, že vaše testovací sada by se měla rozšiřovat a vyvíjet společně s vaší aplikací. Když odhalíte nové režimy selhání nebo chování uživatelů, přidejte reprezentativní příklady, abyste zajistili, že se váš agent bude v těchto oblastech dál vylepšovat.

Přidání kritérií hodnocení

Každý příklad hodnocení by měl mít kritéria pro vyhodnocení kvality. Tato kritéria slouží jako standardy, proti kterým se měří odpovědi agenta, což umožňuje objektivní vyhodnocení ve více dimenzích kvality.

Základní pravdivá fakta nebo referenční odpovědi

Při vyhodnocování přesnosti faktů existují dva hlavní přístupy: očekávané skutečnosti nebo referenční odpovědi. Každý z nich má ve vaší strategii vyhodnocení jiný účel.

Použít očekávaná fakta (doporučeno)

Přístup expected_facts zahrnuje výpis klíčových faktů, které by se měly objevit ve správné odpovědi. Příklad viz Ukázková sada hodnocení s request, response, guidelinesa expected_facts.

Tento přístup nabízí významné výhody:

  • Umožňuje flexibilitu ve způsobu vyjádření faktů v odpovědi.
  • Usnadňuje MSP poskytování skutečných dat.
  • Přizpůsobí se různým stylům odpovědí a zároveň zajistí, že základní informace jsou přítomny.
  • Umožňuje spolehlivější vyhodnocení napříč verzemi modelu nebo nastavením parametrů.

Vestavěný posuzovatel správnosti kontroluje, zda odpověď agenta zahrnuje tato základní fakta, nezávisle na formulaci, pořadí či doplňkovém obsahu.

Použít očekávanou odpověď (alternativní)

Alternativně můžete poskytnout úplnou referenční odpověď. Tento přístup funguje nejlépe v následujících situacích:

  • Máte zlaté standardní odpovědi vytvořené odborníky.
  • Na přesném znění nebo struktuře odpovědi záleží.
  • Vyhodnocujete odpovědi v vysoce regulovaných kontextech.

Databricks obecně doporučuje používat expected_facts přes expected_response, protože poskytuje větší flexibilitu a současně zajišťuje přesnost.

Pokyny pro dodržování stylu, tónu nebo zásad

Kromě faktické přesnosti možná budete muset vyhodnotit, jestli odpovědi splňují konkrétní styl, tón nebo požadavky zásad.

Pouze pokyny

Pokud vaše hlavní obava vynucuje požadavky na styl nebo zásady místo faktické přesnosti, můžete poskytnout pokyny bez očekávaných faktů:

# Per-query guidelines
eval_row = {
    "request": "How do I delete my account?",
    "guidelines": {
        "tone": ["The response must be supportive and non-judgmental"],
        "structure": ["Present steps chronologically", "Use numbered lists"]
    }
}

# Global guidelines (applied to all examples)
evaluator_config = {
    "databricks-agent": {
        "global_guidelines": {
            "rudeness": ["The response must not be rude."],
            "no_pii": ["The response must not include any PII information (personally identifiable information)."]
        }
    }
}

Soudce LLM interpretuje tyto instrukce v přirozeném jazyce a posoudí, zda odpověď vyhovuje. To funguje zvlášť dobře pro subjektivní dimenze kvality, jako je tón, formátování a dodržování organizačních zásad.

Rozhraní LLM pro posuzování stylu a tónu.

Kombinování základní pravdy a pokynů

Pro komplexní vyhodnocení můžete kombinovat kontroly faktické přesnosti s pokyny pro styl. Viz Ukázková vyhodnocovací sada s request, response, guidelinesa expected_facts. Tento přístup zajišťuje, že odpovědi jsou fakticky přesné a dodržují komunikační standardy vaší organizace.

Použití předem zachycených odpovědí

Pokud jste už zachytili páry požadavků a odpovědí z vývoje nebo testování, můžete je vyhodnotit přímo bez opětovného vyvolání agenta. To je užitečné pro:

  • Analýza existujících vzorů v chování agenta
  • Srovnávací testy výkonu oproti předchozím verzím
  • Úspora času a nákladů tím, že neregeneruje odpovědi.
  • Vyhodnocení agenta provozovaného mimo Databricks.

Podrobnosti o poskytování relevantních sloupců ve vyhodnocovacím datovém rámci najdete v části Příklad: Jak předat dříve generované výstupy do hodnocení agenta. Funkce Hodnocení agenta pro platformu Mosaic AI používá tyto předem zachycené hodnoty místo opětovného volání agenta a přitom stále používá stejné kontroly kvality a metriky.

Osvědčené postupy pro kritéria hodnocení

Při definování kritérií hodnocení:

  1. Být specifický a objektivní: Definovat jasná měřitelná kritéria, která by různí vyhodnocovače interpretovaly podobně.
    • Zvažte přidání vlastních metrik pro měření kritérií kvality, na které vám záleží.
  2. Zaměřit se na hodnotu uživatele: Určit prioritu kritérií, která odpovídají tomu, co je pro vaše uživatele nejdůležitější.
  3. Začít jednoduše: Začněte základní sadou kritérií a rozšiřte své znalosti potřeb kvality.
  4. Rozsah vyváženosti: Zahrnout kritéria, která řeší různé aspekty kvality (například faktická správnost, styl a bezpečnost).
  5. iterovat na základě zpětné vazby: Upřesnit kritéria na základě zpětné vazby uživatelů a vyvíjejících se požadavků.

Další informace o vytváření vysoce kvalitních datových sad hodnocení najdete v tématu Osvědčené postupy pro vývoj sady hodnocení.

Spuštění vyhodnocení

Teď, když jste připravili sadu hodnocení s dotazy a kritérii, můžete spustit vyhodnocení pomocí mlflow.evaluate(). Tato funkce zpracovává celý proces vyhodnocení, od vyvolání agenta až po analýzu výsledků.

Základní pracovní postup vyhodnocení

Spuštění základního vyhodnocení vyžaduje jenom několik řádků kódu. Podrobnosti najdete v tématu Spuštění zkušebního.

Při spuštění vyhodnocení:

  1. Pro každý řádek v sadě vyhodnocení mlflow.evaluate() provede následující:
    • Zavolá vašemu agentovi s dotazem (pokud jste dosud neodpověděli).
    • Použije předdefinované porotce LLM k posouzení dimenzí kvality.
    • Vypočítá provozní metriky, jako je využití tokenu a latence.
    • Zaznamenává podrobná odůvodnění pro každé posouzení.
  2. Výsledky se automaticky protokolují do MLflow, čímž se vytvářejí:
    • Hodnocení kvality pro jednotlivé řádky
    • Agregované metriky napříč všemi příklady
    • Podrobné protokoly pro ladění a analýzu

LLM uživatelské rozhraní soudce zobrazující hodnocení soudce.

Přizpůsobit vyhodnocení

Vyhodnocení můžete přizpůsobit vašim konkrétním potřebám pomocí dalších parametrů. Parametr evaluator_config umožňuje provést následující akce:

  • Vyberte, které vestavěné posuzovatele chcete spustit.
  • Nastavte globální pokyny, které platí pro všechny příklady.
  • Nakonfigurujte prahové hodnoty pro soudce.
  • Poskytněte několik příkladů k usnadnění hodnocení soudce.

Podrobnosti a příklady najdete v tématu Příklady.

Vyhodnocení agentů mimo Databricks

Jednou z výkonných funkcí vyhodnocení agenta je schopnost vyhodnocovat aplikace generativní umělé inteligence nasazené kdekoli, nejen na Databricks.

Kteří soudci jsou zapojeni

Ve výchozím nastavení hodnocení agenta automaticky vybere příslušné posuzovatele LLM na základě dat dostupných ve vaší sadě hodnocení. Podrobnosti o posouzení kvality najdete v tématu Jak je kvalita hodnocena porotci LLM.

Analýza výsledků vyhodnocení

Po spuštění vyhodnocení poskytuje uživatelské rozhraní MLflow vizualizace a přehledy, které vám porozumí výkonu vaší aplikace. Tato analýza vám pomůže identifikovat vzory, diagnostikovat problémy a určit prioritu vylepšení.

Když po spuštění mlflow.evaluate(), otevřete uživatelské rozhraní MLflow, najdete několik propojených zobrazení. Informace o tom, jak tyto výsledky procházet v uživatelském rozhraní MLflow, najdete v tématu Kontrola výstupu pomocí uživatelského rozhraní MLflow.

Pokyny k interpretaci vzorů selhání najdete v tématu b. Vylepšení agenta a nástrojů.

Přizpůsobená AI hodnotí metriky &

I když předdefinované soudce pokrývají řadu běžných kontrol (například správnost, styl, zásady a bezpečnost), možná budete muset vyhodnotit aspekty výkonu vaší aplikace specifické pro doménu. Vlastní poroty a metriky umožňují rozšířit možnosti vyhodnocení tak, aby řešily vaše jedinečné požadavky na kvalitu.

vlastní porotci LLM

Podrobnosti o tom, jak vytvořit vlastního soudce LLM z výzvy, najdete v tématu Vytvoření porotců umělé inteligence z výzvy.

Vlastní porotci vynikají při vyhodnocování subjektivních nebo nuanovaných dimenzí kvality, které mají prospěch z lidského úsudku, například:

  • Dodržování předpisů specifických pro doménu (právní, lékařské, finanční).
  • Hlas značky a komunikační styl.
  • Kulturní citlivost a vhodnost.
  • Složitá kvalita zdůvodnění.
  • Specializované konvence psaní.

Výstup soudce se zobrazí v uživatelském rozhraní MLflow společně s integrovanými porotci se stejnými podrobnými odůvodněními, které vysvětlují hodnocení.

vlastní metriky

Pro další programová deterministická posouzení můžete vytvořit vlastní metriky pomocí @metric dekorátoru. Viz @metric dekorátor.

Vlastní metriky jsou ideální pro:

  • Ověření technických požadavků, jako je ověřování formátu a soulad se schématem.
  • Kontrola přítomnosti nebo nepřítomnosti konkrétního obsahu
  • Provádění kvantitativních měření, jako je délka odpovědi nebo skóre složitosti.
  • Implementace ověřovacích pravidel specifických pro firmy
  • Integrace s externími systémy ověřování

b. Vylepšení agenta a nástrojů

Po spuštění vyhodnocení a identifikaci problémů s kvalitou je dalším krokem systematicky řešit tyto problémy, aby se zlepšil výkon. Výsledky vyhodnocení poskytují cenné přehledy o tom, kde a jak váš agent selhává, což vám umožní provádět cílená vylepšení místo náhodných úprav.

běžné problémy s kvalitou a jejich řešení

Hodnocení porotců LLM z vašich výsledků vyhodnocení ukazuje na konkrétní typy selhání ve vašem agentním systému. Tato část se zabývá těmito běžnými vzory selhání a jejich řešeními. Informace o tom, jak interpretovat výstupy soudce LLM, najdete v tématu výstupy soudce AI.

Osvědčené postupy iterace kvality

Při iteraci na vylepšeních udržujte důkladnou dokumentaci. Například:

  1. Vytvořte verzi svých změn
    • Protokolujte každou významnou iteraci pomocí sledování MLflow.
    • Uložte výzvy, konfigurace a parametry klíče v centrálním konfiguračním souboru. Ujistěte se, že je to zaznamenáno agentem.
    • U každého nového nasazeného agenta udržujte v úložišti protokol změn s podrobnostmi o tom, co se změnilo a proč.
  2. zdokumentovat, co fungovalo a nefungovalo
    • Zdokumentuje úspěšné i neúspěšné přístupy.
    • Všimněte si konkrétního dopadu každé změny na metriky. Odkazovat zpět k běhu MLflow pro vyhodnocování agenta.
  3. sladění se zúčastněnými stranami
    • Pomocí aplikace Review App ověřte vylepšení u msp.
      • Oznamte změny recenzentům pomocí pokynů pro recenzenty .
    • Pro souběžné porovnání různých verzí agenta zvažte vytvoření více koncových bodů agenta a použití modelu v AI Playground. To uživatelům umožňuje odeslat stejný požadavek do samostatných koncových bodů a prozkoumat odpověď a trasování vedle sebe.

3. Výroba

Po iterativním vyhodnocení a vylepšování aplikace jste dosáhli úrovně kvality, která splňuje vaše požadavky a je připravená k širšímu použití. Fáze výroby zahrnuje nasazení zpřesněného agenta do produkčního prostředí a implementaci průběžného monitorování, aby se zachovala kvalita v průběhu času.

Fáze výroby zahrnuje:

  • Nasazení agenta do produkčního prostředí: Nastavení koncového bodu připraveného pro produkční prostředí s odpovídajícím nastavením zabezpečení, škálování a ověřování.
  • Monitorování agenta v produkčním prostředí: Zajištění nepřetržitého hodnocení kvality, sledování výkonu a upozorňování, aby váš agent zachoval vysokou kvalitu a spolehlivost v reálném světě.

Tím se vytvoří smyčka nepřetržité zpětné vazby, kde monitorování přehledů řídí další vylepšení, která můžete testovat, nasazovat a dál monitorovat. Tento přístup zajišťuje, aby vaše aplikace zůstala vysoce kvalitní, vyhovující a v souladu s vyvíjejícími se obchodními potřebami během celého životního cyklu.

Vývojový diagram znázorňující celý pracovní postup vývoje generativní AI, včetně monitorování a protokolů.

a. Nasazení agenta do produkčního prostředí

Po dokončení důkladného vyhodnocení a iterativního vylepšení jste připraveni nasadit agenta do produkčního prostředí. [Rámec agentů AI Mosaic](/generative-ai/agent-framework/build-gen AI-apps.md#agent-framework) zjednodušuje tento proces automatickým řešením mnoha problematik nasazení.

Proces nasazení

Nasazení agenta do produkčního prostředí zahrnuje následující kroky:

  1. Zalogovat a zaregistrovat svého agenta jako Model MLflow v katalogu Unity.
  2. nasazení agenta pomocí rozhraní Agent Framework.
  3. Nakonfigurujte ověřování pro všechny závislé prostředky, váš agent potřebuje přístup.
  4. Otestujte nasazení a ověřte funkčnost v produkčním prostředí.
    • Jakmile je koncový bod obsluhy modelu připravený, můžete s agentem pracovat v AI Playground, kde můžete otestovat a ověřit funkčnost.

Podrobné kroky implementace najdete v tématu Nasazení agenta pro generování aplikací AI.

Důležité informace o nasazení v produkčním prostředí

Při přechodu na produkční prostředí mějte na paměti následující klíčové aspekty:

výkon a škálování

  • Vyrovnejte náklady a výkon na základě očekávaných vzorů využití.
  • Zvažte aktivaci funkce škálování na nulu pro občas používané agenty, aby se snížily náklady.
  • Seznamte se s požadavky na latenci na základě potřeb uživatelů vaší aplikace.

zabezpečení a řízení

  • Zajistěte správné řízení přístupu na úrovni katalogu Unity pro všechny komponenty agenta.
  • Pokud je to možné, použijte integrované předávací ověřování pro prostředky Databricks.
  • Nakonfigurujte odpovídající správu přihlašovacích údajů pro externí rozhraní API nebo zdroje dat.

přístup k integraci

  • Určete, jak bude vaše aplikace komunikovat s agentem (například pomocí rozhraní API nebo vloženého rozhraní).
  • Zvažte, jak zpracovávat a zobrazovat odpovědi agenta ve vaší aplikaci.
    • Pokud klientská aplikace potřebuje další kontext (například odkazy na zdrojový dokument nebo skóre spolehlivosti), navrhněte agentovi, aby do odpovědí zahrnul tato metadata (například pomocí vlastních výstupů).
  • Plánování zpracování chyb a záložních mechanismů pro nedostupnost agenta

kolekce Feedback

  • Využijte aplikaci Review App pro zpětnou vazbu účastníků během počátečního uvedení.
  • Mechanismy návrhu pro shromažďování zpětné vazby uživatelů přímo v rozhraní vaší aplikace
  • Zajistěte tok dat zpětné vazby do procesu vyhodnocení a zlepšování.

b. Monitorování agenta v produkčním prostředí

Po nasazení agenta do produkčního prostředí je nezbytné nepřetržitě monitorovat jeho výkon, kvalitu a vzory použití. Na rozdíl od tradičního softwaru, kde je funkce deterministické, můžou aplikace umělé inteligence genu vykazovat kvalitní posun nebo neočekávané chování, když narazí na skutečné vstupy. Efektivní monitorování umožňuje včas detekovat problémy, porozumět vzorům použití a průběžně zlepšovat kvalitu vaší aplikace.

Nastavení monitorování agenta

Mosaic AI poskytuje integrované monitorovací možnosti , které umožňují sledovat výkon vašeho agenta bez potřeby budování vlastní monitorovací infrastruktury.

  1. vytvořte monitor pro nasazeného agenta.
  2. Nakonfigurujte vzorkovací frekvenci a frekvenci na základě potřeb objemu provozu a monitorování.
  3. Vyberte metriky kvality, abyste mohli automaticky vyhodnotit vzorkované požadavky.

Klíčové dimenze monitorování

Obecně platí, že účinné monitorování by mělo zahrnovat tři kritické dimenze:

  1. provozní metriky

    • Požadovaný objem a vzory
    • Latence odpovědi
    • Míry chyb a typy
    • Využití a náklady na tokeny

  2. metriky kvality

    • Relevance pro dotazy uživatelů
    • Zakotvení ve zjištěném kontextu.
    • Bezpečnost a dodržování zásad.
    • Celková míra úspěšnosti.

  3. zpětné vazby uživatelů

    • Explicitní zpětná vazba (palec nahoru/dolů)
    • Implicitní signály (následné otázky, opuštěné konverzace)
    • Problémy nahlášené v kanálech podpory

Použití uživatelského rozhraní monitorování

Monitorovací rozhraní poskytuje vizualizované přehledy napříč těmito dimenzemi prostřednictvím dvou karet.

  • karta Grafy: Umožňuje zobrazit trendy v objemu požadavků, metrikách kvality, latenci a chybách v průběhu času.
  • záložku Protokoly: Prozkoumejte jednotlivé požadavky a odpovědi, včetně výsledků jejich vyhodnocení.

Možnosti filtrování umožňují uživatelům vyhledávat konkrétní dotazy nebo filtrovat podle výsledku vyhodnocení. Další informace naleznete v tématu Použití uživatelského rozhraní monitorování.

Vytváření řídicích panelů a upozornění

Komplexní monitorování:

  • Vytvářejte vlastní řídicí panely s využitím monitorovacích dat uložených v tabulce vyhodnocených tras.
  • Nastavení upozornění pro kritickou kvalitu nebo provozní prahové hodnoty.
  • Naplánovat pravidelné kontroly kvality s klíčovými zúčastněnými stranami.

Cyklus průběžného zlepšování

Monitorování je nejužitečnější, když se vrací zpět do procesu zlepšování:

  1. Identifikace problémů prostřednictvím monitorování metrik a zpětné vazby uživatelů.
  2. export problematických příkladů do testovací sady.
  3. Diagnostikovat hlavní příčiny pomocí sledování MLflow a výsledků posouzení LLM (jak je popsáno v běžných problémech s kvalitou a jejich řešení).
  4. vyvíjet a testovat vylepšení proti vaší rozšířené sadě hodnocení.
  5. Nasadit aktualizace a sledovat dopad.

Tento iterativní přístup uzavřených smyček pomáhá zajistit, aby se váš agent dál vylepšovat na základě vzorů využití reálného světa, zachoval vysokou kvalitu a zároveň se přizpůsobil měnícím se požadavkům a chování uživatelů. Díky monitorování agentů získáte přehled o výkonu vašeho agenta v produkčním prostředí, abyste mohli aktivně řešit problémy a optimalizovat kvalitu a výkon.