Menggunakan LLM tanpa Membakar Dolar - Strategi Pertanyaan Pangkalan Data Berbeza

Penumpuan berterusan teknologi AI dan sistem penjagaan kesihatan telah membawa ke hadapan banyak kemajuan yang menarik. Mari kita atur tempat kejadian. Jika anda telah berinteraksi dengan model dinamik seperti ChatGPT, anda mungkin, seperti kebanyakan kami, mula membayangkan aplikasinya menggunakan set data unik anda. Katakan dalam sektor penjagaan kesihatan anda ingin memautkan teknologi ini dengan Rekod Kesihatan Elektronik (EHR) atau Rekod Perubatan Elektronik (EMR), atau mungkin anda menyasarkan untuk meningkatkan kesalingoperasian menggunakan sumber FHIR.  Semuanya bermula kepada cara kami memindahkan/menerima data kontekstual ke/daripada LLM yang tersedia di pasaran.

Teknik yang lebih tepat termasuk penalaan halus, melatih LLM secara eksklusif dengan set data konteks. Kecuali, kos berjuta-juta dolar untuk mencapainya hari ini. Cara lain ialah memberi konteks kepada LLM melalui pertanyaan satu pukulan atau beberapa pukulan dan mendapatkan jawapan. Beberapa cara yang boleh dicapai ialah - menjana pertanyaan SQL, menjana kod untuk pertanyaan/menghuraikan, membuat panggilan dengan maklumat daripada spesifikasi API dan sebagainya. Tetapi, terdapat masalah penggunaan token yang tinggi dan beberapa jawapan ini mungkin tidak selalu tepat.

Tiada satu penyelesaian yang sesuai dengan semua keajaiban di sini, tetapi memahami kebaikan dan keburukan teknik ini boleh membantu dalam merangka strategi anda sendiri. Selain itu, memanfaatkan amalan kejuruteraan yang baik (seperti cache, storan sekunder) dan memfokuskan pada penyelesaian masalah boleh membantu mencari keseimbangan antara kaedah yang tersedia. Siaran ini adalah percubaan untuk berkongsi beberapa strategi dan membuat perbandingan antara strategi tersebut di bawah metrik yang berbeza.

Menjana pertanyaan SQL

Pertama, kami mempunyai kaedah yang lebih konvensional - memuatkan dan menghuraikan struktur pangkalan data SQL dan kandungan sampel melalui LangChain dan melaksanakan pertanyaan GPT. Kaedah ini mempunyai rekod prestasi untuk memudahkan komunikasi yang cekap dan dinamik dengan sistem penjagaan kesihatan kami, menandakan dirinya sebagai teknik yang telah dicuba dan benar dalam industri kami.

Terdapat penyelesaian yang hanya melepasi struktur pangkalan data (skema jadual contohnya) dan lain-lain yang menghantar beberapa data yang disunting untuk membantu LLM menjana pertanyaan yang tepat. Penyelesaian terdahulu mempunyai kelebihan penggunaan token tetap dan kos yang boleh diramal tetapi mengambil kesan pada ketepatan kerana tidak mengetahui konteks sepenuhnya. Penyelesaian yang terakhir mungkin lebih intensif tanda dan memerlukan penjagaan khas dengan teknik anonimasi.  Penyelesaian ini mungkin sesuai untuk sesetengah kes penggunaan, tetapi bolehkah wujud strategi yang lebih optimum?

Menggunakan LLM untuk Menjana kod untuk menavigasi API dan pertanyaan Pangkalan Data

Satu lagi teknik canggih ialah membenarkan LLM menjana kod untuk memecahkan soalan kepada berbilang pertanyaan atau panggilan API. Ini adalah cara yang sangat semula jadi untuk menyelesaikan soalan rumit dan melepaskan kuasa menggabungkan bahasa semula jadi dan kod asas.

Penyelesaian ini memerlukan kejuruteraan segera yang baik dan memperhalusi gesaan templat untuk berfungsi dengan baik untuk semua kes sudut. Memasang penyelesaian ini ke dalam konteks perusahaan boleh mencabar dengan ketidakpastian dalam penggunaan token, penjanaan kod selamat dan mengawal sempadan perkara yang boleh dan tidak boleh diakses oleh kod yang dijana. Tetapi secara keseluruhannya kuasa teknik ini untuk bertindak secara autonomi untuk menyelesaikan masalah yang rumit adalah menarik dan kemajuan selanjutnya dalam bidang ini adalah sesuatu yang dinanti-nantikan.

Memuatkan spesifikasi OpenAPI sebagai konteks kepada LLM

Pasukan kami ingin mencuba pendekatan berbeza untuk mengawal penggunaan token tetapi juga memanfaatkan konteks yang tersedia untuk mendapatkan hasil yang tepat. Bagaimana pula dengan menggunakan LangChain untuk memuatkan dan menghuraikan spesifikasi OpenAPI FHIR? OpenAPI menampilkan dirinya sebagai alternatif yang berkesan, dilengkapi dengan prosedur penyesuaian dan piawai, mengesahkan kepentingan piawaian API komprehensif FHIR. Kelebihannya yang tersendiri terletak pada menggalakkan pertukaran data yang mudah antara sistem yang pelbagai. Kawalan di sini terletak pada keupayaan untuk mengubah suai spesifikasi itu sendiri dan bukannya gesaan atau output yang dihasilkan daripada LLM.

