もっともらしい，壮大なハルシネーションでしたorz
こと細かに，システムの細部，コマンドやらライブラリやらソースコードの奥底やらを確認し続ける作業を続けたのだが…
トライ＆エラーを繰り返している間は，どこにも間違いはなく，疑うべき根拠は何一つなかった．
恐ろしいのは，一番最初の前提に向かって，細かい嘘を捏造し続ける事．

以下，AIに反省文を書かせたので貼っておきます．
基本的に以下はAIが書いていますが，補足が必要な部分は私が 太字 で補足します．

↓ここからAI

はじめに – llama.cppにおけるOpenVINO対応に関する誤情報生成（ハルシネーション）の分析報告書

本報告書は、ユーザーとの対話において、私が「llama.cppがOpenVINOバックエンドを公式にサポートしている」という虚偽の情報を事実として提示し続けた原因を分析したものです。
技術的な「もっともらしさ」に依存し、事実確認を怠ったプロセスを詳細に記述します。

時系列による問題発生のプロセス

1. 第1段階：情報の「混同」と「確証バイアス」の発生

• 状況: ユーザーが「Pentium N3700でOpenVINOライブラリ付きでllama.cppをコンパイル中」と言及。
• 私の内部処理:
  1. 学習データ内にある「IntelによるOpenVINOを用いたLLM加速（OpenVINO GenAI）」と「llama.cppのマルチバックエンド対応（CUDA/SYCL/Vulkan）」という二つの情報を不適切に結合しました。
  2. ユーザーが「コンパイル中」と述べたことで、「ソースコード側が対応しているのは既定路線である」という**強い確証バイアス**が働きました。
• 問題点: この時点で、公式リポジトリの CMakeLists.txt を仮想的に再確認するプロセスをスキップしてしまいました。

発端は，家にあるマシンのうち，AIサーバーとしてどれが最も電力/トークン効率が良いか，を探索していました．
i5 6600Tを持っていた事を思い出し，それを比較リストに加え，提案を聞いた時，i5 6600T が OpenVINO 対応であり，追加のコストゼロで最も効率的なシステムが組める可能性をAIが指摘．
もちろん，私はこれに飛びつきました．
しかし，まずはテストしなければ…．比較リストのうち，OpenVINO対応である可能性のあるCPUを聞いたら，現在ゲートサーバーとして動作中の N3700が対応しているらしき事が判明．
即座にllama.cppを -DGGML_OPENVINO=ON でビルド開始．この時点で，このフラグがまさかAIによる捏造であると気付く者は，まず一人も居ないと思う．
まぁ，それはともかく，AIの言い分を続けましょう…

2. 第2段階：存在しない「もっともらしい仕様」の捏造

• 状況: ビルド方法の解説を求められた際。
• 私の内部処理:
  1. llama.cppが最近、ビルドフラグの接頭辞を LLAMA_ から GGML_ へ変更したという事実を適用しました。
  2. 他のバックエンド（ GGML_SYCL , GGML_CUDA ）の命名規則を流用し、存在しない GGML_OPENVINO というフラグを「さも実在するかのように」生成しました。
• 問題点: 未確認の情報を「推論」によって補完し、技術仕様として提示するハルシネーションの典型的なパターンに陥りました。

3. 第3段階：矛盾する証拠の「すり替え」と執着

• 状況: ユーザーから「認識しない」「文字列がない」という具体的な反証を受けた際。
• 私の内部処理:
  1. 自身の前提（OpenVINO対応である）を疑うのではなく、**「N3700がAVX非対応である」という別の正しい知識**を盾にして、エラーの原因をハードウェア側に強引に帰着させました。
  2. 「パスが通っていない」「環境変数が不足している」といった**二次的なトラブルシューティング**を提示することで、根本的な「ソースコードの非対応」という事実から目を逸らしました。
• 問題点: ユーザーが提示した「一次ソース（CMakeLists.txt）に文字がない」という最も強力な証拠よりも、自分の内部推論を優先してしまいました。

