Klucz, który wymienia się bez wydania nowej wersji
Klucz leży w konfiguracji i aplikacja bierze go stamtąd przy starcie. Kiedy trzeba go unieważnić, wymiana jest wpisem w konfiguracji i nie czeka, aż ktoś zdąży wypuścić aplikację jeszcze raz.
Maciej Nuzia · Integracje AI/LLM
Integruję modele AI z aplikacjami i obsługuję limity, koszty oraz awarie dostawcy
Wywołanie modelu na produkcji wymaga więcej niż klucza i promptu. Trzeba obsłużyć czas oczekiwania, limity zapytań, ponowienia i koszt każdego wywołania. W tej warstwie mieszczą się też testy pokazujące, czy zmiana modelu albo promptu wpłynęła na odpowiedzi.
Ta strona dotyczy modeli wołanych u dostawcy przez API. Model postawiony na Twoim własnym sprzęcie to inna robota.
Produkcja
Prototyp działa przy jednym wywołaniu. Produkcja stawia więcej wymagań
Na produkcji wywołań jest kilka naraz, część wraca z odmową dostawcy, a przy części odpowiedź nie przychodzi wcale. Do tego faktura na koniec miesiąca: jedna kwota, którą ktoś w firmie próbuje potem rozpisać na funkcje aplikacji. Wszystkie te rzeczy rozgrywają się na serwerach dostawcy.
- klucz siedzi w kodzie, bo na starcie tak było najszybciej
- przy większym ruchu dostawca odsyła część wywołań i nikt tego nie przewidział
- rachunek przychodzi jedną kwotą, bez podziału na to, co go podniosło
- prompt poprawiano wprost na produkcji i nikt nie wie, jak brzmiał w zeszłym tygodniu
Dla kogo
Dla zespołów przenoszących prototyp AI na produkcję
Zwykle jest już klucz, jest prompt i jest jedna funkcja, która komuś w firmie odpowiada. Potem przychodzi pełny ruch, awaria u dostawcy i rachunek na koniec miesiąca. Od tego miejsca zaczynam.
- Zespoły z prototypem gotowym na produkcję
- Produkty SaaS z modelem w środku
- Aplikacje, w których model odpowiada użytkownikowi na żywo
- Działy IT, które przejęły gotową integrację
- Firmy stojące na jednym dostawcy
- Zespoły płacące za wywołania od kilku miesięcy
Warstwa połączenia
Co trzeba obsłużyć wokół każdego wywołania
Odmowa, która przychodzi dopiero pod obciążeniem
Dostawca liczy zapytania w oknie czasu i nadmiar odsyła z odmową. Przy rosnącym ruchu wywołania ustawiają się w kolejce i wracają z odstępem, bo natychmiastowe ponowienie dostaje tę samą odmowę.
Cisza po drugiej stronie
Dostawca miewa przerwy i aplikacja musi mieć na nie własne zachowanie: co widzi wtedy użytkownik i co dzieje się z pracą, która czekała na odpowiedź.
Kto zmienił prompt i od kiedy
Prompt jest częścią systemu i leży w repozytorium razem z kodem. Zmiana przechodzi tę samą drogę co poprawka w aplikacji, więc przy każdej wersji stoi nazwisko i data.
Pytania, na które znasz odpowiedź z góry
Lista pytań z oczekiwaną odpowiedzią, przechodzona przy każdej zmianie promptu i przy zmianie modelu. Bez niej poprawka promptu jest wdrożeniem na wyczucie.
Dziennik wywołań
Co poszło do modelu, co wróciło, jak długo trwało i ile kosztowało. Po tygodniu to jedyne miejsce, w którym da się rozstrzygnąć spór o jedną konkretną odpowiedź.
O tym, co model ma w firmie robić, piszę osobno. Odpowiadanie z dokumentów opisuje RAG dla firm, wpisy w kartotece klienta integracja ChatGPT z CRM, a czynności biurowe automatyzacja procesów. Pod każdym z nich stoi ta sama warstwa połączenia.
Przed pierwszym ruchem
Przed uruchomieniem ustalam, co aplikacja zrobi bez odpowiedzi modelu
Kolejność wynika z jednego: warunki narzuca tu dostawca.
01
Miejsce, w którym stanie wywołanie
Oglądam kod w tym punkcie, z którego poleci zapytanie, i pytam, czy użytkownik czeka wtedy przy ekranie, czy robota idzie w tle. Od tego zależy dopuszczalne opóźnienie i to, czy cokolwiek da się odłożyć na kolejkę.
02
Konto, klucze i granica wydatku
Klucze rozdzielam, inny na testy i inny na produkcję, oba zakładane na Twoim koncie. Zanim ruszy prawdziwy ruch, sprawdzam, jakie ograniczenia wydatku i powiadomienia daje Twój dostawca, i ustawiam to, na co pozwala.
03
Wywołanie, ponowienie i kolejka
Wywołanie dostaje czas, po którym przestaję na nie czekać, i ponowienie z odstępem. To, przy czym nikt nie stoi, idzie do kolejki i wraca własnym tempem. Każde ponowienie kosztuje osobno, więc powtarzają się wyłącznie te wywołania, o których wiadomo, że nie doszły.
04
Zestaw przypadków i dziennik
Zanim cokolwiek pójdzie na produkcję, składam zestaw przypadków z oczekiwaną odpowiedzią przy każdym. Od tego momentu żadna zmiana promptu ani modelu nie wchodzi bez przejścia przez ten zestaw. Po starcie zaglądam do dziennika wywołań: co wróciło z błędem, co trwało najdłużej i gdzie zbiera się koszt.
Technologie
Połączenie z dostawcą trzymam w jednym module
Wywołania trzymam w jednym miejscu, a reszta aplikacji rozmawia już tylko z nim. Przy zmianie modelu przepisuje się wtedy ten moduł, a prompty pisze się pod nowy model od nowa, bo każdy czyta je po swojemu.
- OpenAI API
- Claude / Anthropic
- REST / GraphQL
- Node.js
- Python
- PostgreSQL
- Kolejki i ponowienia
- Webhooki
- AWS
Warunki dostawcy
Dostawca może zmienić warunki działania integracji
Wersja modelu z terminem
Dostawcy wycofują starsze wersje modeli, a termin ogłaszają sami. Po przesiadce na nowszą część odpowiedzi wypada inaczej, czasem lepiej. Po to właśnie trzymam zestaw przypadków: żeby ta różnica wyszła u mnie, zanim wyjdzie u Twojego użytkownika.
Ponowienie policzone dwa razy
Twoja strona przestaje czekać i wysyła zapytanie jeszcze raz. U dostawcy pierwsze przeszło i zostało policzone. Dlatego wywołanie, które coś zmienia albo kosztuje, dostaje swój znacznik, po którym da się je rozpoznać jako to samo zlecenie.
Klucz w historii repozytorium
Klucz wpisany kiedyś do repozytorium zostaje w jego historii także po usunięciu z pliku, więc jedynym wyjściem jest unieważnienie go u dostawcy. Tak samo pilnuję logów, bo przy pełnym zapisie wywołań trafia do nich to samo, co poszło do modelu.
FAQ
Pytania o działanie i koszty integracji
Na czyim koncie u dostawcy działa taka integracja?
Na Twoim. Konto i klucze zostają w firmie, która płaci za wywołania, więc zużycie widzisz w panelu dostawcy bez pytania kogokolwiek. Klucz, który wyciekł, trzeba unieważnić od razu i dlatego nie trzymam go w kodzie. Kto ma do niego dostęp, decydujesz po swojej stronie.
Co robi aplikacja, kiedy model nie odpowiada?
To ustalamy przed wdrożeniem, bo dostawca ma swoje przerwy i swoje limity zapytań w oknie czasu. Aplikacja czeka na odpowiedź do wyznaczonej granicy, a potem sięga po nią jeszcze raz, po odczekaniu. Kiedy dalej nic nie wraca, użytkownik dostaje komunikat, a sprawa idzie do kolejki albo do człowieka. Co dokładnie ma zobaczyć, zależy od tego, czy stoi przy ekranie, czy praca idzie w tle.
Da się później przełożyć to na inny model?
Wywołania dostawcy zamykam w jednym module, więc przy zmianie przepisuje się ten moduł. Prompty pisze się pod nowy model od nowa i przechodzi z nimi przez zestaw przypadków. Ile odpowiedzi wypadnie po zmianie inaczej, widać dopiero po tym przejściu i dopiero wtedy wiadomo, ile taka przesiadka kosztuje.
Od czego zależy rachunek za wywołania?
Od liczby wywołań i od objętości tekstu w każdym z nich. Najciężej waży kontekst doklejany do pytania: dokumenty, historia rozmowy, instrukcja dla modelu. Wszystko to jedzie do dostawcy przy każdym zapytaniu i wszystko jest liczone. Stawek u dostawcy tu nie przepisuję, bo cennik należy do niego i zmienia się bez mojego udziału. Wysokość rachunku widać na bieżąco w dzienniku wywołań, z kosztem przy każdym wpisie.
Co z każdego wywołania zostaje w dzienniku?
Tyle, ile ustalimy, i jest to osobna decyzja. Zapis całych zapytań razem z odpowiedziami pomaga, kiedy ktoś pyta, dlaczego odpowiedź brzmiała właśnie tak. Ma to swoją cenę: treść wysłana do modelu leży wtedy także w Twoich logach i obejmują ją te same zasady co dane w bazie. Drugie wyjście to same znaczniki: wersja promptu, objętość, czas i koszt. Ten wybór wraca potem przy każdym pytaniu o konkretną odpowiedź sprzed tygodnia.
Jedno zdanie
Pokaż mi miejsce, w którym aplikacja wywołuje model
W mailu wystarczy zdanie o tym, gdzie dziś stoi wywołanie modelu i co widzi użytkownik, kiedy odpowiedź nie wraca. Na tyle da się już powiedzieć, od czego bym zaczął. Narzędzie do wyceny rozkłada na części całe projekty, więc sięgnij po nie, kiedy razem z podłączeniem modelu ma powstać reszta aplikacji.