# RAG y LLMs en 2026: Guía Completa de Retrieval-Augmented Generation para Entrevistas de Data Science

> Domina las preguntas de entrevista sobre RAG y LLMs en 2026. Aprende retrieval augmented generation, pipelines, chunking semántico y evaluación para data science.

- Published: 2026-06-06
- Updated: 2026-06-06
- Author: SharpSkill
- Tags: data-science, machine-learning, llm, rag, embeddings
- Reading time: 12 min

---

Las entrevistas de data science en 2026 han experimentado una transformación radical. Ya no basta con dominar algoritmos clásicos de machine learning o demostrar habilidad con pandas y scikit-learn. Los equipos de contratación ahora esperan que los candidatos comprendan profundamente cómo integrar modelos de lenguaje grandes (LLMs) con sistemas de recuperación de información. Retrieval-Augmented Generation, conocido como RAG, se ha convertido en el patrón arquitectónico dominante para construir aplicaciones de IA generativa en producción, y las preguntas sobre este tema aparecen en prácticamente todas las entrevistas técnicas del sector.

Este artículo explora los conceptos fundamentales, patrones de implementación y consideraciones de producción que todo profesional de data science debe dominar para destacar en entrevistas de IA en 2026.

> **¿Qué es RAG?** Retrieval-Augmented Generation combina la capacidad generativa de los LLMs con la recuperación dinámica de información externa. En lugar de depender únicamente del conocimiento paramétrico del modelo (lo que aprendió durante el entrenamiento), RAG inyecta contexto relevante recuperado de una base de conocimientos en tiempo de consulta. Esto reduce las alucinaciones, permite actualizar información sin reentrenar el modelo y habilita respuestas fundamentadas en datos específicos del dominio.

## El Pipeline RAG de Principio a Fin

Comprender el flujo completo de un sistema RAG constituye el primer requisito en cualquier entrevista sobre LLM interview questions. El pipeline se divide en dos fases claramente diferenciadas: la fase offline de indexación y la fase online de consulta.

Durante la fase offline, los documentos fuente se procesan, dividen en fragmentos manejables y se transforman en vectores densos mediante un modelo de embeddings. Estos vectores se almacenan en una base de datos vectorial que permite búsquedas por similitud semántica de manera eficiente.

La fase online ocurre cuando un usuario realiza una pregunta. El sistema convierte la consulta en un vector, recupera los fragmentos más similares de la base de datos, construye un prompt que incluye tanto la pregunta como el contexto recuperado, y finalmente el LLM genera una respuesta fundamentada en esa información.

```python
# rag_pipeline.py
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.runnables import RunnablePassthrough

# Offline: ingest documents into the vector store
def build_index(documents: list[str]) -> Chroma:
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=512,       # tokens per chunk
        chunk_overlap=64,     # overlap preserves context at boundaries
        separators=["\n\n", "\n", ". ", " "]
    )
    chunks = splitter.create_documents(documents)
    embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
    return Chroma.from_documents(chunks, embeddings)

# Online: retrieve + generate
def query(vectorstore: Chroma, question: str) -> str:
    retriever = vectorstore.as_retriever(
        search_type="mmr",    # Maximal Marginal Relevance for diversity
        search_kwargs={"k": 5, "fetch_k": 20}
    )
    prompt = ChatPromptTemplate.from_template(
        "Answer based on this context only:\n{context}\n\nQuestion: {question}"
    )
    chain = (
        {"context": retriever, "question": RunnablePassthrough()}
        | prompt
        | ChatOpenAI(model="gpt-4o", temperature=0)
    )
    return chain.invoke(question).content
```

El código anterior ilustra una implementación básica pero funcional. Los entrevistadores suelen preguntar sobre las decisiones de diseño: por qué se usa MMR (Maximal Marginal Relevance) en lugar de búsqueda por similitud simple, cómo elegir el tamaño de chunk óptimo, o qué modelo de embeddings seleccionar según el caso de uso.

## Estrategias de Chunking: El Arte de Fragmentar Documentos

La estrategia de chunking representa una de las decisiones más críticas en cualquier sistema RAG, y las preguntas sobre RAG interview questions frecuentemente profundizan en este tema. Un chunking deficiente puede arruinar completamente la calidad de las respuestas, sin importar cuán sofisticado sea el resto del sistema.

