大規模言語モデル

大規模言語モデルは、非常に大規模なテキストデータセットでトレーニングされた機械学習モデルで、トークン（テキストの小さな単位）を予測し、受けた文脈から言語を生成します [1]。

LLMは多くのチャットボット、ライティングアシスタント、コーディングアシスタント、ドキュメントツールのエンジンです。プロンプトを入力します。プロンプト、会話、トレーニング中に学んだパターンを使用して、次のトークンまたはトークンのシーケンスを予測します。答えは役立ち、構造的で速いかもしれませんが、デフォルトでは検証された知識ではなく、生成された出力です。

最も安全なメンタルモデルは単純です。LLMは文脈から信頼性の高い言語を非常に得意としています。説明、要約、翻訳、下書き、分類、例の処理、構造化された分析の作成が可能です。現代のLLMは強力にTransformerアーキテクチャによって形作られています [2]。しかし、事実を見落としたり、詳細を創作したり、証拠が弱いにもかかわらず確信しているように聞こえることもあります。NISTは生成型AIのリスクを、モデルの選択だけで解決できるものではなく、設計、使用、モニタリング、評価のあらゆる段階で組織が管理すべきものとして扱っています [3]。

LLMは現在、検索ツール、オフィススイート、コードエディタ、サポートシステム、学習製品、分析ワークフローに組み込まれています。ユーザーが使用しているシステムの種類を理解していない場合、ドラフトを検証された答えと誤って扱ったり、データルールを考慮せずにプライベートな情報をツールに貼り付けたりする可能性があります。

LLMの理解は、より良い質問を尋ねるのにも役立ちます。タスク、対象読者、ソース資料、制約を含むプロンプトは、モデルに明確な道を提供します。これは正確性を保証するものではありませんが、曖昧さを減らします。また、ユーザーが生成された表現と、まだ出典が必要な事実を分離するのにも役立ちます。

チームだけでなく個人にとっても重要です。教師はLLMを使って練習問題を作成し、マネージャーはポリシーの要約を再構成し、開発者はコードの下書きを作成することができます。どのケースでも、モデルの出力は時間を節約できますが、ユーザーは責任を持って使用する前に適合性、証拠、リスクを確認する決定を保持する必要があります。

高レベルで見ると、LLMは入力を小さなテキストユニットに変換し、そのユニットをモデルを通じて処理し、次に何が来るべきかを予測します。現代のLLMは、2017年の論文「Attention Is All You Need」[2]で導入された注目ベースのシーケンスモデリングによって強く形作られています。この論文は現在のモデルアーキテクチャの重要な出発点ですが、それ自体で現代のすべてのLLM、製品、トレーニング方法、またはセーフティシステムを定義するものではありません。

トレーニング中にモデルはデータから統計的なパターンを学びます。使用中にモデルは通常、あなたのプロンプトで再トレーニングしません。プロンプトと利用可能なコンテキストを使用して出力を生成します。GoogleのLLMの紹介は、トークン、コンテキスト、予測、生成されたテキストなどの言語モデルのメカニクスに役立ちますが、ベンダーの教育ページはリスクや安全性に関する主張の唯一の権威として扱われてはなりません [1]。

多くの展開されたアシスタントはモデルの周りに追加のシステムを追加します。指示、検索、セーフティフィルター、ツールコール、ロギング、製品ポリシー、ユーザーインターフェースの選択などです。これらのシステムは有用性を向上させますが、表示される答えは依然として生成された言語です。OpenAI自身のユーザーガイドでは、システムが不正確である可能性があり、重要な情報は確認する必要があると述べています。このガイドはベンダー固有のアドバイスとして役立ちますが、すべてのAIシステムに関する普遍的な保証ではありません [4]。

トレーニングと使用の違いは特に重要です。トレーニングはユーザーが到着する前にモデルを形作ります。プロンプトは、インタラクション中にモデルにタスク固有のコンテキストを与えます。検索ツールは外部ドキュメントを追加する可能性があります。製品ルールは一部の出力をブロックする可能性があります。ユーザーが1つの答えを見たとき、これらのレイヤーすべてが関与している可能性があるため、システム設計を知らないまま「モデルは知っていた」とか「モデルは検索した」と言うのは単純すぎます。

マネージャーがAIアシスタントに新しい返品ポリシーを貼り付け、次のように尋ねます。「フロントラインサポート担当者に5つのポイントで要約してください。使用できるのは提供されたポリシーのみです。法務レビューが必要なものをマークしてください。」LLMはプロンプトと貼り付けたポリシーをコンテキストとして読み取り、要求された構造に従った要約を生成します。

結果は強力な最初のドラフトになる可能性があります。マネージャーは、各項目がポリシーによってサポートされているか、どの条件が見落とされたか、および法的レビューのフラグが妥当であるかを確認する必要があります。ポリシーに返金が国、製品タイプ、購入日によって依存するとある場合、ユーザーはチームに要約を送る前にソースドキュメントでこれらの詳細を確認する必要があります。

最も一般的な誤解は、LLMがデータベースのように動作すると考えることです。データベースは記録を保存し、一致する記録を返します。LLMは文脈と学習されたパターンから可能性の高い言語を生成します。正しい事実を生成するかもしれませんが、そのメカニズムは信頼できる記録を開き、答えをコピーするのとは異なります。

その違いは重要です。定義、下書きメール、または考慮すべき質問のリストを尋ねると、生成は役立ちます。法的引用、顧客固有のアカウント詳細、医療用の投与量、または現在のポリシーの期限を尋ねると、権威あるソースとレビューのステップが必要です。

LLMは幻覚を起こす可能性があり、データや設計選択にバイアスを反映し、コンテキストウィンドウの外の情報を見落とし、小さなプロンプトの変更に対して異なる反応をすることがあります。ユーザーがポリシーを確認せずに個人的、機密的、規制対象、または特許情報をツールに貼り付けると、リスクを暴露する可能性があります。

長い答えが必ずしも良い答えではありません。自信ありげな答えが必ずしも検証された答えではありません。引用のように見える文字列が必ずしも実際のソースではありません。プロンプトは出力の形を改善するかもしれませんが、真実を保証することはできません。人間によるレビューは多くの問題を発見できますが、レビュアーが時間、文脈、または専門知識が不足している場合、失敗することもあります。

LLMの答えに頼る前に、尋ねてください：どのソース素材を使用しましたか？どの主張が重要ですか？どの主張が意見、要約、または推測ですか？この答えが間違っていたらどうなりますか？機密データが含まれていますか？人間の専門家、一次ソース、または二重チェックが必要ですか？

LLMを下書き、説明、ブレインストーミング、提供されたテキストの要約、および作業の開始を容易にするために使用してください。金銭、健康、法務、安全、雇用、個人データ、セキュリティ、または公共の主張に関わる決定では、遅くしてください。そのようなケースでは、LLMの出力を実際の証拠と照らし合わせて確認する必要がある下書きとして扱ってください。

実用的なワークフローは、モデルに構造化されたドラフトを依頼し、出力を主張、推奨、スタイル選択に分けることです。スタイル選択は編集のみが必要です。推奨は判断が必要です。主張はソースが必要です。これにより、ツールが役に立つままに保ちつつ、流暢な言葉が検証に置き換わることを防ぎます。