IA et gestion des connaissances¶

L'IA transforme la façon dont on cherche, capitalise et diffusé la connaissance — avec des risques nouveaux que les organisations techniques doivent maîtriser.

La rupture semantique¶

Pendant des decennies, la recherche dans une base documentaire fonctionnait par correspondance de mots-clés. Un utilisateur cherche "restart service", le moteur retourné les documents qui contiennent exactement ces termes. Si le runbook utilisé "redémarrer le service" ou "relancer le processus", il n'apparait pas. La connaissance existe — elle est juste introuvable.

Les modèles de langage et les techniques d'embedding ont change la donne. Il est désormais possible de représenter le sens d'un document dans un espace mathématique et de trouver des documents semantiquement proches d'une requête, indepedamment de la formulation exacte. Un utilisateur peut demander "comment faire répartir le composant quand il se bloque" et trouver le runbook intitule "Procédure de remédiation pod en crash loop".

Ce saut qualitatif ne résout pas tous les problèmes de KM — il en crée de nouveaux. Mais il ouvre des possibilites concrètes que les DSI progressives commencent à déployer : assistants de recherche interne, chatbots sur base documentaire, détection automatique de documentation obsolète.

Embeddings et recherche semantique¶

Le concept d'embedding¶

Un embedding est une représentation vectorielle d'un texte : un tableau de nombres (typiquement 768 a 4096 dimensions selon le modèle) qui encode le sens du texte dans un espace géométrique. La propriété centrale : deux textes semantiquement proches ont des vecteurs proches dans cet espace, même si leurs mots sont différents.

Le modèle word2vec (Google, 2013) a popularise l'idée pour les mots individuels. BERT (Google, 2018) l'a étendu aux phrases et paragraphes en prenant en compte le contexte. Les modèles d'embedding actuels (sentence-transformers, OpenAI ada-002, Cohere embed) sont optimises spécifiquement pour la recherche semantique.

Exemple concret : dans un espace d'embedding bien entraîné, les phrases suivantes ont des vecteurs proches :

• "Le pod est en crash loop backoff"
• "Le conteneur redémarrage en boucle"
• "CrashLoopBackOff sur le service auth"

Elles sont semantiquement équivalentes et se retrouveront toutes si l'utilisateur cherche l'une d'elles.

Vectorisation de documents¶

Pour rendre une base documentaire searchable par embeddings :

flowchart LR
    A[Documents\nMarkdown, PDF, Confluence] --> B[Chunking\nDecoupage en segments]
    B --> C[Embedding\nModele encodeur]
    C --> D[Index vectoriel\nFAISS, pgvector, Pinecone]
    D --> E[Base indexee]

    F[Requete\nutilisateur] --> G[Embedding\nde la requete]
    G --> H[Recherche\npar similarite]
    H --> D
    H --> I[Top-K documents\npertinents]

Chunking — les documents sont decoupes en segments de taille fixe ou semantique. Taille typique : 256 a 1024 tokens par chunk, avec un overlap de 10 a 20% pour éviter de couper une idée en plein milieu.

Embedding — chaque chunk est transforme en vecteur par le modèle. Cette étape est coûteuse (temps CPU/GPU, coût API) mais se fait une seule fois lors de l'indexation.

Index vectoriel — les vecteurs sont stockes dans une base de données vectorielle (pgvector pour PostgreSQL, FAISS en mémoire, Pinecone ou Weaviate en SaaS) qui permet une recherche des plus proches voisins très efficace.

Similarite cosinus¶

La mesure de distance standard entre deux vecteurs d'embedding est la similarite cosinus : elle mesure l'angle entre deux vecteurs, independamment de leur magnitude.

similarity(A, B) = (A · B) / (||A|| × ||B||)

Resultat entre -1 et 1 :
  1 = vecteurs identiques (meme sens)
  0 = vecteurs orthogonaux (sens non correles)
 -1 = vecteurs opposes (sens contraire)

En pratique, les scores de similarite semantique pertinents se situent entre 0.7 et 0.95. Un seuil a 0.75 est souvent un bon point de départ pour filtrer les résultats non pertinents.

RAG : Retrieval-Augmented Génération¶

Principe et architecture¶

