Cómo reduje el costo de RAG en un 99%

Los demos de RAG son baratos. RAG en producción no lo es.

La mayoría de prototipos que he auditado cuestan entre $2 y $5 por consulta cuando sumas embeddings, búsqueda vectorial y la llamada al LLM. En un notebook esos números parecen razonables. Con 10,000 consultas diarias estás viendo $1.5M al año en inferencia — antes de generar un dólar de ingreso.

Este caso documenta el playbook que construí para cerrar la brecha entre demo y producción: la arquitectura de retrieval, las palancas de costo, el harness de evals y los números duros.

Arquitectura de retrieval

Cada decisión de diseño responde a una pregunta: ¿mejora la economía unitaria o la confiabilidad? Si no hace ninguna de las dos, es complejidad innecesaria.

• Chunking padre-hijo con token awareness — chunks pequeños para matching, expansión al padre para contexto. Sin oraciones cortadas a la mitad, sin tokens desperdiciados.
• Embeddings del tamaño correcto — text-embedding-3-small (1536 dims) para retrieval inicial; conserva el 95% del recall a 5x menos costo. El modelo grande solo toca los top 20 candidatos durante reranking. Esto solo cortó costos de embedding en un 80%.
• Búsqueda híbrida en Supabase — pgvector para retrieval denso y pg_trgm para matching por keywords, fusionados con reciprocal rank fusion. Un solo Postgres gestionado en vez de una base vectorial separada. Menos servicios, menos factura, ops más simples.
• Reranking con cross-encoder — retrieval inicial trae top 100 a propósito. Un cross-encoder los puntúa contra la consulta y poda a los top 5. Retrieval barato lanza la red; reranking caro la cierra.

Palancas de reducción de costos

El 99% no es un solo truco — son cinco palancas compuestas.

1. Caché semántico — Redis con umbral de similitud coseno de 0.97. Si la consulta es casi idéntica a una cacheada, devolvemos el resultado sin generar embeddings ni llamar al LLM. En producción alcanza un 60% de cache hit porque los usuarios preguntan variaciones de lo mismo. Esta sola palanca cortó costos a la mitad.
2. Modelos por nivel — modelo pequeño para retrieval, grande solo para reranking de top-k. El modelo grande ve 20 documentos en vez de 50,000. Tres órdenes de magnitud de diferencia.
3. Almacenamiento por niveles — documentos consultados en los últimos 30 días viven en pgvector caliente; 30-90 días van a almacenamiento comprimido; el resto se archiva en S3 frío. Esto redujo el tier de compute de Supabase un 40%.
4. Batch processing fuera de pico — el contenido nuevo se embeddea en jobs nocturnos. Compute más barato y oportunidad de deduplicar antes de indexar.
5. Chunking token-aware — cada chunk maximiza densidad de información dentro de la ventana de contexto. Sin relleno, sin desperdicio. Cuando la ventana de contexto es el recurso más caro, cada token mal usado es una fuga directa de costos.

Harness de evals

Reducir costos sin medir calidad es correr a ciegas.

• Golden dataset — 500 pares consulta-respuesta con scores de relevancia etiquetados por humanos. Sin atajos sintéticos para la línea base.
• Métricas automatizadas — cada cambio en el pipeline dispara: Recall@10, MRR, NDCG para retrieval; factualidad, fidelidad y relevancia (LLM-as-judge) para generación.
• Regression gate — si cualquier métrica cae más de 2% respecto al último run aprobado, el deploy se bloquea. Sin excepciones.
• Bucle de feedback — las evals detectan una regresión, diagnostico si es chunking, retrieval o generación, corrijo, re-evalúo y despliego con confianza. La disciplina de medir antes y después de cada cambio es lo que endurece el sistema.

Antes y después

| Métrica | Antes | Después | Cambio | |---------|-------|---------|--------| | Costo por consulta | $4.85 | $0.05 | -99% | | Recall@10 | 72% | 94% | +22 pts | | Latencia (p50) | 2.8 s | 340 ms | -88% | | Latencia (p95) | 8.1 s | 890 ms | -89% | | Tasa de alucinación | 14% | 3.2% | -77% | | Costo mensual infra (10K consultas/día) | ~$145K | ~$1.5K | -99% |

Los números de costo son el titular, pero latencia y precisión importan igual. Respuestas más rápidas significan mayor tasa de completación. Mayor recall significa menos callejones sin salida. Menor alucinación significa que los usuarios confían en el output — y esa confianza es lo que generó el 482% de aumento en engagement.

Aprendizajes

• El caché es la palanca de mayor impacto. Esperaba que la optimización de modelos dominara. No fue así. El caché semántico representó más de la mitad de la reducción porque el tráfico real es mucho más repetitivo de lo que sugieren benchmarks sintéticos.
• La búsqueda híbrida no es opcional. Empecé con retrieval vectorial puro y chocaba con casos exactos — códigos de producto, números de error, nombres propios. Agregar pg_trgm resolvió una clase entera de fallos.
• Las evals son infraestructura, no un nice-to-have. Cada vez que salté el paso de evals para "ir más rápido", introduje una regresión que tardó más en debuggear que lo que hubiera tardado la eval.
• Supabase pgvector está subestimado para esta carga. Evalué Pinecone y Weaviate. Ambos excelentes, pero si ya necesitas Postgres para auth, RLS y datos de aplicación, agregar una base vectorial separada introduce hops de red, complejidad de facturación y un servicio más que monitorear.

Si lo hiciera de nuevo, construiría el harness de evals primero — antes de escribir una sola línea de retrieval. Tener mediciones de verdad desde el día uno me habría ahorrado dos semanas de "¿esto se siente mejor?"

También puedes revisar otros proyectos para comparar enfoques, trade-offs y patrones de implementación relacionados.