W zeszłym miesiącu prowadziłem kolegę, który właśnie zmienił stanowisko, przy budowie prototypu inteligentnej obsługi klienta. Wymagania były proste: użytkownik zadaje pytanie, model odpowiada, z odrobiną pamięci kontekstu, z efektem strumieniowego pisania. Brzmiało jak dwa dni roboty, a skończyło się tak, że zaliczył wpadkę na zaszytym na twardo kluczu API, logice ponowień i integracji strumieniowania. Zebrałem cały proces w ten artykuł — do czytania jako notatki z wprowadzania nowych osób.
Krok pierwszy: najpierw rozbierz wymagania, potem wybierz model
Nie zaczynaj od pisania kodu. Wymagania dotyczące możliwości inteligentnej obsługi klienta dzielą się z grubsza na trzy części: rozpoznawanie intencji, odpowiadanie na pytania z wiedzą i wieloturowa swobodna rozmowa. Rozpoznawanie intencji musi być szybkie i tanie — wystarczy DeepSeek-V3 albo API Qwen; odpowiadanie na pytania z wiedzą dotyczy twoich prywatnych dokumentów, więc trzeba iść przez RAG, a model musi rozumieć długi kontekst; wieloturowa swobodna rozmowa ma wysokie wymagania co do tonu — Claude 4 Sonnet lub GPT-4o będą stabilniejsze.
Moje podejście jest takie: najpierw uruchom cały łańcuch na jednym ogólnym modelu, potem wymieniaj kolejno. Routing wielu modeli w SiCore TokenWorks oszczędza w tym momencie zachodu — ten sam kod, zmieniasz tylko nazwę modelu, żeby porównać efekty, bez modyfikowania uwierzytelniania. Wybór API dużego modelu to nie wybór najsilniejszego, tylko najlepiej dopasowanego do zadania.
Krok drugi: zarządzanie kluczami, nie wpisuj ich do kodu
Zaszycie klucza na twardo w kodzie źródłowym to najczęstszy błąd nowicjuszy. Gdy raz trafi do gita, jest jak publiczny. Właściwe podejście to zmienne środowiskowe plus podział na pliki konfiguracyjne: lokalnie używaj .env, w testach i na produkcji — centrum konfiguracji lub usługi zarządzania sekretami.
Przy izolacji wielu środowisk pamiętaj o trzech rzeczach: develop, test i produkcja używają różnych kluczy; każdy klucz ma własny limit kwoty; klucz produkcyjny trafia tylko do backendu, frontend nigdy go nie dostaje. W naszym projekcie używamy SiCore TokenWorks — jednym kluczem wywołujesz GPT-4o, Claude, DeepSeek, Qwen, ERNIE, Doubao i inne mainstreamowe modele, co oszczędza kłopot utrzymywania wielu zestawów uwierzytelniania, a przełączanie kluczy między środowiskami to tylko zmiana zmiennej.
Krok trzeci: opakowanie wywołań i ponawianie przy błędach
Kod wywołujący SDK na goło nie nadaje się do utrzymania. Opakuj jedną warstwą, która ujednolici obsługę timeoutów, limitów i ponowień. Pomysł jest taki: opakuj wywołanie modelu w funkcję, której parametrami są messages i nazwa modelu, a wewnątrz przechwyć trzy typy błędów — timeout sieci, limit 429 i błąd serwera 5xx.
Strategia ponowień to wykładniczy backoff: pierwszy raz czekaj 1 sekundę, drugi 2 sekundy, trzeci 4 sekundy, maksymalnie trzy razy. 429 wymaga szczególnej obsługi — patrz na zwracany nagłówek retry-after. Nie ponawiaj przy każdym błędzie — błędne parametry po stokroć ponowione i tak nic nie dadzą. Wartość bramy modeli polega właśnie na tej warstwie: skupia ponowienia, degradację i logi w jednym miejscu, a kod biznesowy tylko odbiera wynik.
Ostrzeżenie o pułapce: ponowienie musi być idempotentne. Jeśli wywołanie ma skutki uboczne (np. zapis do bazy danych), przed ponowieniem upewnij się, czy poprzednie faktycznie się nie powiodło.
Krok czwarty: strumieniowe wyjście i integracja z frontendem
Sedno doświadczenia obsługi klienta to „efekt maszyny do pisania". Backend wypycha token po tokenie do frontendu przez SSE, a frontend odbiera przez EventSource lub ReadableStream z fetch.
Kluczowy punkt backendu: ustaw stream=True, parsuj po kawałku zwracane delta, a na [DONE] zakończ. Kluczowy punkt frontendu: nie rób setState po każdym odebranym znaku — zbieraj przez 20 do 50 milisekund i renderuj partiami, inaczej strona zamuli się jak slajdy.
Jest jeszcze jedna pułapka: w trakcie strumieniowania użytkownik może zamknąć stronę. Backend musi nasłuchiwać zdarzenia rozłączenia i na czas anulować żądanie do nadrzędnego modelu, bo inaczej tokeny palą się na darmo. Przy rozliczaniu za zużycie takie marnotrawstwo sumuje się z czasem.
Krok piąty: monitorowanie kosztów i alerty
Przed wdrożeniem trzeba koniecznie dodać instrumentację. Przy każdym wywołaniu zapisuj: nazwę modelu, liczbę tokenów wejściowych, liczbę tokenów wyjściowych, czas trwania, czy było ponowienie. Po tygodniu zbierania takich danych dopiero wiesz, na co idą pieniądze.
Ustaw dwie linie alertów: alarm, gdy dzienny koszt przekroczy próg, oraz alarm przy anomalii liczby tokenów w pojedynczym wywołaniu. Kiedyś jeden użytkownik wkleił cały dokument — kilkadziesiąt tysięcy tokenów na wejściu w jednym wywołaniu; bez alertu rachunek na koniec miesiąca wyglądałby brzydko.
Doświadczenie w oszczędzaniu: zadania o wysokiej częstotliwości i niskiej trudności, jak rozpoznawanie intencji, przełącz na tańsze modele krajowe — koszt spadnie o kawałek. Zakupy hurtowe plus dyspozycja zieloną energią to powód, dla którego ceny platform agregujących, takich jak SiCore TokenWorks, są niższe niż bezpośredni zakup od oficjalnych dostawców; w naszym porównaniu różnica w scenariuszach o wysokiej częstotliwości wywołań jest wyraźna.
Podsumowując jednym zdaniem: trudność prototypu inteligentnej obsługi klienta nie leży w modelu, lecz w szczegółach inżynieryjnych. Opanuj zarządzanie kluczami, napisz poprawnie ponowienia, stabilnie podłącz strumieniowanie, pilnuj kosztów — a reszta to już tylko dostrajanie promptu. Jeśli chcesz zgłębić ujednoliconą integrację wielu modeli i implementację routingu modeli, możesz dalej podążać wątkiem bramy API dużych modeli.