RAG con SharePoint, Drive o Confluence

La promesa de RAG sobre documentación corporativa suena perfecta: conectas tu SharePoint, Google Drive o Confluence, indexas todo el contenido y tu equipo empieza a hacer preguntas en lenguaje natural. En la práctica, cada una de estas fuentes tiene particularidades que hacen la implementación bastante más compleja de lo que parece en una demo.

No es que no funcione. Funciona, y bien, cuando se implementa teniendo en cuenta las limitaciones de cada plataforma. Pero hay diferencias sustanciales entre conectar un RAG a un repositorio limpio y bien organizado y conectarlo a un SharePoint con 8 años de documentos acumulados sin criterio.

¿Qué problemas plantea SharePoint como fuente para RAG?

SharePoint es la fuente documental más habitual en empresas que usan ecosistema Microsoft. Tiene varias ventajas para RAG: API bien documentada, control de permisos granular y soporte nativo de versionado. Pero también tiene trampas:

• Permisos: lo que un usuario puede ver en SharePoint tiene que respetarse en el sistema RAG. Si el departamento legal tiene documentos restringidos, el sistema no puede mostrar esos fragmentos a un usuario de operaciones. Implementar esta capa de permisos heredados añade complejidad significativa al proyecto.
• Documentos duplicados y versiones obsoletas: muchos SharePoints tienen 3 o 4 versiones del mismo documento, algunas obsoletas. Si se indexan todas, el sistema puede recuperar una versión antigua y dar una respuesta incorrecta. Hay que definir reglas de versionado antes de indexar.
• PDFs escaneados: una proporción significativa de documentos en SharePoint son PDFs escaneados (contratos firmados, albaranes, facturas antiguas). Requieren OCR antes de poder indexarse, y la calidad del OCR depende de la calidad del escaneo.
• Estructura de carpetas caótica: la mayoría de SharePoints corporativos no tienen una estructura lógica consistente. Documentos de 2019 en carpetas de 2022, archivos en el sitio equivocado, carpetas personales mezcladas con carpetas de proyecto. Limpiar esta estructura antes de indexar es casi siempre necesario.

Google Drive: la trampa del acceso abierto

Google Drive es habitual en empresas que usan Google Workspace. Su principal ventaja es la facilidad de integración vía API. El problema más frecuente es el opuesto al de SharePoint:

• Permisos demasiado laxos: en muchas organizaciones, los documentos de Drive están compartidos con «cualquiera con el enlace» o con toda la organización. Cuando conectas un RAG, de repente el sistema puede acceder a documentos que, aunque técnicamente accesibles, no deberían estar disponibles para todos los usuarios. Hay que auditar los permisos antes de conectar.
• Google Docs vs archivos subidos: Google Docs nativos se indexan fácilmente (la API devuelve texto limpio). Pero los archivos subidos (PDFs, Word, Excel) requieren procesamiento adicional. Y los Google Sheets con datos tabulares son particularmente problemáticos para la segmentación de RAG.
• Carpetas compartidas vs Mi unidad: la estructura de propiedad de Drive puede hacer que documentos críticos estén en la unidad personal de alguien que ya no está en la empresa. Hay que mapear la topología real de la documentación antes de decidir qué indexar.

Confluence: estructura buena, calidad variable

Confluence tiene una ventaja estructural importante: sus páginas son texto nativo con formato, jerárquicamente organizadas en espacios. Esto hace que la indexación sea relativamente limpia. Pero:

• Páginas obsoletas que nadie ha archivado: Confluence tiende a acumular documentación que ya no refleja la realidad. Procedimientos de hace tres años, decisiones de arquitectura que ya no aplican, actas de reuniones que no aportan nada. Si se indexa todo sin filtrar, el sistema dará respuestas basadas en información obsoleta.
• Adjuntos: muchas páginas de Confluence tienen adjuntos (PDFs, hojas de cálculo, presentaciones) que contienen información complementaria. Si solo indexas el texto de la página e ignoras los adjuntos, pierdes contexto relevante.
• Macros y contenido dinámico: las tablas de Jira embebidas, los diagramas de Draw.io y otros contenidos dinámicos no se renderizan como texto plano. Hay que decidir qué hacer con ellos en el pipeline de indexación.

Lecciones comunes independientemente de la fuente

Después de implementar RAG sobre distintas fuentes documentales, hay aprendizajes que se repiten:

1. 1Invierte tiempo en decidir qué NO indexar. Más documentos no significa mejores respuestas. Un corpus más pequeño y de mayor calidad produce mejores resultados que indexar todo sin criterio.
2. 2Define un proceso de actualización desde el día uno. Quién marca un documento como obsoleto, con qué frecuencia se re-indexa, quién valida que los documentos nuevos están en el formato correcto.
3. 3Prueba con un subconjunto antes de escalar. Indexa los documentos de un departamento o un tipo concreto (procedimientos operativos, por ejemplo), valida la calidad de las respuestas y después amplía.
4. 4No subestimes el esfuerzo de permisos. Si tu empresa tiene requisitos de confidencialidad entre departamentos, los permisos del sistema RAG deben replicar los permisos de la fuente. Esto no es trivial y requiere diseño específico.

El problema de la segmentación (chunking) según el tipo de documento

Uno de los pasos técnicos más críticos en un sistema RAG es la segmentación: dividir cada documento en fragmentos (chunks) que se almacenan en el vector store y se recuperan cuando un usuario hace una pregunta. La segmentación que funciona para un tipo de documento puede fallar estrepitosamente con otro, y cada fuente tiene sus particularidades.

• Documentos largos y bien estructurados (manuales, SOPs): funcionan bien con segmentación por secciones o encabezados. Si el documento tiene una estructura jerárquica clara (H1, H2, H3), dividir por sección mantiene el contexto de cada fragmento.
• Documentos cortos y densos (políticas, normativas): a veces conviene indexarlos enteros como un solo chunk. Si se dividen en fragmentos demasiado pequeños, se pierde el contexto de excepciones y condiciones que solo tienen sentido cuando se leen juntas.
• Tablas y datos tabulares: los fragmentos que contienen tablas son problemáticos. Si una tabla se corta a la mitad, el sistema puede recuperar filas sin encabezado o encabezados sin datos. Hay que tratar las tablas como unidades atómicas o extraerlas a un formato consultable aparte.
• Presentaciones (PowerPoint, Google Slides): cada diapositiva suele tener poco texto y mucho contexto visual que se pierde. Indexar diapositivas sueltas produce fragmentos con frases como «Siguiente paso: implementar» sin contexto. Es mejor valorar si las presentaciones aportan valor real al corpus.
• Emails y comunicaciones: contienen mucho ruido (firmas, disclaimers, cadenas de respuestas). Si se indexan, hay que limpiar antes el contenido para que solo entre el cuerpo relevante del mensaje.

Actualización del índice: el problema que nadie planifica

La mayoría de proyectos RAG se centran en la carga inicial: conectar la fuente, indexar el contenido, probar que funciona. Pero los documentos corporativos cambian. Se actualizan procedimientos, se publican nuevas políticas, se archivan documentos obsoletos. Si el índice no se actualiza, el sistema empieza a dar respuestas basadas en información antigua sin que nadie lo note.

La frecuencia de actualización depende del tipo de contenido y de la fuente:

Lo ideal es combinar una re-indexación periódica con webhooks o eventos que disparen una actualización inmediata cuando un documento relevante cambia. SharePoint y Confluence soportan este tipo de notificaciones; Google Drive también, aunque con más limitaciones en la detección de cambios en archivos subidos.

Combinar varias fuentes en un mismo sistema RAG

Muchas empresas no usan una sola plataforma documental. Es habitual encontrar procedimientos en Confluence, documentación de proyectos en SharePoint y archivos sueltos en Google Drive. Conectar varias fuentes al mismo sistema RAG es posible, pero añade complejidad en tres dimensiones:

1. 1Permisos heterogéneos: cada plataforma gestiona los permisos de forma distinta. Un usuario que tiene acceso a cierto contenido en SharePoint puede no tener acceso al equivalente en Confluence. El sistema RAG debe resolver estas diferencias y aplicar el permiso más restrictivo cuando haya duda.
2. 2Duplicación entre fuentes: el mismo documento puede existir en SharePoint y en Google Drive con versiones distintas. Sin una política de fuente de verdad por tipo de documento, el sistema puede recuperar la versión incorrecta.
3. 3Metadatos inconsistentes: cada plataforma gestiona los metadatos de forma diferente (fechas, autores, categorías). Normalizar estos metadatos es necesario para que las búsquedas y los filtros funcionen de forma consistente en el sistema unificado.

Si estás evaluando conectar tu documentación corporativa a un sistema de consulta con IA, el primer paso es auditar el estado real de esa documentación. En nuestro servicio de copilots e IA empresarial incluimos esta fase de auditoría documental como paso previo a cualquier implementación de búsqueda inteligente con RAG.

Si necesitas orientacion sobre como implementar un copilot con RAG en tu empresa, en nuestra página de copilot RAG empresarial explicamos el proceso completo.

Para más contexto, puedes consultar la documentación de Azure AI Search sobre RAG.