Passer au contenu principal

Fonction principale : Collections RAG analysées

Les espaces de travail Paradigm sont conçus pour organiser et rendre accessibles tous les types de documentation non structurée à l’aide d’une architecture de collection RAG (Retrieval-Augmented Generation) analysée.
Rappel importantLa description de l’espace de travail dans Paradigm n’ est actuellement pas utilisée par le système RAG. Elle sert uniquement de documentation pour les administrateurs. Le système RAG s’appuie uniquement sur le contenu des documents eux-mêmes.

Qu’est-ce qu’une collection RAG analysée ?

Chaque espace de travail contient une collection qui :
  • analyse automatiquement les documents téléchargés, quel que soit leur format (PDF, DOCX, XLSX, images, etc.)
  • extrait et structure le contenu non structuré pour le rendre compréhensible par l’IA
  • Génère des embeddings pour une recherche sémantique avancée
  • Contextualise les réponses en fonction de tous les documents de l’espace de travail.
Avantage cléGrâce à l’analyse RAG, Paradigm peut comprendre et interroger n’importe quelle documentation technique, commerciale, juridique ou opérationnelle, même si elle est hétérogène et non structurée. Le système transforme automatiquement vos documents en une base de connaissances interrogeable.
Note: La description de l’espace de travail n’ est actuellement pas utilisée par le système et sert uniquement de documentation pour les administrateurs.

Types de documentation pris en charge

Les collections RAG peuvent analyser et inclure
  • Documentation technique: spécifications, documentation sur les API, architecture, code.
  • Documents commerciaux: procédures, guides, formations, playbooks
  • Ressources juridiques: Contrats, NDA, politiques, conformité
  • Données client: Spécifications, livrables, communications
  • Connaissances diverses: Wikis, notes, présentations, feuilles de calcul

Stratégies d’organisation

Approche recommandée : Organisation par domaine de connaissances

Puisque les espaces de travail fonctionnent comme des collections de RAG, organisez-les par domaine de connaissance cohérent plutôt que par structure organisationnelle :
Exemples of optimal workspace organization :

By technical field :
"Engineering - Platform Architecture"
"Engineering - API Documentation"
"Engineering - DevOps & Infrastructure"

By business area :
"Product - User Research & Insights"
"Product - Product Specifications"
"Sales - Sales Playbooks & Methodologies"

By regulatory area :
"Compliance - GDPR Documentation"
"Compliance - SOC2 Evidence"
"Legal - Contracts & Agreements"

Avoid (too generic) :
"Documents"
"Fichiers 2025"
"Misc"

Principe de cohérence thématique

Pourquoi c’est important: Les RAG fonctionnent mieux lorsque les documents d’un même espace de travail sont thématiquement liés. Cela permet :
  1. Une meilleure contextualisation: L’IA comprend mieux les relations entre des documents similaires
  2. Des réponses plus précises: La recherche sémantique est plus efficace dans un corpus cohérent.
  3. Moins de bruit: Évite les résultats non pertinents provenant de différents domaines.
Règle générale: si vous demandez “Ces documents seront-ils interrogés ensemble dans le même contexte ?”, ils doivent se trouver dans le même espace de travail.

Exemples par type d’organisation

▶1**. Organisation par projet (avec cohérence thématique)**

Engineering Team
  ├─ Project Phoenix - Technical Docs
  │  └─ Architecture, specs, API docs, test plans
  ├─ Project Phoenix - User Documentation
  │  └─ User guides, tutorials, FAQs
  └─ Infrastructure - Runbooks
     └─ Procedures, configurations, monitoring

Quand utiliser: Grands projets avec une documentation volumineuse et différents types de public.

▶2. Organisation par domaine fonctionnel

Product Organization
  ├─ Product Requirements
  │  └─ PRDs, specs, roadmaps
  ├─ User Research
  │  └─ Interviews, personas, insights
  ├─ Design System
  │  └─ Components, guidelines, patterns
  └─ Analytics & Metrics
     └─ Dashboards, reports, KPIs

Quand utiliser: Équipes ayant des domaines d’expertise distincts et une documentation spécialisée.

▶3. Organisation hybride (recommandée)

Company Knowledge Base
  ├─ Technical - Backend APIs (domaine)
  ├─ Technical - Frontend Components (domaine)
  ├─ Project Phoenix - All Docs (projet)
  ├─ Customer Success - Playbooks (domaine)
  ├─ Sales - Methodologies (domaine)
  └─ Compliance - All Documentation (domaine)

