Votre pile d'intégration impose un réindexage à 100 % juste pour changer de modèles. Et la plupart des équipes considèrent cela comme inévitable. Imaginez que vous ayez construit un pipeline RAG avec un grand modèle d'intégration pour une qualité de récupération élevée, et qu'il soit mis en production. Six mois plus tard, le trafic de votre application et les coûts de votre modèle d'intégration explosent tandis que votre pipeline peine à évoluer. Vous souhaitez passer à un modèle qui privilégie le coût et la latence afin de répondre à cette nouvelle demande. Mais vos intégrations existantes vivent dans un espace vectoriel, tandis que le nouveau modèle produit des intégrations dans un autre, ce qui les rend incompatibles. Changer de modèle signifie maintenant reconstruire l'index : - Chaque document doit être réintégré - Chaque morceau doit être recomputé - Des millions de vecteurs doivent être régénérés avant que les requêtes ne fonctionnent à nouveau La plupart des équipes regardent cela et décident d'absorber le coût plutôt que de changer. Avec le temps, cela se transforme en une règle tacite. Vous devez soit optimiser pour la qualité, soit optimiser pour le coût, et vous vivez avec la décision que vous avez prise au début. Mais ce n'est pas une limitation fondamentale des intégrations. C'est un choix de conception. Que se passerait-il si les modèles d'intégration partageaient le même espace vectoriel ? Dans cette configuration, vous pourriez indexer des documents en utilisant un grand modèle et les interroger en utilisant un modèle plus léger, sans rien reconstruire. ...