Existen múltiples aproximaciones, cada una con sus ventajas y desventajas:

**Chunking por tamaño fijo** divide el texto en fragmentos de longitud uniforme. Resulta simple de implementar pero ignora completamente la estructura semántica del contenido, pudiendo cortar oraciones o párrafos a mitad de una idea.

**Chunking recursivo** utiliza una jerarquía de separadores (párrafos, oraciones, palabras) para dividir el texto de manera más natural. Esta aproximación respeta mejor la estructura del documento pero puede producir chunks de tamaños muy variables.

**Chunking semántico** representa el estado del arte en 2026. Analiza la similitud entre oraciones consecutivas y crea divisiones cuando detecta cambios de tema significativos.

```python
# semantic_chunking.py
import numpy as np
from sentence_transformers import SentenceTransformer

def semantic_chunk(text: str, threshold: float = 0.3) -> list[str]:
    """Split text where semantic similarity drops below threshold."""
    model = SentenceTransformer("all-MiniLM-L6-v2")
    sentences = text.split(". ")
    embeddings = model.encode(sentences)

    chunks, current_chunk = [], [sentences[0]]

    for i in range(1, len(sentences)):
        # Cosine similarity between consecutive sentences
        sim = np.dot(embeddings[i-1], embeddings[i]) / (
            np.linalg.norm(embeddings[i-1]) * np.linalg.norm(embeddings[i])
        )
        if sim < threshold:       # topic shift detected
            chunks.append(". ".join(current_chunk))
            current_chunk = [sentences[i]]
        else:
            current_chunk.append(sentences[i])

    chunks.append(". ".join(current_chunk))  # final chunk
    return chunks
```

En entrevistas de data science AI interview 2026, resulta común que se solicite explicar cómo ajustar el umbral de similitud o cómo manejar documentos con estructuras muy heterogéneas como código mezclado con texto narrativo.

## Bases de Datos Vectoriales y Embeddings

La selección de la base de datos vectorial y el modelo de embeddings impacta directamente en la latencia, precisión y escalabilidad del sistema RAG. Los entrevistadores esperan que los candidatos puedan justificar sus elecciones técnicas basándose en los requisitos específicos del proyecto.

| Database | Indexing | Managed | Strength |
|----------|----------|---------|----------|
| Pinecone | Proprietary | Yes | Simplicity, serverless scaling |
| Weaviate | HNSW | Yes/Self | Hybrid search (vector + BM25) |
| Milvus | IVF, HNSW | Yes/Self | Billion-scale datasets |
| Qdrant | HNSW | Yes/Self | Filtering + payload storage |
| pgvector | IVF, HNSW | Self | PostgreSQL integration |

Respecto a los modelos de embeddings, la tendencia en 2026 favorece modelos especializados por dominio sobre embeddings genéricos. Para aplicaciones legales, médicas o financieras, los embeddings fine-tuneados en corpus específicos superan consistentemente a modelos generalistas como text-embedding-3-large de OpenAI.

La dimensionalidad del embedding también merece consideración. Vectores de mayor dimensión capturan más matices semánticos pero aumentan los costos de almacenamiento y búsqueda. La mayoría de los sistemas en producción utilizan entre 768 y 1536 dimensiones.

## Recuperación Híbrida: Combinando lo Mejor de Dos Mundos

La búsqueda puramente vectorial tiene limitaciones. Puede fallar con términos técnicos específicos, nombres propios o identificadores alfanuméricos que no aparecieron en el entrenamiento del modelo de embeddings. Por otro lado, la búsqueda léxica tradicional (BM25) carece de comprensión semántica.

La recuperación híbrida combina ambos enfoques mediante técnicas de fusión de rankings. Reciprocal Rank Fusion (RRF) se ha establecido como el método preferido debido a su simplicidad y efectividad.

```python
# hybrid_retrieval.py
from rank_bm25 import BM25Okapi
import numpy as np

def reciprocal_rank_fusion(
    dense_results: list[str],
    sparse_results: list[str],
    k: int = 60
) -> list[str]:
    """Merge dense (vector) and sparse (BM25) results using RRF."""
    scores: dict[str, float] = {}

    for rank, doc_id in enumerate(dense_results):
        scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)

    for rank, doc_id in enumerate(sparse_results):
        scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank + 1)

    # Sort by combined RRF score, highest first
    return sorted(scores.keys(), key=lambda d: scores[d], reverse=True)
```

