Dokonaj drobnej optymalizacji czy wezwij API? Koszty pipeline do wydobywania dokumentów

Liderzy działów inżynieryjnych ciągle zadają to samo pytanie, zazwyczaj zaraz po otrzymaniu pierwszej dużej faktury od OpenAI lub Anthropic: czy zespół powinien dostosować swój własny model, czy nadal korzystać z API? Oczekiwana odpowiedź brzmi, że dostosowanie modelu jest tańsze. Czasami to prawda, ale zazwyczaj z powodów mniej oczywistych, niż przypuszczają ludzie, a dla wielu zespołów to po prostu błąd. Ten artykuł analizuje realistyczny system obciążony dokumentacją, oceniony z obu perspektyw, przy użyciu cen katalogowych z września 2026 roku, aby można było zobaczyć, skąd naprawdę pochodzą oszczędności, kiedy opłaca się posiadać model oraz jak podjąć decyzję bez ryzykowania ośmiu tygodni pracy inżynierów na podstawie domysłów.

Opcja, którą ludzie sobie wyobrażają, już nie istnieje

Jedna zmiana po cichu odmieniła całą dyskusję: w momencie pisania tego tekstu nie można dostosować aktualnego modelu najnowszej generacji.

Zgodnie z stroną cenową OpenAI, ich platforma do drobnej kalibracji jest stopniowo wycofywana: nowi klienci nie mogą się zapisać, a o4-mini jest jedynym pozostałym modelem poddającym się kalibracji, za który pobierana jest opłata w wysokości 100 dolarów za godzinę treningu. API firmy Anthropic w ogóle nie umożliwia drobnej kalibracji. Jedyną dotychczasową metodą była kalibracja nadzorowana modelu Claude 3 Haiku na platformie Amazon Bedrock, a model Haiku 3 został odsunięty od użycia we wszystkich miejscach z wyjątkiem Bedrock i Google Cloud.

W związku z tym pod koniec 2026 roku „dokładna optymalizacja versus nowe rozwiązania” oznaczają coś bardziej konkretnego: bierze się model o otwartym kodzie, takie jak Qwen, Llama, wersję Nemotron lub gpt-oss, trenuje się adapter LoRA na własnych danych, a następnie umieszcza go na własnej infrastrukturze lub u dostawcy takiego jak Fireworks lub Together. Ryzyka związane z tą decyzją nie są takie, jak sobie wyobrażają ludzie – chodzi tu o selekcję modelu, jego ocenę oraz dostarczanie usług, które zwykle za nas zajmuje hostowana API. Należy być precyzyjnym w tym temacie przed prezentacją zarządowi.

System referencyjny: platforma do gromadzenia dowodów audytowych

System opisany tutaj to nie zabawka. Jest to kompletna platforma do gromadzenia dowodów audytowych dla firmy średniej wielkości – taki produkt faktycznie kupiłaby brytyjska lub nordycka kancelaria rachunkowa. Działa on w siedmiu etapach:

1. Przyjmowanie danych. Klienci przesyłają pliki przez portal, głównie w formie zeskanowanych plików PDF. Typowymi danymi wejściowymi są faktury, zamówienia zakupowe, notatki o przyjęciu towarów, wyciągi bankowe, umowy najmu oraz protokoły ze spotkań zarządu.
2. Klasyfikacja. Każdemu dokumencowi przypisuje się typ i wysyła go do odpowiedniego testu.
3. Ekstrakcja danych. Strukturyzowane pola są wprowadzane do ustalonego schematu, obejmującego dostawcę, datę, kwotę netto, VAT, numer zamówienia zakupowego, osobę upoważnioną do zatwierdzenia, walutę oraz centrum kosztów. Wynikiem musi być ważny plik JSON, który za każdym razem dokładnie odpowiada schematowi.
4. Testy kontroli. Sprawdzanie zgodności trzech źródeł polega na weryfikacji, czy faktura jest zgodna z zamówieniem zakupowym i notatką o przyjęciu towarów, oraz czy osoba upoważniona działała w ramach swoich uprawnień. Większość tych funkcji stanowi zwykły kod, a nie model.

