Changer les modèles d’incorporation RAG sans réindexation : comment fonctionne rebasis

Mettre à jour le modèle d’incorporation utilisé dans un système de génération améliorée par la recherche semble être une tâche ordinaire, jusqu’à ce que l’index vectoriel existant devienne un obstacle. Un outil open source en Python nommé rebasis vise précisément ce problème. Il entraîne un petit adaptateur capable de traduire les vecteurs de requête provenant d’un nouveau modèle d’incorporation dans l’espace compris par l’ancien index. Ainsi, une réindexation complète peut être reportée, ou effectuée progressivement et sous surveillance.

Cet outil teste plusieurs types de mappage (Procrustes orthogonale centrée, affine, réseaux à rang faible et à petits résidus) au sein d’un même protocole d’évaluation commun. Il ne se limite pas à évaluer la qualité de l’alignement ; il est également capable d’estimer dans quelle mesure le nouveau modèle est réellement supérieur sur le corpus concerné, ainsi que de déterminer si le système adapté est préférable à la persistance du système existant. Des intervalles de confiance issus d’une méthode bootstrap appariée, plusieurs métriques de récupération, des empreintes de la configuration d’encodage, des enregistrements d’audit reproductibles et une routine de migration résistante aux pannes permettent de faire de la mise à niveau une décision mesurable plutôt qu’un pari aveugle.

Les sujets abordés sont le RAG, le dérive des embeddings, les bases de données vectorielles, la compatibilité inverse, la migration de modèles, l’évaluation de la récupération et la recherche du voisin le plus proche approximative.

Pourquoi le modèle d’embeddings reste bloqué

La création d’un système RAG exige plus qu’un modèle de langage et une base de données vectorielle : il faut également tenir compte du système de coordonnées du modèle d’incorporation en vigueur au moment de l’indexation. Les documents, qu’ils soient des milliers ou des millions, sont divisés en fragments, encodés puis enregistrés dans un index. Tôt ou tard, un modèle d’incorporation plus rapide, meilleur ou plus adapté apparaît, et c’est là que commencent les problèmes : un vecteur de requête généré par le nouveau modèle n’a aucun sens pour un index créé avec l’ancien modèle.

Le conseil habituel est de « simplement réindexer tout le contenu ». Cela est techniquement correct, mais souvent coûteux. Une grande base de connaissances personnelle, un ensemble de documents internes, une base de code ou la mémoire à long terme d’un agent doivent être à nouveau divisés en fragments et intégrés, ce qui nécessite du temps, des ressources de calcul, un budget API et comporte des risques opérationnels. De nombreux systèmes restent donc utilisés avec un modèle obsolète bien après l’apparition d’un modèle plus performant.

rebasis a été conçu pour briser cet effet de verrouillage. Son objectif affiché est de permettre à un système RAG local de changer son modèle d’incorporation sans supprimer l’index vectoriel qu’il possède déjà.

Transformer la requête, pas l’index

Deux modèles d’incorporation ne produisent pas des espaces comparables. En encodant une même phrase avec chacun d’eux, la dimensionnalité peut différer, mais les différences sont plus profondes : la signification de chaque axe, le centre de l’espace, le facteur de mise à l’échelle et l’organisation des voisins sémantiques peuvent tous changer. Un vecteur de requête provenant du nouveau modèle, envoyé directement à l’index ancien, renvoie principalement des résultats sans signification. Certaines bases de données vectorielles refusent carrément la requête car la dimensionnalité ne correspond pas à celle de la collection.

La réponse de l’outil est un petit adaptateur appris. Il prend un vecteur de requête provenant du nouveau modèle et le projette dans l’espace utilisé par l’index existant. Pour apprendre cette projection, les mêmes textes sont encodés à la fois par l’ancien et le nouveau modèle, ce qui génère des vecteurs appariés. Si la relation entre les deux espaces est suffisamment apprenable, un nouveau vecteur de requête peut être transformé en quelque chose de significatif pour l’index ancien.