Bayangkan senarionya: POST API melakukan semua semakan pengesahan yang diperlukan sebelum data ditambahkan pada pangkalan data. Sekarang, bayangkan memanfaatkan API POST yang sama, tetapi menggunakan kaedah bahasa semula jadi. Ia masih menjalankan pemeriksaan ketat yang sama, memastikan konsistensi dan kebolehpercayaan. Sifat OpenAPI ini bukan sahaja memudahkan interaksi dengan perkhidmatan dan aplikasi penjagaan kesihatan, tetapi juga meningkatkan kefahaman API, menjadikannya mudah difahami dan boleh diramal.

Kami memahami penyelesaian ini tidak mempunyai kuasa yang sama seperti memecahkan tugas atau menjana kod secara autonomi, tetapi ini adalah matlamat untuk mencapai penyelesaian yang lebih praktikal yang boleh disesuaikan untuk kebanyakan kes penggunaan dengan cepat.

Perbandingan

Walaupun semua teknik ini menunjukkan faedah unik dan potensi untuk mencapai tujuan yang berbeza, marilah kita menilai prestasinya berdasarkan beberapa metrik.

1. Kebolehpercayaan - Mengutamakan kebolehpercayaan memandangkan pakatan kami dengan AI, OpenAPI mempunyai kelebihan kerana penggunaan API terpiawainya. Ini memastikan akses tanpa kebenaran yang terhad dan pengesahan pengguna yang tepat kepada data tertentu, memberikan keselamatan data yang dipertingkatkan berbanding dengan menghantar SQL yang dijana AI untuk akses DB - kaedah yang berpotensi menimbulkan kebimbangan kebolehpercayaan.

2. Kos - Kecekapan keupayaan penapisan API yang ditakrifkan oleh FHIR memainkan peranan dalam pengurangan kos. Ini membenarkan hanya data yang diperlukan, diperkemas melalui kejuruteraan segera yang sengit, untuk diurus niaga, tidak seperti DB tradisional yang mungkin mengembalikan lebih banyak rekod daripada yang diperlukan, yang membawa kepada lonjakan kos yang tidak perlu.

3. Prestasi - Persembahan data yang berstruktur dan piawai oleh spesifikasi OpenAPI sering menyumbang kepada hasil keluaran unggul daripada model GPT-4, meningkatkan prestasi. Walau bagaimanapun, SQL DB boleh mengembalikan hasil dengan lebih pantas untuk pertanyaan langsung. Adalah penting untuk mengambil kira potensi Open API untuk maklumat yang berlebihan disebabkan oleh takrifan lebih banyak parameter daripada yang mungkin diperlukan untuk pertanyaan.

4. Saling kendali - Spesifikasi OpenAPI menyerlah apabila melibatkan kebolehoperasian. Sebagai bebas platform, mereka selaras dengan sempurna dengan misi FHIR untuk meningkatkan kesalingoperasian dalam penjagaan kesihatan, memupuk persekitaran kolaboratif untuk penyegerakan yang lancar dengan sistem lain.

5. Pelaksanaan & Penyelenggaraan - Walaupun agak mudah untuk spin off DB dan menyediakan konteks kepada AI untuk pertanyaan menjadikan kaedah pemuatan pangkalan data SQL dengan lapisan kawalan lean mungkin kelihatan lebih mudah untuk dilaksanakan, spesifikasi OpenAPI , setelah dikuasai, menawarkan faedah seperti penyeragaman dan penyelenggaraan yang lebih mudah yang mengatasi keluk pembelajaran dan pelaksanaan awal.

6. Skalabiliti dan Fleksibiliti - Pangkalan data SQL menuntut skema tegar yang mungkin tidak membenarkan skalabiliti dan fleksibiliti dengan selesa. Tidak seperti SQL, OpenAPI menawarkan penyelesaian yang lebih adaptif dan berskala, menjadikannya alternatif yang mesra masa hadapan.

7. Etika dan Keprihatinan - Faktor penting, namun kompleks untuk dipertimbangkan memandangkan pertumbuhan pesat AI. Adakah anda selesa memberikan akses DB terus kepada pelanggan, walaupun dengan penapis dan pengesahan? Fikirkan tentang kepentingan penyahidentifikasi data dalam memastikan privasi dalam ruang penjagaan kesihatan. Walaupun kedua-dua pangkalan data OpenAPI dan SQL mempunyai mekanisme untuk menangani kebimbangan ini, penyeragaman sedia ada yang disediakan oleh OpenAPI menambah lapisan keselamatan tambahan.

Walaupun perbincangan ini menawarkan cerapan tentang beberapa faktor utama untuk dipertimbangkan, adalah penting untuk menyedari bahawa pilihan antara SQL, penjanaan kod dan OpenAPI adalah pelbagai rupa dan tertakluk pada keperluan khusus projek dan organisasi anda.

Sila bebas untuk berkongsi pendapat dan perspektif anda tentang topik ini - mungkin anda mempunyai mata tambahan untuk dicadangkan atau anda ingin berkongsi beberapa contoh yang paling berkesan untuk kes penggunaan anda.

Atas ialah kandungan terperinci Menggunakan LLM tanpa Membakar Dolar - Strategi Pertanyaan Pangkalan Data Berbeza. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!