Baru-baru ini saya menerima emel daripada seorang sarjana berbakat yang bertanya bagaimana Botpress berinteraksi dengan LLM.
Beliau sedang menulis kertas kerja tentang mengelakkan penguncian vendor, dan ingin tahu sama ada kami mungkin menggunakan rangka kerja seperti LangChain atau Haystack.
Saya dengan senang hati berkongsi bahawa kami membangunkan abstraksi kami sendiri yang membolehkan pembangun Botpress berinteraksi dengan LLM.
Memandangkan minat yang meluas terhadap topik ini, saya ingin berkongsi maklumat ini secara terbuka. Ia mungkin berguna untuk pembangun lain atau pengguna platform kami. Saya harap anda mendapati ia menarik seperti mana saya mendapati ia menarik semasa menciptanya.
Dua cara Botpress berinteraksi dengan LLM
Botpress telah membangunkan abstraksinya sendiri yang berfungsi dalam dua cara:
1. Integrasi
Integrasi mempunyai konsep tindakan dengan jenis input dan output tertentu.
Kami menyediakan komponen sumber terbuka di platform, jadi komuniti boleh membina integrasi mereka sendiri yang boleh digunakan secara peribadi atau dikongsi secara umum.
Jadi penyedia LLM – OpenAI, Anthropic, Groq, dan lain-lain – masing-masing mempunyai integrasi. Inilah salah satu cara pengguna kami boleh berinteraksi dengan mereka.
2. Antara muka integrasi LLM
Selain konsep integrasi, kami menambah "antara muka".
Ini hanyalah definisi skema standard yang boleh diperluaskan oleh integrasi. Kami telah mencipta skema standard untuk LLM.
Selagi satu integrasi memanjangkan skema ini, integrasi tersebut dianggap sebagai penyedia LLM. Jadi ia berfungsi secara automatik dalam Botpress.
Berikut adalah beberapa contoh integrasi Botpress untuk pelbagai penyedia LLM:
Kami juga mempunyai antara muka serupa untuk text2image, image2text, voice2text, text2voice, dan sebagainya.
Konfigurasi model
Dalam Botpress Studio, kami menyediakan dua konfigurasi umum: "Model Terbaik" dan "Model Pantas". Kami dapati kebanyakan tugasan sesuai dengan salah satu daripada dua mod ini.


Namun, selain pemilihan model semata-mata, kami dapati penyedia yang berbeza mempunyai perbezaan besar dalam pemanggilan alat dan format mesej, jadi menukar model tidak semestinya memberikan prestasi yang baik.
Enjin inferens Botpress
Disebabkan itu, kami membangunkan enjin inferens kami sendiri yang dipanggil LLMz, yang boleh digunakan dengan mana-mana model tanpa (atau dengan perubahan prompt yang sangat minimum). Ia juga menyediakan pemanggilan alat yang jauh lebih baik dan sering kali prestasi yang lebih baik dari segi kos token dan bilangan pusingan LLM.
Enjin ini menggunakan jenis typescript di belakang tabir untuk definisi alat, markdown untuk format output mesej dan kod, serta kotak pasir pelaksanaan asli LLM untuk inferens.
LLMz menyediakan pelbagai ciri pengoptimuman dan penyahpepijatan yang diperlukan untuk kes penggunaan lanjutan seperti:
- Pemampatan token input
- Pemotongan token pintar
- Memori ke konteks yang dioptimumkan token
- Pemanggilan alat selari & komposit
- Gabungan pelbagai mesej + pemanggilan alat dalam satu panggilan LLM
- Alat yang benar-benar selamat jenis (input & output)
- Sesi jangka panjang melalui penyirian kotak pasir
- Mocking, pembungkusan dan penjejakan alat
- Pengasingan pelaksanaan penuh dalam V8 isolates ringan (membolehkan ribuan pelaksanaan serentak dijalankan dengan pantas dan kos rendah)
- Iterasi automatik dan pemulihan ralat
Semua ciri ini penting untuk kes penggunaan kami. Namun, ia sama ada mustahil atau sangat sukar dilakukan dengan pemanggilan alat biasa.
Mengapa kami tidak membina model router ringan
Kami pernah mempertimbangkan untuk membina model router ringan yang akan duduk di atas model sedia ada dan secara automatik memilih model terbaik untuk sesuatu tugasan.
Namun, kami memutuskan untuk tidak melakukannya atas beberapa sebab:
1. Kebolehjangkaan
Kebanyakan pelanggan kami – secara difahami – mahukan hasil yang boleh dipercayai dan boleh diramal.
Jadi idea router model dinamik agak menakutkan untuk ejen peringkat tinggi. Ia menambah satu lagi lapisan ketidakpastian pada LLM.
2. Kelajuan
Kelewatan adalah sangat penting untuk kes penggunaan kami. Untuk router menjadi pantas, model perlu sangat kecil (dan mungkin kurang pintar) berbanding model yang akan dirutekan – kemungkinan besar pengelas tradisional.
Walaupun biasanya ia berfungsi dengan baik apabila dilatih untuk tugasan tertentu, a) saiz konteks yang pendek menjadi isu untuk prompt panjang dan b) ia gagal untuk menggeneralisasi kepada prompt lain di luar apa yang telah dilatih.
3. Keunggulan model atau kesamarataan model
Walaupun penanda aras mungkin menunjukkan sebaliknya, dalam penggunaan sebenar, kami jarang melihat model mengatasi GPT-4o (setakat ini).
Masih belum jelas sama ada LLM benar-benar akan lebih baik untuk tugasan X berbanding tugasan Y dari masa ke masa, atau jika semua LLM akhirnya akan sangat baik untuk kebanyakan perkara. Jika yang kedua berlaku, pemilihan model tidak lagi berbaloi.
Masa depan LLM dengan maklum balas
LLM akan menjadi komoditi dalam beberapa tahun lagi dan pemilihan model tidak akan menjadi isu utama.
Atas sebab-sebab itu, kami memutuskan untuk melaburkan usaha kami dalam menyediakan mekanisme yang baik untuk memberikan contoh kepada LLM.
Jadi kami membina sistem untuk menangkap maklum balas. Ia menyimpan "pembelajaran" untuk pelaksanaan masa hadapan. Dan ia secara dinamik menyediakan pembelajaran paling relevan semasa prompt untuk pelaksanaan seterusnya, bagi memastikan penambahbaikan yang berterusan dan boleh dipercayai dari masa ke masa.
Sambil setiap LLM terus berkembang ke arah prestasi yang lebih tinggi, kami bersedia dan teruja untuk memanfaatkannya sepenuhnya untuk pengguna platform kami.





.webp)
