Guide complet de l'API Jina (2026)

Vous avez sans doute vu le nom « Jina AI » revenir régulièrement dans les discussions techniques autour du RAG (Retrieval-Augmented Generation) ces derniers mois — mais ce n'est pas le genre de nouveauté qui devient virale du jour au lendemain et envahit les réseaux sociaux. Rien qu'en nombre d'étoiles GitHub, le dépôt open source de Jina Reader tourne autour de 11 000 étoiles — à peine une erreur d'arrondi face aux plus de 130 000 de Firecrawl. Mais au cours des dix derniers mois, deux événements réels se sont produits, suffisamment concrets pour remettre sur la table la question du « comment choisir sa couche de récupération RAG » : le 9 octobre 2025, Elastic — la société d'infrastructure de recherche cotée au Nasdaq, éditrice d'Elasticsearch — a finalisé le rachat intégral de Jina AI ; et après ce rachat, l'équipe Jina n'a pas ralenti le rythme de sortie de ses modèles, publiant deux nouvelles générations de modèles Embeddings en février puis en mai 2026.

Cet article essaie de poser les choses honnêtement : pourquoi l'API Jina mérite votre attention en ce moment, où se situent réellement ses forces et ses faiblesses face à Firecrawl / Tavily / Exa / Diffbot, et — à l'aide d'un pipeline que nous avons réellement testé — comment transformer un ensemble de pages web en un graphe de connaissances métier véritablement interrogeable. Précision d'entrée de jeu : la gamme de produits de Jina ne propose aucune API « générer un graphe de connaissances en un clic » — c'est plutôt le positionnement de Diffbot. Le tutoriel de cet article présente un pipeline que vous devez assembler vous-même, dans lequel Jina prend en charge les couches d'exploration et de vectorisation.

1. Ce qu'est Jina AI, et ce qui s'est passé après le rachat par Elastic

Jina AI (jina.ai) ne fait pas de complétion conversationnelle et ne cherche pas à concurrencer GPT/Claude sur ce terrain principal. Elle se concentre au contraire en profondeur sur le trio de la « couche de récupération », le plus critique — et le plus souvent négligé — de l'ingénierie RAG : Embeddings, Reranker et Reader (transformer une page web en texte propre), ainsi qu'une famille de produits connexes construits autour du même système : Search (recherche web), DeepSearch, Classifier et Segmenter. Tous ces produits partagent la même clé API et le même pool de tokens — c'est le choix de conception central qui la distingue des « fournisseurs d'embeddings à usage unique » comme Voyage AI, qui ne fait que de l'embedding. L'avis déjà publié sur ce site, API Jina AI, couvre en détail la tarification, le crédit gratuit et d'autres aspects ; cet article se concentre sur deux choses : pourquoi elle mérite votre attention, et comment l'utiliser pour construire un graphe de connaissances.

