お金を使わずに LLM を使用する - さまざまなデータベース クエリ戦略

AI テクノロジーと医療システムの継続的な融合により、多くの魅力的な進歩がもたらされました。場面を設定しましょう。 ChatGPT のような動的モデルを操作したことがある場合は、私たちの多くと同じように、独自のデータセットを使用してそのアプリケーションを想像し始めているかもしれません。ヘルスケア分野で、このテクノロジーを電子医療記録 (EHR) または電子医療記録 (EMR) とリンクしたいと考えている場合、あるいは FHIR のリソースを使用して相互運用性の向上を目指しているとします。  すべては、市場で入手可能な LLM との間でコンテキスト データをどのように転送/受信するかに帰着します。

より正確な手法には、コンテキスト データセットのみを使用して LLM を微調整してトレーニングすることが含まれます。ただし、今日これを達成するには数百万ドルの費用がかかります。もう 1 つの方法は、ワンショット クエリまたは少数ショット クエリを通じて LLM にコンテキストをフィードし、回答を取得することです。これを実現する方法としては、SQL クエリの生成、クエリ/解析するコードの生成、API 仕様からの情報を使用した呼び出しなどがあります。ただし、トークンの消費量が多いという問題があり、これらの答えの一部は常に正確であるとは限りません。

すべての魔法に適合する唯一の解決策はありませんが、これらの手法の長所と短所を理解することは、独自の戦略を立てるのに役立ちます。また、適切なエンジニアリング プラクティス (キャッシュ、二次ストレージなど) を活用し、問題解決に重点を置くことは、利用可能な方法間のバランスを見つけるのに役立ちます。この投稿は、いくつかの戦略を共有し、異なる指標の下でそれらを比較する試みです。

SQL クエリの生成

まず、より従来的な方法として、LangChain を通じて SQL データベース構造とサンプル コンテンツをロードして解析し、GPT クエリを実行します。この方法には、医療システムとの効率的かつ動的な通信を促進する実績があり、業界で実証済みの技術としての地位を確立しています。

データベース構造 (テーブル スキーマなど) だけを渡すソリューションと、LLM が正確なクエリを生成できるように編集されたデータを渡すソリューションがあります。前者のソリューションには、トークンの使用量が固定され、コストが予測可能であるという利点がありますが、コンテキストを完全に認識していないため、精度が低下します。後者のソリューションはトークンをより大量に使用する可能性があるため、匿名化技術に特別な注意が必要です。  これらのソリューションは一部のユースケースには最適かもしれませんが、より最適な戦略は存在するのでしょうか?

LLM を使用して API とデータベース クエリをナビゲートするコードを生成する

もう 1 つの高度な手法は、LLM に質問を複数のクエリまたは API 呼び出しに分割するコードを生成させることです。これは複雑な質問を解決するための非常に自然な方法であり、自然言語と基礎となるコードを組み合わせる力を解き放ちます。

このソリューションには、適切なプロンプト エンジニアリングと、すべての特殊なケースに適切に機能するテンプレート プロンプトの微調整が必​​要です。このソリューションをエンタープライズ コンテキストに適合させることは、トークンの使用法、安全なコード生成、生成されたコードからアクセスできるものとアクセスできないものの境界の制御が不確実であるため、困難になる可能性があります。しかし全体として、複雑な問題を解決するために自律的に動作するこの技術の力は魅力的であり、この分野のさらなる進歩が期待されています。

OpenAPI 仕様をコンテキストとして LLM にロードする

私たちのチームは、トークンの使用を制御すると同時に、利用可能なコンテキストを活用して正確な結果を得るために別のアプローチを試したいと考えていました。 FHIR の OpenAPI 仕様のロードと解析に LangChain を採用してみてはいかがでしょうか? OpenAPI は、適応性のある標準化された手順を備えた影響力のある代替手段として存在し、FHIR の包括的な API 標準の重要性を証明しています。その明確な利点は、多様なシステム間の楽なデータ交換を促進することにあります。ここでの制御は、LLM からのプロンプトや生成された出力ではなく、仕様自体を変更できることにあります。

