Construyendo Bases de Conocimiento para Agentes de IA a Partir de Documentos Empresariales On-Premise

El agente de IA es tan bueno como la base de conocimiento detrás de él. Puedes desplegar el mejor modelo en el mejor hardware con el mejor framework de agentes, y el agente seguirá dando respuestas incorrectas si la base de conocimiento de la que recupera contiene documentos mal parseados, texto mal fragmentado, contenido duplicado o información desactualizada.

Esto no es teórico. En despliegues de agentes empresariales, la calidad de recuperación — la precisión y relevancia de lo que devuelve el vector store — es el predictor individual más fuerte de la calidad de salida del agente. Una base de conocimiento bien construida con un modelo de 7B consistentemente supera a una base de conocimiento desordenada con un modelo de 70B. El cuello de botella casi siempre son los datos, no el modelo.

Esta guía recorre el pipeline completo para construir una base de conocimiento de agentes a partir de documentos empresariales, completamente on-premise. Ningún dato sale de tu red. No se llaman APIs externas. Cada componente se ejecuta localmente.

Panorama del Pipeline

Raw Enterprise Documents
    ↓
Step 1: Document Ingestion (Parse)
    ↓
Step 2: Text Cleaning
    ↓
Step 3: Chunking with Metadata
    ↓
Step 4: Embedding (Local Model)
    ↓
Step 5: Vector Store Indexing
    ↓
Step 6: Retrieval Testing and Validation
    ↓
Agent RAG Queries

Cada paso tiene requisitos específicos, modos de fallo comunes y métricas de calidad. Omitir o acortar cualquier paso degrada la calidad final de la base de conocimiento — y por extensión, la calidad de salida del agente.

Paso 1: Ingesta de Documentos

Los documentos empresariales vienen en docenas de formatos: PDFs (basados en texto y escaneados), documentos Word (.docx, .doc), hojas de cálculo Excel, presentaciones PowerPoint, emails (.eml, .msg), páginas HTML, archivos de texto plano, y a veces formatos propietarios de sistemas empresariales.

Cómo Se Ve un Buen Parsing

Un buen parsing de documentos preserva la estructura y significado del documento original:

Encabezados de sección son identificados y etiquetados, no aplanados en texto de cuerpo
Tablas son extraídas como datos estructurados (filas y columnas preservadas), no convertidas en flujos de texto
Listas mantienen su orden y anidamiento
Headers y footers son identificados y separados del contenido principal
Números de página son removidos del texto pero registrados como metadatos
Imágenes con texto (gráficos, diagramas con etiquetas) pasan por OCR y el texto es extraído
Señales de formato (negrita, cursiva, subrayado) que transmiten significado son preservadas o anotadas

Desafíos Específicos por Formato

PDFs son el formato más común y más problemático. Un PDF basado en texto generado desde Word es sencillo — la capa de texto es extraíble. Un PDF escaneado es una imagen que requiere OCR. Un PDF generado desde una página web puede tener disposiciones de columnas inusuales. Un PDF con campos de formulario tiene datos en la capa de formulario que la extracción simple de texto omite.

Documentos Word son generalmente más fáciles de parsear, pero formato complejo — tablas anidadas, cuadros de texto, SmartArt, objetos incrustados — puede confundir a los extractores. Los cambios rastreados y comentarios pueden o no ser relevantes dependiendo del caso de uso.

Hojas de cálculo Excel presentan un desafío estructural: la relación entre celdas (qué encabezado va con qué valor) es espacial, no textual. Aplanar una hoja de cálculo a texto pierde estas relaciones. Las celdas combinadas, múltiples hojas y fórmulas agregan complejidad.

Emails tienen metadatos (de, para, fecha, asunto) que a menudo son más importantes para la recuperación que el texto del cuerpo. Las cadenas de email tienen artefactos de reenvío, marcadores de respuesta y bloques de firma que deben limpiarse. Los archivos adjuntos necesitan manejo separado.

Enfoque Práctico

Usa un parser de documentos que maneje múltiples formatos con lógica específica por formato. Ejecuta el parser en una muestra de tu corpus de documentos e inspecciona manualmente la salida. Marca los documentos que fallen en las verificaciones de calidad — errores de OCR por encima de un umbral, secciones faltantes, tablas corruptas — para revisión manual o reprocesamiento.

Métrica de calidad: Tasa de precisión de parsing — ¿qué porcentaje de documentos se parsean sin errores estructurales significativos? Objetivo: más del 90% para documentos basados en texto, más del 80% para documentos escaneados (con OCR).

Paso 2: Limpieza de Texto