Les avantages pratiques sont importants : le nouveau modèle peut traiter immédiatement les requêtes, tandis que les vecteurs de documents dans l’index restent inchangés. L’intégration dans une application est délibérément simplifiée. Tout d’abord, l’importation :

from rebasis import Bridge

Puis charger l’adaptateur et l’insérer dans le chemin de la requête :

bridge = Bridge.load("adapters/minilm-to-bge.rbs")query_vector = new_model.encode(["how do I deploy to production?"])
query_vector = bridge.to_index_space(query_vector)
results = collection.query(query_embeddings=query_vector, n_results=10)

Bridge est la fine couche située sur le chemin critique de l’application RAG. Lors du chargement de l’adaptateur, celui-ci vérifie les identités des modèles, les profils d’encodage, les dimensions ainsi que l’intégrité du fichier d’adaptateur. Par la suite, chaque requête ne nécessite que l’opération matricielle. Le journalisation, la construction du dictionnaire et les validations répétées sont délibérément exclus de ce chemin, car un petit avantage ne doit pas se transformer en coût à chaque demande. Aucune GPU n’est non plus nécessaire, car à cette échelle, le transfert de données entre les appareils a tendance à coûter plus cher que la multiplication elle-même.

Les mathématiques derrière l’adaptateur par défaut

Appelons le vieux modèle d’incorporation f_old et le nouveau f_new, puis prenons n de documents codés par les deux. Cela donne deux matrices de données, une dans chaque espace. L’objectif est d’apprendre une fonction qui mappe l’espace nouveau vers l’ancien ; sous sa forme générale, l’objectif d’entraînement minimise la distance de norme de Frobenius entre les vecteurs nouveaux mappés et les anciens.

La méthode par défaut est la Procrustes orthogonale centrée. On soustrait d’abord la moyenne de chaque colonne des deux matrices. Pour des espaces de dimension égale, la contrainte est que la transformation doit être une matrice orthogonale de type rotation. En effectuant la décomposition en valeurs singulières du produit des matrices centrées, on obtient une forme fermée pour la meilleure matrice orthogonale, construite à partir du produit des vecteurs singuliers gauche et droit. Une requête est alors transformée en la centrant par rapport à la moyenne de l’espace nouveau, en la rotant, puis en ajoutant à nouveau la moyenne de l’espace ancien. Il s’agit du problème classique de Procrustes, étudié depuis les années 1960.

Cette solution ne nécessite aucune optimisation itérative, il n’y a donc ni taux d’apprentissage ni choix d’epochs. Les mêmes données d’entrée donnent toujours la même transformation.

Les vecteurs sont normalisés par leur longueur avant l’ajustement, puis à nouveau après application de l’adaptateur, de sorte que la similarité cosinus se réduit à un produit scalaire. Le centrage est important car les espaces d’incorporation sont anisotropes et possèdent une composante moyenne commune. En la supprimant, on évite à la transformation de devoir représenter une translation que une simple rotation ne peut pas exprimer. Si une paire de modèles nécessite plus de liberté, des alternatives affines, à rang faible ou résiduelles prennent le relais.

Une propriété importante du point de vue opérationnel en découle : le coût d’entraînement dépend du nombre de paires correspondantes, et non de la taille du corpus. Un adaptateur peut être ajusté à partir de quelques milliers de paires représentatives, même lorsque l’index contient des centaines de milliers d’enregistrements. Une transformation de matrice complète coûte de l’ordre du produit des deux dimensions par requête et nécessite une mémoire de paramètres de même ordre. Une factorisation de rang-r réduit le coût de la requête à environ r fois la somme des dimensions. À titre indicatif, une matrice float32 de 768 par 768 occupe environ 2,36 MB, ce qui est négligeable par rapport à l’espace que l’on économise en évitant de la reconstruire.

Pourquoi une seule méthode de transformation ne suffit pas

