Agentowe procesy kodowania z małymi modelami

OK.

Dzień dobry,

Nazywam się Jose, a ze mną są Ian i Zoe.

Wszyscy znamy LLM.

Używamy ich do wszystkiego: wyszukiwania przepisów, podsumowywania filmów na YouTube i kodowania.

Istnieją naprawdę duże modele LLM, takie jak modele Gemini, które potrafią robić niesamowite rzeczy, ale w tym wystąpieniu skupimy się na małych modelach językowych.

Są to również LLM, ponieważ coś, co ma 4 miliardy czegoś, nie może być małe, ale od teraz będziemy rozróżniać modele graniczne i małe modele językowe, rakietę i rower.

Omówimy małe modele niekoniecznie jako alternatywę dla modeli granicznych, ale głównie jako ich uzupełnienie.

Omówimy wszystkie zalety małych modeli językowych, zwłaszcza gdy są one otwarte, mają otwarte wagi i są dostępne do pobrania, ale najpierw przyjrzyjmy się kosztom.

Na potrzeby tej prezentacji przeprowadziłem wiele testów porównawczych. Jeden z nich obejmował zbiór danych zawierający 200 średnich i trudnych zadań, w których wykorzystano prawie 131 milionów tokenów za mniej niż 9 USD.

Użyłem do tego modelu Gemma 4, więc mogłem go po prostu pobrać i uruchomić bezpłatnie na własnym sprzęcie, ale uruchomiłem go na komercyjnej bramie, aby porównanie było uczciwe.

Ile kosztuje model graniczny?

Około 20–200 razy więcej, w zależności od buforowania tokenów i innych czynników.

Rower może nie być najszybszym środkiem transportu, ale z pewnością jest najbardziej efektywny.

To prawda.

Teraz nasuwa się oczywiste pytanie: jaka jest różnica w jakości i dokładności?

W tym konkretnym zbiorze danych Gemma 4 może rozwiązać 53% zadań.

Oznacza to 2 rzeczy.

Jeśli do wykonywania tych zadań po lewej stronie używasz modelu granicznego, może to być przesada.

Jeśli do wykonania tych zadań po prawej stronie używasz małego modelu, musisz go nakierować na rozwiązanie lub użyć większego modelu.

W tym wystąpieniu chcemy pomóc Ci lepiej wykorzystać każdy token.

Zoe wyjaśni, jak wybrać mały model, a Ian opowie o modelach Gemma, abyście zrozumieli, jak myśleć o ich możliwościach.

Następnie szybko pokażę, jak wypróbować Gemmę 4 w Android Studio, a na koniec pokażemy, jak dopasować małe modele do codziennych przepływów pracy, a także rzeczywiste testy porównawcze programowania na Androida, aby pomóc Ci zrozumieć, co te modele potrafią.

Teraz głos ma Zoe.

Dziękuję, Jose.

Używanie jednego modelu do wszystkiego jest więc trochę jak strzelanie z armaty do wróbla, prawda?

Jest to skuteczne, ale trochę nieproporcjonalne.

Myśląc o małych modelach, można je traktować jako rozszerzenie zestawu narzędzi.

Aby wiedzieć, co musisz wprowadzić do swoich przepływów pracy, musisz otworzyć zestaw narzędzi i sprawdzić, co jest dostępne, jakie są specyfikacje i do czego służą.

Aby wybrać małe modele, musisz je znać.

Typem modelu, o którym większość ludzi myśli, gdy mowa o modelu językowym, jest autoregresyjny model językowy.

Jest to model autoregresyjny, ponieważ na podstawie danych wejściowych podzielonych na tokeny wybiera najbardziej prawdopodobny następny token z listy kandydatów.

Następnie ten najbardziej prawdopodobny kolejny token, który został wybrany, wraca do danych wejściowych i proces jest kontynuowany. Dzięki temu model może generować spójne i inteligentnie brzmiące odpowiedzi, ale ma pewne ograniczenia, w tym między innymi działa liniowo.

Możemy więc pracować nieliniowo.

Model dyfuzyjny działa podobnie, ale przetwarza blok tokenów naraz.

To prawie jak szkic, który nabiera ostrości.

W tym przypadku DiffusionGemma działa na fragmentach po 256 tokenów naraz.

Zasadniczo otrzymujesz więc przepustkę, która działa na całym bloku, dzięki czemu możesz generować wyniki z mniejszym opóźnieniem.

