RAG simplificado: 6 arquitecturas de retrieval para startups

La trampa del over-engineering en RAG

La mayoría de los equipos que montan un sistema RAG saltan directo a embeddings, bases vectoriales y pipelines de reranking. Mientras tanto, sus usuarios solo quieren encontrar el documento que dice "cómo resetear mi contraseña". El resultado: tres meses de trabajo y US$5.000 en infraestructura para resolver un problema que un full-text search de Postgres resolvía en una tarde.

La regla que separa a los equipos que escalan de los que se quedan atrapados es simple: empezar por lo más simple, medir con datos reales, y solo añadir complejidad cuando los números lo justifiquen. El artículo original de Lighthouse Newsletter recorre seis arquitecturas de retrieval ordenadas de menor a mayor complejidad, con criterios concretos para decidir cuándo subir de nivel.

Las 6 recetas de retrieval, de simple a complejo

Receta 1 — Full-text search puro (BM25)

El viejo BM25. Elasticsearch. La búsqueda full-text de Postgres. Cero costo de API, latencia inferior a 10ms, fácil de debuggear (ves exactamente por qué un documento matcheó). Funciona sorprendentemente bien: cubre keywords exactas ("invoice #12345"), terminología propietaria y queries estilo "pandas merge dataframe".

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

La trampa: falla con sinónimos ("car" vs "automobile") y con preguntas conversacionales ("¿Cómo hago…?"). Pero para muchos productos SaaS, este nivel cubre el 60% de los casos de uso. No lo saltes.

Receta 2 — Reescritura agentica de queries

Un LLM (modelo GPT-4o-mini, por ejemplo) transforma queries conversacionales en búsquedas de keywords limpias. Cuesta aproximadamente US$0.001 por query. El agente quita stopwords, añade sinónimos, traduce jerga interna y descompone consultas complejas en sub-búsquedas.

La magia: si los resultados no son buenos, ajustas el system prompt. No re-embedeas nada, no reindexas, no corres regression tests. Iteras en minutos, no en días.

Para terminología propietaria (tu framework interno llamado "Atlas"), el matching exacto de keywords le gana al entendimiento semántico. Un modelo de embeddings generalista asociará "Atlas" con mitología griega o mapas; tu BM25 con keywords reforzadas por prompt matcheará perfecto.

Receta 3 — Búsqueda híbrida con reranking

BM25 trae los top 50-100 candidatos, embeddings los rerankea a top 10. La combinación cubre lo que cada uno hace mal por separado. Costo de embedding: aproximadamente US$15 al mes por cada 1.000 queries diarias, según los cálculos del artículo original con precios de OpenAI text-embedding-3-small (US$0.02 por millón de tokens).

El problema real no es costo sino latencia: embeddear 50 documentos on-the-fly suma 200-500ms por query. Para búsqueda user-facing, es notable.

Receta 4 — Embedding on-the-fly (datos frescos)

Si tu contenido cambia más del 10% por día (noticias, social, documentos en constante actualización), pre-embeddear no tiene sentido. Embeddeas solo los documentos candidatos en el momento de la query.

El beneficio crítico: cuando OpenAI deprecó text-embedding-ada-002 a favor de la familia text-embedding-3, los equipos con pre-embedding tuvieron que re-embeddear millones de documentos. Con on-the-fly, cambias una línea de código y listo.

El precio: 200-500ms de latencia. Solo viable si tu caso de uso prioriza frescura sobre velocidad.

Receta 5 — Pre-embedding con tiers hot/cold (el pragmatic play)

El patrón Pareto se cumple en retrieval: el 20% de los documentos recibe el 80% del tráfico. La arquitectura hot/cold pre-embeddea los documentos frecuentes (hot tier) y embeddea on-the-fly los raros (cold tier).

Resultado: rápido para el 80% de queries, fresco para el resto, y al cambiar de modelo solo re-embeddeas el 20% del corpus. El mejor balance latencia/costo/flexibilidad para corpus medianos y grandes (más de 100.000 documentos).

Receta 6 — Pre-embedding completo (solo para escala masiva)

Embeddeas todo upfront, almacenas en una vector database, búsquedas con ANN (approximate nearest neighbors). Latencia inferior a 50ms, pero solo viable con corpus muy estable (menos del 5% de churn mensual) y más de 10.000 queries diarias.