La relation entre deux espaces d’incorporation est souvent proche d’une rotation, mais ce n’est pas le cas pour tous les paires de modèles. rebasis ne suppose donc pas qu’un seul algorithme puisse fonctionner partout. Il part de la méthode Orthogonal Procrustes, qui permet d’aligner au mieux deux ensembles de points correspondants de manière formelle. Cependant, les espaces réels peuvent présenter des déplacements moyens, des différences de échelle par dimension ainsi que des composantes non linéaires.

Avec l’option --method auto, l’outil teste plusieurs algorithmes sur la même partition des données et avec le même prétraitement, avant de les comparer :

• Procrustes, dans ses variantes centrées et classiques.
• Une carte linéaire régularisée par des crêtes.
• Une carte affine à faible rang.
• Procrustes avec une échelle par dimension.
• Lorsque PyTorch est disponible, un petit réseau MLP résiduel.

CSLS n’est pas imposé dans le mappage ; il concourt également en tant que candidat. La raison en est pratique : dans les espaces à haute dimension, il peut atténuer le problème de « hubness » pour les adaptateurs faibles, mais il peut nuire à un alignement déjà solide. L’objectif n’est pas une longue liste de noms d’algorithmes, mais un gagnant sélectionné par des mesures effectuées sur des données réservées. Lorsque plusieurs candidats se trouvent dans la même région d’incertitude, l’outil préfère celui qui possède moins de paramètres et un coût plus faible.

Les données d’entraînement et d’évaluation restent strictement disjointes tout au long du processus, et ce n’est pas simplement une convention. L’outil vérifie la présence de chevauchements en temps réel. Évaluer un adaptateur à l’aide des exemples qu’il a appris fournirait un chiffre impressionnant qui ne prouve rien.

Les modèles d’incorporation asymétrique font également l’objet d’un traitement explicite. Dans la famille E5, par exemple, les préfixes query: et passage: signifient que le même texte est encodé différemment en fonction de son rôle, et d’autres modèles utilisent des instructions de type query ou document à des fins similaires. En adaptant l’adaptateur aux paires encodées en document et en l’appliquant aux vecteurs encodés en query, on crée un cas typique de désalignement entre entraînement et utilisation en production. C’est pourquoi un profil d’encodage dans rebasis prend en compte bien plus que le nom du modèle : dimensionnalité, normalisation, agrégation, les préfixes query et document, ainsi que toute dimension Matryoshka. Un adaptateur construit selon un profil incorrect est rejeté au moment du chargement plutôt que de produire silencieusement de mauvais résultats.

Comment cela s’inscrit dans les recherches antérieures

Rendre les embeddings compatibles entre les différentes versions est un problème ancien. L’entraînement compatible vers l’arrière restreint un nouveau modèle pendant l’entraînement afin que ses représentations restent comparables à celles des versions antérieures. L’entraînement compatible vers l’avant agit dans le sens inverse, en préparant des informations complémentaires pendant l’entraînement du modèle existant, ce qui facilite les mises à jour ultérieures. Ces deux approches conviennent aux grands systèmes de récupération qui contrôlent l’ensemble du cycle de vie du modèle depuis la phase de conception.

rebasis s’adresse à une autre situation : l’index existe déjà, les anciens et les nouveaux modèles ont été entraînés séparément, et personne ne peut modifier aucun de ces processus d’entraînement. Cela en fait une couche de compatibilité post-hoc. Elle s’appuie sur la méthode Orthogonal Procrustes, les transformations à rang faible ainsi que les travaux plus récents de la série Drift-Adapter, et sa propre contribution réside dans l’ingénierie : elle regroupe ces idées en un outil local qui intègre également des fonctionnalités de mesure, de sélection d’adaptateurs, de théorie des décisions, d’abstractions relatives aux bases de données, de migration sécurisée, ainsi qu’un flux de travail pour des audits reproductibles.

