DeepResearchの質がなぜバラけるのか調べるほど技術的についていけない件

GeminiのDeepResearchをかけようとすると計画段階での内容が既知の内容だったので、ひとこと「より技術的な内容を含めよ。」と追加した結果、以下の仕切り線のような出力となりました💦

……これもう、雰囲気でしか理解するの、ムリだ……

従来の検索エンジンが文字そのものを取り扱っていたのに対して、今のGoogle検索はキャッシュを持たないベクトル化されたインデックス構造になっているため、どうしても更新してからインデックス反映までの遅延は発生してしまいます。それをAIサービスに対して最適化するのに、非常に多くの技術が投入されていることはわかりましたが……たぶん、1年経つとまた新しい技術が増えている可能性が高く、いま、すべてを理解しようとすることにそもそも意味がない……気がします💦

固まっていてもしょうがないので、最も整理されていて重要ぽいとこだけ抜き出すと、以下のコンテクスト・エンジニアリングという辺りが該当するかと。

引用文献の著者はインド系の名前をもつエンジニアで、一見カラフルすぎて独自性の高い記事に見えるけれども、経歴を洗うと十分に信用できると思いました。

「制約の厳しいプロダクション環境」というのは、DeepResearchの実行中がまさにそういう状態で、AIベンダーとしてはどこまで処理を軽くするか、そして同時にユーザーが離れない程度の検証可能性をもって出力する必要があるので、実質的なDeepResearchの実行枠が公称よりも1/4から1/6といった遥かに小さい件数に収めないと採算がとれないから、現状そうなっているわけで……たとえ各所でいくら公称値との乖離を指摘されようとも……

Geminiの方も今回もDeepResearch中に処理しきれない部分があったようで、クロス・エンコーダーがクロスコ・エンコーダーになっていたのは、誤記だと思ったので訂正を入れました。意味はよく理解してないけど、クロスコはないと思う。

……プロンプトとして余計な一言、いれない方が、精神的によかった？もしかして？🙇

なお、トップページ画像は、「AI SEOとウェブエコシステムの変容」という件が気になったので、SEOとAIを印象付けるものをお借りいたしました。

次世代大規模言語モデルにおけるウェブ検索融合技術の深化とシステム最適化に関する包括的研究報告

大規模言語モデル（LLM）の発展は、単なるテキストの生成から、外部世界と動的に相互作用する「推論エンジン」としての確立へとその歩みを進めています。初期の言語モデルは、広範なコーパスを用いた事前学習を通じて獲得された「パラメトリック知識」のみに依存しており、情報の新鮮さや事実の正確性、さらには特定の専門領域における深い洞察に限界を抱えていました ［1］。しかし、検索拡張生成（Retrieval-Augmented Generation, RAG）やツール利用（Tool-use）といったウェブ検索融合技術の台頭により、これらの制約は劇的に緩和されつつあります ［1］。

今日の高度なAIシステムは、ウェブ空間を単なるデータの保管場所としてではなく、複雑な推論を補完するための「作業メモリ」や「証拠の貯蔵庫」として活用しています。本報告書では、LLMとウェブ検索の融合におけるアーキテクチャの進化、検索とリランキングの技術的詳細、知識の衝突とその解消メカニズム、そしてシステム的な制約や互換性の問題について、最新の研究知見に基づき包括的な分析を行います。

検索融合アーキテクチャのパラダイムシフト

LLMと外部検索機能を統合する設計思想は、単純な情報の付加から、エージェントによる自律的な計画実行へと進化しています。初期の統合形態は、ユーザーのクエリを検索エンジンに投げ、得られた上位の結果をプロンプトに挿入する静的なものでしたが、現在はより洗練された多層的なアプローチが主流となっています ［1］。

統合手法の主要な分類と特徴

現在、主要な検索融合アーキテクチャは、その動作原理と最適化の対象によって主に三つの階層に分類されます。これらは、情報の正確性を担保するRAG、柔軟な操作を可能にするツール利用、そして長時間の調査を遂行するディープリサーチシステムです ［1］。