Klasyfikacja wyjątków. Wszystko, co nie przechodzi testu, jest oceniane i sortowane.

Tworzenie wstępnego projektu raportu. System sporządza pierwszy szkic każdego stwierdzenia, na przykład informację o tym, że sprawdzono 42 płatności przekraczające próg 50 000 funtów, a trzy z nich nie miały udokumentowanej dodatkowej aprobaty.

Pytania i odpowiedzi audytora. Audytorzy mogą sprawdzać cały plik z danymi dotyczącymi audytu i otrzymywać uzasadnione odpowiedzi z odniesieniami do dokumentów źródłowych.

Etapy 2 i 3 zużywają prawie wszystkie tokeny i są również najbardziej powtarzalną, mechaniczną oraz ograniczoną schematem częścią systemu. To w etapach 6 i 7 podejmowane są rzeczywiste decyzje, choć ich udział w ogólnej objętości jest znikomy. Pamiętaj o tym podziale, ponieważ reszta analizy wynika z niego.

Oszacowanie ilości tokenów

Model zakłada, że każdy dokument jest najpierw konwertowany na tekst za pomocą OCR, zanim dotrze do niego model. Dzięki temu unika się opłat za tokeny obrazowe, co i tak byłoby standardowym podejściem w praktyce.

Każdy dokument przechodzi przez trzy etapy (klasyfikację, wydobywanie informacji i samokontrolę), co daje łącznie mniej więcej:

• 5 200 tokenów wejściowych, obejmujących tekst dokumentu, schemat oraz kilka przykładów typu few-shot
• 600 tokenów wyjściowych dla strukturyzowanego wyniku

Założono dwa poziomy obciążenia:

• Pilot: 100 000 dokumentów miesięcznie, reprezentujących jedną firmę w okresie największej aktywności.
• Scale: 2 000 000 dokumentów miesięcznie, reprezentujących ten sam produkt sprzedawany pięćdziesięciu firmom.

To daje około 580 milionów tokenów miesięcznie przy poziomie pilotowym oraz 11,6 miliarda tokenów przy poziomie Scale.

Jak wygląda rachunek

Poniższe ceny opierają się na standardowych stawkach za usługi z globalnym routowaniem, bez żadnych zniżek za większe ilości lub cacheowanie, tak jak zostały opublikowane na stronach cenowych poszczególnych dostawców we wrześniu 2026 roku. Ceny często się zmieniają, więc należy traktować je jako przybliżone wartości i ponownie sprawdzić przed ustalaniem budżetu.

Przy małych ilościach danych argumenty za dopasowywanie modeli tracą na znaczeniu. Uruchomienie całego procesu wydobywania danych przy użyciu Claude Sonnet 5 kosztuje około 1 640 dolarów miesięcznie, Haiku 4.5 około 820 dolarów, a dopasowany model o pojemności 8B około 116 dolarów. Oszczędność w wysokości około 1 500 dolarów miesięcznie nigdy nie zrekompensuje wysiłku potrzebnego do stworzenia takiego modelu. Na tym etapie lepiej korzystać z API.

Przy dużych ilościach danych wybór staje się rzeczywiście istotny:

• Claude Opus 5: około 82 000 dolarów miesięcznie
• GPT-5.6 Sol: około 65 600 dolarów miesięcznie
• Claude Sonnet 5: około 32 800 dolarów miesięcznie
• Claude Haiku 4.5: około 16 400 dolarów miesięcznie
• GPT-5.6 Luna: około 3 520 dolarów miesięcznie

Dopracowany model 8B, dostarczany w formie serverless: około 2 320 dolarów miesięcznie