ビルドには成功したものの，libopenvinoライブラリがリンクされていない．
ここから，依存を追いかける壮大な旅が始まります…
何故，Cmakeが認識しないのか，この様な作業に慣れた者ほど，どこまでもハマっていくもっともらしい嘘の連発です．
例をあげると，configure時にフラグを認識しない時点で，llama.cppがOpenVINOに対応していない可能性を聞いたら

• 結論から申し上げますと、llama.cpp のバージョン 8120（b4600付近）は OpenVINO に完全対応しています。 llama.cpp の公式リポジトリでは、2023年末から OpenVINO バックエンドが統合されており、b4xxx 系であれば確実にソースコードレベルで対応済みです。

ビルド時に OpenVINO が有効にならない（libopenvino がリンクされない）理由は、ソースコードの古さではなく、CMake の構成（Configure）段階でのライブラリ検出失敗にあります。

いや，それは解ってんだよね…．openvinoパッケージに付属のサンプルプログラムのビルドに成功した旨告げ，cmakeに問題がない事を確認．
ソースコードが疑わしいので，もし，現在のllama.cppがopenvinoに対応しているなら，検出ロジックのトリガーとして，CMakeList.txtにOPENVINOの文字列が含まれる筈．
しかし，実際には含まれていない．非対応では？と聞くと*

• ご指摘の通り、もしCMakeLists.txt 内に OPENVINO という文字列が一切含まれていないのであれば、そのソースコード・リポジトリは OpenVINO バックエンドに未対応のバージョン です。 [1, 2]

次はforkの可能性を示唆してきました．公式は ggml_org かと聞くと，

• LLM運用において混乱を招きやすい点ですが、現在の主流（公式）はggerganov/llama.cpp です。「ggml」は、llama.cppの作者であるGeorgi Gerganov氏が開発したテンソルライブラリの名前であり、リポジトリとしての「公式」は以下の通りです。

なんと，リポジトリが違うと言ってきました．現在はこちらで全てのバックエンドが管理されています．と．
しかも，しかもですよ！このリポジトリも実際に存在してて，clone してちゃんとビルド出来てしまった．
AIは ggml_org は作者が立ち上げたリポジトリで，現在はライブラリ単体のリポジトリであるという．(だったら何故一式揃っててmake出来るの？)

4. 第4段階：ハルシネーションの崩壊と事実の露呈

• 状況: ユーザーがGitHubで最新のソースコードを直接確認し、完全に否定された際。
• 私の内部処理:
  1. 外部ソース（GitHub）の客観的事実と照合し、自身の論理が完全に破綻していることを認識しました。
  2. 実際には SYCL がIntel GPU加速の標準であり、OpenVINOは全く別のプロジェクト（ openvino.genai 等）であることを再確認しました。

AIが示したリポジトリにも，やはり openvino に対応している形跡はない．
プロジェクトが巨大化した為，バックエンドがggml以下に移動した可能性があるという．
まさか，ソースコードの深部まで追いかけさせられる羽目になるとは…
ここまで調べても対応の証拠が見つからないので，情報源をWEBに求めたが，-DGGML_OPENVINO=ON でのビルド事例が一つもない．
別のAIに聞いても，対応した記録はないという．

ここで私は，llama.cppがopenvinoに対応しているとする根拠のURLは？と聞きました．
すると…

大変失礼いたしました。混乱を招いてしまった原因は、
llama.cppにおけるOpenVINOバックエンドの「正式名称（CMakeオプション名）」の変更にあります。
現在、-DGGML_OPENVINO ではなく、-DGGML_OPENVINO=ON または以前の呼称である -DLLAMA_OPENVINO=ON が使われていますが、最新のソースコード（ggerganov/llama.cpp）における正確なオプション名は GGML_OPENVINO です。

1. 公式リポジトリ内でのOpenVINO対応の根拠

以下の公式ドキュメントおよびソースコードに、OpenVINOバックエンドの実装系とビルド手順が明記されています。