$$
\small \def\arraystretch{1.5}
\begin{array}{|l|l|l|l|} \hline
\textsf{\textbf{アーキテクチャ階層}} & \textsf{\textbf{動作メカニズム}} & \textsf{\textbf{主な利点}} & \textsf{\textbf{技術的課題}} \\ \hline
\textsf{\textbf{検索拡張生成 (RAG)}} & \textsf{事前にインデックスされた外部データベースから関連文書を取得し、生成時のコンテキストとして利用する ［4］} & \textsf{ハルシネーションの抑制、検証可能な根拠（グラウンディング）の提供 ［2］} & \textsf{検索の不正確さ、マルチホップ推論における情報の欠落 ［4］} \\ \hline
\textsf{\textbf{ツールとしての検索 (Tool-use)}} & \textsf{モデルが推論の過程で能動的に検索APIを呼び出し、特定の情報を取得する ［3］} & \textsf{適応性が高く、推論ステップの途中で必要な情報を動的に補完できる ［4］} & \textsf{大規模な学習データ（軌跡データ）の必要性、勾配ベースの直接最適化が困難 ［3］} \\ \hline
\textsf{\textbf{ディープリサーチ (Deep Research)}} & \textsf{エージェントが計画立案、広範な証拠収集、情報の合成を自律的に繰り返す長周期ワークフロー ［1］} & \textsf{複雑な問いに対する垂直的な深掘りと、異種ソース間の情報の統合が可能 ［1］} & \textsf{高い計算コスト、エージェントの迷走（ループ）、レイテンシの増大 ［1］} \\ \hline
\end{array}
$$

RAGは、事前学習による知識のカットオフを補うための標準的な手法として定着していますが、その効果は検索器（Retriever）の精度に強く依存します ［12］。これに対して、ツール利用はLLMが「いつ」「何を」検索すべきかを自ら決定するエージェント的な能力を要求します。さらに、OpenAIのo3やo4-mini、Gemini Deep Researchなどの最新システムに見られるディープリサーチは、情報を単に取得するだけでなく、取得した情報に基づいて計画を修正し、必要であればさらなる深掘りを行う「証拠の連鎖」を構築します ［1］。

強化学習による検索行動の最適化

検索エンジンの操作をLLMの内部推論とより密接に結合させるために、強化学習（RL）を導入する試みが注目を集めています。例えば、SEARCH-R1フレームワークは、LLMが自身の思考プロセスの中で検索エンジンを呼び出し、その結果を統合する一連の挙動をRLによって最適化します ［3］。この際、PPO（Proximal Policy Optimization）やGRPO（Group Relative Policy Optimization）といったアルゴリズムが用いられ、特に検索によって得られた情報を処理する際のトークンマスキング技術などが、学習の安定化に寄与しています ［3］。

このようなトレーニングベースのアプローチは、プロンプトベースの手法に比べて高い汎用性と適応性を発揮しますが、高品質な「検索と推論の対話ログ（軌跡）」を大量に生成・注釈する必要があり、スケーリングにおける大きな壁となっています ［3］。

検索・リランキングと文書解析の技術的プロセス

ウェブ情報をLLMが理解可能な形式に変換し、最も関連性の高い情報を選別するプロセスは、単なる検索エンジンの呼び出し以上に複雑な多段階のパイプラインで構成されています。情報の「ノイズ」を排除し、「シグナル」を最大化することが、最終的な回答の質を左右します ［8］。

クエリの最適化と適応型検索

ユーザーの問いかけは、必ずしも検索エンジンに適した形式であるとは限りません。そのため、システム側でクエリを書き換える「クエリ・リライト」や、複数の視点からクエリを生成する「マルチクエリ」といった手法が採用されています ［14］。

さらに、効率性を追求するために「いつ検索すべきか」を判断する適応型クエリ増強（Adaptive Query Augmentation）も重要な技術です。M-Solomonのようなモデルでは、クエリを「増強が必要なもの」と「不要なもの」に事前に分類し、必要な場合にのみ検索を実行することで、システム全体のレイテンシを抑制しています ［14］。また、Self-RAGのように、モデル自身が検索の必要性をトークンとして出力する自己制御型のアプローチも研究されています ［16］。

構造解析とコンテンツ抽出の課題

ウェブページから情報を抽出する際、HTMLの構造は情報の完全性に大きな影響を与えます。セマンティックな構造（意味的なHTMLタグ）が適切に設定されているページでは抽出精度が85〜95%に達しますが、複雑に入れ子になったdiv構造や、JavaScriptによる動的生成が多用されているページでは、重要なコンテキストが欠落するリスクが高まります ［17］。

