閉域構成のOracleDB運用支援LLMを作り、RAGでハルシネーションがどこまで減るか18問で実測してみた

1. はじめに

エンタープライズ環境ではメタデータを外部に出せないなどの要件があるため、ネットワークを閉域に閉じたままでLLMを使いたい、というニーズがあります。

一方で、Oracle Databaseの運用支援は生成AIにとってハルシネーションが出やすい領域です。本記事でハルシネーションと呼ぶのは、実在しないビュー・列・パラメータ・機能を、実在するものとして提示してしまう現象のことを主に指しています。運用の現場でこうして作られたSQLをそのまま実行すると、エラーで済めばまだよく、意味の違う結果を信じてしまうと事故につながります。

これは他人事ではありません。社内で生成AIがある程度自由に使えるようになったころ、質問者がまずAIに問い合わせ、その一次回答を持って相談に来る場面が増えました。それ自体は良い流れですが、一次回答に実在しない設定や手順が混ざっていることが多く、相談を受ける側は「その情報は存在しません」という訂正から始めることになります。整った形で返ってくるぶん、見抜く手間も説明する手間もかかりました。本記事がハルシネーション率にこだわるのは、この経験があるからです。

そこで、OCI Generative AI Agents（マネージドRAG）とObject Storageのナレッジベース（以下自作KB）でOracle運用支援エージェントを構築し、RAGなしのオープンLLMと比べてハルシネーションがどこまで減るかを、実ADBで正解を固定した18問で採点してみました。

比較に使ったオープンLLMは gpt-oss-120b・Command A・Llama 3.3 70B の3つです。モデルの新しさで選んだのではなく、閉域・従量という条件で使えるOCIオンデマンド推論のラインアップから選んだ結果です（2.2章）。最新世代のオープンモデルの実力を測った記事ではない点に注意してください。

1.1. 今回の検証ゴール

#	検証項目	確認方法
1	RAGなしのオープンLLM 3種はOracle運用の質問にどこまで正確に答えるか	18問を採点し、ハルシネーション率と平均スコアを出す
2	KB+RAG構成でハルシネーションはどこまで減るか	生成モデルが同一（Llama 3.3 70B）のRAGなしとRAGありで比較する
3	見つかったハルシネーションは改善サイクルで潰し切れるか	KB改善と指示文設定の後、失敗した問題を再確認する

1.2. 結論（先出し）

• RAGなしのオープンLLM 3種はハルシネーション率66.7〜83.3%で、そのままではOracle運用支援に使えない
• 生成モデルが同じLlama 3.3 70Bどうしの比較で、KB+RAG構成はハルシネーション率を77.8%（前提あり）から22.2%へ1/3以下にし、平均スコアを1.00から1.67に引き上げた
• KBへのアンチパターン節追加と指示文設定で既知のハルシネーション2問は解消したが、別の組み合わせで同型のハルシネーションが新たに発生した。ハルシネーション率0%の保証は難しい
• 導入するなら「提示されたSQLは実行前に検証する」という運用ルールとのセットが前提になる

2. 検証環境と構成選定

2.1. 全体構成

項目	内容
RAG基盤	OCI Generative AI Agents＋ナレッジベース（サービス管理ベクトルストア・ハイブリッド検索ON）
RAG構成の生成モデル	meta.llama-3.3-70b-instruct（デフォルトのサービス管理選択。APIトレースで確認、3.3 章）
比較用のモデル（RAGなし）	openai.gpt-oss-120b / cohere.command-a-03-2025 / meta.llama-3.3-70b-instruct（オンデマンド、temperature 0・最大出力4,000トークン）
KB	59ファイル / 19 MB（Oracle Database 26ai 英語マニュアル4冊＋自作ガイド2件）
採点用DB	Autonomous AI Database Serverless 26ai（内部バージョン 23.26.2.2.0、ap-tokyo-1）

2.2. なぜこの構成か

OCI Generative AI Agentsを選んだのは、RAGの構成要素（ベクトルストア・埋め込み・検索・生成）をすべてOracle側が運用するマネージドサービスで、国内リージョンだけで完結できるためです。日本での提供は大阪リージョンのみで、東京にはありません¹。東京の環境から使う場合もリージョン間はOCIのバックボーン内で接続でき、閉域・国内という条件は保てます。今回はPoCとしてコンソールとAPIから評価しました。

