使用法學碩士而不燒錢——不同的資料庫查詢策略

人工智慧技術和醫療保健系統的持續融合帶來了許多引人注目的進步。讓我們來設定一下場景。如果您與 ChatGPT 等動態模型進行過交互，您可能會像我們許多人一樣，開始使用您獨特的資料集設想其應用程式。假設在醫療保健領域，您希望將此技術與電子健康記錄 (EHR) 或電子病歷 (EMR) 連結起來，或者您的目標是使用 FHIR 的資源來增強互通性。  這一切都歸結為我們如何與市場上可用的法學碩士傳輸/接收上下文資料。

更精確的技術包括微調、僅使用情境資料集訓練法學碩士。不過，今天要實現這一目標需要花費數百萬美元。另一種方法是透過一次性或幾次查詢向法學碩士提供上下文並獲得答案。實現此目的的一些方法包括：產生 SQL 查詢、產生查詢/解析程式碼、使用 API 規格中的資訊進行呼叫等。但是，存在代幣消耗高的問題，其中一些答案可能並不總是準確的。

這裡沒有一種解決方案適合所有魔法，但了解這些技術的優缺點有助於制定自己的策略。此外，利用良好的工程實踐（如快取、輔助儲存）並專注於解決問題可以幫助在可用方法之間找到平衡。這篇文章試圖分享一些策略並在不同指標下對它們進行比較。

產生 SQL 查詢

首先，我們有更常規的方法－透過LangChain載入並解析SQL資料庫結構和範例內容並執行GPT查詢。這種方法在促進與我們的醫療保健系統進行高效、動態的溝通方面有著良好的記錄，使其成為我們行業中經過驗證的技術。

有些解決方案僅傳遞資料庫結構（例如表架構），而其他解決方案則傳遞一些經過編輯的資料以幫助 LLM 產生準確的查詢。前一種解決方案具有固定令牌使用和可預測成本的優點，但由於不完全上下文感知，準確性受到影響。後者解決方案可能更加密集，並且需要特別注意匿名化技術。  這些解決方案可能非常適合某些用例，但是否有更最佳化的策略？

使用 LLM 產生程式碼來導覽 API 和資料庫查詢

另一種複雜的技術是讓法學碩士產生程式碼將問題分解為多個查詢或 API 呼叫。這是解決複雜問題的一種非常自然的方式，並釋放了自然語言和底層程式碼相結合的力量。

此解決方案需要良好的提示工程並微調模板提示，以便適用於所有極端情況。由於令牌使用、安全代碼產生以及控制生成的代碼可存取和不可訪問的邊界等方面的不確定性，將此解決方案融入企業環境可能具有挑戰性。但總的來說，這種技術自主解決複雜問題的能力是令人著迷的，而該領域的進一步進展值得期待。

載入 OpenAPI 規範作為 LLM 的上下文

我們的團隊希望嘗試一種不同的方法來控制令牌的使用，同時也利用可用的上下文來獲得準確的結果。使用LangChain來載入和解析FHIR的OpenAPI規格怎麼樣？ OpenAPI 是一個有影響力的替代方案，配備自適應和標準化程序，驗證了 FHIR 綜合 API 標準的重要性。其獨特的優點在於促進不同系統之間輕鬆的資料交換。這裡的控制在於能夠修改規格本身，而不是 LLM 的提示或產生的輸出。

想像一下場景：POST API 在將資料新增至資料庫之前執行所有必要的驗證檢查。現在，設想利用相同的 POST API，但使用自然語言方法。它仍然執行同樣嚴格的檢查，確保一致性和可靠性。 OpenAPI 的這種性質不僅簡化了與醫療保健服務和應用程式的交互，還增強了 API 的可理解性，使它們易於理解和預測。

我們知道該解決方案不具備與自動分解任務或產生程式碼相同的能力，但這是為了找到一個更實用的解決方案，可以快速適應大多數用例。

比較

雖然所有這些技術都展示了獨特的優勢和服務於不同目的的潛力，但讓我們根據一些指標來評估它們的性能。

1. 可靠性 - 考慮到我們與 AI 的聯盟，優先考慮可靠性，OpenAPI 由於使用標準化 API 而具有優勢。這可確保限制未經授權的存取和對特定資料的精確使用者身份驗證，與透過 AI 產生的 SQL 進行資料庫存取相比，提供增強的資料安全性 - 這種方法可能會引起可靠性問題。

2. 成本 - FHIR 定義的 API 過濾功能的效率在降低成本方面發揮作用。這僅允許透過密集的即時工程簡化的必要資料進行交易，這與傳統資料庫不同，傳統資料庫可能會傳回超出所需的記錄，從而導致不必要的成本激增。

3. 效能 - OpenAPI 規範對資料的結構化和標準化表示通常有助於 GPT-4 模型的卓越輸出結果，從而提高效能。但是，對於直接查詢，SQL DB 可以更快地傳回結果。由於定義的參數多於查詢所需的參數，因此必須考慮到開放 API 可能會過度告知。

4. 互通性 - OpenAPI 規範在互通性方面表現優異。它們獨立於平台，與 FHIR 的使命完美契合，即提高醫療保健領域的互通性，創造與其他系統無縫同步的協作環境。

5. 實作與維護 - 雖然分離資料庫並為AI 提供查詢上下文可能相對更容易，使得SQL 資料庫載入方法及其精實控制層看起來更容易實現，但OpenAPI 規範一旦掌握，其帶來的好處包括標準化和更容易維護，這些好處超過了最初的學習和執行曲線。

6. 可擴充性和靈活性 - SQL 資料庫需要嚴格的模式，可能無法輕鬆實現可擴展性和靈活性。與 SQL 不同，OpenAPI 提供了更具適應性和可擴展性的解決方案，使其成為面向未來的替代方案。

7. 道德與擔憂 - 鑑於人工智慧的快速發展，這是一個需要考慮的重要但複雜的因素。即使使用過濾器和身份驗證，您是否願意向客戶提供直接資料庫存取權？反思資料去識別器在確保醫療保健領域隱私的重要性。儘管 OpenAPI 和 SQL 資料庫都有解決這些問題的機制，但 OpenAPI 提供的固有標準化增加了額外的安全層。

雖然本討論提供了一些需要考慮的關鍵因素的見解，但必須認識到 SQL、程式碼產生和 OpenAPI 之間的選擇是多方面的，並且取決於您的專案和組織的具體要求。

請隨意分享您對此主題的想法和觀點 - 也許您還有其他要點要建議，或者您想分享一些最適合您的用例的範例。

以上是使用法學碩士而不燒錢——不同的資料庫查詢策略的詳細內容。更多資訊請關注PHP中文網其他相關文章！