Le 9 octobre 2025, Elastic (la société mère d'Elasticsearch, cotée au Nasdaq sous le symbole ESTC) a finalisé le rachat intégral de Jina AI ; son communiqué officiel présente Jina AI comme « un leader des modèles de pointe pour la recherche multimodale et multilingue ». Han Xiao, fondateur et ex-CEO de Jina AI, est devenu VP of AI chez Elastic après le rachat. Elastic a explicitement déclaré qu'elle poursuivrait la pratique antérieure de Jina AI consistant à publier ses modèles en open source sur Hugging Face et à continuer de publier des travaux de recherche académique — ce qui signifie que la gamme Embeddings/Reranker/Reader de Jina continue actuellement de fonctionner de façon indépendante, dans le cadre de la stratégie « Search AI Platform » d'Elastic, plutôt que d'être mise de côté ou abandonnée.

L'itération des modèles ne s'est pas ralentie après le rachat — le rythme est même resté soutenu :

• 18 février 2026 : sortie de la série jina-embeddings-v5-text (paliers small/nano) — scores moyens MTEB English v2 annoncés officiellement de 71,7 pour le palier small (677M de paramètres) et 71,0 pour le palier nano (239M de paramètres), le meilleur score à l'époque parmi les modèles d'embedding multilingues de moins d'1 milliard de paramètres, avec prise en charge de plus de 119 langues et un contexte allant jusqu'à 32K tokens
• 11 mai 2026 : Elastic publie officiellement jina-embeddings-v5-omni, le premier modèle multimodal partageant le même espace vectoriel que v5-text — texte, image, vidéo et audio peuvent tous être encodés dans le même espace vectoriel, ce qui signifie que les utilisateurs ayant déjà indexé leurs données avec v5-text peuvent basculer directement sur le modèle omni pour injecter images/vidéos/audio dans la même base vectorielle, sans avoir à tout réindexer

Ces deux événements constituent ensemble l'argument central de cet article sur le « pourquoi s'y intéresser maintenant » — non pas une viralité sur les réseaux sociaux, mais un véritable rachat et une intégration d'entreprise, associés à un rythme de publication de modèles à l'état de l'art qui s'est maintenu après la finalisation de l'opération. La section suivante distingue honnêtement ce point de la question « est-ce que c'est vraiment un phénomène de mode ».

2. Pourquoi l'API Jina mérite votre attention maintenant : trois raisons vérifiables

Soyons clairs d'emblée : mesuré en étoiles GitHub ou en bruit sur les réseaux sociaux, Jina Reader n'est pas actuellement l'acteur le plus bruyant de ce secteur. Nous l'avons spécifiquement vérifié en préparant cet article — le dépôt open source de Firecrawl a dépassé les 130 000 étoiles, ce qui le place parmi les 100 projets les plus étoilés de tout GitHub ; celui de Jina Reader tourne autour de 11 000 à 12 000 étoiles, un ordre de grandeur en dessous. Donc si « l'API Jina est soudain partout » est compris littéralement comme « une explosion virale qui a éclipsé la concurrence en peu de temps », cette affirmation ne tient pas — et cet article choisit de le dire honnêtement plutôt que de l'esquiver pour un titre plus accrocheur.

Mais posez une question plus précise — « l'API Jina mérite-t-elle encore que les développeurs RAG y consacrent du temps » — et la réponse est oui, pour trois raisons qui résistent à l'examen :

1. Être racheté par un acteur d'infrastructure plus important, et continuer d'y recevoir des investissements, est un signal plus solide qu'une propagation virale

Qu'une start-up indépendante spécialisée dans la couche de récupération RAG soit rachetée intégralement par une société cotée de la taille d'Elastic, elle-même acteur majeur de l'infrastructure de recherche, constitue en soi une forme de validation — cela indique que la pile technique de Jina a été jugée « digne d'être intégrée dans une capacité centrale de plateforme de recherche d'entreprise », et non comme un simple jouet de développeur isolé. Elastic s'est explicitement engagée à poursuivre le rythme de publication en open source après la finalisation de l'opération, et le fondateur a rejoint l'acquéreur en tant que VP of AI plutôt que d'encaisser et de partir — ces détails pointent ensemble vers un signal relativement stable : dans un avenir prévisible au moins, la gamme de produits API de Jina continuera probablement d'être maintenue et de bénéficier d'investissements, plutôt que d'être abandonnée ou mise de côté. C'est une forme d'attention de type « rachat et intégration d'infrastructure d'entreprise », une nature de popularité complètement différente d'un « buzz viral du jour au lendemain » — mais pour un développeur en phase de choix technologique, la première est en réalité le signal le plus pertinent à prendre en compte.

2. Le rythme de sortie des modèles ne s'est pas ralenti après le rachat, et il s'accompagne de résultats de benchmarks vérifiables

Beaucoup d'entreprises traversent une phase d'accalmie silencieuse dans l'intégration de leurs gammes de produits après un rachat, mais ce n'est pas ce qui s'est produit, pour l'instant, du côté Jina/Elastic — v5-text (février 2026) et v5-omni (mai 2026) sont sortis à moins de trois mois d'intervalle, et v5-text a obtenu un résultat précis et vérifiable — « meilleur score MTEB parmi les modèles d'embedding multilingues de moins d'1 milliard de paramètres » (confirmé à la fois par l'annonce officielle et par la fiche modèle Hugging Face) — tandis que v5-omni constitue une tentative technique rare consistant à partager un même espace vectoriel entre texte, image, vidéo et audio. Cela suggère que le rachat n'a pas ralenti l'itération produit ; les ressources d'Elastic ont même pu rendre le rythme plus stable.

