Przejdź do treści
megapromotingPorozmawiajmy

Ekspertyza · Dostosowane modele AI

Wybieramy model na podstawie pomiaru, nie reputacji — i od początku mówimy, kiedy poprawna odpowiedź brzmi: niczego nie trenować.

Praca ma cztery części: mierzymy modele kandydackie na Twoich danych, wybieramy między konfiguracją, wyszukiwaniem w dokumentach i dostrojeniem, sprawdzamy prawa do użycia danych, a potem ustawiamy zużycie poniżej budżetu na klucz. Nie trenowaliśmy jeszcze żadnego modelu w produkcji i mówimy to zanim zapytasz.

Już zbudowaneCzęść pomiarowa i operacyjna jest zbudowana i uruchamiana, z zachowanymi wynikami: własne stanowisko testowe, które porównało osiem systemów rozpoznawania mowy na tych samych 200 rumuńskich wypowiedziach, z przedziałem ufności i różnicami parami, plus rozkład opóźnienia głosowego na sześć segmentów, które sumują się do całości z odchyleniem poniżej jednej milisekundy. Część operacyjna to własny gateway z 44 skonfigurowanymi modelami, kluczami per projekt z białą listą modeli i budżetem oraz codzienną konsolidacją zużycia na użytkownik × klucz × model. Część, której NIE zrobiliśmy — właściwe dostrajanie — jest opisana właśnie tak: potok jest przygotowany i wyceniony, ale nigdy nie działał na GPU. Usługa pozostaje „dostarczona”, ponieważ pracą, którą sprzedajemy, jest świadomy wybór i operowanie, a nie trenowanie.

Większość projektów „modelu niestandardowego” nie potrzebuje wytrenowanego modelu. Potrzebują właściwego modelu, z właściwą instrukcją, na właściwych danych, z kosztem na wywołanie, który ktoś monitoruje. Praca zaczyna się od pytania, którego niewiele osób zadaje: jak wygląda sukces, mierzony w jaki sposób, na jakim zestawie przypadków? Bez tej odpowiedzi każde porównanie modeli jest rozmową o gustach.

Mierzymy sami, nie przejmujemy liczb od dostawców. Gdy musieliśmy wiedzieć, co najlepiej rozpoznaje rumuński mówiony, uruchomiliśmy osiem systemów na tych samych 200 zdaniach, z tym samym normalizatorem, z przedziałem ufności przez bootstrap i z różnicami liczonymi parami. Wyniki były niewygodne: system, którego używaliśmy w produkcji, miał 26,26% wskaźnika błędu słowa, a mały model, 110 milionów parametrów, uruchomiony na procesorze, miał 6,83%. Opublikowaliśmy też nieprzyjemną część — w dokładności dla rumuńskiego przegrywamy wyraźnie z komercyjnymi dostawcami.

Druga część pracy to wybór między trzema drogami, które często się mylą: konfiguracją modelu (instrukcja, narzędzia, parametry), wyszukiwaniem w dokumentach i dostrajaniem. Kolejność, w jakiej je próbujemy, nie jest preferencją, tylko oszczędnością: pierwsze dwie są odwracalne w jedno popołudnie, trzecia wymaga danych, praw, GPU i pomiaru przed i po. Polecamy dostrajanie tylko wtedy, gdy mamy dowód, że pierwsze dwie nie wystarczają.

Trzecia część, ta, która zostaje po wdrożeniu: koszt na wywołanie. Modele przechodzą przez własny gateway, gdzie każdy klucz ma białą listę modeli, budżet i okres. Zużycie jest scalane codziennie według użytkownik, klucz i model, co oznacza, że pytanie „dlaczego rachunek wzrósł w tym miesiącu” ma odpowiedź w wierszach, a nie w przypuszczeniach.

Co obejmuje

Praca, komponent po komponencie

Definiujemy, co znaczy „lepszy”, zanim porównamy cokolwiek

Zestaw przypadków z Twojej rzeczywistości, kryterium liczbowe i metoda normalizacji ustalone na piśmie. Dla mowy używamy wskaźnika błędu słowa z własnym normalizatorem; dla odpowiedzi tekstowych, zgodności ze schematem plus sprawdzenia zdrowego rozsądku plus podobieństwa do odpowiedzi referencyjnej. Bez tego kroku reszty pracy nikt nie może zweryfikować.

