Preparar documentación para RAG y Copilot interno

Muchas empresas llegan a un proyecto de RAG o Copilot interno pensando que el reto principal es elegir modelo o proveedor. En la practica, el cuello de botella suele estar antes: en la documentacion. Segun McKinsey (2025), el 60% de las implantaciones de IA generativa en empresas encuentran la calidad del dato como principal freno. Con RAG, ese problema se concentra en la base documental.

La pregunta que mas repiten los equipos antes de arrancar es: "No sabemos si nuestros documentos estan preparados." Este articulo responde esa pregunta de forma directa. Sin entrar en arquitectura tecnica, sino en lo que depende del equipo: que documentos sirven, cuales generan ruido y como preparar la base documental antes del primer sprint.

Por que la preparacion documental determina el resultado del RAG

RAG (Retrieval-Augmented Generation) funciona en dos fases. Primero, el sistema busca en tu base documental los fragmentos mas relevantes para la pregunta del usuario. Segundo, el modelo de lenguaje usa esos fragmentos como contexto para generar la respuesta. Si los fragmentos recuperados son obsoletos, ambiguos o contradictorios, la respuesta sera mala aunque el modelo sea excelente. Segun Azure AI Search (2025), la precision del retrieval es el factor que mas peso tiene en la calidad final de las respuestas.

El modelo no sabe distinguir entre un documento actualizado de esta semana y uno de hace cuatro anos. Tampoco detecta que dos procedimientos internos se contradicen. Devuelve la informacion que encuentra con igual confianza. Por eso la calidad de la entrada determina directamente la calidad de la salida. No es una cuestion tecnica: es una cuestion de gobierno documental.

Que documentos funcionan bien en RAG y Copilot

Funcionan bien los documentos orientados a procesos, criterio y contexto operativo. Es decir, materiales que ya ayudan a una persona nueva o a un equipo transversal a entender como hacer algo, cuando aplica una excepcion y donde mirar si hay dudas. Cuanto mas operativo y mantenido este el documento, mas util suele resultar para un sistema RAG o Copilot interno.

Documentos de proceso y criterio operativo

Los procedimientos operativos estandar (SOPs), manuales de proceso y guias paso a paso son el tipo de documento mas util para RAG. Contienen reglas, contexto y lenguaje de negocio. No obligan al sistema a improvisar: le permiten recuperar piezas concretas y apoyarse en ellas para responder. La condicion es que esten versionados, con fecha de ultima revision visible y con un responsable asignado.

FAQs internas y bases de conocimiento

Las bases de conocimiento de soporte, los repositorios de incidencias resueltas y las FAQs internas funcionan especialmente bien porque ya estan estructuradas en torno a preguntas y respuestas. El sistema RAG puede recuperar la respuesta directamente sin necesidad de sintetizar. La condicion es que el mantenimiento sea activo: una FAQ desactualizada genera mas dano que no tenerla.

Politicas, procedimientos y normativas

Las politicas internas, normativas corporativas y documentos de compliance funcionan bien porque aterrizan que se puede hacer, que no y quien aprueba. La condicion critica aqui es que el texto sea vigente y que el owner este identificado. Indexar una politica de hace tres versiones puede generar respuestas incorrectas con apariencia de autoridad.

Documentos que generan problemas

No todos los documentos que existen en tu empresa son utiles para RAG. Algunos generan mas ruido que valor. Indexarlos sin filtro previo puede empeorar la calidad de las respuestas respecto a no tenerlos. La regla general: si el documento no ayudaria a una persona nueva a hacer su trabajo, no ayudara al sistema RAG tampoco.

• Documentos duplicados o con multiples versiones sin control: el sistema no sabe cual es la vigente y puede mezclar informacion de distintas epocas.
• PDFs escaneados sin OCR: el texto no es extraible y el sistema los ignora o genera errores.
• Correos electronicos y chats exportados: contienen conversaciones sin contexto suficiente, ruido alto y escasa estructura.
• Documentos de hace mas de tres anos sin revision: pueden ser tecnicamente accesibles pero contener informacion obsoleta que el sistema devolvera con igual confianza que la actual.
• Ficheros con contenido mayoritariamente visual: presentaciones con graficos sin texto alternativo, tablas en imagen o diagramas sin descripcion.
• Documentacion sin owner ni fecha: sin responsable asignado, no hay garantia de que el contenido sea fiable ni de que se actualizara.

Los 5 requisitos reales para que tu base documental funcione en RAG

