tryAGI/LangChain : une réimplémentation C# qui assume sa dette envers l'original

Le problème : écrire du C# sans quitter l'écosystème LangChain

Le README est clair sur la motivation. Semantic Kernel est utile, l'équipe dit l'utiliser quand c'est possible, mais il ne couvre pas tous les scénarios et reste étroitement lié à l'écosystème Microsoft. tryAGI/LangChain se présente donc comme une alternative pour les développeurs .NET qui veulent les abstractions de LangChain, avec une tolérance assumée pour les bibliothèques tierces. La cible est un développeur C# qui connaît déjà LangChain côté Python et ne veut pas réécrire sa logique de retrieval ou de chaînes dans un autre paradigme. Le dépôt n'essaie pas de convaincre un public non technique. Il s'adresse à des gens qui savent ce qu'est un splitter de texte et qui cherchent surtout à savoir si l'API C# tient la comparaison.

Le mécanisme : documents, embeddings, collection, chaîne

Le flux de données décrit dans le README est linéaire. On instancie un provider OpenAI, on en tire un modèle de chat et un modèle d'embedding. On ouvre une base vectorielle SQlite avec un fichier local, vectors.db dans l'exemple. La méthode AddDocumentsFromAsync charge un document via un loader, ici PdfPigPdfLoader, le découpe avec un textSplitter dont la valeur par défaut est CharacterTextSplitter avec ChunkSize = 4000 et ChunkOverlap = 200, calcule les embeddings et les range dans une collection nommée. Ensuite deux chemins coexistent. Le premier appelle GetSimilarDocuments avec une question et un nombre de résultats, puis injecte le texte obtenu dans un prompt envoyé au LLM. Le second construit une chaîne avec des opérateurs : Set pour la question, RetrieveSimilarDocuments pour la recherche, CombineDocuments pour fusionner les extraits sous la clé context, Template pour le prompt, LLM pour l'appel final. Le résultat se récupère avec RunAsync("text"). Le README mentionne aussi llm.Usage et embeddingModel.Usage, ce qui laisse entendre qu'un suivi de consommation est exposé, sans détailler le format.

Démarrage : ce que le README donne réellement à copier

Les commandes exactes ne sont pas dans le README, mais les dépendances le sont : LangChain, LangChain.Databases.Sqlite et LangChain.DocumentLoaders.Pdf. Le paquet NuGet publié s'appelle LangChain, comme l'indique le badge nuget/vpre/LangChain. La clé d'environnement attendue est OPENAI_API_KEY, lue via Environment.GetEnvironmentVariable, avec une InconclusiveException si elle manque. Le point de configuration le plus facile à rater est dimensions: 1536, que le README justifie par le choix de TextEmbeddingV3SmallModel. Un autre est collectionName, présenté comme optionnel mais nécessaire dès qu'on veut plusieurs collections dans le même fichier. Le textSplitter passé à null déclenche les valeurs par défaut. Le README signale un coût indicatif de 0,015 dollar pour une exécution depuis zéro et 0,0004 dollar en réexécution si la base existe déjà, ce qui suppose que les embeddings sont persistés et réutilisés. Ces chiffres viennent du commentaire de l'exemple, pas d'une mesure indépendante.

La documentation comme point faible structurel

Le README renvoie au wiki hébergé sur tryagi.github.io, puis ajoute une phrase qui devrait retenir l'attention : si le wiki contient du code obsolète, il faut consulter les tests, en particulier src/Meta/test/WikiTests.cs. C'est un aveu utile et un signal de maintenance. Une documentation dont la véracité est garantie par des tests qui la compilent est une bonne pratique, mais elle implique que le wiki peut dériver entre deux passages. Pour un lecteur qui évalue le projet, cela veut dire que la source de vérité est le code de test, pas la page web. Le dépôt fournit aussi examples et src/tests/LangChain.IntegrationTests/ReadmeTests.cs. La conséquence pratique est simple : prévoyez de lire du C# pour comprendre l'API, pas seulement de la prose. Ce n'est pas un défaut rédhibitoire pour un public .NET, mais c'est un coût d'entrée réel.

Chaînes contre appels directs : deux styles, un compromis