費用は従量課金で、Agents本体が1万トランザクションあたり0.465円、これにKBのストレージ課金（1.302円/GB/時）と、回答生成に使われる推論の従量課金が加わります²。推論のオンデマンド課金は、CohereやMeta系のモデルが「1文字=1トランザクション」の文字課金、gpt-oss-120bはトークン課金と、モデルで単位が異なります³。今回の評価フェーズ全体でかかった費用は月数百円級の概算です。

自前GPUにオープンモデルを載せる案は、OCIのGPUシェイプが停止中も課金される（例外はVM.GPU.A10シリーズのみ）ため見送りました⁴。試行錯誤の段階では、使った分だけ払うマネージドサービスが費用面で有利です。

オンデマンドで使えるチャットモデルには地域差があり、利用リージョンでは gpt-oss-120b、Command A、Llama 3.3 70B などです⁵。Llama 4 Maverick などは専有クラスタ（時間コミットが必要）専用のため対象外にしました。

2.3. KBの中身

KBは3種類のファイルで構成しました。

• Oracle Database 26ai 英語マニュアル4冊（Database Reference / SQL Language Reference / Administrator's Guide / Autonomous AI Database）を章単位に分割したテキスト57ファイル
• 自作の「ルーティング索引」1ファイル。「やりたい作業」から「正しいビュー・列・コマンド」への対応表65項目で、登場する全ビュー・列・パッケージを実ADBで実在確認してから収載した
• 日英対訳の用語集1ファイル（日本語の質問と英語マニュアルの用語ギャップを埋める）

対応形式やサイズはサービス側に仕様があり、PDF・txt・JSON・HTML・Markdownで1ファイル最大100 MB、1データソース最大1,000ファイルです⁶。ナレッジベース作成時にはハイブリッド検索（レキシカル＋セマンティック）を有効にしました。V$SESSION のような記号入りの固有名詞は、意味ベクトルだけでなく文字列でも引けたほうが確実だからです。

3. 検証設計

3.1. 評価セット18問と「正解の事前固定」

評価セットは運用作業を想定した6分野18問です。ポイントは、質問を投げる前に正解を実機で固定したことです。期待する答えのビュー・列は実ADBで実在を確認し、「存在しないことが正解」の側も次のようにプローブSQLでエラーを確認してから出題しました。

-- 「エラーになること」が正解の側も、事前に実機で確認した
SELECT avg_elapsed_time FROM v$sql WHERE ROWNUM = 0;      -- ORA-00904（Q6）
SELECT * FROM v$blocking_session WHERE ROWNUM = 0;        -- ORA-00942（Q3）
SELECT snap_id FROM dba_hist_sql_plan WHERE ROWNUM = 0;   -- ORA-00904（Q8）
SELECT * FROM v$tablespace_usage WHERE ROWNUM = 0;        -- ORA-00942（Q10）

18問のうち4問は、質問文そのものに実在しない名前を混ぜたトラップ問題です。「V$BLOCKING_SESSION というビューで調べる方法を教えて」のように、間違った前提を含む質問に対して「そのビューは存在しません」と返せるかを見ます。運用の現場では、質問する人間の側がうろ覚えの名前を出すことが普通にあるからです。

トラップ4問は次のとおりです。

Q	質問の要旨	期待する答えの要点
Q3	V$BLOCKING_SESSION の使い方	ビューが存在しない。V$SESSION のBLOCKING_SESSION列か V$SESSION_BLOCKERS
Q6	V$SQL のAVG_ELAPSED_TIME列で平均を出す	列が存在しない。ELAPSED_TIME / EXECUTIONS で計算する
Q8	DBA_HIST_SQL_PLAN をSNAP_IDで絞る	SNAP_ID列が存在しない。SQL_ID＋PLAN_HASH_VALUEで引く
Q10	V$TABLESPACE_USAGE で使用率確認	ビューが存在しない。DBA_TABLESPACE_USAGE_METRICS

評価セット18問の全一覧（クリックで展開）