W naszym zestawie narzędzi mamy modele, które potrafią pisać, prawda?

Nieprawidłowa odpowiedź.

Zasadniczo modele wektorów dystrybucyjnych przekształcają obiekty takie jak obraz, tekst lub dowolne inne pojęcie w wektor.

Dzięki temu możemy mapować współrzędne na przestrzeń wielowymiarową, co pozwala nam porównywać 2 rzeczy pod względem koncepcyjnym.

Jeśli na przykład hot dog jest kanapką, prawdopodobnie będą blisko siebie lub znajdą się w bliskiej przestrzeni.

Dzięki temu sprawdzenie, czy 2 pojęcia są powiązane, staje się, powiedzmy, prostym działaniem matematycznym, a nie przejściem modelu, które też jest działaniem matematycznym, ale… Ten paradygmat idzie jeszcze dalej, prawda?

Są też mniejsze, wyspecjalizowane modele, które potrafią wykonywać jedno zadanie i robią to naprawdę dobrze.

Oto kilka przykładów: mamy modele funkcji, które przekształcają język naturalny w wywołania interfejsu API, modele wizyjne, których możliwości można się domyślić po nazwie, czy klasyfikatory, które mogą oceniać dane wejściowe na podstawie określonych parametrów.

Jest z czego wybierać, prawda?

Istnieje wiele różnych typów modeli, które mają różne wymiary, rozmiary, okna kontekstu, możliwości i wykorzystanie pamięci. Gdy otworzysz zestaw narzędzi i uwzględnisz każdą możliwość, liczba opcji wzrośnie wykładniczo do tego stopnia, że każdy fan majsterkowania będzie zachwycony lub sparaliżowany koniecznością podjęcia decyzji.

Jak więc wybrać mały model?

Zacznijmy od otwarcia zestawu narzędzi z otwartymi małymi modelami, które można uruchamiać lokalnie – modelami Gemma.

Przekazuję głos Ianowi.

Dziękuję, Zoe.

Jak Jose wspomniał na początku, mały model językowy może wykonać około 50% zadań od razu po uruchomieniu.

Dlaczego warto wybrać model lokalny?

Wszystko sprowadza się do 4 kwestii.

Pierwszy z nich to prywatność.

Możesz mieć na przykład klucze interfejsu API, zastrzeżony kod lub inne elementy, które nie mogą opuścić Twojego laptopa.

Drugi to czas oczekiwania.

Gdy model zostanie załadowany do pamięci (karty graficznej lub zunifikowanej), otrzymasz odpowiedź, gdy tylko zakończy się obliczanie.

Nie ma więc czasu błądzenia do serwerów ani dodatkowych opóźnień.

Kolejny element to zerowy koszt krańcowy.

Modele są więc opłacalne, gdy możesz kontrolować, gdzie są uruchamiane.

Na przykład w przypadku uruchamiania czegoś na komputerze lokalnym może to być wykonywanie dodatkowych prób w pętli błędów.

To nic nie kosztuje i nie wiąże się z żadnymi nieoczekiwanymi opłatami za interfejs API.

Czwarty sposób to dostęp offline.

Wyobraź sobie, że możesz używać tego w samolocie, pociągu, autobusie czy metrze – w zasadzie wszędzie, gdzie model działa na Twoim urządzeniu.

To brzmi świetnie, ale przy podejmowaniu takich decyzji musimy wziąć pod uwagę 2 główne czynniki.

Pierwszy to pamięć, a drugi to szybkość.

Jeśli spojrzysz na ten diagram, zobaczysz, że 2 dolne modele, 26B i 31B, wymagają ponad 50 GB pamięci RAM wideo, aby działać w BF16, czyli 16-bitowej kwantyzacji.

Wyzwanie polega na tym, że nie zmieściłoby się to w wielu urządzeniach.

Dlatego przeprowadzamy proces zwany kwantyzacją, który zmniejsza precyzję do 4 bitów w liczbie zmiennoprzecinkowej.

Teraz jest to trochę bardziej rozsądne.

Mówimy o 14 GB i 17 GB, prawda?

Teraz zmieściłby się na przykład na Macu ze zunifikowaną pamięcią.

Problem polega na tym, że w przypadku normalnej kwantyzacji po trenowaniu podczas kompresowania wag tracisz część dokładności modelu podstawowego. Mamy jednak technikę, która pozwala temu zapobiec.

