Gunther Oracle APEX und Datenbank Wiki

Bei der reinen Vektorsuche liegt der Schwerpunkt mehr auf der Bedeutung und dem Kontext von Wörtern oder Sätzen.

Die Suche nach einem exakten Schlüsselwort, wie „Tankdeckel“, findet dann auch evtl. „Tankverschluss“, da die Vektorsuche die semantische Beziehung zwischen den abgefragten Wörtern berücksichtigt.

Die reine Stichwortsuche wiederum mit der Oracle Text Suche liefert nur Ergebnisse, die genau die abgefragten Wörter (bzw. den Mitgliedern dieser Wortfamilie) enthalten, da sie sich auf die exakten Schlüsselwörter und die Darstellung von Wörtern oder Sätzen mit tokenisierten Begriffen in einem eigenen Tabellen Modell basiert.

Mehr zu Oracle Text unter Oracle Text - Volltext Suche über Text Dokumente

Soll mehr Logik enthalten sein muss, für einen reinen Oracle Text Index eine Ontologie erarbeitet und hinterlegt werden, die Begriffe wie Tankdeckel auf Tankverschluss per Definition mappt.

Bei bestimmten Anwendungen ist eine reine Schlüsselwortsuche möglicherweise aber nur bedingt geeignet. Wenn die exakten Begriffe im Inhalt nicht vorhanden sind und der Anwender nur „so ähnlich“ sucht findet der Anwender nicht das gewünschte.

Die hybride Suche kann nun beide Komponenten einer solchen Abfrage berücksichtigen, indem die Schlüsselwortsuche von Oracle Text und die AI Vektor Suche auf denselben Daten durchführt werden.

Beiden Suchergebnisse werden zu einer Ergebnismenge kombiniert und können zu besseren Ergebnissen führen.

Die Ergebnismenge wird nach einem gewählten Ähnlichkeits-Maßstab/-Wert (Score) sortiert; der numerischer Wert gibt die Ähnlichkeit zwischen dem gesuchten Begriff/Satz (der Suchvektor) und den vorhanden Datensatzvektor an. Die ersten Treffer in unsere Liste sind dann die hoffentlich gewünschten und erwarteten Ergebnisse.

Je nach dem wie nun die Ähnlichkeit definiert ist erhalten wir ein gutes oder auch nur ein mittelmäßiges Ergebnis. Da wir aber ja zusätzlich die exakte Wortsuche von Oracle Text mit in unsere Ergebnisse haben, hoffen wir darauf das wir auch möglichst alles finden.

Ich sehe den Hauptvorteil darin, das die Ontologischen Funktionen des Oracle Text Index nun über die Vector Suche ohne großen Aufwand ergänzt bzw. komplett ersetzt werden können.

In der alten Oracle Text Welt war besonders der Aufbau von Themen Indexes und ähnlichen Dinge wie ein Thesaurus von der Defintion so umständlich, das in der Praxis das kaum umgesetzt wurde (siehe auch Einen Oracle Text Theme Index aufbauen und Mit einem Thesaurus und Oracle Text arbeiten ).

Die Kombination beider Index Typen bietet sich an da in Oracle Text der Part Dateien zu analysieren und den reinen Text zu extrahieren sehr mächtig ist (siehe Oracle Text für die Verarbeitung von Binären Dokumenten in PL/SQL verwenden und Oracle Text für die Indizierung binärer Daten verwenden).

Das Filtern der eigentlichen Dokument und das Erkennen von Textes kann elegant in der Oracle Text Pipeline abgewickelt werden und die notwendigen Daten werden von dem KI Part gleich mit gelesen.

Und das über die „Exakte Stichwort Suche“ wird das Rauschen eines reinen Vector Indexes reduziert und die Trefferwahrscheinlichkeit steigt.

Als Vorbereitung wurde eine 23ai Container Umgebung (siehe ⇒ Oracle Datenbank 23ai Free Edition über ein Container Image unter Linux 9 als Testumgebung für AI Vector Search verwenden ) bereitgestellt

Einen User mit entsprechenden Rollen für die weiteren Test Cases anlegen (User SYS im der PDB):

sqlplus sys@//10.10.10.118:1521/freepdb1 AS sysdba
 
