Oracle Autonomous AI Database の Data Science Agent を Llama 3.3 70B で試してみた

Posted at 2026-09-17

1. はじめに

2026 年 6 月 30 日に Oracle Autonomous AI Database Serverless に Data Science Agent が追加されました。リリースノートには、Oracle Machine Learning（OML）のチャット画面から "profile data, prepare features, train models, evaluate results, and generate inference SQL" ができ、処理は DB の中で実行される、とあります¹。

ユーザーズガイドには LLM を自分で用意すると書かれていて²、推奨モデルの表には GPT・Grok・Gemini・Claude が並び、Llama はありません³。一方で OCI Generative AI の大阪リージョンで使える meta.llama-3.3-70b-instruct をリソースプリンシパルで呼べば、API キーもネットワーク ACL も設定せずに利用できます。推奨表に無いこのモデルで Data Science Agent がどこまで進むのか、そして Always Free の Autonomous Database（1 OCPU と 20 GB の固定構成⁴）で動くのかを、SH スキーマ由来の 4,400行の 2 値分類で試します。OML UI にログインして、推論 SQL の取得まで 1 会話で進めます。

1.1. 結論（先出し）

Always Free の ADB と Llama 3.3 70B で、データ把握から特徴量の選択、学習、評価、推論 SQL の提示まで 1 会話で進んだ。ユーザーの送信は 4回、会話全体で 7 分半だった
会話の作成時に「Model is not recommended」の警告が出るが、Test は成功し、会話は作れる。「Improve Profile」が提案する代替は google.gemini-2.5-pro への差し替えだけだった
LLM が生成した本文中の推論 SQL は、今回の会話では Oracle の構文として無効だった（ORA-02012）。ツールが生成した「SQL Code for Manual Inference」パネルの SQL は実行でき、100行が返った。本文の SQL は LLM が書くたびに変わり得るので、コピーするのはパネルの方である
公式の例にある max_tokens: 8192 は Llama 3.3 70B では上限超えで呼び出しに失敗する。4096 にすると呼び出せる
Always Free の制約（HTTP 同時ユーザー数、PGA、セッション数）に該当するエラーは出なかった。学習は DBMS_SCHEDULER のジョブとして DB 内で実行され、91 秒のジョブのうち CPU は 6.4 秒だった

1.2. 検証ゴール

#	確かめること	確認できれば OK の条件
1	Always Free の ADB と Llama 3.3 70B で、データ把握、特徴量、分割、学習、評価、推論 SQL の 6 つの工程が OML UI の 1 会話で進むか	スキーマに分割ビューとマイニングモデルができ、UI が返した推論 SQL を SQL クライアントで実行すると 100件の予測と確率が返る
2	工程ごとの所要時間と生成物、DB 側の CPU 時間	工程ごとの所要秒、生成物の名前、アルゴリズム、評価指標が表になり、DB 側の SQL の CPU 時間と経過時間が取れる
3	Always Free 固有の制約に該当するエラーが出るか	出たならどの工程でどのエラーか、出なかったなら「出なかった」と書ける

2. 検証環境

項目	内容
ADB	ADBTEST01、Oracle AI Database 26ai Enterprise Edition Release 23.26.3.3.0、Always Free、ATP、ap-tokyo-1。公式の構成は 1 OCPU・20 GB でスケール不可⁴。DB 側は `cpu_count` 2（`v$license` の CPU_COUNT_CURRENT も 2）、`sessions` 30、`pga_aggregate_target` 3 GB、`pga_aggregate_limit` 約 5.9 GB
LLM	OCI Generative AI ap-osaka-1、`meta.llama-3.3-70b-instruct`。資格証明は `OCI$RESOURCE_PRINCIPAL`
OML UI	ユーザー DBA_COPILOT、Service Level（会話ごとに選ぶ DB サービスの優先度。4.1 章）は Low
データ	`DSA_CUSTOMERS` 4,400行（SH.CUSTOMERS と SH.SUPPLEMENTARY_DEMOGRAPHICS と SH.COUNTRIES を結合。目的変数 `AFFINITY_CARD` は 1 が 1,046件）、`DSA_PROSPECTS` 100行（目的変数なし。答え合わせ用に元の値を別表に控えた）
クライアント	Windows 11 Pro、python-oracledb 4.0.1（thin）

