In diesem Artikel erfahren Sie:
- Was Retrieval-Augmented Generation (RAG) und ChromaDB sind und was jedes davon bietet.
- Warum die Kombination von Bright Data’s Web Unlocker API mit ChromaDB ein praktischer Weg ist, ein Sprachmodell mit aktuellen, realen Daten zu verankern.
- Wie man eine End-to-End-Pipeline aufbaut, die Web-Inhalte sammelt, sie lokal einbettet und Fragen dazu beantwortet – alles auf dem eigenen Rechner.
Bevor wir auf die Tools und den Code eingehen, ist es hilfreich, die Konzepte zu klären und zu sehen, wie sie in einem RAG-Workflow zusammenpassen.
Was ist Retrieval-Augmented Generation (RAG)?
Ein großes Sprachmodell kennt nur das, womit es trainiert wurde. Fragen Sie es nach einer Seite, die letzte Woche online ging, einem internen Wiki oder einem Nischen-Produktkatalog, wird es entweder raten oder mitteilen, dass es die Antwort nicht kennt. Retrieval-Augmented Generation schließt diese Lücke.
Die Idee ist einfach. Anstatt sich auf das Gedächtnis des Modells zu verlassen, speichern Sie Ihre eigenen Dokumente in einem durchsuchbaren Index. Wenn eine Frage eingeht, rufen Sie zunächst die relevantesten Textabschnitte ab, ergänzen dann den Prompt, indem Sie diese Abschnitte als Kontext einfügen, und lassen schließlich das Modell eine in diesem Material verankerte Antwort generieren. Das Modell übernimmt weiterhin das Schreiben, aber die Fakten stammen aus Daten, die Sie kontrollieren.
Das ist aus zwei Gründen wichtig. Antworten bleiben aktuell, weil Sie entscheiden, was in den Index aufgenommen wird und wann er aktualisiert wird. Und Antworten bleiben präzise, weil das Modell über echten Quelltext nachdenkt, anstatt Lücken aus Trainingsdaten zu füllen. Für Wissensdatenbanken, Support-Assistenten, Recherche-Tools und alles, was auf proprietären oder sich schnell ändernden Informationen basiert, ist RAG zum Standardansatz geworden.
Nachdem die Retrieval-Seite geklärt ist, schauen wir uns an, wo diese Dokumente tatsächlich gespeichert werden.
Was ist ChromaDB?
ChromaDB (meist einfach Chroma genannt) ist eine Open-Source-Vektordatenbank, die für KI-Anwendungen entwickelt wurde. Eine reguläre Datenbank gleicht exakte Werte ab; eine Vektordatenbank gleicht Bedeutungen ab. Dies geschieht durch das Speichern von Embeddings – numerische Darstellungen von Text, bei denen ähnliche Konzepte im Vektorraum nah beieinander liegen. Bei einer Abfrage gibt Chroma die gespeicherten Abschnitte zurück, deren Embeddings Ihrer Frage am nächsten liegen, selbst wenn keine exakten Wörter übereinstimmen.
Was Chroma für einen ersten RAG-Aufbau geeignet macht, ist der geringe Aufwand. Es wird mit einem einzigen pip install installiert, läuft eingebettet in Ihrem Python-Prozess ohne separaten Server und speichert alles über PersistentClient dauerhaft auf der Festplatte, sodass Ihr Index einen Neustart übersteht. Sie können jedes Embedding-Modell einbinden, von OpenAI- oder Google-APIs bis hin zu einem lokalen Modell, das nie das Netzwerk berührt. Für ein Projekt, das auf einem Laptop laufen und privat bleiben soll, ist diese Kombination kaum zu übertreffen.
RAG vs. Fine-Tuning: Was ist der Unterschied?
Menschen, die neu in diesem Bereich sind, wägen RAG oft gegen Fine-Tuning ab, als wären es konkurrierende Optionen. Sie lösen jedoch unterschiedliche Probleme:
- Fine-Tuning verändert das Modell selbst. Sie trainieren es auf Beispielen neu, damit es seinen Ton, sein Format oder sein Verhalten anpasst. Es ist das richtige Werkzeug, wenn Sie möchten, dass das Modell anders agiert, aber es ist langsam, teuer, und das eingebackene Wissen veraltet in dem Moment, in dem sich Ihre Daten ändern.
- RAG lässt das Modell unverändert und ändert, was es zum Zeitpunkt der Frage sieht. Sie fügen bei jeder Anfrage relevanten Kontext in den Prompt ein. Es ist das richtige Werkzeug, wenn das Modell etwas Spezifisches und Aktuelles wissen soll, und die Aktualisierung ist so günstig wie das Hinzufügen eines Dokuments zum Index.
Die grobe Regel, auf die die meisten Teams kommen: Wenn Sie neues Wissen benötigen, greifen Sie zu RAG; wenn Sie neues Verhalten benötigen, erwägen Sie Fine-Tuning. Viele Produktionssysteme nutzen beides. In diesem Tutorial konzentrieren wir uns ausschließlich auf RAG, da das Ziel darin besteht, Fragen über Web-Inhalte zu beantworten, die sich viel zu häufig ändern, um ein Modell dafür neu zu trainieren.
Warum Bright Data in eine RAG + ChromaDB-Pipeline integrieren?
Ein RAG-System ist nur so gut wie die Dokumente, die Sie ihm zuführen. Schlechte Eingaben führen zu selbstsicher klingenden, aber falschen Ausgaben. Der eigentliche Engpass in den meisten Pipelines ist also nicht die Vektorsuche oder das Modell – es ist das Beschaffen von sauberem, zuverlässigem und aktuellem Quellmaterial.
Das ist einfach, wenn Ihre Daten bereits in einem Ordner mit PDFs liegen. Es wird schwierig, sobald Ihr Wissen aus dem offenen Web stammen muss. Öffentliche Seiten verstecken sich hinter Bot-Erkennung, rendern Inhalte mit JavaScript, liefern je nach Region unterschiedliche Ergebnisse und werfen CAPTCHAs auf alles, was automatisiert aussieht. Eigene Scraper gegen all das zu warten, ist eine Aufgabe für sich – und eine, die jedes Mal kaputt geht, wenn eine Zielseite ihr Markup ändert.
Hier passt Bright Data’s Web Unlocker API hinein. Sie senden eine Ziel-URL, und sie gibt den Seiteninhalt zurück – Anti-Bot-Maßnahmen, Proxy-Rotation, JavaScript-Rendering und Geo-Targeting werden im Hintergrund erledigt. Sie können sogar anfordern, dass die Seite als sauberes Markdown zurückgegeben wird, was für RAG nahezu ideal ist, da Navigation und Boilerplate entfernt werden und lesbarer Text zum Aufteilen und Einbetten übrig bleibt. Keine Browser-Automatisierung, kein Proxy-Pool zu verwalten.
Kombiniert mit Chromas lokalem Vektorspeicher und einem lokal ausgeführten Modell ergibt dies eine Pipeline, die dort aktuell ist, wo es nötig ist, und überall sonst privat bleibt: Nur der Datensammlungsschritt greift auf das Web zu, während Einbettung, Speicherung, Abruf und Generierung auf Ihrem Rechner verbleiben.
Dieses Muster ist besonders nützlich für:
- Recherche-Assistenten, die Fragen zu den neuesten Artikeln, Papieren oder Dokumentationen beantworten, anstatt auf den Trainings-Snapshot eines Modells zurückzugreifen.
- Wettbewerbsanalyse-Tools, die Produkt-, Preis- oder Feature-Seiten einer Reihe von Konkurrenzseiten verfolgen.
- Interne Support-Bots, die auf Live-Dokumentation basieren, sodass Antworten die aktuelle Dokumentation widerspiegeln und nicht eine Version von vor Monaten.
- Marktüberwachungssysteme, die aktuelle Angebote oder Nachrichten abrufen und es einem Analysten ermöglichen, diese in normaler Sprache abzufragen.
Indem Sie Bright Data’s Web-Dateninfrastruktur die Sammlung übernehmen und Chroma den Abruf verwalten lassen, erhalten Sie eine produktionsreife RAG-Engine, ohne eine einzige Zeile Scraping-Code zu schreiben.
Wie man eine lokale RAG-Pipeline mit Bright Data und ChromaDB aufbaut
In diesem Abschnitt bauen Sie eine Pipeline mit drei Stufen:
- Web-Inhalte sammeln: Ein Skript ruft Bright Data’s Web Unlocker API auf, um eine Reihe von Seiten abzurufen und jede als Markdown zurückzugeben.
- Einbetten und speichern: Ein zweites Skript unterteilt den Inhalt in Abschnitte, generiert Embeddings lokal mit einem Sentence-Transformer-Modell und schreibt die Vektoren in ChromaDB.
- Abrufen und generieren: Ein Abfrageskript bettet Ihre Frage ein, ruft die relevantesten Abschnitte aus Chroma ab und übergibt sie an ein lokales Modell, um eine fundierte Antwort mit Quellen zu erzeugen.
Hinweis: Dies ist eines von vielen möglichen Designs. Sie könnten das lokale Modell durch einen API-Aufruf für qualitativ hochwertigere Antworten ersetzen, einen Re-Ranking-Schritt zwischen Abruf und Generierung hinzufügen oder die Sammlungsphase auf Hunderte von URLs statt drei ausrichten. Die Struktur bleibt gleich.
Folgen Sie den nachstehenden Schritten, um eine vollständig lokale RAG-Pipeline zu erstellen, die von Bright Data’s Web Unlocker API und ChromaDB angetrieben wird.
Voraussetzungen
Um mitzumachen, benötigen Sie:
- Ein Bright Data-Konto mit einer aktiven Web Unlocker-Zone. Melden Sie sich in Ihrem Dashboard an, gehen Sie zu Account Settings und kopieren Sie Ihr API Token (es liegt im UUID-Format vor). Notieren Sie auch Ihren Zonennamen; Sie benötigen beides.
- Python 3.10+ lokal installiert.
- Ollama installiert, mit einem für den Generierungsschritt heruntergeladenen Modell (dieses Tutorial verwendet
llama3.1, aber jedes Chat-Modell funktioniert). Wenn Sie lieber ein gehostetes Modell verwenden möchten, zeigt Schritt 5, wo Sie einen API-Aufruf eintauschen können.
Schritt 1: Projekt-Setup
Erstellen Sie ein Arbeitsverzeichnis, richten Sie eine virtuelle Umgebung ein und installieren Sie die Abhängigkeiten:
mkdir local-rag-pipeline && cd local-rag-pipeline
python -m venv venv
source venv/bin/activate # Unter Windows: venv\Scripts\activate
pip install requests chromadb sentence-transformersBeim ersten Ausführen der Pipeline lädt sentence-transformers das Embedding-Modell herunter (einige hundert Megabyte). Danach wird es aus dem Cache geladen und läuft offline.
Laden Sie ein Modell für den Generierungsschritt herunter, falls noch nicht geschehen:
ollama pull llama3.1Schritt 2: Projektstruktur erstellen
Erstellen Sie die Ordner, in die die Pipeline schreibt:
mkdir -p data/raw data/chromaIhre Projektstruktur wird so aussehen:
local-rag-pipeline/
├── data/
│ ├── raw/ # Rohes Markdown aus dem Web gesammelt
│ └── chroma/ # Persistierter ChromaDB-Index
├── collect.py # Stufe 1: Seiten über Bright Data abrufen
├── ingest.py # Stufe 2: Aufteilen, einbetten und speichern
└── rag.py # Stufe 3: Abrufen und generierenSchritt 3: Web-Daten mit Bright Data sammeln
Erstellen Sie die Datei collect.py:
import json
import requests
from pathlib import Path
API_KEY = "your-brightdata-api-token-here"
ZONE = "web_unlocker1"
BASE_URL = "https://api.brightdata.com/request"
RAW_DATA_PATH = "data/raw/pages.json"
HEADERS = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json",
}
TARGETS = [
"https://en.wikipedia.org/wiki/Retrieval-augmented_generation",
"https://en.wikipedia.org/wiki/Vector_database",
"https://en.wikipedia.org/wiki/Large_language_model",
]
def fetch_pages():
results = []
for url in TARGETS:
print(f"Fetching: {url}")
response = requests.post(
BASE_URL,
headers=HEADERS,
json={
"zone": ZONE,
"url": url,
"format": "raw",
"data_format": "markdown",
},
timeout=60,
)
response.raise_for_status()
results.append({"url": url, "content": response.text})
print(f" -> {len(response.text)} chars")
Path(RAW_DATA_PATH).parent.mkdir(parents=True, exist_ok=True)
with open(RAW_DATA_PATH, "w") as f:
json.dump(results, f, indent=2)
print(f"Saved {len(results)} pages to {RAW_DATA_PATH}")
if __name__ == "__main__":
fetch_pages()Ersetzen Sie your-brightdata-api-token-here durch Ihr tatsächliches API-Token und aktualisieren Sie ZONE entsprechend Ihrem Web Unlocker-Zonennamen.
Das macht jeder Teil:
API_KEYundZONE: Ihre Bright Data-Anmeldedaten. Das API-Token ist das UUID-Format-Token aus Ihren Kontoeinstellungen, kein Zonenpasswort.TARGETS: Die aufzunehmenden Seiten. Die drei Wikipedia-Artikel hier bilden ein kohärentes Korpus, über das man Fragen stellen kann. Tauschen Sie Ihre eigenen URLs ein; hier beweist der Web Unlocker seinen Wert, da Nachrichtenseiten, Produktseiten und JavaScript-lastige Apps, die normale Anfragen blockieren, sauber über die API zurückgegeben werden.fetch_pages: Durchläuft jede URL und sendet eine POST-Anfrage an den Web Unlocker-Endpunkt. Die Optiondata_format: "markdown"weist Bright Data an, lesbares Markdown statt rohem HTML zurückzugeben, was einen Parsing-Schritt einspart. Ergebnisse werden in eine einzelne JSON-Datei für die nächste Stufe geschrieben.
Hinweis: Einige Seiten können mit einer
bad_endpoint-Meldung zurückkommen, wenn eine Website unter Bright Data’s Sofortzugriffsmodus eingeschränkt ist. Dies ist erwartetes Verhalten; Bright Data zeigt den Fehler in der Antwort an, anstatt still zu scheitern. Wenden Sie sich an Ihren Account Manager, wenn Sie vollen Zugang zu einem eingeschränkten Ziel benötigen.
Schritt 4: Inhalte in ChromaDB einbetten
Erstellen Sie die Datei ingest.py:
import json
import chromadb
from chromadb.utils import embedding_functions
RAW_DATA_PATH = "data/raw/pages.json"
CHROMA_PATH = "data/chroma"
COLLECTION_NAME = "web_knowledge"
def chunk_text(text, size=800, overlap=100):
words = text.split()
chunks, i = [], 0
while i < len(words):
chunks.append(" ".join(words[i:i + size]))
i += size - overlap
return chunks
def main():
with open(RAW_DATA_PATH) as f:
pages = json.load(f)
client = chromadb.PersistentClient(path=CHROMA_PATH)
embed_fn = embedding_functions.SentenceTransformerEmbeddingFunction(
model_name="all-MiniLM-L6-v2"
)
collection = client.get_or_create_collection(
name=COLLECTION_NAME,
embedding_function=embed_fn,
)
documents, metadatas, ids = [], [], []
for page in pages:
for idx, chunk in enumerate(chunk_text(page["content"])):
documents.append(chunk)
metadatas.append({"source": page["url"], "chunk": idx})
ids.append(f"{page['url']}#{idx}")
collection.upsert(documents=documents, metadatas=metadatas, ids=ids)
print(f"Indexed {len(documents)} chunks from {len(pages)} pages")
print(f"Collection now holds {collection.count()} chunks")
if __name__ == "__main__":
main()Diese Stufe erledigt die schwere Arbeit, rohen Text in etwas Durchsuchbares umzuwandeln:
chunk_text: Teilt jede Seite in überlappende Fenster von etwa 800 Wörtern auf. Das Aufteilen ist wichtig, weil Sie fokussierte Passagen abrufen möchten, nicht ganze Seiten, und die 100-Wörter-Überlappung verhindert, dass ein Satz, der eine Grenze überschreitet, in der Mitte abgeschnitten wird.SentenceTransformerEmbeddingFunction: Lädtall-MiniLM-L6-v2, ein kleines, schnelles Embedding-Modell, das lokal läuft. Chroma ruft es automatisch auf, wenn Sie Dokumente hinzufügen oder abfragen, sodass Sie Vektoren nie manuell verwalten müssen.get_or_create_collection: Öffnet die persistente Sammlung auf der Festplatte, erstellt sie beim ersten Durchlauf und verwendet sie danach wieder.collection.upsert: Schreibt die Abschnitte, ihre Metadaten und stabile IDs in Chroma. Die Verwendung vonupsertstattaddbedeutet, dass Sie das Skript nach dem Sammeln neuer Inhalte erneut ausführen können, ohne auf Fehler durch doppelte IDs zu stoßen.
Schritt 5: Den Abruf- und Generierungsschritt aufbauen
Erstellen Sie die Datei rag.py:
import sys
import requests
import chromadb
from chromadb.utils import embedding_functions
CHROMA_PATH = "data/chroma"
COLLECTION_NAME = "web_knowledge"
OLLAMA_URL = "http://localhost:11434/api/generate"
MODEL = "llama3.1"
PROMPT_TEMPLATE = """You are a research assistant. Answer the question using only the context below.
If the context does not contain the answer, say you don't have enough information.
Context:
{context}
Question: {question}
Answer:"""
def retrieve(question, n_results=4):
client = chromadb.PersistentClient(path=CHROMA_PATH)
embed_fn = embedding_functions.SentenceTransformerEmbeddingFunction(
model_name="all-MiniLM-L6-v2"
)
collection = client.get_collection(
name=COLLECTION_NAME, embedding_function=embed_fn
)
results = collection.query(query_texts=[question], n_results=n_results)
chunks = results["documents"][0]
sources = [m["source"] for m in results["metadatas"][0]]
return chunks, sources
def generate(question, chunks):
prompt = PROMPT_TEMPLATE.format(context="\n\n".join(chunks), question=question)
response = requests.post(
OLLAMA_URL,
json={"model": MODEL, "prompt": prompt, "stream": False},
timeout=120,
)
response.raise_for_status()
return response.json()["response"]
def main(question):
chunks, sources = retrieve(question)
answer = generate(question, chunks)
print("\n=== Answer ===")
print(answer.strip())
print("\n=== Sources ===")
for src in dict.fromkeys(sources): # Deduplizieren, Reihenfolge beibehalten
print(f" - {src}")
if __name__ == "__main__":
main(" ".join(sys.argv[1:]))Hier ist der Ablauf:
retrieve: Bettet Ihre Frage mit demselben Modell ein, das bei der Aufnahme verwendet wurde (diese Konsistenz macht die Ähnlichkeitssuche funktionsfähig), und fragt Chroma nach den vier nächsten Abschnitten. Es gibt sowohl den Text als auch die Quell-URL jedes Abschnitts zurück.generate: Erstellt einen Prompt, der das Modell auf den abgerufenen Kontext festlegt und es anweist, zuzugeben, wenn die Antwort nicht vorhanden ist – das ist die wirksamste Schutzmaßnahme gegen Halluzinationen. Anschließend ruft es ein lokales Modell über Ollama’s REST-API auf.main: Verbindet die beiden Teile und gibt die Antwort zusammen mit der deduplizierten Quellenliste aus, sodass jede Antwort auf die Seiten zurückverfolgt werden kann, aus denen sie stammt.
Wenn Sie ein gehostetes Modell bevorzugen, ist dies die einzige Funktion, die sich ändert. Tauschen Sie den requests.post-Aufruf an Ollama gegen einen Aufruf der Anthropic– oder OpenAI-API aus und übergeben Sie denselben Prompt; die Retrieval-Hälfte bleibt genau wie sie ist.
Schritt 6: Die Pipeline ausführen
Führen Sie die drei Stufen der Reihe nach aus. Zuerst die Seiten sammeln:
python collect.pyDann in Abschnitte aufteilen und in Chroma einbetten:
python ingest.py
Jetzt eine Frage stellen:
python rag.py "What problem does retrieval-augmented generation solve?"Schritt 7: Die Ergebnisse prüfen
Die Abfrage gibt eine fundierte Antwort gefolgt von den verwendeten Quellen zurück:
=== Answer ===
Retrieval-augmented generation addresses the fact that a language model only
knows what it was trained on. By retrieving relevant passages from an external
index at query time and adding them to the prompt, the model can answer using
current, specific information it was never trained on, which also reduces
hallucination because the response is anchored to real source text.
=== Sources ===
- https://en.wikipedia.org/wiki/Retrieval-augmented_generation
- https://en.wikipedia.org/wiki/Large_language_model
Screenshot-Vorschlag: Die Terminal-Ausgabe einer rag.py-Abfrage, die die generierte Antwort und darunter die Quellenliste zeigt.
Probieren Sie einige weitere Fragen aus, um ein Gefühl für die Abrufqualität zu bekommen:
python rag.py "How does a vector database differ from a relational database?"
python rag.py "What are common limitations of large language models?"Wenn eine Antwort dünn wirkt, sind zwei Parameter es wert, zuerst angepasst zu werden. Die Erhöhung von n_results in rag.py versorgt das Modell mit mehr Kontext, was breiten Fragen auf Kosten eines längeren Prompts hilft. Die Anpassung von size und overlap in ingest.py ändert, wie der Text aufgeteilt wird; kleinere Abschnitte schärfen präzise Suchen, größere Abschnitte bewahren mehr umgebenden Kontext. Führen Sie ingest.py nach jeder Änderung der Aufteilung erneut aus, damit der Index diese widerspiegelt.
Die gesamte Schleife lief ohne eine einzige Zeile Scraping- oder Proxy-Code. Bright Data lieferte sauberes Markdown aus dem Web, Chroma verarbeitete die Embeddings und die Ähnlichkeitssuche lokal, und ein lokales Modell produzierte die Antwort – alles verankert in den Seiten, die Sie gesammelt haben.
Weiterführende Möglichkeiten
Diese Pipeline ist eine funktionierende Grundlage, und Sie können sie in mehrere Richtungen weiterentwickeln:
- Tauschen Sie das lokale Modell gegen eine gehostete API wie Anthropic oder OpenAI aus, wenn Sie stärkeres Reasoning oder längeren Kontext benötigen, während die gesamte Retrieval-Hälfte unverändert bleibt.
- Fügen Sie einen Discovery-Schritt mit Bright Data’s SERP-API hinzu, damit die Pipeline relevante Seiten aus einer Suchanfrage finden kann, anstatt mit einer festen URL-Liste zu arbeiten.
- Rufen Sie strukturierte Datensätze statt Freitext über Bright Data’s Web Scraper API ab, die über 120 Domains abdeckt. Der Agentic RAG-Walkthrough zeigt dieses Muster von Anfang bis Ende.
- Verwenden Sie Chromas Metadatenfilterung (das
where-Argument beiquery), um den Abruf auf eine bestimmte Quelle, ein Datum oder eine Kategorie einzugrenzen. - Fügen Sie eine Re-Ranking- oder Hybrid-Suchebene hinzu, wenn Ihre Dokumente voller Eigennamen und Codes sind, mit denen die reine semantische Suche Schwierigkeiten hat.
- Planen Sie regelmäßige Aktualisierungen, oder stellen Sie das Ganze einem Assistenten über einen MCP-Server zur Verfügung, damit ein Tool wie Claude Desktop bei Bedarf sammeln und abfragen kann.
- Wechseln Sie von lokalem Chroma zu einem verwalteten Vektorspeicher wie Pinecone oder pgvector, sobald Ihre Sammlung einen einzelnen Rechner übersteigt; die Aufnahme- und Abruflogik lässt sich mit minimalen Änderungen übertragen.
Die Möglichkeiten sind nahezu unbegrenzt.
Fazit
In diesem Artikel haben Sie eine funktionierende lokale RAG-Pipeline erstellt, indem Sie Bright Data’s Web Unlocker API mit ChromaDB kombiniert haben.
Chroma übernimmt Einbettung, Speicherung und Ähnlichkeitssuche lokal, sodass Ihr Index und Ihre Abfragen Ihren Rechner nie verlassen. Ein lokales Modell verwandelt den abgerufenen Kontext in eine fundierte, quellenbasierte Antwort. Und Bright Data nimmt den schwierigsten Teil des gesamten Prozesses ab: das Sammeln von frischem, sauberem Seiteninhalt aus dem offenen Web, ohne Proxys zu verwalten, Scraper zu schreiben oder Anti-Bot-Systeme zu bekämpfen.
Im Gegensatz zu einem No-Code-Assistenten gibt Ihnen dieser Stack vollständige Kontrolle über jede Ebene: welche Seiten Sie sammeln, wie Sie sie aufteilen und einbetten, wie viele Sie abrufen und welches Modell die Antwort schreibt. Er fügt sich natürlich in jede größere Daten- oder KI-Plattform ein und skaliert mit Ihren Anforderungen.
Um reichhaltigere Pipelines zu erstellen, erkunden Sie Bright Data’s vollständige Suite von Web-Daten-Tools, einschließlich des Web Unlockers für bot-geschützte Seiten, der SERP-API für Suchdaten und fertige Datensätze für gängige Anwendungsfälle.
Registrieren Sie sich noch heute für ein kostenloses Bright Data-Konto und beginnen Sie, Ihre Modelle mit echten Web-Daten zu verankern.