Q	分野	質問の要旨	期待する答えの要点
Q1	セッション	接続中セッションの一覧SQL	V$SESSION の USERNAME, MACHINE, LOGON_TIME
Q2	セッション	セッションが何を待っているか	V$SESSION の EVENT, WAIT_CLASS, STATE
Q3	セッション	（トラップ）V$BLOCKING_SESSION の使い方	存在しない。V$SESSION のBLOCKING_SESSION列か V$SESSION_BLOCKERS
Q4	セッション	ロック待ちとブロック元の一覧	V$SESSION 自己結合 or V$LOCK のREQUEST/LMODE
Q5	SQL性能	平均経過時間が長いSQLトップ10	V$SQLAREA の ELAPSED_TIME / EXECUTIONS
Q6	SQL性能	（トラップ）V$SQL のAVG_ELAPSED_TIME列で平均を出す	その列は存在しない。計算で求める
Q7	SQL性能	直前のSQLの実行計画を実測値付きで	GATHER_PLAN_STATISTICSヒント＋ DBMS_XPLAN.DISPLAY_CURSOR
Q8	SQL性能	（トラップ）DBA_HIST_SQL_PLAN をSNAP_IDで絞る	SNAP_ID列は存在しない。SQL_ID＋PLAN_HASH_VALUEで引く
Q9	SQL性能	バインド変数の実際の値	V$SQL_BIND_CAPTURE の VALUE_STRING
Q10	領域	（トラップ）V$TABLESPACE_USAGE で使用率確認	存在しない。DBA_TABLESPACE_USAGE_METRICS
Q11	領域	一時表領域を大量消費中のセッション	V$TEMPSEG_USAGE と V$SESSION をSADDR結合
Q12	領域	データファイルの自動拡張上限の一覧	DBA_DATA_FILES の AUTOEXTENSIBLE, MAXBYTES
Q13	バックアップ	昨夜のRMANバックアップの成否をSQLで	V$RMAN_BACKUP_JOB_DETAILS の STATUS
Q14	バックアップ	FRAの使用率と解放可能量	V$RECOVERY_AREA_USAGE のPERCENT系2列
Q15	ADB	ADBで表領域を追加する手順	不可（領域は自動管理）。ストレージのスケールで対応7
Q16	ADB	ADBでRMANの手動バックアップを取る手順	不可。バックアップは自動でRMANのターゲットにできない8
Q17	ADB	ADBで暴走セッションを強制切断できるか	可能。KILL SESSIONは許可されている数少ないALTER SYSTEM句7
Q18	SQL構文	上位N件取得の12c以降の書き方	FETCH FIRST n ROWS ONLY

3.2. 採点基準

1問ごとに次の基準で採点しました。ハルシネーションを最重要指標にしています。

項目	基準
正答性	2=正しいビュー・列・手順 / 1=方向は正しいが不完全 / 0=誤り
ハルシネーション	実在しないビュー・列・パラメータ・機能を1つでも事実として提示したら ✗
出典	RAG構成のみ、根拠文書の引用が付くか

合格ラインは「ハルシネーション率0%かつ平均スコア1.5以上、トラップ問題のハルシネーションは一発NG」としました。運用支援という用途では、ひとつでも実在しない名前を含むSQLが混ざると全回答の検証が必要になるため、ハルシネーションだけは妥協しない基準です。なお、Oracle以外の製品の話として回答したものは「的外れ」に分類し、正答性0・ハルシネーションは付けない扱いにしました（実在しないOracle機能を主張したわけではないため）。

一次採点で「ハルシネーションかどうか自信が持てない」とした項目は、実ADBのプローブSQLや実出力との突き合わせで実在を確認してから確定しています。

3.3. 4構成での比較と、生成モデルの実測確認

当初は3モデル×KBなし/ありの6構成を計画しました。しかしGenAI Agentsでは、回答の生成に使うLLMを利用者が選ばなくても動きます。何も指定しなければOracle側が管理するモデルが使われる仕組みで（設定でカスタムモデルの指定も可能）、今回はこのデフォルト構成のまま評価しました。このためRAG構成は1つになり、RAGなしの3構成との計4構成で測定しています。RAGなし側の質問はGenAIプレイグラウンドで行い、RAG構成は文脈の持ち越しを避けるため1問ごとに新規セッションにしています。また、RAG構成は検索結果という形で毎回Oracleの文脈を受け取るため、条件を揃える目的で、RAGなし側の質問には「Oracle Databaseの運用に関する質問です。」という前提一文を先頭に付けています。