Le RAG (Retrieval-Augmented Génération, Lewis et al., 2020) est l'architecture dominante pour les assistants IA sur base documentaire. Plutôt que de reposer uniquement sur ce que le LLM a appris pendant son entrainement, le RAG récupéré dynamiquement des documents pertinents et les fournit au modèle comme contexte pour générer sa réponse.

sequenceDiagram
    participant U as Utilisateur
    participant S as Systeme RAG
    participant I as Index vectoriel
    participant L as LLM

    U->>S: Question en langage naturel
    S->>S: Embedding de la question
    S->>I: Recherche top-K documents pertinents
    I-->>S: K chunks pertinents + metadonnees
    S->>L: Prompt = contexte (chunks) + question
    L-->>S: Reponse generee ancree dans les sources
    S-->>U: Reponse + references aux sources

L'avantage fondamental du RAG sur un LLM nu : la réponse est ancrée dans les documents de l'organisation. Le modèle ne "invente" pas — il synthetise ce que les documents disent. Les sources sont citables et verifiables.

Chunking : l'art du découpage¶

La qualité du chunking conditionne la qualité du retrieval. Un chunk trop petit perd le contexte. Un chunk trop grand noie la requête dans du bruit.

L'overlap (chevauchement) entre chunks evite de couper une information importante en deux : les derniers tokens du chunk N sont répétés au début du chunk N+1.

Metadata filtering¶

Les metadonnees enrichissent le retrieval et permettent de filtrer les résultats avant la recherche vectorielle. Un chunk bien annote inclut :

{
  "text": "Pour redemarrer le service auth en production...",
  "metadata": {
    "source": "runbooks/auth-service.md",
    "type": "runbook",
    "service": "auth",
    "environment": "production",
    "last_updated": "2024-03-15",
    "author": "sre-team",
    "severity": "operational"
  }
}

Un utilisateur qui filtre explicitement ("runbooks pour le service auth en production") peut prefiltrer par metadonnee avant la recherche vectorielle — reduisant le bruit et ameliorant la précision.

Évaluation d'un pipeline RAG¶

Trois métriques fondamentales pour évaluer un RAG :

Faithfulness — la réponse est-elle fidele aux documents sources ? Mesure le taux d'hallucination (affirmations non supportees par les sources).

Answer Relevance — la réponse répond-elle vraiment à la question posee ?

Context Relevance — les chunks recuperes etaient-ils pertinents pour la question ?

Des frameworks comme RAGAS (open source) permettent l'évaluation automatique de ces trois dimensions sur un jeu de test.

Assistants internes sur base documentaire¶

Cas d'usage concrets pour une DSI¶

Les assistants IA internes trouvent leur plus forte valeur sur les usages ou la connaissance est fragmentee, souvent consulted en urgence, et ou la formulation de la question varie.

Intégration Slack et Teams¶

L'intégration dans les outils de communication réduit la friction d'utilisation. L'assistant est là où les équipes travaillent, sans changer d'outil.

Architecture typique d'un bot Slack sur RAG :

/doc <question> → Bot RAG → Reponse + lien source

Ou via mention directe dans un thread :

@knowledge-bot comment on deploy le service payment en staging ?

Le bot répond dans le thread, cite les sources, et propose des documents connexes. Toutes les interactions sont loggees pour améliorer l'index (les questions sans bonne réponse identifient des lacunes documentaires).

Conditions de succès d'un assistant interne¶

Un assistant IA sur base documentaire n'est pas un projet technique — c'est un projet de gestion des connaissances avec une interface IA. Les conditions de succès :

1. Base documentaire de qualité — garbage in, garbage out. Un assistant sur une documentation inexacte produit des réponses inexactes avec l'apparence de la certitude.
2. Périmètre clairement défini — l'assistant répond sur un domaine précisé. Un assistant "omniscient" sur toute l'entreprise dilue la qualité et multiplie les hallucinations.
3. Sources citees systematiquement — chaque réponse doit pointer vers les documents sources pour que l'utilisateur puisse vérifier.
4. Fallback explicite — si l'assistant ne trouve pas de réponse pertinente (score de similarite trop bas), il doit le dire clairement et rediriger vers un expert humain.
5. Boucle de feedback — les utilisateurs doivent pouvoir noter la réponse (utile/pas utile) pour améliorer le système.

