Cortex Search¶
Überblick¶
Cortex Search ermöglicht eine qualitativ hochwertige „unscharfe“ Suche mit geringer Latenz in Ihren Snowflake-Daten. Cortex Search ermöglicht Snowflake-Benutzern ein breites Array an Suchmöglichkeiten, darunter Retrieval Augmented Generation (RAG) Anwendungen, die Large Language Models (LLMs) nutzen.
Mit Cortex Search können Sie eine hybride (Vektor- und Schlüsselwort-) Suchmaschine für Ihre Textdaten in wenigen Minuten in Betrieb nehmen, ohne sich um die Einbettung, die Wartung der Infrastruktur, die Abstimmung der Parameter für die Suchqualität oder die laufende Indexaktualisierung kümmern zu müssen. Das bedeutet, dass Sie weniger Zeit für die Optimierung der Infrastruktur und der Suchqualität aufwenden müssen und mehr Zeit für die Entwicklung hochwertiger Chat- und Sucherlebnisse unter Verwendung Ihrer Daten haben. In den Cortex Search Tutorials finden Sie Schritt-für-Schritt-Anweisungen zur Verwendung von Cortex Search für AI-Chat- und Suchanwendungen.
Wann Sie Cortex Search verwenden sollten¶
Die beiden Hauptanwendungsfälle für Cortex Search sind das Abrufen von Augmented Generation (RAG) und die Unternehmenssuche.
RAG Engine für LLM Chatbots: Verwenden Sie Cortex Search als RAG-Engine für Chat-Anwendungen mit Ihren Textdaten, indem Sie die semantische Suche für individuelle, kontextbezogene Antworten nutzen.
Enterprise-Suche: Verwenden Sie Cortex Search als Backend für eine hochwertige, in Ihre Anwendung eingebettete Suchleiste.
Cortex Search für RAG¶
Retrieval Augmented Generation (RAG) ist eine Technik zum Abrufen von Daten aus einer Wissensdatenbank, um die generierte Antwort eines großen Sprachmodells zu verbessern. Das folgende Architekturdiagramm zeigt, wie Sie Cortex Search mit Cortex LLM-Funktionen kombinieren können, um Unternehmens-Chatbots mit RAG zu erstellen, die Ihre Snowflake-Daten als Wissensdatenbank nutzen.