3. La différenciation structurelle elle-même n'a rien perdu de sa pertinence — elle a toujours existé, elle bénéficie simplement aujourd'hui d'une caution plus forte

Plusieurs arguments techniques de longue date de Jina restent valables en 2026, et leur combinaison demeure rare parmi les produits comparables : Embeddings + Reranker + Reader partageant la même clé API et le même pool de tokens gratuits (10M de tokens, sans carte bancaire), ainsi que la prise en charge par Embeddings du Late Chunking (encoder un document long entier en une seule passe pour préserver le contexte inter-segments, puis en extraire des vecteurs par segment) et de l'apprentissage de représentation Matryoshka (les vecteurs peuvent être tronqués à des dimensions plus basses à la demande pour économiser du stockage). Aucune de ces fonctionnalités n'est nouvelle en 2026, mais leur combinaison reste rare dans le créneau du « pack complet de couche de récupération » — la section 3 les compare point par point à la concurrence, sans passer sous silence les points sur lesquels Jina accuse aujourd'hui clairement du retard.

3. API Jina face à la concurrence : forces, faiblesses et comparatif honnête

À la mi-2026, le créneau « URL/page web → contenu propre prêt pour un LLM + vectorisation » est devenu un marché encombré, avec au moins trois niveaux de concurrence et une quinzaine d'acteurs actifs en même temps — les concurrents directs incluent Firecrawl, Exa, Tavily, Diffbot et Spider.cloud, tandis que les fournisseurs de scraping généralistes (ScrapingBee, ScraperAPI) ont eux aussi ajouté des fonctionnalités « export Markdown pour LLM ». Voici un comparatif vérifié.

Là où les avantages de Jina tiennent réellement la route