リソースプリンシパルの動的グループとポリシー（generative-ai-family の use）は、Select AI の検証で作ったものをそのまま使っています。IAM の追加はしていません。

3. 構成・実装

3.1. 前提条件と今回の満たし方

ユーザーズガイドに書かれている前提条件と、今回それをどう満たしたかを並べます⁵。

前提	公式の記述	今回
AI 資格証明	DBMS_CLOUD で作る	リソースプリンシパル `OCI$RESOURCE_PRINCIPAL` を使い、資格証明は作らない
AI プロファイル	DBMS_CLOUD_AI で作る。対応プロバイダーに限る	3.2 章のとおり `DSA_OSAKA` を作る
`OML_DEVELOPER` ロール	Database Actions で作ったユーザーは自動付与	既存ユーザーに `GRANT OML_DEVELOPER TO DBA_COPILOT` で手動付与
ホスト ACL	OCI Generative AI では不要	何もしない
オブジェクト権限	表・ビューへの権限	自分のスキーマの表を使う

OML_DEVELOPER を手で付けただけで OML UI にサインインでき、プロジェクトとワークスペースは初回に自動で作られました。DBA_COPILOT はプロキシ認証専用（NO AUTHENTICATION）で作成していたため、OML UI のサインイン用にパスワードを設定しています。

3.2. AI プロファイル

公式の例³に合わせて temperature 1、max_tokens 8192、oci_compartment_id 付きで作りました。

-- DBA_COPILOT で実行
BEGIN
  DBMS_CLOUD_AI.CREATE_PROFILE(
    profile_name => 'DSA_OSAKA',
    attributes   => '{"provider":"oci",
                      "credential_name":"OCI$RESOURCE_PRINCIPAL",
                      "region":"ap-osaka-1",
                      "model":"meta.llama-3.3-70b-instruct",
                      "temperature":1,
                      "max_tokens":8192,
                      "oci_compartment_id":"ocid1.tenancy.oc1..xxxxxxxx"}');
END;
/

作成は成功しますが、DBMS_CLOUD_AI.GENERATE で疎通確認をすると HTTP 400 で失敗しました。OCI 側の応答本文は Invalid 'maxTokens': Value is greater than maximum: 4096 です。OCI Generative AI のモデルのページには、オンデマンドの応答長は 4,000 トークンまでとあり⁶、API の応答が返した上限は 4096 でした。どちらにしても公式例の 8192 はそのままでは使えません。一方でユーザーズガイドには「4096 未満は推奨しない」とも書かれているので³、境界値の 4096 に変えました。

BEGIN
  DBMS_CLOUD_AI.SET_ATTRIBUTE(
    profile_name    => 'DSA_OSAKA',
    attribute_name  => 'max_tokens',
    attribute_value => '4096');
END;
/

変更後の疎通確認は 3回とも 0.3 秒以内（0.23 秒、0.12 秒、0.14 秒）に OK が返りました。

3.3. データセット

Always Free の ADB にも読み取り専用の SH スキーマが入っています。顧客の属性から「アフィニティカードを持っているか」（AFFINITY_CARD が 0 か 1）を予測する 2 値分類にしました。アフィニティカードは提携先の特典が付くクレジットカードの類で、SH サンプルスキーマではその保有有無が AFFINITY_CARD 列（0 か 1）に入っています。OML のチュートリアルで長く使われているお題なので、生成される SQL を既知の形と比べやすいと考えて選びました。

-- 学習用 4,400行（先頭 100 顧客を除く）
CREATE TABLE dsa_customers AS
SELECT c.cust_id, c.cust_gender, c.cust_year_of_birth, c.cust_marital_status,
       c.cust_income_level, c.cust_credit_limit, c.cust_city, c.cust_state_province,
       co.country_name, d.education, d.occupation, d.household_size, d.yrs_residence,
       d.bulk_pack_diskettes, d.flat_panel_monitor, d.home_theater_package,
       d.bookkeeping_application, d.printer_supplies, d.y_box_games, d.os_doc_set_kanji,
       d.affinity_card
FROM   sh.customers c
JOIN   sh.supplementary_demographics d ON d.cust_id = c.cust_id
JOIN   sh.countries co ON co.country_id = c.country_id
WHERE  c.cust_id NOT IN (SELECT cust_id FROM (SELECT cust_id FROM sh.supplementary_demographics
                                              ORDER BY cust_id FETCH FIRST 100 ROWS ONLY));

