Un ingeniero crea un servicio RAG local para la documentación de API de CAD y lo explica en Habr

Un ingeniero ha publicado en Habr un análisis de cómo construyó un servicio RAG local para trabajar con la documentación de las API de los sistemas de diseño asistido por ordenador (CAD). Según explica, el proyecto responde a la presión que ejercen sobre las empresas de ingeniería unos clientes que recortan presupuestos y plazos.

Por qué la documentación de CAD se convirtió en candidata a la automatización

Según el autor, en los últimos años la ingeniería vive bajo el lema "lo mismo, pero más barato y más rápido": los clientes recortan presupuestos y plazos, y los contratistas buscan qué procesos pueden optimizar. La automatización del diseño es una de las primeras candidatas a esa optimización. El diseño incluye muchas operaciones rutinarias, y buena parte de ellas puede delegarse en scripts y pequeñas utilidades de software en lugar de que las haga un ingeniero a mano.

• El autor es un ingeniero que construyó por su cuenta un servicio RAG local para API de CAD
• El motivo del proyecto son las operaciones rutinarias de diseño que pueden delegarse en scripts
• El contexto general es el recorte de presupuestos y plazos por parte de los clientes de servicios de ingeniería

Se trata precisamente de las API de los sistemas de diseño asistido por ordenador, no de los planos en sí. Los scripts y las utilidades suelen escribirse para acciones repetitivas, como la generación masiva de informes, la comprobación de parámetros frente a estándares internos o el procesamiento de archivos por lotes. Son tareas que un ingeniero repite a mano decenas de veces en cada proyecto, pero que se pagan mal como trabajo creativo.

Qué aporta un RAG local en este escenario

RAG (retrieval-augmented generation, generación aumentada por recuperación) es un enfoque en el que el modelo, antes de responder, busca fragmentos relevantes en su propia base de documentos en lugar de basarse solo en lo que memorizó durante el entrenamiento. Para la documentación de API de CAD resulta especialmente adecuado: estas API suelen estar descritas en manuales extensos, dispersos y que se actualizan con regularidad. El despliegue local, por su parte, permite mantener los datos de ingeniería sensibles y la documentación propietaria dentro del perímetro de la empresa, sin enviarlos a servicios en la nube externos.

Por eso el autor optó por una solución local y no por un asistente de AI en la nube ya hecho. Con datos de ingeniería, la confidencialidad suele importar más que la comodidad de configuración, y acceder a la versión actual de la documentación de la API es crítico, porque los sistemas CAD cambian con regularidad sus interfaces y métodos. Desplegarlo "en casa", sin enviar consultas a un servicio externo, también elimina la duda sobre adónde van a parar las formulaciones de los pliegos técnicos internos y los fragmentos de documentación cerrada del fabricante.

Qué dificultades suelen surgir en este tipo de proyectos

La documentación técnica de una API es un material incómodo para un pipeline RAG clásico. Contiene muchas tablas de parámetros, referencias a otras secciones, notas de versión y terminología específica de cada plataforma CAD, que no se divide bien en chunks con los métodos estándar. Quienes desarrollan este tipo de servicios suelen tener que diseñar aparte la división de los documentos en fragmentos con sentido, la actualización del índice cuando sale una nueva versión de la API y la verificación de que el modelo no confunde métodos de nombre parecido pero comportamiento distinto. Es un trabajo manual y minucioso que normalmente no se ve en el resultado final, pero que ocupa buena parte del tiempo de un proyecto así.

Qué significa esto

El caso refleja una tendencia más amplia: mientras los grandes fabricantes lanzan asistentes de AI universales, ingenieros individuales y equipos pequeños construyen cada vez más herramientas RAG locales muy especializadas para rutinas concretas, como el trabajo con documentación, las operaciones con plantillas y los estándares internos. En las organizaciones de ingeniería y diseño, donde importan la confidencialidad de los planos y la correspondencia exacta con la versión de la API, una herramienta local de fabricación propia como esta a menudo resulta más práctica que conectar un servicio de AI externo en la nube a toda la base documental de la empresa.