Uruchamiamy porównanie na identycznych danych, z przedziałem ufności

Te same zdania, ta sama maszyna, tylko jeden model załadowany naraz, każdy we własnym procesie. Raportujemy przedział ufności przez bootstrap i różnice parami, a nie tylko średnią — bo dwa modele mogą mieć różne średnie, a mimo to być statystycznie remisowe. Mieliśmy dokładnie taki przypadek: dwa systemy przy 66 z 66 porównań parami, czyli remis, mimo że tabela średnich sugerowała zwycięzcę.

Rozkładamy latencję na segmenty, które się sumują

W jednym przebiegu głosowym zmierzyliśmy osobno sześć segmentów — decyzję tury, rozpoznawanie mowy, bramkę, czas do pierwszego tekstu modelu, pierwszy blok syntezy, kolejkę i transport. Kontrola, która ma znaczenie: suma tych sześciu daje całkowity czas do pierwszego dźwięku z odchyleniem poniżej jednej milisekundy na każdej prawidłowej turze. Stąd widać, gdzie leży problem: w zmierzonym przypadku 68,7% czasu stanowiło oczekiwanie na pierwszy tekst od modelu, a nie rozpoznawanie mowy, które zajmowało 2,9%.

Wybieramy między konfiguracją, wyszukiwaniem w dokumentach i dostrajaniem

Wyszukiwanie w dokumentach jest zaimplementowane i działa: wyszukiwanie hybrydowe, 70% semantyczne i 30% dopasowanie słów, próg podobieństwa 0,70, pięć fragmentów na pytanie, z dziennikiem per zapytanie, który zachowuje wyniki i czasy. Dostrajanie proponujemy tylko z dowodem, że pierwsze dwie opcje nie wystarczają — oraz z budżetem i prawami na stole wcześniej, nie później.

Sprawdzamy prawa do korzystania z danych przed każdym trenowaniem

To nie formalność, to coś, co zatrzymuje projekty. Korpus 1.746 godzin rumuńskiego, który brałyśmy pod uwagę, okazał się objęty licencją niekomercyjną — a więc nieprzydatny do komercyjnego modelu. Zestaw 270.946 przykładów miał kod na licencji permisywnej, ale dane bez żadnej zadeklarowanej licencji. A polityka korzystania jednego dostawcy głosu wyraźnie zakazuje trenowania modelu na jego wyjściu. Każde źródło sprawdzamy na jego własnej stronie, a nie na podstawie tego, co napisano w artykule.

Trzymamy zużycie w budżecie na kluczu, nie na fakturze

Własny gateway z 44 skonfigurowanymi modelami, każdy z kosztem na token i limitem kontekstu w konfiguracji. Klucz projektu ma białą listę modeli, budżet i okres, i można go rotować, zachowując historię. Zużycie jest konsolidowane codziennie na użytkowniczka × klucz × model. Routing używa strategii „najmniej zajęty”, dwóch ponowień i maksymalnego czasu 120 sekund.

Bierzemy pod uwagę tokeny, za które dostawca nalicza opłatę, ale gateway ich nie widzi

Modele typu rozumowania wytwarzają wewnętrzne kroki, których platforma do śledzenia kosztów nie widzi, ale dostawca je nalicza. Praktyczna konsekwencja: brutto budżet ustawiony na kluczu musi być mniejszy niż pożądany limit, podzielony przez współczynnik rozumowania. Jeśli nie wykonasz tej korekty, klucz wydaje się w budżecie, a faktura nie jest.

Uruchamiamy modele lokalnie, gdy dane nie mogą wyjść

Mamy działający lokalny łańcuch: rozpoznawanie mowy z modelem 0,6 miliarda parametrów na procesorze i synteza głosu z modelem 99 milionów parametrów, również lokalnie. W produkcie do monitorowania radia transkrypcja odbywa się lokalnie, a wersja przez gateway istnieje równolegle — więc porównanie lokalnego i hostowanego jest wykonane, nie założone. Z maszyny wychodzi tekst, nie audio.

Śledzimy dryf po uruchomieniu

