Jak testować modele AI

Krótka odpowiedź: Aby dobrze ocenić modele AI, zacznij od zdefiniowania, jak „dobrze” wygląda z punktu widzenia rzeczywistego użytkownika i podejmowanej decyzji. Następnie stwórz powtarzalne oceny z reprezentatywnymi danymi, ścisłą kontrolą wycieków i wieloma metrykami. Dodaj obciążenia, błędy i kontrole bezpieczeństwa, a za każdym razem, gdy coś się zmieni (dane, monity, zasady), ponownie uruchom system i kontynuuj monitorowanie po uruchomieniu.

Najważniejsze wnioski:

Kryteria sukcesu : przed wyborem metryk zdefiniuj użytkowników, decyzje, ograniczenia i najgorsze możliwe awarie.

Powtarzalność : Zbuduj narzędzie ewaluacyjne, które będzie ponownie uruchamiać porównywalne testy po każdej zmianie.

Higiena danych : utrzymuj stabilne podziały, zapobiegaj duplikatom i blokuj wycieki danych na wczesnym etapie.

Sprawdzanie zaufania : solidność testów warunków skrajnych, wycinki uczciwości i zachowania bezpieczeństwa LLM z jasnymi rubrykami.

Dyscyplina cyklu życia : wdrażanie etapowe, monitorowanie odchyleń i incydentów oraz dokumentowanie znanych luk.

Artykuły, które mogą Ci się spodobać po przeczytaniu tego:

🔗 Czym jest etyka sztucznej inteligencji
Poznaj zasady odpowiedzialnego projektowania, użytkowania i zarządzania sztuczną inteligencją.

🔗 Czym jest stronniczość sztucznej inteligencji?
Dowiedz się, w jaki sposób stronnicze dane wypaczają decyzje i wyniki sztucznej inteligencji.

🔗 Czym jest skalowalność AI
Poznaj skalowanie systemów AI pod kątem wydajności, kosztów i niezawodności.

🔗 Czym jest sztuczna inteligencja?
Przejrzysty przegląd sztucznej inteligencji, jej rodzajów i zastosowań w świecie rzeczywistym.

1) Zacznij od mało atrakcyjnej definicji „dobrego”

Zanim zaczniesz analizować dane, zanim zaczniesz tworzyć pulpity nawigacyjne i zanim zaczniesz testować swoje wyniki, zastanów się, jak wygląda sukces.

Wyjaśniać:

Użytkownik: wewnętrzny analityk, klient, lekarz, kierowca, zmęczony agent wsparcia o godzinie 16:00…
Decyzja: zatwierdzenie pożyczki, zgłoszenie oszustwa, zaproponowanie treści, podsumowanie notatek
Najważniejsze porażki:
- Wyniki fałszywie dodatnie (irytujące) i fałszywie ujemne (niebezpieczne)
Ograniczenia: opóźnienie, koszt na żądanie, zasady prywatności, wymagania dotyczące możliwości wyjaśnienia, dostępność

To ten moment, w którym zespoły zaczynają optymalizować swoje działania pod kątem „ładnych wskaźników” zamiast „znaczących rezultatów”. Zdarza się to często. Naprawdę… często.

Dobrym sposobem na zachowanie świadomości ryzyka (a nie opieranie się na wibracjach) jest opracowanie testów wokół wiarygodności i zarządzania ryzykiem cyklu życia, tak jak robi to NIST w ramach AI Risk Management Framework (AI RMF 1.0) [1].

2) Co sprawia, że „jak testować modele AI” jest dobrą wersją?

Solidne podejście do testowania ma kilka niepodważalnych zasad:

Dane reprezentatywne (nie tylko czyste dane laboratoryjne)
Wyczyść pęknięcia i zapobiegaj przeciekaniu (więcej na ten temat za chwilę)
Linie bazowe (proste modele, które należy pokonać – estymatory pozorne istnieją z jakiegoś powodu [4])
Wiele wskaźników (ponieważ jedna liczba kłamie ci prosto w twarz, grzecznie i uprzejmie)
Testy wytrzymałościowe (przypadki skrajne, nietypowe dane wejściowe, scenariusze antagonistyczne)
Pętle przeglądu przez człowieka (szczególnie w przypadku modeli generatywnych)
Monitorowanie po uruchomieniu (ponieważ świat się zmienia, rurociągi pękają, a użytkownicy są… kreatywni [1])