Nazywa się to trenowaniem z uwzględnieniem kwantyzacji.

Gdy to zrobimy, model zostanie wytrenowany tak, aby wiedział, że będzie działać na mniejszych rozmiarach, dzięki czemu straty będą mniejsze.

Dzięki temu wymagania dotyczące pamięci RAM zmniejszyły się o 75% i teraz model może działać na tych urządzeniach.

Idziemy o krok dalej.

Dlatego nasze podejścia do kwantyzacji mobilnej, które działają na wielu telefonach komórkowych, mogą jeszcze bardziej zmniejszyć te modele, dzięki zrozumieniu, jak działają wszystkie różne warstwy i w jakich rozmiarach mogą działać.

Mamy więc różne rodzaje kwantyzacji.

W ten sposób zmniejszamy rozmiar modelu Gemma E2B z 11,4 GB do 1,1 GB.

Teraz jest to znacznie bardziej uzasadnione w przypadku telefonów ze średniej i wyższej półki.

Kolejny czynnik to szybkość.

Gdy używasz modelu autoregresyjnego, jak wspomniała Zoe, przewidujesz kolejny zestaw tokenów.

W przypadku zadania związanego z kodowaniem wiele z tych tokenów może być dość przewidywalnych, np. koniec sygnatury metody albo nawias otwierający lub zamykający.

Możesz użyć techniki zwanej dekodowaniem spekulatywnym.

W tym celu używa mniejszego modelu do przewidywania liczby tokenów, które następnie są weryfikowane przez większy model.

W architekturze Gemma 4 jest to możliwe, ponieważ modele korzystają z tej samej pamięci podręcznej KV.

Można to traktować jako pamięć krótkotrwałą modelu.

W takim przypadku mały model generujący prognozuje 3 lub 4 tokeny z wyprzedzeniem, a większy model analizuje tę samą pamięć podręczną KV i zasadniczo weryfikuje dane wyjściowe.

Może to skutkować około 3-krotnym przyspieszeniem działania bez utraty jakości wyników modelu, ponieważ model tylko prognozuje, a następnie decyduje, czy wynik jest prawidłowy czy nie.

Wszystko zależy od zadania, które wykonujesz.

Nie sprawdza się to zbyt dobrze w przypadku kreatywnego pisania, ponieważ występuje tu większa zmienność, ale działa bardzo dobrze w przypadku przewidywalnych rzeczy, takich jak struktury JSON i kodowanie.

Jak więc ocenić jeden z tych modeli?

Najbardziej oczywistą rzeczą, jaką można zrobić, jest sprawdzenie testu porównawczego, takiego jak LiveCodeBench czy MMLU, i wyniku.

To jednak da Ci tylko ogólny obraz możliwości modelu.

Trzeba ocenić cały stos, w którym działa.

Jest to model, którego używasz, wagi i podejście do kwantyzacji, wnioskowanie środowiska wykonawczego, więc możesz używać czegoś takiego jak llama.cpp, Ollama lub LiteRT, uprząż agenta, której używasz, niezależnie od tego, czy jest to Pi, OpenCode czy Antigravity, a następnie okno kontekstu, które jest rodzajem przestrzeni dla wszystkich danych, które model ma przetwarzać.

Połączenie tych wszystkich czynników decyduje o tym, czy dany pomysł jest wykonalny.

Podam krótki przykład: przeprowadzaliśmy testy z Gemmą 4 na Android Bench i uruchamialiśmy wersję Ollama z domyślnym kontekstem 32 tys.

Odkryliśmy, że w jednym z testów, w którym szukano błędu, kompresja uprzęży agenta powodowała usunięcie tego pliku z pamięci, przez co model nie był w stanie wykonać zadania i kończyło się ono niepowodzeniem.

Dzięki zwiększeniu kontekstu z 32 tys. do 256 tys. model może zachować te informacje w pamięci i zdać ten test.

Wskaźnik sukcesu w przypadku tej konkretnej oferty pracy wzrósł dwukrotnie.

To pokazuje, że nawet jeden z tych drobnych czynników może mieć duży wpływ na to, czy dany model jest odpowiedni.

Jak więc przeprowadzić własną ocenę?

Oto 3 krótkie sugestie.

Możesz na przykład wziąć historię Git, czyli kilka udanych PR-ów, i użyć ich jako promptów dla modelu, aby zobaczyć, jak sobie z nimi poradzi.