-- 採点用 100行（AFFINITY_CARD を持たない）
CREATE TABLE dsa_prospects AS
SELECT c.cust_id, c.cust_gender, c.cust_year_of_birth, c.cust_marital_status,
       c.cust_income_level, c.cust_credit_limit, c.cust_city, c.cust_state_province,
       co.country_name, d.education, d.occupation, d.household_size, d.yrs_residence,
       d.bulk_pack_diskettes, d.flat_panel_monitor, d.home_theater_package,
       d.bookkeeping_application, d.printer_supplies, d.y_box_games, d.os_doc_set_kanji
FROM   sh.customers c
JOIN   sh.supplementary_demographics d ON d.cust_id = c.cust_id
JOIN   sh.countries co ON co.country_id = c.country_id
WHERE  c.cust_id IN (SELECT cust_id FROM (SELECT cust_id FROM sh.supplementary_demographics
                                          ORDER BY cust_id FETCH FIRST 100 ROWS ONLY));

ALTER TABLE dsa_customers ADD CONSTRAINT dsa_customers_pk PRIMARY KEY (cust_id);
ALTER TABLE dsa_prospects ADD CONSTRAINT dsa_prospects_pk PRIMARY KEY (cust_id);

採点結果を後で答え合わせできるように、100 顧客の元の AFFINITY_CARD は DSA_PROSPECTS_ANSWER に控えています。エージェントには関連付けません。

4. 手順・実行

4.1. OML UI から会話を作る

OML UI のホーム画面にある「Data Science Agent」カードを選択すると、会話一覧画面に遷移します⁷。「作成」ボタンから新規会話を作成する際、AI プロファイルに DSA_OSAKA を選択した時点で警告が表示されました。

「Test」を押すと「AI profile test succeeded」と表示されます。「Improve Profile」を押すと、提案される変更は google.gemini-2.5-pro への差し替えだけでした（今回は取り消しています）。

Service Level のデフォルト値は Medium で、選択肢は Low、Medium、High の 3 つでした。ユーザーズガイドにはデフォルトは Low とあります⁷。今回は Low を選びました。

4.2. オブジェクトの関連付け

会話画面の「Objects」から DSA_CUSTOMERS と DSA_PROSPECTS を関連付けます。自分のスキーマにあるテーブルがそのまま選択候補として表示されました（公式には既知の問題として「自分のスキーマのテーブルが表示されない場合がある」と案内されていますが⁸、今回の検証では発生しませんでした）。

4.3. 送ったプロンプト

送ったのは 4回です。1回目は公式の会話例⁹の 1 文目をもとにし、2回目以降はエージェントが返した確認の質問への返答です。

#	プロンプト	狙い
1	Using the associated objects, describe the data and how to frame this as a machine learning problem to predict AFFINITY_CARD.	データ把握と問題設定
2	Yes, go ahead. After validating, describe the data (rows, columns, target distribution) and explain how to frame the prediction of AFFINITY_CARD as a machine learning problem.	1 の確認の質問への回答
3	Yes. Score the DSA_PROSPECTS table and return the 10 prospects most likely to have an affinity card, and show the inference SQL I can run myself.	推論と推論 SQL
4	Which factors are most associated with AFFINITY_CARD? Show the pairwise relationship analysis of the features versus AFFINITY_CARD.	ペアワイズ分析

会話の間、別接続で 30 秒おきに V$SESSION と V$PGASTAT を取り、終了後に V$SQL を parsing_schema_name で絞って DB 側の SQL を集めました。

5. 結果

5.1. 段ごとの所要時間と生成物

送信	応答の内容	所要時間	生成物
1	表を調べて「特徴量を検証してよいか」という確認の質問を返す（3 ステップ）	25〜60 秒	なし
2	検証、単変量分析、分割、特徴量重要度、XGBoost 学習、評価まで進み「DSA_PROSPECTS を採点するか」という確認の質問を返す（14 ステップ）	約 110 秒	分割ビュー 4本、学習ビュー、モデル、評価結果表
3	採点して上位を表示し、推論 SQL を提示（2 ステップ）	35〜70 秒	推論用ビュー
4	5 変数のペアワイズ分析を返し「他の特徴も見るか」という確認の質問を返す（4 ステップ）	50〜85 秒	なし

所要時間は UI での送信から応答完了までを 20〜90 秒おきに画面を確認して記録したので幅があります。会話全体は 17:49:48 から 17:57:16 の 7 分半でした。

