RAG sync manuel et recherche vectorielle
RAG sync manuel et recherche vectorielle
Mode d'emploi complet pour synchroniser vos commits et interroger Milvus depuis les agents
Pilotez manuellement la synchronisation RAG, comprenez ce que fait le service en arrière‑plan et apprenez à interroger la base vectorielle par texte depuis vos agents.
Ce que couvre cette page
Synchroniser les vecteurs vers Milvus
Comment les documents modifiés sont transformés en vecteurs et stockés dans Milvus, avec bonnes pratiques et limites.
Lancer manuellement un RAG sync
Procédure pas à pas depuis l’interface : ouvrir un repo, cliquer sur RAG sync, suivi de l’opération.
Interroger Milvus par texte via les agents
Guide pour configurer un step d’agent qui fait une recherche vectorielle textuelle et intègre les résultats au prompt.
Visibilité & suivi
Où regarder le statut, comment interpréter les logs et les scores de similarité.
Conseils coûts & quotas
Impact des embeddings sur le crédit du projet, rate limits et stratégie de retry.
Scénarios avancés
Gestions des grands dépôts, re‑authentification, filtres et mises à jour partielles.
Introduction Cette page explique, pour un utilisateur non‑technique, comment lancer un RAG sync manuel depuis l’interface, ce que le service effectue ensuite pour récupérer les commits et mettre l’index à jour, et comment un agent peut interroger Milvus par texte pour effectuer une recherche vectorielle. Vous trouverez des instructions pas à pas, des bonnes pratiques, des pièges à éviter et des cas avancés.
Workflow 1 — Lancer un RAG sync manuel depuis l'interface
Étape 1 — Ouvrir votre projet et accéder aux dépôts
Dans le tableau de bord, sélectionnez le projet concerné puis rendez‑vous dans l’onglet “Repositories” (ou “Repos”). Vous verrez la liste des dépôts connectés à ce projet.
Étape 2 — Vérifier l'état du token
Avant de lancer le sync, regardez l’icône d’état du token du dépôt (vert/orange/rouge). Si le token est expiré ou nécessite ré‑authentification, suivez la procédure de ré‑authentification avant de continuer.
Étape 3 — Choisir la branche de synchronisation
Si vous avez configuré une branche de sync spécifique, vérifiez qu’elle est correcte. Sinon, le système utilisera la branche par défaut fournie par le fournisseur (GitHub/GitLab).
Étape 4 — Lancer le RAG sync
Ouvrez la carte du dépôt et cliquez sur le bouton “RAG sync” (ou l’action équivalente). Après clic, vous recevrez un retour immédiat (notification/Toast) indiquant que la synchronisation a été lancée.
Étape 5 — Suivre la progression
La synchronisation est traitée en arrière‑plan : consultez la section de progression du projet ou les logs de génération pour voir l’état des jobs. Le temps varie selon la taille du dépôt et les quotas.
Étape 6 — Vérifier les résultats
Quand le job est marqué comme terminé, vérifiez : nombre de commits traités, nouveaux documents indexés, et éventuels messages d’erreur. Si nécessaire, relancez un sync partiel ou complet.
Étape 7 — En cas d'erreur
Si la sync échoue, contrôlez l’état du token, les limites de rate (quotas) et les notifications. Relancez après avoir corrigé les problèmes (ré‑auth, réduire la fenêtre temporelle, etc.).
Tip — lancer une sync ciblée pour gagner du temps
Pour les gros dépôts, privilégiez une fenêtre temporelle courte (par ex. derniers 7–30 jours) ou sélectionnez une branche spécifique afin de réduire le temps de traitement et la consommation d’embeddings.
Tip — prioriser les fichiers importants
Si vous traitez beaucoup de fichiers, appliquez des filtres (types de fichiers ou répertoires) dans la configuration de votre projet/agent pour indexer en priorité les contenus pertinents (docs README, fichiers de doc, modules clés).
Attention — opérations asynchrones, rate limits et coûts
L’indexation est asynchrone et traitée par des workers ; la durée dépend de la taille du dépôt et des quotas de rate‑limit. Les opérations d’insertion et de recherche vers Milvus respectent des limites et une politique de retry. La création d’embeddings consomme des crédits du projet — surveillez votre consommation.
Section — Que fait le service en arrière‑plan ? Avant de lancer la prochaine série d’actions depuis l’interface, il est utile de comprendre ce qui se passe « derrière ».
Workflow 2 — Traitement en arrière‑plan : récupération des commits et mise à jour de l'index
Étape 1 — Validation et préparation
Le système vérifie que le dépôt est accessible (token valide, droits de lecture) et détermine la branche effective à synchroniser (soit la branche configurée, soit la branche par défaut fournie par le fournisseur).
Étape 2 — Collecte des commits récents
Il récupère les commits récents dans la fenêtre temporelle définie (par ex. les 30 derniers jours) et identifie les fichiers modifiés entre les versions (diffs).
Étape 3 — Extraction des fichiers et découpage
Les fichiers modifiés sont récupérés, nettoyés et découpés en passages ou « chunks » adaptés pour la recherche sémantique (taille de passage, overlap).
Étape 4 — Création des embeddings
Chaque passage est transformé en vecteur d’embedding. Cette étape consomme des crédits parce qu’elle fait appel au service d’embeddings.
Étape 5 — Insertion dans la base vectorielle
Les vecteurs, avec leur méta‑donnée (source, type, index chunk), sont insérés dans la collection Milvus du projet. Les opérations suivent une politique de rate‑limit et de retry en cas d’échec temporaire.
Étape 6 — Mise à jour de l'index de fichiers
Le système met à jour l’index interne qui relie les vecteurs aux fichiers/commits afin que la recherche RAG retrouve les passages corrects.
Étape 7 — Reporting et notification
Le job envoie des messages de progression, enregistre des logs et notifie les utilisateurs (interface, notifications) quand l’opération est terminée ou si des erreurs surviennent.
Étape 8 — Politique de reprise
En cas d’erreurs temporaires (ex : quota, timeout), le système retry automatiquement selon une stratégie exponentielle ; si l’erreur persiste, il alerte et marque le job comme échoué pour diagnostic.
Tip — suivre les logs en temps réel
Pour comprendre pourquoi un commit n’a pas été indexé, consultez la file de progression (jobs) du projet et les messages de logs : ils indiquent les fichiers ignorés, les erreurs d’embedding ou les insertions refusées.
Traitement rapide : quelques minutes. Embeddings et insertions sont généralement faites en un seul lot, peu de retries. Idéal pour tests rapides.
Avant le sync manuel
- Index vectoriel potentiellement obsolète.
- Recherches RAG retournant passages manquants.
- Nécessité d’actions manuelles pour rafraîchir.
Après un sync réussi
- Nouveaux passages indexés dans Milvus.
- Résultats de recherche textuelle plus pertinents.
- Historique de commits lié aux documents indexés.
Section — Interroger Milvus par texte depuis un agent Les agents peuvent effectuer automatiquement une recherche vectorielle à partir d’une requête texte et utiliser les meilleurs passages retrouvés comme contexte pour un modèle LLM.
Workflow 3 — Configurer un agent pour interroger Milvus par texte (recherche vectorielle)
Étape 1 — Créer/modifier un agent
Ouvrez la configuration de l’agent et ajoutez un step de type “retrieval” ou “search” (ouéquivalent dans l’interface). Donnez un nom clair au step (ex : ‘Recherche RAG’).
Étape 2 — Définir la requête textuelle
Dans le step, fournissez le texte de requête (cela peut être une entrée utilisateur ou une variable issue d’un step précédent).
Étape 3 — Sélectionner la collection et les filtres
Choisissez la collection Milvus du projet et, si disponible, des filtres pour restreindre la recherche (type de document, source, nom de fichier). Cela réduit le bruit et le coût.
Étape 4 — Paramétrer topK et les paramètres de similarité
Réglez le nombre de résultats renvoyés (topK). Commencez par 3–5 passages. Limitez la longueur totale du contexte que vous allez insérer dans le prompt LLM.
Étape 5 — Intégrer les passages au prompt LLM
Concaténez les passages les plus pertinents (en veillant à l’ordre de priorité) au prompt envoyé au modèle. Si plusieurs passages, inclure des séparateurs et indiquer la source/score.
Étape 6 — Gérer l'absence de résultats
Prévoir un comportement de secours : si la recherche ne retourne rien, l’agent peut soit demander plus d’informations à l’utilisateur, soit basculer sur une recherche basique par mots‑clés.
Étape 7 — Contrôler les coûts et la latence
Limiter la taille et le nombre de passages réduit le coût d’embeddings et le temps de latence. Cachez les résultats fréquents si la même requête est posée souvent.
Étape 8 — Interpréter les scores de similarité
Les résultats fournis incluent un score : interprétez‑les comme une mesure de proximité. Selon la métrique utilisée, un score plus bas peut signifier une meilleure similarité (vérifiez l’UI). N’utilisez pas un seuil unique sans tests.
Étape 9 — Tester et itérer
Testez l’agent avec requêtes réelles, ajustez topK, filtres et pré‑traitement des passages pour optimiser pertinence et coût.
Tip — limiter le contexte envoyé au LLM
Plutôt que d’envoyer tous les passages, concaténez seulement les 2–3 meilleurs et résumez ou réécrivez si nécessaire pour rester sous le seuil de tokens.
Limites à prendre en compte lors des requêtes vectorielles
Les opérations vers Milvus sont soumises à des limites de débit et à une politique de retry. Des recherches trop fréquentes ou larges peuvent engendrer des délais, des retries ou l’échec temporaire des requêtes. Ajustez la fréquence des agents et activez la mise en cache quand c’est possible.
Section — Cas pratiques et recommandations avancées
- Rafraîchissement incrémental : privilégiez des synchronisations périodiques sur des fenêtres restreintes (p.ex. 7–30 jours) pour limiter coût et charge.
- Gestion des tokens : surveillez l’expiration et automatisez la ré‑authentification si votre fournisseur le permet.
- Monitoring : activez les notifications pour être informé des échecs de sync et des dépassements de quotas.
- Tests A/B : comparez différents topK et méthodes de concaténation pour trouver le meilleur compromis pertinence/coût.
- Requête agrégée : pour des demandes complexes, exécutez d’abord une recherche large, puis affinez localement par re‑ranking ou heuristique.
Frequently Asked Questions
Bonnes pratiques résumées
- Toujours vérifier l’état des tokens avant de lancer un sync.
- Commencer par topK = 3–5 pour la recherche RAG et ajuster.
- Préférer sync incrémental pour gros dépôts.
- Mettre en place une stratégie de cache pour requêtes fréquentes.
- Surveiller la consommation de crédits liée aux embeddings.
Prêt à synchroniser et à améliorer vos recherches RAG ?
Lancez un RAG sync sur un dépôt de test, surveillez les logs et ajustez les paramètres de recherche pour optimiser pertinence et coûts.