LLMとは何ですか？

Scrapeless Web Unlockerは、LLMアプリケーションが外部コンテキストとして使用できるウェブコンテンツを取得します。

LLM（大規模言語モデル）とは、大量の言語データを元にパターンを学び、テキスト生成、要約、分類などのタスクをサポートするためにトレーニングされた機械学習モデルです。現在の多くのLLMはトランスフォーマーアーキテクチャを使用しています。これらはテキストをトークンとして処理し、特定のリクエストに対して与えられたコンテキストと学習されたパラメータに基づいて出力を生成します。

LLMはアプリケーションの一部です。チャットインターフェース、会話ストレージ、検索コネクタ、ドキュメントの権限、およびそれに関連するツールは別々のシステムです。この区別は、同じモデルに基づいて構築された2つの製品が非常に異なる動作をする理由を説明しています。ある製品はプロンプトからのみ回答するかもしれませんし、別の製品は現在のドキュメントを取得したり、承認されたタスクを実行したりするかもしれません。

トークンと予測タスク

トークンはトークナイザーによって生成される単位であり、必ずしも単語全体に対応するわけではありません。名前、句読点、または単語の一部が独自のトークンを占めることがあります。異なるトークナイザーは、同じテキストを異なる方法で分割します。これは入力の長さや、アプリケーションが提供できる文脈の量を推定する方法に影響を与えます。

自己回帰型言語モデルでは、生成は利用可能なシーケンスから次のトークンを予測することによって進行し、その後拡張されたシーケンスで続行されます。生成は漸進的であるにもかかわらず、結果は計画された完全な段落のように見えることがあります。アプリケーションは、その出力を到着するにつれてユーザーにストリーミングすることがあります。

可能な継続は必ずしも真実の声明ではありません。モデルは、それを支持する証拠にアクセスせずに、もっともらしい引用または馴染みのある説明を生成することができます。正確な事実に依存する作業の場合は、文法的な自信を事実的な自信として扱うのではなく、ソースを取得し出力を確認するようにアプリケーションを設計してください。

なぜトランスフォーマーが重要なのか

トランスフォーマーは、トークンの表現間の関係を計算するためにアテンションメカニズムを使用します。アテンションは、モデルが言語を処理する際にコンテキストを利用するのに役立ちます：単語の意味は、それを取り巻く単語やタスクが求める内容によって変わる可能性があります。 オリジナルのトランスフォーマーアーキテクチャ 注意に基づくアプローチを確立し、現代の言語モデリングの中心的なものとなりました。

モデルアーキテクチャと完成したモデルとの間には有用な区別があります。アーキテクチャは計算構造を説明します。トレーニングデータ、最適化、パラメータ値、そして後の適応が完成したシステムの振る舞いの多くを決定します。モデルがトランスフォーマーであることを知っても、あなたの特定の文書に対する精度についてはほとんど何も教えてくれません。

「大きい」という言葉には、それを超えるすべてのモデルをLLMとし、それ以下のすべてのモデルを何か別のものとする単一の閾値はありません。パラメータ数は一つの特徴ですが、タスクのパフォーマンスはトレーニングの選択や評価条件にも依存します。サイズだけでシステムを選ぶことは避けてください。小さなモデルは、明確に定義されたスキーマを持つ狭い抽出タスクには適切かもしれません。

事前学習、適応、および推論

プレトレーニングは、大規模なトレーニングコレクションを使用してモデルのパラメータを調整します。後の適応は、指示のフォロー、好ましい応答スタイル、または専門的タスクに対するパフォーマンスを形成することができます。推論は、結果として得られたモデルを使用して新しい入力を処理し、出力を生成することです。これらの段階には異なるコストとシステムへの異なる影響があります。

プロンプトにドキュメントを提供することは、推論時の操作です。それ自体はモデルの重みが更新されたことを意味しません。同様に、アプリケーションによって提供された会話履歴は、基本モデルにその情報を永久に教えることなく、モデルがコンテキストを維持するのに役立ちます。データの保持と将来のトレーニングの使用はサービスと構成に依存するため、それらは別々に確認する必要があります。

研究について few-shot言語モデルの振る舞い 文脈における例が、タスク特有のパラメータ更新なしにタスクを導く方法を探ります。アプリケーションの設計において、これは実際的な最初の実験を示唆しています：カスタムトレーニングプロジェクトが必要であると決定する前に、明確な指示と代表的な例を提供します。

コンテキストウィンドウの役割

コンテキストウィンドウは、リクエスト内でモデルが考慮できるトークン化された材料の量を制限します。これはモデルおよびサービス設定に依存します。指示、ユーザーコンテンツ、以前のメッセージ、取得された抜粋、ツールの結果など、すべてがそのスペースを争う可能性があります。大きな広告されたウィンドウがあるからといって、含まれるすべての詳細が同等にうまく使用されるわけではありません。