Następnie potrzebujesz czegoś w rodzaju deterministycznego systemu oceniania, który pomoże Ci ocenić, czy dane wyjściowe modelu są prawidłowe.

Mamy 2 świetne przykłady.

Mamy kompilator i testy jednostkowe.

Niezależnie od tego, co zostanie wygenerowane, możesz to sprawdzić i dowiedzieć się, czy udało Ci się wykonać dane zadanie.

Trzecia to trajektorie logów.

Dlatego podczas uruchamiania agenta chcesz mieć możliwość śledzenia jego różnych zachowań, sprawdzania, gdzie odnosi sukcesy, a gdzie ponosi porażki. Możesz wykorzystać te informacje do oceny, jak dobrze model potrafi wchodzić w interakcje i korzystać z narzędzi.

Chcę, żebyście spróbowali zmienić sposób sformułowania pytania z „Czy ten model jest tak inteligentny jak ten duży model graniczny?”

na pytanie: „Czy to zadanie jest możliwe na tym sprzęcie z tą konkretną konfiguracją?”.

Aby to ustalić, opracowaliśmy platformę o nazwie „Daleko jeszcze?”.

Możesz też użyć AWTY.

Cała zasada tego modelu polega na tym, aby ocenić na tej osi wszystkie te różne zadania pod kątem gotowości.

Czyli sam model, używany silnik wnioskowania, uprząż i konfiguracja sprzętu.

Dzięki temu dowiesz się, czy jesteś już gotowy(-a).

Możesz na przykład sprawdzić, jak niezawodne jest dane zadanie.

Jeśli uruchomisz go 10 razy z rzędu, czy za każdym razem zrobi to samo?

Być może analizujesz opóźnienie.

Może potrzebujesz odpowiedzi w czasie rzeczywistym.

Jakie są Twoje progi, jeśli chodzi o szybkość wykonywania zadania?

Możesz też sprawdzić wymagania dotyczące pamięci RAM.

Nie chodzi więc tylko o pamięć RAM, którą ma urządzenie, ale o pamięć RAM, którą urządzenie… o pamięć, którą można wydzielić, oraz o inne aplikacje i narzędzia, które również trzeba będzie uruchomić na tym sprzęcie.

Czy może wykorzystać 50% pamięci RAM, czy tylko 10%?

Otrzymasz ostateczny wynik gotowości.

Jeśli jest zielony, oznacza to, że konfiguracja jest gotowa.

Jeśli jest pomarańczowy, żółty lub czerwony, może być konieczna zmiana konfiguracji.

Może potrzebujesz szybszego akceleratora, aby zmniejszyć opóźnienie, a może większego modelu o większych możliwościach.

Dlatego sugeruję, aby się temu przyjrzeć.

Obecnie mamy wersję testową i chętnie poznamy Twoją opinię na temat przydatności tego narzędzia.

Zoe opowie później o tym, jak skonfigurowaliśmy niektóre oceny, ale teraz przekażę głos Jose, który pokaże Wam, jak szybko zacząć korzystać z Gemmy 4.

Dziękuję, Ian.

Najszybszym sposobem na wypróbowanie Gemmy 4 jest obecnie Android Studio.

Pokażę Ci, jak to zrobić.

Przełączmy się na laptopa.

Nareszcie.

Jeśli więc przejdę na stronę dostawców modeli w ustawieniach i wybiorę Gemmę, zobaczę, jak duży jest każdy model.

Muszę tylko pobrać modele na dysk twardy.

Otwiera on lub uruchamia serwer llama.cpp, który jest od razu prawidłowo skonfigurowany.

Możesz też użyć własnego serwera llama.cpp, Ollama lub LM Studio.

W tym celu wystarczy dodać lokalnego dostawcę.

Warto też używać małych modeli za pośrednictwem dostawcy zdalnego.

Możesz dodać tutaj model, o ile jest zgodny z OpenAI lub Anthropic.

Dobrze, zobaczmy.

Model w Android Studio wybiera się oczywiście za pomocą tego menu.

Mam wybrany model Gemma 4 26B i mogę zapytać: „Co to jest ViewModel?”.

OK.

Dlatego bardzo ważne jest, aby pamiętać, że za każdym razem, gdy zmieniasz model, cała rozmowa jest wysyłana do nowego modelu od początku.

Jeśli więc wygenerujesz naprawdę długą rozmowę z modelem i chcesz przełączyć się na nowy, prawdopodobnie musisz rozpocząć nową rozmowę, skrócić ją lub zrobić coś innego.

