Przez mniej więcej miesiąc próbowałem zastąpić zamknięte modele w naszym pipelinie wytwarzania oprogramowania modelami z otwartymi wagami.
Ten miesiąc mogłem przeznaczyć na sam produkt. Zaryzykowałem, bo każda wyspecjalizowana rola w OwlMeans wywołuje model językowy, a zmiana w tym miejscu dociera do całego procesu wytwarzania.
Nasz ówczesny preset łączył modele Anthropic i OpenAI. Próbowałem modeli GLM, Kimi, DeepSeek i Qwen u dostawców, którzy je hostują. Chciałem się dowiedzieć, czy inny preset niezawodnie wykona tę samą pracę.
Ten czerwcowy eksperyment nie jest benchmarkiem. Nie dowodzi, że OwlMeans ma przewagę kosztową.
Nasz pipeline dzieli produkt na małe kawałki. Rola pracuje nad user story, decyzją projektową albo zmianą w kodzie o wyraźnie wyznaczonych granicach. Dostaje kontekst potrzebny do tego zadania, a nie polecenie, żeby wymyślić całą aplikację.
Myślałem, że dzięki takiej strukturze zmiana modeli może okazać się prosta. Gdyby zadanie było wystarczająco wąskie, może model miałby mniej okazji, żeby je źle zrozumieć.
Tę inżynierską hipotezę mogłem sprawdzić we własnym systemie. Dla założyciela, który działa w pojedynkę, było to też kuszące zboczenie z kursu. Ulepszanie maszynerii wydawało się przydatne w każdym przyszłym projekcie, więc łatwo było usprawiedliwić kolejny dzień dostrajania.
Musiałem patrzeć na cały przebieg, nie tylko na aplikację, która z niego wyszła.
Puste odpowiedzi
Pierwszym problemem okazało się rozumowanie.
Niektóre modele zużywały dostępny budżet tokenów wyjściowych na wewnętrzne rozumowanie i nie zwracały żadnej użytecznej treści. Rola programisty kończyła zapytanie, ale następny etap nie miał czego zastosować.
Próbowałem wyłączyć rozumowanie ustawieniem, którego dostawca nie zawsze przestrzegał. Potem nałożyłem jawne limity na role, których to dotyczyło, i dostrajałem je model po modelu.
Wymagało to więcej uwagi, niż sugerowałby sam przełącznik presetów. Rola planisty i rola programisty potrzebowały czego innego. Ustawienie, które działało w jednym modelu, nie było regułą, którą mogłem bezpiecznie przenieść na pozostałe.
Następnym problemem był format odpowiedzi. Nasze etapy przekazują sobie ustrukturyzowane wyniki. Odpowiedź, która mnie wydaje się sensowna, może mimo to nie spełniać schematu, którego oczekuje następny krok.
Tam, gdzie model nie potrafił niezawodnie zwrócić oczekiwanej struktury, dodałem ścieżkę przez wywołanie narzędzia. Zmieniłem też sposób, w jaki kod przechodził przez pipeline: agent pracował na istotnych fragmentach i łatkach, zamiast raz po raz obrabiać całe pliki.
Te zmiany weszły do systemu, który musiałem utrzymywać. Eksperyment był już czymś więcej niż wybraniem modelu z listy.
Dostawca pośrodku
Nazwa modelu nie określała całego środowiska wykonawczego.
Od hosta zależało, które funkcje są dostępne i jak zachowują się zapytania. Testowałem różnych dostawców, a w końcu użyłem w eksperymentalnym presecie routingu i przełączania awaryjnego z OpenRoutera.
Dokumentacja OpenRoutera o routingu między dostawcami objaśnia ustawienia, którymi można wybierać i filtrować hosty. Mój pipeline zależał od konkretnego kształtu odpowiedzi, więc te ustawienia miały znaczenie. Całą trasę, z której korzystałem, i tak musiałem przetestować sam.
Wreszcie mogłem przełączać się między presetami i przepuszczać przez nie ten sam projekt. Tyle że za przełącznikiem stały już wtedy limity rozumowania, obsługa odpowiedzi, wydobywanie kodu i wybór dostawców.
Aplikacja na końcu
W tych przebiegach powstałe aplikacje były do siebie z grubsza podobne. Zauważyłem różnice w CSS i sporadyczne dodatki do interfejsu, o które nie prosiłem.
Widziałem też, jak zdolne modele dodają ozdobniki do małego zadania, choć chciałem dosłownej implementacji. Była to obserwacja dotycząca moich zadań i mojej konfiguracji. Do ogólnego rankingu modeli byłaby to kiepska podstawa.
Jako operator systemu musiałem radzić sobie z różnicami, których mniej widać. Nieudane ustrukturyzowane wyniki wymagały kolejnej próby, a łatkami, które nie dawały się nałożyć, musiałem się zająć sam. Nawet zwykły krok potrafił stanąć przez niezgodność po stronie dostawcy.
Na końcowym zrzucie ekranu tej pracy nie widać.
Wymieniając modele, brałem na siebie więcej pracy wewnątrz pipeline’u.
Miałem nieformalne porównanie z własnych pomiarów. Nie ufałem mu na tyle, żeby zrobić z niego ogólne twierdzenie o wydajności.
Modele były różnie dostrojone. Zachowanie dostawcy było częścią wyniku. Ponowienia i kroki naprawcze sprawiały, że droga do wyniku liczyła się tak samo jak końcowy artefakt.
Rzetelne porównanie wymagałoby zdefiniowanego zadania, tych samych kryteriów odbioru, spójnych pomiarów i jawnie raportowanych niepowodzeń. Moje przebiegi dały mi notatki inżynierskie.
Dlatego w tej wersji nie ma już dawnego tytułu z liczbą. Publiczny adres zostawiłem bez zmian, żeby istniejące linki dalej działały.
Nadal musiałem zdecydować, na co poświęcić czas. Mogłem dalej dostrajać eksperymentalny preset albo wrócić do reszty produktu. Kolejne pomiary pomogłyby tylko wtedy, gdyby dawały odpowiedź potrzebną do decyzji, którą naprawdę musiałem podjąć.
Miesiąc dostrajania
Zostawiłem sobie działającą ścieżkę do testowania różnych modeli. Znalazłem też kilka założeń, które kryły się wewnątrz pipeline’u: jak rola rozumuje, jak zwraca wynik, ile kodu źródłowego dostaje i co się dzieje, gdy jej dostawca zawiedzie.
To przydatna wiedza dla silnika, który buduję. Nie dowodzi jednak, że inny założyciel powinien powtórzyć ten sam eksperyment.
Gdybym robił to jeszcze raz, wcześniej określiłbym warunki stopu. Zanim poświęciłbym kolejny tydzień na zmienianie ustawień, zdecydowałbym, które powtarzające się awarie muszę zrozumieć.
Za ten miesiąc kupiłem sobie lepsze zrozumienie własnego systemu. Ten sam miesiąc odebrałem jednak reszcie OwlMeans. Obie rzeczy trzeba ująć w rachunku.
Poprawiono 15 października 2026 r. Tekst zachowuje opis czerwcowego eksperymentu. Zachowanie modeli i dostawców od tamtej pory wciąż się zmienia; powyższe obserwacje opisują tamte przebiegi.