CREATE USER GPI IDENTIFIED BY MYSecretPWD
DEFAULT TABLESPACE USERS
TEMPORARY TABLESPACE TEMP;
 
ALTER USER GPI QUOTA UNLIMITED ON USERS;
 
-- normal Developer rights
GRANT CONNECT TO GPI;
GRANT DB_DEVELOPER_ROLE TO GPI;
GRANT SELECT_CATALOG_ROLE TO GPI;
 
-- AI Features
GRANT CREATE MINING MODEL TO GPI;
-- data Exchange for MODEL and Test Data
GRANT READ ON DIRECTORY DATA_EXCHANGE TO GPI;
GRANT WRITE ON DIRECTORY DATA_EXCHANGE TO GPI;
 
-- Oracle Text Test Case
GRANT CTXAPP TO GPI;
 
 
ALTER USER GPI DEFAULT ROLE CONNECT, DB_DEVELOPER_ROLE, SELECT_CATALOG_ROLE, CTXAPP;

Über den Python Client OML4Py (siehe ⇒ Oracle Datenbank 23ai - Modelle für Vector Search über Python OML4Py bereitstellen und mit Hybrid Vector Search testen ) wird nun ein passendes Model im ONNX Format bereitgestellt und dann per PL/SQL in das User Schema geladen.

Im Import Verzeichnis wurde nach obiger Anleitung ein Modell hinterlegt und kann nun geladen werden:

-- löschen falls schon existiert!
BEGIN
   DBMS_VECTOR.DROP_ONNX_MODEL (model_name => 'ALL_MINILM_L6_V2', force => TRUE);
END;
/
 
--einlesen
BEGIN
 DBMS_VECTOR.LOAD_ONNX_MODEL(
     directory  => 'DATA_EXCHANGE'
    ,file_name  => 'all-MiniLM-L6-v2.onnx.onnx'
    ,model_name => 'ALL_MINILM_L6_V2'
    ,metadata   => JSON ('{ "function" : "embedding", "embeddingOutput" : "embedding", "input": { "input": ["DATA"] } }')
  );
END;
/
 
 
SELECT * FROM USER_MINING_MODELS;
 
ALL_MINILM_L6_V2	EMBEDDING	ONNX	NATIVE	18.03.2025 20:42	0	90621438	NO

Damit haben wir eine User und ein Model für die nächsten Schritte.

Für unsere Daten benötigen wir eine einfache Tabelle:

 
CREATE TABLE texte ( id NUMBER(11) PRIMARY KEY, text varchar2(4000));
 
INSERT INTO texte VALUES (1,'Ein Hund steht neben der Hütte');
INSERT INTO texte VALUES (2,'Die liebsten Haustiere sind Katze und Hund');
INSERT INTO texte VALUES (3,'Die Katze auf dem Dach');
 
commit;

(siehe dazu Oracle Text - In Texten suchen für das Grundprinzip von der Suche auf dem Beispiel)

Oracle Text ( mehr dazu unter Oracle Text - Volltext Suche über Text Dokumente ) zerlegt einen Text in seine einzelnen Bestandteile und speichert Bestandteile (Die Token) in einer eigenen Tabellen Struktur.

Dazu wird ein Text in Sätze und Wörter zerlegt, unnötiges aussortiert und Word Zusammenhänge analysiert.

Ablauf beim Auswerten eines Texts (Index Pipline von Oracle Text):