コンテンツ抽出のパイプラインでは、以下の工程が一般的です ［8］。

1. クリーニング: 広告、ナビゲーション、スクリプトなどの「ボイラープレート」を除去し、本文のみを抽出します ［8］。

2. 正規化: 文字コードの統一、HTMLエンティティのデコード、重複コンテンツのフィルタリング（MinHashなどを使用）が行われます ［17］。

3. トークン化: 抽出されたテキストは、LLMが処理可能なトークンへと変換されます。この際、BPE（Byte Pair Encoding）などのサブワードトークン化手法が用いられますが、ブランド名や専門用語が不適切に分断されることで、モデルのセマンティックな理解が低下する副作用も報告されています ［17］。

リランキングとセマンティック・マッチング

検索エンジンから返された多数の結果を、LLMの制約あるコンテキストウィンドウに収めるためには、高精度なリランキングが不可欠です。初期の検索にはBM25などのキーワードベースの手法や、Dense Vectorによるベクトル検索が用いられますが、その後に、より計算コストの高い「クロスコ・エンコーダークロス・エンコーダー」や「LLMベースのリランカー」を適用することで、文脈的な関連性を詳細に評価します ［7］。

近年では、情報の「量」よりも「質（顕著性）」を重視するスコアリング手法が提案されています。例えば、情報の独自性、新しさ、およびクエリとの類似度を統合的に評価するマルチファクタースコアリングなどが挙げられます ［19］。

知識の衝突（Knowledge Conflict）とその解消技術

外部知識を導入する際、最も困難な技術的課題の一つが、モデルの内部知識と取得した外部知識の間に生じる矛盾、すなわち「知識の衝突」です。この衝突をいかに適切に管理するかが、システムの信頼性と頑健性を決定づけます ［20］。

知識衝突の類型化

知識の衝突は、情報の発生源と相互作用のパターンに基づき、以下の四つのカテゴリーに整理されます ［20］。

$$
\small \def\arraystretch{1.5}
\begin{array}{|l|l|l|} \hline
\textsf{\textbf{衝突のカテゴリー}} & \textsf{\textbf{衝突の主体}} & \textsf{\textbf{具体的な事象}} \\ \hline
\textsf{\textbf{コンテキスト対メモリ (CM)}} & \textsf{外部文書 vs 内部パラメトリック知識} & \textsf{最新ニュース（外部）が、古い学習データ（内部）と矛盾する ［20］} \\ \hline
\textsf{\textbf{コンテキスト間 (IC)}} & \textsf{外部文書A vs 外部文書B} & \textsf{異なるウェブサイト間で情報の主張やデータが食い違っている ［20］} \\ \hline
\textsf{\textbf{メモリ内 (IM)}} & \textsf{内部知識内部の不整合} & \textsf{同じ概念に対して、プロンプトの微細な変化でモデルの回答が変わる ［20］} \\ \hline
\textsf{\textbf{ツール対メモリ (TMC)}} & \textsf{検索ツール vs 内部パラメトリック知識} & \textsf{ツールが提供する最新データが、モデルの静的な重みと対立する ［21］} \\ \hline
\end{array}
$$

これらの衝突は、モデルがどちらの情報を信頼すべきかという「信頼性の帰属」の問題を引き起こします。特に、モデルが自身の不正確な記憶に固執する「信念の固執」や、逆に不正確な外部情報を鵜呑みにしてしまう「ハルシネーションへの誘引」が懸念されます ［15］。

隠れ状態における衝突シグナルの検知

最新の研究では、LLMの内部で知識の衝突がどのように処理されているかが明らかになりつつあります。例えば、CLEAR（Conflict-Localized and Enhanced Attention for RAG）の研究によれば、知識の統合は「トークン→文→パッセージ」という階層的なステップで行われており、衝突のシグナルは出力層に到達する前の中間層（文レベルの抽象化が行われる段階）ですでに顕在化していることが確認されています ［22］。

この内部シグナルを「プローブ」と呼ばれる軽量な分類器で検知することで、モデルが生成を開始する前に衝突を予測し、より慎重な推論へと誘導することが可能になります ［21］。

衝突解消のための高度なフレームワーク

