Can I use this for sites other than LinkedIn?

Yes. Bright Data's Web Scrapers Library covers hundreds of sites (Amazon, Zillow, Yelp, and more), each with its own dataset_id. Swap the DATASET_ID in scrape.py and the to_row() mapping in index.py for the new JSON shape. The search and indexing logic is data-agnostic and carries over.

Do I need a paid Cohere account for this?

No, a trial key runs the whole demo. Cohere's trial Rerank endpoint is currently capped at 10 calls/min, so eval.py hits a 429 and backs off automatically (~90s instead of ~15s). Scraping, indexing, and ad-hoc search stay well under the limits. Upgrade only if you iterate on the eval often.

Why LanceDB, not Pinecone, Weaviate, or pgvector?

LanceDB is an embedded library with no server, no separate database, and no managed-service bill. It supports hybrid search and Cohere reranking natively, and every write is a version snapshot. For a single-machine pipeline with no ops, that's the least overhead. The others are capable but add more infrastructure.

How often should I re-run the scraper?

Once a day suits an active job board. Bright Data can run scheduled collection from the dashboard, and the merge_insert upsert dedupes on the LanceDB side, so re-runs are cheap. Postings older than ~30 days are usually closed, so old snapshots become historical, and versions.py keeps them queryable.

Semantic Job Search with Bright Data, LanceDB and Cohere

Les sites d’offres d’emploi ne recherchent que des mots exacts, ce qui fait que le bon poste reste caché quand vos termes ne correspondent pas à l’annonce. La recherche sémantique s’appuie sur le sens. Nous la construisons de bout en bout, puis mesurons quel mode de recherche l’emporte au lieu de supposer que le plus complexe gagne.

TL;DR

Ce guide construit un moteur de recherche d’emploi sémantique sur 200 offres LinkedIn réelles en utilisant Bright Data (scraping), Cohere (embeddings + rerank) et LanceDB (stockage vectoriel local).

La recherche par mots-clés correspond à des mots exacts. La recherche vectorielle correspond au sens. Une requête comme “ingénieur travaillant sur des LLMs” trouve un poste de “Développeur GenAI” que la recherche par mots-clés manque.
L’API Web Scraper de Bright Data retourne des offres LinkedIn structurées en JSON à 0,0015 $ par enregistrement, sans analyse HTML ni maintenance de Scraper.
LanceDB fonctionne localement et combine la recherche vectorielle avec des filtres SQL (salaire, ancienneté) en 1 requête, plus la recherche en texte intégral et le reranking Cohere.
Sur 10 requêtes de test, la recherche vectorielle a obtenu 70% de precision@3 contre 43% pour les mots-clés. Hybrid + rerank n’a apporté aucun gain mesurable à cette échelle, donc en dessous de ~10k lignes, le vecteur seul est une valeur par défaut raisonnable.
Le projet complet comprend 9 petits fichiers, dont un harnais d’évaluation, et le code complet est sur GitHub. L’exécution complète coûte environ 0,34 $.

Le problème avec la recherche par mots-clés

La recherche par mots-clés sur un site d’offres d’emploi fait exactement ce que vous demandez. Elle retourne les annonces dont le titre ou la description contient les tokens littéraux de votre requête. Cherchez “ingénieur travaillant sur des LLMs et du prompt engineering” et vous manquerez des postes comme “Développeur GenAI” même quand ils correspondent parfaitement. La recherche lexicale correspond aux mots exacts, pas au sens.

La recherche vectorielle s’appuie sur le sens. Chaque description de poste est convertie en embedding (un vecteur de haute dimension capturant son contenu sémantique), tout comme votre requête. Un poste dont le vecteur est proche de celui de votre requête est une bonne correspondance de sens, même quand il ne partage aucun des mêmes mots.

Transformer cela en moteur de recherche fonctionnel nécessite 3 éléments :

Bright Data scrape 200 vraies offres d’emploi LinkedIn en JSON structuré propre.
Cohere transforme les descriptions en embeddings et rerankeles résultats finaux.
LanceDB stocke les embeddings localement et sert des requêtes hybrides (vecteur + texte intégral) avec des filtres de type SQL.

La stack en un coup d’œil

