En RGS, los LLM locales redujeron el análisis de 500 tareas de cinco días laborables a dos

Antes de cada ciclo de planificación en RGS, los equipos de desarrollo presentan cientos de tareas, y cada una debe evaluarse según varios criterios de priorización. Uno de ellos es el cumplimiento de TI: si implementar la tarea ayuda a cumplir los requisitos legales. Anastasia, responsable del área de cumplimiento de TI, contó en Habr cómo redujo el análisis de unas 500 tareas de cinco días laborables a dos. No tenía presupuesto de desarrollo y no sabe programar: todo el flujo se apoya en herramientas gratuitas y funciona en un portátil.

Por qué no sirvió el filtro por palabras clave

En el piloto participaron dos «trenes», es decir, dos grandes áreas de desarrollo. Solo el primer ciclo generó unas 500 tareas, y analizarlas costó una semana del único experto. Durante todo ese tiempo se paró el trabajo para el que existe el área de cumplimiento: analizar nuevos requisitos y acompañar proyectos complejos. Incorporar el resto de los trenes se habría llevado la mayor parte del trimestre, y ampliar el equipo para cubrir los picos de carga no era posible.

La búsqueda por palabras no funcionaba: cada equipo formula las tareas de forma distinta y lo que hay que evaluar es el significado. Por eso Anastasia decidió comprobar su hipótesis de la forma más barata posible. Preparó una exportación anonimizada de tareas y se la pasó a varios modelos externos junto con instrucciones sobre los criterios. Tras varias iteraciones del prompt, el resultado se estabilizó, pero la coincidencia con las evaluaciones de los expertos fue de en torno al 60%, y los errores iban sobre todo hacia la sobrestimación. Para empezar bastaba: un modelo que peca de cauteloso descarta con fiabilidad lo que el experto no necesita revisar.

Montaje local: n8n,

Ollama y una base de evaluaciones validadas

La primera versión tenía tres puntos débiles: la preparación manual de las exportaciones, la pérdida de significado al anonimizar y la dependencia de servicios externos que en Rusia pueden dejar de funcionar. Una solución corporativa no salió adelante de entrada, así que Anastasia optó por un modelo local. Los datos no salen del ordenador y no hacen falta servicios externos. El precio son las limitaciones del portátil: las tareas se envían por lotes y los modelos demasiado pesados bloqueaban el equipo por completo.

Como orquestador se eligió n8n, un constructor visual de procesos. Los modelos se ejecutaron con LM Studio y Ollama, y al final se quedó con Ollama. El flujo funciona así: exportación de tareas, limpieza del texto de ruido técnico, envío al modelo junto con las instrucciones, respuesta en formato estricto (nivel en una escala y una breve justificación) y almacenamiento del resultado.

El elemento central es la base de evaluaciones ya validadas con RAG. Al recibir una tarea, el modelo busca otras similares que haya evaluado un experto y se apoya en ellas. Sin esa base, las primeras versiones mostraban una precisión de solo el 20%. Tras mejorar la selección de ejemplos, el prompt y el conjunto de modelos (Qwen y GPT-oss), el sistema alcanzó un 70–80% en la muestra de prueba y procesaba 500 tareas en unas 12 horas. Son unos 1,5 minutos por tarea.

Para comparar las variantes con rigor, Anastasia escribió con ayuda de una IA un programa convencional. Contrasta las evaluaciones de varios algoritmos con las de los expertos y calcula cuatro indicadores: acierto exacto, acierto con tolerancia de un escalón de la escala, descarte de lo innecesario y dirección de los errores. La sobrestimación implica una revisión de más; la subestimación implica el riesgo de pasar por alto una tarea importante.

Del 55–60% en el flujo real al 78–82%

La muestra de prueba resultó optimista. Con tareas reales, la primera versión buena dio solo un 55–60%: en el flujo real hay más formulaciones y sistemas nuevos, y parte de las tareas llega de trenes que apenas se están incorporando a la priorización. Después, Anastasia probó varias evaluaciones de distintos modelos o de un mismo modelo con parámetros diferentes, conocimientos adicionales y contexto enriquecido, también mediante MCP. El criterio de selección era sencillo: si la precisión de una variante caía al incorporar nuevos trenes, se descartaba.

Las versiones que superaron la selección tardan más que la inicial, 12–24 horas para 500 tareas, pero alcanzan un 78–82% con datos reales, y los errores de sobrestimación y subestimación ahora están equilibrados. En lugar de un filtro para el experto, el resultado es un algoritmo que asigna los valores por sí mismo y un experto que los revisa cuando hace falta. La lógica económica es simple: el tiempo del ordenador es más barato que el del experto, y cuanto más preciso es el algoritmo, menos revisión manual se necesita.

El proceso también cambió en alcance. Antes solo se evaluaban a mano las tareas nuevas, y las modificadas no se revisaban de nuevo por falta de tiempo. Ahora el algoritmo exporta por sí mismo las tareas nuevas y las que tienen la descripción modificada antes de que empiece su implementación, asigna las evaluaciones, entrega un archivo para su revisión y escribe el valor del criterio en el campo que se usa para calcular la prioridad. Se puede escribir de inmediato o después de la revisión. En lugar de dos trenes, el proceso da servicio a nueve.

Limitaciones y próximos pasos

La solución tiene puntos débiles, y la autora los reconoce. Depende de un solo portátil y de un solo experto, y una precisión del 80% es buena para un modelo local, pero no elimina la revisión por muestreo. Anastasia piensa comprobar periódicamente si la precisión baja. La instancia corporativa del algoritmo ya funciona en modo limitado y ofrece una precisión comparable seis veces más rápido. Según Anastasia, solo queda levantar las restricciones.

Para los profesionales, la conclusión es esta. El esquema «leer, contrastar con las reglas, evaluar» sirve para muchos procesos operativos. El mínimo para que funcione: una base acumulada de evaluaciones de expertos para RAG, métricas que tengan en cuenta la dirección de los errores y pruebas con el flujo real, no solo con una muestra. En RGS ya se está lanzando en modo de prueba un proceso similar. El papel del experto cambia: gestiona el proceso y decide donde su decisión es realmente necesaria.