CSLS provient de la littérature sur l’alignement des embeddings interlangagiers. Il tient compte de la densité du voisinage local de la requête et de la cible, et pénalise les vecteurs « hubs » qui deviennent les voisins les plus proches de trop nombreuses requêtes. En termes généraux, il attribue à une paire un score égal à deux fois la similarité cosinus moins un terme de densité pour chaque côté. Selon les expériences menées sur un corpus réel par le projet lui-même, cet outil a aidé les mappages faibles et a parfois nui à ceux qui étaient forts, c’est pourquoi on le mesure plutôt que de l’appliquer aveuglément.

Un outil qui vous dit parfois de ne pas l’utiliser

Dès les débuts du projet, la question « peut-on construire un pont entre ces deux espaces ? » s’est avérée être la mauvaise question à se poser seule. Trois autres questions sont plus importantes :

1. Le nouveau modèle d’embedding est-il vraiment meilleur avec ces données en particulier ?
2. Quelle partie de la qualité d’un réindex complet l’adaptateur conserve-t-il ?
3. Le passage à un modèle intermédiaire est-il préférable à la simple utilisation du modèle actuel ?

C’est pourquoi probe, et non fit, est présenté comme la commande clé. Il regroupe l’échantillonnage, l’incorporation, la construction des données de référence, l’ajustement des candidats, le calcul des métriques et la décision finale en un seul flux de mesure, sans jamais écrire dans l’index existant.

Une mesure centrale est le ARR, Adapted Recall Retention : la qualité de la recherche adaptée exprimée en fraction de ce que permettrait un réindex complet avec le nouveau modèle. Un ARR élevé n’est pas suffisant en soi. Si le nouveau modèle ne représente qu’une légère amélioration par rapport à l’ancien, l’adaptateur a peu de valeur opérationnelle. Si le nouveau modèle représente un grand progrès mais que l’adaptateur ne parvient pas à transmettre cet avantage, un réindex complet pourrait être la solution appropriée.

La décision dépend donc d’une mesure d’équilibre financier :

bridge_advantage = ARR × upgrade_gain

En l’écrivant, la logique devient plus claire. Soit Ra la valeur de Recall@k pour le système adapté, Rn la même valeur pour un système entièrement réindexé avec le nouveau modèle, et Ro pour l’ancien système actuel. ARR représente alors l’avantage du système adapté par rapport à l’ancien, divisé par l’avantage du réindexage complet par rapport à l’ancien ; l’avantage de la mise à niveau correspond au rapport Rn/Ro. En les multipliant, les termes Rn s’annulent, ce qui laisse Ra divisé par Ro : c’est donc une comparaison directe entre le système adapté et l’alternative réelle du utilisateur, qui consiste à ne rien faire.

Chaque facteur répond à une question simple. ARR indique dans quelle mesure l’indexation idéale a été conservée. Le gain d’amélioration montre de combien le nouveau modèle est supérieur. Leur produit permet de déterminer si le passage au modèle actuel permet réellement d’avancer. Une valeur supérieure à 1 signifie que le passage au nouveau modèle est avantageux ; une valeur inférieure à 1 l’indique pas. Lorsque la mesure est trop proche du seuil, l’outil ne peut pas affirmer avec certitude le résultat ; il le qualifie alors de borderline et recommande d’utiliser un échantillon plus grand.

Avec un vrai journal des requêtes ainsi que des identifiants de documents pertinents évalués par des humains, probe peut mesurer le véritable gain du nouveau modèle sur cet ensemble de documents. En l’absence de tel journal, des documents non utilisés peuvent servir de requêtes, et des requêtes synthétiques basées sur des mots-clés fournissent une évaluation approximative. Chaque résultat indique son niveau de fiabilité, de sorte que la sortie comprend à la fois une note et les critères sur lesquels elle a été obtenue.

Un ensemble de mesures, pas un seul chiffre

Recall@k constitue l’axe décisionnel principal, mais la qualité de la récupération ne se résume pas à une seule valeur. Une seule exécution de probe génère plusieurs indicateurs complémentaires :

