LLM（Language Model）をアプリケーションに統合する際の複雑さと課題

LLMのアプリケーション統合の複雑さと課題

コードにLLMサービスを統合する予定ですか？その際に予想される一般的な課題をいくつかご紹介します

大規模言語モデル（LLM）は、OpenAIのChatGPTやGPT APIのリリースより前から存在していました。しかし、OpenAIの努力により、GPTは開発者や非開発者にとって簡単にアクセスできるようになりました。このリリースは、AIの最近の復興において間違いなく重要な役割を果たしています。

OpenAIのGPT APIがリリースされてからわずか6か月で、その採用は非常に速いペースで進んでいます。ほとんどのSaaSサービスは、ユーザーの生産性を向上させるために何らかの形でそれを組み込んでいます。

しかし、これらのAPIの設計と統合作業を完了した人々だけが、それに起因する複雑さと新たな課題を本当に理解しています。

過去数ヶ月間、私はOpenAIのGPT APIを利用するいくつかの機能を実装してきました。このプロセスを通じて、GPT APIや他のLLM APIを利用する人々に共通するいくつかの課題に直面しました。それらをここでリストアップすることで、エンジニアリングチームが適切に準備をし、LLMベースの機能を設計できるように役立てたいと思います。

• 「注目すべき8つのトレンディングで新しい大規模言語モデル」
• 「TransformersとTokenizersを使用して、ゼロから新しい言語モデルを訓練する方法」
• 「Microsoft Azureの新しいディープラーニングと自然言語処理のチュートリアルを発表します」

いくつかの典型的な障害を見てみましょう。

コンテキストメモリとコンテキストの制約

これはおそらく最も一般的な課題です。LLMの入力のためのコンテキストは制限されています。最近、OpenAIは16Kトークンに対するコンテキストのサポートをリリースしましたし、GPT-4ではコンテキストの制限が32Kに達することができます。これは数ページに相当します（例えば、数ページ分の大きなドキュメント上でLLMを動作させたい場合など）。しかし、多くの場合、特にLLMを使用して複数のページを持つ多数のドキュメントを処理する必要がある場合（例えば、法務テクノロジー企業がLLMを使用して回答を抽出するために多数の法的文書を処理する場合など）、それ以上のコンテキストが必要です。

この課題を克服するためのさまざまな技術があり、新たな技術も現れつつありますが、それは自身で1つ以上の技術を実装する必要があるということを意味します。実装、テスト、メンテナンスのためのさらなる作業が必要になります。

データの充実

LLMベースの機能では、おそらくプロプライエタリデータを入力として使用します。ユーザーデータをコンテキストの一部として入力するか、他の収集したデータや保存しているドキュメントを使用するかに関係なく、所有するさまざまなデータソースからデータを取得する呼び出しを抽象化するシンプルな仕組みが必要です。

テンプレート

LLMに送信するプロンプトには、ハードコードされたテキストや他のデータソースからのデータが含まれます。つまり、静的なテンプレートを作成し、ランタイムでデータを動的に埋め込むことになります。言い換えれば、プロンプト用のテンプレートを作成し、複数のテンプレートを持つ可能性があります。

そのため、文字列の連結のようにコードが見えることは避けたいでしょうから、何らかのテンプレートフレームワークを使用する必要があります。

これは大きな課題ではありませんが、考慮すべき別のタスクです。

テストと微調整

LLMを満足のいく精度まで高めるには、多くのテスト（場合によっては大量のトライアルアンドエラーを伴うプロンプトエンジニアリング）とユーザーフィードバックに基づく微調整が必要です。

もちろん、すべての統合が正しく機能することを確認するためにCIの一部として実行されるテストもありますが、それが真の課題ではありません。

ここで言うテストとは、sandboxでプロンプトを繰り返し実行して精度を微調整することを指しています。

テストでは、テストエンジニアがテンプレートを変更し、必要なデータでそれらを充実させ、LLMと一緒にプロンプトを実行して望む結果を得ることができる方法が必要です。そのようなテストフレームワークをどのように設定しますか？

さらに、LLMの出力に関するユーザーからのフィードバックを得ることで、LLMモデルを常に微調整する必要があります。そのようなプロセスをどのように設定しますか？

キャッシュ

LLMモデル（例：OpenAIのGPT）には、回答のランダム性を制御するパラメータがあり、AIがより創造的になることができます。ただし、大規模なリクエストを処理している場合、API呼び出しに高額な料金が発生し、レート制限に達する可能性があり、アプリのパフォーマンスが低下する可能性があります。LLMへの入力の一部が異なる呼び出しで繰り返される場合、回答をキャッシュすることを検討することができます。たとえば、LLMベースの機能に対して10万回の呼び出しを処理する場合、それらのすべての呼び出しがLLMプロバイダーにAPI呼び出しをトリガーする場合、コストは非常に高くなります。ただし、入力が繰り返される場合（これはテンプレートを使用して特定のユーザーフィールドでフィードする場合に起こる可能性があります）、事前処理済みのLLM出力の一部をキャッシュして提供できる可能性が高いです。

