Bases de connaissances
Les trois surfaces de connaissance dans Scrydon — la connaissance de conversation, les bases de connaissances d'espace de travail et la KB d'organisation gouvernée — quand utiliser laquelle, pourquoi elles diffèrent, et comment nous évaluons la qualité de la récupération par rapport au marché.
Scrydon propose plusieurs types de bases de connaissances, et ce délibérément. La connaissance en entreprise obéit à des cycles de vie différents — un fichier joint à une conversation, la documentation vivante d'une équipe dans son espace de travail, et les faits vérifiés dont dépend l'ensemble de l'organisation ne sont pas la même chose. Prétendre le contraire est ce qui conduit les plateformes de connaissance à n'offrir ni gouvernance ni utilisabilité. Cette page explique les différentes surfaces, quand utiliser laquelle, et comment nous mesurons la qualité de la récupération.
Les trois surfaces de connaissance
| Connaissance de conversation | Bases de connaissances d'espace de travail | KB d'organisation (gouvernée) | |
|---|---|---|---|
| Ce que c'est | Fichiers joints à une conversation Chat, indexés automatiquement. | KBs nommées que vous créez dans un espace de travail — documents, transcriptions, contenus collés. | Connaissance organisationnelle typée, soumise à la conformité, avec marquages d'accès et cycle de révision. |
| Portée | Une seule conversation. | Un espace de travail (partageable selon la politique d'accès). | L'ensemble de l'organisation. |
| Cycle de vie | Supprimée avec la conversation. | Gérée par vous — ajout, mise à jour, suppression. | Le contenu entre par promotion et révision ; les modifications sont auditées ; le retrait est gouverné. |
| Gouvernance | Aucune nécessaire — privée par construction. | Niveaux d'habilitation par page, scan de secrets à l'ingestion. | Complète : marquages d'accès, habilitation, récupération gouvernée, paquets d'audit. |
| Mise en place par | Personne — joignez un fichier et elle existe. | Les membres de l'espace de travail, via l'interface ou le Chat. | Les administrateurs d'organisation et les auteurs de packs, via l'SDK d'authoring. |
Quand utiliser laquelle
- Vous répondez à une question maintenant — joignez le fichier à la conversation. La KB privée à la conversation ne nécessite aucune configuration et ne fuit nulle part. Voir Chat → Bases de connaissances.
- Une équipe travaille régulièrement sur les mêmes documents — documents de projet, runbooks, transcriptions de réunions, historique du support d'un produit — créez une base de connaissances d'espace de travail. Les workflows, les agents et le Chat peuvent tous l'interroger, et les niveaux d'habilitation empêchent les utilisateurs non autorisés d'accéder aux pages sensibles.
- Toute l'organisation doit s'appuyer dessus — entités clients, faits de politique, apprentissages institutionnels validés — cela appartient à la KB d'organisation. Le contenu y est promu par un processus de révision, porte des marquages d'accès, et chaque lecture est gouvernée. Si vous devez livrer des connaissances avec un pack, c'est également la surface dans laquelle les packs s'installent.
Un schéma courant utilise les trois : une conversation révèle quelque chose qui vaut la peine d'être conservé → cela atterrit dans une KB d'espace de travail → après révision, les faits durables sont promus vers la KB d'organisation. La promotion est un flux intégré, pas un copier-coller.
Deux moteurs de récupération, et pourquoi
Les bases de connaissances d'espace de travail proposent deux moteurs au moment de la création :
| RAG | Memex | |
|---|---|---|
| Comment il récupère | Similarité vectorielle — vos documents sont intégrés et les requêtes correspondent par proximité sémantique. | Récupération textuelle déterministe multi-signal — correspondance exacte et sensible à la langue, suivi de liens de citation, et classement statistique. Sans embeddings. |
| Dépendance au modèle | Nécessite une intégration d'embedding ; les résultats varient si le modèle d'embedding change. | Aucune. Aucun appel de modèle à l'ingestion, aucun appel de modèle à la requête. Même requête, même corpus → même résultat, à chaque fois. |
| Points forts | Rappel sémantique flou — « trouver des choses à propos de cette idée » quand la formulation diffère complètement. | Matériel d'entreprise — documents, journaux de chat, PR, notes de réunions — où les noms, identifiants et citations portent le signal. |
| Auditabilité | Les scores de similarité dépendent du modèle et sont difficiles à expliquer à un auditeur. | Chaque résultat est explicable à partir du corpus seul — pourquoi une page est classée est inspecrable, reproductible et révisable. |
| Infrastructure | pgvector + un fournisseur d'embedding. | PostgreSQL uniquement. Processeur seul, sans GPU, compatible déploiement isolé d'internet. |
Memex incarne la même philosophie de conception que le reste de la plateforme — voir Pourquoi déterministe. Les LLMs sont utilisés là où le langage est le goulot d'étranglement (synthèse de réponse quand vous posez une question à une KB), pas pour décider ce qui est stocké ou ce qui est récupéré. Cela permet une ingestion gratuite (indexez un million de documents sans un seul appel de modèle), une récupération reproductible, et un chemin complet exécutable dans un cluster isolé d'internet.
Quel moteur choisir ? Optez par défaut pour Memex pour les collections de documents d'entreprise — c'est le moteur que nous évaluons, il ne nécessite aucune intégration d'embedding, et ses résultats sont auditables. Choisissez RAG quand vos requêtes ne partagent vraiment pas de vocabulaire avec vos documents et que vous avez une intégration d'embedding installée.
Comment nous évaluons — et comment nous nous comparons au marché
Les affirmations sur la qualité de la récupération sont faciles à formuler et difficiles à vérifier, c'est pourquoi nous mesurons les nôtres sur un benchmark public tiers : HERB (Heterogeneous Enterprise RAG Benchmark, Salesforce AI Research). HERB est conçu pour ressembler à la base de connaissances d'une vraie entreprise : documents, fils Slack, transcriptions de réunions, PR GitHub et URL, avec des questions multi-sauts dont les réponses sont dispersées dans différents types d'artefacts — y compris des pièges délibérés comme un renommage de produit en milieu d'historique.
Deux constats du papier cadrent le marché :
- Même les meilleurs systèmes RAG agentiques atteignent en moyenne ~33/100 sur HERB de bout en bout.
- La récupération — pas le LLM — est le goulot d'étranglement : les systèmes échouent parce qu'ils ne font jamais remonter les bonnes preuves, puis raisonnent avec confiance sur un contexte partiel.
Ce second constat explique pourquoi nous investissons en priorité dans la récupération. Voici comment les techniques standards du marché se comparent à la récupération Memex livrée par Scrydon — toutes mesurées par nos soins, sur le même échantillon HERB, avec le même harnais, les chiffres sont donc directement comparables (precision@5 : parmi les 5 premiers résultats, combien sont des artefacts que le benchmark indique comme nécessaires à la réponse) :
| Approche de récupération | precision@5 |
|---|---|
| Chevauchement de mots-clés naïf | 0,39 |
| Recherche plein texte standard en base de données (base de référence typique « utilisez simplement Postgres FTS ») | 0,44 |
| Récupération et reclassement avec un modèle cross-encoder (le schéma courant « ajouter un reranker » du marché) | 0,55 |
| Récupération Scrydon Memex (livrée) | 0,64 |
Le chemin livré surpasse le schéma de reranker cross-encoder sans utiliser le moindre modèle — sans embeddings, sans pod reranker, sans GPU, sans coût de modèle par requête, et avec un comportement identique dans un déploiement isolé d'internet. Les signaux de classement déterministes encodent ce que le reranker générique aurait dû deviner.
Le pipeline livré est également sensible à la structure : les pages qui citent le même lien, les messages appartenant au même fil de conversation, et les faits typés sur les pages de pull request (approuvé / fusionné / auteur) alimentent tous directement la récupération — ainsi une question comme « quelles PR n'ont pas été approuvées ? » ou une dont la réponse se trouve dans un fil de chat se résout via une structure que le scoring par mots-clés seul ne peut jamais exprimer. Sur le benchmark complet (30 produits, 38 600 artefacts, 815 questions), la prise en compte de la structure a augmenté la part des preuves nécessaires remontées dans le pool de candidats de 73 % en une seule version — toujours sans aucun appel de modèle.
Ce que nous affirmons et ce que nous n'affirmons pas
- Ce sont des scores de récupération — les bons artefacts ont-ils fait surface — pas des scores de bout en bout. La récupération est le goulot d'étranglement qu'identifie HERB, c'est pourquoi nous la mesurons directement.
- Le tableau comparatif est mesuré sur l'échantillon mono-produit du benchmark (17 questions multi-sauts sur 471 artefacts) ; traitez les écarts comme directionnellement solides, pas précis à la décimale. Nous exécutons également le benchmark complet (30 produits, 38 600 artefacts, 815 questions) en CI à chaque version et suivons les résultats par famille de questions, afin que les régressions sur n'importe quelle forme de corpus remontent avant d'être livrées.
- Les benchmarks concernent des entreprises fictives. Pour voir comment la récupération se comporte sur vos données, le Knowledge Health Report exécute le même harnais de mesure sur votre propre corpus et produit un rapport signé — précision de la récupération, taux de citation fondée, réutilisation des connaissances, déclin et couverture des facteurs bus. Contactez votre référent Scrydon pour en planifier un.
Voir aussi
- Chat → Bases de connaissances — connaissance de conversation et création de KBs depuis le Chat.
- Plateforme → Habilitation des bases de connaissances — niveaux d'habilitation sur les KBs d'espace de travail.
- SDK d'authoring → KB d'organisation — la surface de KB d'organisation gouvernée, les marquages et la promotion.
- Pourquoi déterministe — la philosophie de conception à l'échelle de la plateforme que suit la récupération Memex.