研究の 長文における情報の配置 コンテキストの長さとコンテキストの効果的な使用が別々に評価されなければならない理由を示します。文書アーカイブ全体を一つのプロンプトに配置することが、質問に答えるために段落を慎重に選択することに等しいと仮定しないでください。

ポリシーアシスタントの場合、質問、該当ポリシーのバージョン、および関連する例外を一緒に考慮できるほど近くに保ってください。重複したナビゲーションテキストや古いコピーは削除します。ソース資料に矛盾がある場合は、キーワードを含むパッセージだけを選ぶのではなく、その矛盾を明示的に保存します。

リトリーバルはアプリケーションに外部証拠を提供します

リトリーバルは、リクエスト時にモデルのパラメータの外部から素材を供給します。リトリーバルシステムは、データベースを検索したり、インデックスにクエリをかけたり、ウェブページを収集したりすることがあります。アプリケーションは、その後、選択されたコンテンツをLLMに提示します。これにより、システムはモデルのトレーニングとは独立して変化する情報を扱うことができるようになります。

インフォメーションを管理するドキュメントアシスタントの場合、ソースパイプラインは承認された公開ドキュメントを収集し、セクションを抽出し、URLを保持し、検索用にインデックスを作成できます。読者が機能について尋ねると、システムは該当するセクションを取得し、その証拠に基づいてモデルに回答を要求します。ソースリンクは応答を確認するために利用できる状態を維持するべきです。

ツールはモデルがワークフローに参加するのを可能にします

ツールは周囲のアプリケーションが呼び出すことができるアクションまたは情報ソースを公開します。モデルがツールコールを提案することもありますが、ホストアプリケーションがそのコールが許可されるかどうか、その結果がどのように返されるかを制御します。したがって、ツール対応のアシスタントは、実行のために通常のソフトウェアに依存しながらも、単に文章を生成する以上のことを行うことができます。

外部の状態を変更するアクションから読み取り操作を分けます。カタログを読み取り、注文を提出することは同じウェブサイトを利用するかもしれませんが、それには異なる承認が必要です。ツールの説明には、モデルとオペレーターが選択を理解できるように十分に明確に入力、出力、および副作用を記載する必要があります。

返されたウェブコンテンツをデータとして扱います。アシスタントに指示を無視するように伝えたり、情報を他の場所に送信するように指示するドキュメントは、承認されたユーザーリクエストではありません。タスクの指示と分析される資料の間の境界を維持してください。リトリーバルはアプリケーションが読むことができる情報を拡大し、この境界をより重要にします。

LLM、埋め込み、検索システム

埋め込みモデルは比較に役立つ表現を生成し、生成的LLMは回答や要約のようなシーケンスを生成します。検索エンジンは候補ドキュメントを取得します。エージェントアプリケーションは、これらすべてをツールや制御ループと組み合わせることができます。名前は異なる機能を指しますが、製品がそれらをまとめている場合があります。

タスクを満たす最小のワークフローを選択します。正確な製品識別子を見つける必要がある場合、データベースクエリが十分かもしれません。同様に意味のある説明をグループ化する場合、埋め込みが役立つかもしれません。取得したポリシーを平易な言葉で説明する場合、生成モデルはソースの選択が正しい後に寄与できます。

繰り返し可能な抽出のために出力フィールドを定義し、モデルの外側でそれらを検証します。見た目上適切な回答でも、誤った通貨の価格や無関係なページセクションから取得した日付が含まれている可能性があります。明示的な欠測値ルールを使用し、各重要なフィールドの背後にある証拠を保持します。

LLMアプリケーションの評価

LLMアプリケーションは、応答の流暢さだけでなく、ユーザーが完了する必要があるタスクに対して評価されるべきです。代表的な質問と期待される証拠を集め、システムが自制すべきなケースを含めます。矛盾するドキュメント、あいまいな指示、欠如したソース情報の例を保持します。

段階を別々に評価します。収集は意図したページを返しましたか？リトリーバルは正しいセクションを選択しましたか？モデルは要求された形式に従いましたか？最終的な回答は証拠の範囲内に収まっていますか？単一の全体評価は、どのコンポーネントが失敗を引き起こしたかを隠す可能性があり、問題を修正しない高価な変更につながることがあります。

コストとレイテンシを段階ごとに追跡します。収集インフラには独自の 価格, モデル推論には別の予算があります。無関係なテキストを減らすことは、コストと回答の質の両方を改善する可能性があります。モデルを置き換えることは、比較が真の違いを反映するように、同じ保持されたタスクでテストされるべきです。

結論

LLMは言語のパターンを学習し、コンテキストを使用して有用な出力を生成しますが、アプリケーションはその証拠、許可、品質管理を提供する必要があります。まずタスクを定義し、それをサポートできるソースを定義します。次にモデルがリトリーバル、外部ツール、または単に明確なプロンプトを必要とするかを決定します。そのアプローチにより、改善を測定しやすくし、失敗を説明しやすくします。