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.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Kryteria oceny

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.

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ą.

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

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.