Wybór dostawcy modelu AI — kryteria oceny i jak nie uzależnić się od jednej firmy
Rynek modeli językowych zmienia się szybciej niż jakikolwiek inny obszar technologii, z którego korzystają firmy. Co kilka miesięcy pojawiają się nowe wersje, zmieniają się ceny, możliwości i warunki korzystania. Firma, która buduje rozwiązanie na jednym modelu, stoi przed dwoma pytaniami: którego dostawcę wybrać dziś i jak zbudować system, żeby jutro móc zmienić zdanie bez przepisywania wszystkiego. Wybór oparty na rankingach z internetu albo na tym, z którego czatu korzysta prezes, rzadko jest najlepszy.
Krótka odpowiedź: dostawcę modelu wybiera się na podstawie wyników na własnym zestawie testowym, a nie ogólnych rankingów, oraz oceny warunków ochrony danych, lokalizacji przetwarzania, stabilności i dostępności usługi, polityki zmian modeli, jakości w języku polskim i łącznych nakładów przy przewidywanym wolumenie. Żeby ograniczyć uzależnienie, system powinien mieć warstwę pośrednią oddzielającą logikę aplikacji od konkretnego dostawcy.
Najlepszy model w rankingu nie musi być najlepszy dla Twojego zadania. Mniejszy model często wystarcza, a działa szybciej.
Kryteria oceny
| Kryterium | Pytania do sprawdzenia |
|---|---|
| Jakość w zadaniu | Jaki wynik osiąga model na naszym zestawie testowym? Jak radzi sobie z przypadkami trudnymi? |
| Język polski | Czy odpowiedzi są poprawne gramatycznie i naturalne? Czy model rozumie polską terminologię branżową i prawną? |
| Ochrona danych | Czy dane są wykorzystywane do trenowania? Jak długo są przechowywane? Czy jest umowa powierzenia? |
| Lokalizacja | Czy można przetwarzać dane w Europie? Jakie są transfery poza obszar gospodarczy? |
| Bezpieczeństwo | Jakie certyfikaty i audyty posiada dostawca? Jak zarządza dostępem? |
| Dostępność | Jaka jest deklarowana dostępność usługi? Jak wyglądała historia awarii? |
| Limity | Ile zapytań na minutę? Czy limity wystarczą w szczycie? |
| Polityka zmian | Jak długo stare wersje modeli są dostępne? Z jakim wyprzedzeniem dostawca informuje o wycofaniu? |
| Możliwości | Długość kontekstu, analiza obrazów, ustrukturyzowane odpowiedzi, wywoływanie narzędzi |
| Szybkość | Czas do pierwszej odpowiedzi i całkowity czas przy typowym zadaniu |
| Nakłady | Łączne opłaty przy przewidywanym wolumenie, z uwzględnieniem wszystkich wywołań |
| Wsparcie | Dokumentacja, kontakt techniczny, warunki dla firm |
Test na własnych danych
Ogólne rankingi modeli mierzą umiejętności na standardowych zadaniach, najczęściej po angielsku. Twoje zadanie — klasyfikacja zgłoszeń od polskich klientów, odczyt faktur, odpowiedzi na podstawie regulaminu firmy — może wyglądać zupełnie inaczej.
- Zestaw kilkudziesięciu do kilkuset przypadków z prawdziwych danych, z oczekiwanymi wynikami.
- Te same instrukcje dla wszystkich porównywanych modeli, z niewielkimi dostosowaniami, jeśli dokumentacja je zaleca.
- Kilka uruchomień dla sprawdzenia powtarzalności.
- Pomiar jakości według kategorii, nie tylko ogólny wynik.
- Pomiar czasu i zużycia dla każdego modelu.
- Ocena przypadków granicznych — odmowy, niepewność, błędne dane wejściowe.
Budowę takiego zestawu opisujemy w tekście o testowaniu systemów AI.
Uwaga praktyczna: porównuj także mniejsze i tańsze modele tych samych dostawców. W wielu zadaniach — klasyfikacji, wyciąganiu danych, prostych odpowiedziach — różnica jakości względem największych modeli jest niewielka, a czas odpowiedzi i zużycie znacznie mniejsze. Często najlepsze rozwiązanie łączy mały model do prostych kroków z dużym do trudnych.
Ochrona danych i umowy
Warunki dotyczące danych różnią się między dostawcami, a nawet między produktami tego samego dostawcy — wersja konsumencka czatu ma zwykle inne zasady niż interfejs programistyczny dla firm.
- Wykorzystanie danych do trenowania — przy firmowym dostępie przez API zwykle wyłączone domyślnie, ale trzeba to potwierdzić w umowie.
- Okres przechowywania zapytań i odpowiedzi oraz możliwość jego skrócenia.
- Umowa powierzenia przetwarzania danych zgodna z RODO.
- Lista podprzetwarzających i lokalizacje przetwarzania.
- Mechanizmy transferu danych poza Europejski Obszar Gospodarczy.
- Obowiązki dostawcy wynikające z europejskich przepisów o sztucznej inteligencji dla modeli ogólnego przeznaczenia.
Więcej o tym, jakie dane można bezpiecznie przesyłać, piszemy w tekście o danych firmowych a modelu w chmurze, a o obowiązkach przy wdrożeniach — w materiale o AI a RODO.
Dostęp bezpośredni czy przez chmurę
Wiele modeli jest dostępnych na kilka sposobów, co wpływa na warunki, lokalizację i integrację z istniejącą infrastrukturą.
| Sposób dostępu | Zalety | Ograniczenia |
|---|---|---|
| API bezpośrednio od twórcy modelu | Najszybszy dostęp do nowych wersji i funkcji | Osobna umowa i rozliczenia |
| Przez dużego dostawcę chmury | Wybór regionu, istniejące umowy, zintegrowane zabezpieczenia | Nowe funkcje mogą pojawiać się później |
| Otwarty model na własnej infrastrukturze | Pełna kontrola, brak zależności od dostawcy | Utrzymanie po stronie firmy, zwykle niższa jakość w złożonych zadaniach |
| Pośrednik łączący wielu dostawców | Jeden interfejs do wielu modeli | Dodatkowa strona w przetwarzaniu danych |
Porównanie modeli w chmurze i uruchamianych lokalnie opisujemy w tekście o modelu lokalnym czy w chmurze.
Ryzyko uzależnienia
Uzależnienie od jednego dostawcy ma kilka wymiarów. Każdy z nich można ograniczyć, ale wymaga to decyzji na etapie projektowania.
- Zmiany cen — rozwiązanie opłacalne dziś może stać się drogie po zmianie cennika.
- Wycofanie modelu — wersja, na której przetestowano system, przestaje być dostępna.
- Zmiana zachowania — nowa wersja odpowiada inaczej, co wymaga poprawek instrukcji.
- Awarie — niedostępność jedynego dostawcy zatrzymuje proces.
- Zmiany warunków — polityki użycia, ograniczenia regionalne, zasady dotyczące danych.
- Funkcje specyficzne — rozwiązanie oparte na unikalnej funkcji jednego dostawcy trudno przenieść.
Architektura ograniczająca uzależnienie
- Warstwa pośrednia — aplikacja komunikuje się z modelem przez własny interfejs, a nie bezpośrednio przez bibliotekę dostawcy rozsianą po całym kodzie.
- Instrukcje przechowywane osobno, z wersjami, możliwe do dostosowania dla różnych modeli.
- Zestaw testowy pozwalający w ciągu godzin ocenić, jak system działa na innym modelu.
- Standardowe mechanizmy — ustrukturyzowane odpowiedzi i wywoływanie narzędzi w formie, którą obsługuje większość dostawców.
- Model zapasowy — skonfigurowany drugi dostawca, na który system przełącza się przy awarii, przynajmniej dla najważniejszych funkcji.
- Własne dane — bazy wiedzy, indeksy i dzienniki przechowywane u siebie, a nie wyłącznie w usługach dostawcy.
Taka architektura nie wymaga dużego dodatkowego wysiłku, jeśli zostanie zaplanowana od początku. Dodawanie jej do działającego systemu jest znacznie trudniejsze.
Proces decyzji
| Krok | Działanie |
|---|---|
| 1. Wymagania | Rodzaj zadania, dane, wolumen, wymagania prawne i dotyczące lokalizacji |
| 2. Wstępna lista | Dostawcy spełniający wymagania dotyczące danych i lokalizacji |
| 3. Test | Porównanie kilku modeli, w tym mniejszych, na zestawie testowym |
| 4. Warunki | Umowy, polityka zmian, limity, wsparcie |
| 5. Wybór | Model główny i zapasowy, decyzja udokumentowana z wynikami testów |
| 6. Przegląd | Powtórzenie testów co kilka miesięcy lub przy nowych wersjach |
Rozliczanie wydatków na modele i ich kontrolę opisujemy w tekście o kosztach modeli językowych.
Przykład z praktyki
Firma logistyczna planuje automatyczną klasyfikację i ekstrakcję danych z wiadomości od klientów — zleceń transportowych, reklamacji i zapytań o status przesyłek. Zespół początkowo zakłada wybór najbardziej rozpoznawalnego modelu. Przed decyzją przygotowuje jednak zestaw dwustu realnych wiadomości w języku polskim, niemieckim i angielskim, z oczekiwanymi kategoriami i danymi do wyciągnięcia.
Test obejmuje cztery modele od trzech dostawców, w tym dwa mniejsze. Wyniki pokazują, że w klasyfikacji różnice między modelami są niewielkie, a mniejsze modele odpowiadają kilkukrotnie szybciej. W wyciąganiu danych z nietypowych, długich wiadomości z załącznikami wyraźnie lepiej radzą sobie większe modele. Zespół sprawdza też warunki: jeden z dostawców nie oferuje przetwarzania w Europie dla wybranego produktu, co przy danych klientów jest dla firmy wymaganiem.
Ostateczna architektura wykorzystuje mniejszy model do klasyfikacji wszystkich wiadomości i większy do ekstrakcji danych tylko tam, gdzie jest to potrzebne. Komunikacja z modelami odbywa się przez własną warstwę pośrednią, a jako zapasowy skonfigurowany jest model innego dostawcy, sprawdzony na tym samym zestawie. Kilka miesięcy później, gdy jeden z dostawców zapowiada wycofanie używanej wersji modelu, zespół w ciągu jednego dnia uruchamia zestaw testowy na nowej wersji i przeprowadza zmianę bez przerwy w działaniu.
Najczęstsze błędy przy wyborze
Najczęściej firmy wybierają model na podstawie rankingów lub doświadczeń z czatem konsumenckim, pomijają test na własnych danych w języku polskim, nie sprawdzają warunków ochrony danych dla konkretnego produktu dostawcy i budują aplikację tak, że zmiana modelu wymaga przepisania dużej części kodu. Każdy z tych błędów jest łatwy do uniknięcia na etapie projektu, a kosztowny do naprawienia po wdrożeniu.
Warto więc potraktować wybór dostawcy jako decyzję, do której będzie się wracać, a nie jednorazowy zakup, i od początku budować system z myślą o tej zmienności.
Podsumowanie
Wybór dostawcy modelu AI powinien opierać się na wynikach testu na własnych danych, ocenie warunków ochrony danych i lokalizacji, stabilności usługi, polityki zmian, jakości w języku polskim i łącznych nakładów przy realnym wolumenie. Rynek zmienia się szybko, dlatego równie ważna jak sam wybór jest architektura, która pozwala zmienić dostawcę: warstwa pośrednia, instrukcje z wersjami, zestaw testowy i model zapasowy.
Zanim podpiszesz umowę, przygotuj pięćdziesiąt realnych przypadków i porównaj na nich trzy-cztery modele, w tym mniejsze. Wyniki często zaskakują i pozwalają podjąć decyzję na podstawie danych, a nie popularności. Więcej o budowie rozwiązań AI dla firm przeczytasz na stronie wdrożenie agenta AI.
Najczęstsze pytania
Na podstawie wyników na własnym zestawie testowym zbudowanym z prawdziwych przypadków, a nie ogólnych rankingów. Oprócz jakości warto ocenić ochronę danych, lokalizację przetwarzania, dostępność usługi, politykę zmian modeli, jakość w języku polskim, szybkość i łączne nakłady przy przewidywanym wolumenie.
Nie. W wielu zadaniach, takich jak klasyfikacja, wyciąganie danych czy proste odpowiedzi, mniejsze modele osiągają zbliżoną jakość przy krótszym czasie odpowiedzi i mniejszym zużyciu. Często najlepiej sprawdza się połączenie małego modelu do prostych kroków z dużym do trudnych.
Na wykorzystanie danych do trenowania, okres przechowywania zapytań, umowę powierzenia przetwarzania danych, listę podprzetwarzających, lokalizację i transfery danych, dostępność usługi, limity oraz zasady wycofywania starszych wersji modeli.
Budując warstwę pośrednią między aplikacją a modelem, przechowując instrukcje osobno z wersjami, utrzymując zestaw testowy do szybkiej oceny innych modeli, korzystając ze standardowych mechanizmów, konfigurując model zapasowy i przechowując bazy wiedzy oraz dzienniki u siebie.
Co kilka miesięcy oraz przy pojawieniu się nowych wersji modeli, zmianach cen lub warunków. Dzięki zestawowi testowemu porównanie zajmuje zwykle kilka godzin, a pozwala skorzystać z lepszych lub bardziej opłacalnych modeli bez ryzyka pogorszenia jakości.
Bezpłatna wycena Twojego projektu
Opisz w kilku zdaniach, co chcesz zbudować — stronę, aplikację czy sklep. Odpowiadamy w ciągu 24 godzin roboczych konkretną propozycją zakresu i harmonogramu. Konsultacja i wycena są bezpłatne, bez zobowiązań.