衝突を効果的に解消するための手法として、以下の三つの代表的なアプローチが提案されています。

1. CRAG (Corrective Retrieval-Augmented Generation): 検索結果の信頼性を「正確（Correct）」「不正確（Incorrect）」「曖昧（Ambiguous）」の三段階で評価します。不正確と判定された場合は内部知識を無視してウェブ検索を再実行し、曖昧な場合は両方の知識を慎重に統合します。この「プラグアンドプレイ」型のアーキテクチャは、既存のRAGシステムに容易に組み込むことができます ［23］。

2. RE-RAG (Relevance Estimator RAG): 各検索文書に対して詳細な信頼性スコアを付与します。このスコアに基づき、情報の統合度合いを動的に調整することで、悪意のある操作データやノイズによる精度の低下を防ぎます ［7］。

3. C-RAG (Contrastive RAG): 対照的な説明を生成させることで、複数の情報源の間の相違点を明示的にモデルに理解させます。これにより、単一の情報を盲信するのではなく、多角的な視点から結論を導き出す「批判的推論」を促進します ［15］。

システム的な制約：レイテンシとトークンの経済学

LLMとウェブ検索を融合させたシステムを実用化する上で、最大の障壁となるのは計算リソースの制約と、それに伴うレイテンシの増大です。これらは「トークン」を基軸とした経済的な最適化問題として捉えることができます ［19］。

コンテキストウィンドウの管理と性能劣化

最新のLLMは100万トークンを超える膨大なコンテキストウィンドウを提供していますが、これは必ずしも「情報を詰め込むほど性能が上がる」ことを意味しません。

• Lost-in-the-Middle問題: 文脈の中間に配置された情報は、最初や最後に配置された情報に比べてモデルの注目（Attention）を受けにくく、無視される傾向があります ［19］。

• 有効コンテキスト長の限界: モデルが実際に高性能を維持できる範囲は、公称の最大ウィンドウよりも大幅に短いことが多く、特に長文の質問応答ではハルシネーションの発生率が上昇します ［25］。

• アテンションの希薄化: 関連性の低い文書をコンテキストに含めると、モデルの計算資源が分散され、重要な事実を見落とす確率が高まります。研究によれば、8,000トークンの冗長な情報を与えるよりも、厳選された1,800トークンの方が回答精度が10%以上向上し、ハルシネーション率も半減することが示されています ［19］。

推論レイテンシの構造とボトルネック

LLMの推論にかかる時間は、入力および出力されるトークン数に直接的に依存します。

$$
\small \def\arraystretch{1.5}
\begin{array}{|l|l|l|} \hline
\textsf{\textbf{指標}} & \textsf{\textbf{技術的影響}} & \textsf{\textbf{ユーザー体験への影響}} \\ \hline
\textsf{\textbf{トークンあたりの加算時間}} & \textsf{不要なトークンが1つ増えるごとに約0.05〜0.1msの遅延が生じる ［19］} & \textsf{数千トークンの増大は、秒単位の遅延として体感される ［19］} \\ \hline
\textsf{\textbf{メモリ帯域幅の飽和}} & \textsf{推論レイテンシの47〜63\%が、GPUのメモリ帯域幅の制限に起因する ［19］} & \textsf{コンテキストの肥大化がこのボトルネックを直撃し、スループットを低下させる ［19］} \\ \hline
\textsf{\textbf{コンテキスト圧縮の利得}} & \textsf{4,000トークンを1,200トークンに圧縮すると、初回生成（TTFT）が2〜3倍高速化する ［19］} & \textsf{リアルタイム対話システムにおいて、応答の機敏さが大幅に向上する ［19］} \\ \hline
\end{array}
$$

高度なコンテキスト・エンジニアリングの手法

制約の厳しいプロダクション環境において高いパフォーマンスを維持するためには、コンテキストを「データ」ではなく、高度に最適化されるべき「インフラ」として扱う必要があります。以下の六つのレイヤーで構成される「コンテキスト・エンジニアリング」が有効です ［19］。

• レイヤー1: ターゲット固有のトークナイズ: 使用するモデルと同一のトークナイザーを用いることで、トークン数見積もりの誤差（通常10-20%）を排除します ［19］。