Również: dobrym podejściem jest dokumentowanie tego, co sprawdziłeś, czego nie sprawdziłeś i co cię niepokoi. Ta sekcja „czego się obawiam” wydaje się niezręczna – i to właśnie tam zaczyna się budować zaufanie.

Dwa wzorce dokumentacji, które pomagają zespołom zachować szczerość:

Karty modelowe (do czego służy model, jak został oceniony, gdzie zawodzi) [2]
Arkusze danych dla zestawów danych (czym są dane, jak zostały zebrane, do czego powinny/nie powinny być wykorzystywane) [3]

3) Rzeczywistość narzędziowa: czego ludzie używają w praktyce 🧰

Narzędzia są opcjonalne. Dobre nawyki ewaluacyjne nie.

Jeśli zależy Ci na pragmatycznym podejściu, większość zespołów kończy z trzema grupami:

Śledzenie eksperymentów (uruchomienia, konfiguracje, artefakty)
Zestaw narzędzi ewaluacyjnych (powtarzalne testy offline + zestawy regresyjne)
Monitorowanie (sygnały dryfu, wskaźniki wydajności, alerty o incydentach)

Przykłady, które często można spotkać w praktyce (nie chodzi o rekomendacje, ale o zmiany funkcji/cen): MLflow, Weights & Biases, Great Expectations, Evidently, Deepchecks, OpenAI Evals, TruLens, LangSmith.

Jeśli wybierzesz tylko jeden pomysł z tej sekcji: zbuduj powtarzalną uprząż ewaluacyjną . Chodzi o „naciśnij przycisk → uzyskaj porównywalne wyniki”, a nie „uruchom ponownie notatnik i módl się”.

4) Zbuduj odpowiedni zestaw testowy (i zapobiegnij wyciekom danych) 🚧

Zaskakująco duża liczba „niesamowitych” modelek oszukuje nieumyślnie.

Dla standardowego ML

Kilka mało atrakcyjnych zasad, które ratują kariery:

Utrzymuj szkolenia/walidacji/testowania (i zapisz logikę podziału)
Zapobiegaj powstawaniu duplikatów w różnych częściach (ten sam użytkownik, ten sam dokument, ten sam produkt, niemal duplikaty)
Uważaj na wycieki funkcji (informacje z przyszłości przedostające się do „bieżących” funkcji)
Używaj wartości bazowych (estymatorów pozornych), żeby nie świętować pokonania… niczego [4]

Definicja wycieku (wersja skrócona): wszystko w procesie szkolenia/ewaluacji, co daje modelowi dostęp do informacji, których nie miałby w momencie podejmowania decyzji. Może być oczywiste („etykieta przyszłości”) lub subtelne („koszyk znacznika czasu po zdarzeniu”).

Dla LLM i modeli generatywnych

Budujesz system szybkich i skutecznych działań , a nie tylko „model”.

Utwórz złoty zestaw podpowiedzi (mały, wysokiej jakości, stabilny)
Dodaj ostatnie prawdziwe próbki (anonimizowane i chroniące prywatność)
Zachowaj pakiet skrajnych przypadków : literówek, slangu, niestandardowego formatowania, pustych pól, wielojęzycznych niespodzianek 🌍

Praktyka, którą widziałem nie raz: zespół wysyła produkt z „wysokim” wynikiem offline, a obsługa klienta stwierdza: „Super. Zdecydowanie brakuje jednego zdania, które ma znaczenie”. Rozwiązaniem nie był „większy model”. Chodziło o lepsze monity testowe , bardziej przejrzyste rubryki i zestaw narzędzi regresyjnych, który karał dokładnie ten tryb awarii. Proste. Skuteczne.

5) Ocena offline: wskaźniki, które coś znaczą 📏

Metryki są w porządku. Monokultura metryczna nie.

Klasyfikacja (spam, oszustwo, zamiar, triaż)

Liczy się coś więcej niż tylko dokładność.

Precyzja, odwołanie, F1
Dostrajanie progów (domyślny próg rzadko jest „poprawny” w stosunku do kosztów) [4]
Macierze pomyłek dla każdego segmentu (region, typ urządzenia, kohorta użytkowników)

Regresja (prognozowanie, ustalanie cen, punktacja)

