利益:
- API キーをクライアントに保持せず、バックエンド プロキシを経由する安全なクラウド LLM アーキテクチャを確立する機能
- ストリーミングの体感速度を向上させ、タイムアウト、ネットワークエラー、速度制限などの状況を優しく処理する堅牢な統合を作成する機能
- 送信されるトークンを短縮することでコストを削減し、クラウドに送信される前の個人データの必要性を検討する機能
オンデバイス AI は強力ですが限界があります。真の「スマート チャット アシスタント」、長いテキストの要約、または複雑なクリエイティブな制作をアプリに追加したい場合は、携帯電話に収まらないほど大きすぎるモデルが必要です。ここでクラウド AI が活躍します。アプリケーションは、API (アプリケーション プログラミング インターフェイス - 2 つのソフトウェアが相互にデータを送受信する標準インターフェイス) を介して大規模言語モデル (LLM) に接続します。この単元では、安全、高速、コストを意識した方法でクラウド LLM をモバイル アプリケーションに統合する方法を学びます。重要なのはセキュリティです。LLM 統合が正しくインストールされていないと、API キーが漏洩し、数千ポンド相当の請求が発生する可能性があります。
アーキテクチャの黄金律: キーをクライアント上に保持する
クラウド AI 統合で犯し得る最も危険な間違いは、API キー (サービスの使用を許可する秘密のパスワード) をモバイル アプリケーション コードに直接埋め込むことです。モバイル アプリケーションはユーザーのデバイスにダウンロードされ、リバース エンジニアリングによってコードを読み取ることができます。つまり、コンパイルされたアプリケーションを解析してその中身を確認します。あなたのキーがアプリ内にある場合、誰かがそれを抽出し、あなたのアカウントから無制限にリクエストを行うことができます。
正しいアーキテクチャは次のとおりです。モバイル アプリケーションはリクエストを独自のバックエンド サーバー (制御するプロキシ サーバー) に送信します。キーはサーバー上にのみ存在します。サーバーは LLM サービスにアクセスし、アプリケーションに応答を返します。このミドルウェアは、速度制限、悪用防止、コスト管理も提供します。
アプローチ
鍵はどこにありますか
セキュリティ
キーはアプリケーション内にあります (FALSE)
クライアント、パブリックで
漏れる、紙幣が爆発する
キーはバックエンドにあります (TRUE)
サーバー上で非表示に
安全、制御可能
注意: AI にクラウド LLM 統合を要求すると、利便性のためにキーをアプリケーション コードに直接書き込む例が生成される場合があります。決してこれをライブで受け取らないでください。プロンプトには必ず「API キーはクライアント上に存在しないでください。バックエンド プロキシを経由してください」という文を含めてください。
ストリーミング: 体感速度の向上
LLM の回答は長くなる場合があり、すべてを作成するのに数秒かかる場合があります。ユーザーを空白の画面で待たせるのは、悪い経験です。このソリューションはストリーミングであり、生成された回答を単語ごとに表示します。ユーザーは、ChatGPT と同様に、テキストのスペルを監視します。これにより、体感速度と流暢さが劇的に向上します。モバイルでのフローとは、到着時にサーバーからインターフェイスに部分 (トークン、つまりモデルによって生成されたテキストの部分) を追加することを意味します。 AI への統合を印刷するときにフローを明示的に要求します。
ヒント: ストリーミング応答に「一時停止」ボタンを追加します。ユーザーは、必要な答えが得られたときに生産を停止できる必要があります。これにより、エクスペリエンスが向上し、不必要なトークンの生成が削減されることでコストが削減されます。長い答えの途中で、ユーザーはすでに答えを見つけている可能性があります。
コスト、遅延、エラーの管理
Cloud LLM は、リクエストごとに金銭的コスト (トークンごとの料金) と時間的コスト (レイテンシー) を伴います。 3つの分野が不可欠です。 Cost: limit prompt and response length, do not send unnecessarily long system instructions, default to small and cheap model if possible.遅延: ストリーミングを使用し、タイムアウトを設定し、ネットワークが遅い場合はユーザーに通知します。エラー: ネットワーク障害。サービスは 429 (リクエストが多すぎる) または 500 (サーバー エラー) を返す可能性があります。それぞれを丁寧に扱い、アプリをクラッシュさせないでください。また、LLM は意味のない、または不正確な (幻覚) 答えを与えることがあります。重要な領域に答えを検証するレイヤーを追加します。
ミニケース3個
ケース 1 — キーの漏洩。あるスタートアップは、迅速に動作を開始するために、OpenAI キーを React Native アプリに直接埋め込みました。アプリがリリースされてから 3 週間後、キーはリバース エンジニアリングされ、一晩で 2,400 ドル相当の使用が行われました。チームはキーを無効にし、バックエンド プロキシを設定する必要がありました。教訓: 利便性のために取った近道が、最も高価なルートになった。
ケース 2 — フローとともにドロップアウトが減少しました。ある教育アプリが初めて Q&A 機能をストリーミングなしでリリースしました。ユーザーは 6 秒間のアイドル待機後に終了していました。フローを追加すると、最初の単語は 0.8 秒で現れ始め、放棄率は 48% から 12% に低下しました。同じモデル、同じ速度 - プレゼンテーションが異なるだけです。
ケース 3 — コスト管理。 1 つのアプリは、すべてのユーザー メッセージとともにチャット履歴全体をモデルに送信していました。長い会話では、1 つのリクエストが 8,000 トークンに達し、コストが膨らみました。最後の数メッセージと概要だけを送信することで、チームはリクエストあたりのトークンを 70% 削減し、月々の請求額を 3 分の 1 に削減しました。教訓: 何を送信するかを測定する。
弱いプロンプト / 強いプロンプト
弱いプロンプト: 「ChatGPT のようなチャットをアプリに追加します。」
強力なプロンプト: 「iOS/Swift アプリケーションにチャット アシスタントを追加します。アーキテクチャ: アプリケーションは自分のバックエンドにリクエストを送信します。LLM API キーはクライアント上になく、プロキシを経由します。 - 応答はストリーミングで届き、単語ごとに表示されます - 「停止」ボタンにより生産が中断されます - タイムアウト、ネットワーク エラー、429 および 500 の状況を適切に処理します - チャット履歴を短縮します: 最新の 6 メッセージ + 概要 (コスト管理) を送信します。最初にアーキテクチャ図を作成し、次にクライアントとプロキシのコードを別々に指定します。」
コピー可能なテンプレート
安全なアーキテクチャ テンプレート:「[プラットフォーム] アプリケーションへのクラウド LLM の統合を設計します。ルール: API キーはバックエンドのみ。クライアント -> プロキシ -> LLM。プロキシ内: 認証、ユーザーごとのレート制限、ログの要求。クライアントとプロキシの責任を個別にリストし、コードをエクスポートします。」
ストリーミング テンプレート: 「このチャット画面にストリーミング応答を追加します。- 到着時にメッセージ バブルにスニペットを追加します。- 入力中にカーソル/アニメーションを表示します。- 「停止」ボタンでストリームをキャンセルします。- 部分的なテキストを保持し、ストリームの終了中にエラーが発生した場合は警告します[既存のコード]」
コストとレイテンシのテンプレート:「この LLM 統合でコストとレイテンシを削減します:- 送信されるトークン (履歴の省略形、概要) を減らすにはどうすればよいですか?- この場合、より小型/安価なモデルで十分ですか?- タイムアウトと再試行戦略を提案します[コード]」
フォールト トレランス テンプレート: 「この LLM 呼び出しを回復力のあるものにする:- ネットワークなし、タイムアウト、429 (レート制限)、500 (サーバー) に対する個別の動作- ユーザーへの非技術的で丁寧なメッセージ- 重要な返信における幻覚のリスクに対する検証メモ[コード]」
よくある間違い
- API キーをアプリケーションに埋め込みます。最も高価で一般的なセキュリティ バグ。鍵は間違いなくバックエンドにあります。
- フローを使用していない。ユーザーを長い答えを待たせたままにしておくと、ユーザーは遠ざかってしまいます。
- すべてのリクエストでチャット履歴全体を送信します。トークンのコストと待ち時間が倍増します。
- エラー状態をバイパスします。 429/500/timeout に対処しないと、アプリケーションがクラッシュまたはフリーズします。
- LLM の答えは疑いもなく正しいと考えられます。幻覚は本物です。クリティカルエリアに検証レイヤーを追加します。
- 不要な LLM にユーザー データを送信します。個人データが必要かどうか、またはクラウドに送信する前にマスクする必要があるかどうかを尋ねます。
要約すれば
Cloud LLM は、デバイスには適合しない優れた機能をモバイルにもたらしますが、セキュリティとコストの規律が必要です。黄金律: API キーはクライアント上に存在することはなく、バックエンド プロキシを経由します。フローにより、体感速度と保持力が大幅に向上します。 「停止」ボタンでサポートされます。コストは、送信されるトークンを短縮することによって決定されます。回復力は、すべてのエラーケースを適切に処理することによって実現されます。 LLM の回答には幻覚が含まれる場合があります。重要な領域では検証が不可欠であり、個人データはクラウドに送信される前にレビューされます。
アプリケーションタスク
「テキスト要約」または「チャット」機能の「セキュア アーキテクチャ テンプレート」を使用して、AI にクライアント + バックエンド プロキシの設計をリクエストします。 API キーが生成されたデザインのバックエンドにのみ存在することを確認します。次に、「コスト遅延パターン」で送信されるトークンを削減する少なくとも 2 つの方法を抽出し、エラー状態 (例: 429) でユーザーに表示される丁寧なメッセージを作成します。
チェックリスト
- [ ] API キーがクライアントではなくバックエンドに存在することを確認しました
- [ ] 応答をストリーミング化し、「一時停止」ボタンを追加しました
- [ ] タイムアウト、ネットワークエラー、429 および 500 の状況を処理しました
- [ ] 送信されたトークンを過去の略語/概要で縮小しました
- [ ] LLM の回答で幻覚のリスクに対する検証を検討しました
- [ ] クラウドを利用する前に個人データの必要性/マスキングを確認しました