Tygodniowy bank regresji na stałych przypadkach, który porównuje zgodność ze schematem, przechodzi test zdrowego rozsądku i mierzy podobieństwo do odpowiedzi referencyjnych. Model, który zmienia się pod tobą — i zmienia się — widać w tabeli, nie w skargach klientek.

Jak to wygląda

Trasa, krok po kroku.

01

Piszemy kryterium i budujemy zestaw przypadków

Przypadki pochodzą z twojej rzeczywistości, a nie z ogólnego zestawu testowego. Ustala się kryterium liczbowe, metodę normalizacji i próg, od którego wynik jest akceptowalny. Dostarczamy: zestaw przypadków, zapisane kryterium i skrypt, który je oblicza.

02

Uruchamiamy porównanie i publikujemy także wyniki, które nam przeczą

Kandydackie modele działają na identycznych danych, z przedziałem ufności. Dostarczamy: tabelę ze wszystkimi testowanymi systemami, także odrzuconymi i z podaniem powodu, plus dokładną komendę do odtworzenia. Model, który odrzuciliśmy dla rumuńskiego, miał 99,69% wskaźnik błędu, bo zjeżdżał na włoski — rumuński nie był wśród jego zadeklarowanych języków. Ten wynik jest w tabeli.

03

Wybieramy drogę i uzasadniamy ją na piśmie

Konfiguracja, wyszukiwanie w dokumentach albo precyzyjne dostrojenie — z uzasadnieniem, kosztem i tym, co się traci przy wyborze. Dostarczamy: uzasadnioną decyzję, plus pomiar, który ją wspiera. Jeśli rekomendacja brzmi „nie trenujemy niczego”, zapisujemy to tak samo jasno.

04

Uruchamiamy z kluczem, budżetem i białą listą modeli

Klucz projektu jest wydawany z budżetem, okresem i listą dozwolonych modeli, z zastosowaną korektą dla tokenów rozumowania. Dostarczamy: klucz, panel zużycia i próg, od którego ktoś otrzymuje alert.

05

Mierzymy ponownie po wdrożeniu

Te same przypadki, to samo kryterium, według modelu w produkcji. Dostarczamy: porównanie przed/po i listę zmian z uzasadnieniem każdej z nich. Rekurencyjny bank regresji wychwytuje zmiany zachowania modelu dostawcy.

Przebieg wyboru modelu1kryterium pisemne i zestawde cazuri2porównanie na danychidentice, cu intervalwiarygodny3decyzja międzykonfiguracja, wyszukiwaniew dokumentach ireglaj fin4uruchomieniez kluczem, budżetem ibiała lista5okresowy ponowny pomiar
Przebieg wyboru modelu

Dane

Czego dotykamy, gdzie to leży i jak długo zostaje

Pytania, które zadaje każdy, kto ma inspektora ochrony danych — postawione tutaj, zanim on je zada.

Jakie dane dotykamy i gdzie są przechowywane
Zbiór ewaluacyjny pozostaje Twój i jest przechowywany oddzielnie od zbioru używanego do instrukcji lub przykładów. Gdy ewaluację można przeprowadzić na danych publicznych — jak w przypadku naszego benchmarku dla rumuńskiego — robimy to tam i w ogóle nie dotykamy danych klienta.
Rozdzielenie zbiorów, żeby pomiar coś znaczył
Zbiór, na którym stroimy, i zbiór, na którym mierzymy, nie stykają się. Jeśli przykład został użyty do napisania instrukcji, nie ma już prawa znaleźć się w zbiorze ewaluacyjnym. To jedyna zasada, która odróżnia liczbę od liczby, która coś znaczy.
Pochodzenie i licencja każdego źródła
Dla każdego zbioru danych treningowych zapisuje się źródło, czas materiału, dokładną licencję i stronę, z której został odczytany. Odrębnie zaznaczamy, co zmierzyliśmy my, a co oszacowaliśmy, wraz z podstawą obliczenia zapisaną obok. Ta konwencja wychwyciła już trzy błędy licencyjne, które trafiłyby do projektu.
Dziennik zapytań
Dla wyszukiwania w dokumentach przechowuje się, dla każdego zapytania, zwrócone fragmenty, ich wyniki oraz czasy — wyszukiwania i całkowity. Bez tego dziennika „dlaczego odpowiedziało tak” nie ma odpowiedzi. Z nim strojenie odbywa się na danych.
Zużycie
Jedna linia dziennie dla każdej kombinacji użytkownik × klucz × model, plus stan klucza: maksymalny budżet, wydane w 24 godziny, 7, 14 i 30 dni, wykorzystany procent, liczba żądań i lista modeli faktycznie użytych.