• MRR@k indique à quelle hauteur apparaît le premier résultat pertinent.
• nDCG@k prend en compte à la fois le degré de pertinence et la position dans le classement.
• Top-k overlap montre dans quelle mesure l’ensemble de résultats adapté conserve les éléments proches de ceux du système de référence.
• Corrélation de Spearman mesure dans quelle mesure l’ordre interne des résultats partagés se dégrade.
• Distance de Kolmogorov-Smirnov évalue dans quelle mesure la calibration déplace la distribution des scores de similarité.

Tail ARR détermine la qualité des clusters les plus dispersés par rapport à la moyenne globale, ce qui permet de mettre en évidence les déviations qui affectent plus sévèrement certaines régions.

Ces distinctions sont importantes. Deux systèmes peuvent restituer les mêmes documents dans des ordres différents, ce que le taux de rappel ne peut pas détecter tandis que le nDCG le peut. De même, un classement peut sembler correct alors que la forme de la distribution des scores a suffisamment changé pour contrecarrer un filtre à seuil fixe. Lorsque les résultats obtenus en se basant sur le taux de rappel et sur le nDCG diffèrent, rebasis signale cette discordance sans remplacer discrètement l’une des métriques par l’autre.

L’incertitude fait partie du résultat

La valeur ARR mesurée sur un échantillon constitue une estimation ponctuelle ; par conséquent, l’outil définit un intervalle de confiance de 95 % à partir de 2 000 rééchantillonnages bootstrap, selon la méthode d’Efron. Au niveau de preuve T1, l’ARR est le rapport de deux moyennes. Rééchantillonner indépendamment le numérateur et le dénominateur détruirait leur dépendance statistique, c’est pourquoi une méthode de rééchantillonnage par paires réutilise les mêmes indices de requête pour les deux. Les limites de cet intervalle correspondent aux 2,5e et 97,5e percentiles de la distribution obtenue.

La mise en paire permet de préserver une corrélation réelle : une requête difficile pour l’adaptateur l’est généralement aussi pour l’oracle. Lorsque l’intervalle englobe un seuil de décision, le résultat n’est pas considéré comme définitif. Plutôt que de confondre les décimales avec une certitude scientifique, la précision de la mesure fait partie intégrante de la décision. La graine de génération, la stratégie d’échantillonnage et la version de la métrique sont enregistrées dans le rapport d’audit, afin que l’intervalle puisse être reproduit.

D’après le projet, la mesure a déterminé directement sa direction. Selon son rapport publié, il a comparé le modèle ancien, un simple remplacement de modèle, une adaptation de la récupération des données et un réindexage complet sur des ensembles de requêtes identiques, portant sur 11 corpus, 398 010 documents et 10 346 requêtes réelles d’utilisateurs. Des jugements de pertinence effectués par des humains ont été utilisés, et les principaux résultats ont été évalués de manière indépendante à l’aide de ranx plutôt que de se fier uniquement au code métrique propre à l’outil. Selon ces chiffres, un simple remplacement conservait environ 12,5 % de la qualité d’un réindexage complet, tandis que l’approche intermédiaire en conservait environ 71 %, soit une capacité de récupération environ 6,4 fois supérieure à celle du remplacement naïf.

Le résultat le plus révélateur est que la méthode de pontage n’était pas toujours la bonne. Elle s’est réellement avérée utile uniquement dans 12 des 62 paires de modèles et de corpus testées. La règle de décision a indiqué la bonne direction dans 61 des 62 cas, y compris 32 des 33 cas concernant des corpus qu’elle n’avait jamais vus avant que la règle ne soit fixée. Un outil gagne la confiance en indiquant « réindexer ici » ou « vous n’avez pas besoin de cette mise à niveau » lorsque c’est la réponse honnête, ainsi qu’en disant « utilisez-moi ».

Le flux de travail en ligne de commande du début à la fin