1回目の返答では、指示した「データの説明と問題設定」は直接出力されず、「特徴量の検証を進めてよいか」という確認メッセージが返ってきました。これに Yes と返答したところ、エージェントは公式の会話例で 7回のやり取りに分かれている工程⁹を 1 ターンで学習と評価まで進めました。分割の比率も指定していませんが、ORA_HASH(CUST_ID) による 80/10/10 のハッシュ分割で DSA_CUSTOMERS_TRAIN（3,507行）、_VAL（424行）、_TEST（469行）、_UNLABELED（0行）が作られました。

生成物は 5 種類で、モデル以外はビューと表です。

生成物	種別	内容
`DSA_CUSTOMERS_TRAIN` / `_VAL` / `_TEST` / `_UNLABELED`	ビュー	ハッシュ分割。定義 SQL が UI に出る
`DSA_CUSTOMERS_TRAIN_TOP_XGB`	ビュー	重要度上位の 16列に絞った学習用
`DSAGENT$AFFINITY_CARD_MODEL_4EFB`	マイニングモデル	XGBoost（`ALGO_XGBOOST`、`num_round` 10）、`build_duration` 1 秒、70,378 バイト
`DSAGENT$AFFINITY_CARD_MODEL_4EFB_TEST_RESULTS`	表	評価指標 10行（行単位の予測ではない）
`DSAGENT$INFERENCE_DATA_4EFB`	ビュー	採点時に追加。`DSA_PROSPECTS` の自己結合

ユーザーズガイドには生成物に DSAGENT$ の接頭辞が付くと書かれていますが⁷、分割ビューは元の表名に _TRAIN 等を付けた名前でした。学習を再現する PL/SQL（DBMS_DATA_MINING.CREATE_MODEL2）もパネルに出ます。

5.2. 評価指標

テストの 469行で評価した指標です。正例（1）の Recall が 0.6 で、正例を取りこぼす側に寄っています。

指標	値
Accuracy	0.8422
Balanced Accuracy	0.7585
Precision	0.6979
Recall	0.5982
F1	0.6442
AUC	0.8907

混同行列の内訳を見ると、実際の正例 112件中 67件を正例と予測し、45件を 0 と予測していました。実際の負例 357件中では 29件を 1 と誤予測しています。特徴量重要度の上位は CUST_MARITAL_STATUS（0.181）、CUST_YEAR_OF_BIRTH（0.121）、YRS_RESIDENCE（0.107）です。

5.3. 推論 SQL

3回目の応答には推論 SQL が 2 か所に出ます。1 つは LLM が生成した本文の中、もう 1 つはツールが生成した「SQL Code for Manual Inference」パネルです。

本文中の SQL は次のとおりです。

SELECT CUST_ID,
       PREDICTION( USING * FOR DSAGENT$AFFINITY_CARD_MODEL_4EFB WITH PROBABILITY ) AS PREDICTION,
       PREDICTION_PROBABILITY( USING * FOR DSAGENT$AFFINITY_CARD_MODEL_4EFB ) AS PROBABILITY
FROM   DBA_COPILOT.DSA_PROSPECTS
ORDER  BY PROBABILITY DESC FETCH FIRST 10 ROWS ONLY;

この SQL を SQL クライアントで実行すると、ORA-02012: missing USING keyword エラーが発生します。この構文は今回の会話で LLM が書いたもので、別の会話や別のモデルでは違う SQL が出ると考えられます。Oracle の PREDICTION 関数の構文ではモデル名の直後に USING を指定する必要があり¹⁰、USING * FOR という構文は SQL リファレンスに存在しません。

パネルの SQL は次のとおりです（モデル名の修飾を短くしています）。

SELECT fd."CUST_ID",
       PREDICTION(DSAGENT$AFFINITY_CARD_MODEL_4EFB USING fd.*) AS predicted,
       ROUND(PREDICTION_PROBABILITY(DSAGENT$AFFINITY_CARD_MODEL_4EFB, '1' USING fd.*) * 100, 2)
         AS "PROBABILITY OF 1 (%)"
FROM   "DBA_COPILOT"."DSA_PROSPECTS" fd
INNER JOIN "DBA_COPILOT"."DSA_PROSPECTS" ii ON fd."CUST_ID" = ii."CUST_ID"
ORDER  BY "PROBABILITY OF 1 (%)" DESC;