1. 1Texto extraible. Los documentos deben ser digitales y con texto seleccionable. PDF con texto real, Word, Markdown, paginas de wiki, Google Docs o Confluence. Un PDF escaneado sin OCR es opaco para el sistema y quedara fuera del indice.
2. 2Estructura minima identificable. Titulos, secciones y parrafos que un programa pueda distinguir. No hace falta formato perfecto, pero si que sea claro donde empieza un tema y donde acaba. Los documentos completamente planos sin jerarquia producen chunks de baja calidad.
3. 3Informacion actualizada y coherente. RAG no distingue entre documentos de esta semana y de hace cuatro anos. Si hay versiones contradictorias indexadas a la vez, las respuestas seran inconsistentes. La regla practica: si no puedes decir quien es el owner y cuando fue la ultima revision, no lo indexes todavia.
4. 4Densidad de informacion util. Con menos de 50-100 documentos relevantes y actualizados, el sistema tendra poco contenido para trabajar. No se trata de cantidad bruta, sino de cuantos documentos responden realmente las preguntas del caso de uso definido.
5. 5Accesibilidad tecnica. Los documentos deben poder extraerse de forma programatica. SharePoint, Confluence, Google Drive, un gestor documental con API o un servidor de archivos con estructura razonable son viables. Documentacion repartida en emails, chats y discos duros personales requiere consolidacion previa.

Senales de que tus documentos no estan listos

• No sabes con certeza cuantos documentos activos tienes ni donde estan todos.
• Hay varios ficheros con el mismo nombre o contenido similar sin saber cual es el definitivo.
• La documentacion no se ha revisado en mas de dos anos de forma sistematica.
• No hay un responsable claro de cada area de documentacion.
• Una parte significativa esta en PDFs escaneados, imagenes o presentaciones sin texto alternativo.
• El equipo que usaria el copilot no confia en que la documentacion existente refleje como se trabaja realmente hoy.

Como preparar la documentacion en la practica

Preparar la base documental para RAG no requiere una transformacion documental completa antes de empezar. Requiere un enfoque pragmatico: identificar el subconjunto de documentacion que cubre el caso de uso, evaluarlo con criterios claros y corregir solo lo que impide el funcionamiento. No es necesario que todo este perfecto para lanzar un piloto util.

Auditoria documental previa

Antes de indexar nada, conviene hacer un inventario rapido: cuantos documentos existen, en que formatos, cuando fue la ultima actualizacion y quien los mantiene. No hace falta ser exhaustivo en toda la empresa: basta con el perimetro del caso de uso elegido. Esta auditoria tarda entre uno y tres dias segun el volumen, y evita semanas de trabajo desperdiciado en infraestructura sobre documentacion inutilizable.

Estructuracion y limpieza

Una vez identificados los documentos utiles, el siguiente paso es asegurar que el texto es extraible, que las versiones duplicadas quedan fuera del indice y que los documentos obsoletos se archivan o eliminan. En paralelo, conviene anadir metadatos minimos a los documentos clave: area, fecha de revision y owner. Esos metadatos permiten filtrar por permisos y por vigencia en el momento de la consulta.

Mantenimiento continuo

Mantener la base de conocimiento al dia requiere un proceso continuo de actualizacion, versionado y re-indexacion. No es suficiente con preparar bien el corpus inicial. Si los documentos cambian y el indice no se actualiza, la calidad de las respuestas se degrada progresivamente. El proceso de mantenimiento debe estar definido antes del lanzamiento: quien actualiza, con que frecuencia y como se valida que el indice refleja la documentacion vigente.

Checklist antes de lanzar tu proyecto RAG

1. 1Tenemos un caso de uso concreto definido, no solo la idea de que sea util en general.
2. 2Hemos identificado el subconjunto de documentacion que cubre ese caso de uso.
3. 3Todos los documentos del perimetro tienen texto extraible (sin PDFs escaneados sin OCR).
4. 4Hemos eliminado o archivado las versiones duplicadas o contradictorias.
5. 5Cada documento del indice tiene un owner identificado y una fecha de ultima revision.
6. 6Los documentos mas criticos tienen estructura minima: secciones, titulos y parrafos distinguibles.
7. 7Contamos con al menos 50 documentos relevantes y actualizados para el caso de uso.
8. 8Sabemos como se va a actualizar el indice cuando cambie la documentacion.
9. 9Hemos revisado los permisos de acceso: quien puede consultar que y si el copilot debe respetar esos permisos.
10. 10El equipo que usara el copilot ha validado que la documentacion actual refleja como se trabaja de verdad.

Si tu documentacion supera este checklist, estas en condiciones de arrancar un piloto con garantias. Si detectas problemas en varios puntos, lo mas eficiente es resolverlos antes de invertir en infraestructura. El siguiente paso natural es entender como conectar esa base documental a las fuentes que ya usas, o explorar directamente como desplegamos un Copilot RAG sobre documentacion interna.