Kamakailan, nakatanggap ako ng email mula sa isang mahusay na iskolar na nagtatanong kung paano nakikipag-ugnayan ang Botpress sa mga LLM.
Nagsusulat siya ng papel tungkol sa pag-iwas sa vendor lock-in, at nais niyang malaman kung gumagamit kami ng framework tulad ng LangChain o Haystack.
Ikinatuwa kong ibahagi sa kanya na gumawa kami ng sarili naming mga abstraksyon na nagpapahintulot sa mga tagabuo ng Botpress na makipag-ugnayan sa mga LLM.
Dahil marami ang interesado sa paksang ito, nais kong gawing pampubliko ang impormasyong ito. Maaaring makatulong ito sa ibang developer o mga gumagamit ng aming plataporma. Sana ay maging kasing-interesante ito sa inyo gaya ng paggawa ko rito.
Dalawang paraan ng pakikipag-ugnayan ng Botpress sa mga LLM
Gumawa ang Botpress ng sarili nitong mga abstraksyon na gumagana sa dalawang paraan:
1. Mga Integrasyon
May konsepto ang mga integrasyon ng mga aksyon na may tiyak na mga uri ng input at output.
Mayroon kaming open source na mga bahagi sa plataporma, kaya maaaring gumawa ang komunidad ng sarili nilang mga integrasyon na maaaring pribado o bukas para sa lahat.
Kaya ang mga LLM provider – OpenAI, Anthropic, Groq, atbp. – ay may kanya-kanyang integrasyon. Isa ito sa mga paraan para makipag-ugnayan ang aming mga user sa kanila.
2. Mga interface ng LLM integration
Bukod sa konsepto ng mga integrasyon, nagdagdag kami ng mga “interface.”
Ito ay mga karaniwang depinisyon ng iskema na maaaring palawakin ng mga integrasyon. Lumikha kami ng pamantayang iskema para sa LLMs.
Basta't sumusunod ang isang integration sa schema na ito, itinuturing na itong LLM provider. Kaya gumagana ito agad sa Botpress.
Narito ang ilang halimbawa ng mga integrasyon ng Botpress para sa iba't ibang LLM provider:
Mayroon din kaming katulad na mga interface para sa text2image, image2text, voice2text, text2voice, at iba pa.
Mga configuration ng modelo
Sa loob ng Botpress Studio, may dalawang pangkalahatang configuration: ang "Pinakamahusay na Modelo" at ang "Pinakamabilis na Modelo". Napansin naming karamihan sa mga gawain ay madaling magkasya sa isa sa dalawang mode na ito.
Ngunit bukod sa simpleng pagpili ng modelo, napansin namin na masyadong nagkakaiba-iba ang mga provider pagdating sa tool calling at mga format ng mensahe kaya mahirap palitan ang isang modelo ng iba at asahan ang parehong kalidad ng pagganap.
Ang inference engine ng Botpress
Dahil dito, gumawa kami ng sarili naming inference engine na tinawag naming LLMz, na gumagana sa kahit anong modelo nang walang (o napakakaunting) kailangang baguhin sa prompt. Nagbibigay din ito ng mas mahusay na pagtawag ng mga tool at kadalasan ay mas maganda ang performance pagdating sa gastos sa token at dami ng roundtrip sa LLM.
Gumagana ang engine na ito gamit ang typescript types sa likod ng mga tool definition, markdown para sa format ng mensahe at code output, at isang LLM-native na execution sandbox para sa inference.
Nagbibigay ang LLMz ng maraming optimisasyon at debugging features na kinakailangan para sa mga advanced na gamit tulad ng:
- Pag-compress ng mga input token
- Matalinong pagpapaikli ng token
- Token-optimized na memory-to-context
- Sabay-sabay at pinagsamang tool calling
- Pagsasama ng maraming mensahe + tool call sa isang LLM call
- Lubos na ligtas sa uri ang mga tool (input at output)
- Matagal na mga session gamit ang sandbox serialization
- Pagmo-mock, pagba-balot, at pagtra-trace ng mga kasangkapan
- Kumpletong isolation ng execution sa magagaan na V8 isolates (nagpapahintulot ng libo-libong sabayang execution nang mabilis at mura)
- Awtomatikong pag-uulit at pagbangon mula sa error
Lahat ng mga ito ay kinakailangan para sa aming mga gamit. Ngunit mahirap o halos imposibleng gawin ang mga ito gamit ang karaniwang pagtawag ng kasangkapan.
Ang kaso laban sa magagaan na mga modelo ng router
Matagal naming pinag-isipan ang paggawa ng magaan na router model na uupo sa ibabaw ng mga umiiral na modelo at awtomatikong pipili ng tamang modelo para sa gawain.
Ngunit nagpasya kaming huwag ituloy ito dahil sa ilang dahilan:
1. Predictability
Karamihan sa aming mga kliyente – na maiintindihan naman – ay gusto ng maaasahan at tiyak na resulta.
Kaya ang ideya ng dynamic na model router ay medyo nakakatakot para sa mga high-level na agent. Nagdadagdag ito ng isa pang antas ng hindi tiyak na resulta sa mga LLM.
2. Bilis
Mahalaga ang latency para sa mga gamit namin. Para maging mabilis ang router, kailangang maliit (at marahil mas simple) ang modelo kaysa sa mga modelong papadalhan nito – malamang ay isang tradisyonal na classifier.
Bagamat okay ang performance ng mga ito kapag sinanay sa tiyak na gawain, a) problema ang maikling context size para sa mahahabang prompt at b) hindi sila nakakageneralize sa ibang prompt na wala sa training nila.
3. Kataasan o pagkakapantay-pantay ng modelo
Bagamat iba ang sinasabi ng mga benchmark, sa aktwal, bihira naming makita na may modelong mas mahusay kaysa GPT-4o (sa ngayon).
Hindi pa malinaw kung talagang mas gagaling ang mga LLM sa gawain X kaysa sa gawain Y sa paglipas ng panahon, o kung lahat ng LLM ay magiging mahusay na sa halos lahat ng bagay. Kung mangyari ang huli, hindi na sulit ang pagpili ng modelo.
Pagpapalakas ng mga LLM gamit ang puna
Magiging karaniwan na lang ang mga LLM sa loob ng ilang taon at hindi na magiging isyu ang pagpili ng modelo.
Dahil dito, nagpasya kaming ituon ang aming pagsisikap sa pagbibigay ng mahusay na paraan ng pagbibigay ng mga halimbawa sa mga LLM.
Kaya gumawa kami ng sistema para mangolekta ng feedback. Nagtatabi ito ng "natutunan" para sa mga susunod na execution. At awtomatikong nagbibigay ng pinaka-angkop na natutunan sa prompt-time para sa mga susunod na execution, para masiguro ang tuloy-tuloy at maaasahang pagbuti ng performance sa paglipas ng panahon.
Habang patuloy na gumagaling ang bawat LLM, handa at sabik kaming gamitin ang mga ito para sa mga gumagamit ng aming plataporma.