• Le seul fournisseur à regrouper embedding + reranking + exploration dans un même système de compte : Firecrawl/Tavily/Exa/Diffbot fonctionnent chacun avec une facturation séparée — même en les utilisant simultanément, il faut gérer quotas et factures séparément pour chacun. Jina couvre les trois avec la même clé et le même pool gratuit de 10M tokens ; pour les équipes utilisant déjà Jina Embeddings/Reranker, Reader devient « un point d'accès supplémentaire bien pratique » plutôt que « un nouveau compte à ouvrir »
• Un mode d'appel minimaliste par préfixe d'URL : r.jina.ai/<URL cible>, une requête GET sans corps JSON ni SDK — la section 4 le teste en direct, et même les appels anonymes fonctionnent de bout en bout, ce qui est plus léger que la plupart des concurrents (qui exigent un POST avec un corps JSON et une clé dans l'en-tête)
• Aucune preuve, à ce jour, d'une version auto-hébergée amputée : Firecrawl reconnaît explicitement que sa version auto-hébergée est privée du moteur anti-bot propriétaire cloud (Fire-engine), des points de terminaison Agent et du bac à sable navigateur ; cette recherche n'a trouvé aucune déclaration officielle de Jina concernant une réduction de fonctionnalités dans sa version auto-hébergée — cela ne prouve pas que « Jina est nécessairement plus complète » (il n'existe pas de liste de fonctionnalités équivalente permettant une comparaison point par point), mais au moins aucun contre-exemple n'a été trouvé

Reconnu honnêtement : là où la concurrence est clairement en avance

• L'écosystème open source affiche un écart d'un ordre de grandeur : 130K+ étoiles pour Firecrawl contre environ 11K pour Jina Reader — l'activité communautaire et les intégrations tierces (présence dans les écosystèmes LangChain/LlamaIndex) sont probablement plus fortes du côté de Firecrawl en conséquence
• Une facturation par page/par requête est plus facile à estimer qu'une facturation par token : la plupart des concurrents — Firecrawl, Tavily, ScrapingBee — facturent « un crédit fixe par page » ou « un prix fixe par requête », tandis que la facturation par token de Jina est plus difficile à estimer à l'avance pour les pages longues ; la page de tarification officielle de Jina renvoyait une erreur 404 au moment de la vérification pour cet article, il faut donc se référer à la page actuelle du tableau de bord une fois connecté plutôt que de supposer un chiffre fixe
• Les produits combinant recherche et extraction en un seul appel grignotent le besoin même d'un appel Reader séparé : Tavily Extract, Exa Contents et le point de terminaison LLM Context de Brave permettent tous de « rechercher puis extraire à la demande » en un seul appel. Jina dispose bien d'une API Search séparée (s.jina.ai), mais Search et Reader restent deux points de terminaison distincts — elle n'a pas fusionné « récupération + extraction » en une seule réponse. À cela s'ajoute le fait que l'outil URL Context de l'API Gemini de Google est passé en disponibilité générale complète en 2026, permettant au modèle de lire directement une URL — une pression structurelle de long terme pour l'ensemble du créneau des « API Reader autonomes », Jina Reader compris
• Diffbot est le produit qui mérite réellement le terme « graphe de connaissances » : Diffbot dispose d'un produit Knowledge Graph dédié et d'une Natural Language API — une capacité totalement absente chez Jina —, même si Diffbot se positionne davantage sur l'entreprise, avec un tarif de départ à 299 $/mois, une barrière de prix nettement plus élevée. C'est aussi la raison pour laquelle le titre de cet article n'ose pas affirmer « générer un graphe de connaissances en un clic avec l'API Jina » — la section suivante explique honnêtement comment procéder réellement

En une phrase : si vous utilisez déjà Jina Embeddings/Reranker comme couche de récupération, Reader est un complément à coût marginal quasi nul ; si vous avez besoin d'un écosystème open source mature, d'une tarification par page prévisible, ou d'une recherche-extraction en un seul appel, Firecrawl/Tavily méritent réellement d'être considérés sur leurs points forts respectifs ; si vous avez besoin d'un produit de graphe de connaissances prêt à l'emploi plutôt que d'assembler votre propre pipeline, Diffbot se rapproche davantage de ce que vous cherchez, mais il faudra accepter une barrière de prix plus élevée.

4. Démarrage rapide : authentification, limites de débit et l'appel le plus simple

4.1 Obtenir une clé API

Générez-en une en un clic sur jina.ai/?sui=apikey — aucune carte bancaire requise. Chaque nouvelle clé est dotée d'un crédit gratuit de 10M tokens, partagé entre les pools de tokens Embeddings / Reranker / Reader — si une tâche Embeddings en masse épuise le crédit en avance, Reader en subit aussi les conséquences. Le site officiel précise que le crédit gratuit est réservé à un usage non commercial ; référez-vous à la page actuelle du tableau de bord pour les conditions exactes.

4.2 Authentification

Toutes les API utilisent une authentification standard par Bearer token :

Authorization: Bearer $JINA_API_KEY

4.3 Limites de débit

4.4 L'appel le plus simple : Reader, sans même de clé

La conception la plus intuitive de Reader : ajoutez directement l'URL cible après https://r.jina.ai/, envoyez une requête GET, sans en-tête, sans clé API. Nous l'avons testé en direct pour cet article (19 juillet 2026) :

curl "https://r.jina.ai/https://en.wikipedia.org/wiki/Retrieval-augmented_generation"

Résultat réel : HTTP 200, environ 2,85 secondes, en-tête de réponse x-usage-tokens: 7486 (tokens consommés), x-ratelimit-limit: 20, 20;w=60 — cet en-tête confirme directement la limite documentée de « 20 appels anonymes par 60 secondes », vérifiable sans même avoir besoin d'une clé. Début du contenu retourné (extrait authentique, rien d'inventé) :

Title: Retrieval-augmented generation

URL Source: https://en.wikipedia.org/wiki/Retrieval-augmented_generation

Published Time: 2023-11-05T13:19:20Z

Markdown Content:
From Wikipedia, the free encyclopedia

**Retrieval-augmented generation** (**RAG**) is a technique that enables
large language models (LLMs) to retrieve and incorporate new information
from external data sources. With RAG, LLMs first refer to a specified
set of documents, then respond to user queries...

Le contenu retourné suit une structure fixe en trois parties : Title / URL Source / Markdown Content, et la page récupérée cette fois-ci comportait aussi un champ Published Time (toutes les pages n'en ont pas — cela dépend si la page cible elle-même porte des métadonnées de date de publication). Le tutoriel de la section 5 s'appuie directement sur cette récupération réelle.

5. Tutoriel : construisez votre propre graphe de connaissances métier avec l'API Jina

5.1 Conception globale du pipeline

Un déroulé en cinq étapes — il est important de bien distinguer le périmètre de responsabilité de chacune :

Liste d'URL de documents métier
   │
   ▼
Étape 1  Récupération en masse via Jina Reader      → Texte Markdown propre
   │
   ▼
Étape 2  Le LLM extrait entités/relations           → JSON structuré (entities + relations)
   │        (Jina ne fournit pas cette couche — apportez votre propre LLM)
   ▼
Étape 3  Jina Embeddings vectorise les entités      → Utilisé pour la déduplication/fusion sémantique
   │
   ▼
Étape 4  Assemblage en structure de graphe          → Nœuds/arêtes JSON / NetworkX / Neo4j
   │
   ▼
Étape 5  Requête / récupération de sous-graphe      → Intégré au contexte du prompt RAG en aval

5.2 Étape 1 : récupération en masse des documents métier avec Jina Reader (test réel)

Nous avons utilisé deux vraies pages Wikipedia pour simuler « un petit corpus métier » — Retrieval-augmented generation et Vector database. En pratique, remplacez DOMAIN_URLS par de vrais documents de votre propre domaine (wiki d'entreprise, documentation produit, pages d'articles scientifiques conviennent tous) :

import requests

DOMAIN_URLS = [
    "https://en.wikipedia.org/wiki/Retrieval-augmented_generation",
    "https://en.wikipedia.org/wiki/Vector_database",
    # remplacez par de vraies URL de documents de votre domaine
]

JINA_API_KEY = None  # fonctionne aussi en anonyme (limite 20 RPM) ; utilisez votre propre clé en production (500 RPM sur le palier gratuit)

def fetch_clean_text(url: str) -> dict:
    headers = {"X-Return-Format": "markdown"}
    if JINA_API_KEY:
        headers["Authorization"] = f"Bearer {JINA_API_KEY}"
    resp = requests.get(f"https://r.jina.ai/{url}", headers=headers, timeout=60)
    resp.raise_for_status()
    return {
        "url": url,
        "tokens_used": resp.headers.get("x-usage-tokens"),
        "text": resp.text,
    }

corpus = [fetch_clean_text(u) for u in DOMAIN_URLS]
for doc in corpus:
    print(doc["url"], "→", doc["tokens_used"], "tokens")

Résultats réels de ce test (19 juillet 2026, appels anonymes, sans clé) : la récupération de la page Retrieval-augmented generation a renvoyé un HTTP 200 en environ 2,85 secondes et consommé 7 486 tokens, pour 28 779 octets de texte décompressé ; la récupération de la page Vector database a consommé 11 581 tokens, pour 41 572 octets de texte. Les deux appels ont renvoyé x-ratelimit-limit: 20, 20;w=60, confirmant la limite anonyme de 20 appels par 60 secondes. Ce ne sont pas des chiffres recopiés d'une documentation — ce sont de vrais chiffres produits pour cet article.

5.3 Étape 2 : extraction des entités et des relations avec un LLM

C'est le seul maillon du pipeline que Jina ne fournit pas — vous devez apporter votre propre LLM. L'exemple ci-dessous utilise le format d'appel compatible SDK OpenAI — base_url peut pointer vers n'importe quel modèle ou relais compatible avec le protocole OpenAI, vous n'êtes lié à aucun fournisseur en particulier :

from openai import OpenAI

# Remplacez base_url par le modèle/relais que vous utilisez, et model par le nom de modèle correspondant
# Ce site a passé en revue plusieurs options avec un bon rapport qualité-prix (GLM-5.2, DeepSeek, etc.) — voir « Pour aller plus loin » en fin d'article
client = OpenAI(api_key="votre-clé", base_url="https://votre-relais-ou-point-d-acces-officiel/v1")

EXTRACTION_PROMPT = """Tu es un moteur d'extraction de graphe de connaissances. À partir d'un passage de texte, extrais les entités et les relations entre elles, et produis strictement le format JSON suivant, sans aucun texte superflu :

{
  "entities": [
    {"id": "identifiant_unique", "name": "nom de l'entité", "type": "PERSON|ORG|CONCEPT|TECHNOLOGY|EVENT", "description": "description en une phrase"}
  ],
  "relations": [
    {"source": "id_entité", "target": "id_entité", "relation": "description de la relation, sous forme de groupe verbal"}
  ]
}

Texte :
{chunk}
"""

def extract_entities_relations(chunk: str, model: str = "votre-nom-de-modele") -> dict:
    import json
    response = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": EXTRACTION_PROMPT.format(chunk=chunk)}],
        response_format={"type": "json_object"},
        temperature=0
    )
    return json.loads(response.choices[0].message.content)

Précision honnête : l'environnement de cette tâche ne disposait d'aucune clé API LLM utilisable, donc l'« exemple de sortie » ci-dessous n'est pas le résultat d'un véritable appel de modèle — c'est une illustration rédigée manuellement à partir du contenu réellement récupéré en section 5.2, destinée à montrer la forme de sortie attendue :

{
  "entities": [
    {"id": "e1", "name": "Retrieval-Augmented Generation", "type": "TECHNOLOGY", "description": "Une technique qui permet à un LLM de récupérer des documents externes avant de générer une réponse"},
    {"id": "e2", "name": "Large Language Model", "type": "TECHNOLOGY", "description": "Un grand modèle de langage"},
    {"id": "e3", "name": "Vector Database", "type": "TECHNOLOGY", "description": "Une base de données pour stocker et récupérer des embeddings vectoriels"},
    {"id": "e4", "name": "AI Hallucination", "type": "CONCEPT", "description": "Le phénomène par lequel un modèle génère un contenu inexact"}
  ],
  "relations": [
    {"source": "e1", "target": "e2", "relation": "renforce"},
    {"source": "e1", "target": "e3", "relation": "dépend de"},
    {"source": "e1", "target": "e4", "relation": "atténue"}
  ]
}

5.4 Étape 3 : vectoriser les entités avec Jina Embeddings pour la déduplication sémantique et le liage

Les entités extraites de plusieurs documents s'avèrent souvent être « la même chose formulée différemment » (par exemple « RAG » et « Retrieval-Augmented Generation »). Vectoriser le nom + la description de chaque entité avec Embeddings puis calculer la similarité cosinus permet de les fusionner en un même nœud. Le code ci-dessous est également rédigé à partir de la documentation officielle de l'API, sans appel réel cette fois (une vraie clé serait nécessaire) :

import requests

def embed_texts(texts: list, jina_api_key: str, task: str = "retrieval.passage") -> list:
    resp = requests.post(
        "https://api.jina.ai/v1/embeddings",
        headers={
            "Authorization": f"Bearer {jina_api_key}",
            "Content-Type": "application/json"
        },
        json={
            "model": "jina-embeddings-v5-text-small",
            "input": texts,
            "task": task,
            "normalized": True
        }
    )
    resp.raise_for_status()
    return [d["embedding"] for d in resp.json()["data"]]

entity_texts = [f"{e['name']}: {e['description']}" for e in entities]
entity_vectors = embed_texts(entity_texts, JINA_API_KEY)

import numpy as np

def cosine_sim(a, b):
    a, b = np.array(a), np.array(b)
    return float(a @ b / (np.linalg.norm(a) * np.linalg.norm(b)))

def merge_similar_entities(entities, vectors, threshold: float = 0.88):
    """Les entités dont la similarité dépasse le seuil sont considérées comme un même nœud et fusionnées
    (par exemple « RAG » et « Retrieval-Augmented Generation » provenant de documents différents)"""
    merged, used = [], set()
    for i, e in enumerate(entities):
        if i in used:
            continue
        group = [i]
        for j in range(i + 1, len(entities)):
            if j not in used and cosine_sim(vectors[i], vectors[j]) >= threshold:
                group.append(j)
                used.add(j)
        merged.append({**entities[i], "aliases": [entities[k]["name"] for k in group[1:]]})
    return merged

5.5 Étape 4 : assembler la structure du graphe

La forme la plus simple est une structure JSON de nœuds et d'arêtes — cette étape ne dépend d'aucune API externe, il s'agit de pure mise en forme de données, exécutable directement :

import json

def build_graph(all_entities, all_relations):
    nodes = [
        {"id": e["id"], "label": e["name"], "type": e["type"], "description": e["description"]}
        for e in all_entities
    ]
    edges = [
        {"source": r["source"], "target": r["target"], "label": r["relation"]}
        for r in all_relations
    ]
    return {"nodes": nodes, "edges": edges}

graph = build_graph(merged_entities, all_relations)
with open("domain_knowledge_graph.json", "w", encoding="utf-8") as f:
    json.dump(graph, f, ensure_ascii=False, indent=2)

print(f"Nœuds : {len(graph['nodes'])}, Arêtes : {len(graph['edges'])}")

Si le volume de données augmente et que vous avez besoin de capacités de requête sur le graphe, optez pour NetworkX (entièrement en mémoire, adapté aux volumes petits et moyens) :

import networkx as nx

G = nx.DiGraph()
for n in graph["nodes"]:
    G.add_node(n["id"], **n)
for e in graph["edges"]:
    G.add_edge(e["source"], e["target"], label=e["label"])

list(G.successors("e1"))  # récupère tous les voisins à un saut d'une entité

Pour un stockage persistant, des requêtes concurrentes multi-utilisateurs, ou un graphe de plus grande taille, passez à Neo4j :

from neo4j import GraphDatabase

driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "password"))