Kuszące jest podawanie, że dzięki dopracowaniu oszczędza się ponad 90%, a matematyka potwierdza to w porównaniu z najwyższymi pakietami: koszt dopracowania wynosi około 7% ceny modelu Sonnet 5 i mniej niż 3% ceny modelu Opus 5. Jednak żadna zespołów nie powinna od początku używać zaawansowanych mechanizmów wydobywania faktur na bazie modeli najwyższej klasy. Porównywanie optymalnego rozwiązania z celowo marnotrawnym to marketing, a nie analiza.

Routing, a nie dopracowywanie modeli, zapewnia duże oszczędności

Porównajmy ostatnie dwie pozycje z tej listy: 3 520 dolarów za model GPT-5.6 Luna w porównaniu z 2 320 dolarami za dopracowany model 8B. Różnica wynosi 1 200 dolarów miesięcznie, czyli około 14 400 dolarów rocznie.

Odpowiednie dostosowanie modelu wymaga oznaczania danych, napisania narzędzia do oceny, przeprowadzenia treningu, uruchomienia systemu serwowania oraz wdrożenia monitoringu odchyleń. Realistyczna ocena to osiem tygodni pracy inżynierów. Pomnożywszy to przez typową stawkę europejskich wykonawców, zwrot z oszczędności wynikających wyłącznie z tokenów przekracza nawet osiemnaście miesięcy.

Bardziej przydatnym wnioskiem jest to, że największe oszczędności wynikają z wykorzystania mechanizmu routingu. Przeniesienie procesów klasyfikacji i wydobywania danych z najnowocześniejszej wersji na najtańszy poziom, który nadal spełnia wymagania oceny, zmniejsza miesięczne koszty na poziomie Opus z 82 000 dolarów do 3 520 dolarów, co stanowi redukcję o około 96%. Dzięki routerowi oraz solidnemu zestawowi do oceny tę zmianę można wprowadzić już po popołudniu. Dalsza optymalizacja pozwala zaoszczędzić jeszcze około 34%. Ten sam princip, polegający na dopasowywaniu rozmiaru modelu do każdej żądania, jest szerzej omawiany w artykule right-sizing LLMs with routing, retrieval and evaluation.

Sam proces szkolenia jest praktycznie bezpłatny. Fireworks oferuje usługę dopracowywania modeli typu LoRA pod nadzorem za cenę 0,50 dolara za milion tokenów treningowych dla modeli o maksymalnie 16 miliardach parametrów. Dwadzieścia tysięcy etykietowanych przykładów po 2500 tokenów każdy, przeszkolonych przez trzy epoki, to 150 milionów tokenów treningowych, co odpowiada około 75 dolarom za jedno przeprowadzenie procesu. Osiem takich przeprowadzeń w trakcie rozwoju kosztuje w przybliżeniu 600 dolarów. Obliczenia nigdy nie były najdroższą częścią; drogie są przygotowanie danych i ich ocena. Każda wycena związana z dopracowywaniem modeli, oparta głównie na kosztach GPU, pochodzi od osoby, która sama tego nie robiła.

Dlaczego w ogóle dopracowywać modele?

Jeśli koszt tokenów nie jest wystarczającym powodem, mogą nim być dwa inne czynniki.

Pierwszy powód: ścisłe przestrzeganie schematu

Jest to szczególnie ważne w pracach audytowych, ale otrzymuje znacznie mniej uwagi, niż na to zasługuje.

Modele typu Frontier są uogólniaczami. Jeśli poprosić je o wybór spośród 51 ustalonych podkategorii, czasami wygenerują 52. opcję, ponieważ tworzenie tekstów brzmiących wiarygodnie jest dokładnie celem ich szkolenia. W przypadku asystenta do rozmów takie błędy praktycznie nie mają znaczenia. W dokumencie badawczym, który stanowi podstawę zaopiniowania audytorskiego, jest to natomiast wada.

