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’emploi ne recherchent que par mots exacts, donc le bon poste reste caché quand votre formulation ne correspond pas à l’annonce. La recherche sémantique associe sur le sens à la place. Nous la construisons de bout en bout, puis mesurons quel mode de recherche gagne plutôt que de supposer que le plus complexe l’emporte.

TL;DR

Ce guide construit un moteur de recherche d’emploi sémantique sur 200 vraies offres LinkedIn en utilisant Bright Data (Scraping web), Cohere (embeddings + rerank) et LanceDB (vector store local).

La recherche par mots-clés correspond aux mots exacts. La recherche vectorielle correspond au sens. Une requête comme « ingénieur qui travaille sur les LLMs » trouve un poste « Développeur GenAI » que la recherche par mots-clés rate.
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 plein texte et le reranking Cohere.
Sur 10 requêtes de test, la recherche vectorielle a obtenu 70 % de précision@3 contre 43 % pour les mots-clés. Le mode hybride + rerank n’a apporté aucune amélioration mesurable à cette échelle, donc en dessous de ~10 000 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 ~0,34 $.

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

La recherche par mots-clés sur un site 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. Demandez « ingénieur qui travaille sur les LLMs et le prompt engineering » et vous raterez 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 correspond au sens. Chaque description de poste est convertie en embedding (un vecteur haute dimension qui capture son contenu sémantique), ainsi que votre requête. Un poste dont le vecteur est proche de celui de votre requête est une bonne correspondance en termes 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 reclasse les résultats finaux.
LanceDB stocke les embeddings localement et sert des requêtes hybrides (vecteur + plein texte) avec des filtres de style 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`, qui est multimodal. Nous utilisons v3 ici 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).
Vector store	LanceDB	Local, embarqué, sans serveurs. Il supporte la recherche hybride (vecteur + BM25) et les préfiltres SQL.
UI (optionnel)	Streamlit	Interface web à code minimal pour une application de données Python.

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 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=...

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 comprend deux flux, pas un. L’ingestion construit l’index (exécuté une fois, ou selon un calendrier). La requête s’exécute à chaque recherche. Les deux utilisent Cohere et LanceDB, mais pour des travaux différents.

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 + plein texte avec un préfiltre SQL, puis reclasse. 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 (précision@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 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, donc vous ne maintenez pas de parsers.

Choisir le bon endpoint

Bright Data expose plusieurs Scrapers LinkedIn :

Profils de personnes → profils de membres individuels
Informations d’entreprise → pages d’entreprises
Offres d’emploi → Collecter par URL → URLs d’emploi 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 titre, entreprise, localisation, niveau d’ancienneté, type d’emploi, 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 à exécuter 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/product manager, New York/python developer). 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 petits lots.
Asynchrone (POST /datasets/v3/trigger) retourne un ID de snapshot. Vous interrogez jusqu’à 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 pour tout le lot, ce qui risque d’expirer. 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 une dépense prévisible :

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

Augmentez-le pour des exécutions plus grandes, 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 obtenez en retour

Chaque emploi dans le JSON possède plus de 25 champs. Voici ceux qui comptent :

{
  "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 possibles les requêtes de filtre par salaire à l’étape suivante.

Indexer avec Cohere et LanceDB

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

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 à l’insertion et à la requête sans appels manuels à embed().
L’API Rerank. C’est un modèle séparé qui prend une requête et 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()              # ← quoi embedder
    vector: Vector(cohere.ndims()) = cohere.VectorField()  # ← embedding stocké
    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 des salaires

La plupart des emplois ont des salaires exprimés par an, mais quelques-uns sont par heure. Pour que salary_min_annual >= 200000 fonctionne de manière cohérente, nous normalisons à 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’homme (pour l’UI).

Mises à jour incrémentielles avec des upserts

La première fois que 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()       # actualiser les offres d'emploi existantes
         .when_not_matched_insert_all()   # ajouter les nouvelles découvertes
         .execute(rows)
)
print(f"inserted={result.num_inserted_rows}, updated={result.num_updated_rows}")

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

L’upsert entier est une transaction atomique unique. Parce que Lance stocke les données de manière colonnaire 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 ne disions à 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 ce dont nous avons besoin :

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 entièrement Full-time, et search_keyword est l’un de nos 2 mots-clés de scrape. 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 se trouve 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")  # épinglé ; le modèle plus récent de Cohere est 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 plein texte que nous avons construit au moment de l’indexation (FTS natif de LanceDB). L’union des candidats est ensuite reclassée.
.rerank(reranker) envoie la liste de candidats à l’API Rerank de Cohere et retourne son classement. Nous passons explicitement model_name="rerank-v3.5" car le défaut 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 meilleurs résultats pour une requête qui ne partage pas beaucoup de mots littéraux avec un titre de poste 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 parlent d’entraînement ML distribué, ce qui est ce que la requête demande. La recherche par mots-clés purs raterait probablement les deux.

Chaque mode retourne un type de score différent. Le mode vectoriel retourne la distance cosinus (plus bas = plus proche), hybride+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 entre les modes, 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 (>= 250 000 $). Les deux résultats sont des postes Fintal Partners dans la bonne fourchette salariale.

Le même pattern hybride + filtre s’exécute dans l’UI Streamlit, sur un scrape 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 minimum dans la barre latérale réglé à 250 000 $. L'en-tête des résultats indique '3 résultats · mode : hybride · 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 de salaire vert 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 précision@3 sur 10 requêtes de test : mots-clés 43 %, vecteur 70 %, hybride + rerank 67 %.

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

Domaine	Produit Bright Data	Ce que vous interrogeriez
Accès web agentique	Le MCP Bright Data (niveau gratuit actuellement 5 000 requêtes/mois)	« donner à un agent IA des outils de recherche + scrape en direct, puis ancrer ses réponses dans un cache LanceDB de résultats passés »
Corpus de sites entiers	API de 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 d’actualités	API SERP + Web Unlocker	« articles sur la sécurité IA de cette semaine, classés par pertinence pour l’alignement »
Prospection commerciale	Infos entreprises LinkedIn	« startups Série A en IA de santé 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 obtenez en retour

Indexer avec Cohere et LanceDB

Pourquoi Cohere

Le registre d’embedding LanceDB

L’astuce de normalisation des salaires

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

Où les mots-clés, le vecteur et le mode hybride divergent

Mesurer la qualité avec précision@3

Ce que disent les chiffres

Quand activer hybride + rerank

Ajouter une interface web avec Streamlit

Le voyage dans le temps gratuit avec LanceDB

Coût et échelle

Monter en é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, pas Pinecone, Weaviate ou pgvector ?

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

Vous pourriez aussi être intéressé par

Accès Web Prêt pour la Production dans OpenHuman via le CLI Bright Data

Scraping Web Multimodal avec MiniMax

Les 10 meilleurs outils CLI pour Codex en 2026 – Testés & Classés