Ce que fait chaque couche, et pourquoi nous l’utilisons :

Couche	Outil	Pourquoi celui-ci
Données web	Bright Data API Web Scraper	Le Scraper LinkedIn pré-construit retourne du JSON structuré avec salaire, ancienneté et localisation, sans analyse HTML ni maintenance de Scraper.
Embeddings	Cohere `embed-english-v3.0`	Encodage asymétrique (types d’entrée différents pour les documents vs les requêtes). Cohere propose aussi `embed-v4.0`, multimodal. Nous utilisons v3 pour son profil prix/latence en anglais uniquement (prévoir de ré-embedder avant la fin de vie de v3).
Reranker	Cohere `rerank-v3.5`	Nous épinglons v3.5 pour son profil prix/latence. Cohere propose aussi `rerank-v4.0` (`-pro` pour la qualité, `-fast` pour la latence).
Stockage vectoriel	LanceDB	Local, embarqué, sans serveur. Il supporte la recherche hybride (vecteur + BM25) et les préfiltres SQL.
UI (optionnel)	Streamlit	Interface web à code minimal pour une application Python de données.

Cette stack fonctionne depuis un seul venv Python sur votre ordinateur portable. Bright Data et Cohere sont les seuls services gérés impliqués.

Configuration

Le projet complet et exécutable est sur GitHub. Clonez-le et installez les dépendances (Python 3.10 ou plus récent) :

git clone https://github.com/triposat/semantic-job-search.git
cd semantic-job-search
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt

Copiez le fichier env d’exemple et ajoutez vos deux clés API, un token Bright Data et une clé Cohere depuis dashboard.cohere.com (une clé d’essai fonctionne pour tout le guide) :

cp .env.example .env
# then edit .env with your keys:
#   BRIGHTDATA_API_TOKEN=...
#   COHERE_API_KEY=...

Avec les deux clés en place, exécutez python scrape.py pour récupérer les données et python index.py pour construire l’index.

Architecture

Le système comporte deux flux, pas un. L’ingestion construit l’index (exécutée une fois, ou selon un calendrier). La requête s’exécute à chaque recherche. Les deux utilisent Cohere et LanceDB, mais pour des tâches différentes.

Les deux flux côte à côte. L’ingestion embed les documents et les stocke. La requête embed le texte de recherche, exécute une recherche vecteur + texte intégral avec un préfiltre SQL, puis rerankeles résultats. Cohere et LanceDB apparaissent dans les deux flux mais font un travail différent dans chacun, c’est pourquoi le rerank ne touche jamais le chemin d’ingestion.

3 scripts exécutent le pipeline : scrape.py, index.py, search.py. 6 autres helpers : lib.py (backend de recherche partagé), compare.py (comparaison de modes), eval.py (precision@3), stats.py (résumé du jeu de données), versions.py (navigateur de snapshots) et app.py (UI Streamlit).

Scraper LinkedIn avec Bright Data

LinkedIn est une source majeure de données d’emploi, mais il est difficile à scraper de manière fiable : limites de débit, balisage dynamique et HTML qui change sans préavis. L’API Web Scraper retourne du JSON structuré propre depuis des endpoints pré-construits, vous n’avez donc pas à maintenir des parseurs.

Choisir le bon endpoint

Bright Data expose plusieurs Scrapers LinkedIn :

Profils de personnes → profils de membres individuels
Informations sur les entreprises → pages d’entreprises
Offres d’emploi → Collecter par URL → URLs d’emplois spécifiques que vous avez déjà
Offres d’emploi → Découvrir par mot-clé ← c’est ce que nous voulons
Offres d’emploi → Découvrir par URL → emplois depuis une URL de résultats de recherche
Publications LinkedIn et Recherche de personnes → autres types d’entités

Découvrir par mot-clé est le bon choix car nous voulons une découverte d’emplois en masse depuis une requête de recherche. Un seul appel API retourne jusqu’à 1 000 offres d’emploi structurées par mot-clé, incluant le titre, l’entreprise, la localisation, le niveau d’ancienneté, le type d’emploi, la fourchette salariale si indiquée, et la description complète du poste.

