Modeli otwartych jest kilkadziesiąt i co kwartał pojawiają się nowe. Wybór warto oprzeć na kilku cechach, nie na nazwie.
Modele małe uruchamiane na zwykłym komputerze, średnie wymagające dobrej karty i duże potrzebujące sprzętu serwerowego. Różnica jakości między nimi jest wyraźna, ale mniejsza, niż sugeruje różnica rozmiaru.
Z tego wynika praktyczna wskazówka: zaczynać od mniejszego. Jeśli mniejszy wystarcza do zadania, całe wdrożenie robi się tańsze i prostsze w utrzymaniu. Dopiero gdy widać braki, warto sięgać wyżej — i wtedy sprawdzić, czy kwantyzacja nie pozwoli zmieścić większego modelu na tym samym sprzęcie.
Te grupy nie zastępują się nawzajem. Model do wyszukiwania znaczeniowego nie napisze odpowiedzi, a model ogólny nie zbuduje sensownego indeksu bazy wiedzy. W typowym wdrożeniu pracują obok siebie dwa różne, każdy w swojej roli.
Dobór zaczyna się więc od zadania, nie od przeglądu dostępnych nazw. Jeśli firma chce wyciągać dane z dokumentów do dalszego przetwarzania, potrzebuje modelu, który trzyma się zadanej struktury. Jeśli chce pomocy przy redagowaniu korespondencji, liczy się co innego. Jeden model do wszystkiego zwykle wypada przeciętnie w każdym z tych zastosowań.
Rozstrzygające kryterium przy zastosowaniach krajowych. Różnice między modelami są tu większe niż w angielskim, a zestawienia publikowane przez autorów rzadko go obejmują.
Sprawdzać trzeba więc samodzielnie i na własnym materiale: odmiana nazwisk i nazw firm, skróty branżowe, opisy towarów, formy grzecznościowe w korespondencji. Model, który świetnie radzi sobie z tekstem ogólnym, potrafi się gubić na słownictwie z konkretnej branży.
Wersje przystosowane do konkretnych zadań przez społeczność. Bywają lepsze od pierwowzoru w wąskim zastosowaniu i gorsze we wszystkim pozostałym.
Przy takich wersjach warto sprawdzić dwie rzeczy: kto je przygotował i na jakich warunkach udostępnia. Kwestię formalną porządkują licencje modeli otwartych — nie każdy model opisany jako otwarty można bez zastrzeżeń wykorzystać komercyjnie.
Model wybrany dziś za pół roku będzie miał lepszego następcę. Rozwiązanie warto budować tak, żeby podmiana nie wymagała przebudowy.
W praktyce oznacza to oddzielenie modelu od reszty: konfiguracja w jednym miejscu, polecenia i szablony osobno, zestaw przykładów testowych trzymany razem z projektem. Przy takim układzie zmiana modelu to kwestia ponownego przejścia testu, a nie nowego wdrożenia.
Dwa lub trzy modele na tym samym zestawie przykładów. Różnice bywają zaskakujące i nie zawsze na korzyść większego.
Zestaw przykładów powinien obejmować także przypadki trudne: dokumenty nietypowe, niepełne, z błędami. To one pokazują, gdzie leży granica, i to od nich zależy późniejsza jakość odpowiedzi w codziennej pracy.