MAE / RMSE (wybierz w zależności od tego, jak chcesz karać błędy)
Kontrole o charakterze kalibracyjnym, gdy wyniki są wykorzystywane jako „wyniki” (czy wyniki są zgodne z rzeczywistością?)

Systemy rankingowe/rekomendacyjne

NDCG, MAP, MRR
Wycinek według typu zapytania (głowa i ogon)

Wizja komputerowa

mAP, IoU
Wydajność na klasę (rzadkie klasy to takie, w których modele Cię zawstydzają)

Modele generatywne (LLM)

To tutaj ludzie zaczynają… filozofować 😵💫

Praktyczne opcje, które sprawdzają się w prawdziwych zespołach:

Ocena człowieka (najlepszy sygnał, najwolniejsza pętla)
Preferencje parowe / wskaźnik wygranych (A kontra B jest łatwiejsze niż punktacja bezwzględna)
Zautomatyzowane metryki tekstu (przydatne w przypadku niektórych zadań, mylące w przypadku innych)
Kontrole oparte na zadaniach: „Czy wyodrębniono właściwe pola?”, „Czy przestrzegano zasad?”, „Czy cytowano źródła, gdy było to wymagane?”

Jeśli potrzebny jest ustrukturyzowany punkt odniesienia obejmujący wiele wskaźników i scenariuszy, HELM jest dobrym punktem odniesienia: wyraźnie przesuwa ocenę poza dokładność w stronę takich kwestii, jak kalibracja, solidność, stronniczość/toksyczność i kompromisy dotyczące wydajności [5].

Mała dygresja: automatyczne metryki jakości pisania czasami przypominają ocenianie kanapki poprzez jej ważenie. To nic takiego, ale… no weź 🥪

6) Testowanie wytrzymałości: trochę się spoć 🥵🧪

Jeśli twój model działa tylko na prostych danych wejściowych, to w zasadzie jest szklanym wazonem. Ładnym, delikatnym, drogim.

Test:

Szum: literówki, brakujące wartości, niestandardowy kod Unicode, błędy formatowania
Zmiana dystrybucji: nowe kategorie produktów, nowy slang, nowe czujniki
Wartości ekstremalne: liczby poza zakresem, ogromne ładunki, puste ciągi znaków
Dane wejściowe „wrogie”, które nie wyglądają jak zestaw treningowy, ale wyglądają jak dane użytkowników

W przypadku studiów LLM należy uwzględnić:

Próby natychmiastowego wstrzyknięcia (instrukcje ukryte w treści użytkownika)
Wzory „Ignoruj poprzednie instrukcje”
Przypadki skrajne związane z używaniem narzędzi (błędne adresy URL, przekroczenia limitu czasu, częściowe dane wyjściowe)

Solidność to jedna z tych cech wiarygodności, która brzmi abstrakcyjnie, dopóki nie zdarzy się jakiś incydent. Wtedy staje się… bardzo namacalna [1].

7) Stronniczość, uczciwość i dla kogo to działa ⚖️

Model może być ogólnie „dokładny”, a jednocześnie konsekwentnie gorszy dla określonych grup. To nie jest drobny błąd. To problem produktu i zaufania.

Kroki praktyczne:

Oceń wydajność według istotnych segmentów (odpowiednich pod względem prawnym/etycznym do pomiaru)
Porównaj wskaźniki błędów i kalibrację w różnych grupach
Przetestuj funkcje proxy (kod pocztowy, typ urządzenia, język), które mogą kodować wrażliwe cechy

Jeśli nigdzie tego nie dokumentujesz, w zasadzie prosisz siebie z przyszłości o debugowanie kryzysu zaufania bez mapy. Karty modeli to dobre miejsce do tego [2], a ramy NIST dotyczące wiarygodności dają solidną listę kontrolną tego, co „dobre” powinno obejmować [1].

8) Testy bezpieczeństwa (szczególnie dla studentów prawa) 🛡️

Jeśli Twój model potrafi generować treści, testujesz coś więcej niż tylko dokładność. Testujesz zachowanie.

Uwzględnij testy dla:

Niedozwolone generowanie treści (naruszenia zasad)
Wyciek danych osobowych (czy ujawnia tajemnice?)
Halucynacje w domenach wysokiego ryzyka
Nadmierna odmowa (model odmawia normalnych próśb)
Wyniki toksyczności i nękania
Próby eksfiltracji danych poprzez natychmiastowe wstrzyknięcie

