Rzemiosło · The Craft
Czym jest The CraftPoziomyJak zacząćRozdziały Szukaj Pobierz PLEN
Level 3 · Kodeks ~4 min czytania

W jednym zdaniu: Jak skutecznie, tanio i z kontraktem pozyskiwać dane z sieci, delegować zadania do AI i budować chatbota sterowalnego bez deployu.

Ten rozdział po ludzku

Rozdział o trzech mocach, które napędzają dziś wiele produktów: pobieranie danych z sieci (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.), delegowanie zadań do AI i chatboty. Robi się je „z kontraktem”, nie magią.

Scraping — najpierw oficjalne źródło. Jeśli jest 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 albo eksport — bierzesz je; ręczne „zdzieranie” HTML to ostateczność, bo pęka przy każdym przeprojektowaniu strony. I szanuj źródło: respektuj robots.txt, nie zalewaj serwera zapytaniami — cel to dane, nie DoS.

AI do tego, czego zwykły kod nie ogarnie. Model językowy świetnie wyciąga sens z nieustrukturyzowanego tekstu, klasyfikuje, streszcza. Ale nie używaj go do tego, co zrobi regex albo SQL — to drożej, wolniej i mniej pewnie. I zawsze wymuś format odpowiedzi (np. JSON), zamiast parsować prozę „na nadzieję”.

Chatbot to funkcja produktu, nie zabawka. Jego osobowość i zasady trzymaj jako konfigurację (plik/baza), nie zaszyte w kodzie — wtedy zmieniasz ton bez wdrożenia. I musi odpowiadać z Twoich danych (grounding), a nie z pamięci modelu — inaczej „pewnie” zmyśli cenę czy fakt.

Przykład zagrożenia (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ść od użytkownika albo ze strony traktuj jak dane, nie polecenia. Jeśli chatbot ślepo wykona instrukcję ukrytą w cudzym tekście, ktoś może nim sterować wbrew Twoim zasadom.

Doczytaj: czym jest web scraping · RAG — grounding odpowiedzi AI · prompt injection.

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, SQL czy 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.

Treść doktryny prowadzimy po polsku.