rebasis n’est pas seulement une fonction de bibliothèque. Sa ligne de commande transforme un changement de modèle en un processus gérable. Elle commence par vérifier l’environnement ainsi que les stockages et les embedders disponibles :

# Inspect the environment and available store/embedder support
rebasis doctor

Viennent ensuite les trois étapes du processus réel : mesurer d’abord et choisir une voie, installer l’adaptateur, puis migrer l’index en lots en arrière-plan une fois prêt.

# Measure first and choose the right path
rebasis probe --store chroma:///path/to/db#notes \
  --old sentence-transformers/all-MiniLM-L6-v2 \
  --new BAAI/bge-base-en-v1.5 \
  --queries queries.jsonl --sample 10000 --report report.html# Fit the appropriate adapter
rebasis fit --store chroma:///path/to/db#notes \
  --old sentence-transformers/all-MiniLM-L6-v2 \
  --new BAAI/bge-base-en-v1.5 \
  --method auto --pairs 4000 \
  --out adapters/minilm-to-bge.rbs# When ready, migrate the index in background batches
rebasis migrate --adapter adapters/minilm-to-bge.rbs \
  --store chroma:///path/to/db#notes --priority access --limit 5000

L’adaptateur .rbs résultant contient plus que des poids. Son manifeste enregistre les identités des modèles anciens et nouveaux, les dimensions vectorielles, la direction ainsi que les empreintes des profils d’encodage. Les tenseurs sont stockés au format safetensors, et les résultats de calibration et d’évaluation des scores y sont également conservés. Un adaptateur constitue donc un enregistrement portable et vérifiable indiquant quels modèles et quelles conditions l’ont généré, et les hachages des tenseurs peuvent être recomputés pour vérifier leur intégrité.

La calibration des scores mérite une attention particulière. Une transformation peut conserver le classement tout en modifiant les scores de similarité absolus. Une application utilisant un seuil fixe, comme similarity > 0.7, pourrait alors supprimer silencieusement certains résultats. Pour y remédier, l’outil applique un calibrateur isotonique monotone qui ramène les scores vers l’échelle traditionnelle sans en changer l’ordre, tout en avertissant les systèmes dépendant de seuils fixes.

Comportement en termes de calcul et de mémoire

Un outil qui, en théorie, n’a pas besoin de tout le corpus en mémoire peut tout de même le charger par accident. Dans rebasis, les itérateurs de corpus diffusent les enregistrements par flux, de sorte que la consommation maximale de mémoire pendant la migration est de l’ordre de la taille du lot multipliée par la dimension du vecteur. Le temps d’exécution augmente avec le nombre d’enregistrements, mais le corpus de l’utilisateur n’est jamais matérialisé en RAM. Lorsque la mémoire approche du plafond défini par --max-memory, la taille du lot peut diminuer et le job marqué par un point de contrôle peut être mis en pause au lieu d’être arrêté.

La matrice de similarité utilisée pour la recherche de valeurs de référence, selon la taille des échantillons, n’est pas non plus construite en totalité. Les requêtes sont traitées par blocs. Chaque bloc effectue une multiplication matricielle, extrait les k meilleurs résultats et jette la matrice de scores intermédiaire. Un tri complet coûterait S log S par ligne. L’utilisation de argpartition maintient le coût de sélection attendu par ligne en fonction linéaire de S. Pour les vecteurs float32 normalisés, la recherche par cosinus se réduit à une seule multiplication matricielle, ce qui permet de contrôler à la fois la mémoire requise et les différences entre plateformes liées au type de données.

Dans ce projet, le processeur central constitue la référence principale plutôt qu’un recours de seconde catégorie. Une carte graphique peut accélérer considérablement la génération des embeddings, mais le transfert entre l’appareil hôte et la carte graphique peut annuler cet avantage pour une simple opération d’adaptation sur une seule requête. Les tests d’équivalence entre appareils comparent les tolérances des scores, ainsi que les ensembles de voisins récupérés, et surtout déterminent si des données identiques conduisent à la même décision finale. Une petite différence numérique qui fait dépasser un ARR une certaine limite, comme 0,95, n’est pas considérée comme une variation matérielle acceptable ; elle est plutôt vue comme un défaut dans le comportement du produit.