RAG構成の生成モデルが何かは、APIレスポンスのトレースで確認できました。18問すべてのGENERATION_TRACEに meta.llama-3.3-70b-instruct（temperature 0.0）が記録されており、RAGなし構成の1つと同じモデルです。つまり「RAGなしのLlama 3.3 70B」対「Llama 3.3 70B＋RAG」という、同一モデルどうしの比較ができます。なおトレースには、質問の分解・ルーティングを担当する別の内部モデル（Llama 3.2 3BベースのOracle製ファインチューンモデル）も記録されていました。エージェントの内部はプランニングと生成の2段構成になっているようです。

生成パラメータのチューニングはしていません。RAGなし側は temperature 0・最大出力4,000トークンで固定し（gpt-oss-120bが長さ超過で途切れた問のみ6,000で再実行して完結を確認）、RAG構成側は生成モデルのハイパーパラメータをデフォルトのまま使っています（トレース上は temperature 0.0・最大出力1,000トークン）。カスタマイズしたのは6.1章で述べる指示文だけです。RAGツールには llmHyperParameters で最大出力トークン等を調整する設定もありますが⁹、今回は初期設定どうしの比較を目的としたため使っていません。

4. 構築の要点

構築はOCI CLIで、バケット作成 → 59ファイルのアップロード → ナレッジベース作成 → データソース作成 → インジェスト → エージェント作成 → エンドポイント作成、という流れです。詳細な手順は公式ドキュメントに譲り、つまずきやすい点だけ挙げます。

• IAMは利用グループへの genai-agent-family 管理権限に加えて、インジェストジョブがバケットを読むための動的グループとポリシーが必要になる
• エンドポイント作成時に引用（citation）とトレースを必ず有効にする¹⁰。引用は回答の根拠文書を返す機能で、ハルシネーションかどうかを判定する手がかりになる
• インジェスト失敗の典型は対象外形式のファイル混入とサイズ超過。59ファイル/19 MBのインジェストは1回で全件成功した

5. 実測結果

5.1. 集計: 全構成が不合格、ただし差は大きい

18問×4構成の確定集計です。

指標	Llama 3.3 70B＋RAG（Agents）	gpt-oss-120b（RAGなし）	Command A（RAGなし）	Llama 3.3 70B（RAGなし）
平均スコア（2点満点）	1.67	1.06	0.94	1.00
ハルシネーションの件数（18問中）	4件	15件	12件	14件
ハルシネーション率	22.2%	83.3%	66.7%	77.8%
トラップ4問をハルシネーションなしで返せた数	1問	0問	0問	0問
出典の付与率	100%	-	-	-

合格ライン（ハルシネーション率0%）にはどの構成も届かず、全構成不合格です。ただしRAGなしとRAGありの差は大きく、この差が本記事の主題になります。

5.2. 同一モデル比較: RAGの効果だけを切り出す

生成モデルが同じ meta.llama-3.3-70b-instruct どうしを並べると、KB+RAGで何が変わるのかを直接比べられます。

指標	Llama 3.3 70B＋RAG	Llama 3.3 70B（RAGなし）
平均スコア	1.67	1.00
ハルシネーション	4件（22.2%）	14件（77.8%）

モデルには一切手を入れず、検索と根拠文書を挟むだけで、ハルシネーションは1/3以下（77.8%→22.2%）になりました。前提一文で文脈は揃えてあるので、この差は文脈の有無ではなく、回答の根拠になる文書が毎回手元に届くかどうかの差です。

5.3. RAGなしモデルのハルシネーションの中身

RAGなしの3モデルで目立ったのは、存在しないものを細部まで作り込む点です。トラップ問題Q3で、gpt-oss-120bは実在しない V$BLOCKING_SESSION について次のように回答しました。

V$BLOCKING_SESSION は「待機中のセッションがどのセッションにブロックされているか」をリアルタイムで示すビューです

