Guide pratique pour connecter les données de web crawling à RAG

"Nous voulons créer un chatbot IA qui répond avec nos propres données d'entreprise." — Nous entendons vraiment beaucoup de demandes de ce genre ces jours-ci. Bien que ChatGPT soit intelligent, pour lui permettre de répondre en se basant sur nos données d'entreprise les plus récentes, il est nécessaire d'utiliser RAG. Et la performance de RAG dépend finalement de la qualité des données.

Dans cet article, nous résumons le processus complet de connexion des données collectées par web crawling au pipeline RAG, avec du code pratique.

Table des matières

• Qu'est-ce que RAG ?
• Flux complet du pipeline
• Étape 1: Crawling — Collecte des données brutes
• Étape 2: Chunking — Diviser le texte en morceaux appropriés
• Étape 3: Embedding + Stockage dans une base de vecteurs
• Étape 4: Requête RAG — Poser des questions à LLM
• La qualité des données influence la performance de RAG
• Intégration de Hashscraper MCP + LangChain
• Conclusion

Qu'est-ce que RAG ?

RAG (Retrieval-Augmented Generation) est simplement une combinaison de "recherche + génération".

Avant que LLM ne génère une réponse, il recherche d'abord des documents pertinents dans une base de données externe pour les fournir en tant que contexte. Cela permet à GPT d'utiliser des informations récentes, des documents internes et des données spécialisées dans un domaine pour réduire considérablement les hallucinations.

L'essentiel est le suivant : LLM est intelligent, mais il ne sait pas tout. RAG est une structure qui complète ce que LLM "ne sait pas" par la recherche.

Flux complet du pipeline

Le flux complet du pipeline RAG est divisé en 5 étapes :

웹 크롤링 → 텍스트 청킹 → 임베딩 변환 → 벡터DB 저장 → LLM 쿼리

Nous examinerons chaque étape avec du code.

Étape 1: Crawling — Collecte des données brutes

Les données sont le point de départ de RAG. Les informations sur les produits, les actualités, les documents techniques, les messages communautaires collectés sur le web peuvent tous servir de sources pour RAG.

Ce qui est important ici, c'est l'extraction de texte propre. Si vous incluez des balises HTML, des publicités, des menus de navigation mélangés aux données, les performances de RAG en seront grandement affectées.

import requests
from bs4 import BeautifulSoup

def crawl_page(url):
    """단순 크롤링 예시 — 실전에서는 봇 차단, JS 렌더링 등 고려 필요"""
    response = requests.get(url, headers={
        "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"
    })
    soup = BeautifulSoup(response.text, "html.parser")

    # 본문 텍스트만 추출 (네비게이션, 광고 등 제거)
    for tag in soup(["nav", "header", "footer", "script", "style", "aside"]):
        tag.decompose()

    text = soup.get_text(separator="\n", strip=True)
    return text

Cependant, la réalité n'est pas aussi simple. Pour les pages rendues en JavaScript, les pages nécessitant une connexion, les sites bloquant les bots, les requêtes seules ont leurs limites.

Étape 2: Chunking — Diviser le texte en morceaux appropriés

Si vous incorporez un document entier, la précision de la recherche en souffrira. La clé est de diviser en morceaux de taille appropriée.

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=500,        # 청크당 최대 500자
    chunk_overlap=50,      # 청크 간 50자 겹침 (문맥 유지)
    separators=["\n\n", "\n", ". ", " "]  # 분할 우선순위
)

documents = splitter.split_text(crawled_text)
print(f"총 {len(documents)}개 청크 생성")

Conseils pour le chunking :
- Trop petit, le contexte est perdu ; trop grand, la précision de la recherche diminue
- Pour le texte coréen, des chunks de 500 à 800 caractères montrent généralement de bonnes performances
- Configurez chunk_overlap pour éviter la coupure de phrases

Étape 3: Embedding + Stockage dans une base de vecteurs

Convertissez les chunks en vecteurs (tableaux numériques) et stockez-les dans une base de vecteurs. Ici, nous utilisons une combinaison d'embedding OpenAI + ChromaDB.

from langchain_openai import OpenAIEmbeddings
from langchain_chroma import Chroma

# 임베딩 모델 초기화
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

# 벡터DB에 저장
vectorstore = Chroma.from_texts(
    texts=documents,
    embedding=embeddings,
    collection_name="crawled_data",
    persist_directory="./chroma_db"
)

