Krok muestra cómo construyó un asistente RAG interno para datos corporativos

Krok explicó cómo construyó un asistente RAG interno para trabajar con conocimiento corporativo en un entorno cerrado. En lugar de crear «un chat por el chat», la compañía desarrolló una herramienta que reduce el tiempo de búsqueda de los fragmentos necesarios en documentos, wikis y portales internos.

Por qué eligieron RAG

El equipo partió de un problema simple: el buscador integrado existe, formalmente, en casi todos los grandes sistemas corporativos, pero eso no facilita la vida a los empleados. La información está dispersa en varios almacenes, cada uno con sus propias reglas, estructura y lógica de resultados. Como consecuencia, la gente recuerda el sentido de un documento, pero no su redacción exacta, el nombre del archivo ni dónde está guardado. La búsqueda tradicional se basa en coincidencias de palabras y no en el contexto, y ahí empieza a fallar.

También probaron el escenario directo con GPT y carga de documentos, pero no sirvió para grandes volúmenes de datos. Se juntaron varias limitaciones: la ventana de contexto, la inestabilidad de las respuestas y el riesgo de sacar documentos sensibles fuera del perímetro de la empresa. Por eso Krok optó por RAG: primero localizar fragmentos relevantes en las fuentes internas y solo después pasarlos al modelo de lenguaje para que redacte la respuesta.

«No necesitábamos IA por seguir una moda, sino un asistente

corporativo controlable».

En este proyecto se eligió RAG por cuatro razones prácticas:

• los documentos permanecen dentro de la infraestructura de la empresa;
• al modelo solo se le pasa el contexto necesario, no todo el conjunto de datos;
• la indexación y los resultados se pueden controlar por separado;
• el riesgo de alucinaciones es menor, porque la respuesta se apoya en fuentes reales.

Cómo se diseñó el sistema

La solución se basa en dos circuitos independientes. El primero se encarga de crear asistentes: el usuario añade, a través del mensajero corporativo o de una interfaz web piloto, archivos, enlaces al portal o espacios de la base de conocimiento. Después, el sistema de gestión de asistentes comprueba los permisos de acceso, lanza los parsers necesarios, prepara los datos y solo entonces los envía al núcleo RAG para indexarlos. Cuando el índice está listo, el empleado recibe una notificación y puede empezar a conversar.

El segundo circuito es el de diálogo. La consulta del usuario pasa por el bus corporativo de trabajo con LLM, y el motor RAG selecciona de antemano el contexto relevante. Los permisos no se verifican una sola vez al cargar los datos, sino en cada acceso al asistente. Debido a la complejidad de las ACL en los distintos sistemas, en algunos escenarios el equipo renunció a los asistentes compartidos y pasó a los personales. Es menos cómodo, pero reduce el riesgo de que un empleado vea datos que no le corresponden.

Además, hubo que construir conectores y preprocesamiento para casi cada tipo de fuente. El portal corporativo, la base de conocimiento, los archivos personales y las páginas wiki resultaron demasiado distintos para entregárselos «de serie» a un único núcleo RAG. Por eso la limpieza, la normalización y la preparación de datos se trasladaron a servicios independientes.

Como punto de entrada principal eligieron un mensajero interno basado en Express: Telegram parecía cómodo al principio, pero para información sensible un servicio externo quedó descartado de inmediato.

Dónde surgieron los problemas

Las dificultades más molestas no estuvieron en la interfaz, sino en los datos y los procesos. Las wikis con marcado complejo exigieron mucha limpieza manual. Las tablas y los datos numéricos daban respuestas inestables. Los PDF con escaneos y gráficos rompían el parsing básico. El modelo entendía peor las estructuras visuales, como los organigramas, que el texto, y podía confundir las relaciones entre departamentos y responsables. Además, los usuarios esperaban de RAG una búsqueda completa de todas las coincidencias, aunque el enfoque más bien ordena el contexto más probable en lugar de garantizar una lista completa de apariciones.

Trabajar con el proveedor no fue menos doloroso. Krok probó varias plataformas con sus propios conjuntos de documentos y preguntas típicas, y después dedicó casi un año a perfeccionar la solución junto con el proveedor. El problema fueron las actualizaciones, que podían cambiar bruscamente la calidad de las respuestas: una de las versiones hizo caer una métrica del 85 % al 70 %. Como la conexión entre RAG y el LLM integrado era opaca, el equipo pidió una interfaz independiente entre ambos para elegir el modelo por su cuenta y controlar el procesamiento posterior del contexto.

Para controlar la calidad introdujeron benchmarks, preguntas de referencia, comprobaciones periódicas e incluso un LLM independiente que actúa de juez y compara la respuesta real con la esperada.

Qué significa

El caso de Krok muestra que la IA corporativa hoy consiste menos en elegir un modelo que en la ingeniería en torno a los datos, los accesos y las pruebas. RAG por sí solo no resuelve el problema si faltan conectores, aislamiento de colecciones, control de ACL y métricas de calidad claras. Pero si todo se integra en un solo sistema, un asistente interno puede eliminar horas de búsqueda rutinaria y hacer notablemente más rápido el trabajo con el conocimiento corporativo.