Migration résistante aux interruptions

Grâce à ce mécanisme de pontage, l’index n’a pas besoin de changer immédiatement ; le système peut continuer à fonctionner via l’adaptateur aussi longtemps que souhaité. Si l’index doit être déplacé de manière permanente, la commande migrate transfère les enregistrements vers l’espace nouveau par lots, et dans ce cas la sécurité des données prend le pas sur la vitesse brute.

Chaque lot commence par la lecture des vecteurs actuels, qui sont copiés dans un stock d’ombre avant toute écrasement. Les vecteurs transformés sont ensuite écrits, et un échantillon des enregistrements écrits est lu à nouveau pour les vérifier. À la fin, l’outil ne se fie pas uniquement à son identifiant de client actuel. Il rouvre le stock via une nouvelle connexion et effectue à nouveau des prélèvements pour garantir la fiabilité, de sorte que le cache côté client ne puisse pas cacher ce qui a réellement atteint le stock persistant.

Le moteur de migration repose sur quatre invariants :

1. Un vecteur original de type float32 doit exister dans le stock d’ombre avant que son enregistrement ne soit modifié.
2. Un échantillon post-écriture de chaque lot marqué comme terminé doit être lisible dans les limites admises.
3. Un travail terminé doit encore être vérifié après que le stock ait été rouvert via une nouvelle connexion.

Le rollback doit restaurer les vecteurs originaux sans modifier le nombre d’enregistrements ni les données contenues dans ces enregistrements.

L’ordre des opérations constitue le fondement de l’argument de sécurité en cas de panne. Si le processus s’arrête après l’écriture dans la copie de secours mais avant l’écriture dans le stockage principal, le résultat n’est qu’une copie supplémentaire inoffensive. Si ces deux étapes sont inversées, la même interruption pourrait détruire définitivement un vecteur original.

La file d’attente de migration sert également de point de contrôle ; ainsi, l’option --resume reprend la traite à partir du dernier lot terminé. L’outil peut surveiller la pression mémoire et l’état de la batterie, et un journal d’accès peut placer en premier les enregistrements les plus sollicités. Si les résultats ne sont pas satisfaisants, l’opération rollback restaure les versions originales à partir de la copie de secours. Les contrats partagés entre les différents systèmes de stockage (Chroma, LanceDB, sqlite-vec, Qdrant, FAISS ainsi qu’un système en mémoire) garantissent que ces opérations ont toujours le même sens partout.

Plugins pour différents systèmes

Local RAG ne repose pas sur une seule base de données vectorielle ou fournisseur d’embeddings, de sorte que le stockage et les embeddings sont gérés via des registres basés sur des plugins. Les systèmes de stockage pris en charge : Chroma, LanceDB, sqlite-vec, Qdrant et FAISS, ainsi qu’un backend fonctionnant en mémoire. Pour générer des embeddings, on dispose de sentence-transformers, fastembed, Ollama, des API compatibles OpenAI, llama.cpp et des vecteurs précalculés.

L’installation de base est conçue pour fonctionner sans PyTorch. Les fonctionnalités de base probe, l’ajustement de Procrustes et la logique de décision s’exécutent avec NumPy, SciPy et scikit-learn, tandis que les dépendances lourdes ou spécifiques à une plateforme ne sont installées que par ceux qui en ont besoin. Les paquets tiers peuvent exposer un point d’entrée rebasis.stores ou rebasis.embedders afin d’ajouter une intégration sans fork du projet.

Confidentialité, journalisation et reproductibilité

