RAG de PDF a respuesta: el pipeline completo y las 3 trampas que lo rompen
Tienes los PDFs, los embeddings y la vector DB. El sistema sigue fallando donde se conectan las piezas, no donde las montas.
En este artículo
El pipeline ya lo sabes. El problema está en las uniones
Llevas montando RAG como un IKEA: extraes el PDF, lo partes, lo conviertes en embeddings, lo tiras a un índice y le pides al modelo que conteste. Eso funciona en el tutorial. En producción se cae.
No se cae en el extractor. No se cae en el índice. Se cae donde las piezas se tocan.
Esta guía recorre el pipeline completo, pero no para explicarte qué es un embedding: eso ya lo sabes o lo encuentras en diez sitios. La clave está en tres decisiones concretas que la mayoría toma mal y que luego no saben dónde buscar cuando el sistema empieza a mentir con confianza.
Qué necesitas para arrancar
RAG es fontanería: el modelo no se sabe tu PDF. Tú buscas trozos en un almacén, se los pegas al prompt y le pides que conteste con eso delante.
Para un mínimo funcional hacen falta estas piezas:
- Corpus: los PDFs que quieres que el sistema conozca.
- Extractor de texto: convierte el PDF en texto legible. Si es un escaneo, OCR. Si tiene tablas, decide ya si las tratas como tablas o aceptas que saldrán rotas.
- Modelo de embeddings: convierte fragmentos de texto en vectores numéricos.
- Almacén vectorial: guarda esos vectores y permite buscar por similitud.
- Índice de palabras: para hybrid search, imprescindible en producción.
- LLM: el modelo que genera la respuesta final.
Nada más es imprescindible para un primer test real: un PDF de prueba, un índice vacío y una pregunta cuya respuesta esté en la página 3. Si eso no sale citado de verdad, el resto del stack es teatro.
El flujo paso a paso
El orden que usa todo el mundo, y que funciona, es este:
Extraer. El PDF pasa a texto. Aquí el primer problema real: los PDF están diseñados para impresión, no para máquinas. Los saltos de página, los encabezados repetidos y los pies de página interrumpen la coherencia semántica. Las columnas se fusionan y las tablas se destruyen. Los saltos de línea duros parten palabras con guiones, creando tokens rotos que el modelo interpreta mal. El tamaño de chunk recomendado para documentos empresariales es 512-1.024 tokens con solapamiento de 100-200 tokens; las tablas se convierten a markdown antes de indexar para preservar las relaciones fila/columna y reducir alucinaciones numéricas.
Trocear y etiquetar. Cada fragmento lleva de dónde sale: archivo, página, sección. Sin esa etiqueta, más adelante no hay cita que podar. No es burocracia; es la única forma de que la atribución sea determinista.
Indexar. Calculas embeddings y los guardas. El hybrid search mezcla búsqueda vectorial con búsqueda por palabras; el reranking reordena el resultado con un modelo más fino. Las dos cosas juntas reducen el ruido de candidatos que hablan del mismo tema pero no responden la pregunta.
Recuperar. La pregunta se convierte en embedding (y en query de palabras) y sale una lista ordenada de fragmentos.
Generar. Esos fragmentos van al prompt. El modelo escribe con ellos delante.
Medir. Sin evaluación vuelas a ciegas. El corpus de evaluación que duele es el de las preguntas reales que la gente hacía antes de que existiera el bot, no el de las preguntas de demo que tú mismo escribiste para que salieran bien.
Hasta aquí el Lego. Ahora las tres trampas.
Trampa 1: La cita se gana, no se hereda
Si metes veinte PDF en el índice y dejas que el modelo devuelva "fuentes" al final, vas a publicar citas huérfanas: documentos que se descargaron, se embedieron y nunca sostuvieron ninguna frase de la respuesta. El modelo no tiene pudor. Si le pides que devuelva índices de fuente, te los va a inventar o te va a citar el manual que ni abrió.
La atribución hecho→fuente se hace después del modelo, con un validador espejo y poda de citas huérfanas. Es determinista y post-LLM.
La cita se gana respaldando un hecho usado, no por haber estado en el índice.
El procedimiento:
- Generas la respuesta sin pedirle al modelo IDs de fragmento.
- Partes la respuesta en hechos comprobables ("el plazo es 15 días", "la cláusula 4.2 permite X").
- Para cada hecho, buscas en los chunks que se recuperaron cuál lo sostiene con el texto a la vista.
- Si un chunk no sostiene ningún hecho usado, fuera de la lista de fuentes.
- Si un hecho no tiene chunk, o se corta de la respuesta o se marca como no respaldado. No se completa con lo que el modelo se sepa de memoria.
Esta poda no es opcional cuando el corpus incluye documentos legales, manuales técnicos o cualquier cosa donde una cita incorrecta tiene consecuencias. Que el PDF esté en el índice no te da derecho a citarlo.
Trampa 2: Las reglas se inyectan. El recall no las va a buscar
Hay dos tipos de conocimiento en un RAG: lo que debe cumplirse siempre y lo que quizá haga falta. Confundirlos es el error de arquitectura más caro.
Lo que debe cumplirse siempre (quién puede ver qué, qué está prohibido decir, qué corpus es clasificado) va en el system prompt, inyectado de oficio en cada turno. No en un PDF de política que "ya indexamos". No se delega al retrieval.
Lo que quizá haga falta (fragmentos de documentos, datos contextuales, historial relevante) sí va en el recall. El retrieval es para el conocimiento condicional; el prompt es para las reglas incondicionales.
Por qué importa: si la única barrera entre un usuario y un documento confidencial es "a ver si el embedding no lo acerca demasiado", has puesto la confidencialidad en manos de una distancia de coseno. Las actas de junta, los objetivos de adquisición, los datos personales: si están en el índice y el único candado es semántico, cualquier pregunta suficientemente cercana puede filtrarlos.
El cableado que aguanta:
- ACL y prohibiciones en el system prompt en cada turno.
- Filtrado de candidatos por rol del usuario antes de montar el prompt. El fragmento que el usuario no puede ver no entra en el contexto.
- Inventario de qué corpus está en el índice. Si no sabes si las actas de junta están dentro, el resto es decorado.
- Revisión humana para respuestas sobre material sensible. No como postureo ético: como mitigación real.
El error clásico: escribir la política de acceso en un documento, indexar ese documento y esperar que el modelo la "recuerde". El modelo no recuerda. El modelo recupera. Y solo recupera si alguien pregunta algo suficientemente cercano.
Trampa 3: El embedding ordena candidatos. No decide si hay respuesta
La similitud de embeddings mide vecindad temática. Sirve para ordenar la cola de candidatos. No certifica que alguno de esos candidatos responda la pregunta.
Un umbral absoluto de coseno (si supera X, hay respuesta) parece un botón que se calibra. No lo es. El mismo número significa cosas distintas según el dominio, el modelo de embeddings y lo limpio o sucio que esté el chunk. El resultado más cercano puede hablar del mismo tema y no contestar nada.
El sistema que contesta siempre, con el trozo más cercano, es el camino corto hacia una alucinación con cita.
El uso que no miente:
- Recuperas un top-k con hybrid search (vector + palabras).
- Reordenas ese corto con reranking.
- Un chequeo independiente del coseno pregunta: ¿este fragmento contiene una respuesta a esta pregunta concreta? Puede ser una regla explícita, un clasificador o una revisión humana en el lote de evaluación. No es "distancia al centroide".
- Si ningún fragmento pasa ese chequeo, se responde que no está en el corpus. Callarse es una feature, no un fallo.
El reranking mejora el orden de la lista. No convierte vecindad temática en verdad factual. Eso lo decide una regla de sistema, no un coseno.
Dónde la caga todo el mundo la primera vez
Tratar el índice como un disco duro infinito. El PDF retirado sigue contestando durante meses porque nadie tiene un proceso de baja. Si legal retiró un manual, ese manual tiene que salir del índice el mismo día.
Pedirle al modelo la lista de fuentes. Te va a inventar la página o a citar el documento que no usó. La atribución es post-LLM y determinista, no un campo más de la respuesta generada.
Dejar las ACL al sentido común del LLM. El modelo no tiene sentido de la confidencialidad. Tiene embeddings y probabilidades. Las reglas de acceso van en el prompt y en el filtro de candidatos, no en la esperanza de que el modelo "no lo saque".
Evaluar con preguntas de examen que escribiste tú. Las preguntas de demo salen bien porque las diseñaste para que salgan bien. El corpus de evaluación que duele es el de las preguntas reales que los usuarios hacían antes de que existiera el sistema.
Creerte los números de los whitepapers patrocinados. Cualquier proveedor de soluciones RAG va a tener cifras de mejora impresionantes. Úsalos como hipótesis de trabajo, no como suelo de comparación.
Cuando acabes de leer
Abre el flujo que ya tienes. Coge una respuesta de ayer y pregunta tres cosas: ¿cada cita sostiene un hecho que se usó, o solo se descargó el PDF? ¿La regla de quién puede ver qué estaba en el prompt o la diste por recuperada? ¿El sistema contestó porque había respuesta o porque un embedding dijo "cerca"?
Si alguna de las tres falla, no te falta un curso. Te falta una unión.
Preguntas frecuentes
¿Cuál es el tamaño de chunk recomendado para RAG con documentos empresariales?
Para documentos empresariales, 512-1.024 tokens con solapamiento de 100-200 tokens equilibra precisión y contexto. Las tablas se convierten a markdown antes de indexar para preservar las relaciones fila/columna; indexarlas como texto plano destruye su estructura y genera errores en consultas numéricas o de comparación.
¿Por qué los PDF son problemáticos como fuente para RAG?
Los PDF están diseñados para impresión, no para procesamiento automático. Los saltos de página y encabezados repetidos fragmentan la coherencia semántica. Los saltos de línea duros parten palabras con guiones, creando tokens rotos. Las columnas y tablas se fusionan en texto inutilizable. Todo eso degrada la calidad de los chunks y, con ella, la calidad de la recuperación.
¿Un umbral de similitud de embeddings sirve para saber si hay respuesta?
No. La similitud ordena candidatos por vecindad temática; no certifica que el texto responda la pregunta concreta. El mismo umbral significa cosas distintas según el dominio y el modelo de embeddings. Decidir si se responde o se dice "no está en el corpus" es una regla de sistema explícita, no un coseno.
¿Por qué las reglas de acceso no pueden ir solo en los documentos indexados?
Porque el retrieval es condicional: solo recupera lo que una consulta activa. Una política de acceso indexada solo aparece en el contexto si alguien hace una pregunta suficientemente cercana a ella. Las reglas que deben cumplirse siempre van en el system prompt, inyectadas en cada turno, independientemente de lo que se recupere.
Fuentes · 3
Aprobado por El Búfalo, editor humano responsable.