El texto parseado no es texto limpio. La limpieza elimina artefactos que degradan la calidad de recuperación sin agregar valor informativo.

Qué Eliminar

Boilerplate: Headers, footers, avisos de copyright, disclaimers de confidencialidad que se repiten en cada página. Estos agregan ruido al vector store sin agregar valor de recuperación.
Números de página y encabezados corrientes: "Página 47 de 132" y "Acme Corp — Confidencial" en cada página contaminan el espacio de embedding.
Artefactos de OCR: Caracteres mal reconocidos, palabras rotas, texto ilegible de escaneos de mala calidad. Errores leves de OCR (sustituir "l" por "1") pueden corregirse con post-procesamiento. Errores graves pueden requerir re-escaneo o transcripción manual.
Problemas de codificación: Normalización Unicode, comillas tipográficas vs. comillas rectas, guiones largos vs. guiones cortos. Estos parecen menores pero causan fallos en la detección de duplicados (el mismo texto con diferente codificación se trata como diferente).
Contenido duplicado: El mismo documento existe en múltiples ubicaciones (adjunto de email, drive compartido, sistema de gestión documental). El mismo párrafo aparece en múltiples documentos (cláusulas estándar, secciones de boilerplate).

Qué Preservar

Terminología de dominio: No "limpies" términos técnicos, abreviaciones o jerga. "ICD-10-CM" no debería normalizarse a "ICD 10 CM."
Datos numéricos: Cifras, medidas, fechas, valores financieros. Estos son de alto valor para la recuperación.
Estructura del documento: Saltos de sección, jerarquía de encabezados, estructura de listas. Estos informan la fragmentación.
Metadatos: Autor, fecha, tipo de documento, versión, departamento. Estos permiten recuperación filtrada.

Estrategia de Deduplicación

La deduplicación opera en dos niveles:

A nivel de documento: Detección de duplicados exactos y casi-duplicados. La comparación basada en hash captura duplicados exactos. La comparación basada en similitud (MinHash, SimHash) captura casi-duplicados — documentos que son más del 90% similares pero tienen diferencias menores (números de versión, fechas, formato).

A nivel de párrafo: Cláusulas estándar, secciones de boilerplate y texto frecuentemente copiado aparecen en muchos documentos. Estos deben deduplicarse para evitar que el vector store sobre-represente texto común a expensas de contenido único y de alto valor.

Métrica de calidad: Tasa de deduplicación — ¿qué porcentaje de contenido duplicado o casi-duplicado fue eliminado? Objetivo: más del 95% de duplicados eliminados mientras se retiene cero contenido único.

Paso 3: Fragmentación con Metadatos

La fragmentación es donde la mayoría de las construcciones de bases de conocimiento fallan. El enfoque predeterminado — dividir texto cada 512 o 1,024 caracteres — es simple de implementar y produce resultados malos de manera confiable.

Por Qué Falla la Fragmentación por Conteo de Caracteres

La fragmentación por conteo de caracteres no tiene conciencia de la estructura del documento. Divide:

Una tabla entre la fila de encabezado y las filas de datos, creando un fragmento con nombres de columna pero sin datos y otro fragmento con datos pero sin nombres de columna
Una declaración condicional entre la condición y la consecuencia ("Si el paciente tiene diabetes..." en un fragmento, "...entonces prescribir metformina" en el siguiente)
Una lista numerada entre ítems, perdiendo el contexto de qué trata la lista
Un párrafo a mitad de oración, creando fragmentos que comienzan y terminan con fragmentos de oración

Cada una de estas divisiones crea fragmentos que son individualmente sin sentido o engañosos. Cuando el agente recupera un fragmento que dice "entonces prescribir metformina" sin la condición, puede recomendar metformina incondicionalmente.

Fragmentación Semántica

La fragmentación semántica divide en límites naturales de tema:

Encabezados de sección: Dividir en cada encabezado. Esto preserva las unidades lógicas del documento.
Límites de párrafo: Dentro de una sección, dividir en saltos de párrafo. Cada párrafo típicamente aborda un solo punto.
Límites de tabla: Mantener las tablas intactas como fragmentos individuales. Incluir el encabezado de tabla con cada fragmento de tabla.
Límites de lista: Mantener las listas intactas. Incluir el texto introductorio con los ítems de la lista.

Configuración de Fragmentación

Parámetro	Rango Recomendado	Justificación
Tamaño objetivo del fragmento	300-800 tokens	Suficientemente grande para contexto, suficientemente pequeño para recuperación precisa
Tamaño máximo del fragmento	1,200 tokens	Límite duro para evitar que fragmentos sobredimensionados dominen las ventanas de contexto
Solapamiento	50-100 tokens	Mantiene la continuidad de contexto entre fragmentos adyacentes
Tamaño mínimo del fragmento	50 tokens	Evitar micro-fragmentos que carecen de contexto

