As jy in 'n maatskappy werk wat webdata gebruik, weet jy seker dat dit net die eerste laag van 'n meer komplekse produk is. In werklikheid is webskrape data tradisioneel in lêers of databasisse (cloud-opslagbakke, data-meer of data-opslaghuise) gestoor en dan geanalyseer met behulp van Business Intelligence (BI) gereedskap, beide kommersiële en proprietêre. Byvoorbeeld, 'n span kan produkpryse of kliëntebeoordelings van die web skraap, die ruwe data as CSV / JSON-lêers bewaar, laai dit in 'n SQL-data-opslag, en gebruik dan BI-platforms soos Tableau of Power BI om dashboards en verslae te skep. Moderne webskrape oplossings maak selfs data in gestrukture Vandag verander groot taalmodelle (LLM's) hierdie paradigma. In plaas daarvan om slegs op statische dashboards of SQL query's te vertrou, kan organisasies AI-assisteurs gebruik om insigte uit gekraapde data via natuurlike taalverwysings te kry. Met ander woorde, eerder as om 'n mens 'n query te skryf of 'n grafiek te interpreteer, kan 'n AI-assisteur direkte vrae oor die data beantwoord. Dink aan om jou ChatGPT-agtige koppelvlak te hê en 'n paar prompts te skryf om insigte te kry, die skep van die dashboard te omseil. Ek het hierdie soort benadering in verskeie produkte gesien voordat LLM's gekom het, maar met geen groot sukses nie. Die evolusionêre AI-landskap en die wekelijkse verbeterings wat ons Stel jou die vraag, in plaas van die regte dashboard of Excel-verslag deur jouself te vind om die antwoord te kry. Hierdie benadering belowe vinniger, meer intuïtiewe toegang tot inligting vir nie-tegniese gebruikers sonder die oorhoof van bou grafieke of skryf kode. Watter mededinger het die hoogste prys in die vorige kwartaal gehad? Natuurlik ontstaan 'n nuwe stel uitdagings: wat van hallusinasies? as ons nie die onderliggende getal van 'n antwoord sien nie, kan ons 100% seker wees dat die antwoord korrek is? In hierdie pos (en die volgende in die Lab-reeks), sal ons 'n eind-tot-end-projek bou waar ons sal begin deur die artikels in hierdie nuusbrief te skraap, hulle in 'n databasis te plaas wat geskik is vir AI-gebruik, hierdie kennis te herhaal, en dan 'n webtoepassing te publiseer wat 'n verrijkte weergawe van 'n GPT-model kan gebruik. Verbetering van LLM kennis Die integrasie van aangepaste data (soos jou gekraapde dataset) in 'n LLM kan hoofsaaklik op twee maniere gedoen word: deur Die model of die gebruik van , en elkeen van hierdie metodes het voor- en nadele. Laat ons sien hoe hulle verskil en watter benadering die beste vir ons gebruik geval kan wees. fine-tuning Retrieval-Augmented Generation (RAG) Fine-Tuning versus Retrieval-Verhoogde Generasie beteken opleiding die basis LLM op bykomende data sodat dit nuwe kennis absorbeer. In wese, jy neem 'n vooraf opgeleide model en voortgaan om dit op jou domein-spesifieke dataset te opleiding, die aanpassing van sy gewigte om daardie kennis in te voeg. Byvoorbeeld, as jy 'n versameling van tegniese artikels gekraap het, kan jy 'n LLM op daardie artikels verfijn. Fine-tuning word dikwels gedoen deur die model te verskaf met 'n groot stel vraag-antwoorde paartjies of teks passages uit jou data sodat dit leer om met daardie inligting te reageer wanneer dit relevant is. – die kennis word deel van sy parameters.Die volgende keer as jy die model vra, kan dit op hierdie gebakken-in inligting trek sonder om eksterne hulp te benodig. Fine-tuning intrinsically knows augmented from the inside neem 'n ander benadering: die model bly onveranderd, maar ons gee dit toegang tot 'n eksterne kennisbasis (gewoonlik deur middel van 'n vetorsoek). Die LLM genereer dan sy antwoord met die hulp van daardie aanvullende konteks. Vir boomers soos ek, oorweeg dit soos om 'n CD in die Neo se kop in die Matrix in te voer om nuwe vaardighede en bewegings te leer. In ons geval kan die kennisbasis 'n versameling gekraap webartikels in 'n gespecialiseerde databasis wees. RAG is soos 'n oop boek eksamen vir die LLM - op die query tyd kyk dit op die relevante "blad" van data en gebruik dit om 'n antwoord te formuler, eerder as om slegs op sy interne geheue te vertrou. Retrieval-Augmented Generation (RAG) retrieve relevant documents Soos jy kan voorstel, is een sleutelverskil waar die bykomende kennis bly: met fijnstyling word die kennis ingebed. (die gewigte van die model word opgedateer). Met RAG bly die kennis Fine-tuning is soortgelyk aan om die model nuwe feite permanent te leer, terwyl RAG is soos om die model uit te rus met 'n dinamiese biblioteek wat dit op die vlieg kan verwys. in the model itself external Die twee benaderings het verskillende voor- en nadele: Fine-Tuning: Once fine-tuned, the model can respond faster and more integratedly to new knowledge. It doesn't need lengthy prompts with documents each time. A well-fine-tuned model typically outperforms the base model on domain-specific questions because it has a deeper understanding of that niche terminology and content. Pros: Fine-tuning can be resource-intensive and time-consuming – you need sufficient training data and computing power (or budget if using a service). It also makes the model static concerning that training snapshot. If your scraped data changes or new information comes in, you’d have to fine-tune again to update the model. There’s also a risk of the model or overriding some of its original knowledge if not carefully managed. Importantly, fine-tuning means your data becomes part of the model’s parameters, which could be a privacy concern if the model weights are exposed or if using a third-party service to fine-tune (your data is uploaded for training). Last but not least, once the knowledge is embedded in the model, you cannot cite any article used to improve it. Cons: forgetting Retrieval-Augmented Generation (RAG): No need to modify the LLM itself – you leave the base model as-is and simply provide relevant context at query time. This makes updating or expanding the knowledge base easy: add or remove documents in your external index, and the model will use the latest data. It’s very flexible and (which can be more secure). RAG can reduce hallucinations by grounding answers in real sources – essentially, the model has the “receipts” to back up its answer. It also typically requires less upfront work than full fine-tuning; most effort goes into setting up the retrieval system. Pros: keeps your proprietary data external RAG introduces more moving parts – you need a system for embedding and indexing documents and retrieving them at runtime. At query time, you pay the cost in latency and token length for feeding documents into the model’s prompt. If the retrieved documents aren’t relevant (due to a bad query or vector mismatch), the answer will suffer. The LLM is also limited by its input size; if the documents plus question exceeds the model’s context window, you might have to truncate or select fewer documents. Additionally, the raw text of documents might influence the model's style, which could lead to less coherent or conversational answers unless you prompt it to refine the wording. Cons: Kortom, finetuning bakes in 'n gefokusde begrip, terwyl RAG toelaat real-time toegang tot kennis. vir ons gebruik geval van die integrasie van voortdurend opgedateerde skraap data, RAG lyk 'n beter benadering: jy kan voortdurend trek in nuwe web data en hê jou assistent gebruik dit onmiddellik eerder as periodiek heropleiding van die hele model. Voordat jy verder gaan, is dit die moeite werd om op te let dat fine-tuning en RAG nie mekaar uitsluit nie; hulle kan mekaar aanvul. Byvoorbeeld, jy kan 'n model fine-tune om sy toon aan te pas of die vermoë om instruksies te volg (of om kennis wat klein en statiese is, toe te voeg), en nog steeds gebruik RAG om dit toegang te gee tot 'n groter kennisbasis wat gereeld actualiseer. Gebruik 'n plaaslike model vs. 'n eksterne API Nog 'n oorweging is vir jou AI-assistent: 'n plaaslike (open-source) model wat jy jouself bestuur of 'n gehostede model via 'n API (soos OpenAI se GPT-3.5/GPT-4 of ander). what LLM to use – Modelle soos LLaMA 2, Mistral, of Falcon kan op jou eie bedieners uitgevoer word. . Jou gekraapde data verlaat nooit jou omgewing nie, wat belangrik is as dit sensitiewe inligting bevat. Jy kan dit vrylik op jou data afstemming of verander hoe dit werk. Kosteneens, die hardloop van 'n plaaslike model kan goedkoper wees vir groot volumes van vrae (geen API-vergoeding), maar jy moet belê in hardware of wolk-infrastruktuur om dit te hosting. Die nadeel is dat baie oop modelle nie die prestasie van die nuutste GPT's kon pas nie. Jy mag groter of meer gespesialiseerde modelle gebruik om vergelykbare prestasie te kry, wat kompleks kan wees om te bestuur. Daarbenewens is die instandhouding en opdatering van die model (en moontlik die vector databasis as on-prem) op jou. met 'n hoogs domeinspesifieke dataset en die kundigheid, kan 'n plaaslike model goed aangepas word om in daardie domein te uitstek, wat dit 'n sterk oplossing vir 'n "privaat GPT" maak. Local Open-Source LLMs control and privacy die – Met behulp van 'n API soos OpenAI se GPT-4 beteken jy hoef nie bekommerd te wees oor die uitvoering van die model nie; jy stuur net jou opdragte na hul diens en kry die voltooiing. Dit is baie gerieflik en gee jou gewoonlik toegang tot geavanceerde modelkwaliteit sonder infrastruktuurprobleme. Vir ons scenario kan jy RAG gebruik deur eenvoudig die afgeleë dokumente op jou opdrag te vooraf te stel en die API te vra om te antwoord. Die nadele hier verband hou met aanpassing en privaatheid. Jy is ook onderhewig aan die verskaffers se reëls (byvoorbeeld, hulle kan inhoudsfilters hê wat sommige skraapverwante vrae kan voorkom).Van 'n privaatheidsperspektief stuur jy jou data (vra en gevind konteks) na 'n derde party, so ek sal nie hierdie benadering voorstel vir sensitiewe of kopieregte data nie. External API LLMs (e.g. OpenAI’s) OpenAI, byvoorbeeld, kan jy dit doen op GPT4-o en GPT4-mini OpenAI, byvoorbeeld, kan jy dit doen op GPT4-o en GPT4-mini In die algemeen, as jou gebruik geval behels hoogs sensitiewe data of vereis volle beheer, word 'n plaaslike LLM aanbeveel ten spyte van die ekstra poging. As jou prioriteit is die beste moontlike taal vaardigheid en vinnige instelling, 'n gehost model soos OpenAI se kan die beter keuse wees. In die implementering van hierdie pos, sal ons illustreer gebruik OpenAI se GPT API vir eenvoud en gehalte, maar die opname stelsel wat ons bou, kan net so maklik voed in 'n oop bron model soos Llama2 via HuggingFace of LangChain biblioteke. Die opname meganisme (vektor databasis + soortgelykheid soek) bly dieselfde; slegs die uiteindelike antwoord-genererende model sou verskil. Ons sal die RAG-benadering gebruik met 'n OpenAI-model, wat goed in ooreenstemming is met voortdurend opgedateerde webdata en vermy die behoefte aan duur afstemming van werk. Skraap TWSC met Firecrawl is 'n web skraap masjien blootgestel as 'n REST API en SDK. Dit is spesifiek ontwerp om webwerwe in (in formate soos skoon teks of markdown), die hantering van al die swaar opheffing, soos crawling skakels, rendering JavaScript, en so aan. Die groot voordeel van Firecrawl is dat jy met een API-oproep 'n hele webwerf kan skraap. Vuurkrans LLM-ready data Vuurkrans Vuurkrans Vir The Web Scraping Club blog, sal ons sy sitemap gebruik om al die artikel URL's te ontdek. (Die blog word gehost op Substack, wat 'n XML-sitemap verskaf wat al die poste lys.) Firecrawl kan die webwerf sonder 'n sitemap kruip, maar gebruik dit as 'n beginpunt kan meer doeltreffend wees en verseker dat ons geen bladsye mis nie. Eerstens stel ons Firecrawl op deur sy Python SDK te installeer en met 'n API-sleutel te outentiek (in die veronderstelling dat jy aangemeld is en 'n sleutel verkry het): from firecrawl import FirecrawlApp import os os.environ["FIRECRAWL_API_KEY"] = "YOURKEY" # or load from .env app = FirecrawlApp() # Define the sitemap URL (we can loop this for multiple years if needed) map_result = app.map_url('https://substack.thewebscraping.club/sitemap.xml', params={ 'includeSubdomains': True }) print(map_result) for article in map_result['links']: if '/p/' in article: print(article) response = app.scrape_url(url=article, params={'formats': [ 'markdown' ]}) Met net 'n paar reëls van kode, is ons artikels reeds in Markdown-formaat. Kies 'n Vector Database vir RAG a is 'n sleutelkomponent van die implementering van RAG. Dit stoor die embeddings van jou dokumente (vektorverteenwoordigings) en laat 'n vinnige soortgelykheidsoek toe om relevante dokumente vir 'n gegewe query-embedding te kry. Baie opsies is beskikbaar, insluitend open-source biblioteke en bestuurde wolkdienste, maar vir ons implementering, sal ons gebruik . vector database Pinecone is a In teenstelling met open-source databasisse wat selfhosting benodig, is Pinecone 'n wolk-native oplossing, wat beteken dat ons nie bekommerd hoef te wees oor infrastruktuurbestuur nie. Die Pinekone fully managed vector database Die Pinekone Die opstel van Pinecone Die eerste stappe is natuurlik om by Pinecone te registreer en die API_KEY en omgewing van die dashboard te kry. pip install pinecone Ten slotte, dan kan ons verbind tot Pinecone in ons script from pinecone import Pinecone, ServerlessSpec pc = pinecone.Pinecone( api_key="YOUR API KEY" ) Die omgewing waarde kom van die Pinecone web konsole wanneer jy jou API sleutel skep. Maak 'n Pinecone-indeks 'N Indeks is waar jou data vir 'n later retrivial van die LLM gestoor word. In plaas van in eenvoudige teks te wees, is dit in vetoriale formaat (in wese 'n reeks getalle), wat die LLM toelaat om te verstaan watter inskrywing in die indeks is meer waarskynlik 'n goeie antwoord vir die query wat die LLM maak. In die a soos , behalwe vektor data, het ons ook metadata: metadata is Dit word saam met elke vektor (embedding) opgespoor om die herstel meer betekenisvol te maak. vector database Pinecone, , or ChromaDB Weeg extra information ChromaDB ChromaDB Weeg Weeg Terwyl verteenwoordig gebruik vir soortgelykheidsoek, verskaf gestruktureerde inligting oor wat die vektor verteenwoordig. Terwyl ons in die vektor data die markdown van die artikels sal insluit, sal ons in die metadata sommige inligting gebruik wat ons wil hê dat die LLM met ons deel, soos die skrywer van die blog wat vir die antwoord gebruik is, die titel en die skakel na die pos. vectors numerical embeddings metadata filtering, categorization, and interpretability index_name = "article-index" if not pc.has_index(index_name): index_model = pc.create_index_for_model( name=index_name, cloud="aws", region="us-east-1", embed={ "model":"llama-text-embed-v2", "field_map":{"text": "chunk_text"} } ) #pc.describe_index(index_name) #to get the host index=pc.Index(host='YOURINDEXENDPOINT') ..... article_data = [ {"id": f"article-{i}", "text": page["markdown"], "url": page["metadata"]["url"], "title": page["metadata"]["title"], "author": page["metadata"]["author"][0]} for i, page in enumerate(scrape_results['data']) ] #print(article_data) # Generate embeddings using LLaMA v2 for article in article_data: # Estrai il testo dell'articolo text = article["text"] #print(text) # Single article insert to avoid failures embedding = pc.inference.embed( model="llama-text-embed-v2", inputs=[text], parameters={"input_type": "passage"} ) # Prepare data for Pinecone upsert vector_data = { "id": article["id"], # Unique article ID "values": embedding[0]["values"], # Embedding vector "metadata": { "url": article["url"], # Store article URL "content": text[:300], # Store first 500 chars as a preview/snippet "title": article["title"][:100], "author": article["author"][:50] } } #print(vector_data) # Upsert the single article into Pinecone index.upsert(vectors=[vector_data], namespace="articles") print(f"✅ Upserted: {article['id']} ({article['title']})") # Optional: Add a short delay to prevent API rate limits (adjust as needed) time.sleep(1) Soos u uit die kode kan sien, herhaal ons basies elke artikel wat voorheen gekraap is en voeg dit by 'n nuut gemaakte indeks genaamd . article-index As jy meer wil speel met Pinecone daar is 'n Uitgebreide dokumentasie op hul webwerf. 'n Uitgebreide dokumentasie op hul webwerf. Maar nou dat ek al die artikels op die indeks ingesluit het, kan ons die inligting wat ons nodig het, uitneem? Ek het 'n basiese script genaamd query.py geskep om die resultate van die soeke op die indeks te toets. Wanneer gevra word: "Kan jy asseblief 'n paar artikels oor die omskeping van Kasada lys?" die vraag retourneer die volgende artikels: {'matches': [{'id': 'article-0', 'metadata': {'author': 'Pierluigi Vinciguerra', ..., 'title': 'THE LAB #76: Bypassing Kasada With Open ' 'Source Tools In 2025', 'url': 'https://substack.thewebscraping.club/p/bypassing-kasada-2025-open-source'}, 'score': 0.419812053, 'values': []}, {'id': 'article-129', 'metadata': {'author': 'Pierluigi Vinciguerra', ..., 'title': 'How to by-pass Kasada bot mitigation?', 'url': 'https://substack.thewebscraping.club/p/how-to-by-pass-kasada-bot-mitigation'}, 'score': 0.418432325, 'values': []}, {'id': 'article-227', 'metadata': {'author': 'Pierluigi Vinciguerra', ..., 'title': 'Scraping Kasada protected websites', 'url': 'https://substack.thewebscraping.club/p/scraping-kasada-protected-websites'}, 'score': 0.378159761, 'values': []}], 'namespace': 'articles', 'usage': {'read_units': 6}} Nie sleg nie! al die drie artikels was presies oor die onderwerp! Vir vandag is dit genoeg, in die volgende episode sal ons sien hoe om hierdie DB met GPT4 te verbind en dan 'n eenvoudige gebruikersinterface te skep om oproepe te skryf en die data wat jy nodig het, te kry. Die artikel is deel van die "The Lab" reeks deur Pierluigi Vinciguerra. Kyk na sy Substack bladsy vir meer kennis oor Web Scraping. Die artikel is deel van die "The Lab" reeks deur Pierluigi Vinciguerra. Kyk na sy Substack bladsy vir meer kennis oor Web Scraping. “Die laboratorium”
