Re-indexation incrémentale et webhooks
Re-indexation incrémentale et webhooks
Mettre à jour uniquement le contenu modifié et garder votre recherche RAG précise
Gardez l’index de recherche à jour automatiquement lorsque votre dépôt change — ou lancez une re-indexation ciblée quand vous le souhaitez.
Ce que couvre cette page
Re-indexation ciblée
Ne réindexez que les éléments modifiés de vos sources pour gagner du temps et des crédits.
Déclenchement par webhooks
Les pushs sur votre dépôt déclenchent automatiquement une mise à jour incrémentale de l’index.
Sync résilient vers Milvus
Les opérations vers la base vectorielle respectent des limites de débit et une politique de retry avec backoff.
Gestion des suppressions
Les éléments supprimés sont retirés proprement de l’index pour éviter le bruit dans les résultats.
Contrôle et journaux
Suivez l’état des synchronisations et consultez les logs d’activité depuis l’interface projet.
Modes automatique & manuel
Choix entre re-indexation automatique par webhook et resync manuel (ex. pour commits historiques).
Astuce — limiter le bruit
Si votre dépôt contient des répertoires volumineux (binaires, assets), excluez-les des triggers ou des filtres de hook pour concentrer la re-indexation sur le contenu utile à la recherche.
Introduction
Cette page explique comment la re-indexation incrémentale fonctionne lorsque des changements surviennent dans vos sources (commits / push). Vous apprendrez comment activer et contrôler les webhooks, ce qui se passe lorsque le système reçoit un événement de push, comment la synchronisation vers la base vectorielle est gérée (respect des limites de débit, retries), et comment intervenir manuellement si nécessaire. Les instructions sont orientées utilisateur : que faire depuis l’interface, quelles vérifications réaliser, et quelles bonnes pratiques suivre.
Workflow 1 — Activer un webhook pour votre dépôt (configuration initiale)
Étape 1 — Vérifier l’accès au dépôt
Assurez-vous que votre projet est connecté au service d’hébergement (compte autorisé ou application installée). L’interface projet vous indiquera si l’authentification est valide.
Étape 2 — Créer ou activer le webhook depuis l’interface
Dans la page de gestion des sources du projet, choisissez le dépôt et demandez la création du webhook. L’outil proposera de générer un secret signé et enregistrera l’intégration côté projet.
Étape 3 — Valider le webhook côté hébergeur
Depuis l’interface du fournisseur (ex. GitHub/GitLab), vérifiez que le webhook est présent et qu’il retourne des livraisons réussies (200). En cas d’erreur, relancez la création depuis votre projet.
Étape 4 — Définir les filtres (optionnel) pour réduire la portée
Si vous ne souhaitez indexer que certains types de modifications (par exemple dossier docs/ ou branches spécifiques), configurez les filtres de trigger dans le hook pour éviter des re-indexations inutiles.
Étape 5 — Tester le déclencheur
Effectuez un petit commit test sur une branche choisie. Dans l’interface projet, observez que la tâche de re-indexation démarre et suivez sa progression via la section “jobs” ou “progress”.
Astuce — utiliser un secret de webhook
Conservez le secret signé généré par l’interface du projet. Il permet de vérifier l’authenticité des événements et réduit les faux déclenchements.
Workflow 2 — Que se passe-t-il après un push (re-indexation incrémentale)
Étape 1 — Réception de l’événement
Le système reçoit l’événement de push et détermine la liste des éléments modifiés (ajouts, modifications, suppressions) pour ce push.
Étape 2 — Suppression des entrées obsolètes
Pour chaque élément marqué comme supprimé, l’entrée correspondante est retirée de l’index de recherche vectorielle afin d’éviter des résultats erronés.
Étape 3 — Récupération du contenu modifié
Le contenu des éléments modifiés est récupéré depuis le dépôt pour être évalué et préparé à l’indexation. Les éléments vides ou non pertinents sont ignorés.
Étape 4 — Découpage et création d’embeddings
Le contenu est découpé en morceaux adaptés, puis converti en vecteurs. Chaque morceau conserve un lien vers son origine pour retrouver le contexte en recherche RAG.
Étape 5 — Insertion dans la base vectorielle (Milvus) avec résilience
Les vecteurs sont insérés dans la base vectorielle. Ces opérations respectent des limites de débit et une stratégie de retry : quand la plateforme limite les requêtes, les insertions sont mises en file d’attente et réessayées avec backoff.
Étape 6 — Mise à jour de l’index interne et du contexte global
L’index manifest côté projet est mis à jour pour faire correspondre les nouveaux vecteurs et métadonnées. Si nécessaire, les embeddings globaux (contexte) sont recalculés pour garder la cohérence des recherches.
Étape 7 — Notification & logs
Vous recevez un retour dans l’interface projet (progress, logs, résultats) et les éventuelles destinations configurées (email, webhook externe) peuvent être notifiées.
Attention — limitations à connaître
Les opérations vers la base vectorielle peuvent être ralenties par des limites de débit externes. En cas de gros pushs simultanés, la mise à jour peut être mise en file d’attente et traitée progressivement. Ne paniquez pas si la synchro n’apparaît pas immédiatement.
Workflow 3 — Gestion des erreurs et procédures de secours (retry & monitoring)
Étape 1 — Consulter les livraisons webhook
Si une re-indexation semble avoir échoué, commencez par vérifier les livraisons du webhook dans le fournisseur (erreurs, codes de retour, messages).
Étape 2 — Voir les logs et le statut dans l’interface projet
Ouvrez la section “jobs” ou “progress” du projet pour lire les erreurs remontées et le nombre de tentatives. Les erreurs temporaires liées à des limites seront souvent suivies de tentatives automatiques.
Étape 3 — Relancer la re-indexation ciblée
Si nécessaire, lancez manuellement une re-indexation ciblée pour les éléments affectés (option disponible dans l’interface : “resync” ou “ré-indexer les changements récents”).
Étape 4 — Reconnexion / réautorisation
Si les erreurs d’accès persistent (jeton expiré, droits insuffisants), reconnectez ou autorisez à nouveau le dépôt via la configuration du projet.
Étape 5 — Contact & support
Si le problème persiste malgré les retries et relances, exportez les logs d’erreur visibles depuis l’interface et contactez l’assistance en joignant ces informations.
Astuce — resync planifié en dehors des heures de pointe
Pour de très gros dépôts, planifiez les resyncs ou les tests de ré-indexation en dehors des heures de travail afin d’éviter les pics de trafic et limiter les impacts sur les limites de débit.
- Idéal pour la plupart des projets : chaque push déclenche une mise à jour incrémentale.
- Avantages : faible latence, consommation optimisée (seules les modifications sont traitées), intégration continue de la recherche RAG.
- À surveiller : filtres de hook pour éviter d’indexer les changements non pertinents.
Avant : index obsolète
- Résultats de recherche incohérents.
- Réponses RAG qui pointent vers du contenu supprimé ou périmé.
- Génération de résumés basée sur un contexte incomplet.
Après : re-indexation incrémentale
- Seules les modifications sont traitées, gain de temps et crédits.
- Suppressions retirées immédiatement de l’index.
- Contexte global mis à jour pour améliorer la pertinence des réponses RAG.
Limites opérationnelles courantes
- Les éléments très volumineux peuvent être découpés ou partiellement indexés pour respecter des contraintes de taille et de tokens.
- Les opérations simultanées peuvent être séquencées : attendez la fin des jobs en cours avant de lancer un resync massif.
Workflow 4 — Bonnes pratiques opérationnelles (checklist)
Étape 1 — Définir des filtres pertinents
Excluez les répertoires et types non pertinents (assets, binaires, gros logs) directement via la configuration du hook ou des règles de source.
Étape 2 — Protéger l’accès
Conservez le secret de webhook et gardez vos autorisations à jour (réautorisation après rotation de clés).
Étape 3 — Monitorer les jobs
Surveillez régulièrement la file d’attente et les logs dans l’interface projet. Mettez en place des notifications si nécessaire.
Étape 4 — Planifier les gros resyncs
Programmez les resyncs lourds en période creuse et découpez-les en lots si possible.
Étape 5 — Tester les filtres sur un petit périmètre
Avant d’appliquer des filtres globaux, testez-les sur une branche ou un dossier restreint pour valider le comportement.
Astuce — limiter les coûts et le temps
Activez les filtres de chemin et les limites de taille pour réduire le nombre de morceaux à vectoriser. Moins de vecteurs = coût et latence réduits.
Questions fréquentes — Re-indexation incrémentale et webhooks
Résumé pratique
- Activez un webhook pour que chaque push déclenche une re-indexation ciblée.
- Le flux supprime les entrées obsolètes, récupère le contenu modifié, génère des vecteurs et les synchronise vers la base vectorielle en respectant les limites de débit et une politique de retry.
- Utilisez les filtres et la planification pour optimiser coûts et latence.
- En cas d’échec, consultez les logs, vérifiez l’accès et relancez une synchronisation manuelle si nécessaire.
Prêt à mettre en place la re-indexation incrémentale ?
Ouvrez la page de votre projet pour créer ou vérifier vos webhooks, ajuster les filtres et lancer un resync de test.