この課題は、そのためのキャッシュメカニズムを構築することです。実装は難しくありませんが、別のレイヤーと移動部品を追加する必要があり、適切にメンテナンスする必要があります。

セキュリティとコンプライアンス

セキュリティとプライバシーは、このプロセスの中で最も難しい側面かもしれません。作成したプロセスがデータ漏洩を引き起こさないようにするにはどうすればよいですか？また、どのようにしてPII（個人情報識別子）が漏洩しないようにするかを確認する必要があります。

さらに、すべてのアクションを監査する必要があります。これにより、データ漏洩やプライバシーポリシーの侵害がなかったかを検証することができます。

これは、サードパーティのサービスに依存するソフトウェア会社にとって共通の課題であり、ここでも取り組む必要があります。

観測性

使用している外部APIと同様に、そのパフォーマンスを監視する必要があります。エラーはありますか？処理にはどれくらいの時間がかかりますか？APIのレート制限や閾値を超えているか、または超えようとしていますか？

さらに、セキュリティ監査の目的だけでなく、出力を評価することによってLLMのワークフローやプロンプトを微調整するのに役立つため、すべての呼び出しをログに記録する必要があります。

ワークフロー管理

裁判所の生産性を向上させるために弁護士が使用する法的技術ソフトウェアを開発するとしましょう。この例では、CRMシステムからクライアントの詳細と取り組んでいるケースの一般的な説明を取得し、法的先例に基づいて弁護士のクエリに応じた回答を提供するLLMベースの機能があります。

それを実現するためには、以下の作業が必要です：

1. 指定されたクライアントIDに基づいてクライアントの詳細を検索します。
2. 取り組んでいる現在のケースの詳細をすべて検索します。
3. LLMを使用して弁護士のクエリに応じて現在のケースから関連情報を抽出します。
4. 上記の情報を事前定義された質問テンプレートに組み合わせます。
5. 多数の法的ケースでコンテキストを豊かにします。（コンテキストメモリの課題を思い出してください）
6. LLMが現在のケース、クライアント、弁護士のクエリに最も適合する法的先例を見つけます。

さあ、もしもこのようなワークフローを持つ2つ以上の機能がある場合、そして最終的には将来的なワークフローも予想してみてください。これらのワークフローを実装した後のコードがどのようになるかを想像してみてください。きっと、ここで行うべき作業について考えるだけで、座っているのが不快に感じるはずです。

コードが保守可能で読みやすいようにするためには、さまざまな抽象化のレイヤーを実装し、将来的にさらなるワークフローが予想される場合は、ワークフロー管理フレームワークを採用または実装することを検討する必要があります。

最後に、この例から次の課題につながります：

強いコードの結合

上記の課題と生じる複雑さに気付いたのであれば、いくつかのタスクは開発者の責任ではないということに気付くかもしれません。

具体的には、ワークフローの構築、テスト、微調整、アウトカムの監視、外部APIの使用に関連するすべてのタスクは、ソフトウェアの構築を専門とする人々がより専念して行うことができます。ここでは、この役割をLLMエンジニアと呼びましょう。

LLMワークフロー、テスト、微調整などは、ソフトウェアの構築者の責任に置かれるべき理由はありません。ソフトウェア開発者はソフトウェアの構築に長けています。同時に、LLMエンジニアはソフトウェアの構築ではなく、LLMワークフローの構築と微調整に長けているべきです。

ただし、現在のフレームワークでは、LLMワークフロー管理はコードベースに結合されています。これらのワークフローを構築する人々は、ソフトウェア開発者とLLMエンジニアの専門知識が必要です。

デカップリングを行う方法はいくつかあります。たとえば、すべてのワークフローを処理する専用のマイクロサービスを作成するという方法がありますが、これもまた対処する必要がある別の課題です。

これらはただいくつかの課題の一部でした。

これらの問題をすべて解決する方法については触れませんでした。なぜなら、まだ自分自身でそれを解明しようとしているからです。ただし、LangChainはこれらの問題にいくらか近づいている唯一のフレームワークのようであり、すべてを解決するには程遠いですが、正しい方向に向かっているようです。時間が経つにつれて、私はLLMプロバイダーが提供するサービスが改善され、これらの課題にある程度対応できるプラットフォームが提供されると信じています。

共有していただける追加の課題がありましたら、他の読者のためにコメントにご投稿ください。また、これらの課題に役立つツールをご存知でしたら、コメントで共有してください。

この記事が役に立ったと思われた場合は、拍手を追加していただき、私をフォローしてチームビルディング、ソフトウェアエンジニアリング、技術に関する記事をもっと読んでください。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!