Fine-tuning vs RAG¶

Deux approches pour specialiser un LLM¶

Pour adapter un LLM général a un domaine spécifique, deux grandes approches s'opposent :

Fine-tuning — on reentrainer le modèle sur un corpus spécifique à l'organisation. Le modèle intégré la connaissance dans ses poids. Il "sait" les choses sans avoir besoin de les récupérer.

RAG — le modèle général récupéré dynamiquement les informations pertinentes au moment de la requête. La connaissance reste dans les documents, pas dans le modèle.

Quand utiliser quoi¶

Le fine-tuning est justifie quand :

• Le style et le format des réponses doit être très spécifique (ex: génération de code dans un framework interne)
• La latence est critique et l'étape de retrieval trop coûteuse
• La connaissance est stable et ne change pas souvent

Le RAG est justifie quand :

• La documentation évolue fréquemment (runbooks, ADR, procédures)
• Les sources doivent être citables et verifiables
• Le budget GPU pour le fine-tuning n'est pas disponible
• La transparence et la traçabilité sont des exigences (compliance, sécurité)

Pour la grande majorité des cas d'usage KM en DSI, le RAG est la bonne architecture par défaut.

Risques et limites¶

Hallucinations¶

Le risque le plus critique des LLM pour les usages KM est l'hallucination : le modèle généré des affirmations plausibles mais fausses, avec la même apparence de confiance que des affirmations vraies.

Dans un contexte de KM technique, les hallucinations sont particulièrement dangereuses :

• Un runbook hallucine peut conduire a une mauvaise manipulation en production
• Une procédure de sécurité inventee peut créer une vulnérabilité
• Un ADR fabrique peut embrouiller la comprehension de l'architecture

Les hallucinations dans un pipeline RAG proviennent de plusieurs sources :

Contexte insuffisant — les chunks recuperes ne contiennent pas l'information pour répondre, mais le modèle "complète" avec ses connaissances générales potentiellement incorrectes dans ce contexte spécifique.

Contradiction dans les sources — plusieurs documents disent des choses contradictoires (documentation obsolète vs. actuelle). Le modèle synthetise une réponse intermédiaire cohérente mais inexacte.

Dépassement du contexte — la question dépassé le périmètre de l'index. Le modèle n'a pas de "je ne sais pas" naturel.

Mitigation : seuillage strict de la similarite (rejeter si score < 0.70), prompt system explicite ("reponds uniquement à partir des documents fournis, si l'information n'est pas disponible, dis-le explicitement"), citation obligatoire des sources, validation humaine pour les réponses opérationnelles critiques.

Obsolescence des embeddings¶

Les embeddings sont calcules au moment de l'indexation. Si un document est mis à jour, son embedding devient obsolète jusqu'à la re-indexation. Un pipeline RAG sans politique de re-indexation régulière dégradé progressivement en qualité.

Stratégies :

• Re-indexation complète périodique (hebdomadaire ou mensuelle selon la fréquence de mise à jour)
• Re-indexation incrementale déclenchée par les modifications de fichiers (webhook Git, modification Confluence)
• Traçabilité de la date d'indexation dans les metadonnees pour détecter les chunks stales

Biais et confidentialite¶

Biais — les modèles d'embedding et les LLM heritent de biais de leur entrainement. Dans un contexte RH ou communication interne, cela peut produire des biais systematiques difficiles a détecter.

Confidentialite — indexer de la documentation interne et l'envoyer a une API cloud (OpenAI, Cohere) souleve des questions de confidentialite des données. Trois approches :

• Modèles et infrastructure on-premise (Ollama + modèle open source, pgvector local)
• Filtrage des données sensibles avant indexation
• Accords de traitement des données avec le fournisseur cloud (DPA, clauses RGPD)

Coût énergétique¶

Générer un embedding et appeler un LLM a un coût énergétique non negligeable. À l'échelle d'une organisation avec des milliers de requêtes quotidiennes, ce coût peut être significatif. La mise en cache des réponses aux questions fréquentes, le choix de modèles adaptés au besoin (pas besoin de GPT-4 pour une FAQ basique), et le monitoring des coûts API sont des pratiques nécessaires.