Avantages: Combine la flexibilité du projet avec la cohérence du domaine thématique

Bonnes pratiques de dénomination

Format recommandé

[Domain] - [Subdomain or Content Type]

Exemples

Excellent naming (descriptive and thematic) :
"Engineering - Platform API Documentation"
"Product - Feature Specifications"
"Sales - Enterprise Playbooks"
"Compliance - Security Policies"
"Customer Success - Implementation Guides"

Good naming (clear and consistent) :
"Technical Documentation - Backend"
"User Research 2025"
"Legal - Vendor Contracts"

À éviter (trop vagues pour une recherche efficace) :
"Documents"
"Workspace 1"
"Misc Files"
"Archive"
"tmp"


Taille et nombre d’espaces de travail

Recommandations

Organisation de la tailleNombre d’espaces de travailPrincipe
Petite équipe (< 10)3-5 espaces de travailPar grande zone
Équipe moyenne (10-50)5-15 espaces de travailPar zone et sous-zone
Grande organisation (> 50)10-30 espaces de travailPar domaine, équipe et projet

Quand créer un nouvel espace de travail

Create a workspace when:
The topic area is distinct
The documents will not be searched together
The members/permissions are different
The content requires isolation (confidentiality)

Do not create a workspace if:
It is just to "organize" similar documents
The same people access it
The documents are thematically related
A simple tag/folder would suffice


Cas d’utilisation pratiques

1. Documentation cohérente pour plusieurs projets

Scénario: Plusieurs projets partageant la même pile technique Solution:
Engineering
  └─ Backend API Documentation (single workspace)
     ├─ Common patterns (files)
     ├─ Project A APIs (files)
     ├─ Project B APIs (files)
     └─ Project C APIs (files)

Avantage du RAG: Le système peut répondre à des modèles communs en s’appuyant sur tous les projets.

2. Base de connaissances du client

Scénario: Agence gérant plusieurs clients Solution:
Client Services
  ├─ Client A - All Documentation
  │  └─ Contracts, deliverables, communications
  ├─ Client B - All Documentation
  │  └─ Contracts, deliverables, communications
  └─ Internal - Service Methodologies
     └─ Processes, templates, best practices

Avantage du RAG: Isolation parfaite par client + méthodologies réutilisables

3. Documentation de conformité

Scénario: Exigences réglementaires multiples Solution:
Compliance
  ├─ GDPR - Complete Documentation
  │  └─ Policies, audits, DPIAs, procedures
  ├─ SOC2 - Evidence & Controls
  │  └─ Controls, tests, reports, evidence
  └─ ISO 27001 - Documentation
     └─ Policies, procedures, audits

RAG Avantage: Recherche précise par cadre réglementaire

4. Embarquement et formation

Scénario: Documentation de formation par rôle Solution:
HR - Learning & Development
  ├─ Engineering Onboarding
  │  └─ Setup guides, tech stack, processes
  ├─ Sales Onboarding
  │  └─ Product training, methodologies, tools
  └─ General Company Onboarding
     └─ Culture, policies, benefits, tools

RAG Advantage: Réponses personnalisées en fonction du rôle de l’utilisateur

Cycle de vie de l’espace de travail

Création d’un espace de travail

  1. Définir un domaine de connaissances clair et cohérent
  2. Identifier les membres travaillant dans ce domaine
  3. Créer un nom descriptif pour le contenu thématique
  4. Documenter l’objectif (même s’il n’est pas utilisé par le système, utile pour les administrateurs)
  5. Commencer à télécharger ou à synchroniser avec la source de données les documents liés à la thématique.

Entretien

  1. Réviser les membres: Tous les trimestres pour les espaces de travail standard
  2. Contrôler la cohérence: S’assurer que les nouveaux documents restent liés thématiquement
  3. Nettoyer régulièrement: Supprimer les documents obsolètes pour améliorer la qualité du RAG
  4. Vérifier l’utilisation: Identifier les espaces de travail sous-utilisés

Désintégration

  1. Inactiver un utilisateur
  2. Supprimer l’adhésion de l’utilisateur à tous ses espaces de travail personnalisés.
  3. Transférer la propriété des espaces de travail si nécessaire

Audit et traçabilité

Événements de l’espace de travail:

  • Création
  • Modification (nom, description)
  • Ajout/suppression de membres
  • Suppression

Événements relatifs aux documents:

  • Téléchargement
  • Consultation via des outils (docsearh, etc.)
  • Supprimer

Evénements liés à l’accès:

  • Tentatives d’accès refusées
  • Changements de permissions
  • Exportation de données