Niedawne badania wskazują w tym samym kierunku, chociaż wiele z nich to prace przedpublikowane i należy je czytać z tym na uwadze:

• Przedpublikacja z 2026 roku dotycząca klasyfikacji dokumentów bezpieczeństwa oceniła modele na podstawie 51 z góry określonych podkategorii, wymagając odpowiedzi w sztywnym formacie JSON. Tam model dostosowany lokalnie przewyższył modele typu frontier o 15 do 20 punktów procentowych, a badacze zaobserwowali, że GPT-5 wymyślał nazwy podkategorii nieobecnych w taksonomii. Ich interpretacja jest kluczowa: modele frontier dobrze radzą sobie z wydobywaniem danych w luźnie sformatowanym formacie, ale przy ścisłych ograniczeniach schematu kalibracja ma większe znaczenie niż umiejętność rozumowania.

Inny preprint opisał dostosowany model Qwen2.5-0.5B – model o pół miliarda parametrów, który mieści się na jednej karcie graficznej typu konsumenckiej, osiągając średnio 0,83 mikro-F1 w zadaniach wyodrębniania relacji w ogólnych domenach. Przy zaledwie minimalnym wsparciu typu zero-shot, GPT-5.4 osiągnął wynik 0,69 w tym samym pomiarze, natomiast Claude Sonnet 4.6 – 0,66. Autorzy podkreślają, że nie oznacza to, iż małe modele są z natury silniejsze; pokazuje to raczej, że dostosowanie modelu do wąskiego, ustalonego zadania może przeważyć nad jego surowymi możliwościami. Wyodrębnianie informacji z audytów to dokładnie taki rodzaj zadania.

Samodzielne opublikowane wyniki Anthropic z dostosowywania Claude 3 Haiku pokazały wzrost dokładności klasyfikacji w zadaniach moderacji komentarzy z 81,5% do 99,6%, przy jednoczesnym zmniejszeniu liczby tokenów na zapytanie o 85%. Choć domena jest inna, wzorzec pozostaje taki sam.

Dla produktu audytowego dwuprocentowe poprawienie dokładności wydobywania danych z pol może być cenniejsze niż całe wydatki na inferencję razem wzięte, ponieważ każdy błąd wydobywania skutkuje koniecznością ręcznej weryfikacji, a ręczna weryfikacja jest najdroższym zasobem w tym biznesie.

Powód drugi: dokładna wiedza o miejscu przechowywania danych

W Europie to często decyduje o sfinalizowaniu umowy.

Pliki audytowe brytyjskich lub unijnych firm księgowych zawierają finansową dokumentację klientów, dane pracowników, a czasami również informacje osobowe dotyczące osób trzecich. Miejsce przetwarzania nie jest kwestią drugorzędną; zazwyczaj to drugie pytanie, które zadaje dział zakupów.

Bieżące opcje, według stanu na wrzesień 2026 roku, zaskakują wiele zespołów:

• API firmy Anthropic nie oferuje opcji przechowywania danych w UE. Parametr inference_geo przyjmuje wartości global lub us; przetwarzanie wyłącznie w USA kosztuje 1,1 raza więcej niż standardowa stawka. Aby utrzymać Claude w UE, trzeba użyć regionu AWS Bedrock lub Google Vertex znajdującego się w UE, gdzie końce punktowe regionalne są droższe o 10% w porównaniu z globalnymi. W chwili pisania artykułu model Claude w Microsoft Foundry nie miał strefy danych w UE.
• OpenAI obsługuje przetwarzanie regionalne, dodając 10% do ceny modeli uruchamianych od 5 marca 2026 roku.
• Fireworks stosuje współczynnik 1,5, gdy dedykowane wdrożenie jest ograniczone do określonego regionu.

Samodzielnie zarządzane karty GPU w centrum danych, powiedzmy we Frankfurcie lub Dublinie obejmują całe wyposażenie oraz koszty hostingu, które ustalasz, a dane nigdy nie wychodzą poza twoją kontrolę.