Ugruntowane podejście to: definiowanie reguł polityki → tworzenie monitów testowych → ocenianie wyników za pomocą kontroli ludzkich i automatycznych → uruchamianie za każdym razem, gdy coś się zmieni. To właśnie ta część „za każdym razem” jest kluczowa.

Wpisuje się to idealnie w podejście do ryzyka cyklu życia: kontroluj, mapuj kontekst, mierz, zarządzaj, powtarzaj [1].

9) Testowanie online: etapowe wdrażanie (gdzie prawda leży u podstaw) 🚀

Testy offline są konieczne. Ekspozycja online to moment, w którym rzeczywistość ujawnia się w zabłoconych butach.

Nie musisz być wymyślny. Wystarczy, że będziesz zdyscyplinowany:

Uruchom w trybie cienia (model działa, nie ma wpływu na użytkowników)
Stopniowe wdrażanie (najpierw mały ruch, a następnie rozszerzanie, jeśli ruch jest stabilny)
Śledź wyniki i incydenty (skargi, eskalacje, naruszenia zasad)

Nawet jeśli nie możesz uzyskać natychmiastowych etykiet, możesz monitorować sygnały proxy i stan operacyjny (opóźnienia, wskaźniki awarii, koszty). Najważniejsze: chcesz mieć kontrolowany sposób wykrywania awarii, zanim zrobi to cała Twoja baza użytkowników [1].

10) Monitorowanie po wdrożeniu: dryf, rozpad i cicha awaria 📉👀

Model, który testowałeś, nie jest tym, z którym ostatecznie będziesz żyć. Dane się zmieniają. Użytkownicy się zmieniają. Świat się zmienia. Rurociąg psuje się o 2 w nocy. Wiesz, jak to jest…

Monitor:

Dryf danych wejściowych (zmiany schematu, braki, przesunięcia rozkładu)
Dryft wyjściowy (przesunięcia równowagi klas, przesunięcia wyników)
Pełnomocnicy wydajności (ponieważ opóźnienia etykiet są rzeczywiste)
Sygnały zwrotne (niepochlebne opinie, ponowne edycje, eskalacje)
Regresje na poziomie segmentów (cisi zabójcy)

I ustaw progi alarmowe, które nie będą zbyt nerwowe. Monitor, który ciągle piszczy, jest ignorowany – jak alarm samochodowy w mieście.

Ta pętla „monitoruj + ulepszaj w czasie” nie jest opcjonalna, jeśli zależy Ci na wiarygodności [1].

11) Praktyczny przepływ pracy, który możesz skopiować 🧩

Oto prosta pętla, która jest skalowalna:

Zdefiniuj tryby sukcesu i awarii (uwzględniając koszty/opóźnienia/bezpieczeństwo) [1]
Utwórz zestawy danych:
- złoty zestaw
- pakiet krawędziowy
- ostatnie prawdziwe próbki (zabezpieczone prywatnością)
Wybierz metryki:
- metryki zadań (F1, MAE, wskaźnik wygranych) [4][5]
- wskaźniki bezpieczeństwa (wskaźnik powodzenia polityki) [1][5]
- metryki operacyjne (opóźnienie, koszt)
Zbuduj zestaw ewaluacyjny (działający przy każdej zmianie modelu/monitu) [4][5]
Dodaj testy obciążeniowe + testy o charakterze przeciwstawnym [1][5]
Recenzja próbki przez człowieka (szczególnie w przypadku wyników LLM) [5]
Wysyłka poprzez wdrożenie w trybie shadow + etapowe [1]
Monitorowanie + alarmowanie + ponowne szkolenie z dyscypliną [1]
Wyniki dokumentu w formie opisu w formie karty modelowej [2][3]

Szkolenie jest atrakcyjne. Testowanie przynosi dochód.

12) Uwagi końcowe + krótkie podsumowanie 🧠✨

Jeśli chcesz zapamiętać tylko kilka rzeczy na temat testowania modeli sztucznej inteligencji :