シナリオを想像してみてください。POST API は、データがデータベースに追加される前に、必要な検証チェックをすべて実行します。次に、同じ POST API を利用するが、自然言語メソッドを使用することを想像してください。一貫性と信頼性を確保するために、引き続き同じ厳格なチェックが実行されます。 OpenAPI のこの性質により、医療サービスやアプリケーションとのやり取りが簡素化されるだけでなく、API の理解性が向上し、理解しやすく予測可能になります。

私たちは、このソリューションが自律的にタスクを分解したりコードを生成したりするほどの力を持たないことを理解していますが、これは、ほとんどのユースケースに迅速に適応できる、より実用的なソリューションに到達することを目的としています。

比較

これらの手法はすべて、独自の利点とさまざまな目的に役立つ可能性を示していますが、いくつかの指標に照らしてそのパフォーマンスを評価してみましょう。

1. 信頼性 - AIとの連携を考慮し信頼性を重視し、標準化されたAPIを利用するOpenAPIが優位性を持っています。これにより、特定のデータに対する不正アクセスの制限と正確なユーザー認証が保証され、DB アクセス用に AI 生成の SQL を渡すのと比較して、データ セキュリティが強化されます。この方法は信頼性に関する懸念を引き起こす可能性があります。

2. コスト - FHIR によって定義された API のフィルタリング機能の効率がコスト削減に貢献します。これにより、必要以上のレコードを返し、不必要なコストの高騰につながる可能性がある従来の DB とは異なり、徹底した迅速なエンジニアリングによって合理化された必要なデータのみを処理できます。

3. パフォーマンス - OpenAPI 仕様によるデータの構造化および標準化された表現は、多くの場合、GPT-4 モデルからの優れた出力結果に貢献し、パフォーマンスを向上させます。ただし、SQL DB は直接クエリに対してより迅速に結果を返すことができます。 Open API では、クエリに必要なパラメーターを超えるパラメーターが定義されているため、過剰な情報が提供される可能性があることを考慮することが重要です。

4. 相互運用性 - 相互運用性に関しては、OpenAPI 仕様が優れています。プラットフォームに依存しないため、医療における相互運用性を向上させ、他のシステムとシームレスに同期するための共同作業環境を促進するという FHIR の使命と完全に一致しています。

5. 実装とメンテナンス - DB をスピンオフして AI にクエリ用のコンテキストを提供する方が比較的簡単かもしれませんが、リーンな制御層を備えた SQL データベースのロード方法は実装が簡単に見えるかもしれませんが、OpenAPI 仕様ではをマスターすると、標準化やメンテナンスの容易化など、最初の学習と実行曲線を上回るメリットが得られます。

6. スケーラビリティと柔軟性 - SQL データベースは、スケーラビリティと柔軟性を快適に実現できない可能性がある厳格なスキーマを要求します。 SQL とは異なり、OpenAPI はより適応性が高くスケーラブルなソリューションを提供し、将来を見据えた代替手段となります。

7. 倫理と懸念事項 - AI の急速な成長を考慮すると、考慮すべき重要かつ複雑な要素です。フィルターや認証を使用したとしても、顧客に直接 DB アクセスを提供することに抵抗はありませんか?医療分野におけるプライバシーを確​​保する上でのデータ匿名化の重要性について考えてみましょう。 OpenAPI と SQL データベースの両方には、これらの問題に対処するメカニズムがありますが、OpenAPI によって提供される固有の標準化により、追加のセキュリティ層が追加されます。

この説明では、考慮すべき重要な要素のいくつかについて洞察が得られますが、SQL、コード生成、OpenAPI のいずれを選択するかは多面的であり、プロジェクトや組織の特定の要件に左右されることを認識することが重要です。

このトピックに関するご意見や展望をお気軽に共有してください。おそらく追加で提案したい点があるか、あなたのユースケースに最適な例をいくつか共有したいと思われます。

以上がお金を使わずに LLM を使用する - さまざまなデータベース クエリ戦略の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。