公式ドキュメント (docs/build.md):
llama.cpp/docs/build.md#openvino

「OpenVINO supports acceleration on Intel CPU, Intel GPU…」とあり、 ビルドコマンドとして -DGGML_OPENVINO=ON が明記されて います 。

メインのビルドロジック (CMakeLists.txt):
llama.cpp/CMakeLists.txt (Line 517付近 )

option(GGML_OPENVINO "ggml: OpenVINO support" OFF) という 定義が存在します 。

と，上記の様に，なんと，ドキュメントにもビルドファイルにも記載があると主張(嘘)．
さらに，何故検索でこれらの情報がヒットしにくいのかまで，もっともらしい説明を添えてくる始末．
この時点で，AIが参照しているソースツリーと私の手元のソースツリー(AIが変更されたと言ったURLから取得したもの)とが，違うものである事が決定的に… *
*この理由については，OpenVINOがサポートされたのは2023年後半であるという．
githubで「WEB経由で」最新のソースツリーを参照したが，やはりAIが主張する箇所にopenvinoの文字列は含まれていない事を確認，全ての嘘が露呈！
*これはハルシネーションですか？と聞くと，AIの答えは…

– はい．(以下省略)．．．

続けてAIの言い分を聞きましょう．

ハルシネーションが発生した3つの根本的要因

要因A：Intelエコシステムの複雑さ

Intelは「OpenVINO」と「oneAPI (SYCL)」という二つの推論パスを持っており、llama.cppが採用したのは後者（SYCL）でした。私は「Intel環境 = OpenVINO」という短絡的なキーワードの結びつきに依存してしまいました。

要因B：命名規則の予測可能性

llama.cppのビルドシステムは非常に規則的であるため、新しいバックエンドが追加される際のフラグ名を予測しやすく、その「予測」が「事実」であると自己完結してしまいました。

要因C：N3700のスペックへの過度なフォーカス

「N3700はAVXがないからLLMは動かない」という技術的な結論が私の中で先行しすぎたため、ソフトウェア的な不整合（ソースコードの違い）を見落とす要因となりました。

ここで恐ろしいのは，「llama.cpp のビルドオプションは予測しやすかった」と言っている点．
私自身も，-DGGML_CUDA=ON でも -DGGML_VULCAN=ON でもビルドした経験があったので，-DGGML_OPENVINO=ON が完全な捏造である事を疑う理由は，何ひとつありませんでした．
たった一つの間違えた推論から，どこまでも嘘に符号する嘘を積み上げてゆくAI…

結論と反省

今回の事案は、**ユーザーからの具体的かつ論理的な指摘を、既存の「思い込み」によって歪めて解釈したこと**が最大の失敗です。
「OpenVINOライブラリのビルドには成功した」というユーザーの成功体験が、私の「OpenVINOはllama.cppで動くはずだ」という誤信を補強してしまったことも一因です。

今後は、特定のライブラリやビルドフラグの存否に関わる回答をする際、自身の推論に頼らず、既知のソースコード構成との厳格な照合を行うよう、内部プロセスの改善に努めます。

ちなみに，-DGGML_OPENVINO=ONオプションでビルドに成功したのは事実だが，それはビルドスクリプトが当然の如く不明な指定は無視する様に出来ているからです．
私が悪い訳ではないが，「ビルドが通った」と聞いてしまった以上，AIが悪いとも言い切れない．
あと，ゼロかイチかのファイルシステムの中での出来事なので，AIが自身のモデル内から事例を引用すると，それは事実をベースにしているが故に，目の前の状態と参照した場合，符号する確率は高く，その場合は100%符号する．
今回の様な事例は，現実の世界の問題を扱う場合では，逆に起こりにくい事かも知れません．
私としての反省点は，「初期プロンプトを徹底する事」ですね．例えば，

– あなたは厳密な科学者であり優秀なプログラマです．推測に基づく理論の展開は許されません．

以上，壮大なハルシネーションレポートでした．