Teraz wróćmy do slajdów i Zoe, aby dowiedzieć się więcej o różnych przepływach pracy, które można uruchamiać przy użyciu małych modeli.

Dziękuję, Jose, i dziękuję, Ian, za omówienie modeli Gemma i tego, czy już osiągnęliśmy ten etap.

Wiemy już, jakie są typy modeli i jakie mają specyfikacje. Teraz musimy zrozumieć, jakie zadania można im zlecać.

Pierwszy rodzaj zadań, które prawdopodobnie już wykonujesz, to procesy kodowania, takie jak debugowanie czy rozwiązywanie problemów, lub coś, co, jak sądzę, wszyscy, a przynajmniej ja, będziemy z głębokim sarkazmem wspominać jako coś, co robiliśmy ręcznie, czyli zwiększanie zakresu testów.

Zgadza się?

To są rzeczy, które, jak sądzę, wszyscy już robią, nawet nie zdając sobie z tego sprawy.

Chcę jednak zachęcić Cię do myślenia o czymś więcej.

Biorąc pod uwagę, że małe modele mogą mieć otwarte wagi i być uruchamiane lokalnie, co może pomóc Ci zaoszczędzić czas?

Zgadza się?

Mówimy o nieużywaniu rakiety, więc dlaczego używamy do tego mózgu?

Jeśli jednak wyjdziemy poza te ramy, co jeszcze mogą robić małe modele?

Jakie procesy robocze można im powierzyć, aby ułatwić sobie życie i zyskać więcej czasu na rzeczy, które chcesz robić?

So, for example, something like making sure that your documentation is always up to date with the changes that you made, or something like ensuring that you have automatic regression tests that are a part of a pre-commit hook, or even making sure that the context that may your agent is receiving as part of your workflows is optimized for it, and it works even faster.

To tylko kilka przykładów.

And, at the end of the day, the sky's the limit to some extent, or architecture is the limit, and there are a lot of things that you could think of how to implement it.

Ale mając specyfikacje, narzędzia i przepływy pracy, nadal nie wiesz, od czego zacząć?

Właśnie po to są testy porównawcze.

Jak powiedział Ian, ogólna tabela wyników, zwłaszcza w przypadku Pythona, nie powie Ci zbyt wiele o tym, czy mały model będzie przydatny w przypadku przepływów pracy na Androidzie.

Podobnie jak wiertło do płyt gipsowo-kartonowych nie powie Ci wiele o wiertle do betonu.

Warto jednak zainwestować we własne oceny.

Warto zainwestować w testowanie własnej architektury, ale zanim to zrobisz, możesz nie chcieć przeznaczać na to wszystkich zasobów.

Wymaga to czasu, pieniędzy i wysiłku, więc zapoznanie się z publicznie dostępnymi testami porównawczymi może dać Ci pewne wyobrażenie i pozwolić na stworzenie krótkiej listy, zanim zdecydujesz się zainwestować we własne oceny.

Podczas oceny testu porównawczego należy zwrócić uwagę na 3 kwestie.

To trochę meta, ale pierwsza rzecz to rodzaj zadania, które wykonuje ten model.

Jak bardzo jest szczegółowa.

Czy przypomina to zadanie, które mu zlecisz?

Drugi to zakres zadania.

Czy jest to pisanie dokumentacji, rozwiązywanie problemów z PR, czy coś, co wygląda na rodzaj pracy, którą wykonujesz?

I wreszcie, czy złożoność systemu jest podobna do złożoności, którą zamierzasz wprowadzić?

I tutaj widzimy, dlaczego test porównawczy Pythona nie będzie zbyt reprezentatywny dla Androida.

Dlatego stworzyliśmy Android Bench, czyli test porównawczy, który obejmuje ekosystem Androida i pracę na Androidzie.

Pierwsza wersja zawiera 100 zadań na Androida o rozmiarze PR. Możesz ją uruchomić już dziś za pomocą Harbor, aby sprawdzić dowolną kombinację agenta, modelu i umiejętności.

Wprowadzamy wersję 2.0 z bardziej złożonymi, długotrwałymi zadaniami, aby zrozumieć, jakie są możliwości modeli granicznych w zakresie wykonywania zadań takich jak te, które im dziś zlecasz.

