Guía de implementación de RAG — generación aumentada mediante recuperación en producción con Claude y Gemini

La mayoría de las demos de RAG mueren en producción. Funcionan con el conjunto de 10 preguntas de la demo y se rompen en cuanto los usuarios preguntan algo novedoso. Esta guía presenta la arquitectura y los patrones que resisten: segmentación que respeta los límites semánticos, recuperación híbrida que detecta consultas difusas y literales, una estructura de prompt que evita las alucinaciones y disciplina de costes que mantiene estable la factura al escalar.

Las cinco decisiones importantes

1. Estrategia de segmentación — afecta más a la calidad de recuperación que el modelo
2. Modelo de embeddings — determina el límite de recuperación
3. Estrategia de recuperación — el vector por sí solo no basta
4. Estructura del prompt — decide si el modelo alucina
5. Modelo de generación + almacenamiento en caché — determina la economía unitaria

1. Segmentación: lo aburrido supera a lo ingenioso

No le des demasiadas vueltas. Usa un divisor recursivo de caracteres con 1000-1500 caracteres por segmento y una superposición de 100-200 caracteres. Intenta dividir primero en los límites de los párrafos, después en las frases y luego en las palabras. Es estable en distintos dominios:

# Recursive character splitter with overlap — the boring choice that wins
from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=1200,
    chunk_overlap=200,
    separators=["\n\n", "\n", ". ", " ", ""],
)
chunks = splitter.split_text(document)
# 1200 chars ≈ 300-400 tokens — fits 5+ chunks in a Sonnet context window
# with room for system prompt + question + answer

Cosas que parecen más inteligentes pero rara vez ayudan: modelos conscientes de las frases, divisores conscientes de Markdown y ventanas deslizantes con embeddings. No son malas; solo son marginalmente mejores a cambio de un esfuerzo enorme. Dedica ese esfuerzo a la recuperación.

2. Modelo de embeddings: text-embedding-3-large es el valor predeterminado

Kunavo no ofrece embeddings; llama directamente a un proveedor de embeddings para este paso. /v1/embeddings es un formato de conexión implementado sin ningún modelo habilitado detrás, por lo que una solicitud falla; GET /v1/models es siempre la autoridad sobre lo que se puede invocar. En la práctica, esto no añade más que una segunda clave al pipeline RAG: la llamada de embeddings y la llamada de generación son solicitudes separadas de todos modos, así que genera los embeddings con OpenAI, Voyage o Cohere y genera con Kunavo.

text-embedding-3-large ofrece el mejor equilibrio entre compatibilidad multilingüe y precisión para la mayoría de los casos de uso en producción, al precio publicado por la propia OpenAI; consúltalo en su página de precios en lugar de aquí, ya que no lo revendemos y no deberíamos citar una cifra. Vuelve a generar los embeddings cuando cambies la estrategia de segmentación o el modelo; no cuando se actualice el contenido (simplemente añade segmentos nuevos).

Excepciones en las que funcionan embeddings más pequeños: recuperación de textos cortos exclusivamente en inglés (preguntas frecuentes, tarjetas de producto). Para esos casos, text-embedding-3-small es 4 veces más barato con una pérdida de calidad insignificante. Para contenido multilingüe o técnico, mantente en large.

3. Recuperación: el vector puro pierde frente a la híbrida

La similitud vectorial es excelente para la coincidencia semántica difusa ("¿cómo cancelo?" → "política de cancelación de suscripciones"). Es terrible con términos literales ("SKU-A92837" u "order #4729"). La solución es híbrida: búsqueda de palabras clave BM25 en paralelo y después fusión de rangos recíprocos:

# Hybrid retrieval: vector similarity + BM25 keyword scoring
# Pure vector misses literal keywords (product SKUs, IDs, dates)
def retrieve(question: str, k: int = 5) -> list[dict]:
    q_embed = embed([question])[0]
    vector_hits = vector_db.similarity_search(q_embed, k=k * 2)
    keyword_hits = bm25_search(question, k=k * 2)

    # Reciprocal rank fusion — simple, robust
    scores: dict[str, float] = {}
    for rank, hit in enumerate(vector_hits):
        scores[hit["id"]] = scores.get(hit["id"], 0) + 1 / (rank + 60)
    for rank, hit in enumerate(keyword_hits):
        scores[hit["id"]] = scores.get(hit["id"], 0) + 1 / (rank + 60)

    top_ids = sorted(scores, key=scores.get, reverse=True)[:k]
    return [chunk_by_id[i] for i in top_ids]

