RAG local sobre tu documentación SAP: pregunta a tus manuales sin que salgan de tu red

Tienes decenas de PDFs. Manuales de proceso, documentación de customizing, guías de usuario, actas de reuniones de proyecto. Están en una carpeta de SharePoint que nadie abre. Cuando alguien necesita un dato concreto —el límite de aprobación de un pedido, el responsable de validar un asiento, el paso siete del proceso de alta de proveedor— pregunta por Teams y espera. A veces media hora. A veces hasta mañana.

Ese conocimiento existe. Está escrito. Lo que falta es la forma de consultarlo. Y aquí es donde casi todo el mundo piensa en subir los documentos a un servicio de inteligencia artificial en la nube, pegar una clave de API y dejar que el modelo “aprenda” de ellos.

Pero tu documentación SAP no es cualquier documentación. Describe tu customizing, tus procesos internos, tus puntos débiles y tus controles. Es justo lo que no quieres que viaje fuera de tu red. La buena noticia es que no hace falta: puedes montar un sistema que responda a tus manuales en lenguaje natural, en segundos, citando el documento y la página exactos, y que nunca saca un solo archivo de tu edificio.

En este artículo te cuento cómo funciona, qué stack usamos, y —esto es lo importante— el hallazgo incómodo que descubrimos midiéndolo de verdad en el Taller IA Local para SAP con Ollama. Porque la teoría del RAG es bonita; la realidad con documentación SAP real tiene una trampa que conviene conocer antes de prometerle nada a nadie.

Qué es RAG, sin jerga

RAG (Retrieval-Augmented Generation = generación aumentada por recuperación) suena complicado, pero la idea es sencilla. El modelo de lenguaje no memoriza tus documentos. No los “estudia” ni los incorpora a su cerebro.

Lo que ocurre es esto: cuando haces una pregunta, el sistema busca primero los fragmentos más relevantes de tu documentación, y se los pasa al modelo como contexto adjunto a la pregunta. El modelo entonces responde basándose en ese texto que acaba de leer, no en lo que recuerda.

Por eso puede citar la fuente. No se inventa la respuesta: la lee de un fragmento concreto que el sistema le ha puesto delante. Si el fragmento viene de la página 14 del manual de compras, el modelo puede decirte “según el manual de compras, página 14”. Esa trazabilidad es lo que diferencia un asistente serio de un loro que alucina datos plausibles.

Dicho de otro modo: RAG separa el recuperar (encontrar el texto correcto entre miles de fragmentos) del generar (redactar una respuesta legible). Y como veremos, la parte difícil no es la que parece.

El stack 100% local

Todo el sistema corre dentro de tu red. Ni una llamada saliente. Estas son las piezas:

Ollama es el motor que ejecuta los modelos en tu máquina o tu servidor; lo usamos tanto para generar los embedding (vectores) como para redactar la respuesta final. Qdrant es la base de datos especializada donde guardamos esos vectores y contra la que lanzamos las búsquedas. n8n es el director de orquesta: cada paso del proceso es un nodo de un workflow (flujo de trabajo). Y el reranker es la pieza que, como verás más abajo, marca la diferencia entre un RAG que funciona y uno que casi funciona.

Ninguna de estas herramientas necesita internet para operar. Eso es el punto.

El pipeline en dos fases

El sistema tiene dos momentos muy distintos: cuando metes la documentación (ingesta, que se hace una vez) y cuando preguntas (consulta, que ocurre cada vez que alguien lanza una pregunta).

En la ingesta preparas el terreno: troceas cada PDF en fragmentos manejables, conviertes cada fragmento en un vector y lo guardas en Qdrant junto con sus metadatos. Ese paso de guardar el documento de origen y la página es el que después permite citar. Sin metadatos no hay cita, y sin cita el sistema pierde la mitad de su valor.

En la consulta, la pregunta sigue el mismo camino que siguieron los fragmentos: se convierte en un vector, se buscan los vectores más cercanos en Qdrant, se reordenan con el reranker y los mejores se le entregan al modelo para que redacte. La respuesta llega con su fuente pegada.

El hallazgo honesto del taller

Aquí está el corazón del artículo, y es la parte que no suele contarse.

En el Taller IA Local para SAP con Ollama hicimos algo que muchos tutoriales se saltan: medimos. Concretamente medimos la similitud coseno (una forma estándar de cuantificar cuánto se parecen dos vectores) usando un embedder modesto y de propósito general, qwen2.5:7b, para ver si era capaz de distinguir a qué documento pertenecía cada pregunta.

El resultado tiene dos caras.

La buena: separa perfectamente dominios distintos. Si tienes documentación SAP, una receta de café y un catálogo de ropa en la misma colección, el sistema no se confunde. Una pregunta sobre pedidos no recupera la receta del cortado. A nivel grueso, funciona de maravilla.