print(f"{len(documents)}개 청크를 벡터DB에 저장 완료")

D'autres bases de vecteurs (Pinecone, Weaviate, Qdrant, etc.) sont également utilisables via une interface similaire dans LangChain.

Étape 4: Requête RAG — Poser des questions à LLM

Maintenant, lorsque la question de l'utilisateur arrive, recherchez les documents pertinents dans la base de vecteurs et transmettez-les à LLM avec le contexte.

from langchain_openai import ChatOpenAI
from langchain.chains import RetrievalQA

# LLM 설정
llm = ChatOpenAI(model="gpt-4o", temperature=0)

# RAG 체인 구성
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    chain_type="stuff",
    retriever=vectorstore.as_retriever(search_kwargs={"k": 3})
)

# 질문하기
answer = qa_chain.invoke("이 제품의 최신 가격은 얼마인가요?")
print(answer["result"])

Remarque : RetrievalQA est l'interface Chain héritée de LangChain. Bien que la configuration RAG basée sur LangGraph soit recommandée dans les versions les plus récentes, nous expliquons ici de manière intuitive cette méthode la plus directe pour la compréhension du concept.

C'est le flux complet de RAG. Crawling → Chunking → Embedding → Base de vecteurs → Requête LLM. La structure en elle-même est simple.

La qualité des données influence la performance de RAG

La partie la plus sous-estimée de RAG est la qualité des données d'entrée.

Peu importe la qualité du modèle d'embedding et de LLM que vous utilisez, si les données d'entrée sont sales, les résultats seront également médiocres. En réalité, la plupart des problèmes de performance de RAG proviennent non du modèle mais des problèmes de données.

Problèmes courants de qualité des données :
- Mélange de texte de navigation, de barre latérale avec le contenu principal → bruit lors de la recherche
- Crawling incomplet (échec du rendu JS) → informations essentielles manquantes
- Données en double → biais dans les résultats de recherche
- Problèmes d'encodage, erreurs de caractères spéciaux → dégradation de la qualité de l'embedding

Garbage In, Garbage Out. La qualité des données propres dès l'étape de crawling détermine le succès global du pipeline RAG.

Intégration de Hashscraper MCP + LangChain

Créer et maintenir un crawler vous fera perdre du temps à gérer des problèmes secondaires tels que le blocage des bots, le rendu JS, la gestion des proxies, etc. En utilisant le serveur MCP (Model Context Protocol) de Hashscraper, vous pouvez vous concentrer sur la logique RAG sans vous soucier de l'infrastructure de crawling.

# 해시스크래퍼 MCP를 LangChain Document Loader로 활용하는 예시
from langchain_core.documents import Document
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_chroma import Chroma
from langchain_openai import OpenAIEmbeddings

# 해시스크래퍼 API로 데이터 수집 — 봇 차단 사이트도 OK
import requests

response = requests.post(
    "https://api.hashscraper.com/api/scrape",
    json={
        "url": "https://target-site.com/products",
        "format": "markdown"            # markdown 또는 text
    },
    headers={
        "X-API-Key": "YOUR_API_KEY",
        "Content-Type": "application/json; version=2"
    }
).json()

# LangChain Document로 변환
docs = [
    Document(
        page_content=response["data"]["content"],
        metadata={
            "url": response["data"]["url"],
            "title": response["data"]["title"]
        }
    )
]

# 이후는 동일: 청킹 → 임베딩 → 벡터DB → RAG
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50)
chunks = splitter.split_documents(docs)
vectorstore = Chroma.from_documents(chunks, embeddings)

Raisons d'utiliser Hashscraper comme source de données pour RAG :
- Extraction de texte propre et stable même sur des sites bloquant les bots
- Automatisation du rendu JS, de la gestion des connexions
- Gestion des proxies, rotation des adresses IP intégrées — pas besoin de se soucier de l'infrastructure
- Sortie de données structurée → amélioration de la qualité du chunking/embedding

Conclusion

Le pipeline RAG est structurellement simple. Cependant, ce qui détermine finalement la performance en pratique est la qualité de la collecte initiale des données.

Plutôt que de consacrer du temps à créer et entretenir un crawler, se concentrer sur la logique RAG sur une infrastructure de crawling vérifiée peut être un choix plus efficace.

Si vous avez besoin de construire un pipeline RAG basé sur des données de crawling, consultez Hashscraper. Nous vous aiderons de la collecte de données à l'intégration avec l'IA, en nous appuyant sur notre expérience pratique.