Teraz Jose pokaże Ci wyniki, które uzyskaliśmy, oraz kilka sposobów na optymalizację pracy z małymi modelami.

OK, dziękuję, Zoe.

Przyjrzyjmy się zadaniom, które może rozwiązać mały model, i tym, z którymi zaczyna mieć problemy.

Zdefiniujmy arbitralnie 4 kategorie zadań: małe, średnie, duże i długofalowe.

Zadania długofalowe to zadania, których wykonanie może zająć człowiekowi dni lub tygodnie.

Na przykład migracja, duża refaktoryzacja. I uwaga, spoiler: nie można tego zrobić za pomocą małego modelu.

Przynajmniej nie za jednym razem.

Porozmawiamy o tym później.

OK, małe zadania.

Są to zadania, które wymagają odczytu i zapisu 1 lub 2 plików i nie wymagają dużej wiedzy.

Na przykład małe modele są całkiem dobre w Compose, przynajmniej w podstawach Compose.

Na przykład: między elementami musi być 8 dp, używaj motywu zamiast kolorów zakodowanych na stałe lub wyodrębniaj ciągi znaków.

Mały model łatwo sobie z nimi poradzi.

To zadanie dotyczy bardziej zaawansowanego tematu, ale nadal jest łatwe.

@Composable
 fun AnimatedDrawer() {
   val offsetX = remember { Animatable(0f) }
-  Box(modifier = Modifier.offset(x = offsetX.value.dp)) {}
+  Box(modifier = Modifier.graphicsLayer { translationX = offsetX.value }) {}
 }

W tym przypadku trudność polega na zakresie, a nie na wiedzy.

Prompt informuje nas, który element kompozycyjny należy zoptymalizować i co jest z nim nie tak: jest rekomponowany w każdej klatce.

Dzięki temu zadanie jest dość łatwe nawet dla małego modelu, takiego jak Gemma 4.

W tym przypadku zajęło to 3 minuty i wymagało zmiany tylko jednej linijki kodu.

OK.

Myślę, że mamy już dobre wyobrażenie o tym, czym jest mały model.

Przyjrzyjmy się mi- przepraszam, małemu zadaniu.

Przyjrzyjmy się zadaniom średnim.

Małe modele powinny być w stanie wykonać większość z nich.

W tym zadaniu w żądaniu z aplikacji Pocket Casts brakuje klienta użytkownika, a w logice ponawiania występuje błąd.

To zadanie jest nieco trudniejsze, ponieważ po pierwsze prosimy o 2 rzeczy jednocześnie, a po drugie nie ma żadnych wskazówek, gdzie te elementy znajdują się w bazie kodu.

Ale przeszło.

Zajęło to 10 minut.

Zmodyfikował 3 pliki.

A przy okazji: kosztowało to 6 centów przez OpenRouter.

Teraz przyjrzyjmy się zadaniu, które nie powiodło się w tym samym zbiorze danych.

To jest przykład aplikacji Now in Android z dość obszernym raportem lub promptem, ale nie wspomina on o nazwie klasy ani pliku, więc agent musi poświęcić więcej wysiłku na zrozumienie architektury aplikacji, warstwy danych, mechanizmu synchronizacji itp. W tym konkretnym przypadku nie udało się wykonać zadania.

Wszystko zostało zaimplementowane prawie prawidłowo, ale założono, że wartość początkowej synchronizacji będzie wynosić -1, podczas gdy w rzeczywistości wynosi 0.

val isInitialSync = currentVersion == -1

val isInitialSync = currentVersion == 0

To wszystko.

Ten błąd zostałby wykryty, gdyby agent uruchomił istniejące testy jednostkowe.

Pokazuje to, że mniejsze modele zwykle zatrzymują się nieco wcześniej niż modele graniczne.

Poprosiliśmy pracownika o rozwiązanie problemu, a nie o jego weryfikację.

Może więc powinniśmy zmodyfikować zadanie, aby zawierało etap weryfikacji.

O tym również za chwilę porozmawiamy.

Porozmawiajmy o dużych zadaniach.

Zgodnie z tą definicją około połowa dużych zadań zawsze kończy się powodzeniem.

Niektóre z tych, które się nie powiodły, są zbyt długie i złożone dla małego modelu. Nie można z tym nic zrobić.

Ale są też takie, w których po przeanalizowaniu tego, co się faktycznie wydarzyło, zdajesz sobie sprawę, że model był w 90% poprawny.

Wybierzmy jeden z nich.