El parámetro k en RRF controla cuánto peso se otorga a los documentos en posiciones más bajas del ranking. Valores más altos de k producen distribuciones más uniformes, mientras que valores bajos favorecen fuertemente los primeros resultados.

## Reranking: Refinando la Relevancia

El reranking añade una capa adicional de refinamiento después de la recuperación inicial. Un modelo cross-encoder evalúa la relevancia de cada documento recuperado respecto a la consulta original, permitiendo reordenar los resultados con mayor precisión.

A diferencia de los bi-encoders usados para generar embeddings (que codifican consulta y documento de forma independiente), los cross-encoders procesan ambos textos juntos, capturando interacciones más sutiles entre ellos. El costo computacional es mayor, pero aplicarlo solo sobre los top-k documentos recuperados mantiene la latencia aceptable.

Modelos como BGE-reranker, Cohere Rerank y ColBERT v2 dominan este espacio en 2026. La elección depende del balance deseado entre calidad y velocidad.

> **Consideración de latencia:** El reranking añade típicamente entre 50-200ms a la latencia total del pipeline. Para aplicaciones en tiempo real, resulta crucial limitar el número de documentos a reranquear (generalmente entre 10 y 25) y considerar modelos distilados optimizados para inferencia rápida.

## RAG Agéntico: Sistemas que Razonan sobre la Recuperación

Los sistemas RAG agénticos representan la evolución natural del patrón básico. En lugar de seguir un flujo lineal rígido, estos sistemas incorporan ciclos de retroalimentación donde el LLM puede evaluar la calidad de los documentos recuperados y decidir si necesita reformular la consulta, buscar en fuentes adicionales o proceder con la generación.

Esta arquitectura resuelve el problema fundamental de las consultas ambiguas o mal formuladas. Si la primera recuperación no produce documentos relevantes, el sistema puede intentar estrategias alternativas antes de generar una respuesta potencialmente incorrecta.

```python
# agentic_rag.py
from langgraph.graph import StateGraph, END
from typing import TypedDict

class RAGState(TypedDict):
    question: str
    documents: list[str]
    generation: str
    retries: int

def retrieve(state: RAGState) -> RAGState:
    """Retrieve documents from vector store."""
    docs = vectorstore.similarity_search(state["question"], k=5)
    return {"documents": [d.page_content for d in docs]}

def grade_documents(state: RAGState) -> str:
    """Decide if documents are relevant enough to answer."""
    prompt = f"Are these documents relevant to: {state['question']}?\n"
    prompt += "\n".join(state["documents"])
    relevance = llm.invoke(prompt)  # returns 'relevant' or 'not_relevant'
    return "generate" if "relevant" in relevance.content else "rewrite"

def rewrite_query(state: RAGState) -> RAGState:
    """Reformulate the query for better retrieval."""
    new_query = llm.invoke(
        f"Rewrite this query for better search results: {state['question']}"
    )
    return {"question": new_query.content, "retries": state["retries"] + 1}

# Build the agent graph
workflow = StateGraph(RAGState)
workflow.add_node("retrieve", retrieve)
workflow.add_node("grade", grade_documents)      # conditional routing
workflow.add_node("rewrite", rewrite_query)
workflow.add_node("generate", generate_answer)

workflow.set_entry_point("retrieve")
workflow.add_edge("retrieve", "grade")
workflow.add_conditional_edges("grade", grade_documents,
    {"generate": "generate", "rewrite": "rewrite"})
workflow.add_edge("rewrite", "retrieve")          # retry loop
workflow.add_edge("generate", END)
```

Langgraph ha emergido como el framework preferido para construir estos sistemas en 2026, proporcionando primitivas para definir grafos de estado, condicionales y ciclos de manera declarativa.

## Graph RAG: Razonamiento sobre Relaciones

Graph RAG extiende el paradigma tradicional incorporando grafos de conocimiento. Mientras que la recuperación vectorial encuentra documentos semánticamente similares, Graph RAG puede navegar relaciones explícitas entre entidades, habilitando razonamiento multi-hop.