Bei einem Hybrid Vector Index wird nun das Konzept des Vector Indexes (mehr dazu unter Oracle Datenbank 23ai - Vector Search - Einen Vector speichern, vergleichen und indizieren und Oracle Datenbank 23ai - Mit Vectoren in der Oracle Datenbank Daten vergleichen - Demo Applikation für die Suche nach Farben als Erweiterung für den normalen Text Index verwendet.

Der Text nun mit einem Sentence Transformer Model wie https://huggingface.co/sentence-transformers analysiert, zerlegt und in Vektoren überführt.

D.h. der Text durchläuft die Oracle Text Logik und wird gleichzeitig mit dem hinterlegten KI Modell analysiert.

In der PDB als Schema Owner anmelden und den Hybrid Vector Index mit einem Model ohne weitere Parameter anlegen.

Das jeweilige Model (in unserem Demo das „ALL_MINILM_L6_V2“ ) wurde zuvor (siehe Oben ) in das Schema geladen.

Anmelden:

sqlplus gpi@//10.10.10.118:1521/freepdb1

Nun kann versucht werden, einen Hybrid Vektor (CREATE HYBRID VECTOR INDEX) mit dem zuvor in die Datenbank geladenen Model ALL_MINILM_L6_V2 anzulegen:

DROP INDEX IDX_HV_TEXTE;
INDEX IDX_HV_TEXTE dropped.
 
CREATE HYBRID VECTOR INDEX IDX_HV_TEXTE 
                         ON TEXTE  (TEXT) 
                 PARAMETERS ('MODEL ALL_MINILM_L6_V2');
 
Hybrid VECTOR created.

Siehe auch Doku unter https://docs.oracle.com/en/database/oracle/oracle-database/23/vecse/create-hybrid-vector-index.html dazu.

Am elegantesten ist es sich Präferenz Objekt mit dem Parametern zu erstellen und diese Präferenz dann beim Anlegen für den Vector Index Part anzugeben.

-- entfernen falls schon existiert
BEGIN
    DBMS_VECTOR_CHAIN.DROP_PREFERENCE (PREF_NAME => 'GPI_HYBRID_VECTOR_DEV');
END;
/
 
-- Preferenz anlegen
BEGIN
  DBMS_VECTOR_CHAIN.CREATE_PREFERENCE(
     'GPI_HYBRID_VECTOR_DEV',
     dbms_vector_chain.vectorizer,
       json('{
              "vector_idxtype" :  "HNSW"
            , "model"          :  "ALL_MINILM_L6_V2"
            , "by"             :  "WORDS"
            , "max"            :  100
            , "overlap"        :  10
            , "split"          :  "recursively"
            , "vector_distance": "COSINE"
            , "vector_accuracy": "95"
         }'
        )
      );
END;
/

• „vector_idxtype“ : „HNSW“

Bedeutung: Gibt den Typ des Vektorindex an.

HNSW: Hierarchical Navigable Small World, Algorithmus für die Annäherungssuche in hochdimensionalen Räumen; besonders gut für die schnelle Suche nach ähnlichen Vektoren

• „model“ : „ALL_MINILM_L6_V2“

Bedeutung: Definiert das Modell, das zur Erzeugung der Vektoren verwendet wird.

ALL_MINILM_L6_V2: Ein kleines Sprachmodell (kompakte Version des MiniLM-Modells mit 6 Schichten)

• „by“ : „WORDS“

Bedeutung: Legt fest, wie der Text in Vektoren umgewandelt wird.

WORDS: Der Text wird auf Wortebene verarbeitet, d. h. jedes Wort oder Token wird in einen Vektor umgewandelt.

• „max“ : 100

Bedeutung: Definiert die maximale Anzahl von Vektoren oder Tokens, die pro Datensatz verarbeitet werden.

100: Es werden maximal 100 Vektoren pro Datensatz erzeugt.

• „overlap“ : 10

Bedeutung: Gibt an, wie viele Tokens zwischen aufeinanderfolgenden Textabschnitten überlappen sollen.

10: Es gibt eine Überlappung von 10 Tokens zwischen benachbarten Textabschnitten, um Kontextverluste zu minimieren.

• „split“ : „recursively“

Bedeutung: Bestimmt die Methode, wie der Text in Abschnitte aufgeteilt wird.

recursively: Der Text wird rekursiv in kleinere Abschnitte aufgeteilt, um sicherzustellen, dass die maximale Länge (max) nicht überschritten wird.

• „vector_distance“ : „COSINE“

Bedeutung: Definiert die Metrik zur Berechnung der Ähnlichkeit zwischen Vektoren.

COSINE: Die Kosinus-Ähnlichkeit wird verwendet, um den Winkel zwischen zwei Vektoren zu messen. Sie ist eine gängige Metrik für Textähnlichkeit.

• „vector_accuracy“ : „95“

Bedeutung: Gibt die gewünschte Genauigkeit der Vektorsuche an.

95: Die Suche soll eine Genauigkeit von 95 % erreichen

Gut sieht man hier das für semitische Daten für das Ähnlichkeitsmaß der COSINE (Kosinus) Abstand der Vektoren anbietet ( Salop gesagt, die Richtung muss stimmen, egal wie „laut“ der Text ist ).