Przykład

Bank testowy, który podważył wybór z produkcji

Sytuacja

Mieliśmy działający system rozpoznawania mowy dla rumuńskiego i otwarte pytanie: czy to najlepszy dostępny, czy tylko pierwszy, który zintegrowaliśmy? Nie było żadnego własnego pomiaru, tylko liczby publikowane przez dostawców, mierzone na innych językach i innych zbiorach.

Co zbudowaliśmy

Zbudowaliśmy bank: 200 rumuńskich wypowiedzi z publicznego zbioru, ten sam seed do selekcji, 35,1 minuty audio, ten sam normalizator dla wszystkich systemów, przedział ufności przez bootstrap, różnice liczone parami. Osiem systemów, każdy ładowany osobno, w osobnym procesie, na tej samej maszynie. W raporcie zapisaliśmy i konfigurację maszyny, i dokładne polecenie odtworzenia.

Co z tego wyszło

System w produkcji miał 26,26% współczynnik błędu na słowo. Model o 110 milionach parametrów, uruchomiony na procesorze z modelem językowym obok, miał 6,83%. Bardzo chwalony model osiągnął 99,69%, ponieważ zjeżdżał na włoski — rumuński nie należał do jego deklarowanych języków. A dwa systemy, które po średniej wyglądały na różne, wyszły statystycznie remisowo w porównaniu parami. Opublikowaliśmy całą tabelę, łącznie z wierszem, który podważał nasz wybór.

Czego nie mówi ten przypadek

Pomiar wykonano na publicznym zbiorze do czytania, a nie na rzeczywistych rozmowach telefonicznych, z szumem i nakładającymi się wypowiedziami. Dobry wynik na tym zbiorze nie gwarantuje tego samego wyniku przez telefon. Dlatego dla klienta bank odtwarza się na jego nagraniach — inaczej mierzymy coś innego niż to, co go interesuje.

Pytania

O co pytają ludzie, zanim zadzwonią

Czy kiedykolwiek trenowałeś własny model?

Nie. Żaden model dopracowany ani wytrenowany przez nas nie działa w produkcji i nie ma żadnego zapisanego punktu kontrolnego w naszych repozytoriach. To, co mamy: potok treningowy zapisany aż do dokładnej komendy uruchomienia maszyny z GPU, budżet obliczony dla trzech scenariuszy, dane przygotowane i licencje zweryfikowane — oraz spisana lista tego, co trzeba zdecydować przed pierwszym uruchomieniem. Wolimy to mówić niż sprzedawać kompetencję, której nie ćwiczyliśmy.

To dlaczego mielibyście żądać od kogoś pieniędzy za „modele personalizowane”?

Bo praca, która daje rezultat w większości przypadków, nie polega na trenowaniu. Chodzi o to, by wiedzieć, który model wykonuje zadanie na Twoich danych, z jakim opóźnieniem i przy jakim koszcie za wywołanie — a to wymaga pomiaru, którego prawie nikt nie robi. Jeden przykład z naszej pracy: jedna błędna wartość domyślna w konfiguracji modelu (kara za powtórzenia ustawiona na 1,2 zamiast 1,0) kosztowała 4,3 punktu procentowego błędu. Nie było potrzebne trenowanie, tylko pomiar.

Dostrajanie czy wyszukiwanie w dokumentach?

Zacznij prawie zawsze od wyszukiwania w dokumentach. Jest odwracalne, aktualizuje się przez zmianę jednego pliku i może pokazać źródło odpowiedzi. Dostrajanie zmienia zachowanie modelu w sposób, którego nie da się sprawdzić, wymaga danych oznaczonych, praw do użycia oraz pomiaru przed i po. Polecamy dostrajanie, gdy mamy dowód, że pierwsza opcja nie wystarcza — na przykład gdy pokazaliśmy, że model offline nie staje się modelem strumieniowym tylko przez konfigurację: zwężenie okna uwagi bez ponownego trenowania zwiększyło błąd z 8,81% do 22,26%, a potem do 48,95%.