def load_into_neo4j(graph):
    with driver.session() as session:
        for n in graph["nodes"]:
            session.run(
                "MERGE (e:Entity {id: $id}) SET e.name = $name, e.type = $type",
                id=n["id"], name=n["label"], type=n["type"]
            )
        for e in graph["edges"]:
            session.run(
                "MATCH (a:Entity {id: $source}), (b:Entity {id: $target}) "
                "MERGE (a)-[r:RELATION {label: $label}]->(b)",
                source=e["source"], target=e["target"], label=e["label"]
            )

5.6 Étape 5 : interroger le sous-graphe et l'injecter dans le RAG en aval

L'usage le plus courant d'un graphe de connaissances une fois construit : pour répondre à une question utilisateur, on utilise d'abord la récupération vectorielle pour localiser les entités pertinentes, puis on étend de N sauts le long des arêtes vers leurs voisins, on assemble les relations du sous-graphe en un contexte structuré, et on l'ajoute aux résultats habituels de récupération vectorielle avant de les envoyer au LLM :

def query_graph(question_vector, graph, entity_vectors, top_k: int = 3):
    sims = [
        (node["id"], cosine_sim(question_vector, vec))
        for node, vec in zip(graph["nodes"], entity_vectors)
    ]
    top_nodes = sorted(sims, key=lambda x: -x[1])[:top_k]

    context_lines = []
    for node_id, _ in top_nodes:
        neighbors = [e for e in graph["edges"] if e["source"] == node_id or e["target"] == node_id]
        for e in neighbors:
            context_lines.append(f"{e['source']} --{e['label']}--> {e['target']}")
    return "\n".join(context_lines)