Der verwendete Algorithmus muss hier fest hinterlegt werden.

DROP INDEX IDX_HV_TEXTE;
 
CREATE HYBRID VECTOR INDEX IDX_HV_TEXTE 
                 ON TEXTE  (TEXT) 
               PARAMETERS ('VECTORIZER      GPI_HYBRID_VECTOR_DEV') ;

Die Charakteristik der Daten spielt eine entscheidende Rolle, wie immer übrigens.

Was ist zu beachten:

Textlänge

„max“ : 100

Wenn die Texte sehr lang sind, kann eine größere max-Größe (z. B. 200 oder 500) sinnvoll sein, um Kontextverluste zu vermeiden. Bei kurzen Texten kann ein kleinerer Wert (z. B. 50) ausreichen.

Textkomplexität

„overlap“ : 10

Komplexe Texte mit vielen Fachbegriffen oder spezifischen Kontexten profitieren von einer höheren Überlappung (overlap), um Kontextinformationen zu erhalten.

Datenmenge

„vector_accuracy“ : „95“

Bei sehr großen Datensätzen kann eine höhere vector_accuracy (z. B. 98 %) die Qualität der Suchergebnisse verbessern, aber die Leistung wiederum stark beeinträchtigen.

Modellauswahl (model)

„model“ : „ALL_MINILM_L6_V2“

Größere Modelle (z. B. BERT-basierte Modelle) erzeugen qualitativ hochwertigere Vektoren, sind aber rechenintensiver, kleinere Modelle wie ALL_MINILM_L6_V2 sind effizienter, aber je nach Anwendungsfall weniger genau.

Für die allgemeine Textähnlichkeitssuchen ist ALL_MINILM_L6_V2 im Prinzip schon ausreichend, ist es aber eine sehr spezialisierte Anwendungen (z. B. Verteidigungsrelevante Vorschriften / Militärische Texte) wäre ein spezialisiertes Modell wohl besser.

Textverarbeitung (by, split, overlap)

Granularität (by):

WORDS eignet sich für die normale Textsuche. Alternativ, gerade beim Hybrid vector, kann sich SENTENCES oder PARAGRAPHS anbieten, da wir ja gerade beim Hybrid Vektor den Gesamt Text im Fokus haben, die einzelnen Wörter bildet ja schon der Oracle Text Index gut ab.

Aufteilung (split):

recursively ist eine sichere Wahl, um Kontextverluste zu minimieren. Bei sehr langen Texten könnte eine feste Größe (fixed_size) effizienter sein.

Überlappung (overlap):

Eine höhere Überlappung (z. B. 20–30) verbessert die Kontexterhaltung, erhöht aber die Anzahl der Vektoren und die Rechenlast.

Was passiert nun im Hintergrund?

Der Hybrid Vector Index Domain Index mit Vector und Oracle Text Funktionalität.

Das sogenannte Vector „Embedding“ ist nicht in unsere Text Basis Tabelle enthalten ( wie bei der normalen Vector Suche) sondern Teil einer Tabelle im Daten Modell des Hybrid Vector Domain Index.

Alle Index Typen von Oracle Text verwenden Datenbank Tabellen um den eigentlichen logischen Index abzubilden.

Auf diesen Hilfstabellen (DR$<index_name>$<I|K|N|R|P) können zum Teil wieder normale Indexe (mit einer Eigenschaft beim Erzeugen des Indexes) zur Performance Optimierung angelegt werden.

Zum Beispiel werden für einen Hybrid Vector Index mit dem Namen „IDX_HV_TEXTE min. die folgenden Tabellen erstellt:

• DR$IDX_HV_TEXTE$I (invertierte Liste aller Wörter)
• DR$IDX_HV_TEXTE$K (Key Map)
• DR$IDX_HV_TEXTE$N (NEG - Gelöschte Datensätze vermerken)
• DR$IDX_HV_TEXTE$R (Denormalisierte Mapping-Tabelle )
  • Optional: DR$IDX_HV_TEXTE$P (Substrings)
  • Optional: DR$IDX_HV_TEXTE$O (ab 12c Forward Indexing für Highlightning, Snippet,Markup Function)
  • Optional: DR$IDX_HV_TEXTE$D (ab 12c Forward Indexing , kompletter Text als PlainText Spalte für Higlighting, Snippet,Markup function für binäre Dokumente)
  • Optional: DR$IDX_HV_TEXTE$G (ab 12c für das Feature Near Real Time Indexes verwendet)