Chaque Scraper a son propre dataset_id. Pour en trouver un, ouvrez la Bibliothèque de Scrapers de Bright Data, recherchez le site (ici, linkedin.com) et ouvrez-le. Choisissez l’endpoint Offres d’emploi → Découvrir par mot-clé, et son dataset_id (gd_lpfll7v5hcqtkxl6l) ainsi qu’une requête prête à l’emploi apparaissent dans le panneau Exemples de code. Un token valide est tout ce dont scrape.py a besoin pour l’appeler.

Tableau de bord Bright Data montrant le menu de la Bibliothèque de Web Scrapers, avec l'endpoint LinkedIn offres d'emploi → 'Découvrir par mot-clé' sélectionné dans la barre latérale gauche. Le panneau central montre l'onglet Configuration avec des exemples d'entrées (paris/chef de produit, New York/développeur python). Le panneau droit montre la vue Exemples de code avec une requête curl authentifiée contenant `dataset_id=gd_lpfll7v5hcqtkxl6l`.

La page du Scraper ‘Découvrir par mot-clé’. Le panneau Exemples de code à droite est là où vous trouverez le dataset_id.

Synchrone vs asynchrone

Bright Data propose 2 modes de livraison :

Synchrone (POST /datasets/v3/scrape) retourne les données en ligne, idéal pour les très petits lots.
Asynchrone (POST /datasets/v3/trigger) retourne un ID de snapshot. Vous interrogez la complétion et téléchargez le résultat, idéal pour tout ce qui est plus grand.

Dans nos exécutions, le temps de réponse était en moyenne de ~6 secondes par entrée. Pour 2 mots-clés avec limit_per_input=100 (200 emplois au total), un appel synchrone doit maintenir la connexion ouverte pendant tout le lot, ce qui risque de dépasser le délai. L’asynchrone est la valeur par défaut sûre.

Contrôler le coût avec des limites par entrée

Le paramètre de requête limit_per_input=N plafonne le nombre de résultats que chaque recherche d’entrée retourne, ce qui est exactement le levier que vous voulez pour des dépenses prévisibles :

2 keywords × 100 jobs × $0.0015 = $0.30 per run

Augmentez-le pour des exécutions plus importantes, jusqu’à 1 000 emplois par mot-clé.

Le code

Le Scraper déclenche un snapshot, interroge jusqu’à ce qu’il soit prêt, et télécharge le JSON. L’essentiel est ci-dessous (une version de production ajouterait des tentatives/backoff et une gestion d’erreurs plus riche) :

# scrape.py
import json, time, sys
from pathlib import Path
import requests
from lib import require_env

BD_TOKEN = require_env("BRIGHTDATA_API_TOKEN")
DATASET_ID = "gd_lpfll7v5hcqtkxl6l"  # LinkedIn jobs - discover by keyword
LIMIT_PER_INPUT = 100

SEARCHES = [
    {"location": "San Francisco", "keyword": "machine learning engineer",
     "country": "US", "time_range": "Past month", "job_type": "Full-time",
     "experience_level": "", "remote": "", "company": "", "location_radius": ""},
    {"location": "New York", "keyword": "python developer",
     "country": "US", "time_range": "Past month", "job_type": "Full-time",
     "experience_level": "", "remote": "", "company": "", "location_radius": ""},
]

API = "https://api.brightdata.com/datasets/v3"
HEADERS = {"Authorization": f"Bearer {BD_TOKEN}", "Content-Type": "application/json"}

def trigger_snapshot() -> str:
    r = requests.post(f"{API}/trigger", headers=HEADERS, json={"input": SEARCHES},
        params={"dataset_id": DATASET_ID, "type": "discover_new",
                "discover_by": "keyword", "include_errors": "true",
                "limit_per_input": str(LIMIT_PER_INPUT)})
    r.raise_for_status()
    return r.json()["snapshot_id"]

def wait_until_ready(snapshot_id: str) -> None:
    while True:
        status = requests.get(f"{API}/progress/{snapshot_id}", headers=HEADERS).json()["status"]
        if status == "ready": return
        if status == "failed": raise RuntimeError("snapshot failed")
        time.sleep(10)

def download(snapshot_id: str) -> list[dict]:
    return requests.get(f"{API}/snapshot/{snapshot_id}",
                        headers=HEADERS, params={"format": "json"}).json()