こちらは 100行が返り、上位 10件の顧客 ID と確率は UI の表示と一致しました。上位は 100052（78.84%）、100037（76.67%）、100036 と 100081（75.23%）です。控えておいた元の値と突き合わせると、上位 10件のうち 7件が実際に 1 で、100件全部では 84件の予測が一致しました。

5.4. ペアワイズ分析

4回目の応答は、婚姻状況、生年、居住年数、職業、世帯人数の 5 変数について、目的変数の平均値との関係を文章と統計で返しました。既婚の顧客の平均は 0.45 で全体平均 0.24 の約 2倍、未婚は 0.04、とエージェントは説明しました。

5.5. DB 側で動いていたもの

V$SQL を DBA_COPILOT の SQL で絞ると、上位は次のようになりました。

SQL	経過時間	CPU 時間	module
`OML$METADATA.DSA_OML.INVOKE_AGENT_PROC`（2回目の送信）	91.4 秒	6.4 秒	DBMS_SCHEDULER
同（3回目の送信）	18.6 秒	7.8 秒	DBMS_SCHEDULER
`DBMS_DSAGENT.ANALYZE_PAIRWISE_RELATION`	9.4 秒	0.4 秒	DBMS_SCHEDULER
`dsa_oml.submit_job`（UI からのジョブ投入）	5.3 秒	5.3 秒	JDBC Thin Client

UI（JDBC Thin Client）は submit_job で非同期ジョブを投入し、user_dsa_oml_jobs を定期的にポーリングして完了を待ちます。エージェント本体は DBMS_SCHEDULER のジョブとして実行され、その中から OML$METADATA.DBMS_DSAGENT パッケージの各プロシージャ（ANALYZE_SINGLE_VARIABLE、RANK_ATTRIBUTE_IMPORTANCE、TRAIN_CLASSIFIER など）が順次実行されていました。会話履歴の保存先は Select AI と共通の DBMS_CLOUD_AI の会話表で、検証の前後で USER_CLOUD_AI_CONVERSATIONS は 43件から 45件へ、USER_CLOUD_AI_CONVERSATION_PROMPTS は 94件から 115件へ増えています。

5.6. Always Free の制約

該当するエラーは出ませんでした。Always Free の制約は、1 OCPU と 20 GB の固定構成⁴、同時セッション数（Autonomous Database のガイドでは 30、Free Tier のページでは 20）、HTTP の同時ユーザー 3〜6 などです¹¹。OCI CLI の autonomous-database get では compute-model が ECPU、compute-count が 1 と返り、コンソールの詳細画面には CPU 数が出ません。DB の中からは cpu_count 2 として見えます。HTTP 同時ユーザー数のエラーは出ず、OML UI が保持するセッションは DBA_COPILOT で常時 5〜6本でした。PGA はインスタンス全体の maximum PGA allocated が 1,530 MB で、pga_aggregate_target の 3 GB に収まっています。Service Level は Low、Medium、High の 3 つとも選べました。V$RESOURCE_LIMIT は 0行で、セッション数の使用状況は取れませんでした（上限値は 2 章の sessions 30）。

6. 考察

6.1. 推奨外のモデルでどこまで進めるか

Llama 3.3 70B で 6 つの工程はすべて進みました。ただし、頼んだ説明を書かずに次の工程に進んでよいかの確認文を返す、指定していない工程まで 1 ターンで進める、本文に無効な SQL が含まれる、という 3 つの違いがありました。ユーザーズガイドの「Ask in multiple iterations」（4.4）や「Follow suggestions」（4.6）は工程を分けて進める前提で書かれています¹²。推奨モデルであれば公式の会話例のように工程ごとに止まると考えられますが、今回は比較していません。

今回の会話で無効だった SQL は本文の段落だけで、ツールが生成するパネルの SQL と分割ビューの定義 SQL は実行できました。パネルの SQL は表名とモデル名を定型に埋めた形に見え、LLM の文章と違って会話ごとに変わりにくいと考えられます。学習や採点そのものは DBMS_DSAGENT のプロシージャが DB 内で実行し、LLM は工程の選択と文章化を担っています。無効な SQL や工程の飛ばしが出るのは文章の部分で、SQL やモデルはツール側が作るので、今回の 1 会話では推奨外のモデルでも成果物はそのまま使えました。

6.2. 1 OCPU で足りるか