Der besondere Hybrid Vector Anteil des Text Indexes Index

• DR$IDX_HV_TEXTE$VR ( contains the indexed data with generated chunks und corresponding embeddings.)

Diese Tabelle enthält die Vector Daten die wiederum über die rowid auf die Original Tabelle referenzieren und eine DOCID Spalte die die Verknüpfung mit dem Oracle Text Index sicherstellt. Damit wird die Verknüpfung zwischen chunks, tokens und documents hergestellt.

Zusätzlich werden die folgende Tabellen erzeugt:

• VECTOR$DR$IDX_HV_TEXTE$VI$72702_72714_0$HNSW_CHECKPOINTS
• VECTOR$DR$IDX_HV_TEXTE$VI$72702_72714_0$HNSW_ROWID_VID_MAP
• VECTOR$DR$IDX_HV_TEXTE$VI$72702_72714_0$HNSW_SHARED_JOURNAL_CHANGE_LOG

Und diese Indexe:

• IDX_VTEXTE_HNSW_IDX als Vector Index vom Subtyp INMEMORY_NEIGHBOR_GRAPH_HNSW

Und diese View

• IDX_HV_TEXTE$VECTORS

Abfragt werden kann der Index auch über die View <index name>$VECTORS

SELECT * FROM IDX_HV_TEXTE$VECTORS;

Der Vorteil der View ist laut Doku “excluding all lazy deletes (along with corresponding chunks and embeddings that are generated).„

Eine direkte Suche auf der DR$IDX_HV_TEXTE$VR könnten auch gelöschte Daten aufzeigen!

Ein klassischer Domain Index vom Typ CONTEXT registriert zwar Veränderung an Texten oder neue Texte, der ganze Pipeline Prozess dahinter erfolgt aber nur bedingt automatisch in der selben Transaktion.

Im Normalfall läuft regelmäßig ein Hintergrund Job, der erkennt was zu tun ist und den Index aktuell hält.

D.h. je nach dem wie oft der Job nun läuft dauert es bis ein neuer /geänderter Text in einer Suche gefunden werden kann.

Wir sind also nicht zu 100% immer im Sync mit dem Index und den Daten.

Es gibt zwar einige Möglichkeiten dies auch synchron zu betrieben, aber ist nicht der Default, um dieser Verhalten zu erziehlen ergeben sich ganz eigenen Herausforderungen (Stichwort Oracle Text Near Real Time Index).

Wie verhält sich das nun bei unsere „normalen“ Hybrid Vector Index bei Data Manipulation Language (DML) Operationen?

Asynchrone vs. Synchrone Updates

• Synchrone Index-Aktualisierung: Der Index wird direkt mit Datenänderungen aktualisiert (hoher Overhead)
• Asynchrone Index-Aktualisierung: Änderungen werden in eine Pending Queue geschrieben und später verarbeitet (bessere Performance, aber leicht verzögerte Suche)

Was ist hier nun der Default?

Aus der Doku: “In an automatic maintenance mode, indexes are asynchronously maintained without any user intervention. Oracle recommends that you periodically examine regular Oracle Text views to know the status of all background maintenance events.„

Was tut sich dazu im Hintergrund:

SELECT * FROM CTX_USER_BACKGROUND_EVENTS

Default index optimization:

Aus der Doku: A hybrid vector index runs with an automatic background Optimize Full job every midnight „local“ time. This job optimizes your index to defragment it and clean up any lazy deletes from secondary tables such as the $I, $D, and $VR.

Hier fällt die Doku doch recht dünn aus, dieser Verhalten ist in der Praxis ja mehr als entscheidend!

UPDATE TEXTE SET TEXT = 'Ein Hund steht neben der Hütte und langweilt sich' WHERE id=1; 
commit;
 
-- in der Oracle Text Welt liegt nur ein Änderungs-Request vor. 
 
 
-- die Veränderung der Daten ist in der <index_name>$VECTORS ist schon sichtbar
 
