人工智慧技術和醫療保健系統的持續融合帶來了許多引人注目的進步。讓我們來設定一下場景。如果您與 ChatGPT 等動態模型進行過交互，您可能會像我們許多人一樣，開始使用您獨特的資料集設想其應用程式。假設在醫療保健領域，您希望將此技術與電子健康記錄 (EHR) 或電子病歷 (EMR) 連結起來，或者您的目標是使用 FHIR 的資源來增強互通性。 這一切都歸結為我們如何與市場上提供的法學碩士傳輸/接收上下文資料。
更準確的技術包括微調、僅使用情境資料集訓練法學碩士。不過，今天要實現這一目標需要花費數百萬美元。另一種方法是透過一次性或幾次查詢向法學碩士提供上下文並獲得答案。實現此目的的一些方法包括：產生 SQL 查詢、產生查詢/解析程式碼、使用 API 規格中的資訊進行呼叫等。但是，存在代幣消耗高的問題，其中一些答案可能並不總是準確的。
這裡沒有一種解決方案可以解決所有問題，但了解這些技術的優缺點有助於制定自己的策略。此外，利用良好的工程實踐（如快取、輔助儲存）並專注於解決問題可以幫助在可用方法之間找到平衡。這篇文章試圖分享一些策略並在不同指標下對它們進行比較。
首先，我們有更常規的方法——透過LangChain載入並解析SQL資料庫結構和範例內容並執行GPT查詢。這種方法在促進與我們的醫療保健系統進行高效和動態通信方面有著良好的記錄，使其成為我們行業中經過考驗的技術。
有些解決方案僅傳遞資料庫結構（例如表架構），而其他解決方案則傳遞一些經過編輯的資料以幫助 LLM 產生準確的查詢。前一種解決方案具有固定令牌使用和可預測成本的優點，但由於不完全上下文感知，準確性受到影響。後者解決方案可能更加令牌密集，並且需要特別注意匿名化技術。 這些解決方案可能非常適合某些用例，但是否有更最佳化的策略？
另一種複雜的技術是讓法學碩士產生程式碼將一個問題分解為多個查詢或 API 呼叫。這是解決複雜問題的一種非常自然的方式，並釋放了自然語言和底層程式碼相結合的力量。
此解決方案需要良好的提示工程並微調模板提示，以適用於所有極端情況。由於令牌使用、安全代碼產生以及控制生成的代碼可存取和不可訪問的邊界等方面的不確定性，將此解決方案融入企業環境可能具有挑戰性。但總的來說，這種技術自主解決複雜問題的能力是令人著迷的，而該領域的進一步進展值得期待。
我們的團隊希望嘗試一種不同的方法來控制令牌的使用，同時也利用可用的上下文來獲得準確的結果。使用LangChain來載入和解析FHIR的OpenAPI規格怎麼樣？ OpenAPI 是一個有影響力的替代方案，配備了自適應和標準化程序，驗證了 FHIR 綜合 API 標準的重要性。其獨特的優點在於促進不同系統之間輕鬆的資料交換。這裡的控制在於能夠修改規格本身，而不是 LLM 的提示或產生的輸出。
想像一下場景：POST API 在將資料新增至資料庫之前執行所有必要的驗證檢查。現在，設想利用相同的 POST API，但使用自然語言方法。它仍然執行同樣嚴格的檢查，確保一致性和可靠性。 OpenAPI 的這種性質不僅簡化了與醫療保健服務和應用程式的交互，還增強了 API 的可理解性，使它們易於理解和預測。
我們知道這個解決方案並不具有與自動分解任務或產生程式碼相同的能力，但這是為了獲得一個更實用的解決方案，可以快速適應大多數用例。
Bien que toutes ces techniques démontrent des avantages uniques et le potentiel de servir différents objectifs, évaluons leurs performances par rapport à certains paramètres.
1. Fiabilité - Donnant la priorité à la fiabilité compte tenu de notre alliance avec l'IA, OpenAPI a un avantage en raison de son utilisation d'API standardisées. Cela garantit un accès non autorisé restreint et une authentification précise de l'utilisateur à des données spécifiques, offrant ainsi une sécurité améliorée des données par rapport à la transmission du code SQL généré par l'IA pour l'accès à la base de données - une méthode qui pourrait potentiellement soulever des problèmes de fiabilité.
2. Coût - L'efficacité des capacités de filtrage de l'API définies par FHIR joue un rôle dans la réduction des coûts. Cela permet de traiter uniquement les données nécessaires, rationalisées grâce à une ingénierie d'invite intense, contrairement aux bases de données traditionnelles qui peuvent renvoyer plus d'enregistrements que nécessaire, entraînant des augmentations de coûts inutiles.
3. Performance - La présentation structurée et standardisée des données par les spécifications OpenAPI contribue souvent à des résultats de sortie supérieurs à partir des modèles GPT-4, améliorant ainsi les performances. Toutefois, les bases de données SQL peuvent renvoyer des résultats plus rapidement pour les requêtes directes. Il est important de tenir compte du potentiel de surinformation de l'Open API en raison de la définition de plus de paramètres que ce qui pourrait être nécessaire pour une requête.
4. Interopérabilité - Les spécifications OpenAPI brillent en matière d'interopérabilité. Indépendants de la plate-forme, ils s'alignent parfaitement sur la mission de FHIR visant à renforcer l'interopérabilité des soins de santé, en favorisant un environnement collaboratif pour une synchronisation transparente avec d'autres systèmes.
5. Implémentation et maintenance - Bien qu'il puisse être comparativement plus facile de créer une base de données et de fournir le contexte à l'IA pour les requêtes, la méthode de chargement de base de données SQL avec sa couche de contrôle allégée peut sembler plus facile à mettre en œuvre, les spécifications OpenAPI, une fois maîtrisées, offrent des avantages tels que la standardisation et une maintenance plus facile qui dépassent la courbe d'apprentissage et d'exécution initiale.
6. Évolutivité et flexibilité - Les bases de données SQL exigent un schéma rigide qui peut ne pas permettre confortablement l'évolutivité et la flexibilité. Contrairement à SQL, OpenAPI offre une solution plus adaptative et évolutive, ce qui en fait une alternative tournée vers l'avenir.
7. Éthique et préoccupations - Un facteur important, mais complexe à prendre en compte compte tenu de la croissance rapide de l'IA. Seriez-vous à l’aise de fournir un accès direct à la base de données aux clients, même avec des filtres et une authentification ? Réfléchissez à l’importance des désidentifiants de données pour garantir la confidentialité au sein de l’espace de soins de santé. Même si les bases de données OpenAPI et SQL disposent de mécanismes pour répondre à ces problèmes, la standardisation inhérente fournie par OpenAPI ajoute une couche de sécurité supplémentaire.
Bien que cette discussion offre un aperçu de certains des facteurs clés à prendre en compte, il est essentiel de reconnaître que le choix entre SQL, la génération de code et OpenAPI est multiforme et soumis aux exigences spécifiques de vos projets et organisations.
N'hésitez pas à partager vos réflexions et vos points de vue sur ce sujet - peut-être avez-vous des points supplémentaires à suggérer ou souhaitez-vous partager quelques exemples qui ont le mieux fonctionné pour votre cas d'utilisation.
以上是使用法學碩士而不燒錢——不同的資料庫查詢策略的詳細內容。更多資訊請關注PHP中文網其他相關文章！