Użyj reprezentatywnych danych testowych i unikaj wycieków [4]
Wybierz wiele wskaźników powiązanych z rzeczywistymi wynikami [4][5]
W przypadku studiów prawniczych (LLM) należy opierać się na ocenie przez człowieka i porównywaniu wskaźników wygranych [5]
Odporność na testy – nietypowe dane wejściowe są zamaskowanymi, normalnymi danymi wejściowymi [1]
Należy bezpiecznie rozwijać i monitorować, ponieważ modele dryfują, a rurociągi pękają [1]
Udokumentuj, co zrobiłeś i czego nie przetestowałeś (niewygodne, ale skuteczne) [2][3]

Testowanie nie polega tylko na „udowodnieniu, że działa”. Chodzi o „znalezienie przyczyn awarii, zanim zrobią to użytkownicy”. I tak, to mniej atrakcyjne, ale to właśnie ta część, która utrzymuje system na miejscu, gdy sprawy zaczynają się chwiać… 🧱🙂

Często zadawane pytania

Najlepszy sposób testowania modeli sztucznej inteligencji, aby odpowiadały rzeczywistym potrzebom użytkowników

Zacznij od zdefiniowania „dobrych” w odniesieniu do rzeczywistego użytkownika i decyzji wspieranej przez model, a nie tylko do wskaźnika z tabeli wyników. Zidentyfikuj najbardziej kosztowne tryby awarii (fałszywie pozytywne i fałszywie negatywne) i określ twarde ograniczenia, takie jak opóźnienie, koszt, prywatność i możliwość wyjaśnienia. Następnie wybierz metryki i przypadki testowe, które odzwierciedlają te wyniki. Dzięki temu unikniesz optymalizacji „ładnej metryki”, która nigdy nie przełoży się na lepszy produkt.

Określenie kryteriów sukcesu przed wyborem metryk oceny

Zapisz, kim jest użytkownik, jaką decyzję ma wspierać model i jak wygląda „najgorszy scenariusz awarii” w środowisku produkcyjnym. Dodaj ograniczenia operacyjne, takie jak akceptowalne opóźnienie i koszt żądania, a także wymogi zarządzania, takie jak zasady prywatności i bezpieczeństwa. Gdy te zostaną wyjaśnione, metryki staną się sposobem pomiaru właściwych rzeczy. Bez tego ujęcia zespoły mają tendencję do optymalizacji tego, co najłatwiej zmierzyć.

Zapobieganie wyciekom danych i przypadkowym oszustwom podczas oceny modelu

Utrzymuj stabilne podziały w procesie szkolenia/walidacji/testowania i dokumentuj logikę podziału, aby wyniki były powtarzalne. Aktywnie blokuj duplikaty i elementy niemal duplikujące w różnych podziałach (ten sam użytkownik, dokument, produkt lub powtarzające się wzorce). Uważaj na wycieki funkcji, gdzie „przyszłe” informacje przedostają się do danych wejściowych poprzez znaczniki czasu lub pola po zdarzeniu. Solidna linia bazowa (nawet estymatory pozorne) pomaga zauważyć, kiedy występuje szum.

Co powinien zawierać zestaw narzędzi ewaluacyjnych, aby testy były powtarzalne w przypadku zmian

Praktyczna uprząż ponownie uruchamia porównywalne testy dla każdego modelu, monitu lub zmiany polityki, korzystając z tych samych zestawów danych i reguł punktacji. Zazwyczaj zawiera zestaw narzędzi regresyjnych, przejrzyste pulpity metryk oraz zapisane konfiguracje i artefakty w celu umożliwienia śledzenia. W przypadku systemów LLM wymagany jest również stabilny „złoty zestaw” monitów oraz pakiet skrajnych przypadków. Celem jest „naciśnij przycisk → porównywalne wyniki”, a nie „uruchom ponownie notatnik i módl się”

Metryki do testowania modeli AI wykraczające poza dokładność

Użyj wielu metryk, ponieważ jedna liczba może ukryć istotne kompromisy. Do klasyfikacji połącz precyzję/współczynnik odczuć/F1 z dostrajaniem progów i macierzami pomyłek dla segmentów. Do regresji wybierz MAE lub RMSE w zależności od sposobu karania błędów i dodaj kontrole w stylu kalibracji, gdy wyniki działają jak wyniki. Do rankingu użyj NDCG/MAP/MRR i przekrój przez zapytania głowa-ogon, aby wykryć nierównomierną wydajność.

Ocena wyników LLM w przypadku, gdy zautomatyzowane wskaźniki są niewystarczające

