Ако работите в компания, която използва уеб данни, вие със сигурност знаете, че това е само първият слой на по-сложен продукт. Всъщност, уеб-изтритите данни традиционно се съхраняват във файлове или бази данни (бюкети за съхранение в облак, езера за данни или складове за данни) и след това се анализират с помощта на инструменти за бизнес разузнаване (BI), както търговски, така и собственици. Например, екип може да изтрие цените на продуктите или отзивите на клиентите от мрежата, да запише суровите данни като CSV/JSON файлове, да ги зарежда в SQL склад за данни и след това да използва BI платформи като Tableau или Power BI, за да създава табла и отчети. Съвременните решения за изтриване на уеб дори извличат данни в структури Днес големите езикови модели (LLM) променят тази парадигма. Вместо да разчитат единствено на статични табла или SQL заявки, организациите могат да използват AI асистенти, за да извличат прозрения от изтрити данни чрез естествени езикови указания. С други думи, вместо човек да пише заявка или да интерпретира диаграма, AI асистентът може директно да отговори на въпроси за данните. Помислете за това, че имате интерфейс, подобен на ChatGPT, и напишете някои указания, за да получите прозрения, заобикаляйки създаването на табла. Видях този вид подход в няколко продукта, преди LLM да излезе, но без голям успех. Развиващият се ландшафт на AI и седмичните подобрения, които виждаме в LLM Представете си, че питате Този подход обещава по-бърз, по-интуитивен достъп до информация за нетехнически потребители, без да се налага да изграждате диаграми или да пишете код.В предишните компании, в които работех, съм виждал твърде много пъти разпространението на различни табла на група потребители (ако не и на потребител), понякога извличайки различни числа един от друг. "Кой конкурент е имал най-високата цена през изминалото тримесечие?" Разбира се, възниква нов набор от предизвикателства: какво да кажем за халюцинациите?Ако не видим основния брой на отговора, можем ли да бъдем 100% сигурни, че отговорът е правилен? В тази публикация (и следващата в поредицата Lab) ще изградим проект от край до край, където ще започнем с изтриване на статиите в този бюлетин, поставяйки ги в база данни, подходяща за използване на AI, извличане на тези знания и след това публикуване на уеб приложение, което може да използва обогатена версия на модел GPT. Подобряване на знанията LLM Интегрирането на персонализирани данни (като вашия сканиран набор от данни) в LLM може да се направи главно по два начина: чрез Моделът или използването на , и всеки от тези методи има плюсове и минуси.Да видим как те се различават и кой подход може да бъде най-добрият за нашия случай на употреба. fine-tuning Retrieval-Augmented Generation (RAG) Fine-Tuning срещу Retrieval-Augmented Generation означава обучение на базовата LLM върху допълнителни данни, така че да абсорбира нови знания. По същество, ще вземете предварително обучен модел и ще продължите да го обучавате на вашия домейн-специфичен набор от данни, като коригирате своите тежести, за да вградите това знание. Например, ако сте извадили колекция от технически статии, можете да финализирате LLM върху тези статии. Fine-tuning често се извършва чрез предоставяне на модела с голям набор от двойки въпроси-отговори или текстови пасажи от вашите данни, така че да се научи да отговаря с тази информация, когато е уместно. - знанието става част от неговите параметри.Следващият път, когато зададете въпрос на модела, той може да се възползва от тази изпечена информация, без да се нуждае от външна помощ. Fine-tuning intrinsically knows augmented from the inside използва различен подход: моделът остава непроменен, но му даваме достъп до външна база от знания (обикновено чрез векторно търсене). LLM след това генерира отговора си с помощта на този допълнителен контекст. За бумъри като мен, помислете за това като поставяне на CD в главата на Neo в Матрицата, за да научите нови умения и движения. В нашия случай, базата от знания може да бъде колекция от изтрити уеб статии, съхранявани в специализирана база данни. RAG е като изпит за отворена книга за LLM - в момента на заявката той разглежда съответната "страница" на данните и я използва, за да формулира отговор, вместо да разчита само на вътрешната си памет. Retrieval-Augmented Generation (RAG) retrieve relevant documents Както можете да си представите, една ключова разлика е там, където остават допълнителните знания: с фино настройване, знанието е вградено (Тежестите на модела се актуализират).С RAG знанията остават Fine-tuning е подобно на постоянно преподаване на нови факти на модела, докато RAG е подобно на оборудване на модела с динамична библиотека, която може да се позове на летището. in the model itself external Двата подхода имат различни плюсове и минуси: 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: Накратко, финото регулиране помага за фокусирано разбиране, докато RAG позволява достъп до знания в реално време.За нашия случай на използване на интегриране на постоянно актуализирани изтрити данни, RAG изглежда по-добър подход: можете непрекъснато да извличате нови уеб данни и да имате вашия асистент да го използва незабавно, вместо периодично да преквалифицирате целия модел. Преди да продължите, си струва да се отбележи, че финото настройване и RAG не се изключват взаимно; те могат да се допълват един друг. Например, можете да фино настройвате модел, за да регулирате тона или способността си да следвате инструкциите (или да добавите знания, които са малки и статични), и все още да използвате RAG, за да му дадете достъп до по-голяма база от знания, която се актуализира често. Използване на локален модел срещу външен API Друго разглеждане е за вашия AI асистент: локален (отворен код) модел, който управлявате сами или хостван модел чрез API (като OpenAI GPT-3.5/GPT-4 или други). what LLM to use – Модели като LLaMA 2, Mistral или Falcon могат да се изпълняват на вашите собствени сървъри. Вашите изтрити данни никога не напускат вашата среда, което е важно, ако съдържа чувствителна информация. Можете свободно да ги настроите върху данните си или да модифицирате начина, по който работят. По отношение на разходите, изпълнението на локален модел може да бъде по-евтино за големи обеми заявки (без такси за API), но трябва да инвестирате в хардуер или облачна инфраструктура, за да го хоствате. Недостатъкът е, че много отворени модели не могат да съответстват на производителността на най-новите GPT. Може да се наложи да използвате по-големи или по-специализирани модели, за да получите сравнима производителност, която може да бъде сложна за управление. с високо специфичен за домейна набор от данни и експертен опит, локалният модел може да бъде фино настроен, за да се отличава в този домейн, което го прави силно решение за "частна GPT". Local Open-Source LLMs control and privacy да – Използването на API като GPT-4 на OpenAI означава, че не е нужно да се притеснявате за стартирането на модела; просто изпращате обажданията си до тяхната услуга и получавате завършването. Това е много удобно и обикновено ви дава достъп до най-съвременното качество на модела без проблеми с инфраструктурата. За нашия сценарий можете да използвате RAG, като просто предварително изтеглите изтеглените документи до вашата справка и помолите API да отговори. Недостатъците тук се отнасят до персонализация и поверителност. Не всеки модел е на разположение за фино настройване ( Вие също се подчинявате на правилата на доставчика (например, те могат да имат филтри за съдържание, които могат да предотвратят някои заявки, свързани с изтриването).От гледна точка на поверителността, вие изпращате вашите данни (заявка и извлечен контекст) на трета страна, така че няма да препоръчам този подход за чувствителни или защитени с авторски права данни. External API LLMs (e.g. OpenAI’s) OpenAI, например, ви позволява да го направите на GPT4-o и GPT4-mini OpenAI, например, ви позволява да го направите на GPT4-o и GPT4-mini Като цяло, ако вашият случай на използване включва високочувствителни данни или изисква пълен контрол, се препоръчва локален LLM въпреки допълнителните усилия. Ако вашият приоритет е най-доброто възможно езиково умение и бърза настройка, хостван модел като OpenAI може да бъде по-добрият избор. В изпълнението на този пост ще илюстрираме използването на GPT API на OpenAI за простота и качество, но системата за извличане, която изграждаме, може също толкова лесно да се захранва с модел с отворен код като Llama2 чрез библиотеките HuggingFace или LangChain. Механизмът за извличане (векторна база данни + търсене на сходство) остава същият; само окончателният модел за генериране на отговори ще се различава. Като вземем предвид тези решения, нека интегрираме откъснатите ми статии в AI асистент.Ние ще използваме подхода RAG с модел на OpenAI, който се вписва добре с непрекъснато актуализираните уеб данни и избягва необходимостта от скъпи работни места за фини настройки. Изтриване на TWSC с Firecrawl е уеб скрепер, изложен като REST API и SDK. Той е специално проектиран да превърне уеб сайтове в (в формати като чист текст или маркировка), обработка на всички тежки повдигания, като сканиране на връзки, рендериране на JavaScript и т.н. Голямото предимство на Firecrawl е, че с едно API повикване можете да сканирате цял сайт. Огнеборци LLM-ready data Огнеборци Огнеборци За блога на The Web Scraping Club ще използваме своята карта на сайта, за да открием всички URL адреси на статията. (Блогът се хоства на Substack, който осигурява XML карта на сайта, в която са изброени всички публикации.) Firecrawl може да сканира сайта без карта на сайта, но използването му като отправна точка може да бъде по-ефективно и да гарантира, че не пропускаме никакви страници. Първо, инсталираме Firecrawl, като инсталираме неговия Python SDK и се удостоверяваме с API ключ (ако приемем, че сте се регистрирали и сте получили ключ): 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' ]}) Само с няколко реда код, нашите статии вече са в Markdown формат. Избор на векторна база данни за RAG А е ключов компонент на внедряването на RAG. Той съхранява вгражданията на вашите документи (векторни представяния) и позволява бързо търсене на сходство, за да получите подходящи документи за вграждане на дадена заявка. . vector database Pinecone е а За разлика от бази данни с отворен код, които изискват самохостинг, Pinecone е облачно решение, което означава, че не е нужно да се притесняваме за управлението на инфраструктурата. Пинекони fully managed vector database Пинекони Създаване на Pinecone Първите стъпки са, разбира се, да се регистрирате в Pinecone и да получите API_KEY и околната среда от таблото. pip install pinecone И накрая, тогава можем да се свържем с Pinecone в нашия скрипт from pinecone import Pinecone, ServerlessSpec pc = pinecone.Pinecone( api_key="YOUR API KEY" ) Стойността на околната среда идва от уеб конзолата на Pinecone, когато създавате вашия API ключ. Създаване на индекс Pinecone Индексът е мястото, където вашите данни се съхраняват за по-късно преразглеждане от LLM. Вместо да е в прост текст, той е във векторния формат (по същество низ от числа), което позволява на LLM да разбере кой запис в индекса е по-вероятно да бъде добър отговор на заявката, която LLM прави. В А като , освен векторни данни, имаме и метаданни: метаданните са Те се съхраняват заедно с всеки вектор (вграждане), за да направят възпроизвеждането по-значително. vector database Pinecone, , or ChromaDB Weaviate extra information ChromaDB ChromaDB Тегло Тегло Докато Представлява използвани за търсене на сходство, предоставя структурирана информация за това какво представлява векторът. Докато във векторните данни ще вмъкнем обозначението на статиите, в метаданните ще използваме част от информацията, която искаме LLM да сподели с нас, като например автора на блога, използван за отговора, заглавието и връзката към публикацията. 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) Както можете да видите от кода, ние основно повтаряме всяка статия, изтрита преди и я добавяме към новосъздаден индекс, наречен . article-index Ако искате да играете повече с Pinecone има an extensive documentation on their website. Огромна документация на сайта им. Но сега, когато вмъкнах всички статии в индекса, можем ли да извлечем информацията, от която се нуждаем? Създадох основен скрипт, наречен query.py, за да тествам резултатите от търсенията в индекса. Когато е зададен въпросът „Можете ли, моля, да изброите някои статии за заобикалянето на Kasada?“, въпросът връща следните статии: {'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}} Не е лошо!Всички три статии бяха точно по темата! За днес това е достатъчно, в следващия епизод ще видим как да свържем този DB към GPT4 и след това да създадем прост потребителски интерфейс, за да напишете обаждания и да получите необходимите данни. Статията е част от поредицата "Лабораторията" на Пиерлуиджи Винчигуера. Проверете страницата му Substack за повече знания за уеб сканиране. Статията е част от поредицата "Лабораторията" на Пиерлуиджи Винчигуера. Проверете страницата му Substack за повече знания за уеб сканиране. „Лаборатория“
