15 — Scraping, API AI i konfigurowalne chatboty
Pozyskiwanie danych z sieci i delegowanie zadań do AI to dziś rdzeń wielu produktów. Rób to skutecznie, tanio i z kontraktem — nie magią. Warstwę operacyjną (timeouty, backoff, rotacja, kwoty, wznawialność) trzyma → 14; ten rozdział jest o tym, jak używać tych mocy jako funkcji produktu: skąd brać dane, jak delegować zadania do AI i jak zbudować asystenta, którym da się sterować bez deployu.
Skuteczny scraping — dane z sieci
- Najpierw oficjalne źródło. API — Umówiony sposób, w jaki dwa programy gadają ze sobą — jeden prosi, drugi odpowiada w ustalonym formacie. Przez API Twoja aplikacja łączy się z cudzymi usługami (płatności, mapy, AI). Klucz API traktuj jak hasło., feed, eksport, sitemap — Scraping — Automatyczne zbieranie danych ze stron internetowych przez program zamiast ręcznego kopiowania. Potężne do pozyskiwania danych, ale wymaga kultury: szanuj cudze zasady (robots.txt), nie przeciążaj serwera. HTML to ostateczność, nie pierwszy ruch. Oficjalny kontrakt nie pęka przy każdym redesignie strony.
- Szanuj źródło. Respektuj
robots.txt/ToS, rozsądny throttle, identyfikuj się. Cel to dane, nie DoS — agresywny scraper to problem prawny i etyczny (→ 09). - Parsuj odpornie. Selektory padają przy redesignie — waliduj kształt wyniku, nie tylko status (klasyczne „200 + strona błędu”, → 14). Drift selektora → alarm, nie ciche zera.
- Normalizuj u wejścia. Dane z sieci są brudne: fuzzy-match i dedup do słowników lookup, Slug — Czytelna, krótka część adresu strony, opisująca jej treść słowami zamiast tajemniczego numeru. Lepszy dla człowieka i SEO; trwały slug nie psuje linków przy zmianach., jedno źródło prawdy (→ 11). Surowiec wpada, czysty rekord zostaje.
- Inkrementalnie. Pobieraj deltę (co się zmieniło od ostatniego razu), nie cały katalog co noc — taniej, szybciej, mniej obciąża źródło. Checkpoint i wznawialność → 14.
- Idempotencja — Cecha operacji, którą można uruchomić wiele razy, a wynik jest zawsze taki sam — bez dublowania. Kluczowa przy skryptach i zdarzeniach: ponowne uruchomienie nie psuje danych. Jak włącznik „ON”. loadery. Ponowny import tych samych danych nie tworzy duplikatów (→ 04).
Anty-wzorce
- 🚫 Scraping zamiast API, które istnieje — kruchość bez powodu.
- 🚫 Selektor bez walidacji kształtu — cicha awaria zalewa bazę śmieciem/zerami.
- 🚫 Pełny re-scrape codziennie zamiast delty — marnotrawstwo i ryzyko bana.
- 🚫 Brak throttle/identyfikacji — DoS dla źródła, problem prawny dla Ciebie.
API AI do konkretnych zadań — nie do wszystkiego
- LLM tam, gdzie kod deterministyczny nie da rady: ekstrakcja z nieustrukturyzowanego tekstu,
klasyfikacja, podsumowanie, normalizacja opisów, generowanie treści. Nie do tego, co zrobi
regex,SQLczy zwykła funkcja — to drożej, wolniej i mniej pewnie. - Dobierz model do zadania. Tani/szybki do prostych (klasyfikacja, ekstrakcja), mocny do złożonego rozumowania. Claude jako default (→ 08). Mierz koszt i latencję, nie zgaduj.
- Wymuś kontrakt wyjścia. Struktura (JSON schema / tool use), walidacja i retry przy niezgodności — nie parsuj prozy na nadzieję. Wyjście LLM traktuj jak niezaufane wejście (→ niżej, guardrails).
- Cache — Tymczasowo zapamiętany wynik, żeby nie liczyć tego samego od nowa przy każdym pytaniu. Przyspiesza aplikację, ale bywa pułapką: nieświeży cache pokazuje stare dane. + idempotencja. Te same wejścia → zapisany wynik; nie wołaj LLM w pętli po tym, co się nie zmienia. Drogie wywołania to koszt i latencja (→ 13).
- Kwoty i budżet. Limit per user/Endpoint — Pojedynczy „adres” w API, pod który wysyłasz zapytanie po konkretną rzecz (np. listę zamówień). Aplikacje rozmawiają przez endpointy — jeden endpoint = jedna funkcja, którą udostępniasz., monitoring kosztu, twarda kwota na płatnym API (→ 14).
- Batch, gdy nie trzeba realtime. Wzbogacanie danych offline w pipelinie z checkpointem (→ 14) bije wołanie LLM na żywo w żądaniu użytkownika.
Anty-wzorce
- 🚫 LLM do tego, co zrobi
regex/SQL— koszt i niepewność tam, gdzie wystarczy kod. - 🚫 Brak kontraktu wyjścia — parsujesz wolną prozę i modlisz się o format.
- 🚫 Brak cache drogich wywołań — rachunek rośnie liniowo z ruchem.
- 🚫 Ślepe zaufanie do wyjścia jako kodu/SQL — Język zapytań do bazy danych — sposób, w jaki „pytasz” bazę o dane albo je zmieniasz. Uniwersalny standard rozmowy z bazą. Źle napisane zapytanie potrafi zamulić całą aplikację./HTML — wektor wstrzyknięcia.
Konfigurowalne chatboty — asystent jako funkcja
- Persona i zasady = konfiguracja, nie kod. System prompt, zakres, ton, granice trzymaj jako dane (plik/baza), wersjonowane w git — iterujesz asystenta bez deployu. „Zaszyty” prompt w kodzie to martwa konfiguracja.
- Grounding obowiązkowy. Asystent odpowiada z Twoich danych (kontekst z bazy / RAG), nie z pamięci modelu. Cytuj źródło (→ 11). Halucynacja na cenie/fakcie = bug, nie „cecha AI”.
- Zdefiniuj zakres i odmowę. Co asystent robi i czego nie robi; bezpieczne „nie wiem”/„to poza moim zakresem” zamiast zmyślania. Pewność siebie modelu ≠ poprawność.
- Streaming — Wysyłanie dużej odpowiedzi kawałkami, na bieżąco, zamiast ładowania wszystkiego naraz do pamięci. Aplikacja nie zatyka się przy wielkich danych — użytkownik widzi wynik szybciej. UX. Odpowiedź token-by-token (SSE), historia rozmowy, jasne limity (→ 13, 14).
- Bezpieczeństwo (Prompt injection — Atak na AI: ktoś wplata w tekst ukrytą instrukcję, żeby asystent zrobił coś wbrew zasadom. Jeśli AI czyta cudze treści (maile, strony), traktuj je jak niezaufane — inaczej da się nim manipulować.). Treść użytkownika i dane z sieci to dane, nie instrukcje. Nie wykonuj akcji side-effect z czatu bez potwierdzenia, nie wyciekaj sekretów ani promptu systemowego (→ 09).
- Eval jak testy. Golden set pytań kontrolnych; zmiana promptu → przepuść przez niego i mierz regresje (→ 03). Prompt bez evala dryfuje po cichu.
- Prawo. Disclaimer („to nie porada specjalistyczna”), RODO / GDPR — Unijne prawo o ochronie danych osobowych — jak wolno zbierać, trzymać i usuwać dane użytkowników. Dotyczy każdej aplikacji z danymi ludzi. Lepiej wpisać zgody i retencję od początku niż płacić kary później. przy zapisie rozmów i danych (→ 09).
Anty-wzorce
- 🚫 Persona zaszyta w kodzie — każda zmiana tonu to deploy zamiast edycji konfigu.
- 🚫 Brak groundingu — asystent „pewnie” zmyśla fakty/ceny.
- 🚫 Brak limitu/kwoty — czat to otwarty rachunek i wektor nadużyć (→ 14).
- 🚫 Akcje z czatu bez potwierdzenia — model wykonuje nieodwracalne na słowo użytkownika.
- 🚫 Traktowanie treści użytkownika jako instrukcji — prompt injection wycieka prompt/sekrety.
Dla nowych projektów
Jeśli produkt żyje z danych z sieci: zacznij od oficjalnego źródła, dołóż walidację kształtu i idempotentny loader zanim zbierzesz pierwszy tysiąc rekordów. Jeśli używasz AI: kontrakt wyjścia i cache od pierwszego wywołania, kwota od pierwszego użytkownika. Asystenta projektuj jako konfigurowalny i ugruntowany od początku — system prompt jako dane, golden set jako test (→ 03), limit jako reguła (→ 14). Reszta dorasta z projektem.