Exécution :

$ python scrape.py
→ scraping 2 keyword searches, max 100 jobs each
  estimated max cost: $0.30 (at $0.0015/record × 200 max records)
  triggered snapshot: sd_mojicp6g39xwbwqn2
  status: ready
✓ saved 204 jobs → data/raw_jobs.json
  actual cost: $0.31

Ce que vous récupérez

Chaque emploi dans le JSON comporte plus de 25 champs. Voici les plus importants :

{
  "job_posting_id": "<id>",
  "job_title": "Associate Machine Learning Engineer",
  "company_name": "ExampleCo",
  "job_location": "San Francisco, CA",
  "job_seniority_level": "Entry level",
  "job_employment_type": "Full-time",
  "job_industries": "Software Development",
  "job_summary": "About ExampleCo. ExampleCo is the career network for the AI economy...",
  "base_salary": {
    "min_amount": 115000,
    "max_amount": 144000,
    "currency": "$",
    "payment_period": "yr"
  },
  "job_posted_date": "2026-04-25T03:41:21.072Z",
  "url": "https://www.linkedin.com/jobs/view/<id>"
}

Le champ structuré base_salary est ce qui rend possible les requêtes de filtre salarial à l’étape suivante.

Indexer avec Cohere et LanceDB

Nous avons 204 enregistrements d’emplois bruts, dont 4 sont des lignes d’erreur que nous filtrons au chargement. Nous rendons maintenant les 200 restants sémantiquement interrogeables.

Pourquoi Cohere

Nous avons choisi Cohere plutôt que les alternatives (modèles d’embedding d’OpenAI, Voyage AI ou sentence-transformers locaux) :

Encodage asymétrique. Cohere vous permet de taguer l’entrée comme search_document lors de l’indexation ou search_query lors de la recherche. Le modèle encode chaque côté différemment, ce qui fonctionne mieux que de traiter les deux de la même façon.
Embedding déclaratif. Le registre de LanceDB supporte Cohere nativement (comme OpenAI et sentence-transformers), donc l’embedding se produit lors de l’insertion et de la requête sans appels embed() manuels.
L’API Rerank. C’est un modèle séparé qui prend une requête plus une liste de candidats et réordonne les candidats par pertinence réelle. C’est la deuxième étape qui peut affiner le classement d’un pipeline hybride, et nous ajoutons cette étape avec un seul appel .rerank().

Le registre d’embedding LanceDB

Les embeddings dans LanceDB passent par son registre d’embedding. Vous déclarez votre schéma une fois, et les embeddings se produisent automatiquement à chaque insertion et chaque requête, chacun avec le bon input_type.

# index.py
import lancedb
from lancedb.embeddings import get_registry
from lancedb.pydantic import LanceModel, Vector

cohere = get_registry().get("cohere").create(
    name="embed-english-v3.0",
    api_key=COHERE_API_KEY,
)

class Job(LanceModel):
    text: str = cohere.SourceField()              # ← what to embed
    vector: Vector(cohere.ndims()) = cohere.VectorField()  # ← stored embedding
    job_id: str
    title: str
    company: str
    location: str
    country_code: str
    seniority: str
    employment_type: str
    job_function: str
    industry: str
    posted_date: str
    apply_url: str
    search_keyword: str
    salary_min_annual: float
    salary_max_annual: float
    salary_currency: str
    salary_display: str
    description_snippet: str

Tout ce qui suit vector est une colonne stockée ordinaire, utilisée pour le filtrage et l’affichage.

L’astuce de normalisation salariale

La plupart des emplois ont des salaires indiqués par année, mais quelques-uns sont par heure. Pour que salary_min_annual >= 200000 fonctionne de manière cohérente, nous normalisons lors de l’ingestion :

HOURS_PER_YEAR = 2080

def _normalize_salary(base):
    if not base:
        return 0.0, 0.0, "", ""
    lo = float(base.get("min_amount") or 0)
    hi = float(base.get("max_amount") or 0)
    if (base.get("payment_period") or "").lower() == "hr":
        lo *= HOURS_PER_YEAR
        hi *= HOURS_PER_YEAR
    currency = base.get("currency") or ""
    display = f"{currency}{int(lo):,}–{currency}{int(hi):,}/yr" if (lo and hi) else ""
    return lo, hi, currency, display