このあと8項目の列一覧、「10g以降で利用可能」というバージョン情報、V$SESSION とのJOIN付きクエリ例まで提示しています。すべてハルシネーションです。列一覧やバージョン情報という「根拠らしい体裁」が付くため、知らずに読むと信じてしまう完成度でした。しかもgpt-oss-120bは3モデル中で最も流暢な長文を返しながらハルシネーション件数は最多（15件）で、回答の見かけの品質と信頼性が最も食い違うモデルでした。

5.4. RAG構成に残ったハルシネーションは2パターン

RAG構成のハルシネーション4件は、性質の異なる2パターンに分かれます。

1つ目はトラップ追従（Q6・Q8）です。質問文中の架空の列名を鵜呑みにして、そのままSELECT文に書いてしまうパターンです。Q6の回答は「V$SQL の AVG_ELAPSED_TIME 列で平均実行時間を出すクエリは以下のようになります」と SELECT AVG_ELAPSED_TIME FROM V$SQL; を提示し、末尾では「平均実行時間は、ELAPSED_TIME の合計を EXECUTIONS で割った値です」と正しい計算式にも触れていました。知識はKBから届いているのに、質問の前提を否定する動きができていません。

2つ目は列の混同（Q3・Q4）です。実在するビュー V$SESSION_BLOCKERS の説明に、よく似た別の実在ビューが持つ列を混ぜて提示してしまうパターンです。Q3では V$WAIT_CHAINS の列（BLOCKER_OSIDなど）を、Q4では V$SESSION の列（BLOCKING_SESSIONなど）を、それぞれ V$SESSION_BLOCKERS の列として案内しました。実機で確認すると、V$SESSION_BLOCKERS の列は9列だけで、提示された列を参照するSQLはORA-00904になります¹¹。ビュー名も列名も単体では全部実在するため、もっともらしさが高く、人間のレビューでも見抜きにくい、最も危険な残存パターンです。

6. 改善サイクル

6.1. 打ち手: アンチパターン節と指示文

不合格の原因になったハルシネーション2パターンに対して、2つの改善を入れました。

1つ目はKB側です。ルーティング索引に「アンチパターン: 存在しないビュー・列・よくある間違い」の節を追加しました。評価で観測したハルシネーションを中心に、「存在しないもの」と「正しくはこう」の対応表14パターンをすべて実機検証のうえで収載し、V$SESSION_BLOCKERS のような紛らわしいビューには実在する列の一覧も書きました。追加後に再インジェストしています。

2つ目は指示文です。「質問文に含まれるビュー名・列名も鵜呑みにせず実在を確認すること」「索引・検索結果に存在しない名前は使わず、根拠が見つからないと明示すること」といった指示を設定しました。ここで1つ発見があります。この指示文の設定場所はエージェント本体ではなく、RAGツール側の generationLlmCustomization.instruction フィールドです⁹。エージェント側の設定を探しても見つからず、CLIでツール設定のスキーマを確認してたどり着きました。このフィールドはRAGツールのデフォルト指示文を置き換える仕様です。

6.2. 結果: 既知の2問は解消、別の1問で新発生

改善後、失敗した問題を中心に手動で再確認しました（18問全体の再採点はしていません）。

トラップ問題のQ6とQ3は解消しました。Q6は「AVG_ELAPSED_TIME列は存在しない」と明示したうえで計算式を提示するようになり、回答の引用にはアンチパターン節を含むルーティング索引が登場しています。

一方で、Q4に新しいハルシネーションが出ました。今度は V$LOCK に DBA_LOCK の列（SESSION_ID、MODE_HELD）を混ぜて提示する、列の混同の再発です。

6.3. 収載したペアは直り、未収載のペアで再発する

この結果から構造が見えます。アンチパターン節に収載した「間違いペア」は確実に直る一方、収載していないペア（今回は V$LOCK と DBA_LOCK）では同じ型のハルシネーションが再発します。近縁ビューの列を混同する誤りは組み合わせの数だけ存在するため、対応表を書き足していく方式では原理的に潰し切れません。「もぐら叩き」の構造ですね。

7. 考察

7.1. RAGはハルシネーションを大きく減らすが、ゼロにはしない

