El Ciclo de Hype del RAG y la Realidad
RAG (Retrieval-Augmented Generation) se suponía que era la respuesta a las alucinaciones de los LLMs. El artículo de 2020 de Lewis et al. prometía respuestas fundamentadas con citas. Pero en la producción empresarial, los resultados a menudo decepcionan. Los usuarios no confían en las respuestas, las citas son vagas y los pasajes recuperados fallan.
El reflejo de la industria es apilar más infraestructura: modelos más fuertes, ventanas de contexto más largas, mejores rerankers. Pero el problema real no es infraestructural. Se trata de disciplina de ingeniería, experiencia de dominio y entender qué es realmente RAG.
Este artículo, basado en la serie Document Intelligence, argumenta que RAG empresarial no es un problema de ML. Es un problema de búsqueda y extracción con una capa de generación encima. La clave es construirlo brick by brick, con un enfoque en auditabilidad y amplificación de expertos.

Los Cuatro Ladrillos: Un Enfoque Relacional
La serie propone cuatro componentes principales, cada uno produciendo datos estructurados para auditoría:
- Parsing: Convertir PDFs en tablas (líneas, tablas, TOC).
- Parsing de Preguntas: Estructurar la consulta del usuario en tablas relacionales.
- Recuperación: Filtrar y buscar usando una combinación de TOC, palabras clave y embeddings.
- Generación: Usar un esquema Pydantic para producir JSON tipado con citas.
Aquí hay un ejemplo mínimo del paso de recuperación + generación, mostrando cómo mantenerlo verificable:
from pydantic import BaseModel
from typing import List
import fitz # PyMuPDF
# Define el esquema de salida
class Respuesta(BaseModel):
respuesta: str
citas: List[str]
# Recuperación simple: palabra clave + fallback de embedding
def recuperar(ruta_pdf: str, pregunta: str, top_k: int = 3):
doc = fitz.open(ruta_pdf)
pasajes = []
for num_pagina in range(len(doc)):
texto = doc[num_pagina].get_text()
# Puntuación simple de palabra clave; en la práctica, combina con embeddings
puntuacion = sum(1 for palabra in pregunta.split() if palabra.lower() in texto.lower())
pasajes.append((puntuacion, num_pagina, texto))
pasajes.sort(reverse=True)
return pasajes[:top_k]
# Genera con citas
def generar(pasajes, pregunta):
# En la práctica, esto llamaría a un LLM con el esquema
contexto = "\n".join([f"Página {p}: {t}" for _, p, t in pasajes])
return Respuesta(respuesta="La respuesta es...", citas=[f"página {p}" for _, p, _ in pasajes])
# Ejecuta el pipeline
pasajes = recuperar("contrato.pdf", "¿Cuál es el deducible?")
resultado = generar(pasajes, "¿Cuál es el deducible?")
print(resultado.json())
Ese script tiene ~100 líneas y es más verificable que muchos sistemas de producción.

Límites y Precauciones
- No es para QA de dominio abierto: Este enfoque asume que tienes expertos de dominio que conocen el corpus.
- Enfoque solo en PDF: Otros formatos (Word, Excel) necesitan lógica de parsing diferente.
- Sin bala de plata: No va a arreglar un proceso de parsing de documentos fundamentalmente roto.
Próximos Pasos para Aprender
Empieza con el pipeline mínimo y luego mejora cada ladrillo sistemáticamente. Enfócate en construir una traza de auditoría relacional y diccionarios orientados por expertos. La serie también cubre temas avanzados como parsing adaptativo, referencias cruzadas e indexación a escala de corpus.
Para más sobre temas relacionados, checa cómo funcionan los pseudo-elementos CSS de resaltado o ve un ejemplo real de IA en diagnóstico de cáncer en AWS.

Conclusión
RAG empresarial no se trata de entrenar un modelo o comprar una base de datos vectorial. Se trata de entender tus documentos, tus expertos y construir un pipeline transparente. El enfoque brick by brick asegura que cada paso sea auditable y cada respuesta esté fundamentada.
Conclusión clave: Deja de tratar RAG como un problema de ML. Trátalo como una disciplina de ingeniería. Empieza con lo básico y construirás sistemas en los que los usuarios realmente confían.