Nous stockons à la fois les valeurs numériques brutes (pour les filtres) et une chaîne d’affichage lisible par l’humain (pour l’interface).

Mises à jour incrémentielles avec des upserts

La première fois qu’index.py s’exécute, il crée la table. Chaque exécution suivante est un upsert basé sur job_id :

result = (
    table.merge_insert("job_id")
         .when_matched_update_all()       # refresh existing job postings
         .when_not_matched_insert_all()   # add newly-discovered ones
         .execute(rows)
)
print(f"inserted={result.num_inserted_rows}, updated={result.num_updated_rows}")

Les nouvelles offres d’emploi provenant d’un nouveau scraping Bright Data sont insérées, et les offres re-postées (même job_id) ont leurs salaires, descriptions et horodatages actualisés. Pour supprimer entièrement les offres obsolètes, enchaînez .when_not_matched_by_source_delete().

L’ensemble de l’upsert est une transaction atomique unique. Comme Lance stocke les données en colonnes avec copie sur écriture, la ré-ingestion est une écriture incrémentielle plutôt qu’une reconstruction complète de la table.

Index scalaires pour des filtres SQL rapides

Quand search.py, where "salary_min_annual >= 200000" s’exécute, LanceDB applique le filtre avant le scan vectoriel (prefilter=True). À 200 lignes, c’est instantané dans tous les cas. À 200 000 lignes, le filtre parcourrait toute la colonne à moins que nous indiquions à LanceDB comment l’indexer :

table.create_scalar_index("salary_min_annual", index_type="BTREE",  replace=True)
table.create_scalar_index("seniority",         index_type="BITMAP", replace=True)
table.create_scalar_index("search_keyword",    index_type="BITMAP", replace=True)
table.create_scalar_index("employment_type",   index_type="BITMAP", replace=True)

2 types d’index couvrent nos besoins :

BTREE pour les colonnes triables à cardinalité élevée. salary_min_annual en bénéficie car nous voulons des requêtes de plage (>=, BETWEEN).
BITMAP pour les enums à faible cardinalité. seniority a ~6 valeurs distinctes, employment_type est presque tout Full-time, et search_keyword est l’une de nos 2 entrées de scraping. Chaque valeur distincte obtient son propre bitmap. Un filtre = devient un simple AND bit à bit.

Les deux s’exécutent avec replace=True, donc réexécuter index.py les reconstruit de manière idempotente. Après l’appel, table.list_indices() rapporte les 5 (les 4 scalaires + l’index FTS) :

text_idx               type=FTS      columns=['text']
salary_min_annual_idx  type=BTree    columns=['salary_min_annual']
seniority_idx          type=Bitmap   columns=['seniority']
search_keyword_idx     type=Bitmap   columns=['search_keyword']
employment_type_idx    type=Bitmap   columns=['employment_type']

Inspecter les données indexées

Après avoir exécuté python index.py, notre script compagnon stats.py résume ce qui est dans la base de données :

$ python stats.py

📊 LanceDB · table 'jobs'  ·  200 rows

by source keyword
  machine learning engineer  ████████████████████ 100
  python developer           ████████████████████ 100

by seniority
  Mid-Senior level  ████████████████████ 99
  Entry level       ████████████ 62
  Not Applicable    ████ 20
  Internship        ██ 14
  Associate          4
  Director           1

salary coverage: 43/200 jobs (22%)
  min  $   65,000
  med  $  150,000
  max  $1,000,000

  highest-paying jobs:
    • Quantitative Developer (Python)                  Fintal Partners       $400,000–$1,000,000/yr
    • Machine Learning Engineer                        Mercor                $130,000–$500,000/yr
    • Data Scientist                                   Triumph               $200,000–$400,000/yr
    • Senior Python Developer (Middle Office Tech)     Quantitative Systems  $200,000–$400,000/yr
    • ML Engineer (Infra & Distributed training)       techire ai            $250,000–$400,000/yr

