Model lokalny a jakość odpowiedzi

Bochenki chleba stygnące na kracie

Modele otwarte są dziś dobre. Nie są równe najlepszym rozwiązaniom chmurowym i przy części zadań różnica ma znaczenie praktyczne.

Gdzie różnica jest niewielka

  • streszczanie i przeredagowanie tekstu,
  • klasyfikacja zgłoszeń do kategorii,
  • wyodrębnianie danych z dokumentów o stałym układzie,
  • odpowiadanie na podstawie przekazanych fragmentów,
  • tłumaczenie prostych treści.

Wspólna cecha tych zadań jest taka, że model dostaje wszystko, czego potrzebuje, i ma to tylko przetworzyć. Nie musi niczego wymyślać ani prowadzić długiego rozumowania. To właśnie zakres, w którym instalacja lokalna wypada najlepiej.

Gdzie różnica jest wyraźna

Zadania wymagające długiego rozumowania, ścisłej precyzji rachunkowej i pracy z bardzo długimi dokumentami. Tam najlepszy model chmurowy nadal wygrywa.

Dochodzi do tego stabilność wyniku. Przy zadaniu wymagającym ścisłego formatu mniejszy model częściej odbiega od wzorca, i to nie za każdym razem, tylko co jakiś czas. Taki błąd jest trudniejszy do wychwycenia niż stała pomyłka, bo ujawnia się dopiero na produkcji.

Język polski

Modele otwarte wypadają w polskim gorzej niż w angielskim, i różnice między nimi są duże. To trzeba sprawdzić samodzielnie.

Sprawdzenie oznacza własny materiał, nie przykładowe zdania: odmiana nazwisk i nazw firm, słownictwo branżowe, skróty używane w dokumentach. Który model wybrać do takiej próby, podpowiada przegląd modeli otwartych.

Zadanie wyznacza wymagania

Do klasyfikacji zgłoszeń mniejszy model lokalny wystarcza w zupełności. Płacenie za najlepszy model przy takim zadaniu to koszt bez korzyści.

Odwrotny błąd jest równie kosztowny: wymuszanie na małym modelu zadania, które go przerasta, kończy się poprawianiem wyników ręcznie. Wtedy sensowniejszy bywa układ, w którym część pracy idzie na zewnątrz — opisuje go tekst o rozwiązaniu mieszanym.

Poprawa bez zmiany modelu

Lepsze przygotowanie polecenia, przekazanie właściwych fragmentów, podział zadania na kroki. Zwykle dają więcej niż podmiana modelu na większy.

Warto też sprawdzić ustawienia samego uruchomienia oraz poziom kwantyzacji. Zdarza się, że winą za słabe odpowiedzi obciążany jest model, a przyczyną jest zbyt mocno zmniejszony zapis przy zadaniu wymagającym precyzji.

Sprawdzenie zamiast założeń

Ten sam zestaw przykładów na modelu lokalnym i chmurowym. Bywa, że różnica nie uzasadnia kosztu — i bywa odwrotnie.

Porównanie ma sens tylko przy tych samych warunkach: identyczne dokumenty, identyczne polecenie, identyczna forma oczekiwanego wyniku. Inaczej porównuje się wrażenia, a decyzja o sprzęcie zapada na ich podstawie.

Ocenę warto przy tym oprzeć na czymś sprawdzalnym, a nie na wrażeniu, że odpowiedź brzmi lepiej. Przy klasyfikacji liczy się zgodność z kategorią, przy wyodrębnianiu danych — poprawność każdego pola, przy odpowiedziach z dokumentów — czy wskazane źródło rzeczywiście zawiera to, co model napisał. Trzy takie miary wystarczają, żeby porównanie dało wynik, o który nikt się potem nie spiera.