FastGPT : orchestrer des agents et du RAG sans écrire de code

Le problème : assembler une chaîne RAG complète avant d'avoir une seule réponse

Construire un système de questions-réponses sur des documents internes demande normalement d'empiler plusieurs briques. Il faut un parseur pour le PDF, le Docx ou le PPTX, un découpage en chunks, un modèle d'embedding, un index vectoriel, une étape de recherche, un reranker, puis un modèle de génération. Chaque brique a sa configuration, ses formats d'entrée et ses modes de défaillance. Le README de FastGPT positionne le projet exactement là : une plateforme qui fournit ces briques ensemble plutôt qu'une bibliothèque à assembler soi-même.

Le public visé est précis. Ce sont des équipes produit ou des intégrateurs qui doivent livrer un assistant documentaire sans mobiliser un ingénieur spécialisé en recherche d'information. Le README liste les formats pris en charge (TXT, MD, HTML, PDF, Docx, PPTX, CSV, XLSX), la lecture d'URL et l'import CSV par lots. Cette liste suffit à couvrir la plupart des corpus d'entreprise, et c'est souvent le point qui bloque dans un projet RAG artisanal.

Le projet ne se limite pas à la recherche. Le README décrit aussi une couche d'orchestration, avec des workflows de conversation et de plugin, des nœuds RPA, du MCP dans les deux sens et une gestion des interactions utilisateur. La frontière entre plateforme RAG et plateforme d'agents est volontairement floue, et c'est un choix de conception qu'il faut évaluer avant d'adopter.

Ce que fait réellement le pipeline, d'après la structure du dépôt

Le dépôt est écrit en TypeScript, avec Next.js dans les topics du projet. La documentation publique décrit une architecture en deux temps : une phase d'ingestion où les documents sont chargés, découpés puis vectorisés, et une phase de requête où la question de l'utilisateur déclenche une recherche puis une génération.

Le README mentionne une recherche hybride et un reranking. La recherche hybride combine généralement une similarité vectorielle et une correspondance par mots-clés, ce qui aide sur les requêtes contenant des références exactes (numéros de contrat, noms de produits). Le reranking réordonne les passages candidats avant de les envoyer au modèle. Ces deux étapes sont activables dans la configuration de la base de connaissances, mais le README ne détaille ni les pondérations par défaut ni le modèle de reranking utilisé. Il faut se référer à la documentation en ligne pour ces valeurs.

Un point intéressant pour les équipes qui maintiennent un corpus vivant : les chunks sont modifiables et supprimables individuellement. Cela évite de reconstruire tout l'index quand une seule section d'un document change. Le README liste aussi trois modes d'import : saisie manuelle, découpage direct, et import par paires question-réponse. Ce dernier mode est utile quand le corpus contient déjà des FAQ, car il court-circuite le découpage automatique, souvent la source d'erreurs la plus difficile à diagnostiquer.

Le projet expose également une API de base de connaissances. Le README cite un endpoint OpenAPI hébergé sur cloud.fastgpt.io/apidoc/systemopenapi. C'est le point d'intégration à examiner en premier si vous prévoyez d'alimenter FastGPT depuis un pipeline existant plutôt que par l'interface web.

Démarrage : deux commandes et un mot de passe par défaut

Le README donne la séquence d'installation. La première commande télécharge un script qui collecte la configuration :

