LLM とは？大規模言語モデルの仕組み
LLM とは、大規模言語モデルのことです。テキストで学習し、言語タスクに役立つパターンを習得する機械学習モデルを指します。多くの生成型LLMは、入力と生成済みのテキストから次々とトークンを予測して応答を作ります。モデルは言語処理の動作を担い、アプリケーションはその周囲のデータ、権限、ツール、インターフェースを提供します。
執筆：Ai Flowi · 公開日
ここでのLLMは人工知能に関する用語です。言語モデルは下書き、要約、分類、情報抽出の支援ができますが、もっともらしい応答は正しさの証拠ではありません。動作は、選んだモデル、要求、アプリケーションが提供する根拠によって変わります。
LLMは何の略か
large language modelの頭文字です。「言語」はテキストを中心とした学習タスクを表し、「モデル」は入力の処理に使う学習済みの数学的なシステムを指します。「大規模」は大まかな表現であり、すべてのモデルが同じ作業をできるようになる固定のサイズ基準ではありません。
チャットボットは会話のインターフェースであり、LLMはその背後で使われるモデルの選択肢の1つです。ワークフローは、1つの解釈段階にLLMを使っても、自律型エージェントになるとは限りません。アプリケーションは、言語モデルを一度も呼び出さずに、決定論的な処理で役立つ作業を行うこともできます。
製品内のこれらの役割は、既存のエージェント・ワークフロー・チャットボットのガイドで説明しています。この項目は、インターフェースや契約プランをLLMの定義とするのではなく、その基盤となるモデルを説明します。
トークンの予測から文章ができる仕組み
トークンは、モデルのトークナイザーが使う表現の単位です。単語、単語の一部、その他のテキスト単位に対応することがあり、1トークンが1単語に等しいという共通の規則はありません。トークン化は、モデルの入力と出力の上限を解釈するうえで重要です。
生成中、モデルは入力と直前までに生成したトークンに基づいて、次に出現し得るトークンを推定します。生成手順は、停止条件に達するまでトークンを選びます。モデルが言語のパターンを学んでいるため文章は一貫したものになり得ますが、根拠のない詳細を含む場合もあります。
要求を送っても、リアルタイムのデータベース照会が自動的に行われるわけではありません。アプリケーションが検索した内容や設定済みのツールの観測結果を提供しない限り、モデルが最新の情報源を参照したとは想定できません。流暢な回答を、外部の操作を実行した報告と取り違えてはいけません。
学習と推論は異なる処理
学習では、データと最適化処理を使って、モデルの学習済みパラメータを更新します。推論は、モデルを使って要求を処理します。プロンプトで方針の一節をモデルに与えることは、通常は推論入力の一部であり、それだけで新たな学習を実行したことにはなりません。
ファインチューニングは、より限定した目的のためにモデルに適用する学習処理です。一方、プロンプトに例を加えることは、文脈内での手法です。どちらの説明も、プロバイダーがサービス方針に基づいて何を保存・利用するかを確定するものではありません。データの取り扱い条件は別途確認する必要があります。
この区別は、文書アシスタントの問題を調べる際に役立ちます。方針が変わった場合、アプリケーションは推論用に提供する根拠を更新する必要があるかもしれません。プロンプトの言い換えでは未更新の情報源を修正できません。また、一節をアップロードしても、モデルの学習済みパラメータが変わった証拠にはなりません。
関連情報：ファインチューニングとは：転移学習、重みの変更とコンテキストの提供。
LLMでできること
LLMは、形式の定まらない要求を要約の下書きに変えたり、その意図を分類したり、抽出するフィールドを提案したりできます。架空のメッセージとして「ケーブルをつないだ後も、会議室の画面に何も映りません」を考えます。この例のタスクでは、簡潔な問題の説明と、問題の切り分けに不足している情報を求められます。
求める説明には、画面に何も映らないこととケーブルをつないだことを残し、ハードウェアの故障を創作してはいけません。「ディスプレイの交換が必要です」は、提供されたメッセージの範囲を超えています。原因を未解決のままにして、報告された内容を述べることも有用な応答です。
これらはタスクと、結果を受け入れる条件の例であり、実際に生成された応答ではありません。正確な計算、決まった規則による検証、既知の識別子の照会には、適した決定論的な処理を使います。解釈が必要な場合に言語モデルの柔軟性は役立ちますが、不必要な解釈は避けられる曖昧さを生むことがあります。
関連情報：生成AIとは：下書きの作成と事実の検証の違い。
モデル・アプリケーション・外部データを分ける
ユーザーの要求
→ アプリケーション：アクセスを確認し、タスクの入力を選ぶ
→ 外部データ：必要に応じて、承認済みの記録やツールの観測結果
→ モデルへの要求：指示と選んだコンテキスト
→ 生成された応答
→ アプリケーション：結果を検証して表示するこれは構成の概念図であり、実行可能なFlowiのグラフではありません。ツールを許可するか、どのデータを含めてよいかをアプリケーションが決めます。モデルは、受け取った要求からテキストを生成します。アクションが成功したという返信は、アプリケーションが実際に実行した証拠にはなりません。
コンテキストの上限も、個々のモデル設定に属します。入力、例、根拠、生成される応答は、適用される許容量に収まる必要があります。コンテキストエンジニアリングはその素材の選択を、プロンプトエンジニアリングはタスクの指示を扱います。
AI Flowi Workflowでモデルを使う
Language Modelのリファレンスでは、コンポーネントの要求設定と接続の型を説明しています。
画面に何も映らないというメッセージについては、設定する前にモデルが何を付け加えるかを決めます。要約は、報告された症状を残し、画面の機種情報がないことを指摘できます。ケーブルを調べたり、物理的な故障の診断を確定したりはできません。症状の要約ではなく原因を求めると、同じモデルが両方の要求を処理しても、必要な根拠が変わります。
生成した下書きと元の報告を区別できるようにします。後で技術者がコネクターの緩みを発見した場合、その観測は、独自の情報源を持つ新しい記録に含めます。その観測を、以前のモデル推論で得られた情報として後から扱ってはいけません。この分離により、人の観測から得た記述と言語タスクから得た記述を説明しやすくなります。
埋め込みモデルは、この要約を書くのではなく表現を作るタスクを担います。その違いはテキスト埋め込みの項目で扱います。
さまざまな言い回しの解釈が役立ち、結果を入力に照らして確認できる場合にLLMを選びます。症状フィールドを備えた定型フォームなら、モデル自体が不要かもしれません。プロバイダーやモデルのバージョンを変える場合は、代表的なメッセージをもう一度確認する必要があります。見慣れたコンポーネント名でも、設定が異なる場合に同じ言語処理の動作をする証拠にはなりません。
カタログに記載されていますが、Ai Flowiによる本番環境でのテストは実施されていません
アクセス設定はAPI Hubを参照してください。症状の要約タスクを実行するには、自分のモデルプロバイダーのアカウントとAPI認証情報が必要です。推論の呼び出し料金は別途支払います。
よくある誤りと制限
モデルのトークンをワークフローの課金単位と同一視したり、コンテキスト中の一節を学習として扱ったり、チャットの応答に最新情報の照会が含まれると想定したりしてはいけません。LLMという略称だけから、特定のモデルの能力、知識の最終更新時点、性能の数値は導けません。
アプリケーションにツールを組み込む場合はAgentのリファレンス、文書化された設計の出発点はユースケースを参照してください。モデル、周囲の制御、情報源はそれぞれ確認する必要があります。文章の断定的な表現は、これらの確認の代わりにはなりません。