2回目の送信のジョブは 91.4 秒で、CPU 時間は 6.4 秒でした。XGBoost の build_duration は 1 秒です。4,400行の学習では DB の CPU はボトルネックになっていません。CPU 以外の約 85 秒の内訳は測っていませんが、LLM の応答待ちが大半と考えられます。ユーザーズガイドには、学習に数分かかることがあり、その間は会話が進まないと書かれています¹³。行数が 10倍、100倍になれば学習と分析のプロシージャの時間が伸びると考えられますが、どの行数まで足りるかは今回の範囲では測っていません。

6.3. Select AI Agent との違い

Select AI Agent は DBMS_CLOUD_AI_AGENT でツールとタスクを自分で定義して作る仕組みです¹⁴。Data Science Agent は工程とツールが DBMS_DSAGENT に組み込み済みで、ユーザーは AI プロファイルと関連付ける表を選ぶだけでした（5.5 章）。両方とも AI プロファイルと会話表を共有しているので、リソースプリンシパルの設定は 1 度で済みます。2 つを並べると、作る側と使う側の違いになります。

6.4. 一般化するときの注意

試行は 1 会話だけで、Llama の応答は温度 1 なので、同じプロンプトで同じ工程を辿るとは限らない
4,400行、16 特徴量の小さなデータでの結果で、Always Free の 20 GB と 1 OCPU がどこで足りなくなるかは測っていない
分割は指定せずにエージェントのデフォルトに任せたので、比率を指定したときの応答は見ていない

7. まとめ

Always Free の Autonomous AI Database でも、リソースプリンシパルで OCI Generative AI の Llama 3.3 70B を呼べば、Data Science Agent の 6 つの工程が 1 会話で進みました。警告は出ますが、会話の作成も学習も止まりません。使うときは、推論 SQL を本文でなくパネルから取ること（本文の SQL は LLM が書くたびに変わり得るため）、Llama では max_tokens を 4096 にしておくことに気をつけます。推奨モデルとの応答の違いと、分割比率を指定したときの応答は、今回は確かめていません。

参考

Oracle Data Science Agent（Autonomous Database Serverless のリリースノート、2026-06-30） ↩
About Data Science Agent（Oracle Data Science Agent User's Guide 1 章。LLM は第三者・OCI GenAI・自前ホストのいずれかを自分で用意する） ↩
Create an OCI Generative AI Credential and AI Profile（同ガイド 3.2。プロファイル例は temperature 1・max_tokens 8192、3.2.1 Recommended Models の表と「4096 未満は推奨しない」の注記） ↩ ↩² ↩³
Always Free Resources（OCI Free Tier のドキュメント。Autonomous Database は「1 Oracle CPU processor (cannot be scaled)」「20 GB storage (cannot be scaled)」、同時セッション 20） ↩ ↩² ↩³
Prerequisites to use Data Science Agent（同ガイド 2 章。前提 5 つの表。2.3 Add User to the Host ACL に「Host ACL entry is not required for OCI GenAI」） ↩
Meta Llama 3.3 (70B)（OCI Generative AI のモデルのページ。オンデマンドでは応答長が 4,000 トークンに制限される） ↩
Use Data Science Agent Chat Interface（同ガイド 3.4。Service Level のデフォルトは Low、生成物は DSAGENT$ 接頭辞。3.1 Access Data Science Agent に OML UI ホームからの導線） ↩ ↩² ↩³
Known Issues in Data Science Agent（同ガイド 7 章。自分のスキーマの表が Object Management に出ないことがある） ↩
Example of a Conversation with Data Science Agent（同ガイド 5 章。銀行マーケティングの 4 表を 7回のプロンプトで採点まで進める例） ↩ ↩²
PREDICTION（Oracle AI Database SQL Language Reference。構文は PREDICTION(model_name USING column_list)） ↩
Always Free Autonomous Database（Autonomous Database Serverless の書籍。Always Free の構成と制限） ↩
Best Practices for using Data Science Agent（同ガイド 4 章。4.4 Ask in multiple iterations、4.6 Follow suggestions provided by Data Science Agent） ↩
Performance and latency related limitations（同ガイド 6.5。探索・学習は数分かかることがあり、その間は会話が進まない） ↩
DBMS_CLOUD_AI_AGENT Package（Select AI Agent のツール・タスク・エージェント・チームを作るパッケージ） ↩

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up