Inference tables pro monitorování a ladění modelů

Důležité

Tato funkce je ve verzi Public Preview.

Důležité

Tento článek popisuje témata, která se týkají inference tables pro vlastní modely . Pro externí modely nebo úlohy se zřízenou propustností použijte bránu AI s podporou pro inference tables.

Tento článek popisuje odvozování tables pro monitorování obsluhovaných modelů. Následující diagram znázorňuje typický pracovní postup s odvozováním tables. Odvozování table automaticky zaznamenává příchozí požadavky a odchozí odpovědi pro koncový bod obsluhující model a protokoluje je jako Unity Catalog Delta table. Data v tomto table můžete použít k monitorování, ladění a vylepšování modelů ML.

Co jsou inference tables?

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. Inference tables zjednodušuje monitorování a diagnostiku modelů průběžným zaznamenáváním vstupů požadavků a odpovědí (předpovědí) z koncových bodů modelové služby Mosaic AI a jejich uložením do Delta table v Unity Catalog. Pak můžete využít všechny možnosti platformy Databricks, jako jsou dotazy Databricks SQL, poznámkové bloky a monitorování Lakehouse, k monitorování, ladění a optimize vašich modelů.

Můžete povolit odvozování tables u jakéhokoli 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 table v UC.

Mezi běžné aplikace pro odvozování tables 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ů Interpretace protokolových dat Tables, jako jsou stavové kódy HTTP, doby provádění modelu a JSON kód požadavků a odpovědí. Tato data o výkonu můžete použít pro účely ladění. K porovnání výkonu modelu u historických požadavků můžete použít také historická data v odvozování Tables.
• Vytvořte trénovací korpus. Spojením odvozování Tables 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 set kontinuální smyčku zpětné vazby a automatizovat opakované trénování.

Požadavky

• Váš pracovní prostor musí mít povolenou Catalog 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átoru musí mít následující oprávnění v Unity Catalog:
  • USE CATALOG oprávnění k zadanému catalog.
  • USE SCHEMA oprávnění k zadanému schema.
  • CREATE TABLE oprávnění v schema.

Povolení a zakázání tables odvození

V této části se dozvíte, jak povolit nebo zakázat odvozování tables pomocí uživatelského rozhraní Databricks. Můžete také použít rozhraní API; Pokyny najdete v tématu Povolení tables odvozování u koncových bodů obsluhujících model pomocí rozhraní API.

Vlastníkem odvozování tables je uživatel, který koncový bod vytvořil. Všechny seznamy řízení přístupu (ACL) na table se řídí standardními oprávněními Catalog Unity a mohou být upraveny vlastníkem table.

Upozorňující

Pokud provedete některou z následujících akcí, může dojít k poškození závěru table:

• Změňte tableschema.
• Změňte název table.
• Odstraňte table.
• Ztratíte oprávnění k Unity Catalog,catalog nebo schema.

V tomto případě stav koncového bodu auto_capture_config ukazuje stav FAILED pro datovou část table. Pokud k tomu dojde, musíte vytvořit nový koncový bod, abyste mohli dál používat odvození tables.

Pokud chcete povolit odvození tables během vytváření koncového bodu, postupujte následovně:

1. Klikněte na Obsluha v uživatelském rozhraní Databricks Mosaic AI.

2. Klikněte na Vytvořit koncový bod obsluhy.

3. Select Povolit inferenci tables.

4. V rozevíracích nabídkách select požadované catalog a schemawhere chcete, aby se table nacházela.

   

5. Výchozí název table je <catalog>.<schema>.<endpoint-name>_payload. V případě potřeby můžete zadat vlastní předponu table.

6. Klikněte na Vytvořit koncový bod obsluhy.

Také můžete povolit inferenci tables na stávajícím koncovém bodu. Pokud chcete upravit existující konfiguraci koncového bodu, postupujte takto:

1. Přejděte na stránku koncového bodu.
2. Klikněte na Upravit konfiguraci.
3. Postupujte podle předchozích pokynů počínaje krokem 3.
4. Až budete hotovi, klikněte na Update obsluhující koncový bod.

Podle těchto pokynů zakažte odvozování tables:

1. Přejděte na stránku koncového bodu.
2. Klikněte na Upravit konfiguraci.
3. Klikněte na Povolit odvozování table pro remove zaškrtnutí.
4. Jakmile budete s specifikacemi koncového bodu spokojeni, klikněte na Update.

pracovní postup : Monitorování výkonu modelu pomocí odvozování tables

Pokud chcete monitorovat výkon modelu pomocí odvozování tables, postupujte takto:

1. Povolte inference tables na koncovém bodu buď během vytváření koncového bodu, nebo jeho následnou aktualizací.
2. Naplánujte pracovní postup pro zpracování JSON zátěží v inferenci table tím, že je rozbalíte podle schema koncového bodu.
3. (Volitelné) Join rozbalených požadavků a odpovědí s popisky základní pravdy, aby bylo možné vypočítat metriky kvality modelu.
4. Vytvořte monitor nad metrikami výsledného rozdílu Delta table a refresh.

Úvodní poznámkové bloky implementují tento pracovní postup.

Úvodní poznámkový blok pro monitorování inferencí table

Následující poznámkový blok implementuje výše uvedené kroky k rozbalení dotazů z procesu inference systému monitorování Lakehouse table. Poznámkový blok můžete spustit na vyžádání nebo podle plánu opakování pomocí úloh Databricks.

Odvozovat table úvodní poznámkový blok monitorování Lakehouse

poznámkového bloku

Ú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 odvozování table, vypočítá set metrik vyhodnocení textu (jako je čitelnost a toxicita) 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í LLM table Lakehouse Monitoring

poznámkového bloku

Dotazování a analýza výsledků v inferenční table.

Jakmile budou vaše nasazené modely připravené, všechny požadavky směřované na vaše modely se automaticky zaprotokolují do inference tablespolu s odpověďmi. table můžete zobrazit v uživatelském rozhraní, dotazovat table z DBSQL nebo poznámkového bloku nebo dotazovat table pomocí rozhraní REST API.

Zobrazení table v uživatelském rozhraní: Na stránce koncového bodu kliknutím na název inference table otevřete table v Průzkumníku Catalog.

Dotazování table z DBSQL nebo poznámkového bloku Databricks: Můžete spustit kód podobný následujícímu dotazu na odvozování table.

SELECT * FROM <catalog>.<schema>.<payload_table>

Pokud jste povolili odvození tables pomocí uživatelského rozhraní, payload_table je table název, který jste přiřadili při vytváření koncového bodu. Pokud jste povolili odvozování tables pomocí rozhraní API, payload_table se zobrazí v state části odpovědi auto_capture_config. Příklad najdete v tématu Povolení inferencí tables na koncových bodech služby modelu pomocí rozhraní API.

Poznámka k výkonu

Po vyvolání koncového bodu se do hodiny od odeslání žádosti o vyhodnocení zobrazí vyvolání zaprotokolované do vašeho odvozovacího procesu table. 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.

Unity Catalog odvození tableschema

Každá žádost a odpověď, které se zaprotokolují do systému inference table, se zapíší do Delta table s následujícími schema:

Poznámka:

Pokud vyvoláte koncový bod s dávkou vstupů, zaprotokoluje se celá dávka jako jeden řádek.

název Column	Popis	Typ
databricks_request_id	Vygenerovaný požadavek Azure Databricks identifier je připojen ke všem žádostem pro obsluhu modelu.	STRING
client_request_id	Volitelný požadavek vygenerovaný klientem identifier, který lze zadat v těle žádosti podávání modelu. 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, where 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 režijní latence sítě a představuje pouze dobu, kterou potřeboval model na generate predikce.	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í poskytnout vlastní identifier pro žádost, která se zobrazí v konečném odvozování table pod client_request_id a může být použita pro připojení k vaší žádosti s jinými tables, které používají client_request_id, jako je připojení základního popisku pravdy. Pokud chcete zadat klíč client_request_iddatové čá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
    }
  ]
}

client_request_id lze později použít pro spojení značek pravdivostního základu, pokud existují další tables, které mají značky spojené s client_request_id.

Omezení

• Klíče spravované zákazníkem se nepodporují.
• U koncových bodů, které hostují základních modelů, se odvozování tables podporují pouze u zřízených úloh s propustností.
• Azure Firewall může způsobit selhání při vytváření Unity Catalog Delta table, a proto není ve výchozím nastavení podporován. Spojte se s týmem účtu Databricks a povolte ho.
• Pokud je povoleno inferování tables, maximální celková souběžnost napříč všemi obsluhovanými modely v jednom koncovém bodu limit je 128. Spojte se s týmem účtů Azure Databricks a požádejte o zvýšení tohoto limit.
• Pokud table odvozování obsahuje více než 500 tisíc souborů, nebudou zaprotokolována žádná další data. Abyste se vyhnuli překročení tohoto limit, spusťte OPTIMIZE nebo set pro zachování na vašem table tím, že odstraníte starší data. Pokud chcete zkontrolovat počet souborů v table, spusťte DESCRIBE DETAIL <catalog>.<schema>.<payload_table>.
• Momentálně je doručování záznamů ze systému Inference tables na bázi nejlepšího úsilí, ale můžete očekávat, že záznamy budou dostupné do 1 hodiny od žádosti. 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ů.