• レイヤー2: セマンティック・チャンキング: 固定文字数での分割ではなく、関数の境界や意味のまとまりに基づいた分割を行い、情報の文脈を保存します ［19］。

• レイヤー3: ベクトルベースの重複排除: 埋め込みベクトルのコサイン類似度を用いて、数ミリ秒以内に重複した情報を排除します ［19］。

• レイヤー4: 顕著性スコアリング: TF-IDFに着想を得た手法を用い、情報の希少性と類似性を天秤にかけて、トークン予算内で最大の情報密度を実現します ［19］。

• レイヤー5: 多層的圧縮: 小型モデル（GPT-4o-miniなど）による要約、あるいは重要文のみを抽出する抽出型圧縮（Extractive Compression）を組み合わせます ［19］。

• レイヤー6: 予算最適化: ナップサック問題のアルゴリズムを応用し、制限されたトークン数の中で回答の質を最大化する情報を選択します ［19］。

互換性とローカライゼーション：日本語特有の障壁

LLMの検索統合は、言語やプラットフォームの垣根を越えた互換性の問題を内包しています。特に日本語のような膠着語（言葉の切れ目がない言語）では、英語圏のシステムをそのまま適用するだけでは不十分です ［26］。

日本語トークナイゼーションと検索の不一致

日本語の処理において、システムの「内部トークン」と「外部検索インデックス」の間のミスマッチが性能低下の主因となります。

• 形態素解析の揺らぎ: 日本語はスペースで単語を区切らないため、形態素解析が必要ですが、解析器の設定によって「人工知能」が「人工/知能」と分割されたり、一語として扱われたりします。この不一致が、検索時のヒット率（Recall）を低下させます ［26］。

• 表記ゆれと全角半角: 「AI」「人工知能」「Ai」などの表記の多様性、さらには全角・半角の混在が、埋め込みベクトル空間において異なる座標としてマッピングされ、セマンティックな検索を妨げます ［26］。

• ByT5による解決案: これらの問題を解決するために、サブワードを介さず「バイトレベル」でテキストを処理するByT5のようなモデルが検討されています。ByT5は、タイポや表記の揺れがあっても、周囲のバイトパターンから意味を維持できる頑健性を備えていますが、生成速度が遅くなる（最大7倍）というトレードオフがあります ［27］。

プラットフォーム間のUIと動作の差異

ユーザーがAI検索の結果をどのように評価し、信頼するかは、インターフェースの設計に大きく依存します。主要なAIサービスは、情報の透明性を確保するために独自のUIラベルを採用しています。

$$
\small \def\arraystretch{1.5}
\begin{array}{|l|l|l|l|} \hline
\textsf{\textbf{サービス}} & \textsf{\textbf{検索モードの呼称}} & \textsf{\textbf{ソース・引用の表示ラベル}} & \textsf{\textbf{信頼性検証のUI機能}} \\ \hline
\textsf{\textbf{ChatGPT}} & \textsf{「ウェブを検索」 ［28］} & \textsf{「情報源」「引用元をチェック」 ［30］} & \textsf{インライン引用および末尾の「Sources」ボタン ［30］} \\ \hline
\textsf{\textbf{Google Gemini}} & \textsf{Google検索との統合 ［26］} & \textsf{「ソース」「回答に貢献したファイル」 ［32］} & \textsf{「回答を再確認」ボタンによる色分け表示（緑・橙） ［32］} \\ \hline
\textsf{\textbf{Perplexity}} & \textsf{リアルタイム検索（常時） ［26］} & \textsf{「出典」「ソース」 ［10］} & \textsf{引用元URL、タイトル、および関連リンクのサイドバー ［26］} \\ \hline
\textsf{\textbf{Microsoft Copilot}} & \textsf{Bing Search連携} & \textsf{「詳細情報」「引用文献」 ［36］} & \textsf{応答上のシールドアイコンによる感度ラベルの提示 ［36］} \\ \hline
\end{array}
$$

特にGeminiが提供する「回答を再確認」機能は、Google検索の結果と「似ている可能性があるコンテンツ（緑）」と「異なる可能性があるコンテンツ（オレンジ）」を視覚的に区別することで、ハルシネーションに対するユーザーの警戒心を高めると同時に、情報の出所を辿るための強力な道筋を提供しています ［32］。

AI SEOとウェブエコシステムの変容

