Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Oracle AI Vector Search 技術詳細

Oracle AI Vector Search 技術詳細

oracle4engineer

May 21, 2024
Tweet

More Decks by oracle4engineer

Other Decks in Technology

Transcript

  1. • Vector Pool • ベクトル索引 • ベクトル索引利⽤時のSQL実⾏計画 • ONNXモデルのインポート •

    DBMS_VECTOR_CHAINパッケージの利⽤ • UTL_TO_TEXT • UTL_TO_CHUNKS • UTL_TO_EMBEDDINGS • UTL_TO_SUMMARY • Chunker Helper Functions 機能⼀覧 Copyright © 2024, Oracle and/or its affiliates 2
  2. ベクトル索引のための新しいSGAメモリ領域 概要 • ベクトル索引のために利⽤するVector Poolと 呼ばれる新しいメモリ領域がSGA上に構成可能に • インメモリネイバーグラフベクトル索引と 関連するメタデータを保存するために使⽤される •

    ネイバーパーティションベクトル索引の作成やそれに関 連するDML操作を⾼速化するためにも使⽤される • V$VECTOR_MEMORY_POOLビューで 領域監視が可能 Vector Pool Copyright © 2024, Oracle and/or its affiliates 4
  3. • CDBレベル、PDBレベルで設定可能 • 設定例は以下の通り Vector Poolの有効化 Copyright © 2024, Oracle

    and/or its affiliates 5 SQL> ALTER SYSTEM SET vector_memory_size=1G SCOPE=BOTH; System altered. SQL> show parameter vector_memory_size NAME TYPE VALUE ------------------- ----------- ------- vector_memory_size big integer 1G
  4. • 特にインメモリネイバーグラフベクトル索引を使⽤する場合、 多くのメモリが必要になることが想定されるためサイジングが重要 • 必要なメモリ量はディメンション数、フォーマットサイズ、レコード数などによって決まる • ディメンション数、フォーマットサイズはEmbeddingモデルごと決まり、例えば以下の表の通り Vector Poolのサイジング Copyright

    © 2024, Oracle and/or its affiliates 6 Name Dimensions Format Size text-embedding-ada-002 1536 4 Byte (float32) text-embedding-3-large 3072 4 Byte (float32) all-MiniLM-L6-v2 384 4 Byte (float32) all-mpnet-base-v2 768 4 Byte (float32) embed-english-v3.0 1024 4 Byte (float32) embed-english-light-3.0 384 4 Byte (float32) multilingual-e5-large 1024 4 Byte (float32) multilingual-e5-small 384 4 Byte (float32)
  5. • サイジングは参考値ではあるが以下の計算式で計算可能 • ディメンション数 × フォーマットのサイズ × レコード数 × 1.3

    • 1.3はグラフレイヤーのオーバーヘッド • 例えば100万レコードで計算すると以下の通り Vector Poolのサイジング Copyright © 2024, Oracle and/or its affiliates 7 Name Dimensions Format Size rows overhead GB text-embedding-ada-002 1536 4 Byte (float32) 1,000,000 1.3 7.4 text-embedding-3-large 3072 4 Byte (float32) 1,000,000 1.3 15.0 all-MiniLM-L6-v2 384 4 Byte (float32) 1,000,000 1.3 1.9 all-mpnet-base-v2 768 4 Byte (float32) 1,000,000 1.3 3.7 embed-english-v3.0 1024 4 Byte (float32) 1,000,000 1.3 5.0 embed-english-light-3.0 384 4 Byte (float32) 1,000,000 1.3 1.9 multilingual-e5-large 1024 4 Byte (float32) 1,000,000 1.3 5.0 multilingual-e5-small 384 4 Byte (float32) 1,000,000 1.3 1.9
  6. 概要 • ⼤量ベクトルデータの⾼速な近傍検索のため、近似解を許容する構造 • リソース(コスト)、検索速度、検索精度のトレードオフを実現 • 求める検索精度を指定して索引の作成が可能 • 原理的で索引構造理解が必要となるパラメータのでの記述を回避 •

    メモリ領域としてSGA上のVECTOR_POOLを使⽤ • 索引は2種類(索引⽣成時にいずれかを選択) • インメモリ近傍グラフベクトル索引 ( In-Memory Neighbor Graph Vector Index) SGA上にインメモリで展開される⾼速なグラフ構造の索引 • 近傍パーティションベクトル索引 (Neighbor Partition Vector Index ) ベクトル同⼠を距離ベースのクラスタリングでまとめた低コストな索引 ベクトル索引 Copyright © 2024, Oracle and/or its affiliates 9
  7. 基本構⽂ 索引作成の基本構⽂ • DISTANCE句はオプション(デフォルトはCOSINE) • 距離関数は、ベクトルの⽣成に使⽤される埋込みモデルに基づいて適切なものを選択 • 利⽤可能な距離関数 • EUCLIDEAN(ユークリッド距離)

    • L2_SQUARED(EUCLIDEAN_SQUARED)(ユークリッド平⽅距離) • COSINE(コサイン距離) • DOT(ドット積) • MANHATTAN(マンハッタン距離) • HAMMING(ハミング距離) 索引作成 CREATE VECTOR INDEX⽂ Copyright © 2024, Oracle and/or its affiliates 10 CREATE VECTOR INDEX photo_idx ON Customer(photo_vector) ORGANIZATION [INMEMORY NEIGHBOR GRAPH | NEIGHBOR PARTITIONS] DISTANCE EUCLIDEAN | COSINE | DOT | HAMMING ...
  8. 近傍検索精度の指定︓WITH TARGET ACCURACY <percentage value> 索引作成の基本構⽂: • 索引作成に必須ではないが、WITH TARGET ACCURACY

    句で、期待する近傍検索精度の指定が可能 • 指定はパーセンテージ ( with target accuracy 90 と記載すれば期待精度90% の意味) • 各索引の構造に基づく、原理的なパラメータ指定も可能 (クエリ時に精度指定することで、索引作成時の精度を上書きしてデータの取得をすることも可能) 索引作成 CREATE VECTOR INDEX⽂ Copyright © 2024, Oracle and/or its affiliates 11 CREATE VECTOR INDEX photo_idx ON Customer(photo_vector) ORGANIZATION [INMEMORY NEIGHBOR GRAPH | NEIGHBOR PARTITIONS] DISTANCE EUCLIDEAN | COSINE | DOT | HAMMING ... WITH TARGET ACCURACY <percentage value>
  9. 概要 • Hierarchical Navigable Small Worlds (HNSW)に基づくグラフ構造のインメモリ専⽤のベクトル索引 メリット • ⾼く安定した近傍検索精度

    • ⾼速な検索 注意点 • 表へのDMLの発⾏が不能になる • メモリリソースを消費する • 索引全体をメモリ上にロードする必要があるため • 索引作成コストがやや⼤きい インメモリ近傍グラフ・ベクトル索引 Copyright © 2024, Oracle and/or its affiliates 12
  10. 構築と検索時の動作イメージ 構築 • グラフの最下位レイヤー(0)にはすべてのベクトルが存在 • ⾼層に⾏くほどベクトルは減少 • 各レイヤーでベクトル間が近い距離のものをエッジで接 続することでグラフが⽣成される 検索

    • 検索は最上位レイヤーのエントリーポイントから開始 • 問い合わせベクトルに近づく⽅向にエッジを辿り、最も 近いベクトルを発⾒したら、探索は下のレイヤーに継承 • 問合せベクトルに最も近い上位Kベクトルが最下位レイ ヤーで⾒つかり次第、探索は完了 インメモリ近傍グラフ・ベクトル索引 Copyright © 2024, Oracle and/or its affiliates 13 エントリーポイント レイヤー3 レイヤー2 レイヤー1 レイヤー0 問合せベクトル 最も近い 隣⼈を⾒つけ、 レイヤーを下に移動 最も近い 隣⼈を⾒つけ、 レイヤーを下に移動 最も近い 隣⼈を⾒つけ、 レイヤーを下に移動 最寄りの Kネイバーを⾒つけ るための貪欲な検 索 新幹線 → 快速列⾞ → 普通列⾞ の乗り継ぎのイメージ
  11. 作成構⽂詳細 インメモリ近傍グラフ・ベクトル索引固有のパラメータ • NEIGHBORS : HNSWグラフ⽣成時に1つのベクトルから結ぶ近傍エッジの最⼤数 • M︓NEIGHBORSと同じ(どちらか⽚⽅だけ指定、MがHNSW上、neiboursを指す⼀般的な呼称) • efConstruction

    : HNSWグラフ⽣成時に近傍として結ぶべき近傍のベクトルの候補を保持するリストの⻑さ インメモリ近傍グラフ・ベクトル索引 Copyright © 2024, Oracle and/or its affiliates 14 CREATE VECTOR INDEX <vector index name> ON <table name> ( <vector column> ) [GLOBAL] ORGANIZATION INMEMORY NEIGHBOR GRAPH [WITH] [DISTANCE <metric name>] [ WITH TARGET ACCURACY <percentage value> [PARAMETERS ( TYPE HNSW, { NEIGHBORS <max number of closest vectors connected> | M <max number of closest vectors connected> }, EFCONSTRUCTION <max number of candidates to consider for connection> )]] [PARALLEL <degree of parallelism>];
  12. 概要 • IVF(Inverted File index/Flat) に基づくベクトル索引 メリット • 低コストで効率的な近傍検索 •

    表へのDML操作が可能(動的な表への適⽤が可能) • データ更新に対する索引更新コストが低い 注意点 • 検索性能はHNSWに劣る • 平時の更新処理時には索引全体の構造の⾒直しを⾏わないため、更新が多発した場合、 精度や性能の低下が発⽣する可能性がある • 精度の監視や⼀定タイミングでのrebuildが必要になる可能性 近傍パーティション・ベクトル索引 Copyright © 2024, Oracle and/or its affiliates 15
  13. 構築と検索時の動作イメージ 近傍パーティション・ベクトル索引 Copyright © 2024, Oracle and/or its affiliates 16

    X軸 Y軸 #1 #2 #3 #4 #5 問合せベクトル 構築 • OMLのK-meansクラスタリング・アル ゴリズムを使⽤し、ベクトルをパーティ ションにグループ化(K = 5)。 (OML: Oracle Machine Learning) 検索 • 問合せベクトルから各パーティション の重⼼までの距離を計算 • 最も近い2つのパーティションを特定 • 問合せベクトルからクラスタ#1およ び#3のすべてのベクトルと問い合わ せベクトル間の距離を計算し、最も 近い上位5件(⾚✖で表⽰)を取得 2次元データ・セット
  14. 近傍パーティション・ベクトル索引固有のパラメータ • NEIGHBOR PARTITIONS︓⽣成するパーティション(クラスタ)数 • SAMPLE_PER_PARTITION • MIN_VECTORS_PER_PARTITION 近傍パーティション・ベクトル索引 Copyright

    © 2024, Oracle and/or its affiliates 17 CREATE VECTOR INDEX <vector index name> ON <table name> ( <vector column> ) [GLOBAL] ORGANIZATION NEIGHBOR PARTITIONS [WITH] [DISTANCE <metric name>] [WITH TARGET ACCURACY <percentage value> [PARAMETERS ( TYPE IVF, { NEIGHBOR PARTITIONS <number of partitions> | SAMPLE_PER_PARTITION <number of samples> | MIN_VECTORS_PER_PARTITION <minimum number of vectors per partition> })]] [PARALLEL <degree of parallelism>];
  15. 基本⽅針 • 断続的なDMLが無く、索引データがメモリに乗り切るのであれば、インメモリ近傍グラフ索引を利⽤ • 更新処理がある場合には、メンテナンス枠などでバッチ的に処理などの対処が必要 • 対象の表に断続的にDML(挿⼊、更新、削除)が⼊る場合、近傍パーティション索引を利⽤ • DMLが無いが、データがメモリに乗り切らない場合には近傍パーティション索引を利⽤ インメモリ近傍グラフ索引

    • ⾮常に⾼速 • インメモリ前提のため必要となるメモリリソースが⼤きい (SGA上のvector poolの確保が必要) • 設定した表への更新処理が⾏えない 近傍パーティション索引 • インメモリ近傍グラフ索引ほどの⾼速性や精度はない • 設定した表への更新処理が可能 • 通常時はパーティションの再計算をせずに、近傍パーティションへの追加を⾏うため、索引精度の劣化が発⽣しうる • 索引精度の確認(索引精度レポート)で確認、必要に応じてrebuild どちらの索引を利⽤するべきか Copyright © 2024, Oracle and/or its affiliates 18
  16. ベクトル索引の詳細ビュー VECSYS.VECTOR$INDEX ビュー Copyright © 2024, Oracle and/or its affiliates

    19 列名 データ・タイプ 説明 とあるVECTORINDEXの例 IDX_OBJN NUMBER ベクトルインデックスのオブジェクト番号 71924 IDX_OBJD NUMBER ベクトルインデックスオブジェクトのID。この ID は、ベクトル インデックスを再構築するために使 ⽤できます。 IDX_OWNER# NUMBER ベクトルインデックスの所有者ID。 user$ エン トリを参照 133 IDX_NAME VARCHAR2(128) ベクトルインデックスの名前。 HNSW_TABA_V IDX_BASE_TABLE_OBJN NUMBER 実表オブジェクト番号 71194 IDX_PARAMS JSON ベクトル インデックス作成パラメータ (インデック ス付けされたベクトル列、インデックス距離、ベク トル次元データ型、次元数、efConstruction 、HNSW索引のM、またはIVF索引の重⼼数 など)。 {"type":"HNSW","num_neighbors":32,"efConstruction":200,"upcast_dtype":1,"distan ce":"COSINE","accuracy":90,"vector_type": "FLOAT32","vector_dimension":5,"degree_of_parallelism":1,"indexed_col":"V"} IDX_AUXILIARY_TABLES JSON ROWID から頂点 ID への変換情報をサポー トするために使⽤される補助表の名前とオブジェ クト ID、または逆フラット ファイル ベクトル イン デックスのセントロイド テーブルとそれに関連する パーティション テーブルの名前。 {"rowid_vid_map_objn":71925,"shared_journal_transaction_commits_objn":71927,"s hared_journal_change_log_objn":71930,"rowi d_vid_map_name":"VECTOR$HNSW_TABA_V$HNSW_ROWID_VID_MAP","shared_j ournal_transaction_commits_name":"VECTOR$HNSW_TABA_V$HN SW_SHARED_JOURNAL_TRANSACTION_COMMITS","shared_journal_change_log_ name":"VECTOR$HNSW_TABA_V$HNSW_SHARED_JOURNAL_CHANGE_L OG"} IDX_SPARE1 NUMBER IDX_SPARE2 JSON
  17. • パーティション表のローカル索引は未サポート • オブジェクトの制限(以下のオブジェクトは、ベクトル索引の作成ができません) • 外部テーブル • IOT • クラスタ/クラスタテーブル

    • グローバル⼀時テーブル • ブロックチェーンテーブル • マテリアライズドビュー • ⾮ベクター列 ( VARCHAR、NUMBERなど) • 関数ベースのベクトルインデックス • シャード化されたテーブル ベクトル索引の制限事項 Copyright © 2024, Oracle and/or its affiliates 20
  18. ベクトル索引を利⽤するオペレーション • 索引⾛査から直接⾏を持ってくる動作 • VECTOR INDEX HNSW SCAN • リレーショナルデータによるフィルタ条件が含まれる際のオペレーション

    • プレ・フィルタリング ( Join-Back 有/無) • リレーショナルデータによるフィルタが先に実⾏され、その後 ベクトル索引が⾛査される • VECTOR INDEX HNSW SCAN PRE-FILTER • イン・フィルタリング ( Join-Back 有/無) • ベクトル索引が⾛査され、その後、リレーショナルデータによるフィルタが実⾏される • VECTOR INDEX HNSW SCAN IN-FILTER ベクトル索引(HNSW) の実⾏計画オペレーション Copyright © 2024, Oracle and/or its affiliates 22
  19. 索引⾛査 ベクトル索引の⾛査のみで完結する場合 VECTOR INDEX HNSW SCAN ベクトル索引の実⾏計画オペレーション Copyright © 2024,

    Oracle and/or its affiliates 23 SELECT name FROM galaxies ORDER BY VECTOR_DISTANCE( embedding, :embedding ) FETCH APPROXIMATE FIRST 10 ROWS ONLY WITH TARGET ACCURACY 90; ------------------------------------------------------------------ | Id | Operation | Name | ---------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | |* 1 | COUNT STOPKEY | | | 2 | VIEW | | |* 3 | SORT ORDER BY STOPKEY | | | 4 | TABLE ACCESS BY INDEX ROWID | GALAXIES | | 5 | VECTOR INDEX HNSW SCAN | GALAXIES_HNSW_IDX | ----------------------------------------------------------------------------
  20. WHERE句条件などに列の評価条件が⼊っているベクトル類似検索は単なる索引⾛査だけでなく 特別なオペレーションで実⾏ リレーショナルデータのフィルターを含んだSQLの実⾏ Copyright © 2024, Oracle and/or its affiliates

    24 SELECT name FROM galaxies WHERE id<5 ORDER BY VECTOR_DISTANCE( embedding, :embedding ) FETCH APPROXIMATE FIRST 10 ROWS ONLY WITH TARGET ACCURACY 90; ----------------------------------------------------------- | Id | Operation | Name | --------------------------------------------------------------------- | 0 | SELECT STATEMENT | | |* 1 | COUNT STOPKEY | | | 2 | VIEW | | | 3 | VECTOR INDEX HNSW SCAN IN-FILTER | GALAXIES_HNSW_IDX | | 4 | VIEW | VW_HIJ_7AA0632F | |* 5 | TABLE ACCESS BY USER ROWID | GALAXIES | ---------------------------------------------------------------------
  21. オペレーション • プレ・フィルタリング VECTOR INDEX HNSW SCAN PRE-FILTER • 最初にベース

    テーブルに対してフィルタリング評価が実⾏され、 その後、対応するベクトルの HNSW ベクトル索引のみが ⾛査される。ほとんどの⾏がフィルターで除外される場合、 こちらが⾼速になりやすい • イン・フィルタリング VECTOR INDEX HNSW SCAN IN-FILTER • 先にHNSW ベクトル索引の⾛査が実⾏され、 各ベクトル候補に対してフィルタリングを呼び出す。 フィルターで除外される⾏が少ない場合、 プレ・フィルター処理よりも優れている可能性がある。 リレーショナルデータのフィルターを含んだSQLの実⾏ Copyright © 2024, Oracle and/or its affiliates 25 • Join-Backオペレーション(有無) • 各フィルタリングの後に関連する列を取りに ⾏くオペレーション • フェッチするデータ量に応じて有無が 選択される • Join-Backなしの場合には フィルタリング前に列を取得する
  22. 先にフィルター条件の⾏集合を取得し、 実⾏計画例︓Join-Backありのプレ・フィルターオペレーション Copyright © 2024, Oracle and/or its affiliates 26

    ------------------------------------------------------------------------------------- | Id | Operation | Name | ----------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | |* 1 | COUNT STOPKEY | | | 2 | VIEW | | |* 3 | SORT ORDER BY STOPKEY | | |* 4 | TABLE ACCESS BY INDEX ROWID | GALAXIES | | 5 | VECTOR INDEX HNSW SCAN PRE-FILTER | GALAXIES_HNSW_IDX | | 6 | VIEW | VW_HPJ_77825837 | | 7 | NESTED LOOPS OUTER | | |* 8 | TABLE ACCESS FULL | GALAXIES | | 9 | TABLE ACCESS BY INDEX ROWID | VECTOR$GALAXIES_HNSW_IDX$HNSW_ROWID_VID_MAP | |* 10 | INDEX UNIQUE SCAN | SYS_C008586 | ------------------------------------------------------------------------------------------------ ROWIDとHNSW の頂点IDのマップ HNSW索引 Join-Back
  23. 先にフィルター条件の⾏集合を取得し、 実⾏計画例︓Join-Backなしのプレ・フィルターオペレーション Copyright © 2024, Oracle and/or its affiliates 27

    -------------------------------------------------------------------------------------- | Id | Operation | Name | ----------------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | |* 1 | COUNT STOPKEY | | | 2 | VIEW | | |* 3 | SORT ORDER BY STOPKEY | | | 4 | VECTOR INDEX HNSW SCAN PRE-FILTER | GALAXIES_HNSW_IDX | | 5 | VIEW | VW_HPJ_77825837 | | 6 | NESTED LOOPS OUTER | | |* 7 | TABLE ACCESS FULL | GALAXIES | | 8 | TABLE ACCESS BY INDEX ROWID | VECTOR$GALAXIES_HNSW_IDX$HNSW_ROWID_VID_MAP | |* 9 | INDEX UNIQUE SCAN | SYS_C008586 | ------------------------------------------------------------------------------------------------ ROWIDとHNSW の頂点IDのマップ HNSW索引
  24. 先にフィルター条件の⾏集合を取得し、 実⾏計画例︓Join-Backありのイン・フィルターオペレーション Copyright © 2024, Oracle and/or its affiliates 28

    ----------------------------------------------------------- | Id | Operation | Name | --------------------------------------------------------------------- | 0 | SELECT STATEMENT | | |* 1 | COUNT STOPKEY | | | 2 | VIEW | | |* 3 | TABLE ACCESS BY INDEX ROWID | GALAXIES | | 4 | VECTOR INDEX HNSW SCAN IN-FILTER | GALAXIES_HNSW_IDX | | 5 | VIEW | VW_HIJ_7AA0632F | |* 6 | TABLE ACCESS BY USER ROWID | GALAXIES | --------------------------------------------------------------------- HNSW索引 Join-Back
  25. 先にフィルター条件の⾏集合を取得し、 実⾏計画例︓Join-Backありのイン・フィルターオペレーション Copyright © 2024, Oracle and/or its affiliates 29

    ----------------------------------------------------------- | Id | Operation | Name | --------------------------------------------------------------------- | 0 | SELECT STATEMENT | | |* 1 | COUNT STOPKEY | | | 2 | VIEW | | | 3 | VECTOR INDEX HNSW SCAN IN-FILTER | GALAXIES_HNSW_IDX | | 4 | VIEW | VW_HIJ_7AA0632F | |* 5 | TABLE ACCESS BY USER ROWID | GALAXIES | --------------------------------------------------------------------- HNSW索引
  26. • ベクトル索引のアクセスパス • 表と索引を指定する • クエリ変換(フィルターを含む)処理 • フィルタータイプ(プレフィルター、インフィルター、join-backの有無まで記述できる) オプティマイザヒント Copyright

    © 2024, Oracle and/or its affiliates 30 VECTOR_INDEX_SCAN ( [ @ queryblock ] tablespec [ indexspec ]) NO_VECTOR_INDEX_SCAN ( [ @ queryblock ] tablespec [ indexspec ]) VECTOR_INDEX_TRANSFORM ( [ @ queryblock ] tablespec [ indexspec [ filtertype ]] ) NO_VECTOR_INDEX_TRANSFORM ( [ @ queryblock ] tablespec [ indexspec ] ) filtertype PRE_FILTER_WITH_JOIN_BACK PRE_FILTER_WITHOUT_JOIN_BACK IN_FILTER_WITH_JOIN_BACK IN_FILTER_WITHOUT_JOIN_BACK
  27. • アクセスパスヒント • フィルタ指定⼊り オプティマイザヒントの利⽤例 Copyright © 2024, Oracle and/or

    its affiliates 31 SELECT /*+ VECTOR_INDEX_SCAN(galaxies) */ name FROM galaxies ORDER BY VECTOR_DISTANCE( embedding, to_vector('[0,1,1,0,0]'), COSINE ) FETCH APPROXIMATE FIRST 3 ROWS ONLY; SELECT /*+ vector_index_transform(galaxies galaxies_hnsw_idx pre_filter_without_join_back) */ name FROM galaxies WHERE id<5 ORDER BY VECTOR_DISTANCE( embedding, to_vector('[0,1,1,0,0]'), COSINE ) FETCH APPROXIMATE FIRST 3 ROWS ONLY WITH TARGET ACCURACY 90;
  28. • ベクトル検索では近似解を許容する構造のため、近傍検索の到達精度の確認が必要になる場合がある • 特に近傍パーティション索引(IVF)では、表に対して更新処理が実施されるため 索引作成時からの精度の変動が発⽣しうる • ⼆通りの精度の確認⽅法 • 単発クエリベースの精度評価 DBMS_VECTOR.INDEX_ACCURACY_QUERY関数

    • レポートベースの精度評価 ワークロードから、特定の期間の特定のベクトル インデックスを使⽤した近似検索による精度値を取得しレポート DBMS_VECTOR.INDEX_ACCURACY_REPORTプロシージャでジョブを実⾏ 結果はDBA_VECTOR_INDEX_ACCURACY_REPORT表に反映 索引精度レポート Copyright © 2024, Oracle and/or its affiliates 33
  29. 任意のクエリベクトル(qv) を与え、そのtop_K個の結果の正答率を計算して返す 結果として得られた精度と、⽬標精度から⾒て、⾼いか低いかが出⼒される 索引精度レポート︓クエリベース Copyright © 2024, Oracle and/or its

    affiliates 34 select DBMS_VECTOR.INDEX_ACCURACY_QUERY( OWNER_NAME => 'VECTOR', INDEX_NAME => 'GALAXIES_HNSW_IDX', qv => to_Vector('[1,0,0,0,1]'), top_K =>10, target_accuracy =>90 ) ac ; AC ------------------------------------------------------------------------------------------- Accuracy achieved (100%) is 10% higher than the Target Accuracy requested (90%)
  30. レポートを作成 確認 索引精度レポート︓レポートベース Copyright © 2024, Oracle and/or its affiliates

    35 VARIABLE t_id NUMBER; BEGIN :t_id := DBMS_VECTOR.INDEX_ACCURACY_REPORT('VECTOR', 'GALAXIES_HNSW_IDX'); END; / SELECT MIN_TARGET_ACCURACY, MAX_TARGET_ACCURACY, num_vectors, MIN_ACHIEVED_ACCURACY, MEDIAN_ACHIEVED_ACCURACY, MAX_ACHIEVED_ACCURACY FROM DBA_VECTOR_INDEX_ACCURACY_REPORT WHERE task_id = 1;
  31. 概要とメリット 概要 • Oracleから提供されるomlutilsツールを利⽤して、 事前訓練済みのモデルをONNX形式に変換し、 Oracle Databaseにインポートして、 データベース内でテキストをEMBEDDINGSへ変換 メリット •

    データベース内で、データベースリソースを使ってテキストをEMBEDDINGSへの変換が可能 • 特にデータベースの中にベクトル化したいデータが格納されている場合、データベース内で処理が完結する • 格納されたLOBデータをUTL_TO_TEXT、UTL_TO_CHUNKS、UTL_TO_EMBEDDINGSなどの DBMS_VECTOR_CHAINパッケージと組み合わせることでEMBEDDINGSまでの⼀連の処理を実⾏可能 ONNXモデルのインポート Copyright © 2024, Oracle and/or its affiliates 37 EXECUTE DBMS_VECTOR.LOAD_ONNX_MODEL ( 'DM_DUMP', 'my_embedding_model.onnx', 'doc_model', JSON('{"function": "embedding", "embeddingOutput": "embedding"}') ); EXECUTE DBMS_DATA_MINING.IMPORT_ONNX_MODEL ( 'my_embedding_model.onnx', 'doc_model', JSON('{"function": "embedding", "embeddingOutput": "embedding"}, "input": {"input": ["DATA"]}}') ); DBMS_VECTOR.LOAD_ONNX_MODEL() {ONNX} モデル DBMS_DATA_MINING.IMPORT_ONNX_MODEL() or {in-database objects}
  32. 仮想環境の作成とomlutilsのインストール 1. Linux環境でminicondaをインストール 2. ONNXモデル作成⽤のpython(=3.12)仮想環境を作成 3. omlutils.zipをダウンロードし、Linux環境でunzipし、unzipしてできたディレクトリ内で以下を実⾏し、 必要なパッケージをインストール ONNXモデルの準備 conda

    create –n onnx python=3.12 conda activate onnx Copyright © 2024, Oracle and/or its affiliates 38 mkdir -p ~/miniconda3 wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -O ~/miniconda3/miniconda.sh bash ~/miniconda3/miniconda.sh -b -u -p ~/miniconda3 ~/miniconda3/bin/conda init bash . ./.bashrc pip install -r requirements.txt pip install omlutils-0.13.0-cp312-cp312-linux_x86_64.whl
  33. ONNXモデルへの変換 • 実⾏⽅法1︓事前構成済みのモデルから変換する (EmbeddingModelConfigのshow_preconfigured()関数で事前構成済みのモデルを確認できる) 上記内容を‘all_MiniLM_L6_v2.py’として作成し実⾏することで、 'all_MiniLM_L6_v2.onnx'が作成され、後述のデータダンプディレクトリにコピーする • 実⾏⽅法2︓テンプレートを設定して変換する ( EmbeddingModelConfigのshow_templates()関数で既存のテンプレートを確認できる)

    上記内容を‘e5_small_v2.py’として作成し実⾏することで、 ' e5_small_v2.onnx'が作成され、後述のデータダンプディレクトリにコピーする ONNXモデルの準備 Copyright © 2024, Oracle and/or its affiliates 39 from omlutils import EmbeddingModel, EmbeddingModelConfig em = EmbeddingModel(model_name="sentence-transformers/all-MiniLM-L6-v2") em.export2file("all_MiniLM_L6_v2", output_dir=".") from omlutils import EmbeddingModel, EmbeddingModelConfig config = EmbeddingModelConfig.from_template("text",max_seq_length=512) em = EmbeddingModel(model_name="intfloat/e5-small-v2", config=config) em.export2file("e5_small_v2",output_dir=".")
  34. ユーザーの作成と権限の付与 1. SQL*PlusでSYSDBAとしてPDBに接続 2. dmuserにDBA権限を付与 3. dmuserにCREATE MINING MODEL権限を付与 4.

    ワーキングフォルダをデータダンプディレクトリ(ONNX形式モデルをここのコピー)として設定 5. DM_DUMPディレクトリに対してdmuserにREAD権限を付与 ONNXモデルのインポート SQL> CONN sys/<password>@pdb as sysdba; SQL> GRANT dba TO dmuser identified by <password>; SQL> GRANT create mining model TO dmuser; CREATE OR REPLACE DIRECTORY DM_DUMP as '<work directory path>'; Copyright © 2024, Oracle and/or its affiliates 40 GRANT READ ON DIRECTORY dm_dump TO dmuser;
  35. 実⾏例1(DBMS_DATA_MINING.IMPORT_ONNX_MODELを使⽤) 1. SQL*PlusでdmuserとしてPDBに接続 2. PL/SQLヘルパーブロックを使⽤して、ONNX形式のモデルをOracleデータベースにインポート ONNXモデルのインポート SQL> CONN dmuser/<password>@<pdbname>; SQL>

    DECLARE m_blob BLOB default empty_blob(); m_src_loc BFILE ; BEGIN DBMS_LOB.createtemporary (m_blob, FALSE); m_src_loc := BFILENAME('DM_DUMP', 'all_MiniLM_L6_v2.onnx'); DBMS_LOB.fileopen(m_src_loc, DBMS_LOB.file_readonly); DBMS_LOB.loadfromfile(m_blob, m_src_loc, DBMS_LOB.getlength(m_src_loc)); DBMS_LOB.CLOSE(m_src_loc); DBMS_DATA_MINING.import_onnx_model ('doc_model', m_blob, JSON('{"function" : "embedding", "embeddingOutput" : "embedding", "input": {"input": ["DATA"]}}')); DBMS_LOB.freetemporary (m_blob); END; / Copyright © 2024, Oracle and/or its affiliates 41
  36. 実⾏例2(DBMS_VECTOR.LOAD_ONNX_MODELを使⽤) 1. SQL*PlusでdmuserとしてPDBに接続 2. PL/SQLヘルパーブロックを使⽤して、ONNX形式のモデルをOracleデータベースにインポート ONNXモデルのインポート SQL> CONN dmuser/<password>@<pdbname>; SQL>

    EXECUTE DBMS_VECTOR.LOAD_ONNX_MODEL('DM_DUMP', 'all_MiniLM_L6_v2.onnx', 'doc_model', JSON('{"function" : "embedding", "embeddingOutput" : "embedding", "input": {"input": ["DATA"]}}')); Copyright © 2024, Oracle and/or its affiliates 42
  37. ONNXモデルの確認とEMBEDDINGS処理の使⽤例 1. インポートしたONNXモデルを確認 2. ONNXモデルを使⽤して、EMBEDDINGS処理を実⾏ ONNXモデルのインポート SQL> SELECT model_name, attribute_name,

    attribute_type, data_type, vector_info FROM user_mining_model_attributes WHERE model_name = 'DOC_MODEL' ORDER BY ATTRIBUTE_NAME; SQL> SELECT MODEL_NAME, MINING_FUNCTION, ALGORITHM,ALGORITHM_TYPE, MODEL_SIZE FROM user_mining_models WHERE model_name = 'DOC_MODEL' ORDER BY MODEL_NAME; SQL> var embed_genai_params clob; SQL> exec :embed_genai_params := '{"provider": "database", "model": "doc_model"}'; SQL> select et.* from dbms_vector_chain.utl_to_embeddings('hello', json(:embed_genai_params)) et; Copyright © 2024, Oracle and/or its affiliates 43
  38. select DBMS_VECTOR_CHAIN.UTL_TO_TEXT ( t.blobdata, json('{ "charset":"UTF8" }') ) from tab

    t; • 必ずしも全ての処理を実⾏する必要はなく利⽤シーンに応じて単体でも、全てを組み合わせて1SQLでも利⽤可能 • 例1︓UTL_TO_TEXT単体で利⽤ • 例2︓UTL_TO_TEXT、UTL_TO_CHUNKS、UTL_TO_EMBEDDINGSの3つを1SQLで利⽤ 利⽤イメージ DBMS_VECTOR_CHAINパッケージ Copyright © 2024, Oracle and/or its affiliates 46 SELECT et.* from documentation_tab dt,dbms_vector.utl_to_embeddings(dbms_vector.utl_to_chunks(dbms_vector.utl_to_text(dt.data)), json(:embed_params)) et;
  39. • それぞれのパッケージで抽出した内容を、別の表や列としてテーブルに格納することが可能 • 例1︓チャンク時にパラメータを変えたデータを別表として保持し複数の表で試しながら精度確認 利⽤イメージ DBMS_VECTOR_CHAINパッケージ Copyright © 2024, Oracle

    and/or its affiliates 47 ID pos siz chunk 1 1 50 Oracle Database Data Warehousing Guide to learn about 2 51 50 nmechanisms¥n¥n ¥n¥nOvervie w of Extraction, Transformation, and Loading (ETL) ID pos siz chunk 1 1 100 Oracle Database Data Warehousing Guide to learn about nmechanisms¥n¥n ¥n¥nOvervie w of Extraction, Transformation, and Loading (ETL) 2 101 100 ………….
  40. • それぞれのパッケージで抽出した内容を、別の表や列としてテーブルに格納することが可能 • 例2︓Embeddingモデルを複数試す際に、モデルごとに別列にデータを格納しておくことで精度⽐較が容易に 利⽤イメージ DBMS_VECTOR_CHAINパッケージ Copyright © 2024, Oracle

    and/or its affiliates 48 商品ID 商品名 商品概要 商品画像 商品価格 商品概要 _Vec_Model1 商品概要 _Vec_Model2 1001 Oracle Red Bull Racing バックパック オラクル レッドブル F1 レー シング チーム公式商品グッ ズ サイズ:約 40.5cm×28cm×14cm - 7,700 -9.76553112E-002,- 9.89954844E- 002,7.69771636E- 003,-4.16760892E- 003,-9.69305634E- 002, -2.86354572E-002,- 7.56499246E-002,- 4.16395674E-003,- 1.52879998E- 001,6.60010576E- 002, 1002 Oracle Red Bull Racing ジャケット メイン素材: ポリエステル(。 前⾯は防⾵素材、後⾯はフ リース素材で、 - 13,000 3.01141385E-002,- 2.63396613E-002,- 2.98553891E- 002,5.96499592E- 002,4.13885899E- 002, -7.82847106E- 002,3.34323719E- 002,8.03267583E- 002,1.70483496E- 002,-
  41. ドキュメントをテキスト化し取り込むパッケージ 概要 • PDF、 DOC、JSON、XML、HTMLなどのドキュメントからテキストを抽出することが可能 • サポートされるドキュメント形式は下記内容を参照 Oracle® Text リファレンス

    23c - B.2 サポートされているドキュメント形式 • 抽出したテキストはCLOBとして出⼒ • メリット • Oracle Databaseのパッケージとして機能を持つことで データベース内で、データベースリソースを使ってドキュメントのテキスト化が可能 • 格納されたLOBデータをUTL_TO_CHUNK、UTL_TO_EMBEDDINGSなどの DBMS_VECTOR_CHAINパッケージと組み合わせることでEMBEDDINGSまでの⼀連の処理を実⾏可能 DBMS_VECTOR_CHAIN.UTL_TO_TEXT Copyright © 2024, Oracle and/or its affiliates 49 DBMS_VECTOR_CHAIN.UTL_TO_TEXT ( DATA IN CLOB | BLOB, PARAMS IN JSON default NULL ) return CLOB; ドキュメント テキスト UTL_TO_TEXT()
  42. 実⾏例 1. 対象となるドキュメントの格納場所をディレクトリオブジェクトとして定義 2. 対象のテーブルを作成しBLOB列を定義 3. ドキュメントを指定してBLOBにINSERT 4. INSERTしたデータの確認 DBMS_VECTOR_CHAIN.UTL_TO_TEXT

    SQL> create or replace directory VEC_DUMP as '/home/oracle/pdf_doc'; SQL> CREATE TABLE documentation_tab (id number, data blob); SQL> INSERT INTO documentation_tab values(1, to_blob(bfilename('VEC_DUMP', ‘sample.pdf'))); SQL> SELECT dbms_vector_chain.utl_to_text(dt.data) from documentation_tab dt; DBMS_VECTOR_CHAIN.UTL_TO_TEXT(DT.DATA) -------------------------------------------------------------------------------- Database Concepts 23c Oracle Database Database Concepts, 23c This software and related documentation are provided under a license agreement containing restrictions on Copyright © 2024, Oracle and/or its affiliates 50
  43. テキストデータのチャンク分割 概要 • ⼤規模なテキストデータをチャンクに分割が可能 • 単語、⽂、段落でのチャンク分割が可能 メリット • Oracle Databaseのパッケージとして機能を持つことで

    データベース内で、データベースリソースを使ってチャンク分割が可能 • 特にデータベースの中にベクトル化したいデータが格納されている場合、データベース内で処理が完結する • 格納されたLOBデータをUTL_TO_TEXT、UTL_TO_EMBEDDINGSなどの DBMS_VECTOR_CHAINパッケージと組み合わせることでEMBEDDINGSまでの⼀連の処理を実⾏可能 DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS ( DATA IN CLOB | VARCHAR2 PARAMS IN JSON default NULL ) return VECTOR_ARRAY_T; Copyright © 2024, Oracle and/or its affiliates 52 テキスト {TEXT} チャンク UTL_TO_CHUNKS()
  44. 実⾏例 • UTL_TO_TEXTで抽出したテキストをUTL_TO_CHUNKSを使ってチャンク分割した例 DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS SQL> SELECT ct.* from documentation_tab dt,

    dbms_vector_chain.utl_to_chunks(dbms_vector_chain.utl_to_text(dt.dat a)) ct; DATA -------------------------------------------------------------------------------- {"chunk_id":1,"chunk_offset":1508024,"chunk_length":579,"chunk_data" :"Inventory ¥n¥n¥n¥nAnalysis ¥n¥n¥n¥nReporting ¥n¥n¥n¥nMining¥n¥n¥n¥nSummary ¥n¥n¥n¥nData ¥n¥n¥n¥nRaw Data¥n¥n¥n¥nMetadata¥n¥n¥n¥nSee Also:¥n¥n¥n¥nOracle Database Data Warehousing Guide to learn about transformation ¥n¥n¥n¥nmechanisms¥n¥n¥n¥nOvervie w of Extraction, Transformation, and Loading (ETL) ¥n¥n¥n¥nThe {"chunk_id":2,"chunk_offset":1508603,"chunk_length":607,"chunk_data":"phys ica lly transported to the target system or an intermediate system for processing. ¥ n¥n¥n¥nDepending on the method of transportation, some transformations can occur during this ¥n¥n¥n¥nprocess. For example, a SQL statement that directly accesse s a remote target through a ¥n¥n¥n¥ngateway can concatenate two columns as part of the ~~~ Copyright © 2024, Oracle and/or its affiliates 54
  45. 実⾏例 • 出⼒されるID、元テキストの位置、⻑さ、データは全て別々に取り出し列として表に格納可能 DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS Copyright © 2024, Oracle and/or its

    affiliates 55 SELECT D.id doc, JSON_VALUE(C.column_value, '$.chunk_id' RETURNING NUMBER) AS id, JSON_VALUE(C.column_value, '$.chunk_offset' RETURNING NUMBER) AS pos, JSON_VALUE(C.column_value, '$.chunk_length' RETURNING NUMBER) AS siz, JSON_VALUE(C.column_value, '$.chunk_data') AS chunk FROM docs D, dbms_vector_chain.utl_to_chunks(D.text, JSON('{ "by":"CHARACTERS", "max":”50", "overlap":"0", "split":"recursively", "language":"american", "normalize":"all" }')) C; ID pos siz chunk txt_vec_model1 txt_vec_model2 1 1 50 Oracle Database Data Warehousing Guide to learn about -9.76553112E-002,- 9.89954844E- 002,7.69771636E-003,- 4.16760892E-003,- 9.69305634E-002, -2.86354572E-002,- 7.56499246E-002,- 4.16395674E-003,- 1.52879998E- 001,6.60010576E-002, 2 51 50 Transformation ----- -------- 3.01141385E-002,- 2.63396613E-002,- 2.98553891E- 002,5.96499592E- 002,4.13885899E-002, -7.82847106E- 002,3.34323719E- 002,8.03267583E- 002,1.70483496E-002,- 抽出SQL例 格納例
  46. パラメータ • JSON形式でパラメータを指定可能 • 指定したパラメータの値によってチャンク動作が変化 • 指定可能なパラメータ表 - 1 DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS

    JSON('{ "by":"vocabulary", "vocabulary":"myvocab", "max":"100", "overlap":"0", "split":"custom", "custom_list": [ "<p>" , "<s>" ], "language":"american", "normalize":"options", "norm_options": [ "WHITESPACE" ] }') Copyright © 2024, Oracle and/or its affiliates 56 パラメータ 説明 指定可能な値 補⾜ by データ分割の⽅法を⽂字、単語、 語彙トークンで指定 デフォルト:by words by characters ⽂字数で計算して分割 by words 単語数を計算して分割 単語ごとに空⽩⽂字が⼊る⾔語が対象 ⽇本語、中国語、タイ語などの場合、 1⽂字が1単語としてみなされる by vocabulary 語彙のトークン数を計算して分割 CREATE_VOCABULARYパッケージを使って 語彙登録が可能 max データ分割の⽅法に応じてそれぞれの⽅法に おける最⼤数を指定 ここで指定した最⼤数に 達したときにデータを分割する デフォルト︓100 50〜4000 by charactersの場合 10〜1000 by wordsの場合 10〜1000 by vocabularyの場合
  47. パラメータ • 指定可能なパラメータ表 - 2 DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS Copyright © 2024, Oracle

    and/or its affiliates 57 パラメータ 説明 指定可能な値 補⾜ split [by] テキストが最⼤サイズに達したときに、 どうやって分割するかを指定 チャンクの適切な境界を 定義するために使⽤する デフォルト︓recursively none max指定されている⽂字数、単語数、 語彙トークン数に達したら分割 newline max指定サイズを超えてテキストの⾏末で分割 blankline max指定サイズを超えて blankline(2回の改⾏)の末尾で分割 space max指定サイズを超えて空⽩の⾏末で分割 recursively blankline、newline、space、noneの 順に条件に応じて分割する 1.⼊⼒テキストがmax値以上の場合、最初の分割⽂字で分割 2.1.が失敗した場合に、2番⽬の分割⽂字で分割 3.分割⽂字が存在しない場合、テキスト中の どの位置においてもmaxで分割 sentence ⽂末の句読点で分割 by wordsとby vocabularyでのみ指定可能 max設定の仕⽅によっては必ず句読点で 区切られるわけではないので注意 例えば、⽂がmax値よりも⼤きい場合、max値で区切られる max値よりも⼩さな⽂の場合で、 2⽂以上がmaxの制限内に収まるのであれば1つに収める custom カスタム分割⽂字リストに基づいて分割 分割⽂字は最⼤16個まで、 ⻑さはそれぞれ10⽂字までで指定可能 例えばVECTOR_CHUNKS(c. doc, by character split custom ('<html>' , '</html>')) vc
  48. パラメータ • 指定可能なパラメータ表 - 3 DBMS_VECTOR_CHAIN.UTL_TO_CHUNKS Copyright © 2024, Oracle

    and/or its affiliates 58 パラメータ 説明 指定可能な値 補⾜ overlap チャンクに含まれる 前チャンクの最後の⽂字数を指定 前チャンクと重複して テキストを持つことができる デフォルト︓0 max値で指定したサイズの 5%〜20% 重複されるサイズの計算⽅法は byパラメータで指定したモードによって異なる normalize ドキュメントをテキストに変換する際に ありがちな問題について、⾃動的に前処理、 後処理を実⾏し⾼品質なチャンクとして 格納するために使⽤ デフォルト︓none none 処理を⾏わない all マルチバイトの句読点をシングルバイトに正規化 punctuation スマート引⽤符、スマートハイフン、マルチバイト句読点を テキストに含める whitespace 不要な⽂字を削除して空⽩を最⼩限に抑える 例えば空⽩⾏はそのままに、 余分な改⾏やスペース、タブを削除する widechar マルチバイト数字とローマ字をシングルバイトに正規化する extended 初期化パラメータのMAX_STRING_SIZE パラメータをentendedに設定することなく、 VARCHAR2の⽂字列の出⼒制限を 32767バイトに増加させる デフォルトはMAX_STRING_SIZEの設定 値によって変化し、STANDARDの場合は 4000、EXTENDEDの場合は32,767 4000 or 32767 MAX_STRING_SIZEはデフォルトSTANDARDであり、 4000バイトまでが制限となる これを拡⼤する場合通常はEXTENDEDに変更する必要があ るが、⼀度変更すると元に戻すことができない そのためCDB、PDBレベルでこのような変更を加えたくない場合 に使⽤する
  49. {TEXT} チャンク UTL_TO_SUMMARY() {TEXT} 要約 テキストデータの要約 概要 • テキスト化したデータやチャンク分割したデータを要約することができる •

    Oracle Textのパッケージを使ったデータベース内での実⾏や REST APIを使ったOCI GenAIでのでの実⾏が可能 メリット • テキストデータを要約することで、⼤規模で複雑なデータから意味のあるコンテンツを抽出することが可能 • 要約したデータをEmbeddingすることで精度が向上する可能性がある • サマリ前のデータとサマリ後のデータをそれぞれ保持し、マルチベクトル検索をかけるなど 精度向上に向けた試⾏錯誤の⼀つに利⽤可能 DBMS_VECTOR_CHAIN.UTL_TO_SUMMARY DBMS_VECTOR_CHAIN.UTL_TO_SUMMARY ( DATA IN CLOB, PARAMETERS IN JSON default NULL ) return CLOB; Copyright © 2024, Oracle and/or its affiliates 59
  50. DBMS_VECTOR_CHAIN.UTL_TO_SUMMARY select dbms_vector_chain.utl_to_summary( 'A transaction is a logical, atomic unit

    of work that contains one or more SQL statements. An RDBMS must be able to group SQL statements so that they are either all committed, which means they are applied to the database, or all rolled back, which means they are undone. An illustration of the need for transactions is a funds transfer from a savings account to a checking account. The transfer consists of the following separate operations: 1. Decrease the savings account. 2. Increase the checking account. 3. Record the transaction in the transaction journal. Oracle Database guarantees that all three operations succeed or fail as a unit. For example, if a hardware failure prevents a statement in the transaction from executing, then the other statements must be rolled back. Transactions set Oracle Database apart from a file system. If you perform an atomic operation that updates several files, and if the system fails halfway through, then the files will not be consistent. In contrast, a transaction moves an Oracle database from one consistent state to another. The basic principle of a transaction is all or nothing: an atomic operation succeeds or fails as a whole.', json(:summarize_genai_params)) from dual; A transaction is a logical unit of work that groups one or more SQL statements that must be executed as a unit, with all statements succeeding, or all statements being rolled back. Transactions are a fundamental concept in relational database management systems (RDBMS), and Oracle Database is specifically designed to manage transactions, ensuring database consistency and integrity. Transactions differ from file systems in that they maintain atomicity, ensuring that all related operations succeed or fail as a whole, maintaining database consistency regardless of intermittent failures. Transactions move a database from one consistent state to another, and the fundamental principle is that a transaction is committed or rolled back as a whole, upholding the "all or nothing" principle. PL/SQL procedure successfully completed. Copyright © 2024, Oracle and/or its affiliates 60 要約のイメージ
  51. 実⾏⼿順(OCI GenAIの場合) 1. DBMS_NETWORK_ACL_ADMINを使⽤してホストに権限付与 2. DBMS_VECTOR_CHAIN.CREATE_CREDENTIALを使⽤してOCIの資格証明を作成 DBMS_VECTOR_CHAIN.UTL_TO_SUMMARY BEGIN DBMS_NETWORK_ACL_ADMIN.APPEND_HOST_ACE( host

    => '*', ace => xs$ace_type(privilege_list => xs$name_list('connect'), principal_name => 'docuser', principal_type => xs_acl.ptype_db)); END; / Copyright © 2024, Oracle and/or its affiliates 61 declare jo json_object_t; begin -- create an OCI credential jo := json_object_t(); jo.put('user_ocid','ocid1.user.oc1..aabbalbbaa1112233aabbaabb1111222aa1111bb'); jo.put('tenancy_ocid','ocid1.tenancy.oc1..aaaaalbbbb1112233aaaabbaa1111222aaa111a'); jo.put('compartment_ocid','ocid1.compartment.oc1..ababalabab1112233abababab1111222aba11ab'); jo.put('private_key','AAAaaaBBB11112222333...AAA111AAABBB222aaa1a/+'); jo.put('fingerprint','01:1a:a1:aa:12:a1:12:1a:ab:12:01:ab:a1:12:ab:1a'); dbms_output.put_line(jo.to_string); dbms_vector_chain.create_credential( credential_name => 'OCI_CRED', params => json(jo.to_string)); end; /
  52. 実⾏⼿順(OCI GenAIの場合) 3. UTL_TO_SUMMARYを実⾏ DBMS_VECTOR_CHAIN.UTL_TO_SUMMARY Copyright © 2024, Oracle and/or

    its affiliates 62 var summarize_genai_params clob; exec :summarize_genai_params := ' { "provider": "ocigenai", "credential_name": "OCI_CRED", "url": "<ocigenai summarize api endpoint url>", "model": "<ocigenai model file name>" }'; select dbms_vector_chain.utl_to_summary( 'A transaction is a logical, atomic unit of work that contains one or more SQL statements. An RDBMS must be able to group SQL statements so that they are either all committed, which means they are applied to the database, or all rolled back, which means they are undone. An illustration of the need for transactions is a funds transfer from a savings account to a checking account. The transfer consists of the following separate operations: 1. Decrease the savings account. 2. Increase the checking account. 3. Record the transaction in the transaction journal. Oracle Database guarantees that all three operations succeed or fail as a unit. For example, if a hardware failure prevents a statement in the transaction from executing, then the other statements must be rolled back. Transactions set Oracle Database apart from a file system. If you perform an atomic operation that updates several files, and if the system fails halfway through, then the files will not be consistent. In contrast, a transaction moves an Oracle database from one consistent state to another. The basic principle of a transaction is all or nothing: an atomic operation succeeds or fails as a whole.', json(:summarize_genai_params)) from dual;
  53. 実⾏⼿順(OCI GenAIの場合) 4. 実⾏結果 DBMS_VECTOR_CHAIN.UTL_TO_SUMMARY Copyright © 2024, Oracle and/or

    its affiliates 63 A transaction is a logical unit of work that groups one or more SQL statements that must be executed as a unit, with all statements succeeding, or all statements being rolled back. Transactions are a fundamental concept in relational database management systems (RDBMS), and Oracle Database is specifically designed to manage transactions, ensuring database consistency and integrity. Transactions differ from file systems in that they maintain atomicity, ensuring that all related operations succeed or fail as a whole, maintaining database consistency regardless of intermittent failures. Transactions move a database from one consistent state to another, and the fundamental principle is that a transaction is committed or rolled back as a whole, upholding the "all or nothing" principle. PL/SQL procedure successfully completed.
  54. テキストおよびチャンク配列をベクトル形式にEMBEDDING 概要 • 次の3つの⽅法でEMBEDDINGを実施 • サービスプロバイダとしてOracle Databaseにアクセス • 事前に学習したONNX形式のベクトル埋め込みモデルを呼び出す •

    OCI Generative AIなどのサードパーティ・サービス・プロバイダーのREST API呼び出し • UTL_TO_EMBEDDINGはテキスト、 UTL_TO_EMBEDDINGSはチャンクの配列が対象 • メリット • Oracle Databaseのパッケージとして機能を持つことでデータベース内で、データベースリソースを使ってテキストのベ クトルデータ化が可能 • 格納されたLOBデータをUTL_TO_CHUNK、UTL_TO_EMBEDDINGSなどの DBMS_VECTOR_CHAINパッケージと組み合わせることでEMBEDDINGSまでの⼀連の処理を実⾏可能 DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDING/ UTL_TO_EMBEDDINGS Copyright © 2024, Oracle and/or its affiliates 64 DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDING ( DATA IN CLOB, PARAMS IN JSON default NULL ) return VECTOR; 7149 ベクトルデータ UTL_TO_EMBEDDINGS() {TEXT} テキスト DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDINGS ( DATA IN VECTOR_ARRAY_T, PARAMS IN JSON default NULL ) return VECTOR_ARRAY_T;
  55. 出⼒データ • UTL_TO_EMBEDDINGはtext (CLOB)をVECTOR型に変換 • UTL_TO_EMBEDDINGSはチャンクの配列(VECTOR_ARRAY_T)を エンベディングの配列(VECTOR_ARRAY_T)に変換 • 出⼒内容 DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDING/

    UTL_TO_EMBEDDINGS Copyright © 2024, Oracle and/or its affiliates 65 { "embed_id":NUMBER, "embed_data":"VARCHAR2(4000)", "embed_vector":"CLOB" } embed_id︓各エンベディング毎に採番されるエンベディングID embed_data︓エンベディングされた⼊⼒テキスト embed_vector︓⽣成されたベクトル表現
  56. パラメータ • JSON形式でパラメータを指定 • UTL_TO_EMBEDDINGSはチャンクの配列(VECTOR_ARRAY_T) 、 エンベディングの配列(VECTOR_ARRAY_T)に 変換 • 出⼒内容

    DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDING/ UTL_TO_EMBEDDINGS Copyright © 2024, Oracle and/or its affiliates 66 { "provider":"Database (default) | User | OCIGenAI | HuggingFace" "credential_name":"credential name", "url":"url value", "model":"model name" }
  57. パラメータ DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDING/ UTL_TO_EMBEDDINGS Copyright © 2024, Oracle and/or its affiliates

    67 パラメータ 説明 指定可能な値 補⾜ Provider エンベディングを⽣成するためにアクセスする サービスプロバイダ デフォルト︓Database Database Oracle Databaseに組み込まれているデフォルトのONNXモデ ルを使⽤ User ユーザー⾃⾝のスキーマにロードしたユーザー定義のONNXモデ ルを使⽤ OCIGenAI|HaggingFace OCIGenAIやHugging Faceなどサポートされている外部プロ バイダを指定。それぞれのONNXモデルをデータベースにロードす ることができます。 credential_name クレデンシャルの名前 schema.credential_name REST APIコールを⾏うためのAIプロバイダーへのアクセスを可 能にする認証クレデンシャル。事前に DBMS_VECTOR_CHAIN.CREATE_CREDENTIALを実 ⾏し、ここで作成したクレデンシャル名を使⽤ url 外部プロバイダーへの各RESTコールのAPIエ ンドポイントのURL model モデルの名前 schema.model_name モデル名がスキーマ修飾されていない場合、プロシージャ呼び出 し元のスキーマが使⽤されます。 ONNX形式の埋め込みモデルが事前に⽤意されていない場合 は、「事前学習済みモデルのONNX形式への変換について」に 記載されている⼿順を実⾏してください。 正確な結果を得るためには、選択したモデルがチャンキングに使⽤した語彙ファイルと⼀致していることを確認してください。 語彙ファイルを使⽤しない場合は、⼊⼒⻑がモデルのトークン制限内に定義されていることを確認してください。
  58. 実⾏例 • UTL_TO_CHUNKSでのチャンキング結果を、load_onnx_modelプロシージャでdatabaseにロードしたモデルを使⽤ してエンベディングを実施 DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDINGS Copyright © 2024, Oracle and/or

    its affiliates 68 CREATE OR REPLACE PROCEDURE load_onnx_model ( file_name VARCHAR2, model_name VARCHAR2, metadata JSON ) AS m_blob BLOB default empty_blob(); m_src_loc BFILE ; BEGIN DBMS_LOB.createtemporary (m_blob, FALSE); m_src_loc := BFILENAME('VEC_DUMP', file_name); DBMS_LOB.fileopen (m_src_loc, DBMS_LOB.file_readonly); DBMS_LOB.loadfromfile (m_blob, m_src_loc, DBMS_LOB.getlength (m_src_loc)); DBMS_LOB.CLOSE(m_src_loc); DBMS_DATA_MINING.import_onnx_model (model_name, m_blob, metadata); DBMS_LOB.freetemporary (m_blob); END load_onnx_model; / SHOW ERRORS; a. load_onnx_modelプロシージャを使⽤してモデルをロードする
  59. 実⾏例 DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDINGS Copyright © 2024, Oracle and/or its affiliates 69

    EXECUTE dbms_data_mining.drop_model(model_name => 'doc_model',force => true); execute load_onnx_model('my_embedding_model.onnx', 'doc_model', json('{"function" : "embedding", "embeddingOutput" : "embedding" , "input": {"input": ["DATA"]}}')); b. load_onnx_modelプロシージャを使⽤して、dropして、事前訓練済みのONNXモデル (my_embedding_model.onnx)をload my_embedding_model.onnxを、embeddingモデルのONNXエクスポートで置き換えてください。ここで、 doc_modelは、インポートされたモデルがOracle Databaseに格納される名前を指定します。 ONNX形式のembeddingモデルが事前に⽤意されていない場合は、「About Converting Pretrained Models to ONNX Format.」に記載されている⼿順を実⾏してください。 c. embeddingパラメータ(embed_params)を指定 var embed_params clob; exec :embed_params := '{"provider":"database", "model":"doc_model"}';
  60. 実⾏例 DBMS_VECTOR_CHAIN.UTL_TO_EMBEDDINGS Copyright © 2024, Oracle and/or its affiliates 70

    SELECT et.* from documentation_tab dt, dbms_vector_chain.utl_to_embeddings( dbms_vector_chain.utl_to_chunks(dbms_vector_chain.utl_to_text(dt.data) ), json(:embed_params)) et; --実⾏結果 DATA -------------------------------------------------------------------------------- {"embed_id":"1","embed_data":"5-4¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥nD:20231208125114-08'00'¥n¥n¥n¥n10- 7¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥nD:20231208125114-08'00'¥n¥n¥n¥n4- 29¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥nD:20231208125114-08'00' ¥n¥n¥n¥n10- 1¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥nD:20231208125114-08'00'¥n¥n¥n¥n17- 21¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥nD:20231208125114-08'00'¥n¥n¥n¥n10- 2¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥nD:20231208125114-08'00'¥n¥n¥n¥n10- 22¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥nD:20231208125114-08'00'¥n¥n¥n¥n1- 6¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥nD:20231208125114-08'00'¥n¥n¥n¥n10- 3¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥n¥nD:20231208125114-08'00'","embed_vector":"[0.125467107,0.0850959048,- 0.0207406133,0.0 0123620778,0.0244407952,-0.0361999273,-0.0162772723,0.210277647,0.0756126642,-0.0884471983, ・・・ (以下略) d. UTL_TO_EMBEDDINGSを実⾏し、チャンクに対応したVECTORエンベディングを⽣成する
  61. BY WORDs MAX 40=最⼤40語で区切る ※CHUNK_LENGTHは⽂字数 BY VOCABULARY xxx MAX 40

    = 最⼤40トークン で区切る DBMS_VECTOR_CHAIN.CREATE_VOCABULARY SQL> SELECT D.id doc, C.chunk_offset pos, C.chunk_length siz, C.chunk_text txt FROM en_tab D, VECTOR_CHUNKS (D.text BY WORDs MAX 40 OVERLAP 0 SPLIT BY recursively LANGUAGE ENGLISH NORMALIZE all) C ; CHUNK_OFFSET CHUNK_LENGTH CHUNK_TEXT ----------------------------------------------- 1 104 Oracle AI Vector Search stores and indexes vector embeddings for fast retrieval and similarity search. 109 230 About Oracle AI Vector Search Vector Indexes are a new classification of specialized indexes that are designed for Artificial Intelligence (AI) workloads that allow you to query data based on semantics, rather than keywords. SQL> SELECT D.id doc, C.chunk_offset pos, C.chunk_length siz, C.chunk_text txt FROM en_tab D, VECTOR_CHUNKS (D.text BY VOCABULARY doc_vocab MAX 40 OVERLAP 0 SPLIT BY recursively LANGUAGE ENGLISH NORMALIZE all) C ; CHUNK_OFFSET CHUNK_LENGTH CHUNK_TEXT ------------------------------------------------- 1 104 Oracle AI Vector Search stores and indexes vector embeddings for fast retrieval and similarity search. 109 30 About Oracle AI Vector Search 143 148 Vector Indexes are a new classification of specialized indexes that are designed for Artificial Intelligence (AI) workloads that allow you to query 291 48 data based on semantics, rather than keywords. Copyright © 2024, Oracle and/or its affiliates 73 単語ごと/トークンごとのチャンキング⽐較
  62. トークンごとのチャンキング実⾏例 英語の場合: トークンには各単語の断⽚が含まれることがあるため、同じMAX値で⽐較すると、通常チャンク・サイズは単語 分割よりも⼩さくなる (例) playing(1語) → play + ###ing(2トークン)

    ⽇本語の場合: 1⽂字単位で語彙登録されているトークナイザだと最⼤トークン数≒最⼤⽂字数となるので、あまり違いは ない DBMS_VECTOR_CHAIN.CREATE_VOCABULARY SQL> SELECT D.id doc, C.chunk_offset pos, C.chunk_length siz, C.chunk_text txt FROM en_tab D, VECTOR_CHUNKS (D.text BY VOCABULARY doc_vocab MAX 40 OVERLAP 0 SPLIT BY recursively LANGUAGE ENGLISH NORMALIZE all) C ; CHUNK_OFFSET CHUNK_LENGTH CHUNK_TEXT -------------------------------------------------------------------------------------------------- 1 104 Oracle AI Vector Search stores and indexes vector embeddings for fast retrieval and similarity search. 109 30 About Oracle AI Vector Search 143 148 Vector Indexes are a new classification of specialized indexes that are designed for Artificial Intelligence (AI) workloads that allow you to query 291 48 data based on semantics, rather than keywords. Copyright © 2024, Oracle and/or its affiliates 74
  63. 実⾏⼿順 1. 使⽤する語彙ファイル(my_model_vocabulary.txt)の格納場所をディレクトリオブジェクトとして定義 2. 語彙トークンを格納する表を定義 DBMS_VECTOR_CHAIN.CREATE_VOCABULARY SQL> create or replace

    directory VEC_DUMP as '/home/oracle/vocab/'; SQL> CREATE TABLE documentation_tab (id number, data clob) CREATE TABLE doc_vocabtab(token nvarchar2(64)) ORGANIZATION EXTERNAL (default directory VEC_DUMP ACCESS PARAMETERS (RECORDS DELIMITED BY NEWLINE) location ('my_model_vocabulary.txt'));; Copyright © 2024, Oracle and/or its affiliates 75
  64. 実⾏⼿順 3. 語彙トークンの作成 4. (オプション) USER_VECTOR_VOCAB_TOKENSビューで各トークンを確認可能 DBMS_VECTOR_CHAIN.CREATE_VOCABULARY DECLARE parameters clob

    := '{"table_name" : "doc_vocabtab", "column_name" : "token", "vocabulary_name" : "doc_vocab", "format" : "bert", "cased" : false}'; BEGIN dbms_vector_chain.create_vocabulary(json(params)); END; / SQL> select * from USER_VECTOR_VOCAB_TOKENS where vocab_token = 'vector'; VOCAB_NAME VOCAB_TOKEN ------------ --------------- DOC_VOCAB VECTOR Copyright © 2024, Oracle and/or its affiliates 76
  65. 実⾏⼿順 5. UTL_TO_CHUNKS / VECTOR_CHUNKSで語彙トークン単位でのチャンキング(BY VOCABULARY指定) 6. (オプション) 作成した語彙トークンの削除 DBMS_VECTOR_CHAIN.CREATE_VOCABULARY

    SQL> SELECT D.id doc, C.chunk_offset pos, C.chunk_length siz, C.chunk_text txt FROM en_tab D, VECTOR_CHUNKS (D.text BY VOCABULARY doc_vocab MAX 40 OVERLAP 0 SPLIT BY recursively LANGUAGE ENGLISH NORMALIZE all) C ; CHUNK_OFFSET CHUNK_LENGTH CHUNK_TEXT ------------------------------------------------------------------------------------------------ 1 104 Oracle AI Vector Search stores and indexes vector embeddings for fast retrieval and similarity search. 109 30 About Oracle AI Vector Search 143 148 Vector Indexes are a new classification of specialized indexes that are designed for Artificial Intelligence (AI) workloads that allow you to query 291 48 data based on semantics, rather than keywords. Copyright © 2024, Oracle and/or its affiliates 77 BEGIN dbms_vector_chain.drop_vocabulary('doc_vocab'); END; /
  66. ⾔語特有の省略形トークンの登録 英語の場合 • ⽂末は[.](ピリオド)で終わるが、略語にも[.]を使うことがある • チャンカーが略語の[.]で⽂を区切らないように予め登録しておく • ⼀般的によく使われる略語についてはデフォルトで区切られないよう登録されている(追加可能) ⽇本語の場合 •

    ⽂末は[。](句点)で終わり、略語に[。]を使うことがない • ⽂末と判定してほしくないピリオドで区切る単語を登録する DBMS_VECTOR_CHAIN.CREATE_LANG_DATA Copyright © 2024, Oracle and/or its affiliates 79 Economist Prof. Johnson warns of economic downturn due to inflation and geopolitical tensions. Economist Prof. warns of economic downturn due to inflation and geopolitical tensions. Economist Prof. Johnson warns of economic downturn due to inflation and geopolitical tensions.
  67. 実⾏⼿順 1. 使⽤する⾔語データ(my_model_langdata.txt)の格納場所をディレクトリオブジェクトとして定義 2. 略語としてデフォルトの⾔語データファイルは$ORACLE_HOME/ctx/data/eos/dreosja.txt(⽇本語)に「題」を追加 3. ⾔語データを格納する表を定義 DBMS_VECTOR_CHAIN.CREATE_LANG_DATA SQL> create

    or replace directory VEC_DUMP as '/home/oracle/vocab/'; SQL> CREATE TABLE doc_langtab(token nvarchar2(64)) ORGANIZATION EXTERNAL (default directory VEC_DUMP ACCESS PARAMETERS (RECORDS DELIMITED BY NEWLINE CHARACTERSET AL32UTF8) location ('my_model_langdata.txt')); Copyright © 2024, Oracle and/or its affiliates 80 題 ← 追加 B C A BR CH … AVE Blvd COL Ave Br CORP
  68. 実⾏⼿順 4. ⾔語データの作成 DBMS_VECTOR_CHAIN.CREATE_LANG_DATA DECLARE parameters clob := '{"table_name" :

    "doc_langtab", "column_name" : "token", "language" : “JAPANESE", "preference_name" : "doc_lang_data"}'; BEGIN dbms_vector_chain.create_lang_data(json(params)); END; / Copyright © 2024, Oracle and/or its affiliates 81
  69. LANGUAGE Japanese(デフォルト)指定 「住居問題」の後のピリオドで⽂末と判定される LANGUAGE doc_lang_tab(カスタム⾔語データ)指定 「住居問題」の後のピリオドで⽂末と判定されない DBMS_VECTOR_CHAIN.CREATE_VOCABULARY SQL> SELECT D.id

    doc, C.chunk_offset pos, C.chunk_length siz, C.chunk_text txt FROM ja_tab D, VECTOR_CHUNKS (D.text BY WORDs MAX 40 OVERLAP 0 SPLIT BY sentence LANGUAGE japanese NORMALIZE all) C ; CHUNK_OFFSET CHUNK_LENGTH CHUNK_TEXT ----------------------------------------------- 1 120 33 ⼀⽅で、都内の住宅価格は上昇傾向にあり、若者や⼀般家庭の住居問題. 1 154 10 が深刻化しています。 SQL> SELECT D.id doc, C.chunk_offset pos, C.chunk_length siz, C.chunk_text txt FROM ja_tab D, VECTOR_CHUNKS (D.text BY WORDs MAX 40 OVERLAP 0 SPLIT BY sentence LANGUAGE doc_lang_tab NORMALIZE all) C ; CHUNK_OFFSET CHUNK_LENGTH CHUNK_TEXT ----------------------------------------------- 1 120 41 ⼀⽅で、都内の住宅価格は上昇傾向にあり、若者や⼀般家庭の住居問題. が深刻化 してい 1 161 3 ます。 Copyright © 2024, Oracle and/or its affiliates 82 実⾏⼿順