La adopción de sistemas RAG -Retrieval-Augmented Generation- en el sector energético crece a un ritmo que rara vez viene acompañado de una pregunta previa: qué tipo de problema resuelve realmente esta tecnología y cuál queda fuera de su alcance por diseño.
Actualmente un RAG combina dos pasos: primero busca los «chunks» más relevantes dentro de un conjunto de documentos, es decir, aquella porción o segmento de información que se extrae y agrupa de manera lógica. Y después un modelo de lenguaje redacta una respuesta a partir de esos segmentos, en lugar de responder solo con lo que aprendió durante su entrenamiento. Esta técnica suele integrarse dentro de un agente de IA, un sistema capaz de decidir qué pasos dar para resolver una consulta, y funciona como una herramienta más entre las que el agente puede usar, junto con otras como el acceso a una base de datos estructurada o el cálculo sobre ciertas planillas.
Pero la confusión sobre sus alcances tiene un costo concreto para cualquier organización, especialmente en el sector energético. Lo que hoy observamos, desde 7Puentes, es que equipos técnicos y de negocio evalúan pilotos con expectativas que un RAG documental no puede cumplir, y el diagnóstico posterior suele leerse como una «falla del sistema» cuando en realidad se trata de una definición de alcance mal planteada desde el inicio.
Qué resuelve un RAG
Un RAG resuelve con solidez tres tipos de tareas:
- Localizar un dato puntual dentro de un volumen grande de documentos, como una especificación técnica o una cláusula contractual.
- Resumir el contenido de uno o varios documentos sobre un tema acotado.
- Responder preguntas de tipo filtro, del estilo «qué piezas fueron reparadas mediante determinado proceso» o «qué documentos mencionan tal norma».
En el sector energético, estas capacidades cubren buena parte de la demanda operativa: consulta de normativas, búsqueda en bitácoras de mantenimiento, revisión de manuales de proveedores. El punto ciego aparece cuando la pregunta deja de ser sobre un documento y pasa a ser sobre una entidad que atraviesa muchos documentos a la vez.
El límite: recuperar y resumir no es lo mismo que ejecutar
La arquitectura de un RAG trabaja sobre un principio de recuperación por similitud: dado un texto de consulta, trae los fragmentos más parecidos semánticamente, en un número acotado (lo que se conoce como top-k). Ese diseño es apropiado para encontrar lo más relevante, pero tiene tres límites estructurales que conviene identificar antes de definir el alcance de un piloto:
Exhaustividad. Preguntas como «qué reparó cada proveedor durante todo el histórico» requieren el conjunto completo de menciones, no una muestra de las más relevantes. Un RAG por diseño trae lo más similar, no todo lo que existe.
Cómputo. Calcular una duración entre dos fechas, comparar una medición dimensional de entrada contra una de salida, o sumar valores a través de distintos registros son operaciones aritméticas. Un modelo de lenguaje puede aproximarse a un cálculo simple, pero no está construido para garantizar precisión sobre datos estructurados dispersos en texto libre.
Razonamiento de cumplimiento. Verificar si un proceso cumplió con una especificación técnica implica convertir esa especificación en una lista de verificación y cruzarla ítem por ítem contra la evidencia disponible. Eso es una tarea de agente con clara lógica de negocio, no la que corresponde a una recuperación de texto.
Estas tres exigencias marcan la frontera real: de un lado, tareas de recuperación y síntesis, que un RAG resuelve bien; del otro, tareas de ejecución, que requieren una capa adicional de datos estructurados y una lógica que opere sobre ellos.
El punto ciego de un RAG: trazabilidad en una central térmica
Un piloto reciente, desarrollado por 7Puentes, sobre una central térmica en la Patagonia ilustra este «punto ciego» con claridad, ya que la pregunta atraviesa múltiples variables de información. El objetivo declarado era evaluar un sistema RAG para trazabilidad de componentes de turbina —álabes, piezas reparadas mediante procesos de soldadura fuerte (brazing) y prensado isostático en caliente (HIP), identificadas por número de serie— a través de distintos talleres reparadores y proveedores, con foco en el cumplimiento de especificaciones técnicas y la detección de desvíos.
El equipo a cargo del piloto preparó nueve preguntas de prueba, pensadas para reflejar el objetivo real del proyecto: trazabilidad de componentes y detección de desvíos.
El análisis de esas nueve preguntas frente a la arquitectura de un RAG documental arrojó un resultado poco intuitivo. Apenas dos se resuelven bien con el sistema tal como está, y corresponden a filtros de recuperación simples, del tipo qué piezas pasaron por determinado proceso o qué documentos mencionan un componente específico. Otras tres se resuelven de forma parcial o frágil, porque dependen de seguir una entidad a través de varios documentos o de sintetizar información sin garantía de cobertura completa. Las cuatro restantes (que son, además, las más representativas del objetivo declarado del piloto) piden reconstruir la historia completa de una pieza, agregar información sobre la totalidad del corpus, calcular tiempos de reparación y operación adicional, o verificar el cumplimiento de una especificación técnica identificando desvíos y faltantes. Ese último grupo queda fuera del alcance de un RAG documental por definición: no se trata de un límite de implementación, sino de la frontera entre recuperar y resumir información —que es lo que un RAG resuelve— y ejecutar una tarea sobre esos datos, como agregar, calcular o verificar cumplimiento, que es trabajo de un agente con acceso a una capa de datos estructurada.
El diagnóstico, entonces, no apunta a una falla del sistema de recuperación. La causa es más simple de explicar: hoy la información vive como texto libre dentro de cada documento, con datos generales sobre el documento en sí (a qué central pertenece, qué tipo de informe es), pero sin ningún registro que conecte una misma pieza, identificada por su número de serie, a través de los distintos documentos donde aparece mencionada, tales como un informe de un taller, un control de otro proveedor o una fecha de entrada registrada en un tercero. El sistema encuentra cada una de esas menciones por separado, con precisión. Lo que no puede hacer todavía es unirlas para reconstruir la historia completa de una pieza, o sumarlas con la certeza de haber cubierto todos los documentos donde esa pieza aparece.
El camino: arquitectura híbrida, RAG + capa estructurada
La respuesta a esta clase de brecha no exige descartar el sistema de recuperación existente ni partir de cero. La mayor parte de la infraestructura —recuperación semántica, búsqueda léxica, filtros de metadata, un agente con capacidad de ejecutar múltiples pasos— se reutiliza sin modificaciones mayores. Lo que falta es una pieza puntual: un paso de extracción estructurada durante la ingesta de documentos.
Ese paso adicional consiste en que, además de fragmentar el documento para la búsqueda semántica, un modelo de lenguaje lea cada documento y emita registros estructurados: pieza, número de serie, proveedor, taller, fechas de entrada y salida, proceso aplicado, dimensiones y referencia a la especificación técnica correspondiente. Cada registro queda enlazado al fragmento y al documento de origen, lo cual preserva la trazabilidad de dónde proviene cada dato.
Con ese índice estructurado disponible, el agente combina dos rutas según el tipo de pregunta. Las consultas de recuperación y de síntesis siguen resolviéndose mediante el RAG y la búsqueda léxica. Las consultas de agregación, cómputo de tiempos y verificación de cumplimiento se resuelven consultando el índice estructurado, con un patrón de agente que traduce la pregunta en una consulta sobre esos datos. El resultado final combina ambas fuentes: una tabla o una línea de tiempo con cada dato enlazado al documento que lo respalda.
En el caso de la central térmica, este camino se ordenó en cuatro etapas:
- Prueba de concepto inmediata, en cuestión de días: responder las preguntas resolubles con el RAG y la búsqueda léxica ya existentes, sobre documentos reales del cliente, para tener algo funcionando y demostrable desde el inicio.
- Diseño de la capa de trazabilidad, en una o dos semanas: definir el esquema de entidades, qué campos extrae el modelo durante la ingesta, y las herramientas nuevas que el agente va a exponer, validando el modelo contra una muestra de documentos reales.
- Implementación incremental: construir el extractor, las tablas y las herramientas por tandas, priorizando primero las preguntas de agregación y cómputo de tiempos, después la comparación dimensional, y por último el análisis de cumplimiento, que es el más exigente en términos de lógica de negocio.
- Validación con el equipo del cliente: correr el conjunto completo de preguntas de punta a punta, con evidencia citada, y ajustar la extracción según los desvíos que el propio piloto busca detectar.
Para una demostración acotada del piloto, alcanza con lo que el sistema ya resuelve sobre dos o tres preguntas. Para responder con seriedad a las consultas que demuestran trazabilidad y detección de desvíos —el objetivo declarado del proyecto— hace falta incorporar un preprocesamiento de los documentos que construya la capa de extracción estructurada durante la ingesta. La recomendación en estos casos es arrancar la prueba de concepto en paralelo al diseño de ese preprocesamiento, en lugar de esperar a tener la arquitectura completa para mostrar el primer resultado.
A modo de cierre: la pregunta que conviene formular antes de evaluar un piloto RAG
El caso de la central térmica nos deja una lección que excede a ese proyecto puntual. Antes de diseñar las preguntas de prueba de un piloto RAG en el sector energético, vale la pena clasificarlas según qué exigen: recuperar y resumir información existente, o ejecutar una tarea que involucra exhaustividad, cálculo o verificación de cumplimiento. Las primeras se resuelven con un RAG bien implementado. Las segundas necesitan una capa de datos estructurados y un agente que sepa operar sobre ella.
Confundir ambos tipos de pregunta durante el diseño del piloto lleva a evaluar la tecnología equivocada, o a concluir que un RAG «no funciona», cuando en verdad se le pidió resolver un problema que estaba fuera de su alcance desde el planteo inicial.
En definitiva, la arquitectura correcta no reemplaza el RAG sino que lo complementa con la capa que faltaba en el proyecto y en el proceso de resolución real del problema.