AI検索エンジンの台頭は、ウェブサイト制作者側の戦略、すなわちSEO（検索エンジン最適化）の概念を根本から変えつつあります。AI検索エンジンに引用されるための「AI SEO」が、今後のデジタルマーケティングの重要課題となっています ［13］。

• クローラーの役割: ChatGPTが利用するOAI-SearchBotや、PerplexityのPerplexityBotをrobots.txtで許可することが、AIによる引用を受けるための前提条件となります ［13］。

• 構造化データの重要性: スキーママークアップ（FAQ、Review、Articleなど）を適切に実装することで、AIモデルが内容のセマンティクスを正確にパースし、引用の精度を高めることが可能になります ［13］。

• ドメイン権威の偏り: 日本語クエリにおいて、ChatGPTなどのモデルは、伝統的な検索エンジン以上に「Wikipedia」や「Yahoo!知恵袋」などの大規模プラットフォームを優先的に参照する傾向があり、中小規模の専門サイトが引用されるための障壁が高まっているという指摘もあります ［38］。

潜在的な互換性の問題と未来への展望

ウェブ検索とLLMの融合は、システムの進化に伴い、より微細で予見しにくい互換性の問題を顕在化させています。

データドリフトとセマンティックシフト

外部検索に依存するシステムは、学習時と運用時のデータの性質の「ズレ」に極めて脆弱です。

• 共変量シフト（Covariate Shift）: 入力される特徴量（ウェブの文脈や流行）の分布が変化し、モデルが学習時に獲得した「単語と概念の結びつき」が通用しなくなる現象です ［39］。

• 概念シフト（Concept Shift）: 単語が指し示す意味そのものが時間の経過とともに変化すること（例：新技術の登場による既存用語の再定義）を指します。LMMRecのような手法では、LLM由来のセマンティックプライア（意味的な事前知識）を注入することで、このシフトを緩和する試みが行われています ［41］。

• セマンティック・エロージョン（意味の劣化）: LLMが生成した大量のテキストがウェブに公開され、それを再びLLMが学習・検索することで、言語のバリエーションが標準化され、独特のニュアンスや専門的な深い意味が失われていくリスクが懸念されています ［42］。

統合技術の今後の方向性

本調査を通じて、LLMとウェブ検索の融合は、単なる「情報の付加」から「知能の拡張」へと向かっていることが浮き彫りになりました。今後の展望として、以下の三つの方向性が示唆されます。

• エージェント型RAGの標準化: 単発の検索ではなく、SEARCH-R1やディープリサーチに見られるような、推論と検索のループを前提としたアーキテクチャが、特に高度な意思決定支援や専門的な調査業務において主流となるでしょう ［1］。

• ハードウェア意識のコンテキスト・デザイン: GPUのメモリ帯域幅やレイテンシの物理的制約を考慮し、情報の密度を極限まで高める「インテリジェント・コンテキスト・エンジニアリング」が、商用システムの競争力の源泉となります ［19］。

• 信頼性の可視化と制御: 知識の衝突を隠蔽するのではなく、Geminiの再確認機能のようにユーザーに提示し、人間が最終的な判断を行う「ヒューマン・イン・ザ・ループ」の仕組みが、信頼性の高いAI運用のための必須要件となります ［15］。

結論として、LLMとウェブ検索の融合技術は、情報のアクセシビリティを革命的に向上させる可能性を秘めている一方で、その実装には、アーキテクチャの洗練、知識衝突の厳密な管理、そして物理的なシステム制約との巧妙なバランスが求められます。技術者や研究者は、これらの複雑な要素を統合的に捉え、単に「動く」だけでなく、「真に信頼に足る」システムの構築を目指すべきであると考えられます。

引用文献

1. Answering Highly Complex Questions with Large Language Models through Super Deep and Super Wide Research - arXiv, 3月 21, 2026にアクセス、 https://arxiv.org/html/2603.00582v1

2. The Complete Guide to Large Language Models: Architecture, Training, and the Future, 3月 21, 2026にアクセス、 https://medium.com/@nraman.n6/the-complete-guide-to-large-language-models-architecture-training-and-the-future-cbfd31b79fee

3. Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning - arXiv, 3月 21, 2026にアクセス、 https://arxiv.org/pdf/2503.09516