Cortex Search ist die Suchmaschine, die das Large Language Model mit dem nötigen Kontext versorgt, um Antworten zu liefern, die auf Ihren aktuellsten proprietären Daten beruhen.
Beispiel¶
Dieses Beispiel führt Sie durch die Schritte zur Erstellung eines Cortex Search Service und dessen Abfrage mithilfe der REST API. Weitere Einzelheiten zur Abfrage des Services finden Sie unter Abfrage eines Cortex Search Service.
Dieses Beispiel verwendet ein Beispieldatenset für ein Kundensupport-Transkript.
Führen Sie die folgenden Befehle aus, um die Beispieldatenbank und das Schema einzurichten.
CREATE DATABASE IF NOT EXISTS cortex_search_db;
CREATE OR REPLACE WAREHOUSE cortex_search_wh WITH
WAREHOUSE_SIZE='X-SMALL';
CREATE OR REPLACE SCHEMA cortex_search_db.services;
Führen Sie die folgenden SQL-Befehle aus, um das Datenset zu erstellen.
CREATE OR REPLACE TABLE support_transcripts (
transcript_text VARCHAR,
region VARCHAR,
agent_id VARCHAR
);
INSERT INTO support_transcripts VALUES
('My internet has been down since yesterday, can you help?', 'North America', 'AG1001'),
('I was overcharged for my last bill, need an explanation.', 'Europe', 'AG1002'),
('How do I reset my password? The email link is not working.', 'Asia', 'AG1003'),
('I received a faulty router, can I get it replaced?', 'North America', 'AG1004');
Die Änderungsverfolgung ist eine Anforderung für den Aufbau des Cortex Search Service. Wenn Sie eine Rolle verwenden, die nicht die Eigentümerschaft für diese Tabelle hat, um den Search Service zu erstellen, führen Sie die folgende Anweisung aus, um die Änderungsverfolgung für die Tabelle zu aktivieren:
ALTER TABLE support_transcripts SET
CHANGE_TRACKING = TRUE;
Weitere Informationen zur Aktivierung der Änderungsverfolgung finden Sie unter Änderungsverfolgung aktivieren.
Dienst erstellen¶
Sie können einen Cortex Search Service mit einer einzelnen SQL-Abfrage oder über das Snowflake AI & ML-Studio erstellen. Wenn Sie einen Cortex Search Service erstellen, führt Snowflake Transformationen an Ihren Quelldaten durch, um sie für die Bereitstellung mit niedriger Latenz bereit zu machen. In den folgenden Abschnitten wird gezeigt, wie Sie einen Service sowohl mit SQL als auch im Snowflake AI & ML-Studio über die Snowsight erstellen.
Bemerkung
Wenn Sie einen Service erstellen, wird der Suchindex als Teil des Erstellungsprozesses erstellt. Das bedeutet, dass die Anweisung CREATE CORTEX SEARCH SERVICE bei größeren Datensets länger dauern kann.
Verwenden von SQL¶
Das folgende Beispiel veranschaulicht, wie ein Cortex Search Service mit CREATE CORTEX SEARCH SERVICE anhand des im vorherigen Abschnitt erstellten Beispiel-Datensets für Kundensupport-Transkripte erstellt wird.
CREATE OR REPLACE CORTEX SEARCH SERVICE transcript_search_service
ON transcript_text
ATTRIBUTES region
WAREHOUSE = cortex_search_wh
TARGET_LAG = '1 day'
EMBEDDING_MODEL = 'snowflake-arctic-embed-l-v2.0'
AS (
SELECT
transcript_text,
region,
agent_id
FROM support_transcripts
);
Dieser Befehl löst den Aufbau des Search Services für Ihre Daten aus. In diesem Beispiel:
Bei Abfragen an den Dienst wird nach Übereinstimmungen in der Spalte
transcript_text
gesucht.Der Parameter
TARGET_LAG
legt fest, dass der Cortex Search Service etwa einmal pro Tag nach Aktualisierungen der Basistabellesupport_transcripts
sucht.Die Spalten
region
undagent_id
werden indiziert, sodass sie zusammen mit den Ergebnissen von Abfragen in der Spaltetranscript_text
zurückgegeben werden können.Die Spalte
region
steht bei der Abfrage der Spaltetranscript_text
als Filterspalte zur Verfügung.Das Warehouse
cortex_search_wh
wird verwendet, um die Ergebnisse der angegebenen Abfrage anfänglich und bei jeder Änderung der Basistabelle zu materialisieren.
Bemerkung
Abhängig von der Größe des in der Abfrage angegebenen Warehouse und der Anzahl der Zeilen in Ihrer Tabelle kann dieser CREATE-Befehl bis zu mehreren Stunden in Anspruch nehmen.
Snowflake empfiehlt, für jeden Service ein eigenes Warehouse zu verwenden, das nicht größer als MEDIUM ist.
Die Spalten im Feld ATTRIBUTES müssen in der Abfrage enthalten sein, entweder über eine explizite Aufzählung oder einen Platzhalter (
*
).
Verwenden von Snowsight¶
Folgen Sie diesen Schritten, um einen Cortex Search Service in Snowsight zu erstellen:
Melden Sie sich bei Snowsight an.
Wählen Sie eine Rolle, die die Datenbankrolle SNOWFLAKE.CORTEX_USER hat.
Wählen Sie im Navigationsmenü die Option AI & ML » Studio aus.
Wählen Sie + Create aus dem Feld Create a Cortex Search Service.
Wählen Sie eine Rolle und ein Warehouse. Der Rolle muss die Datenbankrolle SNOWFLAKE.CORTEX_USER zugewiesen sein. Das Warehouse wird für die Materialisierung der Ergebnisse der Quellabfrage verwendet, wenn der Service erstellt und aktualisiert wird.
Wählen Sie eine Datenbank und ein Schema, in dem der Dienst definiert ist.
Geben Sie einen Namen für Ihren Dienst ein und wählen Sie dann Let’s go aus.
Wählen Sie die Tabelle oder Ansicht, die die Textdaten enthält, die für die Suche indiziert werden sollen, und wählen Sie dann Next aus. Wählen Sie für dieses Beispiel die Tabelle
support_transcripts
aus.Bemerkung
Wenn Sie bei der Definition Ihres Dienstes mehrere Datenquellen angeben oder Transformationen durchführen möchten, verwenden Sie SQL.
Markieren Sie die Spalten, die in den Suchergebnissen enthalten sein sollen,
transcript_text
,region
undagent_id
, und wählen Sie dann Next aus.Markieren Sie die Spalte, die durchsucht werden soll,
transcript_text
, und wählen Sie dann Next aus.Wenn Sie Ihre Suchergebnisse nach einer oder mehreren bestimmten Spalten filtern möchten, markieren Sie diese Spalten und wählen dann Next aus. Wenn Sie keine Filter benötigen, wählen Sie Skip this option. Für dieses Beispiel können Sie diesen Schritt auslassen.
Legen Sie Ihr Ziel fest, d. h. die Zeitspanne, die Ihr Inhalt Ihres Dienstes hinter den Aktualisierungen der Basisdaten zurückbleiben soll, und wählen Sie dann Create search service aus.
Der letzte Schritt bestätigt, dass Ihr Service erstellt wurde und zeigt den Namen des Service und seine Datenquelle an.
Bemerkung
Wenn Sie den Dienst von der Snowsight aus erstellen, wird der Name des Dienstes in doppelten Anführungszeichen angegeben. Was das bedeutet, wenn Sie den Dienst in SQL referenzieren, erfahren Sie unter Bezeichner mit doppelten Anführungszeichen.
Berechtigungen für die Nutzung erteilen¶
Nachdem der Service und der Index erstellt wurden, können Sie anderen Rollen wie customer_support die Nutzung des Services, seiner Datenbank und seines Schemas gestatten.
GRANT USAGE ON DATABASE cortex_search_db TO ROLE customer_support;
GRANT USAGE ON SCHEMA services TO ROLE customer_support;
GRANT USAGE ON CORTEX SEARCH SERVICE transcript_search_service TO ROLE customer_support;
Vorschau auf den Dienst¶
Um zu bestätigen, dass der Service ordnungsgemäß mit Daten gefüllt ist, können Sie eine Vorschau des Services über die Funktion SEARCH_PREVIEW aus einer SQL Umgebung heraus anzeigen:
SELECT PARSE_JSON(
SNOWFLAKE.CORTEX.SEARCH_PREVIEW(
'cortex_search_db.services.transcript_search_service',
'{
"query": "internet issues",
"columns":[
"transcript_text",
"region"
],
"filter": {"@eq": {"region": "North America"} },
"limit":1
}'
)
)['results'] as results;
Beispiel für eine erfolgreiche Antwort auf eine Abfrage:
[
{
"transcript_text" : "My internet has been down since yesterday, can you help?",
"region" : "North America"
}
]
Diese Antwort bestätigt, dass der Service mit Daten gefüllt ist und angemessene Ergebnisse für die gegebene Abfrage liefert.
Sie können auch die Tabellenfunktion CORTEX_SEARCH_DATA_SCAN verwenden, um den Inhalt des Dienstes zu überprüfen.
SELECT
*
FROM
TABLE (
CORTEX_SEARCH_DATA_SCAN (
SERVICE_NAME => 'transcript_search_service'
)
);
+ ---------------------------------------------------------- + --------------- + -------- + ------------------------------ +
| transcript_text | region | agent_id | _GENERATED_EMBEDDINGS_MY_MODEL |
| ---------------------------------------------------------- | --------------- | -------- | ------------------------------ |
| 'My internet has been down since yesterday, can you help?' | 'North America' | 'AG1001' | [0.1, 0.2, 0.3, 0.4] |
| 'I was overcharged for my last bill, need an explanation.' | 'Europe' | 'AG1002' | [0.1, 0.2, 0.3, 0.4] |
+ ---------------------------------------------------------- + --------------- + -------- + ------------------------------ +
Abfrage des Dienstes von Ihrer Anwendung aus¶
Nachdem Sie den Search Service erstellt, Ihrer Rolle die Nutzung gewährt und eine Vorschau angezeigt haben, können Sie ihn nun von Ihrer Anwendung aus mit Python API abfragen.
Der folgende Code zeigt die Verwendung von Python API zum Abrufen des Support-Tickets, das für eine Abfrage über internet issues
am relevantesten ist, gefiltert, um Ergebnisse in der Region North America
zurückzugeben:
from snowflake.core import Root
from snowflake.snowpark import Session
CONNECTION_PARAMETERS = {"..."}
session = Session.builder.configs(CONNECTION_PARAMETERS).create()
root = Root(session)
transcript_search_service = (root
.databases["cortex_search_db"]
.schemas["services"]
.cortex_search_services["transcript_search_service"]
)
resp = transcript_search_service.search(
query="internet issues",
columns=["transcript_text", "region"],
filter={"@eq": {"region": "North America"} },
limit=1
)
print(resp.to_json())
Beispiel für eine erfolgreiche Antwort auf eine Abfrage:
{
"results": [
{
"transcript_text": "My internet has been down since yesterday, can you help?",
"region": "North America"
}
],
"request_id": "5d8eaa5a-800c-493c-a561-134c712945ba"
}
Cortex Search Services geben alle Spalten zurück, die im Feld columns
in Ihrer Abfrage angegeben sind.
Erforderliche Berechtigungen¶
Um einen Cortex Search Service zu erstellen, muss Ihre Rolle über die Datenbankrolle CORTEX_USER verfügen, die für die Cortex LLM-Funktionen erforderlich ist. Informationen zum Zuweisen und Widerrufen dieser Rolle finden Sie unter Erforderliche Berechtigungen für Cortex LLM-Funktionen.
Um einen Cortex Search Service abzufragen, muss die Rolle des abfragenden Benutzers über die Berechtigung USAGE für den Dienst selbst sowie für die Datenbank und das Schema, in dem sich der Dienst befindet, verfügen. Siehe Anforderungen an die Cortex Search-Zugriffssteuerung Anforderungen.
Um einen Cortex Search Service mit dem Befehl ALTER auszusetzen oder wieder fortzusetzen, muss die Rolle des abfragenden Benutzers die Berechtigung OPERATE für den Service haben. Siehe ALTER CORTEX SEARCH SERVICE.
Wichtig
Cortex Search Services führen Suchvorgänge mit den Rechten des Eigentümers durch und folgen demselben Sicherheitsmodell wie andere Snowflake-Objekte, die mit den Rechten des Eigentümers laufen. Weitere Informationen finden Sie unter Anforderung der Zugriffssteuerung für Cortex Search
Die Qualität von Cortex Search verstehen¶
Cortex Search nutzt eine Reihe von Abruf- und Ranking-Modellen, um Ihnen ein hohes Maß an Suchqualität zu bieten, wobei nur wenig bis gar keine Anpassung erforderlich ist. Im Hintergrund verfolgt Cortex Search einen „hybriden“ Ansatz zum Abrufen und Rankint von Dokumenten. Jede Suchabfrage verwendet:
Vektorsuche zum Abrufen von semantisch ähnlichen Dokumenten.
Schlüsselwortsuche zum Abrufen von lexikalisch ähnlichen Dokumenten.
Semantische Neusortierung zur Neusortierung der relevantesten Dokumente in der Ergebnismenge
Dieser hybride Abrufansatz, gekoppelt mit einem semantischen Reranking-Schritt, erreicht eine hohe Suchqualität über eine breite Palette von Datasets und Abfragen.
Cortex Search-Einbettungsmodelle¶
Cortex Search ermöglicht es Benutzern, ein gehostetes Einbettungsmodell auszuwählen, das im Stagingbereich der Vektorsuche verwendet werden soll. Die folgenden Einbettungsmodelle sind in Cortex Search verfügbar.
Wichtig
Die Preise der Modelle variieren. Die Preise für das kanonische Modell finden Sie in der Snowflake Service Consumption Table. Wenn ein unten angegebener Preis von dem Preis abweicht, der für das Modell in der Snowflake Service Consumption Table angegeben ist, ist die Snowflake Service Consumption Table maßgeblich.
Modellbezeichnung |
Umfang der Ausgabe |
Unterstützung von Sprachen |
Credit-Kosten pro 1M Token |
Beschreibung |
---|---|---|---|---|
|
768 |
Nur auf Englisch |
0,03 |
Snowflakes praktischstes, rein englischsprachiges Einbettungsmodell. Dieses Open-Source-Modell mit 110 Mio. Parametern bietet die schnellsten Indizierungszeiten aller in Cortex Search verfügbaren Modelle. Weitere Informationen finden Sie im Blogbeitrag Arctic Embed 1.5 und Arctic Embed 1.5 Modellkarte. |
|
1024 |
Mehrsprachig |
0,05 |
Das preisgünstige mehrsprachige Einbettungsmodell von Snowflake. Dieses Open-Source-Modell mit 568 Mio. Parametern liefert sowohl bei englischen als auch bei nicht-englischen Datensätzen eine hohe Qualität. Weitere Informationen finden Sie im Blogbeitrag Arctic Embed 2 und Arctic Embed 2 Modellkarte. |
|
1024 |
Mehrsprachig |
0,07 |
Das mehrsprachige Einbettungsmodell von Voyage. Dieses Modell liefert sowohl bei englischen als auch bei nicht-englischen Datensätzen eine hohe Qualität. Weitere Informationen finden Sie im Blogbeitrag Voyage Multilingual 2 |
Einige Einbettungsmodelle sind für Cortex Search nur in bestimmten Regionen der Cloud verfügbar. Eine Liste der Verfügbarkeit nach Modell und Region finden Sie unter Regionale Verfügbarkeit von Cortex Search.
Jedes Modell hat unterschiedliche Leistungs-, Kosten- und Qualitätsmerkmale. Prüfen Sie die Modellspezifikationen sorgfältig, um das beste Modell für Ihre spezielle Arbeitslast zu finden. In der Snowflake Service Consumption Table finden Sie eine genaue Übersicht über die Kosten der einzelnen Modelle in Credits pro Million Token.
Token-Beschränkungen und Textsplitting¶
Für optimale Suchergebnisse mit der Cortex Search empfiehlt Snowflake, den Text in Ihrer Suchspalte in Blöcke von nicht mehr als 512 Token (etwa 385 englische Wörter) aufzuteilen. Wenn ein Eintrag in der Suchspalte mehr als 512 Token enthält, führt Cortex Search eine schlüsselwortbasierte Suche im gesamten Textkörper durch, verwendet jedoch nur die ersten 512 Token für die semantische (d. h. vektorbasierte) Suche.
Ein Token ist eine Sequenz von Zeichen und die kleinste Texteinheit, die von einem großen Sprachmodell verarbeitet werden kann. Ein Token entspricht ungefähr 3/4 eines englischen Wortes, also etwa 4 Zeichen. Um die genaue Anzahl der Token in einer Zeichenfolge zu berechnen, können Sie die COUNT_TOKENS Cortex-Funktion verwenden. Zum Beispiel die Berechnung der Token für eine Zeichenfolge, die mit dem Modell snowflake-arctic-embed-m-v1.5
eingebettet werden soll:
SELECT SNOWFLAKE.CORTEX.COUNT_TOKENS('snowflake-arctic-embed-m', '<input_text>') as token_count
Beschränkungen bei der semantischen Suche mit Token verstehen¶
Die Empfehlung für Blöcke mit einer Größe von 512 Token oder weniger beruht auf Forschungsergebnissen, die zeigen, dass eine geringere Größe von Blöcken in der Regel zu einer höheren Abruf- und nachgelagerten LLM-Antwortqualität führt. Obwohl es heute Modelle zur Einbettung in einen längeren Kontext gibt, wie z. B. arctic-embed-m-long, aber Cortex Search entscheidet sich für ein Einbettungsmodell mit einem kleineren Kontextfenster, um von Anfang an eine höhere Suchqualität zu bieten.
Die Idee hinter diesem Konzept ist, dass bei kleineren Datenpaketen die Abfrage für eine bestimmte Suchanfrage präziser sein kann. Dies liegt daran, dass es weniger Token gibt, über die „gemittelt“ werden muss, wenn die Vektoreinbettungen für den Block und die Abfrage generiert werden. Mit kleineren Blöcken kann das nachgelagerte LLM zudem nur die Informationen erhalten, die es benötigt, da in der Eingabeaufforderung für das Modell weniger potenziell verrauschter Text enthalten ist.
Hier finden Sie eine Studie, die zeigt, dass kleinere Blöcke in der Regel bei öffentlichen Benchmark-Datensätzen im Q&A-Stil besser abschneiden.
Aktualisierungen¶
Der Inhalt, der in einem Cortex Search Service angeboten wird, basiert auf den Ergebnissen einer bestimmten Abfrage. Wenn sich die einem Cortex Search Service zugrunde liegenden Daten ändern, wird der Service aktualisiert, um diese Änderungen widerzuspiegeln. Diese Aktualisierungen werden als Auffrischung (engl. refresh) bezeichnet. Dieser Prozess ist automatisiert und umfasst die Analyse der Abfrage, die der Tabelle zugrunde liegt.
Die Cortex Search Services haben die gleichen Eigenschaften wie die dynamische Tabellen. Unter Initialisierung und Aktualisierung dynamischer Tabellen verstehen finden Sie Informationen zu den Aktualisierungsmerkmalen eines Cortex Search Service.
Die Quellabfrage für einen Cortex Search Service muss ein Kandidat für die dynamische inkrementelle Tabellenaktualisierung sein. Einzelheiten zu diesen Anforderungen finden Sie unter Unterstützung von inkrementellen Aktualisierungen. Diese Einschränkung soll verhindern, dass die Kosten für die Berechnung der Vektoreinbettung unkontrolliert steigen. Weitere Informationen über die Konstrukte, die für die dynamische inkrementelle Aktualisierung von Tabellen nicht unterstützt werden, finden Sie unter Unterstützte Abfragen für dynamische Tabellen.
Anhalten der Indizierung und Bereitstellung¶
Ähnlich wie bei Dynamic Tables setzt Cortex Search Services den Indizierungsstatus automatisch aus, wenn fünf aufeinanderfolgende Aktualisierungsfehler in Bezug auf die Ausgangsabfrage festgestellt werden. Wenn dieser Fehler bei Ihrem Service auftritt, können Sie den spezifischen SQL-Fehler entweder unter DESCRIBE CORTEX SEARCH SERVICE oder unter Ansicht CORTEX_SEARCH_SERVICES anzeigen. Die Ausgabe von beiden umfasst die folgenden Spalten:
Die Spalte INDEXING_STATE wird den Wert SUSPENDED haben.
Die Spalte INDEXING_ERROR enthält den spezifischen SQL-Fehler, der in der Quellabfrage aufgetreten ist.
Sobald die Ursache behoben ist, können Sie den Dienst unter ALTER CORTEX SEARCH SERVICE <name> RESUME INDEXING
fortsetzen. Für eine detaillierte Syntax siehe ALTER CORTEX SEARCH SERVICE.
Hinweise zu Kosten¶
Ein Cortex Search Service verursacht Kosten auf folgende Weise:
Kategorie |
Beschreibung |
---|---|
Computing von virtuellen Warehouses |
Ein Cortex Search Service benötigt ein virtuelles Warehouse, um den Service zu aktualisieren: um Abfragen gegen Basisobjekte durchzuführen, wenn diese initialisiert und aktualisiert werden, einschließlich der Orchestrierung von Texteinbettungsaufträgen und dem Aufbau des Suchindexes. Diese Operationen nutzen Computeressourcen, die Credits verbrauchen. Wenn bei einer Aktualisierung keine Änderungen festgestellt werden, werden keine Credits für das virtuelle Warehouse verbraucht, da es keine neuen Daten zu aktualisieren gibt. |
EMBED_TEXT-Token berechnen |
Ein Cortex Search Service bettet automatisch jede Textzeile in der im Parameter |
Rechenleistung |
Ein Cortex Search Service nutzt mandantenfähige Rechenleistung, die von einem vom Benutzer bereitgestellten Warehouse getrennt ist, um einen Dienst mit niedriger Latenz und hohem Durchsatz einzurichten. Die Rechenkosten für diese Komponente fallen pro GB pro Monat (GB/mo) unkomprimierter indizierter Daten an, wobei indizierte Daten die vom Benutzer in der Cortex Search-Quellabfrage bereitgestellten Daten plus die im Namen des Benutzers berechneten Vektoreinbettungen sind. Diese Kosten fallen an, solange der Dienst zur Beantwortung von Abfragen zur Verfügung steht, auch wenn in einem bestimmten Zeitraum keine Abfragen gestellt werden. Die Credit-Rate für Cortex Search-Bereitstellung pro GB/mo indizierter Daten finden Sie in der Snowflake Service Consumption Table. |
Speicher |
Cortex Search Services materialisiert die Abfrage in einer Tabelle, die in Ihrem Konto gespeichert ist. Diese Tabelle wird in Datenstrukturen umgewandelt, die für eine niedrige Latenzzeit optimiert sind und ebenfalls in Ihrem Konto gespeichert werden. Der Speicher für die Tabelle und die dazwischen liegenden Strukturen basiert auf einer Pauschale pro Terabyte (TB). |
Cloud Services Compute |
Cortex Search Services verwenden Cloud Services-Berechnung um Änderungen in den zugrunde liegenden Basisobjekten zu erkennen und um festzustellen, ob das Warehouse aufgerufen werden muss. Die Computekosten für Clouddienste-Computing unterliegen der Einschränkung, dass Snowflake diese nur abrechnet, wenn die täglichen Kosten der Clouddienste mehr als 10 % der täglichen Warehouse-Kosten für das Konto betragen. |
Bewährte Verfahren zur Verwaltung der Kosten eines Cortex Search Service finden Sie unter Die Kosten für Cortex Search Services verstehen.
Um die AI Services-bezogenen Verbrauchskosten für jeden Cortex Search Service in Ihrem Konto, täglich aggregiert, anzuzeigen, besuchen Sie die Ansicht CORTEX_SEARCH_DAILY_USAGE_HISTORY
Bekannte Einschränkungen¶
Die Verwendung von Cortex Search unterliegt den folgenden Beschränkungen:
Größe der Basistabelle: Das Ergebnis der materialisierten Abfrage im Suchdienst muss weniger als 100 Millionen Zeilen groß sein, um eine optimale Leistung zu gewährleisten. Wenn das materialisierte Ergebnis Ihrer Abfrage mehr als 100M Zeilen enthält, schlägt die Erstellungsabfrage mit einem Fehler fehl.
Bemerkung
Um die Beschränkungen der Zeilenskalierung bei einem Cortex Search Service über 100 Mio. zu erhöhen, wenden Sie sich bitte an das Team Ihres Snowflake-Kontos.
Abfragekonstrukte: Die Abfragen des Cortex Search Service müssen denselben Abfragebeschränkungen unterliegen wie die dynamischen Tabellen. Weitere Informationen finden Sie unter Beschränkungen für dynamische Tabellen.
Replikation und Klonen: Die Cortex Search Services unterstützen Replikation oder Klonen nicht. Die Unterstützung für diese Features wird in einem zukünftigen Release verfügbar sein.
Wichtig
Für jeden Cortex Search Service, den Sie erstellen, werden zwei dynamische Tabellenentitäten in der Snowsight-Überwachung UI für dynamische Tabellen angezeigt. Diese beiden Entitäten haben das Format _CORTEX_SEARCH_SOURCE_*
und _CORTEX_SEARCH_REFRESH_*
. Diese Entitäten erscheinen auch in den Ansichten des dynamischen Tabelleninformationsschemas, jedoch nicht in den SHOW/DESC-Befehlen für dynamische Tabellen. Wenn Sie eine dieser Entitäten in der Snowsight UI auswählen, wird die Meldung Dynamic Table not found
angezeigt. Dies ist ein erwartetes Verhalten. Die Entitäten, die sich auf die Cortex Search beziehen, werden in zukünftigen Releases des Produkts aus dem Snowsight Dynamic Tables Monitoring-UI entfernt.
Regionale Verfügbarkeit¶
Dieses Feature ist für Konten in den folgenden Snowflake-Regionen verfügbar: Die Verfügbarkeit für bestimmte Einbettungsmodelle innerhalb einer Region ist durch ein Häkchen gekennzeichnet.
Cloudanbieter
|
Region
|
snowflake-arctic-embed-m-v1.5 |
snowflake-arctic-embed-l-v2.0 |
voyage-multilingual-2 |
---|---|---|---|---|
AWS
|
US West 2 (Oregon)
|
✔ |
✔ |
✔ |
AWS
|
US East 2 (Ohio)
|
✔ |
✔ |
|
AWS
|
US East 1 (N. Virginia)
|
✔ |
✔ |
✔ |
AWS
|
Canada (Central)
|
✔ |
✔ |
|
AWS
|
South America (São Paulo)
|
✔ |
✔ |
|
AWS
|
Europa (Irland)
|
✔ |
✔ |
|
AWS
|
Europe (London)
|
✔ |
✔ |
|
AWS
|
Europe Central 1 (Frankfurt)
|
✔ |
✔ |
✔ |
AWS
|
Europe (Stockholm)
|
✔ |
✔ |
|
AWS
|
Asia Pacific (Tokio)
|
✔ |
✔ |
✔ |
AWS
|
Asia Pacific (Mumbai)
|
✔ |
✔ |
|
AWS
|
Asia Pacific (Sydney)
|
✔ |
✔ |
|
AWS
|
Asia Pacific (Jakarta)
|
✔ |
✔ |
|
AWS
|
Asia Pacific (Seoul)
|
✔ |
✔ |
|
Azure
|
East US 2 (Virginia)
|
✔ |
✔ |
|
Azure
|
West US 2 (Washington)
|
✔ |
✔ |
|
Azure
|
South Central US (Texas)
|
✔ |
✔ |
|
Azure
|
UK South (London)
|
✔ |
✔ |
|
Azure
|
North Europe (Irland)
|
✔ |
✔ |
|
Azure
|
West Europe (Niederlande)
|
✔ |
✔ |
✔ |
Azure
|
Switzerland North (Zürich)
|
✔ |
✔ |
|
Azure
|
Central India (Pune)
|
✔ |
✔ |
|
Azure
|
Japan East (Tokyo, Saitama)
|
✔ |
✔ |
|
Azure
|
Southeast Asia (Singapur)
|
✔ |
✔ |
|
Azure
|
Australia East (New South Wales)
|
✔ |
✔ |
|
GCP
|
Europe West 2 (London)
|
✔ |
✔ |
|
GCP
|
Europe West 3 (Frankfurt)
|
✔ |
✔ |
|
GCP
|
Europe West 4 (Niederlande)
|
✔ |
✔ |
|
GCP
|
Naher Osten Zentral 2 (Dammam)
|
✔ |
✔ |
|
GCP
|
US Central 1 (Iowa)
|
✔ |
✔ |
|
GCP
|
US East 4 (N. Virginia)
|
✔ |
✔ |
Bemerkung
Sie können den regionsübergreifenden Inferenzparameter in jeder der oben genannten Regionen angeben, um auf Modelle zuzugreifen, die nicht direkt von Ihrer Standardregion unterstützt werden.
Cortex Search ist in den folgenden Regionen nur mit regionenübergreifender Inferenz verfügbar. Um die Cortex Search mit regionenübergreifender Inferenz zu nutzen, verwenden Sie den Parameter regionenübergreifende Inferenz.
AWS Europa (Paris)
AWS Europa (Zürich)
AWS Asia Pacific (Singapur)
AWS Asia Pacific (Osaka)
Azure Canada Central (Toronto)
Azure Central US (Iowa)
Azure UAE North (Dubai)
Bemerkung
Bei der regionenübergreifenden Inferenz hängt die Latenz bei Abfragen zwischen Regionen von der Infrastruktur des Cloudanbieters und dem Netzwerkstatus ab. Snowflake empfiehlt, dass Sie Ihren speziellen Anwendungsfall mit aktivierter regionsübergreifender Inferenz testen.
Rechtliche Hinweise¶
Die Datenklassifizierung der Eingaben und Ausgaben ist in der folgenden Tabelle aufgeführt.
Klassifizierung von Eingabedaten |
Klassifizierung von Ausgabedaten |
Benennung |
---|---|---|
Usage Data |
Customer Data |
Die allgemein verfügbaren Funktionen sind abgedeckte AI-Features. Die Vorschaufunktionen sind Vorschau-AI-Features. [1] |
Weitere Informationen dazu finden Sie unter KI und ML in Snowflake.