Ingeniero de Software Junior
en Divusware.

Mantengo y optimizo un pipeline RAG multi-proveedor (Voyage AI, pgVector, OpenAI, Anthropic, Google), logrando una mejora de calidad del 35% y una reducción de costos del 25% al pasar de un modelo fijo a una selección óptima por proveedor. También refuerzo la UI de aplicaciones .NET (Blazor) con mi experiencia en frontend web.

Tech-stack que usé en este rol

Retos que enfrenté

  • Punto único de fallo: Dependencia fija de un LLM sin estrategia de respaldo durante caídas.

  • Pérdida de contexto en RAG multi-turno: Embeddings de consultas aislados y chunks sin persistir causaban fallos de recuperación en seguimientos ambiguos (p. ej., “that”, “the interface”).

  • Deuda técnica silenciosa y cero visibilidad: Un reranker de Voyage deprecado sin detectar en producción y sin logs para rastrear qué modelo generó cada respuesta.

Logros

  • Hasta 35% de mejora. En la calidad de las respuestas gracias a la selección óptima de modelo por proveedor.

  • Hasta 25% de reducción de costos. Asignando modelos más económicos a tareas más simples.

  • Resiliencia sin caídas. Las caídas de un proveedor ya no interrumpen el chat de soporte: se cambia en tiempo real desde el panel de administración.

  • Fallos de recuperación multi-turno corregidos. Mediante reformulación de consultas, caché de chunks en Redis y prompting con contexto.

  • Estrategia de modelos basada en datos. Una línea de modelos evaluada con QA que equilibra calidad, velocidad y precio.

Diagrama de arquitectura

Pipeline RAG multi-proveedor de DivuswareUna pregunta de soporte recorre los canales de chat, la reformulación, la memoria de conversación, los embeddings gestionados, la recuperación en pgVector y un gate de confianza con un reintento, hasta la capa multi-proveedor de modelos y de vuelta como respuesta.Canales de soporteWhatsApp · Intercom · APIAgente RAGRedishistorialmemoria de fuentesReformulaciónheurística + fallback LLMEmbeddingsmodelo gestionadoBase de conocimientodocumentos → vectorespgVectorsimilitud cosenoRerankingcross-encoder · top-kProveedores de modelosAnthropicOpenAIGoogleselección por agente · failovergate de confianzareintento únicorespuesta

Mi enfoque

  • Failover multi-proveedor en vivo: Construí un motor agnóstico de proveedores con un toggle en el panel de administración para cambiar entre LLMs (OpenAI, Anthropic) en tiempo real, sin volver a desplegar.

  • Recuperación híbrida con contexto:

    • Implementé reformulación heurística de consultas con fallback automático a un LLM ligero (gpt-5.4-mini) cuando la confianza de recuperación cae por debajo de 0.45.
    • Añadí caché en Redis sub-milisegundo (TTL de 3 horas) para mezclar IDs de chunks previos entre los candidatos antes del reranking.
    • Refiné los prompts para resolver referencias anafóricas de forma explícita usando el historial del chat.

  • Selección de modelos basada en datos: Establecí un framework de evaluación de QA que puntúa modelos contra el triángulo calidad-velocidad-costo.

  • Observabilidad y remediación de deuda técnica: Migré el reranker deprecado a rerank-2.5-lite e implementé metadata tagging para rastrear las salidas de cada modelo por mensaje.