L'exemple du README montre les deux approches côte à côte, et c'est probablement le passage le plus intéressant du dépôt. Les appels asynchrones directs sont lisibles : on récupère les documents, on compose une chaîne de caractères, on appelle GenerateAsync. La version chaîne remplace cela par une composition d'opérateurs avec des clés nommées, text par défaut pour la question, context pour les documents combinés. L'avantage est la réutilisation : un même pipeline peut être rejoué avec une autre question sans réécrire le prompt. Le coût est une indirection supplémentaire, des clés à retenir et un débogage moins direct. Le README montre d'ailleurs llm.UseConsoleForDebug() comme aide, ce qui suggère que suivre le flux d'une chaîne n'est pas évident sans instrumentation. Pour un pipeline à une seule étape, la version directe est plus honnête. Les chaînes prennent leur sens quand la séquence retrieval, fusion, template, appel se répète.

SQlite comme base vectorielle : pratique, mais jusqu'où

Le choix de SqLiteVectorDatabase avec un simple fichier vectors.db est cohérent avec un objectif de mise en route rapide : pas de service à lancer, pas de conteneur, un fichier qu'on peut supprimer pour repartir de zéro. Le README ne documente ni les performances de recherche, ni le comportement au-delà d'une certaine volumétrie, ni la concurrence en écriture. Ces points ne sont pas abordés, donc on ne peut rien affirmer. Ce qui est visible, c'est que la collection est nommée et que plusieurs collections peuvent coexister dans le même fichier, ce qui suffit pour séparer des jeux de documents. Pour un prototype ou une application de bureau, ce modèle est adapté. Pour un service qui doit indexer en continu et servir plusieurs instances, la question de la persistance partagée se pose et le README n'y répond pas.

Alternatives : Semantic Kernel et le LangChain d'origine

La comparaison la plus directe est celle que le README pose lui-même. Semantic Kernel vient de Microsoft, il est décrit comme utile et utilisé par l'équipe, mais lié à l'écosystème Microsoft et incomplet pour certains scénarios. La différence d'approche est là : Semantic Kernel est un produit d'éditeur avec une trajectoire propre, tryAGI/LangChain est une transposition d'abstractions existantes, portée par une communauté. L'autre alternative est LangChain en Python, qui reste la référence puisque le projet C# dit vouloir s'en rapprocher le plus possible. Si votre équipe est déjà en Python, la question de la réécriture ne se pose pas. Si votre base de code est en C#, la vraie question est de savoir si vous voulez une API qui imite un projet dont les versions évoluent de leur côté, avec le décalage que cela implique.

Maintenance, licence et ce qu'il faut vérifier

Le dépôt est sous licence MIT, et le README précise que l'organisation n'a pas l'intention d'en changer dans un avenir prévisible, tout en notant que d'autres projets de l'organisation peuvent avoir des licences différentes. C'est une distinction à garder en tête si vous dépendez de plusieurs paquets de la même organisation. Le README indique aussi que certaines pages de documentation s'appuient sur dotnet/docs sous CC BY 4.0, avec des exemples adaptés. Sur la maintenance, les notes du mainteneur sont explicites : il dit ne pas pouvoir progresser seul de manière sérieuse, vouloir fédérer des développeurs C#, accepter les pull requests sous 24 heures dans la mesure du possible, et chercher des personnes pour rejoindre l'équipe principale. Les versions listées s'arrêtent à v0.15.0 en juin 2024, alors que le dépôt a reçu des commits bien plus tard. Cette combinaison, activité de code récente et publication de version plus ancienne, mérite d'être vérifiée sur NuGet avant de dépendre du paquet.

Conclusion éditoriale

À adopter si vous écrivez du C# et voulez retrouver les abstractions de LangChain sans passer par Python. À éviter si vous attendez une API stabilée ou une documentation de référence complète : la version publiée la plus récente listée est v0.15.0, et le README renvoie explicitement au wiki en admettant qu'il peut être obsolète. Vérifiez d'abord que les tests WikiTests.cs couvrent bien la page du wiki que vous suivez, puis que vos dimensions d'embedding correspondent au modèle choisi, 1536 pour TextEmbeddingV3SmallModel dans l'exemple.

Sources officielles

1. License: MIT
2. Project website
3. README
4. Releases
5. tryAGI/LangChain on GitHub