Uodpornienie generatora digestu: fallbacki Gemini, smart number gate i optymalizacja kosztów CI

Ostatnia doba w repozytorium portfolio upłynęła pod znakiem stabilizacji automatyzacji i optymalizacji modułu digest. Przy pracy z zewnętrznymi API modeli językowych niezawodność i kontrola kosztów to absolutny priorytet, dlatego przebudowałem mechanizmy awaryjne oraz bramki walidacyjne.

Co zrobiłem

• Wprowadziłem odporne fallbacki dla Gemini: Zbudowałem obsługę wielu modeli (multi-model fallbacks) z automatycznym wykrywaniem dostawcy na podstawie klucza GEMINI_API_KEY oraz ustawiłem sztywny limit czasu (90s timeout).
• Rozbudowałem bramkę walidacji liczb (smart number gate): Do zestawu uziemionych liczb (grounded numbers) dodałem parametr windowHours, zapobiegając fałszywym alarmom przy weryfikacji danych liczbowych.
• Zoptymalizowałem koszty wykonania (perf): Przeniosłem wykonywanie deterministycznych bramek sprawdzających przed kosztowny krok płatnego przeglądu (paid review pass).
• Uporządkowałem CI/CD: Dodałem skrypt check:i18n do package.json, włączyłem weryfikację i18n do pipeline'u CI oraz skonfigurowałem tożsamość autora git w środowisku uruchomieniowym runnera CI i w gitFlow. Wykonałem również rutynowy audit self-check.

Dlaczego to ważne

• Odporność na awarie dostawcy: Mechanizm multi-model fallback z timeoutem 90 sekund gwarantuje, że chwilowa niedostępność jednego modelu lub zacięcie API nie blokuje całego procesu generowania digestu.
• Niższe koszty operacyjne: Uruchamianie darmowych, deterministycznych sprawdzianów przed przekazaniem danych do płatnego modelu sprawia, że nie płacimy za wywołania API w sytuacji, gdy dane i tak nie przejdą podstawowej walidacji.
• Precyzja bez fałszywych odrzuceń: Dostarczenie wartości takich jak windowHours do kontekstu "znanych liczb" uniemożliwia modelowi generowanie zmyślonych statystyk, nie blokując jednocześnie poprawnych danych o oknie czasowym.

Czego się nauczyłem

• Ochrona budżetu wymaga kolejkowania walidacji. Płatny krok LLM powinien być ostatnim etapem pipeline'u. Jeśli kod da się zwalidować statycznie lub deterministycznym skryptem, trzeba to zrobić na samym początku.
• Weryfikacja "grounding" liczb potrzebuje pełnego kontekstu. Wprowadzenie bramki odrzucającej liczby spoza zadanego kontekstu działa świetnie protiv halucynacjom, ale wymaga jawnego przekazania wszystkich zmiennych systemowych (jak ramy czasowe windowHours), inaczej automatyka odrzuci poprawne wpisy.