Gdy koszt lokalizacji zależy od wielkości obciążenia, sytuacja się zmienia. Dwie dedykowane karty H100 obsługujące dostrojony model 8B, dostępne tylko w określonym regionie i działające przez całą dobę, kosztują około 17 520 dolarów miesięcznie. Obsługa tego samego obciążenia za pomocą Claude Sonnet 5 na endpointzie EU Bedrock kosztowałaby około 36 080 dolarów, a z Opus 5 około 90 200 dolarów.

To jest prawdziwy europejski argument za posiadaniem takiego modelu. Nie chodzi o to, że tokeny są tańsze; chodzi o to, że wyjaśnienie wymogów regulacyjnych mieści się w jednym zdaniu, a nie na diagramie architektury.

Nie kupuj dedykowanych kart GPU zbyt wcześnie

Stała miesięczna cena karty graficznej wydaje się atrakcyjna, ale wprowadza w błąd wiele zespołów, ponieważ opłaca się ona tylko przy objętościach, których niewiele produktów kiedykolwiek osiąga. Biorąc za punkt odniesienia parę dedykowanych kart H100 po globalnych cenach, wynoszących około 11 680 dolarów miesięcznie, punkty przełomowe znajdują się mniej więcej w następujących wartościach:

• 700 000 dokumentów miesięcznie dla Claude Sonnet 5 – poniżej tej wartości API jest tańsze
• 1,4 miliona dokumentów miesięcznie dla Claude Haiku 4,5
• 6,6 miliona dokumentów miesięcznie dla GPT-5,6 Luna

Powierzchowny produkt do audytu najprawdopodobniej mieści się poniżej każdej z tych wartości przez pierwsze dwa lata. Hostowanie bez serwera dla dostosowanego modelu całkowicie unika tego problemu: otrzymuje się dostosowane wagi bez konieczności płacenia za nieużywane karty graficzne, co czyni to rozsądnym punktem wyjścia. Wadą jest mniejsza kontrola nad opóźnieniami i przepustowością, co ma znaczenie dopiero wtedy, gdy objętość jest wysoka i stała.

Cztery pytania, które pomogą podjąć decyzję

1. Jaki jest twój rzeczywisty miesięczny wolumen tokenów? Jeśli przetwarzasz mniej niż około miliarda tokenów miesięcznie, wybierz najtańszy poziom Frontier, który pozwoli przeprowadzić twoje oceny, i zainwestuj osiem tygodni pracy inżynierów w coś bardziej przydatnego. Dostosowywanie modelu przy tak małym wolumenie to tylko pozory, a nie prawdziwa praca inżynierska.

2. Na jak wąsko i ograniczenie sformułowana jest zadanie? Stały format wyjściowy, ustalony zestaw etykiet oraz tysiące niemal identycznych przykładów dziennie wskazują na konieczność dostosowywania modelu. Rozumowanie otwarte, decyzje subiektywne oraz tworzenie narracji pod podpis partnera wymagają modelu typu Frontier i najprawdopodobniej tam pozostaną.

3. Gdzie muszą znajdować się dane? Klauzula umowy wymagająca przetwarzania danych w obrębie EEA zmienia zestaw możliwych rozwiązań, zanim rozpocznie się dyskusja na temat kosztów. Należy uwzględnić dodatkowy koszt związaný z lokalizacją danych w pierwszej wycenie, a nie odkrywać go podczas analizy architektury.

4. Czy można uzyskać co najmniej 10 000 etykietowanych przykładów? Dokument badawczy NVIDIA Research na temat małych modeli językowych w systemach agentowych sugeruje, że odpowiedni zakres to od dziesięciu tysięcy do stu tysięcy przykładów dla optymalizacji małego modelu. Jeśli tego brakuje, pierwszym krokiem powinno być wyposażenie pipeline w narzędzia do rejestracji własnych danych treningowych.