Potraktuj to jako system oparty na monitach i zasadach, a nie tylko na podobieństwie tekstu. Wiele zespołów łączy ocenę ludzką z preferencjami par (wskaźnik wygranych A/B) oraz sprawdzaniem opartym na zadaniach, takim jak „czy wyodrębniono właściwe pola” lub „czy przestrzegano zasad”. Zautomatyzowane metryki tekstowe mogą pomóc w wąskich przypadkach, ale często pomijają to, na czym zależy użytkownikom. Jasne rubryki i zestaw regresji zazwyczaj liczą się bardziej niż pojedyncza ocena.

Testy wytrzymałości, które należy przeprowadzić, aby model nie uległ awarii w przypadku zakłóconych danych wejściowych

Przetestuj model pod kątem literówek, brakujących wartości, nietypowego formatowania i niestandardowego kodu Unicode, ponieważ prawdziwi użytkownicy rzadko dbają o porządek. Dodaj przypadki przesunięć w dystrybucji, takie jak nowe kategorie, slang, czujniki lub wzorce językowe. Uwzględnij skrajne wartości (puste ciągi znaków, ogromne ładunki, liczby spoza zakresu), aby wykryć kruche działanie. W przypadku modeli LLM przetestuj również wzorce wstrzykiwania podpowiedzi i błędy użycia narzędzi, takie jak przekroczenia limitu czasu lub częściowe wyniki.

Sprawdzanie problemów związanych z uprzedzeniami i uczciwością bez gubienia się w teorii

Oceń wydajność na istotnych fragmentach i porównaj wskaźniki błędów oraz kalibrację w grupach, w których pomiar jest prawnie i etycznie uzasadniony. Szukaj cech zastępczych (takich jak kod pocztowy, typ urządzenia lub język), które mogą pośrednio kodować wrażliwe cechy. Model może wydawać się „ogólnie dokładny”, a jednocześnie konsekwentnie zawodzić w określonych kohortach. Udokumentuj, co zmierzyłeś, a czego nie, aby przyszłe zmiany nie powodowały ponownego, cichego wprowadzenia regresji.

Testy bezpieczeństwa, które będą obejmować generatywne systemy sztucznej inteligencji i LLM

Przetestuj niedozwolone generowanie treści, wycieki prywatności, halucynacje w domenach wysokiego ryzyka oraz nadmierne odrzucanie, gdzie model blokuje normalne żądania. Uwzględnij próby wstrzyknięcia natychmiastowego i eksfiltracji danych, zwłaszcza gdy system korzysta z narzędzi lub pobiera treści. Ugruntowany przepływ pracy to: zdefiniuj reguły polityki, stwórz zestaw monitów testowych, przeprowadź ocenę za pomocą kontroli ludzkiej i automatycznej oraz uruchom go ponownie za każdym razem, gdy monity, dane lub zasady ulegną zmianie. Spójność to czynsz, który płacisz.

Wdrażanie i monitorowanie modeli AI po uruchomieniu w celu wykrycia dryfu i incydentów

Stosuj etapowe schematy wdrażania, takie jak tryb cienia i stopniowe zwiększanie natężenia ruchu, aby wykrywać awarie, zanim zrobi to cała baza użytkowników. Monitoruj dryft danych wejściowych (zmiany schematów, braki, przesunięcia w dystrybucji) i wyjściowych (przesunięcia w wynikach, przesunięcia w równowadze klas), a także stan operacyjny, taki jak opóźnienia i koszty. Śledź sygnały zwrotne, takie jak edycje, eskalacje i skargi, oraz obserwuj regresje na poziomie segmentów. W przypadku jakichkolwiek zmian ponownie uruchom ten sam proces i stale monitoruj.

Odniesienia

[1] NIST - Sztuczna inteligencja - Ramy zarządzania ryzykiem (AI RMF 1.0) (PDF)
[2] Mitchell i in. - „Karty modeli do raportowania modeli” (arXiv:1810.03993)
[3] Gebru i in. - „Arkusze danych dla zestawów danych” (arXiv:1803.09010)
[4] scikit-learn - Dokumentacja „Wybór i ocena modelu”
[5] Liang i in. - „Całościowa ocena modeli językowych” (arXiv:2211.09110)

Znajdź najnowszą sztuczną inteligencję w oficjalnym sklepie z asystentami AI

O nas

Powrót do bloga

Kraj/region