Mały model poprawnie klasyfikuje większość maili, a duży dodaje długie uzasadnienia i koszt. Na jednej trudnej umowie mały zgaduje termin. Nie potrzebujesz jednego modelu do wszystkiego. Potrzebujesz reguły, kiedy prosty wystarcza i kiedy warto zapłacić za trudniejszy przypadek.
Rozmiar i cena nie są pełną miarą jakości. Zadanie, źródło i format zmieniają wynik. Test powinien obejmować prosty wariant, trudny i koszt odbioru.
Podziel zadania według ryzyka
Zapisz, które przypadki są powtarzalne i odwracalne, a które wymagają głębokiej interpretacji lub mają duży skutek. Klasyfikacja tematu różni się od analizy umowy. Nie porównuj ich w jednym rankingu.
Mały model może wystarczać do formatowania, prostych kategorii i streszczeń z ograniczeniami. Większy może być potrzebny przy konflikcie źródeł i złożonych instrukcjach. To hipoteza do testu, nie reguła.
Nie wybieraj większego tylko dla prestiżu. Koszt odbioru i czasu może przeważać poprawę. Przy prostym procesie prosty model bywa lepszy operacyjnie.
Zbuduj zestaw według trudności
Przygotuj typowe, nietypowe i krytyczne przypadki. Nie ograniczaj się do dokumentów, na których obecny proces działa. Mały model powinien pokazać, gdzie przestaje wystarczać.
Dodaj przypadki z brakiem źródła i konfliktem. Model nie powinien zgadywać niezależnie od rozmiaru. Jeżeli oba zawodzą, problem może być w procesie, nie w skali.
Zachowaj ten sam format i rubrykę. Przy porównaniu pomocny jest artykuł o modelach na własnych danych. Wybór dotyczy procesu, nie samej odpowiedzi.
Mierz jakość przy błędach
Porównaj fakty, źródło, format, instrukcje i skutek. Nie ograniczaj się do oceny stylu. Mały model może pisać prościej i naturalniej, a duży dodawać watę.
Zapisz błędy krytyczne osobno. Jeżeli większy zgaduje mniej przy trudnych dokumentach, może być wart dodatkowego kosztu. Przy prostych przypadkach różnica może nie mieć znaczenia.
Przy długich odpowiedziach oceń, czy dodatkowy tekst jest potrzebny. Większa objętość nie jest jakością. Model powinien odpowiadać na pytanie, nie tworzyć nowych tematów.
Koszt na zaakceptowany wynik
Porównaj cenę wejścia, wyjścia, ponowień i odbioru. Tańszy model może wymagać więcej poprawek i zwiększać koszt pracy. Droższy może być lepszy tylko przy części zadań.
Dodaj koszt integracji i utrzymania. Routing dwóch modeli zwiększa testy i konfigurację. Przy małym wolumenie może nie być opłacalny. Czasem jeden wystarcza z ograniczeniem zakresu.
Przy pełnym rachunku stosuj metody z artykułu o całkowitym koszcie AI. Cena za token jest tylko jednym składnikiem.
Czas i doświadczenie użytkownika
Mały model może odpowiadać szybciej, co pomaga przy interakcji. Większy może być wolniejszy, ale dawać lepszy wynik przy trudnej analizie. Mierz cały czas z odbiorem, nie tylko odpowiedź API.
Nie akceptuj długiego czekania dla prostego zadania bez wartości. Użytkownik może preferować szybki szkic. Przy dokumencie ryzyka czas jest mniej ważny niż poprawność.
Przy fallbacku testuj również opóźnienie przełączenia. Zapasowy model może być tańszy, ale powolny lub niedostępny w tym samym okresie.
Kiedy mały model wystarcza
Wybierz go przy stabilnym formacie, prostych regułach, niskim skutku błędu i dobrych wynikach testów. Dodaj walidację i przypadki zatrzymania. Mały model nadal wymaga procesu.
Jeżeli odbiór jest krótki i błędy drobne, większy koszt może nie dawać wartości. Nie przenoś jednak wyniku na nowy typ dokumentu bez testu.
Przy zadaniach kreatywnych mały model może być wystarczający do wariantów, ale oceń różnorodność i zgodność z briefem. Nie zwiększaj rozmiaru dla samej nowości.
Kiedy wybrać większy model
Wybierz przy złożonym rozumowaniu, konflikcie źródeł, długim kontekście i dużym skutku błędu, jeżeli test potwierdza poprawę. Nie zakładaj, że sam rozmiar rozwiązuje niejasność.
Przy danych wrażliwych oceń kanał przed modelem. Większy dostawca nie jest automatycznie lepszy dla prywatności. Warunki dyskwalifikują niezależnie od jakości.
Jeżeli większy model zgaduje pewniej, może być gorszy. Odbiór powinien obejmować źródło i brak, a nie tylko liczbę poprawnych odpowiedzi.
Routing jako decyzja procesowa
Zdefiniuj prostą regułę: typ dokumentu, pole, format, konflikt lub błąd pierwszego etapu. Nie przekazuj decyzji o routingu innemu modelowi bez kontroli. Reguła powinna być zrozumiała i testowana.
Możesz zacząć od reguły kodu lub mniejszego modelu i przekazywać wyjątki dalej. Inny porządek albo jedna ścieżka też mogą być właściwe. Wybierz je po porównaniu jakości, kosztu, czasu i skutku błędu.
Przy niepewności zachowaj eskalację do człowieka. Routing nie powinien wybierać złej odpowiedzi tylko dlatego, że musi wybrać model.
Test routingu osobno od modeli
Przygotuj przypadki, które powinny zostać przy małym, przejść do dużego i zatrzymać się. Oceń, czy reguła przypisuje właściwie. Zwycięzca modelu nie wystarcza przy złym routingu.
Dodaj nowe typy dokumentów i braki. Proces powinien zachowywać się ograniczająco przy nieznanym przypadku. Nie przypisuj automatycznie do najtańszego.
Po zmianie progu porównaj jakość i koszt. Zbyt wiele trudnych przypadków przy dużym może nie być potrzebne, zbyt wiele przy małym zwiększa odbiór.
Przykład: katalog produktów
W hipotetycznym przykładzie przy standardowych polach mały model poprawnie mapuje atrybuty. Przy wariantach z brakami większy lepiej opisuje konflikt, ale czasem dopowiada fakty. Reguła wymaga źródła przy każdym.
Proces wybiera mały dla standardu, większy dla nietypowych, a przy konflikcie zatrzymuje zapis. Nie zastępuje człowieka przy tożsamości produktu.
Przy katalogu pomocny jest przewodnik o porządkowaniu danych AI. Model jest częścią decyzji, a nie jedyną kontrolą.
Kiedy jeden model jest lepszy niż routing
Jeżeli przypadki są podobne i jeden wariant przechodzi wszystkie, routing dodaje niepotrzebną złożoność. Wybierz prostszy proces z ograniczeniem zakresu. Nie twórz dwóch ścieżek dla pokazania zaawansowania.
Przy małym wolumenie koszt testów i utrzymania może przeważać oszczędność. Zapisz decyzję i warunek zmiany. Routing ma sens przy rzeczywistej różnicy.
Może warto zostać przy większym dla uproszczenia procesu, jeżeli koszt jest akceptowalny. Wybór nie musi być minimalny cenowo, powinien być uzasadniony.
Kiedy problem nie jest w rozmiarze
Jeżeli model gubi źródło, zwiększ kontekst lub popraw mapę, a nie tylko rozmiar. Zły format wymaga schematu, nie większego tekstu. Brak reguły bezpieczeństwa wymaga kodu.
Przy błędzie języka dodaj przykłady i słownik. Model nie zastępuje źródła terminologii. Przewodnik o słowniku AI dla zespołu pokazuje tę warstwę.
Jeżeli oba modele zawodzą, zatrzymaj automatyzację i oceń proces. Większy nie jest rozwiązaniem każdego błędu.
Jak zapisać wybór modelu i regułę
Zapisz zadania, przypadki, jakość, koszt, czas, odbiór i regułę. Dodaj warunek zatrzymania i przeglądu. Nie przedstawiaj jednego rankingu dla wszystkiego.
Rekomendacja powinna mówić, kiedy mały wystarcza, kiedy duży pomaga i kiedy proces się zatrzymuje. To jest decyzja operacyjna, nie tylko wybór dostawcy.
Mały model przy dużym kontekście
Duży dokument może wymagać nie tylko lepszego rozumowania, ale także innego przygotowania źródeł. Nie wybieraj większego modelu tylko dla większego okna. Zacznij od ograniczenia i struktury kontekstu. To często poprawia wynik i koszt.
Przy konflikcie źródeł nie kompresuj ich w jedną spokojną wersję. Zachowaj rozbieżność i właściciela. Mały model może działać poprawnie przy małym, jasnym pakiecie, a większy przy pełnym dokumencie wymagać osobnego testu.
Przy wyborze kontekstu pomocny jest przewodnik o małym pakiecie AI. Model nie zastępuje redakcji danych.
Kiedy większy model nie jest właściwy dla procesu
Jeżeli odbiór wymaga stałej pracy eksperta albo odpowiedź jest zbyt długa dla użytkownika, większy model może pogarszać proces. Nie akceptuj kosztu bez skutku. Może prostszy wariant daje wystarczający wynik.
Przy wrażliwych danych oceń, czy nowy kanał jest dozwolony. Nie przenoś źródeł do większego dostawcy tylko dla jakości. Ogranicz zakres lub wybierz inny proces.
Jeżeli zespół nie umie odebrać złożonego wyniku, ogranicz format. Większa analiza bez odbioru nie jest wartością. Prosty wynik z regułą może być bezpieczniejszy.
Przegląd po zmianie wolumenu
Przy wzroście zadań porównaj nowy koszt i czas. Mały model może przestawać wystarczać przy nowym typie, a duży przy dużym wolumenie może kosztować za dużo. Decyzja powinna reagować na pracę, nie na stałą architekturę.
Zapisz próg zmiany i właściciela. Nie czekaj na awarię lub duży rachunek. Nowe przypadki dodaj do zestawu i porównaj z poprzednim wynikiem.
Przy odbiorze decyzji poproś właściciela procesu o ocenę kilku wyników z małego i dużego bez nazw modeli. To ogranicza preferencję marki i ceny. Dopiero potem pokaż koszt i warunki dostawcy.
Jeżeli wyniki są podobne, zapisz remis i wybierz prostszy proces. Nie dodawaj nowych kryteriów tylko dla uzasadnienia większego modelu. Decyzja może zależeć od kosztu wyjścia i utrzymania.
Przy zakończeniu routingu przetestuj każdy wariant osobno i sprawdź, czy stare przypadki nie trafiają do niewłaściwego kanału. Wycofanie powinno obejmować konfigurację i dane, nie tylko nazwę modelu.
Przy kolejnej wersji modelu zachowaj wspólne przypadki kontrolne. Nie przenoś starej decyzji bez nowego testu. Dostawca może zmieniać zachowanie bez zmiany nazwy procesu.
Przy zmianie właściciela przekaż rubrykę i regułę routingu. Nowa osoba powinna wiedzieć, kiedy mały jest standardem, kiedy duży jest wymagany i kiedy proces się zatrzymuje. Nie przenoś samej nazwy modelu.
Jeżeli nowy typ zadania nie ma testów, zacznij od trybu propozycji. Nie przypisuj go do małego dla oszczędności ani do dużego dla pozoru bezpieczeństwa. Decyzja wymaga dowodu.
Przy zakończeniu zachowaj wyniki i przypadki do kolejnej oceny. Proces i modele zmieniają się, więc decyzja powinna mieć termin i właściciela przeglądu.
Przy kolejnych decyzjach porównaj ten sam wolumen i typy. Mały model może wyglądać taniej przy łatwym okresie, a duży lepiej przy trudnym. Nie przypisuj różnicy tylko skali.
Zapisz, kiedy wybór przestaje być opłacalny. Może proces wymaga ograniczenia lub prostszej alternatywy zamiast nowego modelu.
Przy odbiorze końcowym sprawdź przypadki zatrzymane. One pokazują, czy routing wie również, kiedy nie odpowiadać. Sam wybór modelu nie jest pełnym procesem.
Zachowaj wersję decyzji i koszt odbioru. Nowy właściciel powinien ocenić wynik na podstawie pracy, a nie samej nazwy modelu.
Aeneia Audit pomaga porównać proces i koszt. Przy pilotażu pomocne są kryteria oceny Aeneia Signal.
Zachowaj wyniki obu modeli dla tego samego zestawu zadań wraz z kosztami całego procesu, w tym odbioru. Jeśli mniejszy wariant zawodzi przy ważnym wyjątku, sprawdź możliwość przekazania tylko tych przypadków do mocniejszego modelu. Do tego wyboru warto wrócić po zmianie cen, wolumenu lub wymagań jakościowych.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
