Jakie backendy są najczęściej wykorzystywane w projektach aplikacji web związanych z AI?

pytanie zadane 17 marca w Offtop przez Edd Obywatel (1,400 p.)

Jakie backendy (języki i frameworki) są najczęściej wykorzystywane w projektach aplikacji web związanych z AI? Do opracowania modeli, wiadomo, Python. A co dalej, jak już mamy model? Spotkałem się z opinią, że bardzo popularne są GoLang i Typescript (przy wystawianiu modeli AI/ML), ale zapytam tutaj na forum Was, jakie technologie są najczęściej używane w webowych projektach z AI?

2 odpowiedzi

odpowiedź 18 marca przez Wiciorny Ekspert (283,260 p.)

Moim zdaniem patrzenie na backend w projektach AI jako „jaki język do AI” to trochę niepoprawne, błędne podejście. AI to tylko jeden z elementów systemu, a backend dobiera się przede wszystkim do tego, co aplikacja ma robić i jakie ma wymagania biznesowe. To czy wykorzystujesz AI, czy nie- nie ma nic z tym wspólnego, bo niezależnie od technologii wykorzystanie AI, będzie zbliżone i funkcjonować będzie tak samo.

W dzisiejszych aplikacjach mikroserwisowych ( mocno rozbudowanych i mocno dostosowanych do potrzeb klienta) w większych rzadko kończy się na jednym backendzie, mam na myśli też jednej technologii backendowej. Najczęściej modele np pisane w Pythonie działają jako osobny serwis, a właściwy backend aplikacji (czyli logika biznesowa, autoryzacja, billing, komunikacja z frontendem) jest napisany w czymś innym.

I popularność technologii np takiej jak wspominasz TypeScript/Node.js nie wynika, że ma coś wspólnego z AI, tylko dlatego, że świetnie sprawdza się jako warstwa API i „klej” całej aplikacji – ogarnia requesty, integracje, user flow, a sam model jest po prostu jednym z serwisów, do którego się odwołuje.
Inne jężyki np GO - sprawdzi się pewnie w czymś, co wymaga ( nie jestem przekonany i pewny, bo nie znam sie na Go) ale czymś związanym z wydajnościa, gdzie jest duży workload aplikacji,
Java też jest bardzo popularna i dalej w aplikacjach typu enterprise jest dominantem, króluje ze względu na audytnowane rozwiązania, sprawdzone frameworki - wsparcie w wydaniach, performance też ma w miare dobry, ale dalej jak pisałem to jest kwestia potrzeb

Dlatego wybór backendu nie zależy od tego, że to projekt AI, tylko od potrzeb aplikacji (skala, latency, złożoność logiki, zespół). AI jest po prostu kolejnym komponentem, a nie czymś, co narzuca cały stack technologiczny.

U nas np. w projekcie mamy mikroserwis który ma kilka backendów, kilka rodzaj ow baz, zdarza się, że mikroserwisy mają całkiem inne technologie, jedne są napisane w Javie, inne w Rubym, czy jest to dobre? I tak i nie, komplikuje to złożoność, powoduje, że czasami naistotniejszy jest interfers API i komunikacja, ale każdy zespół pracuje nad innym serwisem, więc jeśli developerzy mają specjalizacje w danej technologii to jest to do pogodzenia ze złożonością, a AI wykorzystujemy w taki sam sposób niezależnie

komentarz 18 marca przez Edd Obywatel (1,400 p.)
edycja 18 marca przez Edd

Dzięki za wpis!

Generalnie pytałem nie "co się bardziej nadaje" tylko co w praktyce "jest częściej używane" w branży ;) -> Ale mniejsza, o to bo poruszyłeś ciekawe sprawy w wątku.

O GoLangu sporo słyszałem, że jest dość często używany do wystawiania modeli głównie LLM - z różnych powodów (np. jest LangChainGo - odpowiednik "oryginalnego" LangChain działającego tylko z Py / JS / TS).

odpowiedź 18 marca przez Benek Szeryf (93,850 p.)

Hm, jak stawiamy jakieś chatboty w pracy to głównie w Pythonie, np. Flask. Oczywiście jest też jakiś JS do obsługi frontu.

Do opracowania modeli, wiadomo, Python. A co dalej, jak już mamy model?

Bardzo rzadko robi się własne modele. Dużo łatwiej zaprząc LLM-y i wykorzystywać je po API. Na przykład w chatbocie często implementuje się RAG-a (chodzi o to, by bot miał wiedzę korporacyjną, która nigdy nie była w danych treningowych), a żeby to zrobić, musisz mieć model do embeddingów. Wytrenowanie aż tak dobrego własnego modelu jest raczej niemożliwe, a na pewno nie opłacalne.