Etiquetado de Metadatos

Cada fragmento debe llevar metadatos que permitan recuperación filtrada y trazabilidad:

source_document: Nombre de archivo o ID de documento del documento original
source_path: Ubicación del documento original en el sistema de archivos o DMS
document_date: Cuándo fue creado o actualizado por última vez el documento
document_author: Quién creó el documento
document_type: Política, procedimiento, guía, contrato, email, reporte, etc.
section_title: El encabezado de la sección de donde viene este fragmento
chunk_index: Posición de este fragmento dentro del documento (para ordenamiento)
classification: Nivel de confidencialidad, departamento, unidad de negocio

Estos metadatos sirven tres propósitos:

Recuperación filtrada: "Encontrar información sobre política de viajes" → filtrar por document_type=política, buscar "viajes"
Ponderación por recencia: Preferir fragmentos de documentos más recientes cuando existen múltiples versiones
Pista de auditoría: Rastrear cualquier respuesta del agente hasta el fragmento específico y documento fuente

Métrica de calidad: Coherencia de fragmentos — para una muestra de fragmentos, ¿cada fragmento contiene una pieza completa y auto-contenida de información? Objetivo: más del 80% de los fragmentos son unidades coherentes por sí mismos.

Paso 4: Embedding

El embedding convierte fragmentos de texto en vectores numéricos que capturan significado semántico. Conceptos similares producen vectores similares, permitiendo búsqueda semántica.

Eligiendo un Modelo de Embedding

Para despliegue on-premise, el modelo de embedding debe ejecutarse localmente. Sin llamadas a APIs externas. Las mejores opciones actuales:

Modelo	Dimensiones	Velocidad (CPU)	Calidad (MTEB)	Tamaño
all-MiniLM-L6-v2	384	Rápida	Buena	80MB
E5-large-v2	1,024	Media	Muy buena	1.3GB
BGE-large-en-v1.5	1,024	Media	Muy buena	1.3GB
E5-mistral-7b-instruct	4,096	Lenta (GPU necesaria)	Excelente	14GB

Para la mayoría de las bases de conocimiento empresariales, E5-large-v2 o BGE-large-en-v1.5 ofrecen el mejor balance de calidad y velocidad. Funcionan bien en CPU para embedding por lotes y producen vectores de alta calidad para búsqueda semántica.

Para bases de conocimiento muy grandes (más de 500K fragmentos) donde la calidad de recuperación es primordial, E5-mistral-7b-instruct proporciona mejor comprensión semántica pero requiere GPU para velocidad de embedding razonable.

Procesamiento por Lotes

Los corpus de documentos empresariales son grandes. Hacer embedding de 100,000 fragmentos uno a la vez es lento. El procesamiento por lotes — haciendo embedding de 32-128 fragmentos a la vez — es 10-50x más rápido.

Para un corpus de 100,000 documentos produciendo aproximadamente 500,000 fragmentos:

Modelo de Embedding	Hardware	Tiempo Estimado
all-MiniLM-L6-v2	CPU (16 cores)	2-4 horas
E5-large-v2	CPU (16 cores)	8-16 horas
E5-large-v2	GPU (RTX 4090)	1-2 horas
E5-mistral-7b-instruct	GPU (RTX 4090)	6-12 horas

Planifica para que el embedding inicial tome horas, no minutos. Las actualizaciones subsiguientes (solo documentos nuevos o modificados) son incrementales y mucho más rápidas.

Consistencia

Usa el mismo modelo de embedding para indexación y para consultas. Si haces embedding de tus documentos con E5-large-v2, las consultas de tu agente también deben hacerse con E5-large-v2. Mezclar modelos de embedding produce vectores en diferentes espacios, haciendo la búsqueda por similitud sin sentido.

Paso 5: Indexación en Vector Store

Los vectores embebidos necesitan almacenarse en una base de datos vectorial que soporte búsqueda eficiente por similitud. Para despliegue on-premise:

Vector Store	Fortalezas	Límite de Escala	Licencia
ChromaDB	Configuración simple, buena para prototipado	~1M vectores	Apache 2.0
Qdrant	Listo para producción, soporte de filtrado, alto rendimiento	100M+ vectores	Apache 2.0
Milvus	Distribuido, escalamiento horizontal	Miles de millones de vectores	Apache 2.0
Weaviate	Búsqueda híbrida (vector + keyword), buen filtrado	100M+ vectores	BSD-3

