はじめに
生成AIという単語と同時に【プロンプト】という単語をよく聞きました。
ChatGPTなどを使う時、正直【プロンプト】を意識しなくても「このエラーは何？」とエラー文を貼り付けるだけで、必要十分な回答をくれている気がしています。
けれど、たまに(60%くらいの確率で)嘘をついてるな、、と思ったこともありました。
そこで今更ではありますが、何故プロンプトが重要なのかを技術的な観点から見ていきたいと思います。
この記事が参考になりそうな人
「プロンプトが大事ってなんか聞いたことあるな～」や「LLMって初めて聞いた」「LLMの内部について知りたいな」という方が対象です。
それ以外の先輩方には味気ない内容となっていると思いますが、良ければご覧ください。
※ 本記事では直感的な理解を優先し、細部は簡略化して説明しています。
生成AIとは
皆さん既にご存じの方も多いと思いますが、生成AIについて軽くまとめてみます。
生成AIは知っての通り、AIの一部です。
AI技術としてよく聞く機械学習や深層学習は判別や予測を行っており、学習したパターンに基づいて値などを予測していました。
あらかじめ用意された選択肢の中から、入力に対して最も適切な答えを出力しているようなイメージです。
生成AIはあらかじめ用意された解答はなく、学習したデータ分布をもとに新しい答えを生成しています。
生成AIには以下の代表的な技術があります。
| 分野 | 技術 | 生成物 |
|---|---|---|
| 自然言語 | LLM | 文章・コード |
| 画像 | Diffusion / GAN | 画像 |
| 音声 | TTS / Music Gen | 音声・音楽 |
| 動画 | Video Diffusion | 動画 |
今回の記事にて対象にしている生成AIはChatGPTやGeminiなどのLLMという技術を使用した生成AIです。
これからLLMについて内部的な構造を知っていき、プロンプトの重要性について考えていきたいと思います。
LLM とは
概要
LLM(大規模言語モデル)は ChatGPT などのサービス基盤となる AI 技術です。
実際、LLM が何をしているかというと「これまでの入力を条件として、次にもっとも確率が高いトークンを生成」しています。入力に対して次に来るであろう文章などを以前の入力情報をもとに確率的に予測して出力しているのです。
その為、残念ながら ChatGPT などは私たちが入力した内容を完全には理解してくれていません。。
ここでいう「理解していない」とは
意味を内部状態として保持・検証できるわけではないという意味であり、
統計的に高度な文脈表現を獲得していない、という意味ではありません。
トークン：出力の最小単位
自然言語処理とLLMの進化
少しだけAI技術の変遷を覗いてみたいと思います。
1950年代~1970年代：ルールベース
文章を処理するために必要な情報を人間が手作業で「この条件ならこう答える」とルールを定義していました。
登録された知識やルールの量と正確さが回答の精度に直結します。
1980年代~1990年代前半：統計的手法・初期 NLP
確率や統計を用いて言語を処理する手法です。
言語をどう扱うかというモデル構造や判断方法を人間が設計していました。
特徴量の選び方もどう使うかも人間が決めていたため、コンピュータは主に「出現頻度の集計」や「確率の計算」を担当していました。
1990年代後半~2010年代前半~：機械学習
コンピュータがデータから規則やパターンを自動的に学ぶ手法です。
機械学習では、判断ルールを人間が直接書かなくなりました。
人間は
- 特徴量
- 正解ラベル
を与えるだけで
- どの特徴をどの程度重視するか
- どこで判断を分けるか
はコンピュータがやってくれます。
機械学習は
- 正解ラベルをもとに学習する「教師あり学習」
- データの構造やパターンを学ぶ「教師なし学習」
- 試行錯誤で最適な行動を学ぶ「強化学習」
に分類されます。
特徴量設計は人間が行うものの、判断ロジックの一部としてではなく判断材料を提供する役割に変わりました。
2012年頃~：深層学習（Deep Learning）
ニューラルネットワーク(人間の脳の神経細胞の仕組みを模倣したモデル)を用いて、データから有用な特徴表現そのものを自動で学習する手法です。
従来の機械学習では人間が特徴量を設計していましたが、深層学習では
- 画像のピクセル
- 音声波形
- 単語ID(正確にはトークンID)
といった生データに近いデータをそのまま与え
ネットワーク内部の多層構造によって段階的に特徴を抽出します。
その結果、画像・音声・自然言語処理で飛躍的な性能向上が起きました。
2018年頃~：LLM（大規模言語モデル）
Transformer を基盤とした大規模深層学習モデルが誕生しました。
LLMは自然言語を入力とし、単一のモデルで多様なNLP(自然言語処理)タスクをこなす事が特徴です。
学習時には【次のトークンを予測する】という単一の目的で大量のテキストを学習します。
Transformerとは
「文章中のすべてのトークン同士の関係を一度に評価できる」Self-Attention を中核にしたニューラルネットワーク構造。
トークンごとではなく複数のトークンを同時に処理し、文脈的なトークン同士の関係を数値的に捉えています。
後ほど解説しています。
LLM についてもう少し詳しく
AI技術について全体をサラっと知ることが出来たので、LLMについてもう少し詳しく見ていきます。
現在の LLM は、Transformer を中核とした確率モデルを基盤に、トークナイズ、指示調整、RLHF、デコーディング制御、安全フィルタや外部ツール連携などの仕組みを組み合わせることで、実用的な対話型 AI として構成されています。
今回はLLMの中核であるTransformerについて学び、その後LLMの特徴を知っていきます。
Transformerを理解すると、LLMがどのような特徴を持つのかを、より本質的に理解できるようになると思います。
Transformerと自己注意(Self-Attention)について
Transformerとは「文章全体を同時に見ながら、トークン同士の関係を数値化するエンジン」です。
次に来る各トークンの確率分布を計算する装置で、実際にどのトークンを選ぶかはモデル外のランタイムが決めています。
つまり、「このトークンが来る確率は30%、別のトークンが来る確率は25%…」という情報を作るのがTransformerで、その確率をもとに実際にどれを選ぶかを決めるのがランタイムです。
※Transformerは連続値を扱うモデルで、「複数の中から一つを選択する」という離散決定はできないため
また、自己注意(Self-Attention)とはTransformerの機能の一部で、「このトークンは、他のどのトークンをどれだけ信用するか(参照しているか)を計算する仕組み」です。
Transformerの前に存在していたRNN(Recurrent Neural Network)/LSTM(Long Short-Term Memory)との最大の違いは文章内のトークンを順番に読まず、全文のトークンを一気に処理する点です。
文章全体を一気に処理するという仕組みは、各トークン同士の隠れた関係性を発見するのに役立ちます。
Transformerは大きく分けてエンコーダとデコーダの２つの部分から構成されています。
入力値をエンコーダが処理し、デコーダが出力を生成します。
現在の LLM では用途に応じて構成が分化しており、GPT 系モデルは Decoder のみを用いた Decoder-only Transformer を採用しています。
エンコーダとデコーダで何が行われているか
ここからエンコーダとデコーダに分け、内部でどのような処理を行なっているのかさらっと見ていきます。
以下は
https://qiita.com/shingo_morita/items/43000991d04413136d62
こちらの記事が分かりやすいので、こちらを読んでここまで読み飛ばして頂いても大丈夫です。
エンコーダとデコーダの目的と出力
| 観点 | Encoder | Decoder |
|---|---|---|
| 目的 | 理解 | 生成 |
| 出力 | 文の意味表現 | 次トークンの確率 |
スムーズに理解が進むように、Transformerだけでなく、ランタイムでの処理も一緒に記載しています。
その際は、コールアウトにて「ランタイムでの処理です」と記載してありますので、それ以外はTransformerの機能として読み進めていただけたらと思います。
※ランタイム：トークン化・デコーディング戦略・サンプリングなどを含む「モデルを使って推論を成立させる実行側の処理」
エンコーダ
エンコーダは入力文を意味が凝縮された内部表現に変換しています。
1. 入力文章をトークンに分割(トークン化)
ここはランタイムで行われいてる処理です。
文章をモデルが扱える最小単位(トークン)に分割します。
例（概念的）：
"I love cats"
→ ["I", " love", " cats"]
→ 各トークンが内部的なIDに変換される
この時の最小単位は単語ではなくサブワードです。
そのため「tokenization」は「token」「ization」分割されます。
トークンに関してはこちらの記事が分かりやすいと思います。
https://g-gen.co.jp/useful/General-tech/explain-language-generation-ai-token/
2. 各トークンをベクトル化（Token Embedding）
トークン埋め込み(Token Embedding)とはトークンの意味や文脈上の関係性をコンピュータが扱える低次元の数値ベクトルで表現するNLP技術です。
トークンIDを固定長のベクトルに変換し、意味的な特徴を含んだベクトル(数値の並び)に変換します。
nトークン × d_model の行列
例: 5トークン × 768次元
d_model：トークンの意味を多次元ベクトルで表す際の次元数
簡単にいうとプロフィール項目数的なもの
3. 位置情報の付与(Positional Encoding)
次の処理であるSelf-Attentionは、今まで順序付きの配列として扱われていたトークン同士の関係を並列に計算する(集合として扱う)ため、そのままでは「どのトークンが先に現れたか」という順序を表現できません。
並び順を持っていないと以下のような状況が起こりえます。
I love cats
と入力したのに
cats love I
と解釈されてしまう可能性がある
そのため、各トークンの埋め込みベクトルに位置情報（Positional Encoding）を加えることで、「どの位置にあるトークンか」をモデルに明示します。
4. Self-Attentionで各トークンと他のトークンの関連性を計算
文中のすべてのトークン同士の関係を同時に評価し、その結果をもとに各トークンごと「自分にとって重要な他トークンの情報」を重み付きで集約し、文脈を考慮した表現として各トークンに付与しています。
詳しい計算方法が気になる方は以下サイトなどを参考にしてください。
これならわかるSelf-Attention：https://zenn.dev/knowhere_imai/articles/1008252132d315
5. 全結合層（Feedforward Neural Network）で特徴量を変換
Self-Attentionによって集約された文脈情報をもとに、各トークンごとに同一の非線形関数で再表現し、次の処理やトークン予測で使いやすい形に整える役割を持ちます。
デコーダ
デコーダの推論時には、これまでに生成・確定したトークン列全体を入力としてデコーダを実行し、次の1トークンを予測します。
この処理をトークンが1つ確定するたびに繰り返すことで、文章を生成します。
先ほど少しお話しした「Decoder-only Transformer」においては、入力にプロンプトを含めます。
1. Self-Attention
これまでに生成したトークン間の関係性を計算します。
デコーダでの生成処理では、次に生成されるトークンを参照できないよう、過去のトークンのみに注意が向くマスク付きSelf-Attentionが用いられます。
トークン列：
[ 私 ] [ は ] [ 猫 ] [ が ] [ 好き ]
Self-Attention（位置：猫）
参照OK： 私 / は / 猫
参照NG： が / 好き（× マスク）
これにより、これまでにどんな文脈で文章を生成してきたかを考慮した表現が得られます。
マスク付きSelf-Attentionについて
次に生成するトークンという説明に困惑した方もいると思います。
普段私たちがChatGPTに質問してGPTが回答を生成する際、次に生成するトークンの正解は明示的に存在していません。（推論のため）
一方で「正解の全文がすでに存在している状態で次トークン予測の訓練をしている学習時」においては、次に生成するトークンが正解として与えられています。
この学習時において次に生成するトークンを参照できてしまうと、本来予測すべき対象を見てしまうことになり、次トークン予測ではなくカンニングになってしまいます。
なぜそれが普段のデコードでも使用されているかというと、学習時と推論時の計算構造を一致させるためです。
学習時と実運用でのズレを防ぐために、推論時でも次に処理するトークン位置を参照できない構造の「マスク付きSelf-Attention」が使われているということなんですね。
【学習時】
入力: 今日は 天気 が 良い
正解: 明日 は 雨
本来予測すべき対象の全文がある
→ でも次に生成するトークンはマスクで見えないようにして推論を行う
【推論時】
入力: 今日は 天気 が 良い
正解: （存在しない）
学習時と推論時のずれを防ぐために同じマスク構造を使う
2. Encoder–Decoder Attention（※Encoder-Decoder 構造の場合）
エンコーダの出力(入力文全体の文脈表現)と現在のデコーダの状態を照らし合わせます。
これにより、今生成しようとしているトークンが入力文のどの部分に対応しているかを考慮できるようになります。
GPT 系（Decoder-only）ではこの処理は存在しません。
3. 全結合層
Self-AttentionとEncoder–Decoder Attentionによって集められた文脈情報を各トークンごとに同じ非線形変換で整理し、次のトークンを予測しやすい形の特徴表現へと整えます。
4. 線形層 + Softmax
モデル内部で作られた情報を使って、「次にどのトークンが一番自然か」を語彙全体について評価し、その可能性を確率として並べたものを出力します。
5. 次のトークンを確定
ここはランタイム(推論ランタイム)で行われいてる処理です。
実際にどのトークンを選ぶかは、推論ランタイム側でデコーディング戦略に基づいて決定されます。
主な決定方法
| 用途 | 選び方 |
|---|---|
| 翻訳 | 最尤（argmax） |
| 会話 | 確率サンプリング |
| 文章生成 | Top-k / Top-p |
| コード | 低温度（安定） |
Temperature(温度)パラメータ
確率分布の「鋭さ」を調整するパラメータです。
- 低温度(0.1~0.3): 確率が高いトークンをより選びやすくする → 安定・予測可能
- 高温度(0.8~1.5): 確率が低いトークンも選ばれやすくする → 創造的・多様
下記が次のトークンを確定していく際のイメージです。
これまでに生成した全文を条件に、次の1トークンを決める確率
P( 次のトークン | これまでに生成した全トークン )
P(t1) → t1 確定
P(t2 | t1) → t2 確定
P(t3 | t1, t2)
...
Transformerのアーキテクチャについて
Transformerには以下のようなアーキテクチャがあり、用途別に使い分けを行っています。
| 構造 | 特徴 | 代表モデル | 内部 |
|---|---|---|---|
| Encoder-only | 理解・分類に強い | BERT, RoBERTa | 入力された文章全体を同時に見て、文脈を反映した“意味ベクトル”に変換する |
| Decoder-only | 生成に強い | GPT系 | 入力文章をトークン化し、そのトークン列をそのまま Decoder に渡し、Self-Attention によって文脈を解釈しながら次のトークンを予測する |
| Encoder-Decoder | 変換・翻訳に強い | T5, BART | Encord時に入力トークンに意味表現を付与し、DecorderはEncoderが作った意味表現を見て出力を生成する |
GPT系はDecoder-only 構造となっています。
GPT 系が Encoder を持たないのは
「入力も出力も同一のトークン列として扱える」ためで、自己回帰生成(これまでに出した答えを、自分で見直しながら続きを書いていく方式)に最適化されているからです。
Decoder-only モデルでは、入力を一度 Encoder によって固定的な意味表現へ変換するのではなく、Self-Attention によってトークン生成のたびに文脈を解釈します。
入力を事前にエンコードする独立した Encoder フェーズを持つ必要がありません。
Transformerの応用モデルの例
| 分類 | モデル名 | 主用途 | 特徴 |
|---|---|---|---|
| Encoder系 | BERT | 文理解・分類 | 双方向文脈理解、事前学習＋微調整 |
| Encoder系 | RoBERTa | 文理解・分類 | BERT改良版、大規模学習 |
| Encoder系 | ALBERT | 文理解 | パラメータ削減、軽量 |
| Encoder系 | ELECTRA | 文理解 | 生成器と判別器で学習効率向上 |
| Decoder系 | GPT | 文章生成 | 自己回帰型、次トークン予測 |
| Decoder系 | GPT-2 | 文章生成 | 大規模事前学習 |
| Decoder系 | GPT-3 | 汎用生成 | Few-shot対応 |
| Decoder系 | GPT-4 / GPT-4o | 高度生成 | マルチモーダル対応 |
| Encoder-Decoder系 | T5 | 文章変換全般 | すべてをText-to-Textで統一 |
| Encoder-Decoder系 | BART | 要約・生成 | ノイズ除去事前学習 |
| Encoder-Decoder系 | mBART | 多言語翻訳 | 多言語対応 |
| Encoder-Decoder系 | Marian | 翻訳 | 高速・軽量翻訳 |
| Vision Transformer | ViT | 画像分類 | 画像をパッチとして扱う |
| Vision Transformer | Swin Transformer | 画像認識 | 階層構造で効率化 |
| Vision Transformer | DeiT | 画像分類 | データ効率改善 |
| 音声 | Whisper | 音声認識 | 多言語音声→テキスト |
| 音声 | Wav2Vec 2.0 | 音声理解 | 自己教師あり学習 |
| マルチモーダル | CLIP | 画像×テキスト | 共通埋め込み空間 |
| マルチモーダル | Flamingo | 視覚＋言語 | Few-shot視覚言語 |
| コード | Codex | コード生成 | GPT派生、プログラミング特化 |
| コード | CodeBERT | コード理解 | 静的解析・検索 |
LLMの特徴
ここからは本題の「なぜプロンプトが重要になのか」をLLMの特徴を元に考えていきます。
1. 次トークン予測モデル
先ほど記載した通り、LLM は入力された文章を理解しているのではなく
これまでの全トークンの流れから次のトークンを予測し、次に来る可能性が高いトークンを確率分布に基づいて選択（サンプリング）しています。
2. 以前の入力情報を基にする
LLM は会話の履歴やプロンプト全文を「ひと続きのトークン列」として扱っています。
ただ、覚えられる量には限界があり、それをコンテキスト長なんて言ったりもします。
コンテキスト長には入出力データだけではなく、「入力＋過去の会話(履歴として再投入されたトークン)＋出力トークン」が含まれます。
主要な LLM のコンテキスト長は以下の通りです。
| モデル名 | 提供元 | 最大コンテキスト長 | 特徴・補足 |
|---|---|---|---|
| GPT-4o | OpenAI | 128k tokens | 高性能・高速。マルチモーダル対応。実運用で最も安定 |
| GPT-4.1 | OpenAI | 128k tokens | 推論・指示追従性が強化された GPT-4 系 |
| Claude 3 Opus | Anthropic | 200k tokens | 長文理解・要約に非常に強い |
| Claude 3 Sonnet | Anthropic | 200k tokens | Opus より軽量・高速、実務向け |
| Gemini 1.5 Pro | 1M tokens（最大 2M） | 超長文処理が可能（動画・コードベース解析向き） | |
| Llama 3.1 (70B) | Meta | 128k tokens | OSS 系で最大級。自己ホスト可能 |
| Llama 3 (8B/70B) | Meta | 8k / 128k tokens | 軽量〜高性能まで幅広い |
| Mistral Large | Mistral AI | 32k tokens | 欧州発。高速・コスト効率重視 |
| Command R+ | Cohere | 128k tokens | RAG 最適化、業務文書向け |
言語によってトークンの粒度
- 日本語: 1トークン ≒ 1~2文字
- 英語: 1トークン ≒ 0.75単語(約4文字)
したがって、同じ128kトークンでも、日本語では約15~25万文字、英語では約9~10万単語程度が目安となります。
また、コンテキストが長すぎると出力の一貫性と正確性が低下する傾向があります。
主な事象
- Transformer は全文を一度に見るため、Attention の計算が膨大になってしまい出力までが遅くなる
- 全体を均等に見ようとして、重要な情報とそうでない情報の重みづけの差が小さくなってしまい正確性が落ちる
- 先頭と文末の距離が極端に大きいと、文頭に書いてある制約と現在の入力の関連性が低いと判断され、制約が破られてしまう
3. Transformer 構造と自己注意(Self-Attention)
Self-Attention とは、各トークンが「過去のどのトークンが重要か」「どのトークンに強く依存すべきか」を重み付きで参照します。
そのため、プロンプト中の書き方・順序・明示性によって Attention の重み分布が変わり、出力結果に影響が出ます。
4. なぜプロンプトが「思考を誘導」できるのか
LLM は思考せず予測しています。
そのため、予測しやすい形式を提示することによって出力結果(次トークン予測のパターン)を誘導することが出来ます。
5. なぜ曖昧なプロンプトはそれっぽい嘘を生むのか【ハルシネーション】
LLM は「分からない」というのが苦手です。
質問されたら何かを答えるというパターンが多いため、条件があいまいだと「最もそれっぽい文章」を生成するのです。
【結論】プロンプトが重要なのはなんで？
LLM は「意味を理解して正解を返す装置」ではなく、「直前までのトークン列から、次に来やすいトークンを確率的に選ぶ装置」です。
そのため放っておくと、
- 曖昧な質問には統計的に“もっともらしい文章”で埋める（ハルシネーション）
- 会話が長くなると重要な指示が薄れて守られなくなる（指示忘れ）
- 目的や出力形式が曖昧だと学習データに基づく一般的な回答に収束する（ブレ）
といった限界が出ます。
プロンプトはこの限界を補うために、
「目的・前提・制約・出力形式」を明示することで、モデルの確率分布（次トークン予測）を目的に合う方向へ誘導する手段です。
LLMは賢いのでなく、賢くふるまえる条件付き確率モデルです。
プロンプトとはその条件を設計する行為のため、プロンプトを意識することが重要なのだということが分かりました。
おまけ
ChatGPTにベストプラクティスを聞いてみた
本人に聞いてしまえ！ということで
ChatGPT に「高確率で正しい情報を得る方法のベストプラクティスを提示して」と聞いてみました。
その回答を以下に記載します。（AI の回答を読みやすいように少し加工しています）
結論（設計原則）
ChatGPT を「知識検索エンジン」として使うと失敗し、
「確率的推論エンジン」として使うと成功する
その前提で設計します。
1️⃣ ハルシネーションを抑える最重要原則
❌ やってはいけないこと
- 曖昧な質問
- 前提を省略
- 一度に多くを聞く
⭕ やるべきこと（原理）
モデルに「知らないこと」を答えさせない
実践テンプレ
以下について、事実ベースで説明してください。
不確かな場合は「分からない」と明示してください。
推測や一般論は書かないでください。
なぜ効くか
- 出力空間を制約
- 「それっぽい文章」の確率を下げる
2️⃣ 正確性を上げる質問設計（Prompt 設計）
原則：問いは「狭く・具体的に」
❌ 悪い例
Transformerを教えて
⭕ 良い例
Transformerにおける
Self-Attentionの計算対象と
位置エンコーディングの役割を
数式レベルではなく概念レベルで説明してください
技術的理由
- 条件付き確率が一点に集中
- 無関係な知識が出にくくなる
3️⃣ トークン長・コンテキスト長のベストプラクティス
原則
長さ ≠ 正確さ
情報密度 ≫ 情報量
⭕ 推奨運用
| 状況 | 対応 |
|---|---|
| 会話が長くなった | 新スレッドで再掲 |
| 前提が重要 | 毎回明示 |
| 長文資料 | 要約してから投入 |
| 複数論点 | 分割して質問 |
なぜか
- Attention 希釈を防ぐ
- 位置情報の弱体化を防ぐ
4️⃣ 前提条件・制約は「毎回」書く
テンプレ例
前提：
- 対象：ソフトウェアエンジニア
- レベル：基礎〜中級
- 観点：技術的・実装寄り
- 禁止：比喩表現、一般論
技術的理由
- トークン位置を最新化
- Attention 重みを復活させる
5️⃣ 「役割（Role）」を明示する
なぜ役割指定が効くのか
- 出力文体・知識領域・抽象度が
条件として固定される
例
あなたは機械学習の研究者です。
以下の質問に学術的観点で答えてください。
👉 「何者として答えるか」は
モデルの探索空間を劇的に狭める
6️⃣ 「正しさ」を検証させる
自己検証プロンプト（強力）
上記の回答について、
誤りや不正確な点がないか
技術的観点から自己レビューしてください。
なぜ効くか
- 1 回目と異なる Attention パターン
- 矛盾が顕在化しやすい
7️⃣ 不確実領域では「選択肢形式」にする
❌
どれが正解？
⭕
以下の選択肢のうち、
一般的に正しいとされるものを選び、
理由を述べてください。
A. ...
B. ...
C. ...
理由
- 出力自由度を強制的に下げる
- ハルシネーション余地を減らす
8️⃣ 長文・専門資料は「RAG 的」に扱う
原則
ChatGPT に“覚えさせない”
必要な部分だけ“見せる”
手順
- 資料を分割
- 関係箇所だけ貼る
- 出典を明示
以下の文章を根拠として回答してください。
この文章に書かれていないことは答えないでください。
9️⃣ 「分からない」を許可する
これは非常に重要です。
明示的に書く
不明な点は無理に補完せず、
「不明」と書いてください。
なぜか
- LLM は沈黙より生成を選びやすい
- 許可しないと「嘘」が出る
10️⃣ 実務向け 黄金テンプレ（保存推奨）
あなたは〇〇の専門家です。
前提：
- 対象：
- 観点：
- 制約：
質問：
（具体的・単一論点）
条件：
- 不確実な点は「不明」と明示
- 推測はしない
- 根拠がある場合は明示
最終まとめ（本質）
ChatGPT の精度は
モデル性能ではなく
「情報の与え方」で決まる
- ハルシネーションは仕様
- コンテキスト長は諸刃の剣
- 正確性は設計で作る
所感
「ChatGPTを知識検索エンジンとして使うと失敗する」という言葉に驚きました。めちゃめちゃ知識検索エンジンだと思っていました。。
ChatGPTが出たばかりの頃に「ChatGPTに語尾を指定してみた」という投稿を見たことがあります。
ユーザ「語尾ににゃを付けて話して」
GPT「わかったにゃ」
ユーザ「敬語にして」
GPT「分かりました」
ユーザ『なんでにゃが消えてるんだ！💢』
「語尾ににゃを付けたまま敬語にして」
GPT「分かりましたにゃ」
ユーザ『大満足🐱』
今回、LLMについて勉強をしたことによって、上記のような「さっき言ったこと覚えてないの！？」という現象の理由を自分なりに考えることが出来るフェーズまで行けたのかなと思います。
皆さんはなんでだと思われますか？？
ちなみに私は
「一つ目の指示と２つ目の指示の関連性が低いと思われ、エンコーディングの次トークン予測の確定時に「にゃ」の語尾にすることが確率的に選ばれなかったからかな」
と思ったのですが、こちらをChatGPTに聞いたところ
GPTの回答
「複数の指示が同時に存在する場合、モデルはそれらを論理的に保持・合成するのではなく、学習分布と Attention に基づいて「もっとも自然で確率が高い出力」を選ぶ。その結果、文体装飾的な指示（にゃ）が落ちることがある。」だそうです。なんかちょっと違ってた。。最も自然な回答を選ぶみたいですね。
以前までは「何でさっき言ったことと違うこと言いだしてるんだ！」と思っていましたが、こうやって理解できたということは一歩前進なんじゃないかな、、と自分に甘く、この記事を締めたいと思います。
知るって大事ですね。
おわりに
今回の記事はAIを使うだけだった初心者エンジニアが
ネットで調べまくったり、ChatGPTに聞きまくったりして書いた文章ですので熟練者の方が見たら間違っている部分もあるかもしれません。
もしお気づきの点ありましたら、コメントいただけますと幸いです。
また、「これ調べるとおもろいよ～」(AIでもAI意外でも)があれば教えていただけますと泣いて喜びます。
参考
https://journal.ntt.co.jp/article/25744
https://elcamy.com/blog/llm-history
https://zenn.dev/karaage0703/articles/76f2a1b20cd6c1
https://note.com/ilujapan/n/n3de92b34e9e9#1f3a3d3c-124e-4b6b-95cb-ceca4eacabda
https://aismiley.co.jp/ai_news/what-is-transformer-deep-learning/