Gwarantujecie mi określoną dokładność?

Nie, i żaden uczciwy dostawca nie może tego zrobić, bo dokładność zależy od Twoich danych. Gwarantujemy metodę: mierzymy na Twoich przypadkach, pokazujemy przedział ufności i mówimy, kiedy różnica między dwiema opcjami nie jest istotna statystycznie. Mieliśmy przypadek, w którym wynik opublikowany przez autorów modelu nie odtworzył się u nas — oni podawali 20,70%, my zmierzyliśmy 26,68% na tym samym modelu. Zapisaliśmy, że nie wiemy dlaczego, zamiast wybierać wygodną liczbę.

Czy moje dane trafiają do dostawców modeli?

To zależy od wybranej drogi i jest to decyzja, a nie wypadek. Przez gateway żądanie trafia do dostawcy modelu. Jeśli to nie jest akceptowalne, mamy lokalny łańcuch funkcjonalny: rozpoznawanie mowy i syntezę głosową uruchomione na Twojej maszynie, z której wychodzi tylko tekst, nigdy audio. W produkcie do monitoringu radiowego lokalna transkrypcja i transkrypcja przez gateway są zaimplementowane obie, więc kompromis między nimi możemy pokazać liczbami.

Co się dzieje, jeśli dostawca zmienia model pod nami?

To się zdarza. Dlatego praca obejmuje bank regresji na stałych przypadkach, uruchamiany okresowo, który porównuje zgodność ze schematem, przechodzi test zdrowego rozsądku i mierzy podobieństwo do odpowiedzi referencyjnych. I dlatego integracja przechodzi przez gateway: model zmienia się w jednym polu, a nie przez przepisanie kodu.

Jak konkretnie kontroluję koszt?

Klucz projektu ma białą listę modeli, budżet i okres oraz może być rotowany z zachowaniem historii. Zużycie jest konsolidowane codziennie według użytkownika, klucza i modelu. Jedna pułapka, którą korygujemy od początku: modele rozumowania generują wewnętrzne kroki, których system śledzenia nie widzi, ale dostawca je nalicza — więc brutto budżet na klucz ustawia się niżej niż pożądany limit, podzielony przez współczynnik rozumowania. Kto nie robi korekty, widzi klucz w budżecie i fakturę ponad limit.

Dlaczego licencja danych ma znaczenie, skoro i tak są publiczne?

Bo „publiczne” i „do użytku komercyjnego” to różne rzeczy, a różnicę odkrywa się późno i drogo. Trzy przykłady z naszych weryfikacji: duży korpus rumuńskiego, licencjonowany niekomercyjnie, więc wykluczony dla produktu komercyjnego; zbiór setek tysięcy przykładów z kodem na licencji permisywnej, ale bez żadnej zadeklarowanej licencji danych; oraz polityka użycia dostawcy głosu, która wyraźnie zabrania trenowania modelu na jego wyjściu. Weryfikację robi się na stronie źródła, a nie na tym, co powtarza artykuł.

Czego nie robi ta usługa?

Nie trenuje dziś modeli bazowych i nie obiecuje własnego modelu w produkcji. Nie gwarantuje procentów poprawy. Nie porównuje modelu z konkurencją na podstawie liczb publikowanych przez konkurencję — jeśli sami nie uruchomiliśmy porównania, mówimy, że to liczba deklarowana przez nich, a nie zmierzona przez nas.

Na czym opierają się powyższe stwierdzenia (26 źródeł)

26 z nich to kod i pliki z naszych repozytoriów. Nie publikujemy ich nazw ani numerów linii: razem, na jednej stronie, opisałoby to zbyt dokładnie, jak zbudowane są systemy, które nie należą tylko do nas. Przechodzimy je razem z Tobą, w repozytorium, na życzenie — weryfikacja pozostaje możliwa, tylko odbywa się w rozmowie.

Co chcesz, żeby działało lepiej?

Opowiedz nam o swoim procesie. Wspólnie ustalimy, co warto zbudować, co da się połączyć i jak sprawdzimy wynik.

Porozmawiajmy