Perfil del cliente
El analista trabaja dentro de un pequeño equipo de ingeniería automotriz o de un proveedor OEM responsable de extraer inteligencia dimensional de planos CAD 2D heredados. Sus materiales de origen son archivos DXF — el formato estándar del sector exportado desde herramientas como AutoCAD, CATIA y SolidWorks — y sus consumidores posteriores incluyen equipos de simulación, planificadores de fabricación y revisores de cumplimiento dimensional. El equipo opera en la intersección de la ingeniería inversa y la preparación de gemelos digitales, donde la precisión de la geometría reconstruida afecta directamente a las herramientas y decisiones de proceso posteriores. La mayoría de los planos de entrada del equipo son diseños de un solo archivo y múltiples vistas: proyecciones lateral, frontal y superior codificadas en un único DXF, sin ningún modelo CAD 3D complementario disponible.
Problema
Antes de trabajar con energent.ai, el equipo dependía de un enfoque de inferencia de profundidad basado en capas para convertir geometría DXF 2D en una representación pseudo-3D. El problema principal era el sobrellenado sistemático: allí donde el plano de origen no tenía suficiente cobertura de múltiples vistas, el algoritmo asignaba valores heurísticos de profundidad en lugar de marcar esas zonas como no soportadas. La geometría fabricada hacía que los resultados de reconstrucción no fueran fiables para los flujos posteriores, y la ausencia de datos de procedencia hacía imposible diagnosticar qué región del plano era responsable de cualquier discrepancia dimensional dada.
Para el vehículo analizado — descrito por un único archivo de plano autorizado (kavz-3244.dxf) — el contorno de referencia estaba especificado con precisión:
- Length: 7,895.0 mm
- Height: 2,820.0 mm
- Width: 2,210.0 mm
Los resultados del panel generados por el flujo anterior no podían validarse frente a esos objetivos de ninguna manera significativa. Se producía una representación 3D visualmente completa, pero el equipo no tenía ninguna cadena de artefactos que conectara cada elemento de superficie renderizado con una vista o región del plano específica. Cualquier discrepancia entre el modelo renderizado y la especificación objetivo era indistinguible entre una brecha dimensional real y un artefacto del relleno heurístico. El flujo anterior también había generado varios archivos intermedios de depuración y visualización que nunca fueron designados formalmente como autorizados ni sustituidos, dejando al equipo sin certeza sobre qué resultados debían utilizarse para las decisiones posteriores.
Por qué ahora
La presión por entregar una reconstrucción fiable surgió de dos fuerzas convergentes. En primer lugar, los equipos posteriores de simulación y fabricación habían empezado a señalar discrepancias dimensionales en los modelos entregados desde el flujo de reconstrucción — y, sin datos de procedencia, el equipo de reconstrucción no podía explicar qué vista del plano proporcionaba cada medida ni si un hueco era intencional o heurístico. En segundo lugar, el equipo acababa de recibir un plano de vehículo con dimensiones objetivo totalmente especificadas, lo que creaba un punto de referencia concreto frente al cual la precisión del flujo anterior podía medirse de forma directa y pública. Un traspaso fallido sobre un punto de referencia acotado sería un evento de calidad visible, no un desajuste silencioso absorbido por las tolerancias. El equipo necesitaba un enfoque de reconstrucción que pudiera producir resultados auditables y escasos antes de la siguiente revisión del benchmark, y lo necesitaba con la suficiente rapidez como para que reconstruir el flujo desde cero en un entorno de scripting no fuera viable.
Por qué energent.ai
El equipo evaluó varias alternativas. El análisis basado en hojas de cálculo no podía gestionar el análisis sintáctico de geometría DXF ni la orquestación de múltiples artefactos a ninguna escala. El software especializado de reconstrucción 3D requería una inversión importante en licencias y una profunda experiencia en CAD para configurarlo para este flujo de trabajo de un solo archivo y centrado en la evidencia. Contratar a un analista adicional no habría resuelto ni la brecha de procedencia ni el problema del relleno heurístico: esos eran problemas de diseño del flujo, no de recursos.
energent.ai ofrecía una vía cualitativamente distinta. El agente podía cargar el archivo DXF directamente, ejecutar scripts de reconstrucción en Python dentro de la sesión, generar e inspeccionar artefactos JSON intermedios, aplicar lógica configurable de puertas de QC y producir un panel HTML interactivo — todo dentro de una única sesión iterativa sin pérdida de contexto entre pasos. Y, de forma crítica, se podía instruir al agente para aplicar una política de evidencia primero a nivel de prompt: renderizar geometría solo donde los datos de vista la respaldaran realmente, dejar las regiones no soportadas escasas en lugar de rellenadas y negarse a recurrir a heurísticas de elevación por capas para el panel 3D final. Ninguna otra herramienta al alcance del equipo combinaba ingesta de archivos, procesamiento de geometría con scripts, control de QC y entrega de visualización sin requerir un entorno de desarrollo separado y un ciclo de implementación más largo.
Flujo de trabajo
El analista cargó kavz-3244.dxf como único archivo fuente autorizado e inició una sesión de reconstrucción con dimensiones objetivo explícitas y un conjunto de instrucciones de evidencia primero.
Paso 1 — Segmentación de vistas. El agente analizó el DXF y lo segmentó en regiones de vista — lateral, frontal y superior — produciendo un artefacto de segmentación dedicado (kavz-3244_view_segmentation_v2.json). El analista revisó las asignaciones de rol de región para confirmar que las etiquetas reflejaban el rol final y no la procedencia de la ventana semilla del algoritmo de segmentación; una versión anterior había usado nombres de región derivados de ventanas de inicialización en lugar de asignaciones de vista confirmadas, y el analista lo detectó y corrigió antes de continuar.
Paso 2 — Correspondencia de características. El agente extrajo correspondencias de características entre vistas (kavz-3244_feature_correspondence.json), vinculando elementos geométricos entre vistas para fundamentar la colocación de secciones en evidencia de múltiples vistas en lugar de en una sola proyección. Este paso es lo que distingue la reconstrucción basada en evidencia de la asignación heurística de profundidad: una característica debe aparecer en más de una vista antes de ganarse una posición en el contorno reconstruido.
Paso 3 — Corte de secciones. Usando los datos de correspondencia, el agente generó cortes de sección a través del contorno reconstruido (kavz-3244_section_slices.json). Los cortes se colocaron solo donde existía soporte entre vistas; las zonas sin suficiente evidencia de correspondencia se dejaron en blanco, produciendo una reconstrucción honesta sobre sus huecos de cobertura en lugar de visualmente completa pero geométricamente fabricada.
Paso 4 — QC de la reconstrucción. Un artefacto de QC dedicado (kavz-3244_reconstruction_qc.json) capturó la evidencia de aprobación de puerta para cada comprobación configurada. El analista inspeccionó este resultado para verificar que las puertas se habían aprobado por las razones correctas — no solo que la marca de aprobado/rechazado estuviera configurada correctamente, sino que la evidencia subyacente fuera coherente con la intención de cada puerta — antes de aprobar el paso final de visualización.
Paso 5 — Geometría etiquetada con procedencia. El archivo de reconstrucción autorizado (kavz-3244_reconstructed_geometry_v2.json) consolidó la geometría basada en secciones con etiquetas de procedencia que identificaban la vista de origen de cada elemento, creando un vínculo trazable entre cada superficie renderizada y los datos de plano que la respaldaban.
Paso 6 — Generación del panel. El agente generó el panel HTML final (kavz-3244_dashboard_v3.html) bajo una instrucción explícita que prohibía el recurso de elevación por capas como respaldo para el panel 3D principal. El panel se renderiza solo a partir del artefacto de reconstrucción validado, lo que hace que la visualización sea directamente trazable a los resultados del flujo con puertas de QC. Dos versiones anteriores del panel y varios archivos de depuración fueron designados formalmente como sustituidos y excluidos del conjunto final de autoridad, proporcionando al equipo un registro inequívoco de qué resultados usar en los procesos posteriores.
Resultados
El pipeline basado en evidencia produjo los siguientes resultados frente al benchmark establecido:
| Dimension | Target | Achieved | Delta |
|---|---|---|---|
| Length | 7,895.0 mm | 7,895.0 mm | 0.0 mm |
| Width | 2,210.0 mm | 2,210.0 mm | 0.0 mm |
| Height | 2,820.0 mm | 2,763.6 mm | −56.4 mm |
La longitud y el ancho coincidieron exactamente con el objetivo. La altura quedó 56.4 mm por debajo, atribuible a una cobertura más débil de las vistas superior/frontal en el DXF de origen — una limitación conocida y documentada, y una que se mantuvo dentro del umbral de tolerancia configurado del plan. Todas las puertas de control de calidad configuradas se aprobaron.
Más allá de la precisión dimensional, la reconstrucción entregó tres resultados cualitativos que el pipeline anterior no podía ofrecer:
- Proveniencia completa. Cada elemento geométrico lleva una etiqueta de vista de origen, lo que hace que las discrepancias sean diagnosticables en lugar de opacas. La brecha de altura de 56.4 mm se atribuye a una cobertura débil de las vistas superior/frontal, no a un error del pipeline — y el artefacto de QC registra esa atribución explícitamente.
- Escasez honesta. Las regiones no soportadas se dejan en blanco en lugar de rellenarse con profundidad heurística, de modo que los equipos de simulación y fabricación posteriores saben exactamente qué zonas requieren datos de origen adicionales antes de poder comprometer decisiones con tolerancia.
- Panel trazable. El dashboard HTML se renderiza a partir de un único artefacto con validación de QC, en lugar de datos brutos de capas, lo que ofrece a los revisores un contrato de entrega limpio y elimina la ambigüedad introducida por el conjunto anterior de archivos intermedios no designados.
El pipeline también produjo cinco artefactos intermedios con nombre que sirven como puntos de control para futuras ejecuciones de reconstrucción, reduciendo el tiempo necesario para diagnosticar regresiones o rastrear una discrepancia dimensional hasta su origen.
Prueba
"El pipeline antiguo nos daba un modelo visualmente completo, pero no teníamos forma de confiar en él — especialmente alrededor del techo y el frontal, donde teníamos una cobertura de planos débil. Lo que necesitaba era algo que me mostrara los huecos en lugar de ocultarlos. La sesión de energent.ai reconstruyó todo el pipeline alrededor de puertas de evidencia, y el JSON de QC me dijo exactamente por qué se aprobaba cada puerta. Eso es una clase de salida distinta a la que teníamos antes."
— Cita compuesta que refleja el rol de analista CAD/ingeniería descrito en este caso de estudio
El entregable final — kavz-3244_dashboard_v3.html — presenta la reconstrucción pseudo-3D con geometría basada en secciones, elementos etiquetados con proveniencia y paneles de resumen dimensional. El artefacto de QC (kavz-3244_reconstruction_qc.json) proporciona la evidencia de aprobación de puertas que sustenta el dashboard y está disponible para revisión junto con él.
Nota de confianza
La reconstrucción descrita aquí es una representación pseudo-3D basada en secciones derivada de una única fuente DXF 2D, no un modelo CAD paramétrico completo. El déficit de 56.4 mm en altura refleja una limitación real en la cobertura de vistas superior/frontal de los datos de origen — no es un defecto del producto, y no desaparece ajustando los parámetros de visualización. Los equipos que utilicen esta salida para simulación posterior, herramientas de fabricación o revisión de conformidad dimensional deben tratar las zonas escasas como si requirieran planos de origen adicionales o datos de nube de puntos antes de comprometer decisiones con tolerancia. Las puertas de QC del agente confirman la consistencia interna del pipeline de reconstrucción; no certifican la conformidad con una norma dimensional externa ni sustituyen un protocolo de medición física.