Kernel Memory : un pipeline RAG de référence, archivé et non supporté
Research project. A Memory solution for users, teams, and applications.
En bref
- De quoi s’agit-il ?
- Microsoft livre une implémentation de référence pour l'indexation documentaire et la génération augmentée par récupération en C#. Le dépôt est archivé, l'éditeur précise qu'il s'agit d'un projet de recherche et non d'un logiciel de production.
- À qui s’adresse-t-il ?
- À adopter comme matériel de lecture et comme point de départ pour comprendre l'architecture d'un service d'indexation RAG, pas comme brique de production : le README qualifie lui-même le code de ressource d'apprentissage, sans support. À éviter si vous cherchez une dépendance maintenue avec engagements de correction.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 99 jours.
- En quel langage est-il écrit ?
- Principalement C#, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Un service d'indexation, pas un chatbot
Kernel Memory répond à un problème précis : transformer un ensemble de fichiers hétérogènes en une base interrogeable en langage naturel, avec citations des sources. Le README décrit un service d'IA multi-modal spécialisé dans l'indexation efficace de jeux de données via des pipelines de données hybrides continus et personnalisés, avec prise en charge de la génération augmentée par récupération. Le public visé n'est pas l'utilisateur final. Ce sont des équipes .NET qui construisent une couche mémoire pour une application, un plugin pour Semantic Kernel, Copilot ou ChatGPT, ou qui veulent expérimenter la recherche sémantique sans écrire elles-mêmes la chaîne d'ingestion. Le dépôt se présente comme une implémentation de référence et un recueil de bonnes pratiques, pas comme un produit. Cette distinction n'est pas cosmétique : elle détermine ce que vous pouvez attendre du projet.
Quatre étapes entre le fichier et la réponse
Le README détaille le pipeline d'ingestion par défaut en quatre temps. Extraction du texte d'abord, avec reconnaissance automatique du format de fichier. Partitionnement ensuite, le texte étant découpé en petits morceaux prêts pour la recherche et les prompts RAG. Troisième étape, le calcul des embeddings par un générateur d'embeddings, n'importe lequel selon la documentation. Stockage enfin dans un index vectoriel, avec Azure AI Search et Qdrant cités en exemple. Ce découpage est le vrai contenu du projet : chaque étape est une interface remplaçable, ce qui explique la longue liste de backends et de modèles configurables. À la requête, le chemin s'inverse. AskAsync interroge l'index, récupère les passages pertinents, les injecte dans un prompt et renvoie une réponse accompagnée de citations pointant vers les documents d'origine. C'est ce mécanisme de citation qui distingue un système RAG utilisable en entreprise d'un simple appel à un modèle.
Les tags comme frontière de sécurité
La fonctionnalité la plus intéressante du projet tient en un mot : les tags. À l'import, chaque document peut recevoir un identifiant et des paires clé-valeur, par exemple user avec une adresse électronique, collection avec business puis plans, et fiscalYear avec 2025. Le README présente cela comme un moyen de protéger les informations privées en spécifiant qui possède chaque document, et d'organiser les données pour la recherche et la navigation à facettes. À la requête, MemoryFilters.ByTag restreint la recherche à un sous-ensemble. Le filtrage se fait donc au moment de la récupération, pas après. C'est un choix architectural qui a des conséquences : si un tag est mal posé à l'ingestion, le document reste invisible pour son propriétaire légitime, ou visible pour quelqu'un d'autre. Rien dans le matériel fourni ne décrit de contrôle d'accès en amont du service, ni de validation des tags. La sécurité repose sur la discipline de l'appelant.
Trois façons de le lancer, trois niveaux d'engagement
Le projet s'utilise comme service web, comme conteneur Docker, comme plugin, ou comme bibliothèque .NET embarquée. Pour un essai rapide, le client web se contente d'une URL : MemoryWebClient prend l'adresse du service, ici http://127.0.0.1:9001, et ImportDocumentAsync envoie le fichier. En Python, l'équivalent est un POST vers /upload avec le champ documentId et une liste de tags au format user:devis@contoso.com. Côté .NET embarqué, KernelMemoryBuilder combiné à WithOpenAIDefaults et Build<MemoryServerless> supprime le service séparé. Pour un déploiement conteneurisé, le README montre une intégration .NET Aspire qui injecte la configuration par variables d'environnement : KernelMemory__TextGeneratorType, KernelMemory__DataIngestion__EmbeddingGeneratorTypes__0, KernelMemory__Retrieval__EmbeddingGeneratorType et KernelMemory__Services__OpenAI__APIKey. Ces clés indiquent la structure de configuration attendue, avec un générateur de texte, un ou plusieurs générateurs d'embeddings à l'ingestion, et un générateur d'embeddings distinct pour la récupération. Un déploiement Azure est également documenté, avec un bouton de déploiement et un guide d'infrastructure dans /infra. Notez que la variable d'exemple contient une clé OpenAI en clair : à traiter comme un exemple, pas comme une pratique de déploiement.
Le suivi des jetons, seule instrumentation visible
Le README documente un rapport d'usage des jetons renvoyé avec les réponses générées par LLM. Chaque entrée porte le type de service, le nom du modèle, son type, et deux compteurs : ServiceTokensIn et ServiceTokensOut. L'exemple de sortie affiché mentionne Azure OpenAI, le modèle gpt-4o en TextGeneration, avec 24356 jetons en entrée et 103 en sortie. Ce rapport est utile pour estimer un coût par requête, mais il ne dit rien de la latence, du taux d'échec d'ingestion, ni de la qualité de la récupération. Aucun de ces indicateurs n'apparaît dans le matériel fourni. Pour un système dont la valeur dépend entièrement de la pertinence des passages récupérés, l'absence de mesure de qualité intégrée est une lacune réelle, pas un détail. Vous devrez construire votre propre jeu d'évaluation.
Archivé, non supporté, et ce que cela change
Le README ouvre sur un avertissement qui ne laisse aucune ambiguïté : projet de recherche archivé, le code sert de ressource d'apprentissage et non de logiciel de production, à utiliser avec prudence et à vos risques, sans support fourni. La description du dépôt reprend la même formule. Un lecteur pressé pourrait considérer cet avertissement comme une clause de style propre aux projets Microsoft. Il faut le prendre au pied de la lettre. Un dépôt archivé ne reçoit plus de commits, donc pas de correctif de sécurité, pas de mise à jour de compatibilité avec les SDK de modèles ou les bases vectorielles qui évoluent vite. Les versions publiées les plus récentes visibles dans le matériel portent les identifiants packages-0.98.250508.3, packages-0.98.250324.1 et packages-0.98.250323.1, la plus récente datant de mai 2025. Deux versions publiées à un jour d'intervalle en mars suggèrent une phase de correction active à ce moment-là, ce qui rend l'archivage d'autant plus net. Le cas où l'outil est le mauvais choix est simple : toute application dont la disponibilité ou la conformité dépend d'une dépendance maintenue.
Face à une chaîne RAG assemblée à la main
L'alternative la plus évidente n'est pas un autre framework mais l'assemblage direct des briques. Vous appelez vous-même un découpage de texte, un modèle d'embeddings, et une base vectorielle comme Qdrant ou Azure AI Search, puis vous composez le prompt. La différence d'approche est nette. Kernel Memory fournit un pipeline unifié où extraction, découpage, embeddings et stockage sont des étapes nommées et interchangeables, avec une API unique côté ingestion et côté requête, et un modèle de tags intégré au filtrage. L'assemblage manuel vous laisse choisir chaque composant et le mettre à jour indépendamment, au prix du code de plomberie et de la gestion des formats de fichiers. Pour un prototype ou une démonstration, la chaîne unifiée fait gagner du temps. Pour un système en production, l'absence de maintenance du pipeline devient le facteur décisif, et la question se déplace vers la bibliothèque d'orchestration que vous utilisez déjà.
Licence MIT et coût réel de la reprise
Le dépôt est publié sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, sous réserve de conserver la notice de licence. Le README précise que le code n'est pas une offre officiellement supportée par Microsoft. Cette combinaison signifie que vous pouvez reprendre le code, le forker et le maintenir vous-même, sans obligation de contribution en retour. Le coût de cette reprise est le vrai sujet : il faut suivre les évolutions des SDK de modèles, des formats de documents et des API des bases vectorielles, sur une base de code C# que vous n'avez pas écrite. Avant de vous engager, vérifiez la version publiée la plus récente sur le registre NuGet et l'état de la branche main. Ce sont les deux points qui déterminent si vous partez d'un socle figé ou d'un socle que quelqu'un d'autre fait vivre.
Conclusion éditoriale
À adopter comme matériel de lecture et comme point de départ pour comprendre l'architecture d'un service d'indexation RAG, pas comme brique de production : le README qualifie lui-même le code de ressource d'apprentissage, sans support. À éviter si vous cherchez une dépendance maintenue avec engagements de correction. Avant tout essai, vérifiez la version publiée la plus récente sur le registre NuGet et l'état de la branche main, puisque le dépôt est archivé.
Notes de la communauté