Para la mayoría de los despliegues empresariales (10K-500K documentos, 50K-2.5M fragmentos), Qdrant es la opción recomendada. Maneja la escala, soporta filtrado de metadatos (esencial para uso empresarial) y funciona bien en un solo servidor.

Para despliegues muy grandes (más de 1M documentos), considera Milvus por su arquitectura distribuida.

Configuración del Índice

Métrica de distancia: Similitud coseno es el valor predeterminado y funciona bien para la mayoría de los modelos de embedding de texto
Tipo de índice: HNSW (Hierarchical Navigable Small World) para búsqueda aproximada de vecinos más cercanos — rápida y precisa
ef_construction: Valores más altos (128-256) construyen un mejor índice al costo de mayor tiempo de construcción. Vale la inversión para despliegues empresariales.
m: Número de conexiones por nodo en el grafo HNSW. 16-32 es típico. Valores más altos mejoran el recall al costo de memoria.

Probando el Índice

Antes de conectar el agente, prueba el vector store directamente:

results = vector_store.query(
    query="What is the company travel policy?",
    top_k=10,
    filters={"document_type": "policy"}
)

for result in results:
    print(f"Score: {result.score:.3f}")
    print(f"Source: {result.metadata['source_document']}")
    print(f"Text: {result.text[:200]}...")
    print()

Ejecuta 50-100 consultas representativas que reflejen lo que los usuarios realmente preguntarán al agente. Para cada consulta, evalúa manualmente si los fragmentos recuperados son relevantes y suficientes para responder la pregunta.

Métrica de calidad: Hits@10 — ¿para qué porcentaje de consultas de prueba la respuesta correcta está contenida en los 10 fragmentos principales recuperados? Objetivo: más del 85%. Si esto está por debajo del 70%, arregla la fragmentación y limpieza antes de conectar el agente.

Paso 6: Pruebas de Recuperación y Validación

Este es el paso que la mayoría de los equipos omiten, y es el paso que más importa. Probar la base de conocimiento antes de conectar el agente separa el problema de calidad de recuperación del problema de calidad del modelo.

Protocolo de Prueba

Crea un conjunto de prueba: 50-100 preguntas que representen las consultas que recibirá tu agente. Incluye preguntas fáciles (la respuesta está en un solo documento obvio), preguntas medianas (la respuesta requiere encontrar el documento correcto entre muchos), y preguntas difíciles (la respuesta requiere sintetizar información de múltiples documentos).
Etiqueta la verdad base: Para cada pregunta, identifica el/los documento(s) fuente correcto(s) y la respuesta correcta. Esto requiere participación de expertos del dominio.
Ejecuta la recuperación: Consulta el vector store con cada pregunta de prueba. Registra los 10 fragmentos principales recuperados.
Evalúa:
- Precisión de recuperación: ¿Qué porcentaje de fragmentos recuperados son realmente relevantes?
- Recall de recuperación: ¿Qué porcentaje de fragmentos relevantes fueron recuperados?
- Cobertura de respuesta: ¿Los fragmentos recuperados contienen suficiente información para responder la pregunta?
Identifica fallos: Para preguntas donde la recuperación falló, diagnostica por qué:
- El fragmento no existe (el documento no fue ingestado o fue filtrado)
- El fragmento existe pero no fue recuperado (desajuste de embedding, la formulación de la consulta no coincide con el lenguaje del documento)
- El fragmento fue recuperado pero está muy fragmentado (una mala división de fragmentación separó la información relevante)
- Se recuperó un fragmento incorrecto (contenido duplicado o engañoso superó en ranking al fragmento correcto)
Arregla y re-prueba: Aborda las causas raíz y re-ejecuta la prueba. Itera hasta que la calidad de recuperación alcance tu umbral.

Errores Comunes y Sus Soluciones

Error	Síntoma	Solución
Fragmentos muy grandes (mas de 1,500 tokens)	Los fragmentos recuperados contienen mezcla de información relevante e irrelevante	Reducir el tamaño objetivo de fragmento a 300-800 tokens con límites semánticos
Fragmentos muy pequeños (menos de 100 tokens)	Los fragmentos recuperados carecen del contexto necesario para responder la pregunta	Aumentar el tamaño mínimo del fragmento; agregar solapamiento; incluir encabezados de sección
Sin filtrado de metadatos	La recuperación retorna fragmentos de tipos de documento incorrectos o versiones desactualizadas	Agregar metadatos a los fragmentos; usar consultas filtradas
Sin deduplicación	La misma información recuperada 3-5 veces de diferentes copias	Ejecutar deduplicación antes del embedding
Sin manejo de PII/PHI	Datos sensibles expuestos a través de la recuperación	Ejecutar detección y redacción de PII/PHI antes de la fragmentación
Desajuste de modelo de embedding	La recuperación retorna resultados semánticamente incorrectos	Asegurar que el mismo modelo de embedding se use para indexación y consultas
Sin solapamiento entre fragmentos	Preguntas sobre información en los límites de fragmentos retornan resultados irrelevantes	Agregar 50-100 tokens de solapamiento entre fragmentos adyacentes

