Poznámka
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
Tento článek poskytuje přehled o hledání vektorů AI v systému Mosaic, včetně toho, co je a jak funguje.
Co je Hledání vektorů AI v systému Mosaic?
Mosaic AI Vector Search je řešení vektorového vyhledávání, které je integrované do platformy Databricks Data Intelligence Platform a integrované s jeho nástroji pro zásady správného řízení a produktivitu. Vektorové vyhledávání je typ vyhledávání optimalizovaný pro načítání vložených objektů. Vkládání jsou matematické znázornění sémantického obsahu dat, obvykle textových nebo obrázkových dat. Vkládání jsou generována velkým jazykovým modelem a jsou klíčovou součástí mnoha generovaných aplikací umělé inteligence, které závisí na hledání dokumentů nebo obrázků, které jsou podobné sobě. Příkladem jsou systémy RAG, doporučené systémy a rozpoznávání obrázků a videa.
Pomocí funkce Mosaic AI Vector Search vytvoříte z tabulky Delta index vektorového vyhledávání. Index obsahuje vložená data s metadaty. Pak můžete index dotazovat pomocí rozhraní REST API, abyste identifikovali nejvíce podobné vektory a vrátili přidružené dokumenty. Index můžete strukturovat tak, aby se automaticky synchronizoval při aktualizaci podkladové tabulky Delta.
Rozhraní AI Vector Search v systému Mosaic podporuje následující:
- Hybridní vyhledávání podle podobnosti klíčových slov
- Filtrování.
- Seznamy řízení přístupu (ACL) pro správu koncových bodů vektorového vyhledávání
- Synchronizovat pouze vybrané sloupce.
- Ukládat a synchronizovat vygenerované embeddingy.
Jak funguje hledání vektorů AI v systému Mosaic?
Mosaic AI Vector Search používá algoritmus Hierarchical Navigable Small World (HNSW) pro přibližné hledání nejbližších sousedů a metriku vzdálenosti L2 k měření podobnosti zapouzdřovacích vektorů. Pokud chcete použít kosinusovou podobnost, musíte před jejich podáváním do vektorového vyhledávání normalizovat vkládání datových bodů. Když jsou datové body normalizovány, pořadí vytvořené vzdáleností L2 je stejné jako pořadí vytvořené kosinovou podobností.
Mosaic AI Vector Search také podporuje hybridní vyhledávání, které kombinuje vektorové vyhledávání založené na vkládání s tradičními technikami vyhledávání založenými na klíčových slovech. Tento přístup odpovídá přesným slovům v dotazu a zároveň používá vyhledávání podobnosti založené na vektorech k zachycení sémantických relací a kontextu dotazu.
Díky integraci těchto dvou technik vyhledávání hybridních klíčových slov načítá dokumenty, které obsahují nejen přesná klíčová slova, ale také ty, které jsou koncepčně podobné a poskytují komplexnější a relevantnější výsledky hledání. Tato metoda je zvláště užitečná v aplikacích RAG, kde zdrojová data mají jedinečná klíčová slova, jako jsou skladové položky nebo identifikátory, které nejsou vhodné pro čistě podobné vyhledávání.
Podrobnosti o rozhraní API naleznete v referenční dokumentaci k sadě Python SDK a v části Dotazování na koncový bod vektorového vyhledávání.
Výpočet vyhledávání podobnosti
Výpočet vyhledávání podobnosti používá následující vzorec:
kde dist je euklidská vzdálenost mezi q dotazu a položkou indexu x:
Algoritmus vyhledávání klíčových slov
Skóre relevance se počítají pomocí okapi BM25. Prohledávají se všechny sloupce textu nebo řetězce, včetně sloupců vkládání zdrojového textu a metadat ve formátu textu nebo řetězce. Funkce tokenizace rozdělí hranice slova, odebere interpunkci a převede veškerý text na malá písmena.
Jak se vyhledávání podobností a hledání klíčových slov kombinuje
Hledání podobnosti a výsledky hledání klíčových slov se kombinují pomocí funkce Reciproční Rank Fusion (RRF).
RRF znovu ohodnotí každý dokument z každé metody pomocí skóre:
Ve výše uvedené rovnici pořadí začíná na 0, sečte skóre pro každý dokument a vrátí nejvyšší bodovací dokumenty.
rrf_param určuje relativní důležitost dokumentů s vyšším pořadím a s nižším pořadím. Na základě literatury je rrf_param nastaveno na 60.
Skóre jsou normalizována tak, aby nejvyšší skóre bylo 1 a nejnižší skóre je 0 pomocí následující rovnice:
Možnosti pro poskytování vektorových reprezentací
Pokud chcete vytvořit index vektorového vyhledávání v Databricks, musíte se nejprve rozhodnout, jak poskytovat vkládání vektorů. Databricks podporuje tři možnosti:
Možnost 1: Delta synchronizační index s vnořenými prvky vypočítanými pomocí Databricks Poskytnete zdrojovou tabulku Delta, která obsahuje data v textovém formátu. Databricks vypočítá vkládání pomocí zadaného modelu a volitelně uloží vložení do tabulky v katalogu Unity. Při aktualizaci tabulky Delta zůstane index synchronizovaný s tabulkou Delta.
Tento proces znázorňuje následující diagram:
- Vytváření vektorových reprezentací dotazů Dotaz může obsahovat filtry metadat.
- Vyhledávání podobností umožňuje identifikovat nejrelevavantnější dokumenty.
- Vraťte nejrelevavantnější dokumenty a připojte je k dotazu.
Možnost 2: Delta Sync Index se samostatně spravovanými vestavěnými vektory Poskytujete zdrojovou tabulku Delta, která obsahuje předem vypočítané vestavěné vektory. Při aktualizaci tabulky Delta zůstane index synchronizovaný s tabulkou Delta.
Tento proces znázorňuje následující diagram:
- Dotaz se skládá z vkládání a může obsahovat filtry metadat.
- Vyhledávání podobností umožňuje identifikovat nejrelevavantnější dokumenty. Vraťte nejrelevavantnější dokumenty a připojte je k dotazu.
Možnost 3: Index přímého vektorového přístupu Musíte ručně aktualizovat index pomocí rozhraní REST API při změně tabulky embeddingů.
Tento proces znázorňuje následující diagram:
Možnosti koncového bodu
Mosaic AI Vector Search poskytuje následující možnosti, které vám umožní vybrat konfiguraci koncového bodu, jež nejlépe odpovídá potřebám vaší aplikace.
Poznámka:
Koncové body optimalizované pro úložiště jsou ve verzi Public Preview a jsou k dispozici v následujících oblastech: eastus, eastus2, westus, westus2, . westeurope
- Standardní koncové body mají kapacitu 320 milionů vektorů v rozměru 768.
- Koncové body optimalizované pro úložiště mají větší kapacitu (více než jednu miliardu vektorů v dimenzi 768) a poskytují 10 až 20krát rychlejší indexování. Dotazy na koncové body optimalizované pro úložiště mají mírně zvýšenou latenci přibližně 250 ms. Ceny pro tuto možnost jsou optimalizované pro větší počet vektorů. Podrobnosti o cenách najdete na stránce s cenami vektorového vyhledávání. Informace o správě nákladů na vektorové vyhledávání viz Mosaic AI Vector Search: Průvodce správou nákladů.
Typ koncového bodu zadáte při vytváření koncového bodu.
Viz také omezení koncových bodů optimalizovaných pro úložiště.
Jak nastavit vektorové vyhledávání v systému Mosaic AI
Chcete-li použít vectorové vyhledávání v systému Mosaic AI, je nutné vytvořit následující:
Koncový bod vektorového vyhledávání. Tento koncový bod slouží indexu vektorového vyhledávání. Koncový bod můžete dotazovat a aktualizovat pomocí rozhraní REST API nebo sady SDK. Pokyny najdete v tématu Vytvoření koncového bodu vektorového vyhledávání.
Koncové body se automaticky škálují tak, aby podporovaly velikost indexu nebo počet souběžných požadavků. Při odstranění indexu se koncové body optimalizované pro úložiště automaticky stáhnou. Standardní koncové body se automaticky nerozšiřují dolů.
Index vektorového vyhledávání. Index vektorového vyhledávání se vytvoří z tabulky Delta a je optimalizovaný tak, aby poskytoval přibližné hledání nejbližších sousedů v reálném čase. Cílem hledání je identifikovat dokumenty, které jsou podobné dotazu. Indexy pro vektorové vyhledávání se zobrazují v katalogu Unity a jsou jím řízeny. Pokyny najdete v tématu Vytvoření indexu vektorového vyhledávání.
Pokud se navíc rozhodnete nechat Databricks vypočítat embeddingy, můžete použít předem nakonfigurovaný koncový bod rozhraní API základního modelu nebo vytvořit koncový bod pro obsluhu modelu, který bude sloužit embeddingovému modelu podle vašeho výběru. Pokyny najdete v tématu rozhraní API základního modelu pro platby za token nebo Vytvoření základního modelu obsluhujícího koncové body.
K dotazování koncového bodu obsluhy modelu použijete buď rozhraní REST API, nebo sadu Python SDK. Dotaz může definovat filtry na základě libovolného sloupce v tabulce Delta. Podrobnosti najdete v tématu Použití filtrů pro dotazy, reference k rozhraní API nebo referenční informace k sadě Python SDK.
Požadavky
- Pracovní prostor s aktivovaným katalogem Unity
- Bezserverové výpočetní prostředky jsou povolené. Pokyny najdete v tématu Připojení k výpočetním prostředkům bez serveru.
- U standardních koncových bodů musí mít zdrojová tabulka povolený kanál změn dat. Vizte Kanál změn dat v Delta Lake na Azure Databricks.
- Pokud chcete vytvořit index vektorového vyhledávání, musíte mít oprávnění CREATE TABLE ve schématu katalogu, kde bude index vytvořen.
Oprávnění k vytváření a správě koncových bodů vektorového vyhledávání se konfiguruje pomocí seznamů řízení přístupu. Viz ACL koncového bodu pro vektorové vyhledávání.
ochrana a ověřování dat
Databricks implementuje následující bezpečnostní prvky, které chrání vaše data:
- Každá žádost zákazníka o hledání vektorů AI v systému Mosaic je logicky izolovaná, ověřená a autorizovaná.
- Mosaic AI Vector Search šifruje všechna data v klidu (AES-256) a při přenosu (TLS 1.2+).
Mosaic AI Vector Search podporuje dva režimy ověřování, aplikační objekty a osobní přístupové tokeny (PAT). V případě produkčních aplikací doporučuje Databricks používat služební principály, které můžou mít výkon dotazů až o 100 ms rychlejší ve srovnání s osobními přístupovými tokeny.
Token principálu služby. Správce může vygenerovat token principála služby a předat ho rozhraní SDK nebo API. Viz principály služeb. Pro případy použití v produkčním prostředí doporučuje Databricks použít token služebního principálu.
# Pass in a service principal vsc = VectorSearchClient(workspace_url="...", service_principal_client_id="...", service_principal_client_secret="..." )Osobní přístupový token. Osobní přístupový token můžete použít k ověření s využitím Funkce vektorového vyhledávání v systému Mosaic AI. Viz token pro autentizaci osobního přístupu. Pokud používáte sadu SDK v prostředí poznámkového bloku, sada SDK automaticky vygeneruje token PAT pro ověřování.
# Pass in the PAT token client = VectorSearchClient(workspace_url="...", personal_access_token="...")
Klíče spravované zákazníkem (CMK) jsou podporovány na koncových bodech vytvořených 8. května 2024 nebo později.
Sledování využití a nákladů
Tabulka fakturovatelného systému využití umožňuje monitorovat využití a náklady spojené s indexy a koncovými body vektorového vyhledávání. Zde je příklad dotazu:
WITH all_vector_search_usage (
SELECT *,
CASE WHEN usage_metadata.endpoint_name IS NULL THEN 'ingest'
WHEN usage_type = "STORAGE_SPACE" THEN 'storage'
ELSE 'serving'
END as workload_type
FROM system.billing.usage
WHERE billing_origin_product = 'VECTOR_SEARCH'
),
daily_dbus AS (
SELECT workspace_id,
cloud,
usage_date,
workload_type,
usage_metadata.endpoint_name as vector_search_endpoint,
CASE WHEN workload_type = 'serving' THEN SUM(usage_quantity)
WHEN workload_type = 'ingest' THEN SUM(usage_quantity)
ELSE null
END as dbus,
CASE WHEN workload_type = 'storage' THEN SUM(usage_quantity)
ELSE null
END as dsus
FROM all_vector_search_usage
GROUP BY all
ORDER BY 1,2,3,4,5 DESC
)
SELECT * FROM daily_dbus
Můžete také zjišťovat využití podle rozpočtové politiky. Viz Mosaic AI Vector Search: Zásady rozpočtu.
Podrobnosti o obsahu tabulky fakturačního využití najdete v referenční informace k tabulce systému účtovatelného využití. Další dotazy jsou v následujícím ukázkovém poznámkovém bloku.
Dotazy na tabulky, systém vektorového vyhledávání, poznámkový blok
Pořiďte si poznámkový blok
Omezení velikosti prostředků a dat
Následující tabulka shrnuje omezení velikosti prostředků a dat pro koncové body a indexy vektorového vyhledávání:
| Prostředek | Členitost | Limita / Omezení |
|---|---|---|
| Koncové body vektorového vyhledávání | Na pracovní prostor | 100 |
| Embedování | Na každý koncový bod | ~ 320 000 000 při embeddingové dimenzi 768 ~ 160 000 000 při zabudování v rozměru 1536 přibližně 80 000 000 při dimenzi vkládání 3072 (škáluje se přibližně lineárně) |
| Dimenze vnoření | Podle indexu | 4096 |
| Indexy | Na každý koncový bod | 50 |
| Sloupce | Podle indexu | 50 |
| Sloupce | Podporované typy: bajty, krátké, celé číslo, dlouhé, číslo s plovoucí desetinnou čárkou, dvojité, logická hodnota, řetězec, časové razítko, datum | |
| Pole metadat | Podle indexu | 50 |
| Název indexu | Podle indexu | 128 znaků |
Následující omezení platí pro vytváření a aktualizaci indexů vektorového vyhledávání:
| Prostředek | Členitost | Limita / Omezení |
|---|---|---|
| Velikost řádku pro Delta Sync index | Podle indexu | 100 kB |
| Vložení velikosti zdrojového sloupce pro index Delta Sync | Podle indexu | 32764 bajtů |
| Limit velikosti hromadného požadavku na upsert pro index Direct Vector | Podle indexu | 10 MB |
| Hromadný limit velikosti žádosti o odstranění indexu Direct Vector | Podle indexu | 10 MB |
Následující omezení platí pro rozhraní API pro dotazy.
| Prostředek | Členitost | Limita / Omezení |
|---|---|---|
| Délka textu dotazu | Na základě dotazu | 32764 bajtů |
| Maximální počet vrácených výsledků (přibližné hledání nejbližšího souseda) | Na základě dotazu | 10 000 |
| Maximální počet vrácených výsledků (hledání hybridního vyhledávání podobnosti klíčových slov) | Na základě dotazu | 200 |
Omezení
- Název sloupce
_idje rezervován. Pokud má vaše zdrojová tabulka sloupec pojmenovaný_id, přejmenujte ho před vytvořením indexu pro vyhledávání vektoru. - Oprávnění na úrovni řádků a sloupců nejsou podporována. Můžete ale implementovat vlastní seznamy ACL na úrovni aplikace pomocí rozhraní API filtru.
Omezení koncových bodů optimalizovaných pro úložiště
Omezení v této části platí jenom pro koncové body optimalizované pro úložiště. Koncové body optimalizované pro úložiště jsou ve verzi Public Preview.
- Režim průběžné synchronizace není podporován.
- Synchronizace sloupců není podporována.
- Rozměr embeddingu musí být dělitelný hodnotou 16.
- Přírůstková aktualizace není podporována. Každá synchronizace plně znovu sestaví index vektorového vyhledávání.
- V porovnání se standardními koncovými body byste měli očekávat významné zkrácení doby potřebné pro synchronizaci. Datové sady s 1 miliardou vkládání by měly dokončit synchronizaci do 8 hodin. Synchronizace menších datových sad bude trvat kratší dobu.
- Pracovní prostory kompatibilní s HIPAA, PCI a FedRAMP se nepodporují.
- Klíče spravované zákazníkem (CMK) se nepodporují.
- Koncové body optimalizované pro úložiště podporují až 1 miliardu vkládání vektorů 768 dimenzí. Pokud máte případ použití většího rozsahu, obraťte se na svůj obchodní tým.