Par conception, rebasis ne envoie aucune donnée locale nulle part. Il ne dispose ni de télémesure ni de compteur d’utilisation, et le texte des documents ainsi que les vecteurs n’atteignent jamais les journaux. Étant donné que les informations peuvent être reconstituées à partir d’une embedding, les vecteurs sont considérés comme aussi sensibles que du texte brut. La prise en charge d’OpenTelemetry existe en tant qu’option, est désactivée par défaut et n’exporte que vers le collecteur propre à l’utilisateur.

Chaque décision peut être enregistrée dans un journal d’audit en mode ajout uniquement afin de garantir sa reproductibilité. L’entrée contient les identifiants du modèle, les empreintes de profil, la méthode d’échantillonnage, la graine, les seuils, la version de la métrique, la version de rebasis ainsi que des détails sur l’environnement. Les entrées sont liées entre elles par une chaîne de hachage, ce qui permet de détecter d’éventuelles corruptions ou modifications partielles ultérieures. rebasis audit replay réexécute une mesure antérieure pour déterminer si une différence provient d’une régression logicielle ou d’un changement dans le corpus.

Ce que l’emballage open source cherche à prouver

rebasis est publié sous la licence Apache 2.0, et l’objectif affiché est de rendre ses affirmations vérifiables tout en assurant que son code soit lisible. Dans le répertoire, vous trouverez des documents décrivant les décisions architecturales prises pour les choix clés, ainsi que des scénarios types, des mesures effectuées sur des corpus réels, des budgets de performance, des tests de contrat pour chaque backend, des tests CLI exécutés du début à la fin, et des documents destinés aux contributeurs. La stratégie de tests va au-delà du scénario idéal pour couvrir la cohérence numérique entre les appareils, les limites de mémoire, les propriétés des adaptateurs, les contrats de stockage, ainsi que la fiabilité des migrations et des retraits.

Le pipeline CI cible Python 3.12 et 3.13 sur Linux et macOS, deux systèmes dont les sémantiques de stockage diffèrent. Les versions minimales des dépendances prises en charge font l’objet d’un traitement distinct, et une tâche séparée vérifie que des éléments optionnels tels que PyTorch ou OpenTelemetry ne se retrouvent pas dans le paquet principal. La vérification de type s’effectue à l’aide de mypy --strict, la qualité du code est gérée par Ruff, les limites entre couches par import-linter, et les liens de documentation par MkDocs en mode strict. L’idée principale est que la confiance envers le logiciel open source repose moins sur des affirmations audacieuses dans le README que sur la démonstration des tests et mesures qui les sous-tendent.

Changements de modèle sans choix binaire

Le problème fondamental n’est pas le choix d’une technologie, mais le coût lié à son remplacement. À mesure que les systèmes RAG se développent, leurs index deviennent des investissements en infrastructure, et le choix d’un modèle d’embedding se transforme en une décision bien plus difficile à annuler qu’elle ne le devrait. L’idée derrière rebasis est de relâcher ce lien.

Lorsqu’un nouveau modèle apparaît, la première étape doit consister à évaluer s’il est réellement meilleur avec vos propres données. S’il l’est, il faut ensuite déterminer s’il est possible de créer un pont fiable pour le relier à l’index actuel. Si ce pont est suffisamment solide, le nouveau modèle peut être utilisé immédiatement. Si l’on souhaite maintenir une qualité optimale sur le long terme, la migration peut se faire par lots contrôlés, avec des vérifications et des garanties de réversion. Et si le pont s’avère insuffisant, cela doit être découvert avant un test en production coûteux, et non pendant celui-ci.

C’est l’espace de décision offert par l’outil : mesurer d’abord, créer des ponts ensuite, migrer en toute sécurité lorsque c’est nécessaire. Il s’agit d’un outil ouvert conçu pour renforcer les infrastructures locales RAG, rendre le choix des modèles d’incorporation moins contraignant et rendre les mises à jour des modèles plus transparentes, et il est accessible aux développeurs afin qu’ils puissent l’examiner, l’essayer sur des corpus réels et contribuer à son développement.