Wybrałem ten, ponieważ jest kruchy.

Test kończy się powodzeniem w około połowie przypadków.

Uważam, że to granica możliwości małego modelu.

A przynajmniej model z kwietnia.

Chodzi o analizowanie nieprawidłowo sformatowanych adresów URL w bibliotece Coil.

Jak widać, opis PR jest dość obszerny, co jest świetne, ale brakuje w nim jednego wymagania.

Przyjrzyjmy się temu pokrótce.

Wszystkie uruchomienia sprawdzały typowe kodowania adresów URL i błędy, ale tylko niektóre, czyli połowa z nich, dodały testy pod kątem nieprawidłowo zakodowanych znaków, więc ten element testowania jest tam.

Te, które nie zostały, nie przeszły oceny.

Wszystkie wyniki są niemal idealne, ale to kolejny dowód na to, że małe modele nie zawsze robią ten dodatkowy krok.

Wykonują instrukcje, ale nie próbują Ci zaimponować, jak robią to modele graniczne.

Wiesz, jak można teraz ustawić wysiłek agenta?

Pamiętaj, że w przypadku małego modelu jest ona ustawiona na zbyt niską wartość.

Zdefiniujmy więc duże zadania jako te, które mogą być wykonywane przez małe modele w około 50% przypadków. Taki wynik Gemma 4 31B może osiągnąć w przypadku zbioru danych Android Bench v1, o którym Zoe mówiła wcześniej.

Zanim więc przejdziemy do zadań długofalowych, czy możemy zrobić coś, aby pomóc małym modelom w ich realizacji?

Oczywiście, a te rzeczy nie wymagają żadnego wysiłku.

Po pierwsze, jeśli używasz modelu takiego jak Gemma 4 lokalnie, jak wspomniał Ian, upewnij się, że jest on prawidłowo skonfigurowany.

Jeśli na przykład używasz Ollama do obsługi Gemmy 4, domyślnie okno kontekstu ma 32 000 tokenów, chociaż w rzeczywistości obsługuje 8 razy więcej.

Oczywiście, jeśli używasz Gemmy 4 w Android Studio, nie musisz jej konfigurować.

Domyślnie jest on prawidłowo skonfigurowany.

W naszym zestawie ocen włączenie pełnego kontekstu spowodowało wzrost wyników z 26% do 53%.

Następnie użyj interfejsu wiersza poleceń Androida, czyli narzędzia interfejsu wiersza poleceń Androida, zwłaszcza do wyszukiwania dokumentacji.

Nie zawsze jest to konieczne, ponieważ modele dobrze radzą sobie z podstawowymi zadaniami, ale gdy używasz nowego lub niszowego interfejsu API, dokumentacja jest kluczowa.

Z naszego doświadczenia wynika, że jest to znacznie lepsze rozwiązanie niż korzystanie z narzędzi do wyszukiwania w internecie.

Następnie dodaj wskazówki dotyczące weryfikacji.

Rozmawialiśmy o tym.

Poinformuj model, jak przeprowadzać testy, jakie typy testów są dostępne, jak zarządzać emulatorami itp. Możesz to zrobić w pliku AGENTS.md, dzięki czemu instrukcje będą dostępne dla wszystkich agentów. To i tak dobra praktyka.

Powinieneś go mieć.

Uważaj też na bardzo długie pliki AGENTS.md, ponieważ jeśli wypróbujesz różne agenty, zobaczysz, że niektóre z nich mają ogromne instrukcje systemowe i opisy narzędzi, które wydają się obniżać wydajność małych modeli.

Próbowaliśmy przeprowadzić te testy porównawcze z OpenCode, ale wyniki były znacznie gorsze niż w przypadku pi, prawdopodobnie dlatego, że używa on większych opisów narzędzi i promptów systemowych.

Następnie dodaj umiejętności, ale też je usuń.

Małe modele mogą potrzebować podpowiedzi, gdy używają nowych i niszowych interfejsów API, ale lepiej nie wypełniać ich kontekstu np. ogólnymi umiejętnościami Compose.

A co z zadaniami długofalowymi?

Są to zadania, które obejmują dziesiątki plików, wymagają poważnych decyzji architektonicznych i są zwykle obsługiwane przez model rozumowania, który tworzy plan i uruchamia rój podagentów wykonujących różne zadania.