SELECT DOC_CHUNK_TEXT FROM IDX_HV_TEXTE$VECTORS;
 
-- Würden wir aber schon etwas finden?
 
 
-- Auf jeden Fall Änderungen aktualisieren im Index mit:
 
BEGIN
ctx_ddl.sync_index('IDX_HV_TEXTE');
END;
/

Eine Abfrage auf den Index erfolgt über DBMS_HYBRID_VECTOR

Siehe dazu https://docs.oracle.com/en/database/oracle/oracle-database/23/vecse/search.html

Eine einfach Abfragen mit dem Suchvector „Haus“ :

SELECT 
   DBMS_HYBRID_VECTOR.SEARCH( 
         JSON( '{  "hybrid_index_name" : "IDX_HV_TEXTE" 
                 , "search_text" : "Haus" } ' 
            ) 
      )
FROM DUAL;

Ergebnis ist eine Liste von Datensätzen, die nach ihrer Ähnlichkeit zu dem Suchvektor sortiert sind:

[
 {"rowid":"AAARdvAAAAAAAMLAAB","score":53.13,"vector_score":58.44,"text_score":0,"vector_rank":1,"text_rank":80,"chunk_text":"Die liebsten Haustiere sind Katze und Hund","chunk_id":"1"}
,{"rowid":"AAARdvAAAAAAAMLAAA","score":52.36,"vector_score":57.6,"text_score":0,"vector_rank":2,"text_rank":80,"chunk_text":"Ein Hund steht neben der Hütte","chunk_id":"1"}
,{"rowid":"AAARdvAAAAAAAMLAAC","score":48.92,"vector_score":53.81,"text_score":0,"vector_rank":3,"text_rank":80,"chunk_text":"Die Katze auf dem Dach","chunk_id":"1"}
]

Und was sagt uns das nun???

der aus beiden Werten (vector_score und text_score ) gebildete Score.

In der Doku steht an einigen Stellen das dieser Wert höher als der vector_score sei, das kann hier aber nicht nachvollzogen werden.

Was uns am meisten interessiert ist der Ähnlichkeitswert (Score); der numerischer Wert, der die Ähnlichkeit zwischen dem Suchvektor und dem Datensatzvektor angibt.

Bei der Kosinus-Ähnlichkeit müsste laut Theorie der Wert zwischen -1 und 1, wobei 1 eine perfekte Übereinstimmung bedeutet, in der Oracle Welt scheint das aber nicht so zu sein.

Unser Hybrid Index ist ja mit „„vector_distance“ : „COSINE““ angelegt worden.

Sieht mir eher nach einer Skalierung aus, 0 ist gleich, je höher die Zahl desto ungleicher? Eigentlich unlogisch, bei einem Vector Vergleich mit „vector_distance“ sind gleiche Vectoren bei 0. Hier sieht es mir genau andersrum aus.

Bei einem Text Score von 0 ist das Wort nicht in den Daten vorhanden.

Ein Beispiel aus der Praxis mit Oracle Text auf 19c

Kunden sucht „Geldwäsche Kontrolle in OSPlus“

Oracle Text sucht hier über Kurstitel / Beschreibung / Erweiterten Kursinformationen in der Kursdatenbank

Oracle findet sehr viele Text Zeilen mit „OSPlus“ , einige mit „Kontrolle“ und ein paar mit „Geldwäsche“

Der Gesamtscore ist nun stark „OSPlus“ Lastig und zeigt in der Sortierung nicht als erstes die erwarteten Kurse an.

Wir wollen möglichst nur Treffen die über den Oracle Text Index den Begriff „Geldwäsche“ enthalten, also in den Kursdaten auch der Begriff vorkommt. Kombiniert mit der Anfrage „OSPLus Kontrolle“.

Eine Lösung ist hier mit