# Ajoutez le texte de relations structuré retourné à votre prompt final, en complément des résultats habituels de récupération vectorielle

5.7 Récapitulatif : qui est responsable de quelle couche dans ce pipeline

6. Pièges courants et accès depuis la Chine continentale

• Les trois produits partagent le même pool de tokens : une tâche Embeddings en masse qui épuise le crédit gratuit en avance affecte aussi Reader/Reranker — planifiez votre capacité sur le total, pas produit par produit
• Le crédit gratuit est réservé à un usage non commercial : pour un déploiement en production/un projet commercial, les 10M tokens gratuits annoncés officiellement peuvent ne pas s'appliquer d'un point de vue conformité — référez-vous aux conditions actuelles du tableau de bord
• Le X-Timeout de Reader plafonne à 180 secondes : la récupération de pages fortement rendues en JS ou protégées contre le scraping peut facilement expirer — associez-le à X-Engine: browser pour forcer le moteur navigateur
• Pour une vectorisation à grande échelle, utilisez l'API Batch Embeddings plutôt que le point de terminaison synchrone : POST /v1/batch/embeddings soumet une tâche, puis vous interrogez son statut et téléchargez les résultats au format JSONL — mieux adapté que /v1/embeddings synchrone pour les scénarios du type « vectoriser toute votre base de connaissances en une seule fois »
• L'accès depuis la Chine continentale nécessite un proxy : le dépôt GitHub officiel jina-ai/reader de Jina contient un ticket intitulé « Jina Reader et Search sont bloqués », ce qui montre qu'au moins certains utilisateurs signalent que r.jina.ai/s.jina.ai sont inaccessibles depuis les réseaux de Chine continentale — mais aucune déclaration officielle ni confirmation durable de ce statut n'a été trouvée. Les équipes en Chine continentale peuvent passer par un proxy local, ou y accéder indirectement via un relais d'API IA comme Chutes, qui a déjà intégré le point de terminaison d'embedding de Jina, dans un format compatible SDK OpenAI