top hiring companies (top 10)
  Turing          ████████████████████ 7
  Handshake       █████████████████ 6
  OpenAI          █████████████████ 6
  Meta            █████████████████ 6
  Jack & Jill     ██████████████ 5
  DataAnnotation  ██████████████ 5
  Catalyst Labs   ███████████ 4
  Notion          ███████████ 4
  LangChain       ███████████ 4
  Uber            ████████ 3

Exécuter la recherche hybride avec reranking

LanceDB supporte 3 modes de recherche, et notre lib.py expose les 3 derrière une seule fonction :

# lib.py
from lancedb.rerankers import CohereReranker

reranker = CohereReranker(model_name="rerank-v3.5")  # pinned; Cohere's newer model is rerank-v4.0

def search(query: str, mode: str = "hybrid", limit: int = 10, where: str | None = None):
    table = _table()
    if mode == "vector":
        q = table.search(query, query_type="vector")
    elif mode == "keyword":
        q = table.search(query, query_type="fts")
    elif mode == "hybrid":
        q = table.search(query, query_type="hybrid").rerank(reranker=reranker)
    if where:
        q = q.where(where, prefilter=True)
    return q.limit(limit).to_pandas()

Trois éléments de search() méritent une explication :

query_type="hybrid" combine la similarité vectorielle et les scores BM25 de l’index de texte intégral que nous avons construit lors de l’indexation (FTS natif de LanceDB). L’union des candidats est ensuite rerankée.
.rerank(reranker) envoie la liste de candidats à l’API Rerank de Cohere et retourne son classement. Nous passons model_name="rerank-v3.5" explicitement car le défaut de LanceDB est plus ancien.
prefilter=True applique la clause SQL WHERE avant le scan vectoriel, pas après. C’est plus rapide (espace de recherche plus petit) et plus précis (vous ne perdez pas de résultats par troncature).

Une vraie requête

Voici les 2 premiers résultats pour une requête qui ne partage pas beaucoup de mots littéraux avec un titre d’emploi dans le jeu de données :

$ python search.py "deep learning model training with GPUs"

  ▸ Training: ML Framework Engineer  ·  score 0.275
    OpenAI — San Francisco, CA
    Entry level · Full-time · 2026-04-22
    "About The Team Training Runtime designs the core distributed
     machine-learning training runtime that powers everything from early
     research experiments to frontier-scale model runs..."

  ▸ Machine Learning Engineer  ·  score 0.138
    Skild AI — San Mateo, CA
    Entry level · Full-time · 2026-04-15
    "Company Overview At Skild AI, we are building the world's first
     general purpose robotic intelligence that is robust and adapts to
     unseen scenarios without failing. We believe massive scale through
     data-driven machine learning..."

Aucun titre de poste ne contient “GPUs”, mais les deux descriptions portent sur l’entraînement ML distribué, ce qui est l’objet de la requête. Une recherche par mots-clés pure manquerait probablement les deux.

Chaque mode retourne un type de score différent. Le mode vectoriel retourne la distance cosinus (plus bas = plus proche), hybrid+rerank retourne le score de pertinence de Cohere (0 à 1, plus haut = meilleur), et le mode par mots-clés retourne le BM25 brut (non borné, plus haut = plus de chevauchement de mots-clés). Les chiffres ne sont pas comparables d’un mode à l’autre, seulement au sein d’un seul mode.

Combiner la sémantique avec des contraintes strictes

La similarité sémantique et les filtres SQL se combinent en une seule requête dans LanceDB :

$ python search.py "fintech python role with equity" \
    --where "salary_min_annual >= 250000"

  ▸ Quantitative Developer (Python)  ·  score 0.374
    Fintal Partners — New York, United States
    Mid-Senior level · Full-time · $400,000–$1,000,000/yr · 2026-04-22

  ▸ Senior Software Engineer (Python)  ·  score 0.272
    Fintal Partners — New York, NY
    Mid-Senior level · Full-time · $250,000–$400,000/yr · 2026-04-23

La partie vectorielle correspond à la partie descriptive (“fintech python avec equity”). Le filtre SQL applique la contrainte numérique (>= 250k$). Les deux résultats sont des postes chez Fintal Partners dans la bonne fourchette salariale.

