Cómo hicimos que RAG fuera un 50% más rápido
- Escrito por
- Michal Korbela
- Publicado
- Última actualización
EscucharEscucha este artículo
RAG mejora la precisión de agentes de IA al fundamentar las respuestas de los LLM en grandes bases de conocimiento. En lugar de enviar toda la base de conocimiento al LLM, RAG genera una representación vectorial de la consulta, recupera la información más relevante y se la proporciona al modelo como contexto. En nuestro sistema, primero añadimos un paso de reformulación de la consulta, que condensa el historial de la conversación en una consulta precisa e independiente antes de la recuperación.
Para bases de conocimiento muy pequeñas, puede resultar más sencillo incluirlo todo directamente en el prompt. Pero, cuando la base de conocimiento crece, RAG se vuelve esencial para mantener la precisión de las respuestas sin sobrecargar el modelo.
Muchos sistemas tratan RAG como una herramienta externa; sin embargo, nosotros lo hemos integrado directamente en el flujo de solicitudes para que se ejecute en cada consulta. Esto garantiza una precisión constante, pero también supone un riesgo de latencia.
Por qué la reformulación de consultas nos ralentizaba
La mayoría de las solicitudes de usuarios hacen referencia a turnos anteriores, por lo que el sistema necesita condensar el historial de la conversación en una consulta precisa e independiente.
Por ejemplo:
- Si usuario pregunta: «¿Podemos personalizar esos límites según nuestros patrones de tráfico punta?»
- El sistema lo reformula como: «¿Se pueden personalizar los límites de frecuencia de la API del plan Enterprise para patrones de tráfico específicos?»
La reformulación convierte referencias imprecisas como «esos límites» en consultas independientes que los sistemas de recuperación pueden utilizar, mejorando el contexto y la precisión de la respuesta final. Sin embargo, depender de un único LLM alojado externamente generaba una fuerte dependencia de su velocidad y disponibilidad. Solo este paso representaba más del 80 % de la latencia de RAG.
Cómo lo solucionamos con carreras de modelos
Rediseñamos la reformulación de consultas para que funcione como una carrera:
- Varios modelos en paralelo. Cada consulta se envía simultáneamente a varios modelos, incluidos nuestros modelos Qwen 3-4B y 3-30B-A3B autoalojados. Gana la primera respuesta válida.
- Alternativas que mantienen el flujo de las conversaciones. Si ningún modelo responde en un segundo, recurrimos al mensaje original de usuario. Puede ser menos preciso, pero evita bloqueos y garantiza la continuidad.
.webp&w=3840&q=80)
El impacto en el rendimiento
Esta nueva arquitectura redujo a la mitad la latencia mediana de RAG, de 326 ms a 155 ms. A diferencia de muchos sistemas que activan RAG de forma selectiva como herramienta externa, nosotros lo ejecutamos en cada consulta. Con una latencia mediana de solo 155 ms, la sobrecarga de hacerlo es insignificante.
Latencia antes y después:
- Mediana: 326 ms → 155 ms
- p75: 436 ms → 250 ms
- p95: 629 ms → 426 ms

La arquitectura también hizo que el sistema fuera más resistente a la variabilidad de los modelos. Aunque los modelos alojados externamente pueden ralentizarse durante las horas de máxima demanda, nuestros modelos internos se mantienen relativamente estables. Hacer competir los modelos suaviza esta variabilidad y transforma el rendimiento individual e impredecible de cada modelo en un comportamiento del sistema más estable.
Por ejemplo, cuando uno de nuestros proveedores de LLM sufrió una interrupción el mes pasado, las conversaciones continuaron sin problemas con nuestros modelos autoalojados. Como ya operamos esta infraestructura para otros servicios, el coste de computación adicional es insignificante.
Por qué es importante
La reformulación de consultas RAG en menos de 200 ms elimina un importante cuello de botella para agentes conversacionales. El resultado es un sistema que mantiene tanto el contexto como la capacidad de respuesta en tiempo real, incluso cuando opera con grandes bases de conocimiento empresariales. Al reducir la sobrecarga de recuperación a niveles casi insignificantes, agentes conversacionales pueden escalar sin comprometer el rendimiento.