7. FAQ

Q : L'API Jina permet-elle vraiment de « générer un graphe de connaissances en un clic » ?

R : Non. La gamme de produits de Jina ne propose pas cette fonctionnalité — c'est plutôt le positionnement du produit Knowledge Graph de Diffbot. La section 5 de cet article présente un pipeline que vous devez assembler vous-même : Jina prend en charge l'exploration et la vectorisation, l'extraction d'entités/relations nécessite votre propre LLM, et le stockage et le requêtage du graphe demandent aussi de choisir un outil (JSON/NetworkX/Neo4j).

Q : Depuis le rachat de Jina par Elastic, l'API risque-t-elle de voir son prix augmenter brutalement ou d'être arrêtée ?

R : Au moment de la rédaction de cet article (juillet 2026), la position officielle est de continuer à fonctionner de façon indépendante et de maintenir le rythme de publication en open source ; des sites d'avis tiers confirment également que les API Reader/Embeddings/Reranker sont toujours activement maintenues, sans changement majeur de la structure tarifaire. Cela dit, toute gamme de produits rachetée comporte un risque de réorientation à long terme — surveillez les annonces officielles et ne considérez pas la tarification à un instant donné comme un engagement permanent.

Q : Quelles parties de ce tutoriel puis-je exécuter sans clé API ?