Gouvernance de l'IA dans le KM¶

Validation humaine : le circuit de confiance¶

L'IA ne peut pas être la seule source de vérité sur des connaissances opérationnelles critiques. Une architecture de gouvernance saine distingue :

Connaissances validees humainement — runbooks, procédures de sécurité, ADR, guides d'architecture. Ces documents sont authoritaires. L'IA peut les retrouver et les citer, mais ne peut pas les modifier sans intervention humaine.

Connaissances générées par IA — suggestions de documentation, eboches de runbooks, synthèses de post-mortems. Ces documents sont des propositions qui necessitent une revue et une validation avant de rejoindre la base authoritative.

Réponses générées à la volee — les réponses de l'assistant en temps réel. Elles sont informatives mais non authoritative. Les utilisateurs doivent être formes a vérifier les informations critiques dans les sources primaires.

Sources de vérité et hierarchy documentaire¶

Un système KM augmente par l'IA doit avoir une hierarchy claire de sources de vérité :

graph TD
    N1["Niveau 1<br/>Authoritative<br/>(validation humaine requise)"]
    N1 --> ADR["ADR<br/>(Architecture Decision Records)"]
    N1 --> RB["Runbooks valides"]
    N1 --> PSEC["Procedures de securite"]
    N1 --> POL["Politiques et standards"]

    N2["Niveau 2<br/>Reference<br/>(mise a jour par equipes responsables)"]
    N2 --> DARCH["Documentation d'architecture"]
    N2 --> README["README et guides de setup"]
    N2 --> FAQ["FAQ techniques"]

    N3["Niveau 3<br/>Contributif<br/>(contenu equipe, moins formal)"]
    N3 --> PM["Notes de post-mortems"]
    N3 --> SPR["Notes de sprint review"]
    N3 --> TIPS["Tips and tricks equipe"]

    N4["Niveau 4<br/>Ephemere<br/>(genere par IA, non stocke)"]
    N4 --> RESP["Reponses de l'assistant<br/>en temps reel"]

L'index RAG peut inclure tous les niveaux, mais les metadonnees doivent encoder le niveau d'authorite pour que l'assistant puisse ponderer ses sources et signaler quand une réponse vient d'un document contributif plutôt qu'authoritative.

Feedback loop et amélioration continue¶

Un assistant IA sur base documentaire s'amélioré si on lui fournit des signaux de feedback :

flowchart TD
    A[Question utilisateur] --> B[Reponse assistant]
    B --> C{Feedback\nutilisateur}
    C -->|Utile| D[Signal positif\nloggue]
    C -->|Pas utile| E[Signal negatif\n+ raison]
    E --> F{Analyse}
    F -->|Doc manquante| G[Creation\ndocumentation]
    F -->|Doc obsolete| H[Mise a jour\ndocumentation]
    F -->|Hallucination| I[Amelioration\nprompt / seuils]
    G --> J[Re-indexation]
    H --> J
    I --> B
    J --> B

Les questions sans bonne réponse sont les plus precieuses : elles identifient des lacunes documentaires que personne n'avait explicitement détectées. Un log hebdomadaire des questions à faible score de similarite est un outil de priorisation KM très efficace.

Mise à jour des index¶

La politique de mise à jour des index vectoriels doit être formalisée et automatisee :

Checklist de gouvernance IA pour le KM¶

Avant de déployer un assistant IA sur base documentaire en production :

• Périmètre documentaire défini et indexe
• Politique de confidentialite des données établie (on-premise vs cloud, DPA signe)
• Seuils de similarite calibres sur un jeu de test representatif
• Comportement "je ne sais pas" teste et valide
• Citations de sources systematiques dans les réponses
• Système de feedback utilisateur en place
• Pipeline de re-indexation automatise et monitore
• Formation des utilisateurs aux limites du système (hallucinations)
• Processus de validation humaine pour les réponses opérationnelles critiques
• Monitoring des coûts API et des performances du pipeline
• Processus d'amélioration continue base sur les feedbacks
• Revue trimestrielle de la qualité des réponses (évaluation sur jeu de test)