O czym jest ten film
- Jack Roberts przedstawia Jev jako model, którego niski koszt i krótki czas odpowiedzi pozwalają oceniać wiele pozycji osobno.
- Pokazuje, jak w Base44 zbudować jedną aplikację z wyszukiwarką emoji oraz narzędziem pomagającym wybrać film.
- Wyjaśnia, że użytkownik może opisać swoje potrzeby zwykłym językiem, a model ocenić dostępne propozycje.
- Omawia dwa sposoby podłączenia AI do aplikacji: integrację dostępną w Base44 oraz własny klucz API z OpenRouter.
- Przedstawia bibliotekę reklam, w której można wyszukiwać materiały według własnych kryteriów i pytać o konkretne cechy kreacji.
- Pokazuje, jak użyć Gemini do opisania obrazów, ponieważ — według autora — Jev przyjmuje w tym zastosowaniu tekst, a nie same obrazy.
- Tłumaczy, dlaczego koszt pojedynczej oceny ma znaczenie, gdy trzeba przeanalizować setki reklam.
- Buduje wyszukiwarkę komponentów interfejsu, która szereguje propozycje według opisu potrzebnego elementu.
- Zwraca uwagę na różnicę między dopasowaniem słowa kluczowego a oceną, czy element spełnia wymaganie.
- Pokazuje publikację aplikacji w Base44, choć nie przechodzi szczegółowo przez konfigurację wszystkich źródeł danych i integracji.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Oceniaj osobno każdą propozycję, gdy liczy się sens zapytania
Na czym polega: Jev może przyjąć opis potrzeby i ocenić kolejne pozycje — emoji, reklamy lub komponenty interfejsu — pod kątem tego opisu.
Jak stosować: Przygotuj listę kandydatów oraz jasne kryterium wyboru. Poproś model o ocenę każdej pozycji i uporządkuj wyniki według uzyskanych ocen.
Na co uważać: Trafność zależy od jakości opisów kandydatów. Model nie oceni cechy, której nie ma w przekazanych mu danych.
2.Niski koszt zmienia sposób projektowania wyszukiwarki
Na czym polega: Według Robertsa Jev jest na tyle tani, że można ponawiać ocenę dużego zbioru po każdym nowym zapytaniu użytkownika.
Jak stosować: Rozważ takie podejście, gdy masz setki lub kilka tysięcy krótkich opisów, a użytkownicy szukają według trudnych do przewidzenia kryteriów.
Na co uważać: Przed wdrożeniem policz koszt całego wyszukiwania, liczbę wywołań i czas odpowiedzi przy rzeczywistym ruchu. Film podaje wyniki demonstracji, a nie pełny cennik gotowej usługi.
3.Zacznij od prostego prototypu
Na czym polega: Autor zleca Base44 przygotowanie aplikacji na podstawie opisu dwóch funkcji: wyszukiwarki emoji i narzędzia do wyboru filmu.
Jak stosować: Opisz, co użytkownik wpisuje, jakie wyniki ma zobaczyć i jak powinien wyglądać ekran. Uruchom wersję próbną, a potem poprawiaj ją na podstawie konkretnych zachowań.
Na co uważać: Samo wygenerowanie interfejsu nie dowodzi, że podłączono właściwy model, aktualne dane i wszystkie potrzebne integracje.
4.Zapytania w zwykłym języku dają więcej swobody niż sztywne filtry
Na czym polega: W demonstracji użytkownik może wpisać zarówno gatunek filmu, jak i mniej oczywisty opis tego, czego szuka. Podobnie pyta o reklamy o określonym stylu lub sposobie przedstawienia oferty.
Jak stosować: Pozwól użytkownikowi opisać cel własnymi słowami. Następnie pokaż, które wyniki pasują i dlaczego zostały wybrane.
Na co uważać: Dla zapytań bardzo ogólnych albo wieloznacznych wynik może być zaskakujący. Warto umożliwić doprecyzowanie pytania.
5.Obrazy najpierw zamień na użyteczne opisy
Na czym polega: W przykładzie z reklamami Gemini opisuje materiały wizualne, a Jev ocenia powstały tekst. Autor przedstawia to jako sposób obejścia ograniczenia Jev dotyczącego obrazów.
Jak stosować: Jeśli analizujesz grafiki, zadbaj, by opis uwzględniał cechy istotne dla zadania: tekst na obrazie, układ, ofertę i element przyciągający uwagę.
Na co uważać: Błąd w opisie obrazu przejdzie do dalszej oceny. Przy ważnych decyzjach sprawdzaj także oryginalną reklamę.
6.Własna skala ocen ułatwia porównywanie reklam
Na czym polega: Pokazana biblioteka ocenia reklamy według przyjętych kryteriów, takich jak sposób przyciągnięcia uwagi, rodzaj przekazu, jego jasność czy zgodność reklamy ze stroną docelową.
Jak stosować: Ustal kryteria przed analizą i zapisz, co oznacza wysoka oraz niska ocena. Dzięki temu możesz porównać materiały konkurencji lub ponowić analizę po zmianie założeń.
Na co uważać: Wynik liczbowy nie jest obiektywną miarą skuteczności reklamy. To ocena według przyjętej skali, którą trzeba zestawić z danymi o rzeczywistych efektach kampanii.
7.Zachowuj uzasadnienie obok wyniku
Na czym polega: W demonstracji przy ocenionych reklamach widać etykiety i przesłanki, które pomagają zrozumieć, dlaczego dany materiał trafił do wyników.
Jak stosować: Przy każdej pozycji zapisuj ocenę, krótkie uzasadnienie i fragment opisu, na którym model ją oparł.
Na co uważać: Uzasadnienie może brzmieć przekonująco mimo błędnego odczytania materiału. Sprawdzaj przykłady z wysokimi i niskimi ocenami.
8.Wyszukuj komponenty według funkcji, nie tylko nazwy
Na czym polega: Autor pokazuje bibliotekę elementów interfejsu, w której model ocenia, czy komponent pasuje do opisu zadania. Przykładowo może szukać tabeli cen z przełącznikiem między płatnością miesięczną i roczną.
Jak stosować: W zapytaniu podaj wymagane działanie, wygląd i kontekst użycia. Tak przygotowany opis pozwoli znaleźć także element, który nie ma oczywistej nazwy.
Na co uważać: Wysoka pozycja w rankingu nie oznacza jeszcze, że komponent pasuje technicznie do projektu. Trzeba sprawdzić kod, zależności i zachowanie po wdrożeniu.
9.Oddziel dostęp do danych od ich oceny
Na czym polega: Jev szereguje kandydatów, ale aplikacja musi najpierw dysponować opisami filmów, reklam lub komponentów. Autor wspomina też o możliwości dodania narzędzi pobierających nowe reklamy.
Jak stosować: Zaplanuj osobno pobieranie materiałów, przygotowanie opisów i ocenę przez model. Dzięki temu łatwiej ustalić, który etap wymaga poprawy.
Na co uważać: Film nie pokazuje szczegółowo, jak zasilane są wszystkie biblioteki. Przed publikacją sprawdź aktualność danych i uprawnienia do ich wykorzystania.
10.Publikację poprzedź sprawdzeniem działania aplikacji
Na czym polega: Roberts pokazuje, że prototyp z Base44 można udostępnić przez funkcję publikacji. Wspomina również o skanach bezpieczeństwa dostępnych na platformie.
Jak stosować: Przetestuj typowe i nietypowe zapytania, sprawdź odpowiedzi modelu, źródła danych oraz ustawienia dostępu, a dopiero potem udostępnij aplikację innym.
Na co uważać: Łatwe opublikowanie prototypu nie zastępuje testów integracji, kosztów i jakości wyników.
Redakcyjne tłumaczenie
Co zmienia Jev
Jev właśnie się pojawił i — zdaniem autora — otwiera możliwości, które wcześniej trudno było uzasadnić kosztowo. Ma być 400 razy tańszy od Astra i odpowiadać znacznie szybciej niż inne modele. Żeby skorzystać z tych zalet, trzeba jednak odpowiednio zaprojektować aplikację. Pokażę to na trzech przykładach, zaczynając od rozwiązania, które można zbudować bez dużego doświadczenia.
Najważniejsze są dwie rzeczy: koszt i czas odpowiedzi. Kiedy ocena pojedynczej pozycji jest tania, można wykonać ją dla większej liczby produktów, użytkowników czy elementów katalogu. Kiedy model odpowiada szybko, wynik może pojawiać się na bieżąco, w trakcie pracy. Właśnie połączenie tych cech sprawia, że pewne pomysły zaczynają mieć sens jako usługi.
We wszystkich przykładach zbuduję aplikacje w Base44, które sponsoruje ten materiał. Będę opisywał potrzebne funkcje, sprawdzał otrzymane wyniki i pokazywał, jak połączyć Jev z innymi narzędziami. Trzeba też pamiętać o jego ograniczeniach.
W tych zastosowaniach Jev wykonuje przede wszystkim krótkie zadania decyzyjne. Dostaje opis w zwykłym języku, a zwraca wybór, ocenę albo informację, że nic nie pasuje. To wystarcza, by zbudować wyszukiwarkę, która reaguje na znacznie swobodniejsze pytania niż zestaw gotowych filtrów.
Pierwszy przykład: emoji i wybór filmu
Punktem wyjścia są pomysły na aplikacje, które przyciągnęły uwagę na platformie X. Jeden z nich pokazuje wyszukiwanie emoji: wpisujemy opis, a pasujące symbole pojawiają się na ekranie. Chcę odtworzyć tę funkcję, a obok niej dodać pomoc w wyborze filmu na wieczór.
W Base44 opisuję więc aplikację z dwiema częściami. Pierwsza ma zawierać pole wyszukiwania, zbiór emoji i animację wyników. Druga ma pomagać wybrać film na podstawie wpisanego życzenia. Nadaję jej nazwę „Netflix Finder”.
W Base44 można wybrać tryb automatyczny, który dobiera model do zadania, albo wskazać model samodzielnie. Przy tworzeniu prototypu wybieram Fable 5.1. Platforma zajmuje się też przygotowaniem i utrzymaniem aplikacji. Zamiast od razu ją budować, można najpierw przejść do trybu planowania i doprecyzować pomysł w rozmowie. Tutaj wysyłam opis do wykonania.
Jak zasilić gotową aplikację przez Jev? Jedna droga prowadzi przez OpenRouter: można uzyskać tam klucz API i wskazać konkretny model. Druga to skorzystanie z integracji AI dostępnych w Base44, rozliczanych w ramach kredytów platformy. W pokazie autor omawia obie możliwości, ale nie przeprowadza szczegółowej konfiguracji połączenia krok po kroku.
Sprawdźmy wyszukiwarkę emoji. Po wpisaniu słowa „dieta” pojawiają się symbole związane z jedzeniem. Można też zapytać mniej typowo: jaka żywność przydałaby się na bezludnej wyspie? Model ma wówczas ocenić opisy poszczególnych emoji pod kątem nowego pytania. Nie potrzebuje wcześniej przygotowanego filtra o dokładnie takiej nazwie.
Autor podkreśla, że przy każdym zapytaniu Jev może ponownie przejrzeć dostępne opisy. Zwraca też uwagę na deklarowaną zerową stawkę za tokeny wyjściowe. W takim sposobie pracy koszt pojedynczej oceny ma duże znaczenie: jeśli jest niski, można powtarzać ją dla całego zbioru przy kolejnych pytaniach.
Druga część aplikacji pomaga wybrać film. Wpisuję „science fiction, które daje do myślenia”, potem „horror”, „filmy o AI” i wreszcie „Mars”. Za każdym razem lista zmienia się zgodnie z zapytaniem. Przy ostatnim haśle pojawia się film związany z Marsem.
Roberts porównuje takie działanie z wyszukiwaniem opartym na osobnej bazie wektorowej, często używanej w rozwiązaniach RAG. W pokazanym przykładzie Jev ocenia dostępne pozycje bez budowania takiego indeksu. Aplikacja nadal musi mieć skąd wziąć opisy filmów, które poddaje ocenie. Autor wspomina o możliwości połączenia jej z API związanym z Netfliksem, ale nie pokazuje takiej integracji w szczegółach.
Kiedy prototyp działa, przechodzę do publikacji w Base44. Platforma pozwala udostępnić aplikację publicznie i oferuje skany bezpieczeństwa. Po kilku kliknięciach otrzymuję adres, który mogę wysłać innym. Można też rozbudować projekt o płatności. Tak pomysł podpatrzony w mediach społecznościowych staje się działającą aplikacją.
W tym miejscu autor odsyła zainteresowanych do własnego kursu o agentach AI, Claude i ChatGPT oraz do materiałów dotyczących jego systemów i projektowania aplikacji.
Drugi przykład: biblioteka reklam, którą można przepytywać
Kolejne zastosowanie dotyczy reklam. Jeśli prowadzisz firmę, możesz chcieć zebrać materiały konkurencji, porównać sposoby przedstawienia oferty i szybko znaleźć przykłady pasujące do planowanej kampanii. Ręczne przejrzenie setek kreacji zajmuje czas. Ocena każdej z nich za pomocą drogiego modelu też może kosztować dużo.
Tutaj pojawia się ważne ograniczenie. W rozwiązaniu przedstawionym przez autora Jev pracuje na tekście, a nie ogląda samych obrazów. Dlatego do pierwszego etapu dodaję Gemini. Ten model opisuje obrazy, a Jev otrzymuje tekstowe opisy i na ich podstawie klasyfikuje oraz ocenia reklamy.
Wracam do Base44 z przykładem aplikacji znalezionej w serwisie X. Proszę o bibliotekę reklam inspirowaną jej wyglądem, ale z dodatkowymi funkcjami. Chcę samodzielnie ustalać kategorie oceny, wybierać firmy lub twórców, których materiały mnie interesują, i zadawać pytania o zgromadzone reklamy. Aplikacja ma odnajdywać te, które najlepiej odpowiadają zamierzonemu celowi.
W demonstracji biblioteka zawiera ponad 400 reklam, między innymi materiały związane z Alexem Hormozim i Skool. Każda kreacja jest oceniana według przygotowanej skali: liczy się między innymi sposób przyciągania uwagi, rodzaj przekazu, jasność komunikatu i zgodność reklamy ze stroną, na którą prowadzi.
Autor wskazuje, że niski koszt modelu pozwala przeprowadzić taką analizę za niewielką kwotę. W materiale zestawia koszt oceny 400 reklam, liczony w centach, z kwotą przekraczającą 30 dolarów przy użyciu droższego modelu. Podobnie ważna jest szybkość: według niego ocena jednej reklamy trwa krócej niż sekundę. Dzięki temu można obserwować, jak biblioteka wypełnia się wynikami, i szybko ponowić analizę po zmianie kryteriów.
Teraz można po prostu zadawać pytania. Proszę o reklamy w stylu UGC, czyli materiały przypominające treści tworzone przez użytkowników. Aplikacja pokazuje pasujące przykłady. Następnie pytam, które reklamy zaczynają od zniżki. Otwieram jeden z wyników i widzę dodatkowe oznaczenia dotyczące sposobu przedstawienia oferty, formatu materiału i okresu próbnego. Można też zapytać, które reklamy prowadzą do strony niespójnej z ich przekazem.
Zamiast przeglądać całą bibliotekę, można więc szukać według pytania, które pojawia się w trakcie pracy: interesującego otwarcia, rodzaju oferty albo konkretnego pomysłu na kreację. Wyniki mają oceny, etykiety i wskazane przesłanki, więc łatwiej sprawdzić, dlaczego dana reklama została wybrana.
Taką bibliotekę dałoby się utrzymywać na bieżąco. Autor proponuje dołączenie narzędzi pobierających reklamy, na przykład przez Apify, aby nowe materiały trafiały do aplikacji i mogły być oceniane według tych samych zasad. To rozszerzenie jest pomysłem na dalszy rozwój; film nie pokazuje jego pełnego wdrożenia.
Trzeci przykład: wyszukiwanie elementów interfejsu
Ostatni przykład jest przeznaczony przede wszystkim dla projektantów i osób budujących aplikacje. Istnieją duże biblioteki gotowych elementów interfejsu, takie jak 21st.dev. Można w nich znaleźć menu boczne, ekrany logowania, tabele cen i wiele innych części strony. Trudność pojawia się wtedy, gdy wiemy, czego potrzebujemy, ale nie znamy nazwy odpowiedniego komponentu.
Pomysł jest prosty: opisuję potrzebny element zwykłymi słowami, a Jev ocenia propozycje z biblioteki. Mogę poprosić o menu boczne pasujące do mojego projektu albo o ekran logowania o określonym wyglądzie. Model ma wskazać najlepszy punkt wyjścia.
W Base44 zlecam zbudowanie wyszukiwarki komponentów interfejsu. Proszę, by aplikacja zebrała przykładowe zasoby i pozwalała odnajdywać je na podstawie opisu użytkownika. Następnie przyglądam się temu, jak działa ocena. W pokazanej wersji biblioteka liczy 255 komponentów. Każdy z nich może dostać ocenę pod kątem wymagań, funkcji i dopasowania wizualnego. Daje to około 750 wywołań modelu na jedno wyszukiwanie. Według autora wyniki wracają po jednej lub dwóch sekundach.
Tu widać różnicę między oceną znaczenia a wyszukiwaniem samego słowa. Jeśli potrzebuję tabeli cen z przełącznikiem między płatnością miesięczną i roczną, istotny jest właśnie ten przełącznik. Nazwa komponentu może nie zawierać słowa „cennik”, a mimo to element może spełniać wymaganie.
Sprawdzam aplikację. Po wpisaniu „login” dostaję listę ekranów logowania ułożonych według dopasowania. Potem zawężam opis: szukam wersji animowanej, z fioletowym akcentem i efektem wiązki światła. W wynikach pojawia się komponent odpowiadający takiemu opisowi. Można też podać bardziej rozbudowane polecenie, na przykład dotyczące strony promującej aplikację do robienia notatek z pomocą AI, i wykorzystać znalezione elementy jako początek dalszej pracy.
Dla autora ważne jest to, że podobną metodę można zastosować poza projektowaniem interfejsów. W dużym zbiorze zawsze wraca pytanie: jak opisać posiadane rzeczy, aby potem odnaleźć tę właściwą? Jeśli dane są obrazami, trzeba najpierw przygotować ich opisy — choćby z pomocą Gemini. Gdy kandydaci są już przedstawieni tekstem, Jev może ich oceniać i układać w rankingu według kolejnych zapytań.
Trzy przykłady pokazują ten sam schemat w różnych sytuacjach. Aplikacja zbiera propozycje, przygotowuje ich opisy, a model wybiera lub szereguje je według bieżącej potrzeby użytkownika. Niski koszt i krótki czas odpowiedzi mają sprawić, że można robić to wielokrotnie, również wtedy, gdy zbiór jest duży. Trzeba przy tym pamiętać, skąd pochodzą oceniane dane i jakie informacje model faktycznie otrzymuje.