Ostatni punkt to najcenniejszy wzorzec w tym przypadku, a jednocześnie najmniej promowany. Wykorzystaj API typu frontier i rejestruj każde wezwanie, włączając dane wejściowe, wyjściowe oraz korekty dokonane przez recenzentów. Po sześciu miesiącach masz już etykietowany zbiór danych, który nie kosztuje nic dodatkowego, i możesz dokonać dopasowań w oparciu o fakty, a nie tylko nadzieję. Rejestrowanie dokumentów klienta wiąże się z własnymi obowiązkami dotyczącymi ochrony danych, dlatego od samego początku należy zaprojektować zasady przechowywania i dostępu do tych записów.

To samo opracowanie NVIDIA oszacowało również udział wezwań LLM, które małe modele mogłyby przejąć w trzech projektach agentów o otwartym kodzie: około 60% w przypadku MetaGPT, 40% w przypadku Open Operator oraz 70% w przypadku Cradle. Nie wszystkie, ale też nie żadne z nich. Prawidłową odpowiedzią jest połączenie obu rozwiązań, a tylko rejestracje pokazują, które wezwania należą do jakiej kategorii.

Najsilniejszy argument przeciwny

Dane dotyczące przyjęcia rozwiązań przez przedsiębiorstwa wskazują inaczej. Zgodnie z badaniem przeprowadzonym przez Menlo Ventures, udział oprogramowania open-source w obciążeniach roboczych firm spadł z 19% do 11%, podczas gdy wydatki skupiły się na zamkniętych API: Anthropic stanowi 40% wydatków firm na modele językowe, OpenAI – 27%, a Google – 21%. (Menlo jest inwestorem w Anthropic, co warto wiedzieć podczas analizy tych danych.)

To nie stoi w sprzeczności z powyższą analizą; pokazuje jedynie, gdzie leży opór. Zamknięte API przewyższają pod względem wygody, a wygoda zazwyczaj przeważa. Zespoły, które uzyskują rzeczywistą korzyść z dostosowań modeli o otwartym kodzie, świadomie wybrały większe obciążenia operacyjne z powodu, który potrafią jasno sformułować. Jeśli nie możesz podać tego powodu, to badanie jest sygnałem wartym uwagi.

Zespoły z Wielkiej Brytanii i UE będą pytać o ustawę dotyczącą sztucznej inteligencji, więc krótka streszczenie będzie przydatne. Traktuj je jako materiał informacyjny, a nie poradę prawną, i sprawdź aktualną wersję tekstu przed oparciem się na jakimkolwiek terminie.

Digital Omnibus on AI, oficjalnie Regulacja (UE) 2026/1744, ukazała się w Dzienniku Urzędowym 24 lipca 2026 roku i weszła w życie trzy dni później, 27 lipca. Przesunęła termin wprowadzenia obowiązków dotyczących systemów o wysokim ryzyku z 2 sierpnia 2026 roku na 2 grudnia 2027 roku. W przypadku systemów sztucznej inteligencji wbudowanych w produkty objęte Załącznikiem I nowym terminem jest 2 sierpnia 2028 roku.

Obowiązki związane z przejrzystością określone w artykule 50 nie zostały odroczone i obowiązują od 2 sierpnia 2026 roku, zgodnie z pierwotnym planem. Dla systemów wprowadzonych na rynek wcześniej obowiązek oznakowania zgodnie z artykułem 50(2) wchodzi w życie 2 grudnia 2026 roku.

Narzędzia wspierające audytorów i wymagające ludzkiego zatwierdzenia zazwyczaj nie podlegają Rozporządzeniu Aneksu III, ale warto ocenić własny przypadek użycia: jeśli jakikolwiek komponent wpływa na decyzje rekrutacyjne lub zdolność kredytową, znajduje się w zakresie obowiązywania przepisów. Nic z tego nie wpływa na GDPR, które reguluje dane klientów przepływające przez system, niezależnie od tego, jak Akt o sztucznej inteligencji klasyfikuje ten system.