Przykłady długofalowych zadań to migracja całej aplikacji z XML do Compose, tworzenie złożonej aplikacji od podstaw lub konwertowanie aplikacji na wiele platform na natywne aplikacje na Androida.

Jeśli spojrzymy na wyniki z Android Bench V2, który koncentruje się wyłącznie na zadaniach długofalowych, zobaczymy, że modele graniczne uzyskują wyniki od 3 do 40%.

W przypadku małych modeli można więc śmiało powiedzieć, że to nie ich liga.

Jednak przekierowanie wstępnej analizy do modelu granicznego, a następnie przekazanie prostszych zadań mniejszym modelom byłoby znacznie bardziej efektywne pod względem tokenów i środków.

Zobaczmy, jak to zrobić.

Wróć do Zoe.

Dziękuję, Jose.

Zanim jednak przejdziemy do kaskady i pokażę Ci kilka sposobów lub zanim szczegółowo omówimy ten temat, chcę cofnąć się o krok i pokazać Ci inne sposoby, w jakie orkiestracja różnych modeli może Ci pomóc.

Dzięki temu nie musisz się martwić, że zostaniesz zablokowany.

Niezależnie od tego, czy dostawca ma awarię, czy osiągniesz limit żądań do interfejsu API, czy jesteś w samolocie lub pociągu, jak mówił Ian, możesz skonfigurować model zastępczy i sprawić, że niezależnie od tego, czy jesteś online, czy lokalnie, możesz kontynuować pracę, jeśli coś się stanie.

Inną rzeczą, którą można zrobić dzięki orkiestracji, jest uzyskiwanie lepszych odpowiedzi.

Na przykład mały model może działać samodzielnie i w razie potrzeby zwracać się do doradcy o pomoc.

Możesz też skonfigurować radę, w której różne typy modeli lub różne modele wykonują jednocześnie to samo zadanie, a następnie ocenić różne odpowiedzi oraz wpływ wag i odchyleń każdego modelu na wynik.

Możesz też użyć osobnego modelu, powiedzmy, do testów.

To coś w rodzaju oceny przez rówieśników.

Można to zobaczyć na tym przykładzie.

I wreszcie, orkiestracja może pomóc Ci zwiększyć opłacalność dzięki kaskadzie.

Możesz skonfigurować go ręcznie, aby ustawić jeden model do planowania, inny do wykonywania, a jeszcze inny do testów.

Można to zrobić na kilka sposobów, np. w chmurze lub konfigurując serwer proxy LiteLLM, aby zrobić to lokalnie.

Możesz też użyć klasyfikatora, aby automatycznie kierować zapytanie do odpowiedniego typu modelu na podstawie żądania. To jest właśnie idea serwera proxy, o której wspomniał Ian, ale w formie automatycznej.

Podsumowując, wróćmy do pytania, które Jose zadał na początku: jaka jest różnica w jakości i dokładności między małymi modelami a modelami granicznymi?

Odpowiedź, jak w przypadku wielu zagadnień z zakresu informatyki, brzmi: to zależy.

Jednak chciałbym podkreślić, że jest to coś, co można zaprojektować.

Możesz to zmienić w zależności od tego, jak skonfigurujesz i jak będziesz używać tych elementów.

Pierwszym krokiem jest wybór odpowiedniego narzędzia.

Istnieje kilka rodzajów narzędzi.

Poznaj je, odkryj je, prawda?

Następnie dowiedz się, do jakich zadań się nadają, a nawet jakie zadania mogą wykonywać.

Po drugie, dostosuj zakres, który model otrzymuje, aby wykonać zadanie.

Na przykład instrukcje dotyczące zadania, podanie odpowiedniego kontekstu i tylko odpowiedniego kontekstu oraz sposoby sprawdzania własnej pracy.

Następnie musisz przetestować całą konfigurację, a nie tylko sam model, ponieważ ma to znaczenie i może się okazać, że uzyskane wyniki można poprawić, jeśli skonfigurujesz model z inną konfiguracją elementów.

Ostatecznie musisz skonfigurować lub utworzyć własne oceny.

Możesz też połączyć rower i rakietę, aby nie musieć wybierać między nimi i wydawać pieniądze w efektywny sposób.

Ale co najważniejsze, możesz dalej odkrywać, budować i dobrze się bawić.

Możesz zacząć już dziś, tworząc listę modeli za pomocą Android Bench i dostępnych tam wyników lub zaczynając od Gemma 4 w Android Studio.

Dziękuję bardzo.