Ollama Embedding en pratique : recherche vectorielle locale et RAG

Plus de 200 PDF sur le disque, et vous cherchez le détail d’un plan technique vu il y a six mois. Recherche par mots-clés ? Inutile — vous vous souvenez du sens, pas des formulations exactes. Près d’une heure perdue. À ce moment-là, on rêve d’un outil qui « comprend le sens ».

Pire encore : ces documents touchent à l’architecture interne. Les envoyer dans le cloud pour une recherche vectorielle ? Hors de question. La ligne rouge de la confidentialité est nette.

Les embeddings Ollama règlent ce cas de figure : tout tourne en local, les données ne sortent pas, et la recherche devient sémantique. Après quelques jours d’essais entre mxbai, nomic et Qwen3, et un tour des bases vectorielles, les pièges apparaissent — mauvais modèle, mauvaise base, et la suite devient pénible.

Cet article rassemble ces retours d’expérience. À la fin, vous pourrez monter un RAG local de A à Z, du traitement documentaire à la recherche sémantique, avec le code complet.

La gamme de modèles Embedding Ollama

Ollama propose plusieurs modèles d’embedding ; au début, difficile de trancher. La doc officielle affirme que mxbai dépasse text-embedding-3-large d’OpenAI — ça sonne bien, mais en pratique ? Après les tests, voici une réponse directe.

Un tableau comparatif pour cadrer le choix :

mxbai-embed-large est celui que j’utilise le plus. Pourquoi ? Simple, stable. Ses vecteurs 1024 dimensions suffisent dans la majorité des cas ; sur le benchmark MTEB (Massive Text Embedding Benchmark), il se place très haut, un peu au-dessus de text-embedding-3-large d’OpenAI. Recherche documentaire, recherche dans du code : c’est le choix sûr.

nomic-embed-text mise sur 8192 tokens de contexte. Pour un article entier ou un long fil de conversation, c’est utile. Plus léger (274M), donc souvent plus rapide que mxbai. Dimension 768 : en théorie un peu moins expressif — en test, peu de différence sur textes courts ; sur longs textes, nomic gagne.

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

Qwen3 Embedding est sorti par Alibaba en avril 2026. Le chinois est vraiment bon : sur des articles techniques, « mécanismes de tolérance aux pannes des systèmes distribués » et « conception tolante aux pannes » se rapprochent ; mxbai accroche moins. Contenu surtout en chinois : à essayer.

En résumé : débuter avec mxbai sans hésiter ; longs textes → nomic ; contenu chinois → Qwen3 en priorité. Tester les trois prend une demi-heure — les résultats comptent plus que le tableau.

Choisir une base de données vectorielle

Modèle choisi, où stocker ? Le choix de la base vectorielle piège autant que le modèle. Trop petit : la montée en charge fait mal ; trop gros : gaspillage. Trois options courantes :

ChromaDB est mon conseil pour débuter. Une commande : pip install chromadb. API claire : quelques lignes pour indexer et interroger. Index HNSW (Hierarchical Navigable Small World), largement suffisant à petite échelle. Limite : déploiement mono-machine ; au-delà de ~100 000 entrées, les perfs baissent.

FAISS, chez Meta, est un classique. C++ pur, vraiment rapide : sur 500 000 entrées, latence stable au milliseconde. C’est surtout une librairie de recherche, pas une base complète — stockage et fichiers d’index à gérer vous-même. Pour les bidouilleurs ou les besoins extrêmes de perf.

Milvus vise la production : distribué, persistance, plusieurs types d’index, offre cloud (Zilliz Cloud). Configuration et coût plus lourds. Millions d’entrées, haute dispo, équipe : là, ça vaut l’investissement.

Ma règle : perso / prototypage → ChromaDB, vite opérationnel ; recherche perf → FAISS ; production → Milvus ou cloud. Ne comptez pas migrer ChromaDB → Milvus sans douleur : formats et API diffèrent.

RAG complet : mise en œuvre

Moins de théorie, plus de code. Voici un RAG local de bout en bout : PDF → recherche sémantique, avec Ollama + ChromaDB.

Préparation de l’environnement

Dépendances :

pip install ollama chromadb langchain langchain-community pypdf

Ollama doit tourner, modèles téléchargés :

ollama pull mxbai-embed-large
ollama pull qwen2.5:7b  # pour générer les réponses

Code

import ollama
from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
import chromadb

# 1. Charger le PDF
loader = PyPDFLoader("./your_document.pdf")
docs = loader.load()