Generalnie trend jest taki, że teraz buduje się agentów do specyficznych zadań. Łączy się je i one zarządzają logiką aplikacji, decydują jakie narzędzie uruchomić etc. To jest dość trudne, bo LLM-y nie są deterministyczne i jeśli zbyt szeroko zdefiniuje się zadanie i nie obsłuży błędów, to taki agent pójdzie w maliny. Na dodatek może wygenerować spore koszty lub dać dostęp do systemu (obie te rzeczy można kontrolować na poziomie projektowania architektury).

Takich agentów tworzy się w różnych językach, ja znam głównie Pythona, ale wiem że ludzie piszą też dużo w JS, można w Golangu. Jak masz API to możesz to zaprogramować we wszystkim. Z mojego rozeznania dominuje Python i JS. Otwórz sobie dokumentację od openAI i zobacz przykładowy kod, by wyczuć o co chodzi.

komentarz 18 marca przez Edd Obywatel (1,400 p.)

Dzięki za odpowiedź! Ciekawe rzeczy piszesz.

Poruszyłeś głównie temat LLM, a "stary, klasyczny" ML jeszcze żyje ;) (wiem, ze sporo projektów, zwłaszcza CV jest wciąż używanych i rozwijanych bez dużych modeli LLM; niby są VLM czy wielomodalne LLM, ale to jeszcze nie ta jakość w CV). Mnie interesują zarówno LLM jak i modele wg. starej szkoły (ponoć ich udział jest nadal sporo większy niż LLM w biznesie - tak mówił Vladimir z DW).

O GoLangu sporo słyszałem, że jest dość często używany do wystawiania modeli z różnych powodów (np. jest LangChainGo - odpowiednik "oryginalnego" LangChain działającego tylko z Py / JS / TS).

Skoro zajmujesz się dużo LLM.... Zastanawiam się jak zabezpieczacie model przed "lewymi" promptami (wiadomo, użytkownik może wpisać wszystko w czacie), czy wręcz promptami które mogą wpłynąć na bezpieczeństwo i działanie całego systemu (luki bezpieczeństwa). Rozumiem, ze GPU macie w chmurze? Z jakich korzystacie głównie?

Czy korzystacie z OpenAI i podobnych zamkniętych modeli czy macie mniejsze, open-sourc-owe modele wystawione na serwerach, chmurze?

komentarz 19 marca przez Benek Szeryf (93,850 p.)

Wiem, że klasyczny ML jest w użyciu, bo takie projekty też robiłem, gdzie trenowałem standardowe klasyfikatory. Jak się zrobi dobry feature engineering to takie modele mają wiele zalet, są lekkie i bardzo wydajne. No i nie płaci się za żadne tokeny. Ogólnie muszę mieć dobre uzasadnienie, by zaprząc LLM-a (np. porównanie kosztów). Czasem trenowanie swoich sieci jest nieopłacalne, jeśli LLM potrafi sklasyfikować poprawnie, czy na obrazku jest kot, czy pies i kosztuje to mikro centa. Wszystko zależy ile takich odpytań poleci i jaki wygeneruje to koszt. Dla miesięcznych wydatków na LLM-a rzędu 100-500$ te koszty dla firm są znikome.

W moim przypadku to są modele w chmurze od openAI. One są zamknięte wewnątrz firmowej infrastruktury. Modele są deployowane w izolowanych środowiskach.

Zabezpieczenia to szeroki temat. Najprostszą opcją jest mieć bota, który pobiera informacje z bazy danych i wszystko co w niej jest, jest dla użytkownika. Nawet w przypadku wycieku nic się nie dzieje.

Natomiast jeśli agent AI ma dostęp do plików systemowych, może w nich coś zapisywać, pobierać itd. to trzeba mocno ograniczyć mu uprawnienia, by właśnie nie usunął takich plików. Wszystko trzeba logować i mieć możliwość przywracania backupów, do których agenci nie mają dostępu.

Przykładem kiedy coś może pójść nie tak jest zwykłe otwieranie pliku na podstawie nazwy pliku wprowadzonej przez użytkownika/innego agenta. Jeśli tej ścieżki się nie obsłuży, to można będzie wstrzyknąć coś takiego: ../../../faktura_01_2026.pdf i odesłać zawartość do użytkownika.

komentarz 19 marca przez Edd Obywatel (1,400 p.)

Fajna dyskusja się wywiązała, bo myśłałem, że to forum zdechło :)

Mam niewielkie pojęcie o feature engineering czy metodach statystycznych, ale trochę się interesowałem computer vision. Modele VLM jak CLIP niestety w moich próbach szybko poległy jeśli chodzi o kategoryzowanie zdjęć, dużo lepiej wypadł własny model oparty na CNN i przetrenowany na 30.000 zdjęć. Koszt jest spory, roboty dużo, ale finalnie zupełnie inna jakość. CLIP z grubsza działa dobrze, kod obsługujący zamykał się w 100 LOC :) (choć prosty przykład można napisać w 15-20 liniach py), ale niestety dokładność była średnia (czytaj: słaba). AI nie jest po to by je ciągle sprawdzać i poprawiać.