Evolution von RAG: Genome und Cache von MCP-Servern

Evolution von RAG-Pipelines durch genetische Algorithmen: Implementierung auf MCP-Servern

RAG-Systeme mit statischen Prompts verlieren an Effektivität, wenn sich Abfragen ändern. Kontrollierte Evolution nutzt LLMs, um Varianten von "Genomen" – Pipeline-Konfigurationen – zu generieren. Ein Bewerter testet sie anhand einer Stichprobe von Abfragen, wobei die besten Kandidaten in den Status pending_approval übergehen, um manuell von einem Administrator bestätigt zu werden. Angewendet auf MCP-Server documents1c (RAG für 1C-Dokumentation) mit drei Ebenen: postprocess, routing, cache_policy.

Die Evolution ist nicht autonom, sondern läuft innerhalb der Labor-Schleife des Admin-Panels. Der Fokus liegt auf der Verbesserung von System-Prompts für Nachbearbeitung und Caching-Richtlinien im Bereich 1C-Dokumentation, mit möglicher Ausweitung auf Finanzen, Buchhaltung und Recht.

Architektur der Drei-Ebenen-Pipeline

Die docsearch-Pipeline verarbeitet Abfragen sequenziell:

• Semantische Chunk-Suche (hybrid bei Bedarf).
• Routing: Ein Klassifizierer bestimmt query_type (factual_lookup, explanation, bsl_help) und aktiviert ein Profil mit system_prompt, depth_budget, format.
• Postprocess: Ein LLM setzt die Antwort gemäß einem Vertrag (answer, key_points, sources, warnings) basierend auf dem aktiven Genom zusammen.
• Cache_policy: Zugangskontrolle vor dem Schreiben in den Cache (min_sources_count, block_if_warnings).

| Ebene | Evolutionsobjekt | Auswirkung |

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

| postprocess | system_prompt, chunk_count, max_tokens | Qualität der Textantwort |

| routing | classifier_prompt, profiles | Anpassung an Abfragetyp |

| cache_policy | Zugangsschwellen (min_supportedness) | Cache-Filterung |

Postprocess und routing modifizieren Antworten in Echtzeit, während cache_policy nur die Speicherung beeinflusst.

Datenmodell für Genome und Bewertungen

Genome werden in der Tabelle evolution_genome als JSONB mit Feldern gespeichert: 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")

Jedes eval_result erfasst query, response (bis zu 2000 Zeichen), judge_score (0–10), judge_reasoning vom LLM-Bewerter.

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)

Für routing wird ein eval_seed_prompt generiert – eine Testsitzung von Agent+MCP.

Evolutionszyklus: Von Mutationen zur Produktion

Zyklus: generate_mutations() → eval_genome() → promote_best() → manuelle Freigabe.

• Generierung: Basisgenom (aktiv oder DEFAULT_GENOMES) + N Abfrage-Antwort-Paare aus dem MCP documents1c-Cache. LLM generiert N JSON-Varianten {"genome": {...}, "notes": "..."}.
• Bewertung: Bewerter (rag_postprocess_model) prüft nach Kriterien: Vollständigkeit, Genauigkeit, Quellen, Prägnanz. Durchschnittsnote über die Stichprobe.
• Beförderung: Bester Kandidat wechselt zu pending_approval.
• Aktivierung: Admin bestätigt in der UI.

Mutationsgenerierung nach Ebene

Postprocess: Mutationen in system_prompt (Anweisungen zum Zusammenstellen von Antworten, Berücksichtigung von Client/Server-Kontext), system_prompt_reduce (Zusammenführen ohne Duplikate), chunk_count (15–20), max_tokens (4096–8192), citation_policy (always/inline), verbosity (adaptive/comprehensive).

Beispiel-Postprocess-Genom:

{
  "verbosity": "adaptive",
  "max_tokens": 4096,
  "chunk_count": 15,
  "system_prompt": "Sie sind ein 1C-Experte. Berücksichtigen Sie bei der Antwort stets den Ausführungskontext (Thin Client, Web Client, Server, Mobile App). Antworten Sie auf Deutsch. Zitieren Sie Quellen.",
  "citation_policy": "always",
  "system_prompt_reduce": "Kombinieren Sie Antworten und trennen Sie Empfehlungen für verschiedene Ausführungskontexte klar. Entfernen Sie Duplikate."
}

Routing: classifier_prompt + Profile nach query_type (system_prompt, depth_budget, format).

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

Echte Dialoge werden dem Generator-Kontext hinzugefügt, um Schwächen zu analysieren.

Bewertung und Bewerter-Metriken

Der Bewerter bewertet basierend auf 4 Metriken (0–10):

• Vollständigkeit: Abdeckung der Abfrage.
• Genauigkeit: Übereinstimmung mit Chunks.
• Quellen: Vorhandensein/Qualität von Zitaten.
• Prägnanz: Fehlen von Fülltext.

Durchschnittsnote bestimmt die Beförderung. Eval_judge_response speichert die rohe LLM-Ausgabe.

Wichtige Punkte

• Ebenen-Evolution ist unabhängig: postprocess verbessert Text, cache_policy steigert Cache-Qualität.
• Manuelle Freigabe verhindert Rückschritte in der Produktion.
• Kontext aus echtem Cache erhöht Relevanz von Mutationen.
• SQLAlchemy-Modelle unterstützen kaskadierendes Löschen für eval_results.
• Skalierbar auf Multi-Domain (1C + Finanzen + Programmierung).

Skalierung und Best Practices

Erweiterung: Ebenen für Domänen hinzufügen (Finanzen: system_prompt mit Referenzdaten; Programmierung: BSL-Syntax). Test mit 10–20 Abfragen aus dem Cache. Überwachen Sie Noten >8,5 für Freigabe. Vermeiden Sie Overfitting – begrenzen Sie Mutationen pro Zyklus.

— Editorial Team