Les automatisations IA sans contexte d’entreprise produisent des sorties génériques. Votre recette peut écrire une excellente analyse concurrentielle — mais elle ne connaît pas vos noms de produits. Elle peut rédiger une réponse à incident — mais elle n’a aucune idée de ce que dit votre runbook.
Les bases de connaissances corrigent cela. Téléchargez vos documents, et JieGou injecte le contenu pertinent dans chaque exécution de recette et workflow automatiquement via la génération augmentée par récupération (RAG).
Comment les documents sont traités
Téléchargez des fichiers dans n’importe lequel de ces formats : PDF, DOCX, CSV, XLSX, TXT, Markdown, HTML. Ou importez directement depuis une URL. La limite de taille par fichier est de 10 MB, avec une limite de contenu extrait de 1 MB après parsing.
Une fois téléchargés, les documents passent par un pipeline de traitement multi-étapes :
1. Découpage. Les documents sont divisés avec une stratégie à deux niveaux. D’abord, le système recherche les titres markdown # et ## et découpe à ces frontières. Pour les documents non structurés sans titres, il se rabat sur le découpage par paragraphes. La taille cible est d’environ 40 000 caractères (~10K tokens), avec un minimum de 4 000 caractères.
2. Résumé. Chaque chunk reçoit un résumé généré par LLM de 200-400 mots via Claude. Ces résumés servent de contexte de repli quand la recherche par embedding ne retourne aucun résultat.
3. Embedding. Chaque chunk est embedded avec OpenAI text-embedding-3-small (1536 dimensions). Les embeddings sont stockés dans Firestore aux côtés du contenu et des métadonnées — aucune base de données vectorielle externe requise.
Comment la récupération fonctionne à l’exécution
Quand une recette ou une étape de workflow s’exécute :
- Un embedding de requête est généré à partir du prompt de l’utilisateur ou de l’entrée de l’étape
- Une recherche par similarité cosinus est lancée contre tous les embeddings de chunks dans les bases de connaissances pertinentes
- Les chunks en dessous d’un seuil de similarité minimum de 0,3 sont éliminés
- La sélection top-k choisit les meilleurs correspondances dans un budget de tokens — par défaut 5 chunks, 8 000 tokens max
- Les chunks sélectionnés sont injectés dans le prompt LLM comme blocs XML
<reference_documents> - Si aucun embedding n’atteint le seuil, le système se rabat sur le contexte basé sur les résumés
Résolution de contexte à trois niveaux
| Niveau | Comment ça fonctionne | Quand l’utiliser |
|---|---|---|
| IDs de documents explicites | IDs de documents spécifiques passés à l’exécution | Quand vous savez exactement quels documents sont pertinents |
| Attaché à la recette/workflow | Bases de connaissances liées via le champ knowledgeBaseIds | Quand certains docs doivent toujours accompagner une recette spécifique |
| Auto-contexte | Bases de connaissances marquées isAutoContext: true, périmétées par département | Quand les documents doivent être disponibles pour chaque exécution d’un département |
L’auto-contexte est le niveau le plus puissant. Marquez votre wiki d’entreprise ou la documentation produit comme auto-contexte, et chaque recette du département obtient les chunks pertinents sans configuration manuelle.
Pertinence pilotée par le feedback
Les bases de connaissances deviennent plus intelligentes au fil du temps. Quand les utilisateurs donnent un feedback positif ou négatif sur la qualité d’une exécution, le système ajuste les scores de pertinence des chunks pour les récupérations futures.
Le scoring utilise le lissage de Laplace : score = (positifs + 1) / (positifs + négatifs + 2). Le facteur de boost résultant va de 0,5x à 1,5x, stocké dans Redis avec un TTL de 7 jours.
Capture de connaissances : apprendre des bonnes sorties
C’est là que les bases de connaissances deviennent un volant d’inertie. Quand une exécution de recette reçoit un feedback positif ou obtient un bon score sur le Quality Guard de JieGou, le système capture automatiquement des connaissances structurées de cette sortie.
Un LLM extrait : titre, faits clés, entités et tags thématiques. Les connaissances extraites sont stockées dans une base « Auto-Captured Knowledge » dédiée avec isAutoContext: true. Les exécutions futures dans le même département peuvent récupérer ces connaissances automatiquement.
Fraîcheur des documents
Les documents sourcés depuis des URLs peuvent être configurés avec un paramètre refreshIntervalDays pour le re-téléchargement automatique. Seuls les chunks affectés sont re-traités — de nouveaux embeddings et résumés sont générés de manière incrémentale plutôt que de retraiter le document entier.
Étape Write-to-KB dans les workflows
Les workflows peuvent écrire les sorties directement dans les bases de connaissances avec l’étape Write-to-KB. Un workflow de triage support client peut résoudre un ticket, puis écrire le résumé de résolution dans une base de connaissances. La prochaine fois qu’un ticket similaire arrive, la résolution est disponible comme contexte RAG.
Disponibilité
Les bases de connaissances avec RAG sont disponibles sur les plans Pro et supérieurs. La capture automatique de connaissances et l’étape Write-to-KB sont incluses sans coût supplémentaire. En savoir plus sur toutes les fonctionnalités ou commencez votre essai gratuit.