Cómo implementar RAG en tu empresa sin romper presupuesto

Implementar Retrieval-Augmented Generation (RAG) suena caro y exótico hasta que te sentás con un arquitecto y ve que el 90% es data pipeline aburrido. Este post es la arquitectura que sacamos cuando un cliente nos dice “queremos IA que responda sobre nuestros propios documentos”, sin quemar presupuesto en lo que no mueve la aguja.

La arquitectura en una hoja

[Documentos / tickets / APIs]
        │
        ▼
[Ingesta + normalización]  ←  lo que la mayoría subestima
        │
        ▼
[Chunking contextual]
        │
        ▼
[Embeddings + índice vectorial]
        │
        ▼
[Retrieval híbrido (BM25 + vector)]
        │
        ▼
[Re-ranking]
        │
        ▼
[LLM con prompt + guardrails]
        │
        ▼
[Cliente]

El modelo bonito de la cadena es el LLM del final, pero el ROI se gana en los dos bloques de arriba: ingesta y chunking. Si eso está mal, no hay Claude que te salve.

Stack que recomendamos (y por qué)

Embeddings: OpenAI text-embedding-3-large o Cohere embed-multilingual-v3 para contenido en español. Alternativa open source: bge-m3 si corres self-hosted.
Índice vectorial: pgvector en Postgres para la mayoría de los casos. Lo conocés, lo operás, corre al lado de tu base operacional. Reservá Pinecone o Qdrant para >10M vectores o patrones multi-tenant complejos.
Retrieval híbrido: combiná BM25 (tsvector en Postgres o Elasticsearch) con similarity search vectorial y fusioná con Reciprocal Rank Fusion. Mejora hit-rate 15–30% vs solo vector.
Re-ranking: Cohere Rerank 3 o bge-reranker-v2-m3. Marginal pero importante cuando recuperás top-20 y querés pasar top-5 al prompt.
LLM de generación: Claude 3.5 Sonnet o GPT-4o. Explicado en detalle en nuestro post de comparativa.

Errores comunes que nos ahorran tiempo

Chunking de tamaño fijo sin respetar estructura. Un PDF con tablas cortado cada 512 tokens parte filas en dos. Invertí en chunking contextual: por sección, respetando headers y tablas.
No versionar los embeddings. Cambiaste de modelo de embeddings y no reindexaste: resultados inconsistentes por meses. Siempre guardá el embedding_model_version junto al vector.
Olvidar evaluación continua. Sin un set de queries con ground truth (aunque sean 50 ejemplos etiquetados), no podés saber si una mejora lo fue.
Prompt infinito. Meter 8.000 tokens de contexto “por si acaso” degrada la respuesta y sube el costo. Objetivo: 3–5 chunks relevantes, no 20.
Respuestas sin fuente. El usuario empresarial necesita poder verificar. Siempre devolvé las fuentes recuperadas con link/ID.

Cuánto cuesta operar

Para un volumen típico de 10K queries/mes sobre una base de 50K documentos:

Embeddings de re-indexación semanal: ~US$10–30.
Infraestructura (Postgres + pgvector en servidor mediano): ~US$100–250.
Inferencia LLM (Sonnet): ~US$100–400.
Observabilidad y logs: ~US$30.

Total: US$240–700 al mes. Una persona del equipo de customer support cuesta más en sueldo que el sistema completo.

Cuándo NO recomendamos RAG

Si tus documentos cambian menos de una vez al trimestre y son <50, fine-tuning o few-shot puede ser más simple.
Si la pregunta es principalmente sobre datos estructurados (bases relacionales), muchas veces un agente con tool use sobre tu base gana a RAG sobre documentos exportados.
Si el caso es sobre conversación natural sin base de conocimiento, RAG es overkill.

Siguiente paso

Si querés ver cómo se ve esto en tu caso, traé 20 preguntas reales de tu equipo de soporte y agendamos una sesión de 30 minutos. En esa llamada salimos con un estimado de esfuerzo y un número realista por mes de operación.