Niedawno otrzymałem e-mail od utalentowanego naukowca, który pytał, jak Botpress współpracuje z LLM-ami.
Pracował nad artykułem o unikaniu uzależnienia od jednego dostawcy i chciał się dowiedzieć, czy korzystamy z frameworków takich jak LangChain lub Haystack.
Z przyjemnością wyjaśniłem mu, że stworzyliśmy własne abstrakcje, które pozwalają twórcom Botpress łączyć się z LLM-ami.
Ze względu na szerokie zainteresowanie tematem postanowiłem upublicznić te informacje. Mogą się przydać innym deweloperom lub użytkownikom naszej platformy. Mam nadzieję, że będzie to dla Was równie ciekawe, jak dla mnie było tworzenie tego rozwiązania.
Dwa sposoby współpracy Botpress z LLM-ami
Botpress stworzył własne abstrakcje, które działają na dwa sposoby:
1. Integracje
Integracje mają pojęcie akcji o określonych typach wejścia i wyjścia.
Na platformie mamy otwarte komponenty open source, dzięki czemu społeczność może tworzyć własne integracje – prywatne lub dostępne publicznie.
Dostawcy LLM – tacy jak OpenAI, Anthropic, Groq itd. – mają każdy swoją integrację. To jeden ze sposobów, w jaki użytkownicy mogą się z nimi integrować.
2. Interfejsy integracji z LLM-ami
Na bazie koncepcji integracji dodaliśmy „interfejsy”.
To są po prostu standardowe definicje schematów, które integracje mogą rozszerzać. Stworzyliśmy standardowy schemat dla LLM-ów.
Jeśli integracja rozszerza ten schemat, jest traktowana jako dostawca LLM, więc działa od razu w Botpress.
Oto kilka przykładów integracji Botpress dla różnych dostawców LLM:
Mamy podobne interfejsy dla text2image, image2text, voice2text, text2voice itd.
Konfiguracje modeli
W Botpress Studio mamy dwa ogólne ustawienia: „Najlepszy model” i „Najszybszy model”. Zauważyliśmy, że większość zadań łatwo przypisać do jednego z tych dwóch trybów.
Jednak oprócz samego wyboru modelu zauważyliśmy, że poszczególni dostawcy bardzo się różnią pod względem wywoływania narzędzi i formatów wiadomości, przez co nie da się łatwo zamienić jednego modelu na inny i oczekiwać dobrych wyników.
Silnik wnioskowania Botpress
Dlatego opracowaliśmy własny silnik wnioskowania o nazwie LLMz, który współpracuje z dowolnym modelem bez konieczności (lub z minimalną koniecznością) zmiany promptów. Zapewnia też znacznie lepsze wywoływanie narzędzi i często znacznie lepszą wydajność pod względem kosztów tokenów i liczby zapytań do LLM.
Ten silnik korzysta z typów typescript do definicji narzędzi, markdown do formatowania wiadomości i kodu oraz natywnej piaskownicy LLM do wnioskowania.
LLMz oferuje wiele optymalizacji i funkcji debugowania, które są niezbędne w zaawansowanych zastosowaniach, takich jak:
- Kompresja tokenów wejściowych
- Inteligentne skracanie tokenów
- Pamięć zoptymalizowana pod kątem tokenów do kontekstu
- Równoległe i złożone wywoływanie narzędzi
- Łączenie wielu wiadomości i wywołań narzędzi w jednym zapytaniu do LLM
- W pełni typowane narzędzia (wejście i wyjście)
- Długotrwałe sesje dzięki serializacji piaskownicy
- Mockowanie, opakowywanie i śledzenie narzędzi
- Pełna izolacja wykonania w lekkich izolatach V8 (umożliwia szybkie i bardzo tanie uruchamianie tysięcy równoczesnych wykonań)
- Automatyczne iteracje i odzyskiwanie po błędach
Wszystkie te funkcje były niezbędne w naszych zastosowaniach. Zwykłe wywoływanie narzędzi nie pozwalało ich zrealizować lub było to bardzo trudne.
Argumenty przeciwko lekkim modelom routerów
Długo rozważaliśmy stworzenie lekkiego modelu routera, który działałby nad istniejącymi modelami i automatycznie wybierał odpowiedni model do danego zadania.
Jednak z kilku powodów zdecydowaliśmy się tego nie robić:
1. Przewidywalność
Większość naszych klientów – co zrozumiałe – oczekuje niezawodnych i przewidywalnych rezultatów.
Dlatego pomysł dynamicznego routera modeli jest nieco ryzykowny dla zaawansowanych agentów. Wprowadza dodatkową warstwę nieprzewidywalności do LLM.
2. Szybkość
Opóźnienie jest bardzo istotne w naszych zastosowaniach. Aby router działał szybko, model musi być bardzo mały (i prawdopodobnie prostszy) niż modele, do których kieruje – najczęściej jest to tradycyjny klasyfikator.
Takie modele zwykle działają dobrze przy zadaniach, do których zostały wytrenowane, ale a) ich krótki kontekst jest problemem przy długich promptach, b) nie radzą sobie z generalizacją do innych promptów niż te, na których były trenowane.
3. Wyższość modelu czy równość modeli
Choć benchmarki mogą sugerować co innego, w praktyce rzadko widzieliśmy modele, które przewyższają GPT-4o (do tej pory).
Wciąż nie wiadomo, czy LLM-y będą z czasem lepsze w zadaniu X niż w Y, czy też wszystkie staną się bardzo dobre w większości zastosowań. W tym drugim przypadku wybór modelu nie będzie miał większego sensu.
Przygotowanie LLM na przyszłość dzięki feedbackowi
LLM-y w ciągu kilku lat staną się powszechnym towarem i wybór modelu nie będzie już istotny.
Z tych powodów postanowiliśmy skupić się na zapewnieniu dobrego mechanizmu przekazywania przykładów do LLM-ów.
Stworzyliśmy więc system zbierania feedbacku. Przechowuje on „wiedzę” na potrzeby przyszłych wykonań i dynamicznie dostarcza najbardziej trafne informacje podczas generowania promptu, aby zapewnić niezawodną i ciągłą poprawę w czasie.
W miarę jak LLM-y osiągają coraz wyższą wydajność, jesteśmy gotowi i podekscytowani, by jak najlepiej wykorzystać je dla użytkowników naszej platformy.
.webp)