Para la mayoría de startups, esta arquitectura es overkill. El artículo original es directo: "He visto equipos pasar meses optimizando su vector database cuando query rewriting habría resuelto el 90% de sus problemas".

El problema de las queries multi-intent

Las recetas anteriores asumen queries simples. Pero los usuarios reales preguntan cosas como: "¿Cómo leo un CSV, limpio datos faltantes y hago un gráfico?" Son tres intents separados. Buscarlas como una sola query es como buscar un restaurante que sirva pizza, sushi y tacos.

El patrón que usan sistemas agentic modernos como Perplexity y ChatGPT Search es: descomponer la query en sub-queries, enrutar cada una a la estrategia óptima (BM25 puro, BM25 con sinónimos, o LLM rewriting según complejidad), ejecutar en paralelo y sintetizar.

Según los cálculos del artículo original, este enfoque es 15 veces más barato que reescribir la query completa con un LLM, porque solo las sub-queries complejas pagan el costo de embedding.

El árbol de decisión: qué construir primero

El flujo que propone Lighthouse Newsletter es directo:

¿Tienes búsqueda? Si no, construye BM25 primero. Punto.
Mide baseline 2-4 semanas. ¿Los usuarios están contentos? Si sí, deja de optimizar y shippea features.
Si se quejan de "no encuentro docs que claramente existen": prueba query rewriting (US$0.001/query, A/B test 2 semanas).
Si se quejan de "resultados ok pero no geniales": A/B test búsqueda híbrida. ¿La latencia adicional vale la pena? Si sí, elige entre on-the-fly, hot/cold o pre-embedding según tu churn.
Si necesitas mejor entendimiento semántico: híbrido. Si tienes churn alto (>10%/día), on-the-fly. Si tienes patrones de acceso claros, hot/cold. Si tienes escala masiva con datos estables, pre-embedding completo.

La regla del 80/20 aplicada a RAG: 60% de los sistemas deberían quedarse en full-text + query rewriting. 25% necesitan híbrido con on-the-fly o hot/cold. 10% necesitan pre-embedding completo. 5% necesitan soluciones custom.

¿Qué significa esto para tu startup?

No construyas la solución del 5% para un problema del 60%. El error más caro en RAG es saltar directo a arquitecturas complejas sin medir si resuelven un problema real de usuarios.

Dos acciones concretas que podés tomar esta semana:

Audita qué tipo de queries recibe tu búsqueda actual. Catalogalas en tres categorías: keyword-heavy ("error X"), semánticas ("¿cómo…?") y multi-intent ("hacé A, después B, después C"). Esto define qué receta necesitás antes de escribir una línea de código.
Si ya tenés embeddings y los costos se disparan, considerá el Batch API de OpenAI, que reporta una reducción del 50% en costos para cargas de trabajo que pueden esperar 24 horas, según documentación de OpenAI recogida por Analytics Insight. Para re-indexar tu corpus de noche, podés ahorrar a la mitad sin tocar la arquitectura.

Si ya escalás más allá de 10.000 queries diarias y tenés un corpus estable, la evidencia reciente recogida por InfoQ refuerza el enfoque híbrido: el estándar de producción es BM25 + embeddings densos fusionados con Reciprocal Rank Fusion (RRF), según análisis técnicos publicados en 2026. Los benchmarks de arquitecturas agentic jerárquicas reportan 84.5% de accuracy en queries multi-hop, frente al 45.2% de un RAG estándar, aunque con 2.1 segundos de latencia p95 frente a 0.8s del RAG clásico. La diferencia de 1.3 segundos vale para casos enterprise; no para una búsqueda en una app móvil.

Si estás construyendo features de IA en 2026, tené en cuenta también que todos los grandes sistemas de búsqueda con IA (Google AI Mode, ChatGPT Search, Perplexity, Claude, Gemini Deep Research) ya migraron a arquitecturas agentic, según un análisis reciente de Search Engine Land. Eso significa que si construís un producto B2B que vende a equipos que usan estas herramientas, tu propia arquitectura de búsqueda debería estar pensada para integrarse con el patrón agentic, no contra él.