Consideraciones de Escala

Corpus Pequeño (1K-10K Documentos)

Manejable con procesos semi-manuales. Un solo ingeniero de datos puede parsear, limpiar, fragmentar y validar la base de conocimiento en 1-2 semanas. Los problemas de calidad pueden identificarse y arreglarse por inspección manual de muestras.

Infraestructura: Un solo servidor con CPU es suficiente. ChromaDB o Qdrant. Embedding con all-MiniLM o E5-large en CPU.

Corpus Mediano (10K-100K Documentos)

Requiere pipelines automatizados con controles de calidad. La inspección manual de cada documento no es factible. Puntuación de calidad automatizada, deduplicación y fragmentación con validación por muestreo.

Infraestructura: Servidor con GPU recomendado para velocidad de embedding. Qdrant para almacenamiento vectorial. Espera 1-2 días para el embedding inicial.

Corpus Grande (100K+ Documentos)

Requiere un pipeline de datos de producción con monitoreo, manejo de errores, actualizaciones incrementales y dashboards de métricas de calidad. Los nuevos documentos deben ser procesables sin re-hacer embedding del corpus completo.

Infraestructura: Servidor GPU dedicado o cluster pequeño. Qdrant o Milvus. Considera particionar el vector store por tipo de documento o departamento para mejor rendimiento de recuperación.

Características del pipeline a escala:

Ingesta automatizada de documentos desde sistemas fuente (DMS, SharePoint, archivos de email)
Monitoreo continuo de calidad (drift de distribución de embeddings, degradación de precisión de recuperación)
Actualizaciones incrementales (agregar nuevos documentos, actualizar documentos modificados, eliminar documentos borrados)
Rastreo de versiones (qué versión de cada documento está actualmente en la base de conocimiento)

El Requisito de Auditoría

Cada documento en la base de conocimiento debe ser rastreable a su fuente. Esto no es solo buena práctica — es un requisito para industrias reguladas y una necesidad práctica para depuración.

La cadena de auditoría:

Documento fuente → identificado por ID de documento, ruta de archivo y hash
Texto parseado → almacenado con timestamp de parseo y versión del parser
Texto limpio → almacenado con las reglas de limpieza aplicadas
Fragmentos → almacenados con ID de fragmento, ID del documento padre y posición del fragmento
Embeddings → almacenados con versión del modelo de embedding y timestamp
Eventos de recuperación → registrados con consulta, IDs de fragmentos recuperados, puntuaciones de relevancia y timestamp

Cuando el agente da una respuesta incorrecta, esta cadena te permite rastrear hacia atrás: ¿qué fragmentos recuperó el agente? ¿Eran esos fragmentos relevantes? ¿De qué documento fuente vinieron? ¿Era el documento fuente correcto y actual? ¿Fue el fragmento correctamente parseado y limpiado?

Esta trazabilidad es lo que separa una base de conocimiento de producción de un prototipo. También es lo que hace posible la mejora continua — puedes identificar y arreglar sistemáticamente los problemas de calidad de datos que causan errores del agente, en lugar de adivinar.

Dónde Empezar

Haz inventario de tus documentos — ¿qué tienes, dónde está almacenado, cuánto hay, qué tan actual es?
Elige un alcance enfocado — empieza con un tipo de documento o un departamento, no con todo el corpus empresarial
Construye el pipeline — parsea, limpia, fragmenta, haz embedding, indexa. Automatiza cada paso.
Prueba la recuperación — más de 50 consultas, evaluación manual, identifica fallos
Arregla la calidad de datos — aborda las causas raíz de los fallos de recuperación
Conecta el agente — solo después de que la calidad de recuperación alcance tu umbral
Monitorea e itera — rastrea la calidad de recuperación a lo largo del tiempo, actualiza documentos, arregla problemas recién descubiertos

La base de conocimiento no es una construcción única. Los documentos cambian, se crean nuevos documentos, los documentos antiguos se vuelven obsoletos. Una base de conocimiento de producción tiene un pipeline de mantenimiento que la mantiene actual y precisa. Planifica el mantenimiento continuo desde el inicio, no como algo posterior.