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

Croc explicó cómo construyó un asistente RAG interno para trabajar con conocimiento corporativo en un circuito cerrado. En lugar de un 'chat por el chat', la empresa creó una herramienta que reduce el tiempo dedicado a buscar fragmentos relevantes en documentos, wikis y portales internos.

Por qué eligieron RAG

El equipo comenzó con un problema simple: aunque la búsqueda integrada existe en prácticamente todos los grandes sistemas corporativos, no facilita la vida de los empleados. La información está dispersa en múltiples repositorios, cada uno con sus propias reglas, estructura y lógica de retorno de resultados. Como resultado, las personas recuerdan el significado de un documento pero olvidan la redacción exacta, el nombre del archivo o la ubicación. La búsqueda estándar se basa en la coincidencia de palabras en lugar del contexto, y es aquí donde comienza a fallar.

También probaron un enfoque directo con GPT y carga de documentos, pero no funcionó para grandes conjuntos de datos. Varias limitaciones entraron en juego: tamaño de ventana de contexto, inestabilidad de respuestas y riesgo de exponer documentos sensibles fuera de la infraestructura de la empresa. Por eso, Croc eligió el enfoque RAG: primero encuentre fragmentos relevantes de fuentes internas y luego páselos a un modelo de lenguaje para armar la respuesta.

"Necesitábamos una herramienta de IA que sirviera a un propósito, no IA por ser tendencia—un asistente corporativo administrado."

RAG fue elegido en este proyecto por cuatro razones prácticas:

• Los documentos permanecen dentro de la infraestructura de la empresa;
• Solo el contexto necesario se pasa al modelo, no el conjunto de datos completo;
• La indexación y recuperación pueden controlarse por separado;
• El riesgo de alucinaciones es menor porque la respuesta se basa en fuentes reales.

Cómo se organizó el sistema

La solución se basa en dos circuitos separados. El primero se encarga de la creación de asistentes: los usuarios pueden agregar archivos, enlaces a portales o espacios de base de conocimiento a través del mensajero corporativo o una interfaz web piloto. El sistema de gestión de asistentes verifica los derechos de acceso, ejecuta los analizadores necesarios, prepara los datos y solo entonces los envía al núcleo RAG para indexación. Una vez que el índice está listo, el empleado recibe una notificación y puede comenzar un diálogo.

El segundo circuito es el circuito de diálogo. Las solicitudes del usuario van a través del bus LLM corporativo y el motor RAG preselecciona el contexto relevante. Los derechos de acceso se verifican no solo una vez durante la carga, sino con cada consulta del asistente. Debido a la complejidad de las ACL en diferentes sistemas, el equipo decidió alejarse de los asistentes compartidos en algunos escenarios y cambió a asistentes personales. Esto es menos conveniente, pero reduce el riesgo de que un empleado vea datos a los que no debería tener acceso.

Tuvieron que construir conectores y preprocesamiento para casi todos los tipos de fuentes de datos. El portal corporativo, la base de conocimiento, los archivos personales y las páginas wiki eran demasiado diferentes para pasar directamente a un único núcleo RAG listo para usar. Entonces extrajeron la limpieza de datos, normalización y preparación en servicios separados. Para el punto de entrada principal, eligieron un mensajero interno basado en Express: Telegram inicialmente parecía conveniente, pero usar un servicio externo para información sensible fue descartado de inmediato.

Dónde surgieron los problemas

Los desafíos más dolorosos no vinieron de la interfaz, sino de los datos y procesos. Los wikis con marcado complejo requerían limpieza manual extensa. Las tablas y los datos numéricos producían respuestas inestables. Los PDF con escaneos y gráficos rompían el análisis básico. El modelo entendía peor las estructuras visuales como organigramas que el texto y podía confundir las relaciones entre departamentos y gerentes.

Además, los usuarios esperaban que RAG proporcionara una búsqueda completa en todas las coincidencias, aunque el enfoque en sí tiende a clasificar el contexto más probable en lugar de garantizar una lista completa de ocurrencias. La colaboración del proveedor fue igualmente desafiante. Croc probó varias plataformas en sus propios conjuntos de documentos y consultas típicas y gastó casi un año refinando la solución con su proveedor. Las actualizaciones se convirtieron en un problema: podrían cambiar drásticamente la calidad de la respuesta: una versión redujo la métrica del 85% al 70%.

Derido a la relación opaca entre RAG y el LLM incorporado, el equipo solicitó una interfaz separada entre ellos para que pudieran elegir independientemente el modelo y gestionar el procesamiento posterior del contexto. Para el control de calidad, introdujeron benchmarks, preguntas de referencia, verificaciones regulares e incluso un juez LLM separado que compara las respuestas reales con las esperadas.

Lo que esto significa

El caso de Croc ilustra bien que la IA corporativa hoy no se trata tanto de elegir un modelo, sino de la ingeniería en torno a los datos, el acceso y las pruebas. RAG por sí solo no resuelve el problema si no hay conectores, aislamiento de colecciones, control ACL y métricas de calidad claras. Pero cuando todo esto se reúne en un sistema, un asistente interno puede realmente eliminar horas de búsqueda rutinaria y hacer que trabajar con conocimiento corporativo sea significativamente más rápido.