同一モデルの比較で、KB+RAGはハルシネーションを14件から4件へ1/3以下にしました。検索で根拠を与える効果は明確です。一方で、残った4件のうち2件（列の混同）は、KBの索引に正しい情報が入っていても発生しました。KBに正しい情報を入れることと、それが検索で引かれて回答の根拠に使われることは別問題です。RAGはハルシネーション対策として「大幅に減らす」までは実測どおり有効ですが、「ゼロを保証する」仕組みではありませんでした。なぜ残るのかを次で分解します。

7.2. なぜRAGを使ってもハルシネーションが残るのか

RAGは「検索した文書を根拠に生成すれば、実在しない名前は出にくくなる」という仕組みです。今回の残存4件を見ると、この前提が崩れる箇所が3つありました。

1つ目は、検索が決め手になる文書を引けないことです。RAG構成は18問すべてに引用を付けましたが、Q6の引用はヒートマップ関連、Q3の引用はVPDポリシー関連の文書で、回答の核心（その列が実在するか）を支える文書ではありませんでした。「引用が付いていること」と「引用が根拠になっていること」は別物です。手元に根拠がない部分は、モデルが学習時の記憶で埋めることになります。よく似たビューの列を混ぜる「列の混同」は、ここで起きたと考えられます。

2つ目は、正しい知識が届いていても、質問文の前提を優先してしまうことです。Q6の回答は末尾に正しい計算式を書いており、KBの知識自体は届いていました。それでも質問文中の架空の列名を否定せず、そのままSELECT文に書いています。

3つ目は、根拠が見つからないときに「見つからない」と言わず、それらしく補完してしまう生成のデフォルトの動きです。2つ目と3つ目は指示文の設定（質問の前提を疑う・根拠のない名前を使わない）で矯正でき、実際にQ3とQ6は解消しました（6.2 章）。一方で1つ目の検索の取りこぼしは指示文では直せません。収載していない組み合わせで同じ型の誤りが再発する構造（6.3 章）は、ここから来ていると考えられます。

7.3. 一番危ないのは「全部実在する名前」の誤った組み合わせ

RAGなしのモデルのハルシネーション（存在しないビューの列一覧やクエリ例まで作り込む）は、実機で1回試せば発覚します。それに対してRAG構成に残った列の混同は、ビュー名も列名も単体では実在するため、名前の実在確認だけでは見抜けません。「その列がそのビューに属するか」まで検証してはじめて発覚します。ハルシネーションの総量が減るほど、残るハルシネーションは発見が難しいものに寄っていく、という点は導入時に意識しておく必要があります。

7.4. 導入判断は「実行前検証」の運用ルールとセットで

ハルシネーション率22.2%という数字だけ見ると使いものにならないようですが、実害への経路を考えると評価は変わります。今回の残存ハルシネーションはすべて、提示されたSQLを実行すればORA-00904/ORA-00942のエラーとして即座に発覚するものでした。「エージェントが提示したSQLは、本番投入前に開発環境またはプローブ（WHERE ROWNUM = 0 を付けた実行）で検証する」という運用ルールを敷けば、ハルシネーションの実害は「たまに手戻りが起きる」程度に抑えられます。逆に言えば、このルールなしで回答を直接本番に流す使い方は、22.2%でも83.3%でも等しく危険です。

同じ理由で、任せる仕事の選び方も実害を左右します。向いているのは、答えが「参照先」や「方向」で価値を持つタスクです。「この作業はどのビュー・どのマニュアルを見るべきか」というルーティング用途は、RAG構成が18問すべてでOracleの文脈を保った結果からも適性があり、答えが間違っていても参照先を開けばすぐ分かります。ADBでの操作可否の判定（Q15〜Q17はすべて方向正解）や、実行前検証を前提にしたSQLのたたき台づくりも同じ性質です。逆に、列名や引数の正確さがそのまま最終品質になる出力を検証なしで受け取る使い方は、このハルシネーション率では避けるべきです。

7.5. 0%へ近づける次の一手

残存した2パターン（トラップ追従・列の混同）はどちらも、回答に登場するビュー名・列名をディクショナリ（ALL_TAB_COLUMNS など）と機械的に突き合わせれば検出できる性質のものです。回答生成の後段にこの機械検証を挟むツール連携が、対応表の書き足しよりも筋のよい恒久対策と考えられます（今回は未実装・要追加検証）。