Popyt jest rzeczywisty. W badaniu przeprowadzonym przez Wolters Kluwer 39% z 4 214 specjalistów od audytu wewnętrznego stwierdziło, że już korzysta z sztucznej inteligencji, a kolejne 41% planuje to zrobić w ciągu roku.

Etapowy plan budowy takiego systemu

Dla zespołu rozpoczynającego pracę nad takim systemem zalecana kolejność działań jest następująca:

1. Rozwijaj system na najtańszym poziomie dostępnym, który przejdzie Twoje testy. Rejestruj każde wezwanie modelu, umożliwij praktykującym audytorom jego używanie podczas rzeczywistego okresu szczytu obłożenia, a dopiero później przystępuj do dalszej optymalizacji.

Zbadaj logi. Zidentyfikuj dwa lub trzy typy połączeń, które odpowiadają za większość tokenów, i sprawdź, czy są one powtarzalne oraz ograniczone schematem. Prawie zawsze tak jest.

Dopasuj tylko te połączenia. Na początku umieść je na infrastrukturze serverless, pozostaw triage, tworzenie projektów i odpowiadanie na pytania modelowi frontier, a przed oboma dodaj router.

Zastosuj dedykowane GPU tylko wtedy, gdy ilość zapytań lub wymogi umowne zmuszają do takiego kroku, a nie wcześniej.

Trzy z tych czterech faz kosztują mniej niż to, co wiele zespołów wydaje już od pierwszego dnia.

Główne wnioski

• Obecne modele frontier na ogół nie mogą być dopasowywane, więc rzeczywistym wyborem jest model o otwartych wagach z adapterem LoRA lub API hostowane.

W procesach przetwarzania dokumentów kilka powtarzalnych wywołań związanych ze schematem pochłania większość tokenów; analiza kosztów powinna zacząć się właśnie od tego.

Kierowanie tych wywołań do najtańszego, odpowiednio sprawdzonego poziomu usług oszczędza znacznie więcej niż dopasowywanie modeli, a realizacja zajmuje godziny, a nie tygodnie.

Dopasowywanie modeli ma sens dzięki ścisłemu przestrzeganiu schematu i zasad lokalizacji danych, a nie ze względu na rachunek za tokeny.

Obliczenia potrzebne do szkolenia modeli są tanie; prawdziwymi kosztami są dane z etykietami, ocena oraz operacje.

Zapisuj wywołania związane z generowaniem logów od samego początku, aby przyszłe dopasowywanie modeli mogło opierać się na dostępnych dowodach.

Ceny, opcje lokalizacji oraz terminy regulacyjne zmieniają się szybko; przed ustaleniem budżetu sprawdź wszystkie dane na aktualnych stronach dostawcy oraz oficjalnych dokumentach.

Pierwotne pytanie nie dotyczyło nigdy konfrontacji małego modelu z modelem zaawansowanym. Chodziło o to, które z waszych zapytań rzeczywiście wymagają rozumowania. Odpowiedziawszy na to pytanie, kwestia kosztów w dużej mierze sama się rozwiązuje.

Literatura pokrewna

• Mapping RAG: Etapy pipeline’a, komponenty podstawowe oraz różne warianty — Dowiedz się, jak działa proces generacji wzbogaconej o informacje z zewnętrznych źródeł od początku do końca, jakie komponenty potrzebuje system RAG oraz jak liczne warianty tego rozwiązania pasują do jednej struktury.

Bezpieczna zamiana modeli LLM: etykiety ludzkie, metryki na każdym kroku, ustawienia wysiłku — Jak przenieść wieloetapowy pipeline LLM na nowsze modele bez konfrontacji z wyimaginowanymi regresjami: ludzkie dane referencyjne, metryki na każdym kroku, przestarzałe prompty oraz ocena wysiłku potrzebnego do rozumowania.