Evolución de RAG: genomas y caché de servidores MCP

Evolución de Pipelines RAG mediante Algoritmos Genéticos: Implementación en Servidores MCP

Los sistemas RAG con prompts estáticos pierden eficacia a medida que cambian las consultas. Implementar una evolución controlada utiliza LLMs para generar variantes de "genomas"—configuraciones de pipeline. Un evaluador juez las prueba en una muestra de consultas, y los mejores candidatos pasan al estado pending_approval para confirmación manual por un administrador. Aplicado a servidores MCP documents1c (RAG para documentación 1C) con tres capas: postprocess, routing, cache_policy.

La evolución no es autónoma, sino que opera dentro del bucle de laboratorio del panel de administración. El enfoque está en mejorar los prompts del sistema para el postprocesamiento y las políticas de caché en el dominio de documentación 1C, con potencial expansión a finanzas, contabilidad y campos legales.

Arquitectura del Pipeline de Tres Capas

El pipeline de búsqueda de documentos procesa consultas secuencialmente:

• Búsqueda semántica de fragmentos (híbrida si es necesario).
• Routing: Un clasificador determina query_type (factual_lookup, explanation, bsl_help) y activa un perfil con system_prompt, depth_budget, format.
• Postprocess: Un LLM ensambla la respuesta según un contrato (answer, key_points, sources, warnings) basado en el genoma activo.
• Cache_policy: Control de admisión antes de escribir en caché (min_sources_count, block_if_warnings).

| Capa | Objeto de Evolución | Impacto |

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

| postprocess | system_prompt, chunk_count, max_tokens | Calidad de la respuesta textual |

| routing | classifier_prompt, profiles | Adaptación al tipo de consulta |

| cache_policy | Umbrales de admisión (min_supportedness) | Filtrado de caché |

Postprocess y routing modifican respuestas en tiempo real, mientras que cache_policy solo afecta el almacenamiento.

Modelo de Datos para Genomas y Evaluaciones

Los genomas se almacenan en la tabla evolution_genome como JSONB con campos: 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")

Cada eval_result registra query, response (hasta 2000 caracteres), judge_score (0–10), judge_reasoning del juez 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)

Para routing, se genera un eval_seed_prompt—una sesión de prueba de agent+MCP.

Ciclo de Evolución: De Mutaciones a Producción

Ciclo: generate_mutations() → eval_genome() → promote_best() → aprobación manual.

• Generación: Genoma base (activo o DEFAULT_GENOMES) + N pares query-response de la caché de MCP documents1c. LLM genera N variantes JSON {"genome": {...}, "notes": "..."}.
• Evaluación: Juez (rag_postprocess_model) verifica según criterios: completitud, precisión, fuentes, concisión. Puntuación promedio en la muestra.
• Promoción: El mejor candidato pasa a pending_approval.
• Activación: Admin confirma en la UI.

Generación de Mutaciones por Capa

Postprocess: Mutaciones en system_prompt (instrucciones para ensamblar respuestas, considerando contexto cliente/servidor), system_prompt_reduce (fusionar sin duplicados), chunk_count (15–20), max_tokens (4096–8192), citation_policy (always/inline), verbosity (adaptive/comprehensive).

Ejemplo de genoma postprocess:

{
  "verbosity": "adaptive",
  "max_tokens": 4096,
  "chunk_count": 15,
  "system_prompt": "Eres un experto en 1C. Al responder, siempre considera el contexto de ejecución (cliente ligero, cliente web, servidor, aplicación móvil). Responde en ruso. Cita fuentes.",
  "citation_policy": "always",
  "system_prompt_reduce": "Combina respuestas, separando claramente recomendaciones para diferentes contextos de ejecución. Elimina duplicación."
}

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

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

Se añaden diálogos reales al contexto del generador para analizar debilidades.

Evaluación y Métricas del Juez

El juez evalúa basándose en 4 métricas (0–10):

• Completitud: Cobertura de la consulta.
• Precisión: Alineación con fragmentos.
• Fuentes: Presencia/calidad de citas.
• Concisión: Ausencia de relleno.

La puntuación promedio determina la promoción. Eval_judge_response almacena la salida cruda del LLM.

Puntos Clave

• La evolución por capa es independiente: postprocess mejora el texto, cache_policy mejora la calidad de la caché.
• La aprobación manual evita regresiones en producción.
• El contexto de la caché real aumenta la relevancia de las mutaciones.
• Los modelos SQLAlchemy soportan eliminación en cascada para eval_results.
• Escalable a múltiples dominios (1C + finanzas + programación).

Escalabilidad y Mejores Prácticas

Expansión: Añadir capas para dominios (finanzas: system_prompt considerando datos de referencia; programación: sintaxis BSL). Probar en 10–20 consultas de la caché. Monitorear puntuaciones >8.5 para aprobación. Evitar sobreajuste—limitar mutaciones por ciclo.

— Editorial Team