Évolution de RAG : génomes et cache des serveurs MCP

Évolution des pipelines RAG via des algorithmes génétiques : Mise en œuvre sur les serveurs MCP

Les systèmes RAG avec des prompts statiques perdent en efficacité lorsque les requêtes changent. La mise en œuvre d'une évolution contrôlée utilise des LLM pour générer des variantes de « génomes » — configurations de pipeline. Un évaluateur-juge les teste sur un échantillon de requêtes, les meilleurs candidats passant au statut pending_approval pour confirmation manuelle par un administrateur. Appliqué aux serveurs MCP documents1c (RAG pour la documentation 1C) avec trois couches : postprocess, routing, cache_policy.

L'évolution n'est pas autonome mais fonctionne dans la boucle de laboratoire du panneau d'administration. L'objectif est d'améliorer les prompts système pour le post-traitement et les politiques de cache dans le domaine de la documentation 1C, avec une expansion potentielle vers la finance, la comptabilité et le juridique.

Architecture du pipeline à trois couches

Le pipeline de recherche de documents traite les requêtes séquentiellement :

• Recherche sémantique de segments (hybride si nécessaire).
• Routing : Un classifieur détermine le query_type (factual_lookup, explanation, bsl_help) et active un profil avec system_prompt, depth_budget, format.
• Postprocess : Un LLM assemble la réponse selon un contrat (answer, key_points, sources, warnings) basé sur le génome actif.
• Cache_policy : Contrôle d'admission avant écriture dans le cache (min_sources_count, block_if_warnings).

| Couche | Objet d'évolution | Impact |

|------|-----------------|---------|

| postprocess | system_prompt, chunk_count, max_tokens | Qualité de la réponse textuelle |

| routing | classifier_prompt, profiles | Adaptation au type de requête |

| cache_policy | Seuils d'admission (min_supportedness) | Filtrage du cache |

Postprocess et routing modifient les réponses en temps réel, tandis que cache_policy n'affecte que le stockage.

Modèle de données pour les génomes et évaluations

Les génomes sont stockés dans la table evolution_genome en JSONB avec les champs : layer, status (candidate → evaluated → pending_approval → active), genome, score.

class EvolutionGenome(Base):
    layer = Column(String(32), nullable=False, index=True)
    status = Column(String(32), nullable=False, default="candidate", index=True)
    genome = Column(JSONB, nullable=False)
    score = Column(Float, nullable=True)
    eval_results = relationship("EvolutionEvalResult", back_populates="genome")

Chaque eval_result enregistre query, response (jusqu'à 2000 caractères), judge_score (0–10), judge_reasoning du juge LLM.

class EvolutionEvalResult(Base):
    genome_id = Column(Integer, ForeignKey("evolution_genome.id"), nullable=False)
    query = Column(Text, nullable=False)
    response = Column(Text, nullable=True)
    judge_score = Column(Float, nullable=True)
    judge_reasoning = Column(Text, nullable=True)

Pour le routing, un eval_seed_prompt est généré — une session de test d'agent+MCP.

Cycle d'évolution : Des mutations à la production

Cycle : generate_mutations() → eval_genome() → promote_best() → approbation manuelle.

• Génération : Génome de base (actif ou DEFAULT_GENOMES) + N paires requête-réponse du cache MCP documents1c. LLM génère N variantes JSON {"genome": {...}, "notes": "..."}.
• Évaluation : Le juge (rag_postprocess_model) vérifie selon les critères : exhaustivité, exactitude, sources, concision. Score moyen sur l'échantillon.
• Promotion : Le meilleur candidat passe à pending_approval.
• Activation : L'administrateur confirme dans l'interface utilisateur.

Génération de mutations par couche

Postprocess : Mutations dans system_prompt (instructions pour assembler les réponses, en tenant compte du contexte client/serveur), system_prompt_reduce (fusion sans doublons), chunk_count (15–20), max_tokens (4096–8192), citation_policy (always/inline), verbosity (adaptive/comprehensive).

Exemple de génome postprocess :

{
  "verbosity": "adaptive",
  "max_tokens": 4096,
  "chunk_count": 15,
  "system_prompt": "Vous êtes un expert 1C. Lorsque vous répondez, tenez toujours compte du contexte d'exécution (client léger, client web, serveur, application mobile). Répondez en russe. Citez les sources.",
  "citation_policy": "always",
  "system_prompt_reduce": "Combinez les réponses, en séparant clairement les recommandations pour différents contextes d'exécution. Supprimez les doublons."
}

Routing : classifier_prompt + profiles par query_type (system_prompt, depth_budget, format).

Cache_policy : min_supportedness, require_sources, min_sources_count, block_if_warnings, confidence_key_points_min.

Les dialogues réels sont ajoutés au contexte du générateur pour analyser les faiblesses.

Évaluation et métriques du juge

Le juge évalue sur 4 métriques (0–10) :

• Exhaustivité : Couverture de la requête.
• Exactitude : Alignement avec les segments.
• Sources : Présence/qualité des citations.
• Concision : Absence de remplissage.

Le score moyen détermine la promotion. Eval_judge_response stocke la sortie brute du LLM.

Points clés

• L'évolution par couche est indépendante : postprocess améliore le texte, cache_policy améliore la qualité du cache.
• L'approbation manuelle évite les régressions en production.
• Le contexte du cache réel augmente la pertinence des mutations.
• Les modèles SQLAlchemy prennent en charge la suppression en cascade pour eval_results.
• Évolutif vers multi-domaines (1C + finance + codage).

Passage à l'échelle et bonnes pratiques

Expansion : Ajouter des couches pour les domaines (finance : system_prompt tenant compte des données de référence ; codage : syntaxe BSL). Tester sur 10–20 requêtes du cache. Surveiller les scores >8,5 pour approbation. Éviter le surapprentissage — limiter les mutations par cycle.

— Editorial Team