Le même pattern hybride + filtre s’exécute dans l’interface Streamlit, sur un scraping ultérieur (les annonces en direct diffèrent de l’exécution CLI ci-dessus) :

Interface de recherche Streamlit avec la requête 'fintech python role with equity' et le curseur Salaire min dans la barre latérale réglé à 250 000 $. L'en-tête des résultats indique '3 résultats · mode : hybrid · filtre : salary_min_annual >= 250000′. La carte du premier résultat montre Senior Software Engineer (Python) chez Fintal Partners à New York, NY, avec des badges Mid-Senior level, Full-time, et un badge vert de salaire indiquant $300 000,$500 000/an, score de pertinence 0.272, et un extrait sur une société de trading quantitatif. Un deuxième résultat, Data Scientist chez OpenArt AI à San Francisco, score 0.165, commence en dessous.”/></figure>
<p class=

Graphique à barres de precision@3 sur 10 requêtes de test : mots-clés 43%, vecteur 70%, hybrid + rerank 67%.

Élément	Coût
Scraping Bright Data (204 enregistrements à 0,0015 $/enregistrement)	0,31 $
Embeddings Cohere (~228k tokens au total à 0,10 $/1M)	~0,02 $
Rerank Cohere (~0,002 $/requête, Rerank v3.5 à 2 $ / 1k recherches)	~0,01 $ pour 5 requêtes
LanceDB	gratuit

Domaine	Produit Bright Data	Ce que vous interrogeriez
Accès web agentique	The Web MCP (niveau gratuit actuellement 5 000 requêtes/mois)	“donner à un agent IA des outils de recherche et de scraping en direct, puis ancrer ses réponses dans un cache soutenu par LanceDB de résultats passés”
Corpus de sites entiers	API Crawl	“indexer un site de documentation entier ou une base de connaissances pour la récupération hybride”
E-commerce	API Web Scraper (produits Amazon)	“chaussures de course confortables à moins de 100 $ avec 4+ étoiles”
Immobilier	API Web Scraper (Zillow / Redfin)	“maison familiale calme près de bonnes écoles, 3+ chambres”
Intelligence des actualités	API SERP + Web Unlocker	“articles sur la sécurité de l’IA de cette semaine, classés par pertinence par rapport à l’alignement”
Prospection commerciale	Informations sur les entreprises LinkedIn	“startups Série A dans la santé IA basées en Europe”
Restaurants	Jeu de données Yelp	“restaurant italien cosy avec terrasse”

Contacter ventes Essai gratuit

Construire un moteur de recherche d’emploi sémantique avec Bright Data, LanceDB et Cohere

TL;DR

Le problème avec la recherche par mots-clés

La stack en un coup d’œil

Configuration

Architecture

Scraper LinkedIn avec Bright Data

Choisir le bon endpoint

Synchrone vs asynchrone

Contrôler le coût avec des limites par entrée

Le code

Ce que vous récupérez

Indexer avec Cohere et LanceDB

Pourquoi Cohere

Le registre d’embedding LanceDB

L’astuce de normalisation salariale

Mises à jour incrémentielles avec des upserts

Index scalaires pour des filtres SQL rapides

Inspecter les données indexées

Exécuter la recherche hybride avec reranking

Une vraie requête

Combiner la sémantique avec des contraintes strictes

Là où les mots-clés, le vecteur et l’hybride divergent

Mesurer la qualité avec precision@3

Ce que disent les chiffres

Quand activer hybrid + rerank

Ajouter une interface web avec Streamlit

Voyage dans le temps gratuit avec LanceDB

Coût et échelle

Passer à l’échelle

8 bugs et pièges que nous avons rencontrés

Ce que vous pouvez construire ensuite

Prochaines étapes

FAQ

Puis-je l’utiliser pour d’autres sites que LinkedIn ?

Ai-je besoin d’un compte Cohere payant pour cela ?

Pourquoi LanceDB, et pas Pinecone, Weaviate ou pgvector ?

À quelle fréquence devrais-je réexécuter le Scraper ?

Vous pourriez aussi être intéressé par

Hermes Agent + Bright Data : Construire l’assistant IA web ultime

Les meilleurs outils CLI pour Claude Code en 2026

Services gérés vs. Scraping web DIY : Le guide complet 2026