Este es el mayor aumento individual de calidad después de elegir un modelo de embeddings decente. Registra recall@5 en una evaluación retenida de 100 preguntas; si pasa del 70% al 90% después de añadir BM25, acabas de eliminar un tercio de los fallos de "no lo sé".

4. Estructura del prompt: tres patrones que evitan las alucinaciones

# Final RAG prompt structure — three sections, citations enforced
SYSTEM_PROMPT = """You answer based exclusively on the supplied Context.
- Cite the [doc_id] for each factual claim.
- If the context doesn't answer the question, say "I don't have that
  information" — do not extrapolate or use general knowledge.
- Be concise. No throat-clearing."""

def answer(question: str) -> dict:
    chunks = retrieve(question, k=5)
    context = "\n\n---\n\n".join(
        f"[doc:{c['id']}] {c['text']}" for c in chunks
    )
    resp = client.chat.completions.create(
        model="claude-sonnet-4-6",
        messages=[
            {"role": "system", "content": [{
                "type": "text",
                "text": SYSTEM_PROMPT,
                "cache_control": {"type": "ephemeral"},
            }]},
            {"role": "user", "content": f"# Context\n{context}\n\n# Question\n{question}"},
        ],
        max_tokens=600,
    )
    return {
        "text": resp.choices[0].message.content,
        "sources": [c["id"] for c in chunks],
    }

Tres elementos innegociables en el prompt del sistema:

• Cita las fuentes — haz que el modelo adjunte [doc:42] a cada afirmación. Si el ID citado no es real, has detectado una alucinación
• Rechaza explícitamente — "si el contexto no responde, di que no tengo esa información". Sin esto, el modelo completa la respuesta con conocimiento del mundo
• Salida concisa — las respuestas breves se correlacionan con respuestas precisas. Un máximo de 600 tokens es un buen valor predeterminado para producción

5. Modelo de generación + almacenamiento en caché: la capa de costes

Claude Sonnet 4.6 es el valor predeterminado. Claude Haiku 4.5 es la alternativa económica si tienes restricciones de coste. Encapsula siempre el prompt del sistema en cache_control; el prompt del sistema es el mismo en cada llamada, así que el almacenamiento en caché reduce esa parte al 10% de la tarifa de entrada.

Coste realista por consulta a escala de producción (5K de contexto, 500 de salida, con el almacenamiento en caché activado):

Con 10.000 consultas/día → $70/día en Sonnet, $10/día en Haiku. Elige Sonnet para casos de uso de alto riesgo (cara al cliente, legales, médicos) y Haiku para procesamiento interno o masivo.

Qué se rompe en producción (y cómo detectarlo)

• Deriva de distribución: el corpus de entrenamiento deja de coincidir con las preguntas reales de los usuarios. Muestrea 100 consultas/semana y comprueba manualmente recall@5
• Embeddings obsoletos: los documentos fuente se actualizan, pero los embeddings no. Registra semanalmente el tamaño del índice frente al tamaño de la fuente
• Citas falsas: el modelo inventa IDs de documentos que parecen reales. Valida cada [doc:N] contra la lista real de IDs recuperados antes de renderizar
• Picos de latencia: la base de datos vectorial se desborda al superar un millón de vectores. Usa indexación HNSW y particiona por tenant si es multi-tenant

Hoja de ruta de producción de 4 semanas

1. Semana 1: crea un prototipo con 100 documentos, 10 preguntas de prueba y evaluación manual
2. Semana 2: escala al corpus completo, crea la recuperación híbrida y escribe un conjunto de evaluación de 100 preguntas
3. Semana 3: ajusta la segmentación + el prompt del sistema iterando sobre la evaluación y publícalo para usuarios internos
4. Semana 4: monitorización, presupuesto de costes y lanzamiento público con una interfaz para citar fuentes

Preguntas frecuentes