De Documentos a Bases de Conocimiento para Agentes: El Pipeline de Datos Completo
Los agentes de AI empresarial son tan buenos como su base de conocimiento. Este es el pipeline completo para convertir documentos no estructurados en conocimiento estructurado y listo para agentes — desde la ingesta de PDFs hasta fragmentos optimizados para recuperacion.
Los agentes de AI empresarial fallan por una razon predecible: la base de conocimiento es mala. No "ligeramente suboptima" — mala. Documentos ingestados sin limpieza. PDFs con errores de OCR propagandose por todo el pipeline. Fragmentos que cortan a mitad de oracion o separan una tabla de su titulo. Metadatos tan escasos que el sistema de recuperacion no puede distinguir una actualizacion de politica de 2024 de un borrador de 2019.
El resultado es un agente que alucina con confianza. Recupera un fragmento corrupto, lo trata como verdad absoluta y genera una respuesta con tono autoritario que esta equivocada. En industrias reguladas, esto no es una verguenza — es una responsabilidad legal.
La solucion no es un mejor algoritmo de recuperacion o un modelo de embeddings mas grande. La solucion es un mejor pipeline de datos. El pipeline de cinco etapas descrito aqui convierte documentos empresariales crudos en conocimiento estructurado, optimizado para recuperacion y listo para agentes. Omite cualquier etapa y la precision del agente se degrada de forma medible.
El Problema de Calidad de la Base de Conocimiento
Un estudio de Databricks a finales de 2025 encontro que el 67% de las fallas en sistemas RAG se rastreaban a problemas de calidad de datos — no fallas de recuperacion, no limitaciones del modelo, sino basura en la entrada. El desglose: 28% por errores de OCR y parseo, 19% por fragmentacion deficiente (informacion relevante dividida entre fragmentos), 12% por metadatos faltantes y 8% por contenido duplicado o contradictorio.
Esto coincide con lo que vemos en despliegues empresariales. Los equipos pasan semanas ajustando parametros de recuperacion y modelos de embeddings cuando el problema real es que los datos fuente nunca fueron limpiados adecuadamente.
La inversion en el pipeline se paga sola. Los equipos que implementan las cinco etapas tipicamente ven la precision de recuperacion mejorar de 55-65% (ingesta cruda) a 85-92% (pipeline completo). La precision de respuestas del agente sigue: de 40-50% a 75-85% en preguntas especificas del dominio.
Etapa 1: Ingestar
La primera etapa maneja la diversidad de formatos. Los documentos empresariales vienen en todos los formatos: PDF (escaneados y nativos), Word (.docx, .doc), PowerPoint, Excel, email (.eml, .msg), HTML, Markdown, exportaciones de Slack, paginas de Confluence, documentos de SharePoint y texto plano.
Cada formato requiere un parser especializado:
- PDF (nativo): Extraer texto con preservacion de layout. Herramientas como Docling o PyMuPDF lo manejan bien. Preservar estructura de tablas, encabezados y numeros de pagina.
- PDF (escaneado): OCR con Tesseract o un modelo de vision local. Espera 95-98% de precision a nivel de caracter en escaneos limpios, 85-90% en documentos antiguos o de baja calidad.
- Word/PowerPoint: Parsear la estructura XML directamente. python-docx y python-pptx manejan la mayoria de los casos, pero cuidado con imagenes incrustadas con texto, cuadros de texto y SmartArt — estos se pierden frecuentemente.
- Email: Extraer cuerpo, asunto, remitente, destinatarios, timestamps y adjuntos. Los adjuntos reingresan al pipeline como documentos separados con enlaces de metadatos padre-hijo.
- Exportaciones de Slack/Teams: Formato JSON con estructura de hilos. Preservar el contexto de hilo — los mensajes individuales sin su hilo suelen ser insignificantes.
La salida de la Etapa 1 es un formato intermedio estandarizado: texto plano con marcadores estructurales (encabezados, parrafos, tablas, listas) y metadatos de origen (nombre de archivo, formato, numero de pagina, fecha de extraccion, puntuacion de confianza de extraccion).
Benchmark de volumen: Un proyecto tipico de base de conocimiento empresarial comienza con 10,000-50,000 documentos. Throughput de ingesta en un solo servidor de 16 nucleos: aproximadamente 500-1,000 documentos por hora para formatos nativos, 100-200 por hora para PDFs escaneados que requieren OCR.
Etapa 2: Limpiar
El texto extraido crudo es ruidoso. La limpieza elimina artefactos que degradarian la calidad de recuperacion.
Correccion de OCR: Los errores comunes de OCR siguen patrones predecibles — "rn" leido como "m", "l" y "1" intercambiados, ligaduras rotas. Construye un diccionario de correccion especifico del dominio. Para un corpus legal, esto significa reconocer que "Artfculo" deberia ser "Articulo" y "dausuta" deberia ser "clausula."
Deduplicacion: Los repositorios de documentos empresariales estan llenos de duplicados — el mismo memo guardado en tres carpetas, el mismo documento de politica en un drive compartido y un wiki, adjuntos de email duplicados entre destinatarios. Usa deduplicacion basada en contenido (hash del texto normalizado) en lugar de coincidencia por nombre de archivo. Espera que el 15-30% de los documentos sean duplicados o cuasi-duplicados.
Normalizacion de formato: Estandarizar codificacion Unicode, saltos de linea, espacios en blanco y caracteres especiales. Convertir comillas tipograficas a comillas rectas. Normalizar guiones (guion largo, guion medio, guion-menos todos se convierten en guiones estandar). Esto previene fallas de recuperacion causadas por diferencias en codificacion de caracteres.
Eliminacion de texto repetitivo: Encabezados, pies de pagina, avisos de copyright, numeros de pagina, marcas de agua "CONFIDENCIAL", firmas de email. Estos agregan ruido a cada fragmento sin agregar informacion. Detectalos y eliminalos usando coincidencia de patrones.
Deteccion de idioma: En empresas multinacionales, los documentos pueden estar en multiples idiomas. Etiqueta cada documento con su idioma para procesamiento posterior (diferentes modelos de embeddings para diferentes idiomas, o traduccion como paso de preprocesamiento).
La salida de la Etapa 2 es texto limpio y normalizado con marcadores estructurales preservados y artefactos eliminados. Una revision aleatoria de 50 documentos deberia mostrar cero artefactos de OCR, cero duplicados y cero restos de texto repetitivo.
Etapa 3: Estructurar
El texto limpio necesita estructura antes de poder fragmentarse efectivamente. La deteccion de estructura identifica la organizacion semantica de cada documento.
Deteccion de secciones: Identificar encabezados, subencabezados y la estructura jerarquica del documento. Un documento de politica tiene capitulos, secciones y subsecciones. Un manual tecnico tiene secciones numeradas. Un hilo de email tiene mensajes individuales con timestamps.
Extraccion de metadatos: Extraer informacion estructurada del contenido: fechas, numeros de version, nombres de autores, referencias a departamentos, nombres de productos, citas de regulaciones. Estos metadatos se convierten en atributos filtrables en el sistema de recuperacion.
Reconocimiento de entidades: Identificar entidades nombradas relevantes para el dominio — nombres de productos, nombres de clientes, identificadores de regulaciones (GDPR Articulo 6, ISO 27001 Seccion A.12), codigos de proyectos internos. Las etiquetas de entidades permiten recuperacion precisa: "Muestrame todos los documentos que mencionan Proyecto Phoenix" devuelve resultados basados en coincidencia de entidades, no busqueda por palabras clave.
Extraccion de tablas: Las tablas en documentos contienen informacion densa y estructurada. Extractalas como datos estructurados (filas y columnas) en lugar de aplanarlas a texto. Una tabla financiera aplanada a texto se convierte en "Ingresos Q1 2025 $4.2M Q2 2025 $4.8M" — inutil para consultas de comparacion. Preservada como datos estructurados, el sistema de recuperacion puede responder "Cual fue el ingreso del Q2 2025?" con precision.
Resolucion de referencias cruzadas: Los documentos referencian otros documentos. "Como se describe en la Politica 4.2.1" deberia enlazar a la Politica 4.2.1 en la base de conocimiento. Resuelve referencias cruzadas internas para crear un grafo de documentos que el agente pueda recorrer.
Etapa 4: Fragmentar
La fragmentacion es donde la mayoria de los pipelines de bases de conocimiento tienen exito o fracasan. El objetivo es dividir documentos en piezas lo suficientemente pequenas para embeddings y recuperacion efectiva, pero lo suficientemente grandes para preservar coherencia semantica.
Fragmentacion de Tamano Fijo
Dividir texto cada N tokens (tipicamente 256-512). Rapido, simple y poco inteligente. Los fragmentos de tamano fijo cortan a mitad de oracion, separan preguntas de respuestas y parten tablas por la mitad. Precision de recuperacion con fragmentos de tamano fijo: tipicamente 60-70%.
Caso de uso: prototipos rapidos, aplicaciones de bajo riesgo, situaciones donde la velocidad importa mas que la calidad.
Fragmentacion a Nivel de Oracion
Dividir en limites de oracion, luego agrupar oraciones hasta alcanzar el tamano objetivo del fragmento. Mejor que tamano fijo porque los fragmentos respetan la estructura de oraciones. Aun tiene problemas con parrafos que construyen un argumento a lo largo de 5-6 oraciones — dividir despues de la oracion 3 pierde la conclusion.
Precision de recuperacion: tipicamente 70-80%.
Fragmentacion Semantica
Usar un LLM o modelo de embeddings para identificar limites semanticos — puntos donde el tema cambia. Agrupar oraciones semanticamente relacionadas en fragmentos independientemente de su longitud (dentro de limites). Esto preserva la coherencia de explicaciones, argumentos y procedimientos.
Precision de recuperacion: tipicamente 80-90%.
El costo de la fragmentacion semantica es tiempo de computo. Un LLM local procesando cada documento para identificar limites semanticos agrega 5-10x a la etapa de fragmentacion. Para bases de conocimiento empresariales donde la precision importa, esta compensacion vale la pena.
Estrategia de Solapamiento
Independientemente del metodo de fragmentacion, usa solapamiento — incluye las ultimas 1-2 oraciones de cada fragmento como las primeras oraciones del siguiente fragmento. Esto previene perdida de informacion en los limites de fragmentos. Un solapamiento del 10-15% del tamano del fragmento es estandar.
Preservar Contexto
Cada fragmento debe llevar su contexto: el titulo del documento, encabezado de seccion, numero de pagina y resumen de la seccion anterior. Sin contexto, un fragmento que dice "El umbral es 5%" no tiene sentido. Con contexto — "Documento: Politica de Riesgo 2026 > Seccion 3.2: Limites de Riesgo Crediticio > El umbral es 5%" — el sistema de recuperacion puede emparejarlo con la consulta correcta.
Etapa 5: Exportar
La etapa final produce el formato de salida que tu sistema de agentes consume. La mayoria de los despliegues empresariales necesitan dos salidas:
Embeddings listos para vectores: Cada fragmento embebido usando un modelo apropiado para tu dominio e idioma. Almacenar embeddings con sus metadatos (documento fuente, seccion, fecha, entidades) en una base de datos vectorial. Esto potencia la generacion aumentada por recuperacion (RAG).
JSONL para fine-tuning: El mismo contenido formateado como pares de instruccion/respuesta para fine-tuning. Esto permite un enfoque complementario donde el modelo aprende conocimiento del dominio directamente, reduciendo la dependencia de recuperacion para consultas comunes.
Producir ambas salidas desde un unico pipeline es mas eficiente que ejecutar dos pipelines separados. Las etapas de ingesta, limpieza y estructuracion son identicas — solo el formato de exportacion difiere.
Validacion de Calidad
Antes de desplegar la base de conocimiento, validala.
Pruebas de precision de recuperacion: Prepara 100-200 consultas de prueba con respuestas conocidas. Ejecuta cada consulta contra la base de conocimiento y verifica si el fragmento correcto aparece en los 5 primeros resultados. Objetivo: 85%+ para despliegue en produccion.
Revisiones puntuales de calidad de respuestas: Haz que expertos de dominio revisen 50 respuestas de agente generadas desde la base de conocimiento. Puntua cada respuesta en precision, completitud y atribucion de fuentes. Cualquier respuesta que cite una fuente inexistente o incorrecta indica una falla del pipeline.
Analisis de cobertura: La base de conocimiento cubre todos los temas que se espera que el agente maneje? Mapea los temas a documentos e identifica brechas — estos son temas donde el agente alucinara porque no tiene material fuente.
Auditoria de frescura: Verifica las fechas de los documentos. Si la version mas reciente de una politica es de 2023 pero existe una actualizacion de 2025 en otra carpeta, la base de conocimiento esta desactualizada. Implementa una verificacion de frescura que senale documentos con versiones mas nuevas disponibles.
Ventaja On-Premise
Todo el pipeline se ejecuta en infraestructura local. Los documentos — que a menudo contienen informacion comercial propietaria, datos de clientes, informacion personal y secretos comerciales — nunca salen de la red de la organizacion.
Esto no es solo una casilla de cumplimiento. Es un requisito practico para los tipos de documentos que forman bases de conocimiento empresariales: politicas de RRHH con detalles de compensacion, memos legales con estrategia de litigio, informes financieros con datos no publicos, documentos de ingenieria con secretos comerciales.
El procesamiento on-premise tambien elimina la dependencia de proveedores. Cuando tu pipeline de documentos se ejecuta en un servicio de nube de terceros, ese servicio controla tu calendario de actualizaciones, tu soporte de formatos y tus precios. Cuando se ejecuta localmente, tu controlas los tres.
Los requisitos de infraestructura son modestos. Un solo servidor con 64GB de RAM, 16 nucleos y una GPU NVIDIA A100 o equivalente maneja las cinco etapas del pipeline para bases de conocimiento de hasta 100,000 documentos. Corpus mas grandes se benefician de paralelizacion entre multiples nodos, pero el pipeline en si es embarazosamente paralelo — cada documento fluye por las etapas de forma independiente.
Your data is the bottleneck — not your models.
Ertas Data Suite turns unstructured enterprise files into AI-ready datasets — on-premise, air-gapped, with full audit trail. One platform replaces 3–7 tools.
Lectura Adicional
- Construyendo Bases de Conocimiento para Agentes AI Empresariales — Consideraciones estrategicas para arquitectura y gobernanza de bases de conocimiento empresariales.
- Guia de Preparacion de Datos para AI Empresarial — El panorama mas amplio de preparacion de datos para despliegues de AI empresarial.
- Documentos No Estructurados como Datos de Entrenamiento para AI — Como manejar el 80% de datos empresariales que vive en formatos no estructurados.
Turn unstructured data into AI-ready datasets — without it leaving the building.
On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.
Keep reading
Why Your RAG Pipeline Breaks on Client-Uploaded Data (and How to Fix It)
Malformed PDFs, encoding issues, PII contamination, and duplicate content silently degrade RAG retrieval. Here is how to build a data quality pipeline upstream of your vector database.
Preparing Tool-Calling Datasets for Enterprise AI Agents: An On-Premise Workflow
AI agents need tool-calling training data to reliably select and invoke the right tools. Here's how to prepare function-calling datasets from enterprise documents — entirely on-premise.
Preparing RAG Datasets vs Fine-Tuning Datasets: Different Pipelines, Same Source Data
RAG needs chunked, retrieval-optimized text. Fine-tuning needs input/output pairs. Both start from the same raw documents. Here's how to run parallel preparation pipelines from a single source.