SELECT DBMS_HYBRID_VECTOR.SEARCH(
    json('{ "hybrid_index_name"     : " IDX_HV_TEXTE",
            "search_fusion"         : "UNION",
            "vector":
                    { "search_text" : "OSPlus Kontrolle" },
             "text":
                    { "contains"    : "Geldwäsche" }
          }'))
FROM DUAL;

In der Treffermenge muss dann, wenigstens in der Theorie, immer etwas mit Geldwäsche vorkommen.

Was ist das komplizierte an dem Verfahren?

Die Ausgangs-Daten werden mit einem „Sentence Transformer Model“ in den Vector gewandelt

• Welche Model wählen?
• Wie das Model parametrisieren?
• Passt zu meinen Zielen zu meinen Zielen?
• Kann ich beweisen das mein Ziel auch erreicht wird?

Was ist die Herausforderung?

Die Qualität der Quantifizierung eines Datensatzes in einen Vector der Eigenschaften aufweist, die sich wiederum ähnliche Daten vergleichen lassen, ist die eigentliche Kunst, hier verbinden wir eine Semantische Analyse mit KI/AI mit den statischen Daten der Relationalen Welt und hoffen auf das beste aus beiden Welten.

Und wie am Ende die Abfragen für den Anwender einfach gestalten?

Alle Sonderfunktionen in Oracle Text und nun die erweiterten Optionen mit Vector Search bieten zwar viele Möglichkeiten, aber der Anwender kann nur bedingt nützen, das entweder die Oberfläche zu kompliziert wird der der Anwender die „Sonder Befehlszeichen“ nicht kennt.

Findet der Index Lauf die gleichen Daten wie ein full Table Scan?

Bei einem Hybrid Vector Index ist der Index nicht auf der Orginal Tabelle sondern auf der beim anlegen des Index erzeugen Detail Tabelle des Domain Indexes:

SELECT INDEX_NAME,INDEX_SUBTYPE,TABLE_NAME 
 FROM USER_INDEXES 
WHERE TABLE_NAME LIKE '%TEXTE%' AND index_type = 'VECTOR';
 
INDEX_NAME                       INDEX_SUBTYPE                 TABLE_NAME                                                                                                                      
--------------------------------------------------------------------------------
DR$IDX_HV_TEXTE$VI               INMEMORY_NEIGHBOR_GRAPH_HNSW  DR$IDX_HV_TEXTE$VR

Qualität bewerten:

SET serveroutput ON
 
VARIABLE query_string VARCHAR2(1000)
VARIABLE query_vector CLOB
BEGIN
    :query_string := 'Die Katze steht auf der Hütte';
    SELECT vector_embedding(ALL_MINILM_L6_V2 USING :query_string AS DATA) INTO :query_vector;
END;
/
 
 
DECLARE
    v_qvector VECTOR; 
    v_report varchar2(128);
BEGIN 
    v_qvector := to_vector(:query_vector);
    v_report := dbms_vector.index_accuracy_query(
          OWNER_NAME => 'GPI' 
        , INDEX_NAME => 'DR$IDX_HV_TEXTE$VI'
        , qv => v_qvector
        , top_K =>10 
        , target_accuracy =>90 );
    dbms_output.put_line(v_report); 
END; 
/
 
 
Accuracy achieved (100%) IS 10% higher than the Target Accuracy requested (90%)

Ein Vector Index verwendet einen eigenen Pool Bereich in der Datenbank den „Vector Pool“, siehe https://docs.oracle.com/en/database/oracle/oracle-database/23/vecse/size-vector-pool.html

Der benötigt für komplexere Indexe dann auch eine gewisse Größe nach dem Motto „Nicht zu groß und nicht zu klein, gerade richtig muss es sein“. Also erstmal mutig ausprobieren.

Die Datenbank View für den Vector Memory Pool dazu ist : V$VECTOR_MEMORY_POOL

mit sqlplus im Container in der CDB anmelden und Parameter ändern:

podman EXEC -it freeDB bash
bash-4.4$ su - oracle
export ORACLE_HOME=/opt/oracle/product/23ai/dbhomeFree
export ORACLE_SID=FREE
export PATH=$ORACLE_HOME/bin:$PATH
 
sqlplus / AS sysdba
 
SHOW parameter vector_memory_size 
NAME               TYPE        VALUE 
------------------ ----------- ----- 
vector_memory_size big INTEGER 0    
 
 
ALTER system SET vector_memory_size=512M scope=spfile;
 
shutdown IMMEDIATE
 
startup

Nun lässt sich der Index auch anlegen.

Web:

• https://enesi.no/2024/05/oracle-database-23ai-and-vector-search/