4. Training LLMs to Reason and Leverage Search Engines with Reinforcement Learning, 3月 21, 2026にアクセス、 https://r.jordan.im/download/language-models/jin2025.pdf

5. Retrieval-Augmented Generation: A Comprehensive Survey of Architectures, Enhancements, and Robustness Frontiers - arXiv, 3月 21, 2026にアクセス、 https://arxiv.org/html/2506.00054v1

6. Retrieval-Augmented Generation for Large Language Models: A Survey - arXiv, 3月 21, 2026にアクセス、 https://arxiv.org/abs/2312.10997

7. RE-RAG: Improving Open-Domain QA Performance and Interpretability with Relevance Estimator in Retrieval-Augmented Generation | Request PDF - ResearchGate, 3月 21, 2026にアクセス、 https://www.researchgate.net/publication/386204640_RE-RAG_Improving_Open-Domain_QA_Performance_and_Interpretability_with_Relevance_Estimator_in_Retrieval-Augmented_Generation

8. How LLMs Do Web Search - Mantra Ideas, 3月 21, 2026にアクセス、 https://mantraideas.com/llm-web-search/

9. Towards Explainable AI in Agentic Retrieval-Augmented Generation: A Systematic Review, 3月 21, 2026にアクセス、 https://www.researchgate.net/publication/397518736_Towards_Explainable_AI_in_Agentic_Retrieval-Augmented_Generation_A_Systematic_Review

10. Perplexity AIとは？特徴やChatGPTとの違い、機能や使い方・活用方法、課題を徹底解説！, 3月 21, 2026にアクセス、 https://ai-market.jp/services/perplexity-ai/

11. LLM Observability: Tutorial & Best Practices - Patronus AI, 3月 21, 2026にアクセス、 https://www.patronus.ai/llm-testing/llm-observability

12. [2404.07220] Blended RAG: Improving RAG (Retriever-Augmented Generation) Accuracy with Semantic Search and Hybrid Query-Based Retrievers - arXiv, 3月 21, 2026にアクセス、 https://arxiv.org/abs/2404.07220

13. How to Optimize for ChatGPT, Perplexity & Gemini in 2026 — AI SEO Playbook, 3月 21, 2026にアクセス、 https://www.amivisibleonai.com/blog/ai-seo-guide-2026

14. Daily Papers - Hugging Face, 3月 21, 2026にアクセス、 https://huggingface.co/papers?q=adaptive%20query%20augmentation

15. Mitigating Hallucination in Large Language Models (LLMs): An Application-Oriented Survey on RAG, Reasoning, and Agentic Systems - arXiv, 3月 21, 2026にアクセス、 https://arxiv.org/html/2510.24476v1

16. Search Augmented Instruction Learning | Request PDF - ResearchGate, 3月 21, 2026にアクセス、 https://www.researchgate.net/publication/376393908_Search_Augmented_Instruction_Learning

17. How LLMs Interpret Web Content: What Every Content Creator Needs to Know - Stridec, 3月 21, 2026にアクセス、 https://www.stridec.com/blog/how-llms-interpret-web-content-content-creator-guide/

18. The Technical User's Introduction to LLM Tokenization - Christopher Samiullah, 3月 21, 2026にアクセス、 https://christophergs.com/blog/understanding-llm-tokenization

19. Context Engineering: The critical Infrastructure challenge in ... - Dev.to, 3月 21, 2026にアクセス、 https://dev.to/siddhantkcode/context-engineering-the-critical-infrastructure-challenge-in-production-llm-systems-4id0

20. Knowledge Conflicts for LLMs: A Survey - arXiv, 3月 21, 2026にアクセス、 https://arxiv.org/html/2403.08319v1

21. [PDF] Knowledge Conflicts for LLMs: A Survey | Semantic Scholar, 3月 21, 2026にアクセス、 https://www.semanticscholar.org/paper/ab8e6df5001dbb9b48445220099425aff536b3e8

22. Probing Latent Knowledge Conflict for Faithful Retrieval-Augmented Generation - arXiv, 3月 21, 2026にアクセス、 https://arxiv.org/html/2510.12460v1

23. [2401.15884] Corrective Retrieval Augmented Generation - arXiv, 3月 21, 2026にアクセス、 https://arxiv.org/abs/2401.15884

