Odvozování tabulek pro monitorování a ladění modelů
Důležité
Tato funkce je ve verzi Public Preview.
Tento článek popisuje tabulky odvozování pro monitorování obsluhovaných modelů. Následující diagram znázorňuje typický pracovní postup s odvozovacími tabulkami. Tabulka odvozování automaticky zaznamenává příchozí požadavky a odchozí odpovědi pro model obsluhující koncový bod a protokoluje je jako tabulku Delta katalogu Unity. Data v této tabulce můžete použít k monitorování, ladění a vylepšování modelů ML.
U modelů obsluhujících koncové body, které hostují externí modely, můžete tabulky odvozování povolit pouze pomocí brány AI.
Co jsou tabulky odvození?
Monitorování výkonu modelů v produkčních pracovních postupech je důležitým aspektem životního cyklu modelu AI a ML. Odvozování tabulek zjednodušuje monitorování a diagnostiku modelů průběžným protokolováním obsluhující vstupy a odpovědi požadavků (předpovědi) z koncových bodů obsluhy modelu Mosaic AI a jejich uložením do tabulky Delta v katalogu Unity. K monitorování, ladění a optimalizaci modelů pak můžete použít všechny možnosti platformy Databricks, jako jsou dotazy Sql Databricks, poznámkové bloky a monitorování Lakehouse.
Tabulky odvozování můžete povolit u libovolného existujícího nebo nově vytvořeného modelu obsluhujícího koncový bod a požadavky na tento koncový bod se pak automaticky zaprotokolují do tabulky v UC.
Mezi běžné aplikace pro odvozování tabulek patří:
- Monitorování kvality dat a modelu Pomocí monitorování Lakehouse můžete průběžně monitorovat výkon modelu a odchylky dat. Monitorování Lakehouse automaticky generuje řídicí panely kvality dat a modelů, které můžete sdílet se zúčastněnými stranami. Kromě toho můžete upozornění povolit, abyste věděli, kdy potřebujete model přetrénovat na základě posunů v příchozích datech nebo snížení výkonu modelu.
- Ladění produkčních problémů Odvozování dat protokolů tabulek, jako jsou stavové kódy HTTP, doby provádění modelu a kód JSON požadavku a odpovědi. Tato data o výkonu můžete použít pro účely ladění. Historická data v tabulkách odvozování můžete použít také k porovnání výkonu modelu u historických požadavků.
- Vytvořte trénovací korpus. Spojením odvozovacích tabulek s popisky základní pravdy můžete vytvořit trénovací korpus, který můžete použít k opětovnému trénování nebo vyladění a vylepšení modelu. Pomocí úloh Databricks můžete nastavit nepřetržitou smyčku zpětné vazby a automatizovat opakované trénování.
Požadavky
- Váš pracovní prostor musí mít povolený katalog Unity.
- Autor koncového bodu i modifikátor musí mít oprávnění Může spravovat koncový bod. Viz seznamy řízení přístupu.
- Tvůrce koncového bodu i modifikátor musí mít v katalogu Unity následující oprávnění :
USE CATALOG
oprávnění k zadanému katalogu.USE SCHEMA
oprávnění k zadanému schématu.CREATE TABLE
oprávnění ve schématu.
Povolení a zakázání odvozovacích tabulek
V této části se dozvíte, jak povolit nebo zakázat tabulky odvozování pomocí uživatelského rozhraní Databricks. Můžete také použít rozhraní API; Pokyny najdete v tématu Povolení odvozovacích tabulek v modelech obsluhujících koncové body pomocí rozhraní API .
Vlastníkem tabulek odvozování je uživatel, který koncový bod vytvořil. Všechny seznamy řízení přístupu (ACL) v tabulce se řídí standardními oprávněními katalogu Unity a může je upravit vlastník tabulky.
Upozorňující
Tabulka odvozování může být poškozena, pokud provedete některou z následujících věcí:
- Změňte schéma tabulky.
- Změňte název tabulky.
- Odstraňte tabulku.
- Ztratí oprávnění ke katalogu nebo schématu Unity.
V tomto případě auto_capture_config
stav koncového bodu zobrazuje FAILED
stav tabulky datové části. Pokud k tomu dojde, musíte vytvořit nový koncový bod, abyste mohli dál používat odvozovací tabulky.
K povolení odvozovacích tabulek během vytváření koncového bodu použijte následující postup:
Klikněte na Obsluha v uživatelském rozhraní Databricks Mosaic AI.
Klikněte na Vytvořit koncový bod obsluhy.
Vyberte Povolit odvozovací tabulky.
V rozevíracích nabídkách vyberte požadovaný katalog a schéma, ve kterém se má tabulka nacházet.
Výchozí název tabulky je
<catalog>.<schema>.<endpoint-name>_payload
. V případě potřeby můžete zadat vlastní předponu tabulky.Klikněte na Vytvořit koncový bod obsluhy.
U existujícího koncového bodu můžete také povolit odvozovací tabulky. Pokud chcete upravit existující konfiguraci koncového bodu, postupujte takto:
- Přejděte na stránku koncového bodu.
- Klikněte na Upravit konfiguraci.
- Postupujte podle předchozích pokynů počínaje krokem 3.
- Až budete hotovi, klikněte na Aktualizovat obsluhující koncový bod.
Podle těchto pokynů zakažte odvozovací tabulky:
- Přejděte na stránku koncového bodu.
- Klikněte na Upravit konfiguraci.
- Zaškrtnutí odeberete kliknutím na Povolit odvozovací tabulku .
- Jakmile budete s specifikacemi koncového bodu spokojeni, klikněte na Tlačítko Aktualizovat.
Pracovní postup: Monitorování výkonu modelu pomocí odvozovacích tabulek
Pokud chcete monitorovat výkon modelu pomocí odvozovacích tabulek, postupujte takto:
- Povolte u koncového bodu tabulky odvozování, a to buď během vytváření koncového bodu, nebo jejich následnou aktualizací.
- Naplánujte pracovní postup pro zpracování datových částí JSON v tabulce odvozování tak, že je rozbalíte podle schématu koncového bodu.
- (Volitelné) Připojte se k rozbaleným požadavkům a odpovědím s popisky základní pravdy, abyste umožnili výpočet metrik kvality modelu.
- Vytvořte monitorování nad výslednou tabulkou Delta a aktualizujte metriky.
Úvodní poznámkové bloky implementují tento pracovní postup.
Úvodní poznámkový blok pro monitorování tabulky odvozování
Následující poznámkový blok implementuje výše uvedené kroky k rozbalení požadavků z tabulky odvozování monitorování Lakehouse. Poznámkový blok můžete spustit na vyžádání nebo podle plánu opakování pomocí úloh Databricks.
Úvodní poznámkový blok odvozovací tabulky Lakehouse Monitoring
Úvodní poznámkový blok pro monitorování kvality textu z koncových bodů obsluhujících LLM
Následující poznámkový blok rozbalí požadavky z tabulky odvozování, vypočítá sadu metrik vyhodnocení textu (například čitelnost a toxicitu) a umožňuje monitorování těchto metrik. Poznámkový blok můžete spustit na vyžádání nebo podle plánu opakování pomocí úloh Databricks.
Úvodní poznámkový blok pro odvození tabulky LLM Lakehouse Monitoring
Dotazování a analýza výsledků v tabulce odvozování
Jakmile budou vaše obsluhované modely připravené, všechny požadavky provedené na vašich modelech se automaticky zaprotokolují do tabulky odvozování spolu s odpověďmi. Tabulku můžete zobrazit v uživatelském rozhraní, dotazovat se na tabulku z DBSQL nebo poznámkového bloku nebo dotazovat tabulku pomocí rozhraní REST API.
Pokud chcete zobrazit tabulku v uživatelském rozhraní: Na stránce koncového bodu kliknutím na název tabulky odvozování otevřete tabulku v Průzkumníku katalogu.
Dotazování tabulky z DBSQL nebo poznámkového bloku Databricks: Můžete spustit kód podobný následujícímu dotazu na tabulku odvozování.
SELECT * FROM <catalog>.<schema>.<payload_table>
Pokud jste povolili odvozovací tabulky pomocí uživatelského rozhraní, je název tabulky, payload_table
který jste přiřadili při vytváření koncového bodu. Pokud jste povolili odvozování tabulek pomocí rozhraní API, payload_table
zobrazí se v state
části auto_capture_config
odpovědi. Příklad najdete v tématu Povolení tabulek odvozování u modelů obsluhujících koncové body pomocí rozhraní API.
Poznámka k výkonu
Po vyvolání koncového bodu se během hodiny od odeslání žádosti o bodování zobrazí volání zaprotokolované do tabulky odvozování. Kromě toho Azure Databricks zaručuje doručení protokolů alespoň jednou, takže je možné, i když je nepravděpodobné, že se odesílají duplicitní protokoly.
Schéma odvozovací tabulky katalogu Unity
Každý požadavek a odpověď, které se zaprotokolují do odvozovací tabulky, se zapisují do tabulky Delta s následujícím schématem:
Poznámka:
Pokud vyvoláte koncový bod s dávkou vstupů, zaprotokoluje se celá dávka jako jeden řádek.
Název sloupce | Popis | Typ |
---|---|---|
databricks_request_id |
Identifikátor požadavku vygenerovaný službou Azure Databricks připojený ke všem žádostem obsluhující model | STRING |
client_request_id |
Volitelný identifikátor požadavku vygenerovaný klientem, který lze zadat v modelu obsluhující tělo požadavku. Další informace najdete v tématu Zadání client_request_id . |
STRING |
date |
Datum UTC, kdy byl přijat požadavek obsluhující model. | DATE |
timestamp_ms |
Časové razítko v epoch milisekundách, kdy byl přijat požadavek obsluhující model. | DLOUHÝ |
status_code |
Stavový kód HTTP vrácený z modelu. | INT |
sampling_fraction |
Zlomek vzorkování použitý v případě, že byl požadavek mimo vzorkování. Tato hodnota je mezi 0 a 1, kde 1 představuje, že bylo zahrnuto 100 % příchozích požadavků. | DVOJITÝ |
execution_time_ms |
Doba provádění v milisekundách, pro kterou model provedl odvozování. Nezahrnuje latence sítě s režií a představuje pouze dobu, kterou model trvalo generování předpovědí. | DLOUHÝ |
request |
Nezpracovaný text JSON požadavku, který byl odeslán do koncového bodu obsluhy modelu. | STRING |
response |
Nezpracovaný text JSON odpovědi vrácený koncovým bodem obsluhy modelu. | STRING |
request_metadata |
Mapa metadat souvisejících s koncovým bodem obsluhující model přidružený k požadavku Tato mapa obsahuje název koncového bodu, název modelu a verzi modelu používanou pro váš koncový bod. | MAPOVACÍ<ŘETĚZEC, ŘETĚZEC> |
Specifikovat client_request_id
Pole client_request_id
je volitelná hodnota, kterou může uživatel zadat v modelu obsluhující tělo požadavku. To uživateli umožní zadat vlastní identifikátor požadavku, který se zobrazí v poslední tabulce odvozování pod client_request_id
tabulkou a může být použit pro připojení k vaší žádosti s jinými tabulkami, které používají client_request_id
popisek , jako je například připojení základního popisku pravdy. Pokud chcete zadat klíč client_request_id
datové části požadavku, zahrňte ho jako klíč nejvyšší úrovně. Pokud není zadána žádná client_request_id
hodnota, zobrazí se hodnota v řádku odpovídajícím požadavku jako null.
{
"client_request_id": "<user-provided-id>",
"dataframe_records": [
{
"sepal length (cm)": 5.1,
"sepal width (cm)": 3.5,
"petal length (cm)": 1.4,
"petal width (cm)": 0.2
},
{
"sepal length (cm)": 4.9,
"sepal width (cm)": 3,
"petal length (cm)": 1.4,
"petal width (cm)": 0.2
},
{
"sepal length (cm)": 4.7,
"sepal width (cm)": 3.2,
"petal length (cm)": 1.3,
"petal width (cm)": 0.2
}
]
}
Později client_request_id
lze použít pro uzemněné spojení popisků pravdy, pokud existují jiné tabulky, které mají přidružené popisky client_request_id
.
Omezení
- Klíče spravované zákazníkem se nepodporují.
- U koncových bodů, které hostují základní modely, jsou tabulky odvozování podporovány pouze u úloh zřízené propustnosti .
- Azure Firewall může způsobit selhání vytvoření tabulky Unity Catalog Delta, takže se ve výchozím nastavení nepodporuje. Spojte se s týmem účtu Databricks a povolte ho.
- Pokud jsou tabulky odvozování povolené, je limit maximální souběžnosti napříč všemi obsluhované modely v jednom koncovém bodu 128. Spojte se s týmem účtu Azure Databricks a požádejte o zvýšení tohoto limitu.
- Pokud tabulka odvozování obsahuje více než 500 tisíc souborů, nebudou zaprotokolována žádná další data. Pokud se chcete vyhnout překročení tohoto limitu, spusťte optimalizaci nebo nastavte uchovávání dat v tabulce odstraněním starších dat. Pokud chcete zkontrolovat počet souborů v tabulce, spusťte
DESCRIBE DETAIL <catalog>.<schema>.<payload_table>
příkaz . - Doručování protokolů odvozování tabulek je v současné době co nejlepší, ale můžete očekávat, že protokoly budou dostupné do 1 hodiny od požadavku. Další informace získáte od týmu účtu Databricks.
Obecná omezení koncového bodu obsluhy modelu najdete v tématu Omezení a oblasti obsluhy modelů.