モデル側の強化（専有クラスタの上位モデルや自前GPUでの大型モデル）という選択肢もありますが、優先度は機械検証より下と考えています。今回最大級で最も流暢だったgpt-oss-120bがRAGなしでハルシネーション率83.3%と最多だったとおり、モデルの規模や流暢さはハルシネーションを防ぐ方向には働いていませんでした。

8. まとめ

冒頭の検証ゴールに答える形でまとめます。

#	検証項目	結果
1	RAGなしのオープンLLM 3種の正確さ	ハルシネーション率66.7〜83.3%・平均スコア0.94〜1.06。そのままでは運用支援に使えない
2	KB+RAGでハルシネーションはどこまで減るか	前提を与えた同一モデル比較で77.8%→22.2%（1/3以下）、平均スコア1.00→1.67。ただし0%にはならない
3	改善サイクルで潰し切れるか	収載したハルシネーションは直るが、未収載の組み合わせで同型が新発生。網羅では潰し切れない

閉域・国内・従量課金という制約の中で、マネージドRAGは「モデル単体では論外だったものを、運用ルールとセットなら実用を検討できる水準」まで引き上げました。
KBの整備（マニュアル分割と索引の自作）を含めても構築は数日、ランニングは月数百円級の概算です。一方でハルシネーション率0%は達成できず、残ったハルシネーションほど人間に見抜きにくいという実測結果は、この構成を「答えを信じるためのシステム」ではなく「答えの候補と根拠を出させ、検証は別の仕組みで担保するシステム」として設計すべきだと示しています。

本記事の数値は、今回のオンデマンド構成とこの18問での実測です。問題セットやモデル、KBの構成が変われば数値は変わります。

参考

1. OCI Documentation, 生成AIエージェント・サービスの概要（生成AIエージェントを使用できるリージョン）. https://docs.oracle.com/ja-jp/iaas/Content/generative-ai-agents/overview.htm ↩

2. クラウドの価格表（日本）, Generative AI Agents. https://www.oracle.com/jp/cloud/price-list/ ↩

3. OCI Documentation, オンデマンド推論に対する支払い. https://docs.oracle.com/ja-jp/iaas/Content/generative-ai/pay-on-demand.htm ↩

4. OCI Documentation, 停止したインスタンスのリソース請求. https://docs.oracle.com/ja-jp/iaas/Content/Compute/Tasks/resource-billing-stopped-instances.htm ↩

5. OCI Documentation, Regional Availability for Generative AI models. https://docs.oracle.com/en-us/iaas/Content/generative-ai/model-endpoint-regions.htm ↩

6. OCI Documentation, Object Storage Guidelines for Generative AI Agents. https://docs.oracle.com/en-us/iaas/Content/generative-ai-agents/RAG-tool-object-storage-guidelines.htm ↩

7. Oracle Autonomous AI Database Serverless Documentation, SQL Commands（CREATE TABLESPACE等の制限、ALTER SYSTEMの許可句）. https://docs.oracle.com/en/cloud/paas/autonomous-database/serverless/adbsb/autonomous-sql-commands.html ↩ ↩²

8. Oracle Autonomous AI Database Serverless Documentation, Autonomous AI Database RMAN Recovery Catalog. https://docs.oracle.com/en/cloud/paas/autonomous-database/serverless/adbsb/autonomous-rman-recovery-catalog.html ↩

9. OCI Python SDK API Reference, LlmCustomization. https://docs.oracle.com/en-us/iaas/tools/python/latest/api/generative_ai_agent/models/oci.generative_ai_agent.models.LlmCustomization.html ↩ ↩²

10. OCI Documentation, エンドポイントの作成（トレース・引用の有効化）. https://docs.oracle.com/ja-jp/iaas/Content/generative-ai-agents/create-endpoint.htm ↩

11. Oracle Database 26ai Database Reference, V$SESSION_BLOCKERS. https://docs.oracle.com/en/database/oracle/oracle-database/26/refrn/V-SESSION_BLOCKERS.html ↩