bash <(curl -fsSL https://doc.fastgpt.io/deploy/install.sh)

La seconde démarre la pile :

docker compose up -d

Une fois les conteneurs actifs, l'interface est accessible sur http://localhost:3000, avec le compte root et le mot de passe 1234. Ce mot de passe par défaut est un point de vigilance immédiat : toute instance exposée sur un réseau non isolé doit être reconfigurée avant le premier usage réel.

Le README oriente vers trois voies de déploiement : Docker, Sealos Cloud pour un déploiement en un clic, et la version commerciale pour des fonctions plus complètes et un accompagnement. La documentation de développement local est séparée, sous doc.fastgpt.io/self-host/dev. Le projet mentionne aussi un service annexe, AI Proxy, présenté comme un agrégateur de modèles avec répartition de charge, ainsi qu'un dépôt fastgpt-plugin distinct pour les plugins.

Cette séparation en plusieurs dépôts (FastGPT, fastgpt-plugin, aiproxy, Sealos) est un choix d'architecture qui a des conséquences pratiques : une mise à niveau implique de vérifier la compatibilité entre plusieurs composants, pas seulement de changer un tag d'image.

Ce que le README annonce comme non terminé

La liste des fonctionnalités du README distingue explicitement les cases cochées des cases vides, et cette distinction est plus informative que la liste des fonctions disponibles. Quatre éléments sont marqués comme non réalisés : la génération assistée de workflows, un mode de débogage avancé pour l'orchestration, les journaux par nœud d'application, et la mise à jour à chaud des modules RAG et de l'Agent-loop. La génération de plugins par IA est également listée comme non disponible.

Ces absences dessinent un profil d'usage. Les journaux par nœud manquants signifient que diagnostiquer un workflow qui produit une mauvaise réponse demande de raisonner au niveau de l'application entière, pas du nœud fautif. Un mode de débogage avancé absent renforce ce problème : sur un graphe à plusieurs branches, isoler l'étape qui dérape devient un travail manuel. Le README indique en revanche que les journaux de chaîne d'appel complets sont disponibles, ce qui atténue partiellement la difficulté.

L'absence de mise à jour à chaud pour le module RAG est une contrainte opérationnelle concrète. Si la configuration de récupération change, il faut s'attendre à un redémarrage plutôt qu'à une rechargement dynamique. Le README précise que seuls les outils système bénéficient de la mise à jour à chaud. Pour une équipe qui itère sur les paramètres de recherche en production, c'est une friction à intégrer dans le planning.

Enfin, la fonction d'évaluation d'application est cochée, mais le README ne décrit ni les métriques calculées ni la méthode de constitution des jeux de test. C'est une zone où la documentation publique est mince, et il vaut mieux la vérifier directement dans l'interface avant de compter dessus.

La licence NOASSERTION : le point bloquant pour un achat en entreprise

Le champ de licence du dépôt est renseigné comme NOASSERTION. Cela signifie que l'outil d'analyse n'a pas pu rattacher le fichier de licence du projet à un identifiant SPDX connu. Ce n'est pas la même chose qu'une absence de licence, et ce n'est pas non plus une licence open source reconnue par l'OSI.

La conséquence pratique est directe. Un service juridique qui applique une politique de liste blanche de licences ne pourra pas valider FastGPT sur la seule base du champ affiché. Il faudra ouvrir le fichier LICENSE sur la branche main et lire les clauses, en particulier celles qui concernent l'usage commercial, la redistribution et les restrictions éventuelles sur l'exploitation en tant que service. Le README mentionne par ailleurs une version commerciale distincte, ce qui suggère une séparation entre le périmètre communautaire et le périmètre payant, mais le README ne décrit pas où passe cette frontière.

Le rythme de publication est soutenu : trois versions en moins d'un mois selon les notes de version fournies (v4.16.0 le 16 août, v4.16.1 le 21 août, v4.16.2 le 3 septembre). Ce rythme a un coût. Chaque mise à niveau peut modifier le schéma de configuration ou les formats d'import, et rien dans le matériel fourni n'indique une politique de compatibilité ascendante. Une équipe qui auto-héberge doit prévoir de tester chaque version sur un environnement de recette avant de la déployer, en particulier si elle a personnalisé des plugins.

Face à Dify : même promesse, équilibre différent

Dify est l'alternative la plus directement comparable. Les deux projets visent le même usage : une interface visuelle pour construire des applications LLM avec RAG. La différence se joue sur l'équilibre entre les deux moitiés du produit.

Chez Dify, l'éditeur de workflow est le cœur du produit, et la base de connaissances est un composant parmi d'autres. Chez FastGPT, le README place la gestion documentaire au même niveau que l'orchestration : découpage manuel, import par paires question-réponse, modification et suppression de chunks individuels, API de base de connaissances dédiée. Pour un projet dont la valeur repose sur un corpus documentaire volumineux et évolutif, ces opérations de maintenance du corpus comptent davantage que la richesse des nœuds de workflow.

L'écart se creuse sur le MCP. FastGPT annonce un support bidirectionnel, ce qui signifie que la plateforme peut à la fois consommer des serveurs MCP externes et exposer ses propres capacités. Le README ne documente pas cette intégration au-delà de la mention dans la liste des fonctionnalités, donc il est impossible de juger de sa maturité à partir du matériel disponible.

Pour un choix entre les deux, la question à se poser n'est pas laquelle a le plus de fonctionnalités cochées. C'est de savoir si votre charge de travail principale est la maintenance d'un corpus documentaire ou la construction de logiques d'agent complexes. FastGPT penche vers la première, Dify vers la seconde.

Qui doit adopter, qui doit passer

FastGPT convient à une équipe qui a un corpus documentaire stable, un besoin de réponses sourcées, et peu de temps pour construire un pipeline RAG à la main. Le déploiement Docker en deux commandes rend l'essai peu coûteux, et la modification de chunks individuels évite de reconstruire l'index à chaque correction. L'API de base de connaissances permet d'automatiser l'alimentation depuis un pipeline existant sans passer par l'interface web.

Il ne convient pas à une organisation qui exige une licence OSI identifiée avant tout pilote. Le champ NOASSERTION impose une revue juridique manuelle du fichier LICENSE, et le README ne fournit pas d'éléments pour anticiper le résultat de cette revue. De même, une équipe qui doit diagnostiquer finement des workflows à plusieurs branches sera gênée par l'absence de journaux par nœud, listée comme non réalisée.

Deux vérifications avant d'engager du temps. D'abord, lire le fichier LICENSE sur la branche main et confirmer ce qui est autorisé en usage commercial et en hébergement multi-tenant. Ensuite, tester la fonction d'évaluation d'application sur un échantillon de vos propres documents : le README la coche comme disponible mais ne décrit ni ses métriques ni sa méthode, et c'est le seul moyen de savoir si la qualité des réponses est mesurable avec les outils intégrés.

Conclusion éditoriale

FastGPT convient aux équipes qui veulent un système de questions-réponses documentaire fonctionnel en une journée, avec Docker, sans écrire de backend. Il ne convient pas à celles qui ont besoin d'une licence OSI claire, d'une API stable ou d'un contrôle fin sur le pipeline de récupération. Avant d'aller plus loin, vérifiez deux choses : le contenu réel du fichier LICENSE sur la branche main, et si la fonction d'évaluation intégrée suffit à mesurer la qualité de vos réponses sur vos propres documents.

Sources officielles

1. Issues
2. labring/FastGPT on GitHub
3. Project website
4. README
5. Releases