Identifier les fichiers/modifications à traiter (nouveaux fichiers, fichiers modifiés, suppressions). Pour une indexation initiale, listez l’ensemble des fichiers éligibles ; pour une sync incrémentale, ne retenez que les fichiers modifiés ou ajoutés depuis la dernière passe.

Découper chaque fichier en segments cohérents (chunks) adaptés au modèle d’embeddings. Pour chaque chunk, préparer les métadonnées à stocker : source (chemin/URL), type (ex. sourcecode, markdown), chunkIndex, modèle d’embedding utilisé, éventuel modèle associé (nom + id) et contenu textuel (ou son résumé).

Pour chaque chunk, calculer l’embedding vectoriel via le service d’embeddings. Vérifier que chaque vecteur est bien numérique, de la dimension attendue, et exempt de NaN ou valeurs manquantes.

Assembler les chunks en lots (batchs) de taille raisonnable (voir section bonnes pratiques). Chaque élément du lot doit contenir : identifiant local, metadata (source/type/chunkIndex), vecteur et contenu. Marquer le lot avec un identifiant de traitement pour faciliter les audits et retours.

Lancer l’opération d’insertion en envoyant le lot vers la collection Milvus via la méthode d’insertion prévue (insertSource). S’assurer d’inclure toutes les métadonnées et de préférer des lots atomiques plutôt qu’une multitude d’inserts 1 à 1.

Le processus d’insertion peut répondre par succès total, succès partiel ou erreur. Vérifier le statut retourné, consigner toute erreur et réessayer selon la stratégie définie (voir avecRetry). En cas de succès partiel, identifier les éléments manquants et relancer uniquement ceux-ci.

Après confirmation d’insertion, mettre à jour le FileIndex afin qu’il reflète la présence des vecteurs pour chaque chunk (statut : indexé, horodatage, id d’insertion). Cela permet aux composants RAG d’ignorer les éléments non indexés.

Effectuer une requête de vérification sur la collection (ex. compter les chunks par source) et comparer avec le FileIndex. Tout écart doit déclencher une action corrective : nouvelle tentative d’insertion, marquage en erreur, ou régénération du chunk.

Journaliser chaque lot (identifiant, nombre d’objets, durée, erreurs). Conserver ces logs pour diagnostiquer des ratés et alimenter des alertes lorsque le taux d’erreur dépasse un seuil.

Immédiatement après un traitement (indexation ou suppression), comparer le nombre de chunks attendus (d’après les sources traitées) et le nombre de vecteurs réellement présents en interrogeant la collection.

Vérifier que les métadonnées critiques (source, type, chunkIndex) sont présentes et cohérentes entre FileIndex et Milvus pour un échantillon représentatif.

Si vous constatez des différences (chunks manquants, doublons ou vecteurs orphelins), répertoriez les sources affectées et le type d’anomalie (manquant / en double / contenu incorrect).

Pour les chunks manquants : relancer l’insertion ciblée (lot réduit) ; pour les doublons : lancer une suppression ciblée des entrées en excès puis réinsérer proprement ; pour les orphelins (vecteurs sans source) : marquer et supprimer après vérification.

Après corrections, refaire la comparaison. Clore l’incident seulement lorsque FileIndex et collection Milvus concordent.

Documenter la cause racine (ex. timeout, lot partiel, erreurs de format) et ajuster la configuration du retry/rate limiter ou la taille des lots pour éviter la répétition.

Sur une suppression de fichier ou un changement majeur, détecter précisément quelles sources/chunks sont affectées.

Supprimer les vecteurs correspondants en utilisant une suppression filtrée par source et type. Attendre confirmation de suppression puis mettre à jour le FileIndex (statut supprimé).

Pour un fichier modifié, regénérer les chunks et embeddings puis réinsérer via la procédure normale d’insertion.

Vérifier que le nombre de chunks et la correspondance des metadatas sont corrects après suppression/réinsertion.

Si des doublons persistent (mêmes source+chunkIndex), supprimer les entrées anciennes ou incohérentes, en conservant celles avec un horodatage le plus récent ou un identifiant de lot validé.

Toutes les opérations sur la collection passent par un limiteur de débit partagé. Cela évite de surcharger le service vectoriel et réduit les erreurs de contention. Attendez-vous à un enchaînement contrôlé des appels : ils peuvent être mis en file et exécutés progressivement.

En cas d’erreur transitoire (timeout, surcharge), les opérations sont automatiquement réessayées avec un délai croissant. Le nombre maximal de tentatives est limité : prévoir des mécanismes de reprise manuelle si l’erreur persiste.

Réduire la taille des lots si vous observez des timeouts ou des échecs répétés. Taille recommandée : commencer par lot de 50–200 vecteurs selon trafic et ressources, puis ajuster.

Si un lot retourne un succès partiel, extraire la liste des éléments échoués et réessayer uniquement ceux-ci, plutôt que de réinsérer l’intégralité du lot.

Après N tentatives échouées (définir un seuil opérationnel), alerter les équipes et inscrire les éléments dans une file d’erreurs pour reprise manuelle. Documenter l’erreur et stocker le contexte (métadonnées, vecteur, message).

Planifier les indexations lourdes (re-index complet) sur des créneaux hors-pic ou en mode contrôlé pour limiter l’impact sur la plateforme et éviter d’atteindre les quotas.