La incómoda: no discrimina de forma fiable entre temas SAP cercanos. Cuando las preguntas tocaban compras, finanzas y RRHH —dominios próximos, con vocabulario solapado— las puntuaciones de similitud quedaban con diferencias de solo un 1-2%. Y en una prueba concreta, para una pregunta de compras, el documento de finanzas llegó a puntuar por encima del de compras. El embedder de propósito general simplemente no veía la diferencia con la nitidez necesaria.

La conclusión empírica es clara y la repetimos en cada edición del taller:

Para documentación SAP real necesitas un embedder dedicado (bge-m3, de 1024 dimensiones) y reranking obligatorio. Sin reranker, el RAG es cojo.

El embedder dedicado genera vectores más ricos (más dimensiones, mejor entrenamiento multilingüe) que capturan matices que el modelo modesto pierde. Y el reranker (bge-reranker-v2-m3) hace una segunda pasada: en lugar de comparar vectores a ciegas, lee la pregunta y cada fragmento candidato juntos y los puntúa por relevancia real. Es más lento, pero corrige exactamente el problema del 1-2%: rescata el fragmento correcto que la búsqueda vectorial había dejado en tercer o cuarto lugar.

Si te quedas solo con la búsqueda por similitud, el sistema parece funcionar en la demo —donde mezclas café y SAP— y falla en producción, donde todo es SAP y los temas se parecen. Ese es el error que vemos una y otra vez.

Ejemplo concreto: pregunta, recuperación y respuesta

Veámoslo con una pregunta real del tipo que recibe un equipo de compras:

Pregunta: “¿Cuál es el límite de importe para la aprobación automática de pedidos en nuestro customizing?”

Respuesta:

El límite es de X según Manual_Compras.pdf, pág. 14.

Fíjate en que la respuesta no es una opinión del modelo: es una lectura del documento, con la referencia para que cualquiera pueda ir a verificarla. Si mañana cambia el umbral, actualizas el PDF, vuelves a ingestar y la respuesta cambia con él.

Buenas prácticas

Lo aprendido en el taller se resume en una lista corta pero innegociable:

• Trocea por secciones, con solape (overlap). No partas el texto en bloques arbitrarios a mitad de frase. Respeta la estructura del documento y deja que los fragmentos se solapen un poco, para que una idea que cae en el borde no se pierda entre dos chunks.
• Guarda SIEMPRE los metadatos (documento + página) en la ingesta. Es la única forma de poder citar. Un RAG que responde sin fuente es un RAG en el que nadie confía.
• Reranking siempre. No es opcional para documentación SAP. Es la pieza que arregla el problema del 1-2% entre temas cercanos.
• Evalúa con un set de preguntas reales. Antes de dar el sistema por bueno, prepara una batería de preguntas que de verdad hace tu equipo y comprueba que recupera el fragmento correcto. Medir es lo que nos reveló el problema; no medir es confiar en una ilusión.
• Cuidado con mezclar idiomas en una misma colección sin un embedder multilingüe. Si tus manuales combinan español e inglés, usa un embedder preparado para ello —bge-m3 lo está— o las búsquedas cruzadas entre idiomas fallarán en silencio.

Por qué local importa especialmente aquí

Con muchos casos de uso de IA, alojar en la nube es una decisión de coste y comodidad. Con tu documentación SAP es una decisión de exposición.

Esos PDFs describen tu customizing: qué umbrales tienes configurados, qué controles aplicas, qué procesos sigues, dónde están tus excepciones. Es el mapa de cómo funciona tu empresa por dentro, incluidas sus debilidades. Indexar ese material en un servicio externo significa entregarle a un tercero el conocimiento más sensible que tienes.

Montándolo con Ollama, Qdrant y n8n dentro de tu red, el problema desaparece de raíz. No hay un dato que proteger en tránsito porque no hay tránsito. La integración con tu stack enterprise —los PDFs viven en SharePoint, las consultas pueden llegar desde Teams, las notificaciones salen por Outlook— se mantiene puertas adentro. El conocimiento se vuelve accesible sin volverse vulnerable.

Conclusión

Un RAG local bien construido cambia la relación de tu equipo con su propia documentación. Lo que era una carpeta de PDFs que nadie abre —un cementerio de conocimiento— se convierte en algo más parecido a un consultor: responde al instante, cita sus fuentes para que puedas verificarlo, y no se equivoca de proyecto.

Pero “bien construido” tiene una condición que el taller dejó grabada: embedder dedicado y reranking obligatorio. Sin esas dos piezas, el sistema brilla en la demo y tropieza en producción, justo donde todos tus temas son SAP y se parecen entre sí.

Hazlo bien y tu documentación deja de ser un archivo muerto para convertirse en un consultor que responde en segundos, cita el documento y la página, no confunde compras con finanzas, y nunca sale de tu edificio.

Fuentes

• Qdrant — documentación oficial
• BAAI bge-m3 y bge-reranker-v2-m3 — Hugging Face
• Ollama — embeddings
• n8n — docs.n8n.io
• Hallazgo propio del Taller IA Local para SAP con Ollama