# 2. Découpage — chunk trop grand : recherche imprécise ; trop petit : perte d'info
splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,      # 800 caractères par bloc
    chunk_overlap=100,   # 100 caractères de chevauchement
)
chunks = splitter.split_documents(docs)

# 3. Embeddings Ollama + stockage ChromaDB
client = chromadb.Client()
collection = client.create_collection("my_docs")

for i, chunk in enumerate(chunks):
    response = ollama.embed(
        model="mxbai-embed-large",
        input=chunk.page_content,
    )
    embedding = response["embeddings"][0]

    collection.add(
        ids=[str(i)],
        embeddings=[embedding],
        documents=[chunk.page_content],
        metadatas=[{"source": chunk.metadata.get("source", "unknown")}],
    )

print(f"Indexé : {len(chunks)} fragments")

# 4. Recherche sémantique
query = "Quels sont les mécanismes de tolérance aux pannes des systèmes distribués ?"
query_embedding = ollama.embed(
    model="mxbai-embed-large",
    input=query,
)["embeddings"][0]

results = collection.query(
    query_embeddings=[query_embedding],
    n_results=3,
)

# 5. Réponse à partir du contexte récupéré
context = "\n\n".join(results["documents"][0])
response = ollama.chat(
    model="qwen2.5:7b",
    messages=[
        {
            "role": "system",
            "content": "Répondez à partir du contenu documentaire ci-dessous. Si l'information manque, dites-le clairement.",
        },
        {"role": "user", "content": f"Contenu : {context}\n\nQuestion : {query}"},
    ],
)

print(f"Réponse : {response['message']['content']}")

Lancez le script. Le flux reste linéaire : découpage → vecteurs → base → requête → réponse.

Pièges fréquents :

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

chunk_size : ne pas le fixer au hasard. À 200 caractères, les extraits sont des miettes, impossibles à assembler. 500-1000 caractères est une zone stable.

Traitement par lots : document volumineux, appels un par un = lent. Regroupez :

# Embeddings par lot — gain net
batch_texts = [chunk.page_content for chunk in chunks[:50]]
batch_embeddings = ollama.embed(
    model="mxbai-embed-large",
    input=batch_texts,
)["embeddings"]

Seuil de similarité : ChromaDB renvoie n_results entrées, pertinentes ou non. Parfois il faut filtrer :

# Filtrer par distance
results = collection.query(
    query_embeddings=[query_embedding],
    n_results=10,
)
filtered = [
    doc for doc, dist in zip(results["documents"][0], results["distances"][0])
    if dist < 0.3
]

À ce stade, vous avez un RAG local. Remplacez le PDF et la requête — le reste tient.

Réglages et bonnes pratiques

Système en place, place à l’optimisation. Quelques paramètres changent tout.

chunk_size :

500-1000 caractères en pratique. Trop petit : sens tronqué, mauvais rapprochement avec la question. Trop grand : bruit, plusieurs sujets dans le même bloc.

Selon le type : docs techniques structurés → découpage par paragraphe ; conversations fragmentées → blocs ~500 caractères. Testez sur vos données — pas de valeur universelle.

Lots pour accélérer :

Un appel par fragment = latence réseau à chaque fois. Lots de 50-100 : plusieurs fois plus rapide. Ne dépassez pas la limite d’entrée du modèle d’embedding.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Seuil de similarité :

Entre 0,7 et 0,85 selon l’exigence. Haut (0,85) : peu de faux positifs, moins de rappel ; bas (0,7) : plus de rappel, plus de bruit. Corpus propre et questions nettes → seuil haut ; questions floues → seuil plus bas.

Conseil : commencez avec 50-100 documents, validez la recherche, puis scalez. Tout indexer avant d’ajuster coûte cher en temps.

Synthèse

L’essentiel :

Modèle selon le cas — généraliste mxbai, long texte nomic, chinois Qwen3. Base : ChromaDB pour démarrer, FAISS si la perf prime, Milvus en production. Le code ci-dessus suffit pour un premier run.

Points forts : local, données maîtrisées ; modèles Ollama gratuits ; ChromaDB simple. Limites : plafond mono-machine, au-delà du million il faut une autre architecture.

Lancez le script avec une cinquantaine de documents, observez qualité de recherche et de réponse, puis étendez. Paramètres au vert, puis volume.

Pour aller plus loin avec LangChain et Ollama (chaînes de dialogue, appels d’outils), voir l’article « Intégration LangChain + Ollama en pratique » — celui-ci couvre la recherche vectorielle ; les deux ensemble dessinent une feuille de route LLM locale complète.