Więcej inteligencji
na GPU.

Jakość zależy od zadania.

Nie ma jednego najlepszego modelu dla każdego zapytania. Model, który świetnie pisze kod, może być złym wyborem do wyciągania pól z polskiej faktury. Duży model rozumujący może być zbędny do klasyfikowania zgłoszenia w pomocy technicznej.

Tania odpowiedź nie jest tania, jeśli ktoś musi ją poprawiać. Chcemy, żeby wybór modelu opierał się na dowodach: jakości na poziomie zadania, koszcie, czasie odpowiedzi i ograniczeniach wdrożenia.

Używaj najmniejszego systemu, który niezawodnie wykonuje zadanie. Eskaluj, gdy zadanie wymaga więcej.

Taki jest kierunek dla Fabryka Router: od wyboru dostępnego modelu do wyboru systemu popartego zmierzonymi możliwościami.

Polski to obciążenie robocze,
a nie etykieta.

Wspieranie polskiego to coś więcej niż generowanie płynnych zdań. To rozumienie dokumentów, wykonywanie instrukcji, praca z lokalną terminologią, używanie narzędzi i wiedza, kiedy dostępne dowody nie uzasadniają odpowiedzi.

Chcemy ewaluacji, które odzwierciedlają tę pracę:

• Język polski, wiedza i rozumowanie
• Rozumienie dokumentów i ustrukturyzowana ekstrakcja
• Programowanie i używanie narzędzi
• Wyszukiwanie w długim kontekście i odpowiedzi oparte na źródłach

Zbiorczy wynik to punkt wyjścia. Liczy się to, czy model potrafi wykonać twoje zadanie.

Badania muszą zasłużyć na swoją moc obliczeniową.

Nowe pomysły powinny zaczynać się od małych, kontrolowanych eksperymentów — a nie od kosztownych zobowiązań. Nasz kierunek badawczy to drabina skalowania: testuj tanio, porównuj z punktem odniesienia i skaluj pomysły, których poprawa się utrzymuje.

Lepszy wynik na małym modelu jest powodem do zbadania sprawy. Nie jest dowodem, że ta sama metoda zadziała w większej skali.

Ten sam standard dotyczy wyboru checkpointów, destylacji, kwantyzacji i łączenia modeli. Liczą się dla nas uzyskane możliwości, koszt i niezawodność — a nie to, czy technika jest modna.

Nie każde zadanie wymaga
modelu ogólnego przeznaczenia.

Duża część przepływu pracy z AI to wąskie, powtarzalne zadania: klasyfikacja, ekstrakcja, rerankowanie, czyszczenie dokumentów i routing. Małe modele specjalistyczne mogą wykonywać te kroki wydajniej, zostawiając większe modele do części, które ich potrzebują.

Chcemy budować i dostosowywać modele wokół użytecznych zadań — a nie liczby parametrów.

Pytanie nie brzmi: „Czy ten model może zastąpić asystenta ogólnego?”. Brzmi ono: „Czy ten system może niezawodnie wykonać to obciążenie przy niższym całkowitym koszcie?”

Lepsze systemy potrzebują
odpowiedzialnych danych.

Destylacja i fine-tuning są tak godne zaufania, jak dane, na których się opierają. Naszym standardem powinny być możliwe do prześledzenia źródła, udokumentowane zgody, kontrole duplikatów, przegląd prywatności i dane ewaluacyjne oddzielone od treningowych.

Dane syntetyczne wymagają tej samej uwagi. Odpowiedź modelu nauczycielskiego to propozycja — nie odpowiedź wzorcowa.

Informacje zwrotne z produkcji również potrzebują jasnych granic. Pomiary operacyjne mogą kierować optymalizacją bez zamieniania rozmów klientów w dane treningowe. Każde wykorzystanie treści klientów do badań powinno wymagać wyraźnej zgody i określonych zasad postępowania.

Ulepszanie systemu nie może odbywać się kosztem ludzi, którzy z niego korzystają.

Publikuj dowody.
Także porażki.

Chcemy, żeby twierdzenia techniczne miały dość kontekstu, by można je było sprawdzić: model, sprzęt, konfigurację, obciążenie i metodę pomiaru.

Gdy optymalizacja poprawia przepustowość, ale pogarsza jakość, liczą się oba wyniki. Gdy eksperyment się nie udaje, to również warto udokumentować.

Publiczny dziennik badań powinien pokazywać, co próbowaliśmy, co się zmieniło i co nie zadziałało. Zaufanie powinno wynikać z powtarzalnych wyników — a nie z przymiotników.

Co istnieje.
Co będzie dalej.

To kierunek, a nie twierdzenie, że każda część jest już zbudowana.