R : L'étape 1 de la section 5 (récupération avec Jina Reader) peut s'exécuter entièrement en mode anonyme, avec une limite de 20 appels/60 secondes — les chiffres du test en direct de cet article proviennent d'appels anonymes. L'étape 3 (vectorisation avec Jina Embeddings) et l'étape 2 (extraction par LLM) nécessitent chacune leur propre clé API.

Q : Le crédit gratuit de 10M tokens suffit-il pour construire un petit graphe de connaissances métier ?

R : D'après les chiffres du test en direct de cet article, deux pages Wikipedia de longueur moyenne (environ 30 à 40 Ko de texte chacune) ont ensemble consommé environ 19 000 tokens — le crédit de 10M pourrait théoriquement couvrir plusieurs centaines de pages de cette taille pour la seule récupération via Reader. Mais ce crédit est partagé entre Embeddings/Reranker/Reader, donc si vous vectorisez aussi un grand nombre d'entités avec Embeddings, le nombre de pages réellement couvrables diminue nettement. Testez d'abord à petite échelle avec le crédit gratuit, puis évaluez si une clé payante est nécessaire.

Q : Faut-il obligatoirement utiliser Jina Embeddings pour vectoriser les entités ? Peut-on le remplacer par un autre modèle d'embedding ?

R : Tout à fait possible. La logique de vectorisation de l'étape 3 de la section 5 (fusion d'entités par similarité) n'est pas fortement liée à un modèle d'embedding en particulier — toute API Embeddings produisant des vecteurs denses peut être substituée. La principale raison de choisir Jina est qu'elle partage le même système de compte que Reader — si vous utilisez déjà Jina Reader pour la récupération, utiliser aussi Jina Embeddings pour la vectorisation évite de gérer un compte supplémentaire.

8. Conclusion