langchain-rust : composer des programmes LLM en Rust, avec ce que la documentation couvre réellement
🦜️🔗LangChain for Rust, the easiest way to write LLM-based programs in Rust
En bref
- De quoi s’agit-il ?
- Le portage Rust de LangChain expose LLM, embeddings, vector stores, chaînes et agents derrière des traits communs. La surface annoncée est large, mais la documentation publique s'arrête souvent à l'exemple, et le lecteur doit vérifier lui-même ce qui est stable.
- À qui s’adresse-t-il ?
- langchain-rust convient à une équipe Rust qui veut un point d'entrée unique vers OpenAI, Azure, Ollama, Anthropic et MistralAI, avec des vector stores variés, sans écrire chaque client HTTP à la main. Il ne convient pas si votre besoin se limite à un seul fournisseur et à un seul appel : le SDK officiel de ce fournisseur est plus court à intégrer et suit ses évolutions de plus près.
- 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 7 jours.
- En quel langage est-il écrit ?
- Principalement Rust, 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
Le problème concret : assembler plusieurs fournisseurs derrière une seule API
Un programme Rust qui interroge un LLM, calcule des embeddings et interroge une base vectorielle finit par empiler des clients HTTP distincts, chacun avec son format de requête, sa gestion d'erreurs et son async. langchain-rust propose de remplacer cette accumulation par des traits communs : le README annonce comme objectif « Building applications with LLMs through composability, with Rust ». Le public visé est donc l'équipe qui écrit déjà du Rust asynchrone et qui veut changer de fournisseur sans réécrire la couche d'appel. Le README énumère quatre fournisseurs de LLM (OpenAi, Azure OpenAi, Ollama, Anthropic Claude) et cinq sources d'embeddings (OpenAi, Azure OpenAi, Ollama, Local FastEmbed, MistralAI). Ce n'est pas un cadre généraliste : c'est une collection d'implémentations derrière une interface partagée, et la valeur vient de cette interface, pas des intégrations prises une par une.
Ce que le dépôt expose : chaînes, agents, outils, routage sémantique
La liste des fonctionnalités du README dépasse le simple appel de modèle. Côté chaînes, sept entrées sont cochées : LLM Chain, Conversational Chain, Conversational Retriever Simple, Conversational Retriever With Vector Store, Sequential Chain, Q&A Chain et SQL Chain. Côté agents, deux : un agent de chat avec outils, et un agent d'outils compatible OpenAI. Les outils listés incluent Serpapi/Google, DuckDuckGo Search, Wolfram/Math, la ligne de commande et un outil de synthèse vocale (Text2Speech). Le routage sémantique existe en deux variantes, statique et dynamique, avec les exemples semantic_routes.rs et dynamic_semantic_routes.rs. Cette étendue est le point fort du projet et aussi sa zone d'incertitude : le README présente une liste de cases cochées, pas une matrice de stabilité. Rien dans le matériel fourni n'indique quelles briques sont couvertes par des tests, lesquelles sont expérimentales, ni lesquelles ont été touchées par les versions récentes. Un lecteur qui a besoin de la chaîne SQL ou de l'agent d'outils doit ouvrir l'exemple correspondant et juger sur pièce.
Le flux de données : chargement, découpage, embeddings, récupération
Le README décrit les document loaders comme le point d'entrée des données. Chaque loader expose une méthode load() qui renvoie un flux : les exemples appellent .load().await puis .map(|d| d.unwrap()).collect::<Vec<_>>().await, ce qui donne un Vec de documents. Les formats annoncés sont PDF (deux variantes, PdfExtractLoader et LoPdfLoader en commentaire), Pandoc pour les fichiers bureautiques, HTML, HTML vers Markdown, CSV et les commits Git. Le lecteur HTML vers Markdown accepte des options, par exemple HtmlToMarkdownOptions::default().with_skip_tags(vec!["figure".to_string()]) pour ignorer certaines balises. Une fois les documents obtenus, la chaîne Conversational Retriever With Vector Store les envoie vers un vector store, parmi OpenSearch, Postgres, Qdrant, Sqlite et SurrealDB, puis récupère les passages pertinents avant de construire le prompt. C'est un pipeline RAG classique, et le projet ne prétend pas faire autre chose. Le point à retenir est que le découpage et la stratégie de récupération ne sont pas détaillés dans le README : ils se lisent dans les exemples, pas dans une spécification.
Mise en route : dépendance, clés et exemples exécutables
L'installation passe par crates.io sous le nom langchain-rust, comme l'indique le badge du README. Le projet publie une documentation de démarrage sur langchain-rust.sellie.tech/get-started/quickstart, et un serveur Discord est lié en tête de README. Les clés d'API ne sont pas décrites dans le matériel fourni : le README renvoie vers des fichiers d'exemple par fournisseur, par exemple examples/llm_openai.rs, examples/llm_azure_open_ai.rs, examples/llm_ollama.rs et examples/llm_anthropic_claude.rs. C'est là qu'il faut chercher les noms de variables d'environnement et les paramètres de construction, car le README ne les reproduit pas. Pour les embeddings, les fichiers correspondants sont examples/embedding_openai.rs, examples/embedding_azure_open_ai.rs, examples/embedding_ollama.rs, examples/embedding_fastembed.rs et examples/embedding_mistralai.rs. Pour les vector stores, chaque backend a son exemple, dont examples/vector_store_postgres.rs, examples/vector_store_qdrant.rs et examples/vector_store_sqlite_vss.rs. Le README donne aussi un extrait de code par loader, avec les imports nécessaires (futures_util::StreamExt, url::Url). La démarche raisonnable consiste à copier l'exemple le plus proche de votre cas et à le compiler avant d'écrire quoi que ce soit d'autre, parce que c'est le seul endroit où les signatures sont visibles.
Les limites visibles dans le matériel fourni
Trois points ressortent. D'abord, la cadence : les trois dernières versions listées sont v4.4.2 (10 septembre 2024), puis v4.5.0 et v4.6.0, toutes deux datées du 6 octobre 2024, tandis que le dernier push sur main est daté du 8 septembre 2026. Le README ne documente pas ce qui s'est accumulé entre la dernière publication et l'état de main. Un utilisateur qui dépend de la version crates.io et un utilisateur qui suit la branche principale ne manipulent donc pas forcément la même surface d'API. Ensuite, la documentation : le README est une liste de fonctionnalités et une série d'extraits. Il ne décrit ni la politique de gestion des erreurs, ni le comportement en cas de réponse malformée du fournisseur, ni les limites de débit. Ce sont précisément les cas où un client maison et une bibliothèque divergent. Enfin, le périmètre : la liste des fournisseurs de LLM s'arrête à OpenAI, Azure OpenAI, Ollama et Anthropic Claude. Si votre modèle passe par un autre fournisseur, langchain-rust ne vous fait pas gagner de travail. Et si votre besoin est un appel unique à OpenAI, la couche d'abstraction ajoute une dépendance sans rien remplacer.
Face à quoi le comparer : le SDK du fournisseur, pas un autre framework
L'alternative la plus directe n'est pas un autre portage de LangChain, c'est le SDK officiel du fournisseur que vous utilisez déjà. La différence tient à ce que chacun optimise. Le SDK officiel suit les évolutions de l'API de son fournisseur au rythme de ce fournisseur, expose ses paramètres propres sans traduction, et n'impose aucune abstraction intermédiaire. langchain-rust, lui, met derrière un même trait des fournisseurs qui n'ont ni les mêmes paramètres ni les mêmes formats de réponse. Ce que vous y gagnez est la substitution : passer de OpenAI à Ollama, ou d'Ollama à Anthropic, sans réécrire la couche d'appel. Ce que vous y perdez est la prise en charge immédiate des nouveautés propres à un fournisseur, puisqu'il faut qu'un contributeur les ajoute et les publie. Le choix se fait donc sur une question précise : votre application doit-elle changer de fournisseur, ou doit-elle exploiter à fond un seul fournisseur ? Dans le second cas, le SDK officiel est le bon outil, et langchain-rust est une couche de trop.
Maintenance, licence et coût de mise à jour
Le projet est publié sous licence MIT, indiquée dans les métadonnées du dépôt. Cette licence autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de copyright et le texte de la licence. Elle n'accorde aucune garantie. Je ne peux pas confirmer, à partir du matériel fourni, la présence d'un fichier LICENSE à la racine ni la mention exacte du titulaire du copyright : c'est la première chose à vérifier dans le dépôt si la conformité compte pour vous. Sur le coût de maintenance, le décalage entre la dernière version publiée (v4.6.0, 6 octobre 2024) et le dernier push sur main (8 septembre 2026) est le point sensible. Une équipe qui épingle une version crates.io se protège des changements d'API mais accumule du retard sur les correctifs et les nouvelles intégrations. Une équipe qui suit main accepte de casser sa compilation sans préavis. Le README ne décrit ni politique de branches, ni calendrier de publication, ni engagement de compatibilité. Ce sont des coûts à intégrer avant l'adoption, pas après.
Conclusion éditoriale
langchain-rust convient à une équipe Rust qui veut un point d'entrée unique vers OpenAI, Azure, Ollama, Anthropic et MistralAI, avec des vector stores variés, sans écrire chaque client HTTP à la main. Il ne convient pas si votre besoin se limite à un seul fournisseur et à un seul appel : le SDK officiel de ce fournisseur est plus court à intégrer et suit ses évolutions de plus près. Avant de vous engager, vérifiez trois choses dans le dépôt : la version publiée sur crates.io face au dernier push sur main, la présence d'un fichier de licence à la racine, et l'exemple correspondant exactement à votre cas (par exemple examples/vector_store_qdrant.rs) plutôt qu'un exemple voisin.
Notes de la communauté