Esta aproximación resulta particularmente poderosa para dominios donde las relaciones entre conceptos son tan importantes como los conceptos mismos: genealogías corporativas, redes de citación científica, sistemas legales con referencias cruzadas entre estatutos y jurisprudencia.

La arquitectura típica combina un grafo de conocimiento (Neo4j, Amazon Neptune) con una base de datos vectorial. La consulta del usuario puede desencadenar tanto búsquedas vectoriales como traversías del grafo, fusionando ambos tipos de contexto antes de la generación.

> **Complejidad de implementación:** Graph RAG introduce complejidad significativa en la ingesta de datos, ya que requiere extracción de entidades y relaciones además del chunking tradicional. Los pipelines de actualización incremental también resultan más desafiantes. Se recomienda comenzar con RAG vectorial tradicional y migrar a Graph RAG solo cuando las limitaciones del enfoque básico se vuelvan evidentes.

## Evaluación de Sistemas RAG

La evaluación rigurosa distingue a los profesionales experimentados en entrevistas de retrieval augmented generation. No basta con probar el sistema manualmente; se requieren métricas cuantitativas y benchmarks reproducibles.

**Métricas de recuperación:**
- **Recall@k**: Proporción de documentos relevantes entre los top-k recuperados
- **MRR (Mean Reciprocal Rank)**: Posición promedio del primer documento relevante
- **NDCG**: Ganancia acumulada descontada normalizada, considera el orden completo del ranking

**Métricas de generación:**
- **Faithfulness**: Grado en que la respuesta se fundamenta en el contexto proporcionado
- **Answer Relevance**: Qué tan directamente la respuesta aborda la pregunta
- **Context Precision**: Proporción del contexto recuperado que resulta útil para la respuesta

Frameworks como RAGAS, DeepEval y Phoenix han estandarizado estas evaluaciones, permitiendo benchmarking consistente durante el desarrollo iterativo.

## Modos de Falla en Producción

Los entrevistadores experimentados preguntan específicamente sobre modos de falla y estrategias de mitigación. Demostrar conciencia de estos problemas señala madurez profesional.

**Deriva del embedding:** Los documentos nuevos pueden tener distribuciones estadísticas diferentes a los documentos originales, degradando gradualmente la calidad de recuperación. Se requiere monitoreo continuo de métricas de relevancia.

**Envenenamiento del contexto:** Documentos maliciosos o incorrectos en el corpus pueden propagarse a las respuestas. Las estrategias de mitigación incluyen validación de fuentes, detección de anomalías en embeddings y logging exhaustivo de trazabilidad.

**Explosión de latencia:** Consultas que requieren múltiples reintentos en sistemas agénticos pueden exceder timeouts. Se necesitan límites estrictos de reintentos y fallbacks graceful.

**Fragmentación semántica:** Información que debería estar junta puede quedar dividida en chunks separados, impidiendo que el LLM sintetice una respuesta coherente. El chunking con overlap y la recuperación de documentos padre mitigan este problema.

## Conclusión

- RAG combina la capacidad generativa de los LLMs con la recuperación dinámica de información para producir respuestas fundamentadas sin reentrenar el modelo
- La estrategia de chunking tiene el mayor impacto en la calidad de recuperación — el chunking semántico supera al corte de tamaño fijo en la mayoría de los casos de uso
- La recuperación híbrida (vectores densos + BM25 disperso) con Reciprocal Rank Fusion es el estándar de producción, resolviendo el problema de desajuste de vocabulario
- Los rerankers cross-encoder agregan una capa de precisión después de la recuperación amplia, procesando solo un conjunto pequeño de candidatos para mantener la latencia aceptable
- El RAG agéntico y el Graph RAG representan los dos avances arquitectónicos principales en 2026, manejando consultas complejas multi-salto donde el RAG básico falla
- La evaluación debe separar las métricas de recuperación (Recall@k, MRR) de las métricas de generación (fidelidad, relevancia) para diagnosticar dónde se rompe el pipeline
- Las fallas de producción más comunes — deriva de embedding, envenenamiento del contexto, explosión de latencia — todas tienen correcciones directas una vez identificadas

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/es/blog/data-science/rag-retrieval-augmented-generation-llm-data-science-interview-2026