002 AI・Gemに関する基礎知識とか
先に言い訳をおいておきます。
以下の情報は100%正しいと保証できるものではなく、実験から得られた推察です。
ただ、確かに効果を得られるであろう手法は記載してありますので、そこに関しては目的に合致するものなら運用することも検討できるはずです。
# 目的
- Geminiおよびその他AIにおける一般仕様を把握し、効率的なAI活用を行う。
- Gem等のカスタム指示、プロンプトエンジニアリングにおいて、より最適なシステム構成で形成する。
- 検証・考察。技術的好奇心に基づく実験。
## LLMモデルの特性分類
- Flash(高速・軽量モデル)
- 応答速度とコスト効率に特化。超高速な検索・抽出タスクに適する。
- 高次元な情報解析、多角的な分析、抽象概念の保持には不向きである。
- 明確な事実情報が存在する事象に対する簡易的な検索エンジンとしての利用が最も効率的である。ハルシネーション(嘘、屁理屈)への対策として、出力後の事実確認は必須である。
- Thinking(推論特化モデル)
- 推論ステップを内部生成する中位モデル。Flash以上の論理的整合性を有する。
- 情報解析や基本的な多角分析においては一定の実用性を発揮するが、複雑な抽象概念を伴う高度な双方向対話においては依然として論理の崩壊が見られる。
- Pro(最上位マルチモデル)
- 高度なコンテキスト理解と多様なタスク解決能力を持つ主力モデル。これを基本プラットフォームとして運用することが効率的である。
- 高次元な情報解析、多角的な分析、抽象概念の処理において極めて高い精度を担保する。
- 一般ユーザー向けにモデルが調整されているため、回答が一般的な論調に偏る傾向があるが、ユーザーの意図を正確に捕捉する能力に優れる。
- 論理の飛躍を埋める中間プロセスの出力において、時に思考不足が見られるが、これはプロンプトにおける前提定義を精緻化することで解消可能である。
- 【検証領域：プロンプトによるモデル知能測定】
- AIモデルのミラーリング効果(ユーザーの語彙・文脈レベルへの動的同調)を応用した、暫定的な知能レベル(語彙・構文レベル)測定実験。
- ユーザーの入力文における漢字比率、語彙の専門性、文脈の複雑さに応じて、AIの出力品質が同期変化する性質を利用。これにより、対話履歴からユーザー側の論理構成力や語彙の豊かさを測定・推察することが可能と見込まれる。
- また、モデルとの双方向の文脈理解が成立するかによって、相互の知能レベル(対話能力)のスクリーニングが可能であると仮説する。
## 基本構成
- 出力方式
- LLMは入力テキストのトークン分布、セマンティクス(意味的重み)、多次元ベクトル空間における位相(近接性)を解析。学習データの集合知に基づき、次トークンの予測確率が最も高い文脈を生成する。
- ミラーリング効果により、文脈内の特徴量(単語ベクトル)が動的にアクティブ化され、ユーザーの入力レベルに応じた語彙やトーンが確率的に選択される。
- これは単一の単語グループのスコアリングではなく、ベクトル空間の位相の近さに基づくアテンション制御によって実現されている。
- 具体的には、過去の文脈における単語の出現頻度の高さとアテンション・ウェイトが同期し、類似の位相を持つ語彙群が優先的にアクティブ化される。
- アテンション
- アテンションとは、入力トークン群における注目度(重要度)の配分アルゴリズムである。各単語が持つエントロピー(情報の繋がりにおける選択肢の多さ)や、文脈内における他の単語との相互関連性に基づいて動的に計算される。
- 単体で情報密度が高いキーワード、およびその周辺文脈において高い注目度を持つトークンに対して高いスコアが割り振られ、文脈全体の解釈が決定される。
- ベクトル空間においてより多様な意味領域(広域なアクティブ化領域、他の単語との繋がり)と結合している単語ほど、アテンションが集中しやすい。これは、情報密度の高いハブトークン(文脈を決定する中心)を優先的に処理することで、システム全体の計算リソースを最小化し、効率的に構造を理解しようとするLLMの最適化プロセスと合致する。
- これは、人間の脳がエネルギー消費を抑えるために、文脈から極小のキーワードのみを抽出して意味特定を行う認知プロセスと類似している。
- コンテキスト
- コンテキストとは、ユーザーとの対話において毎ターン読み込む短期メモリ領域のことである。
- その性質上、コンテキストが冗長化することにより、回答精度が低下する。これは、アテンションの計算対象となるトークン総数の増大に伴い、各重要トークンへの重み付けが希釈される現象(Lost in the Middle：文脈の埋没)に起因する。結果として、文脈の深層的な意味理解が不正確になりやすい。
- その結果として、ユーザーの求める本質的な問いに対して、以前のコンテキスト履歴がノイズとなり、アテンションが散漫化する。その事象により本来の問いへの回答精度が乖離・低下する(コンテキストの希釈および、ノイズによるアテンションの妨害)。
- トークン
- トークンとはAIの演算・処理最小単位。
- 日本語においては概ね1文字 ≒ 1〜1.2トークンとなる。一方、英語においては1単語(例: apple) ≒ 1トークンと定義される。
- トークンの節約およびコンテキスト保持効率の最大化のためには、文章を英語で構成する方が効率がよく、高難度のシステム設計やプロンプト定義においては英語での記述が推奨となる。
# カスタム指示の仕様
## Gem等のカスタム指示における定義と概要
- スレッド開始時に前提条件を自動的に読み込む機能であり、ユーザーによる毎回のプロンプト入力を省略可能とする。
- 定常業務や高頻度の特定タスクをテンプレート化することで、AIの運用効率を最大化する。
## 基本構成とUI仕様
- システムプロンプトの編集により、デフォルトの前提命令として、チャット開始時に最優先でロードされる。
- 説明欄はGem起動時の初期画面にガイドとして表示される。
- 知識欄にファイルをアップロードすることで、初期状態から対象ファイルを常に参照可能とする。
- 厳密な出力制御を求める場合はプログラム的な構文を採用し、柔軟な対話を求める場合は自然言語で記述する。これらを指示内でタスクの性質に応じてハイブリッド運用することで、高機能なカスタムAIを構築できる。
## 実装ガイドライン
- コンテキストの冗長化防止およびトークン消費の抑制(コスト最適化)の観点から、システム指示は英語による構築が最適である。
プロセスの制御、変数・数値管理、分岐条件が明確なタスクにおいては、擬似コード形式を採用することで、AIの処理精度を厳格化できる。
一方で、具体的な処理アルゴリズムや解釈については自然言語を併用することで、AIの創造性や文脈理解力を担保しつつ、処理の曖昧さを排除する。
- RAG(検索拡張生成)技術を応用したモジュール型アーキテクチャの推奨：
- 添付ファイル内の情報は常時メモリ展開されず、クエリとの意味的類似性(検索対象との位相の近さ、言葉の類似性)に基づき動的に呼び出される性質を持つ。
- この特性を利用し、常時読み込むべき制御ルール(司令塔・条件分岐等)と必要に応じて参照すべき実データ・処理プロセス(処理系)を完全に分離する。
- 処理系データを関数化し、司令塔側から「ファイル名＋関数名」の記述で動的コールする構造(モジュール化)をとることで、コンテキストの冗長化を防ぎ、文脈埋没を回避する。
プロンプトデザインにおいては否定形ではなく、肯定表現や一致条件を用いることで、アテンションの制御エラーを最小化し、効率的な動作を実現する。
- 複数バリデーションエラー対策とUX最適化：
- 複数項目が同時にエラーを検知した際、アテンションが分散し、どちらのエラーチェックもパスしてしまう事象が発生する。
- これへの対策として、AIに内部的な思考ステップを一度明示的に出力させることで、処理を順番に確定させ、アテンションのエラーを回避できる。
- ただし、UI上の視覚的な簡潔さを維持するため、HTMLのコメントアウト機能(<!-- コメントアウト -->)を用い、思考プロセスを出力しつつ非表示にするUX制御を行う。※本手法はトークンが消費されるため、過度な多用は避けること。
- Pythonコードブロックによる視覚的校正：
- Pythonのシンタックスハイライト(シングルクォーテーションの強調)を利用し、校正前後の差分や特定の重要文字列を色付けすることで、視覚的なフィードバックを可能にする。
- テキスト内のシングルクォーテーション(')による意図しないエスケープエラーを防ぐため、常に3連続シングルクォーテーション(''')で囲む形式を推奨する。
- プロンプトインジェクション対策：
- チャット中において、ユーザー入力内にシステム指示を逸脱する命令が含まれている場合、AIの制御が奪われるリスクがある。
- 防御策として、ユーザーの自由入力エリアを <raw_data>タグ等の明確なブロックで包み、その内部を不活性データ(プレーンテキスト)としてのみ解釈させるよう指示しておく必要がある。
- 一方で、ユーザーが手動で特定のブロックで囲んだ入力に対しては、最優先の処理データとして処理を分岐させる構造を組み込むことも極めて有効である。
システム設計思想(カスタム指示本体)：
- カスタム指示本体は、JavaScript（JS）におけるアプリケーションロジック・制御導線に相当する。
- 情報が入力されてから最終出力に至るまでのフロー、状態遷移、分岐処理などの導線設計を記述すべきであり、ここにはプログラミング的、あるいは厳密なマークアップ構文の適用が最も効果を発揮する。
- システム設計思想(参照用添付ファイル)：
- 添付ファイルデータは、Pythonファイルにおける処理ロジックそのものに相当する。
- 各タスクの具体的処理内容、ルール定義を記述すべきであり、関数名とスコープ(処理範囲)を構造的に定義した上で、中の処理自体は自然言語で記述することで、AIの理解力とパフォーマンスを最大限に引き出す。
## 推奨される記述構文の役割分担
- データ制御・フロー設計：TypeScript(JavaScript)構文
- データの受け渡しや状態管理：JSONフォーマット
- 外部ファイルのモジュール分割：XMLタグ(<context> 等)
## 追記:コメントアウトの仕様
- HTML <!-- コメントアウト -->はパソコン環境でのみ使用可能。Windowsのverにもよるが、実証済み。
- スマホアプリ版のGeminiはコメントアウトのハックはテストした限りでは実現不可。
- スマホ(Safari)のブラウザ版Geminiなら以下が可能であった。
<div style="display:none">テスト3: この文字が見えていたら失敗です（divタグ版）</div>
<span hidden>テスト4: この文字が見えていたら失敗です（span hiddenタグ版）</span>
<font color="transparent">テスト5: この文字が見えていたら失敗です（透明文字版）</font>