24. [2401.15884] Corrective Retrieval Augmented Generation - ar5iv, 3月 21, 2026にアクセス、 https://ar5iv.labs.arxiv.org/html/2401.15884

25. Context Window Management for LLM Apps: Dev Guide - Redis, 3月 21, 2026にアクセス、 https://redis.io/blog/context-window-management-llm-apps-developer-guide/

26. Human Science | Manual Creation, Translation, e-Learning, Moodle ..., 3月 21, 2026にアクセス、 https://www.science.co.jp/en/annotation_blog/42359/

27. はじめての自然言語処理 ByT5 と Charformer の検証 | オブジェクト ..., 3月 21, 2026にアクセス、 https://www.ogis-ri.co.jp/otc/hiroba/technical/similar-document-search/part17.html

28. ビジネスを加速させる！ChatGPT Searchの魅力と使い方, 3月 21, 2026にアクセス、 https://www.insource-da.co.jp/dxpedia/03_0050.html

29. ChatGPT searchの使い方：新機能web検索を使う条件は？ - GPT Master, 3月 21, 2026にアクセス、 https://chatgpt-enterprise.jp/blog/chatgpt-search/

30. ChatGPTのWeb検索機能「ChatGPT search」とは？使い方・活用例を解説, 3月 21, 2026にアクセス、 https://biz.moneyforward.com/ai/basic/1853/

31. 検索機能「ChatGPT search」を解説｜機能や使い方、活用事例まで - ExcelCamp, 3月 21, 2026にアクセス、 https://excelcamp.jp/ai-bot/media/howto/32439/

32. 関連ソースを表示し、Gemini アプリの回答を再確認する - Android, 3月 21, 2026にアクセス、 https://support.google.com/gemini/answer/14143489?hl=ja&co=GENIE.Platform%3DAndroid

33. Google Workspace with Gemini でソースを使用する方法, 3月 21, 2026にアクセス、 https://support.google.com/a/users/answer/16813283?hl=ja

34. 【2025年最新】Geminiのファクトチェック機能完全解説 ~ChatGPT / Google AI Studioとの違い, 3月 21, 2026にアクセス、 https://note.com/aimasterroad/n/ne27b5a92fbd5

35. 【AI活用術】Perplexity AI日本語対応｜業務効率化と精度UPの秘訣 - Hakky Handbook, 3月 21, 2026にアクセス、 https://book.st-hakky.com/data-science/ai-paradox-latest-trends

36. エージェントの応答で感度ラベルを確認する - Microsoft Copilot Studio, 3月 21, 2026にアクセス、 https://learn.microsoft.com/ja-jp/microsoft-copilot-studio/sensitivity-label-copilot-studio

37. How to Get Your Website “Indexed” in ChatGPT, Gemini, Grok and Perplexity: A Comprehensive Guide - Custom Web Development & AI Integration | NP Group, 3月 21, 2026にアクセス、 https://www.npgroup.net/blog/get-website-indexed-chatgpt-gemini-perplexity-guide/

38. How to Track AI Visibility for Japanese Websites, 3月 21, 2026にアクセス、 https://www.bloomstreetjapan.com/how-to-track-ai-visibility-for-japanese-websites/

39. Continuous Evaluation and Drift Monitoring - Agility at Scale, 3月 21, 2026にアクセス、 https://agility-at-scale.com/ai/generative/continuous-evaluation-and-drift-monitoring/

40. Handling Out-of-Distribution Data: A Survey - IEEE Computer Society, 3月 21, 2026にアクセス、 https://www.computer.org/csdl/journal/tk/2025/10/11098614/28IR1XtmzAY

41. LLM-driven Multimodal Recommendation - arXiv.org, 3月 21, 2026にアクセス、 https://arxiv.org/html/2602.05474v5

42. Seeing the Shift : Keep an Eye on Semantic Changes in Times of LLMs - KOPS, 3月 21, 2026にアクセス、 https://kops.uni-konstanz.de/bitstreams/b764f194-f43f-457b-a304-4176a59e0e2b/download

43. How CIOs Can Minimize LLM Hallucinations and Maximize AI Accuracy in 2025 - You.com, 3月 21, 2026にアクセス、 https://you.com/resources/cio-minimize-llm-hallucinations-maximize-ai-accuracy-2025