Aprenda cómo Retrieval-Augmented Generation puede apoyar la ingeniería consultando normas, proyectos, especificaciones, informes y acervos técnicos con fuentes trazables.
¡Descúbrelo!
RAG en ingeniería es la aplicación de Retrieval-Augmented Generation — generación aumentada por recuperación — para responder preguntas basadas en documentos, normas, proyectos, especificaciones, informes, manuales y otros acervos técnicos. En lugar de depender únicamente del conocimiento incorporado al modelo de lenguaje, el sistema recupera contenido relevante de una fuente externa, añade ese material al contexto y genera una respuesta fundamentada.
La arquitectura es especialmente adecuada para ingeniería porque gran parte del conocimiento no está en páginas públicas ni permanece estático: está en documentos controlados, revisiones, especificaciones contractuales, planos, actas, informes y repositorios internos. Un modelo entrenado de forma genérica no sabe qué documento está vigente en un proyecto. Un sistema RAG puede recuperar la fuente autorizada y, cuando está bien implementado, mostrar de dónde provino la respuesta.
RAG no elimina las alucinaciones ni sustituye la gestión documental. Si el repositorio contiene una revisión incorrecta, el sistema puede recuperar esa revisión incorrecta. Si el chunking separa una condición de su excepción, la respuesta puede perder contexto. Si la búsqueda devuelve un pasaje irrelevante, el modelo puede generar una explicación coherente sobre una base inadecuada.
Por ello, RAG debe tratarse como un sistema de información y de ingeniería del conocimiento, no simplemente como un “chat con PDFs”. Su desempeño depende de la preparación del acervo, metadatos, recuperación, ranking, contexto, instrucciones, evaluación y gobernanza.
Cómo funciona una arquitectura RAG
A IA Generativa en Ingeniería explica el papel de los modelos generativos. RAG añade una capa de recuperación para reducir la dependencia del conocimiento paramétrico del modelo.
El flujo clásico tiene tres movimientos: recuperar, aumentar y generar.
Microsoft y AWS describen arquitecturas similares: el contenido se prepara e indexa; la consulta recupera pasajes relevantes; esos pasajes entran en el prompt; el modelo produce una respuesta fundamentada.
Corpus
El corpus es el conjunto de fuentes que la aplicación puede consultar.
En ingeniería, puede incluir normas licenciadas, especificaciones, memorias, informes, planos convertidos a una representación consultable, actas, RFI, manuales, data books, procedimientos e históricos.
La decisión más importante es definir qué fuentes están autorizadas.
Ingesta
Ingesta prepara documentos para busca.
Puede involucrar extracción de texto, limpieza, identificación de secciones, metadatos, conversión de tablas y tratamiento de imágenes.
Chunking
Los documentos largos se dividen en fragmentos menores.
Los chunks deben ser lo suficientemente pequeños para una recuperación precisa y lo suficientemente grandes para preservar contexto.
Una sección normativa puede exigir una estrategia diferente de la de un acta o manual.
Embeddings
Los embeddings representan contenido como vectores numéricos que capturan relaciones semánticas.
Permiten encontrar pasajes similares en significado incluso cuando las palabras no son idénticas.
Índice
El índice almacena contenido y metadatos para recuperación.
Puede utilizar búsqueda léxica, vectorial o híbrida.
Retrieval
La consulta del usuario se transforma en una búsqueda. El sistema recupera pasajes candidatos.
Reranking
Un reranker puede reorganizar los candidatos para colocar los pasajes más relevantes en primer lugar.
Augmentation
Los pasajes recuperados se añaden al contexto del modelo.
Generation
El modelo genera una respuesta utilizando pregunta, contexto e instrucciones.
Citación
Una aplicación de ingeniería debe preservar el vínculo entre afirmaciones y fuentes.
Sin citación, la respuesta puede ser útil para lectura, pero débil para una decisión auditable.
RAG no es una base de conocimiento por sí sola
RAG no corrige un repositorio sin gobernanza. Si revisión, estado, clasificación y acceso no están controlados, la recuperación puede acelerar la entrega de información incorrecta.
RAG es una arquitectura de consulta sobre fuentes.
Si los documentos no tienen gobernanza, el sistema no sabe qué revisión es válida. Si los permisos no fueron modelados, los usuarios pueden recuperar información a la que no deberían acceder.
A Gestión BIM e Información de Ingeniería y las prácticas de GED/CDE son antecedentes importantes porque organizan versión, estado, clasificación y acceso.
RAG debe consumir una fuente gobernada, no convertirse en el lugar donde se ocultan conflictos documentales.
Chunking: por qué dividir un documento es una decisión técnica
El chunking puede parecer una operación de TI, pero influye directamente en la calidad.
Imagine una especificación en la que el requisito aparece en un párrafo y la excepción en el siguiente. Si los fragmentos se separan sin solapamiento, la recuperación puede devolver solo el requisito.
Las estrategias comunes incluyen tamaño fijo, párrafo, heading, oración, semántica, jerárquica y solapamiento.
No existe una estrategia universal.
Los documentos técnicos suelen beneficiarse de una estructura jerárquica: sección, subsección, cláusula, tabla y metadatos.
Chunking por tipo documental
Una norma tiene una lógica diferente de la de un acta. Un manual tiene una jerarquía diferente de la de un plano convertido a texto.
Una estrategia madura puede variar según el tipo de fuente. Las especificaciones pueden segmentarse por sección; las actas por ítem decisorio; los data sheets por campos; los informes por heading.
Tablas
Tablas representam desafio porque célula isolada pode perder cabeçalho e unidade.
El pipeline debe preservar la relación entre filas, columnas y contexto.
Figuras y planos
Cuando la información está en una figura, scan o plano, la extracción textual puede ser insuficiente.
Puede ser necesario utilizar visión computacional, OCR especializado o metadatos asociados. El resultado debe indicar que la fuente original es visual.
Los metadatos son tan importantes como los embeddings
Los embeddings responden “¿qué es semánticamente parecido?”. Los metadatos responden “¿qué fuente es válida para este contexto?”.
En ingeniería, los filtros pueden incluir proyecto, cliente, disciplina, sistema, documento, revisión, estado, fecha, activo, idioma, clasificación y confidencialidad.
Una consulta sobre “protección contra sobretensiones” puede encontrar varios documentos semánticamente próximos. Los metadatos ayudan a limitar los resultados al proyecto y revisión correctos.
Revisión y supersesión
Si Rev. 03 sustituye a Rev. 02, el índice debe reflejarlo. Mantener todas las revisiones consultables sin reglas puede generar una respuesta técnicamente desactualizada.
Status
Un documento “en desarrollo” no debe necesariamente tener el mismo peso que un documento aprobado.
Proyecto y contrato
El mismo término puede tener criterios diferentes en contratos distintos. Los filtros de contexto evitan mezclas indebidas.
Búsqueda vectorial, léxica e híbrida
La búsqueda vectorial es eficaz para similitud semántica.
La búsqueda léxica es fuerte para códigos, identificadores, números, siglas y términos exactos.
La ingeniería utiliza muchos identificadores: TAGs, normas, códigos de documento, modelos de equipo y cláusulas. Por ello, la búsqueda híbrida suele ser relevante.
| Tipo de búsqueda | Fortaleza | Limitación |
| lexical | términos exactos y códigos | pierde sinónimos |
| vectorial | significado y semántica | puede aproximar contenidos indebidos |
| híbrida | combina ambas | exige calibración |
| filtros | restringe el contexto | depende de metadatos |
Top-k
Top-k define cuántos resultados entran en la etapa siguiente.
Pocos resultados pueden perder contexto; demasiados pueden contaminar el prompt. El valor debe probarse.
Reranking
Los rerankers reevalúan los candidatos con mayor profundidad. Pueden mejorar la relevancia, pero añaden latencia y costo.
Query rewriting y descomposición
Las preguntas complejas pueden reescribirse o dividirse.
“¿Qué requisitos del proyecto afectan puesta a tierra, DPS y telecomunicaciones?” puede convertirse en varias búsquedas por disciplina.
Los sistemas avanzados pueden descomponer la consulta, ejecutar búsquedas y reunir contexto.
Este recurso aumenta la cobertura, pero también la complejidad de evaluación.
Acrónimos y vocabulario técnico
RAG para ingeniería debe manejar siglas y terminología específica. “QGBT”, “MCC”, “VMS” o “BEP” pueden tener significados muy diferentes fuera del dominio.
Diccionarios, expansión de siglas y sinónimos pueden mejorar el retrieval.
RAG estándar vs. RAG agéntico
En RAG estándar, el pipeline es fijo: pregunta → búsqueda → contexto → respuesta.
En RAG agéntico, un agente decide cuándo buscar, qué fuentes consultar y si necesita repetir la recuperación.
Agentic RAG puede ayudar con preguntas multietapa y múltiples bases. También amplía la superficie de riesgo y el costo.
Aplicaciones en ingeniería
Consulta de normas
Los usuarios pueden preguntar por un requisito, condición o definición y recibir un pasaje relacionado.
Cuando las normas tienen restricciones de licencia, la arquitectura y el acceso deben respetar los derechos de uso.
Proyectos y especificaciones
RAG puede localizar requisitos, decisiones, materiales e interfaces en grandes conjuntos de documentos.
RFI y decisiones
Las consultas pueden recuperar historiales de preguntas, respuestas y decisiones similares.
Data books y documentación de proveedores
El sistema puede ayudar a localizar certificados, manuales, hojas de datos y registros.
Comisionamiento
Procedimientos, resultados y pendientes pueden consultarse en lenguaje natural.
Operación y mantenimiento
Manuales, procedimientos e historiales pueden formar una base para soporte técnico.
Gestión de activos
RAG puede recuperar documentación asociada a un activo, siempre que exista el vínculo entre documento y activo.
O Digital Twin y la gestión de activos amplían esta capacidad al conectar información técnica con la identidad del activo.
RAG en normas técnicas: precauciones específicas
Las normas tienen particularidades que exigen controles adicionales.
Licenciamiento
Muchas normas están protegidas por derechos de autor. La organización debe verificar las condiciones de almacenamiento, indexación y visualización.
Versión
Una norma puede ser sustituida, enmendada o tener una nueva edición. El sistema debe identificar versión y vigencia.
Contexto
Las cláusulas pueden depender de definiciones, alcance o excepciones en otras partes.
Citación
Idealmente, la respuesta debe señalar la cláusula o sección sin reproducir contenido excesivo.
Juicio profesional
RAG ayuda a localizar e interpretar, pero la aplicación normativa sigue dependiendo del contexto técnico.
RAG en proyectos multidisciplinarios
Un proyecto puede tener cientos o miles de documentos.
RAG puede ayudar a cruzar disciplinas, pero debe controlar el alcance.
Una pregunta sobre la alimentación de una cámara puede involucrar eléctrica, red, arquitectura y seguridad. Recuperar solo un documento puede ser insuficiente.
Las arquitecturas avanzadas pueden consultar índices por disciplina y después consolidar.
A Coordinación de Proyectos de Ingeniería sigue siendo necesaria para transformar información cruzada en decisiones de interfaz.
Citas y procedencia
Una respuesta técnica debe permitir volver a la fuente.
Una cita útil incluye documento, revisión, sección y, cuando sea posible, fragmento.
El usuario debe poder abrir la fuente y verificarla.
La aplicación también debe distinguir contenido recuperado de texto generado.
Nivel de confianza
Puede ser útil informar si la respuesta está sustentada por una fuente directa, varias fuentes consistentes o evidencia incompleta.
Este indicador no sustituye la revisión, pero ayuda al usuario a interpretar la respuesta.
Control de acceso
RAG no debe ignorar los permisos existentes.
Si un usuario no puede acceder a determinado documento en el GED, no debería recibir su contenido por el chat.
Esto exige security trimming o filtros de acceso durante retrieval.
Multiempresa y segregación
En entornos con varios clientes o proyectos, el aislamiento es crítico.
Un error de filtrado puede provocar fuga de información entre clientes. Las pruebas de autorización deben formar parte de la aceptación.
Riesgos de prompt injection
Los documentos recuperados son datos, no instrucciones confiables.
Un archivo puede contener texto malicioso diseñado para inducir al modelo a ignorar reglas o ejecutar acciones.
Las arquitecturas con agentes exigen una separación clara entre contenido e instrucciones, validación de herramientas y privilegios mínimos.
Cómo evaluar un sistema RAG
Antes de ampliar el corpus, un piloto debe medir retrieval y generación por separado. Preguntas reales, documentos vigentes y casos sin respuesta forman la base de la aceptación.
La evaluación debe separar retrieval de generation.
Retrieval
Preguntar: ¿se recuperaron los documentos correctos?
Las métricas pueden incluir recall@k, precision@k y MRR.
Groundedness
Preguntar: ¿la respuesta está sustentada por los fragmentos recuperados?
Citation correctness
Preguntar: ¿la cita realmente sustenta la afirmación?
Completeness
Preguntar: ¿la respuesta cubrió los puntos necesarios?
Answer relevance
Preguntar: ¿respondió a la pregunta formulada?
Latencia y costo
Un sistema excelente que tarda demasiado o cuesta mucho puede ser inviable.
Seguridad
Evaluar acceso indebido, fugas y comportamiento frente a contenido malicioso.
Microsoft recomienda un enfoque estructurado para preparación, chunking, embeddings, índice, retrieval y evaluación. En ingeniería, esta disciplina evita tratar RAG como simple configuración de producto.
Conjunto de prueba
Antes de liberar la solución, crear preguntas reales.
El conjunto debe incluir:
- preguntas fáciles;
- preguntas con sinónimos;
- códigos exactos;
- preguntas que exigen múltiples fuentes;
- conflictos entre documentos;
- documento sustituido;
- pregunta sin respuesta;
- usuario sin permiso.
Un buen sistema también debe saber decir “no encontré base suficiente”.
Golden set
Un golden set contiene preguntas, respuestas esperadas y fuentes correctas.
Permite comparar versiones del pipeline.
Regresión
Cuando cambian chunking, embedding, índice o modelo, se debe ejecutar nuevamente el conjunto de pruebas.
Si una actualización mejora una clase de preguntas y empeora otra, el equipo debe poder verlo.
Arquitectura por niveles de confianza
No toda respuesta necesita tener el mismo efecto.
| Nivel | Uso | Control |
| informativo | localizar y resumir | citación + revisión eventual |
| apoyo técnico | preparar análisis | revisión obligatoria |
| decisión | sustentar un requisito o aceptación | verificación independiente |
| acción | modificar sistema o workflow | agente restrito + autorizacción |
La autonomía debe disminuir a medida que aumenta la consecuencia.
Observabilidade e operacción
Un sistema RAG en producción debe ser monitoreado.
Registrar consultas, resultados, fontes, latência, erros e feedback ajuda a identificar degradacción.
También es útil acompañar las preguntas sin respuesta. Revelan brechas del corpus o fallas de retrieval.
A operacción deve possuir responsáveis por conteúdo, plataforma, segurança e validacción.
RAG y documentación de ingeniería
El valor aumenta cuando la documentación sigue estándares.
Código de documento, revisión, disciplina, tipo, proyecto y estado permiten filtros confiables.
Cuando ese estándar no existe, una iniciativa RAG a menudo revela problemas de gestión documental que ya existían.
Este diagnóstico es útil: muestra que la gobernanza de la información forma parte de la arquitectura de IA.
Cuando una organización necesita estructurar metadatos, estados y reglas de información antes del uso de IA, Gestión BIM e Información de Ingeniería es un servicio directamente relacionado.
Cómo implementar un piloto de RAG
RAG evoluciona por ciclos: preparar el acervo, probar chunking, calibrar la búsqueda, evaluar respuestas y ampliar fuentes. Cuando la base cambia continuamente, esta evolución puede estructurarse como soporte consultivo bajo demanda.
Elegir un corpus delimitado.
Definir preguntas reales.
Preparar documentos y metadatos.
Comparar estrategias de chunking.
Probar búsqueda léxica, vectorial e híbrida.
Medir retrieval.
Después medir generación.
Probar seguridad y ausencia de respuesta.
Registrar resultados.
Solo entonces ampliar el corpus.
Baseline
Medir cómo los usuarios encuentran información hoy: tiempo, tasa de éxito y fuentes utilizadas.
Criterio de aceptación
Definir umbrales para retrieval, groundedness, citas y seguridad.
Escala
Añadir nuevos tipos documentales uno por uno. Cada tipo puede exigir un parser y chunking diferente.
Un piloto pequeño bien evaluado es más útil que una base enorme sin ground truth.
Cuando la implantación exige ajustes continuos, conectores, pruebas y evolución del corpus, Servicios Continuados de Ingeniería Consultiva pueden organizar la evolución por etapas.
Cómo especificar y contratar RAG para ingeniería
El objeto debe explicar el acervo y el resultado esperado.
Corpus
Definir fuentes, formatos, volumen, actualización y permisos.
Pipeline de ingesta
Definir extracción, limpieza, chunking, embeddings, metadatos e indexación.
Retrieval
Definir tipos de búsqueda, filtros, reranking y top-k.
Generación
Definir modelo, prompts de sistema, política de citación y comportamiento cuando falte información.
Seguridad
Definir autenticación, autorización, logs, retención y confidencialidad.
Evaluación
Exigir conjunto de prueba, métricas de retrieval y generación y criterios de aceptación.
Operación
Definir actualización de documentos, reindexación, cambio de modelo, monitoreo e incidentes.
Portabilidad
Garantizar la exportación del corpus procesado, metadatos y configuraciones esenciales.
SLA y desempeño
Cuando el sistema entra en el workflow diario, disponibilidad, latencia y recuperación de fallas también se convierten en requisitos.
Auditoría
Exigir logs suficientes para reconstruir respuestas críticas.
Cuando diferentes proveedores participan en GED, cloud, modelo y aplicación, Owner’s Engineering puede mantener requisitos, interfaces y aceptación independientes de la implementación.
RAG x fine-tuning
RAG y fine-tuning resuelven problemas diferentes.
RAG inyecta información externa en tiempo de consulta.
Fine-tuning modifica el comportamiento del modelo mediante ejemplos de entrenamiento.
Para conocimiento que cambia, documentos privados o necesidad de citación, RAG suele ser más natural. Fine-tuning puede ser útil para comportamiento, estilo o una tarea específica.
Los enfoques pueden coexistir.
RAG vs. búsqueda tradicional
La búsqueda tradicional devuelve documentos o enlaces.
RAG intenta transformar la recuperación en una respuesta.
Por ello, RAG aumenta la conveniencia y también la responsabilidad. Una respuesta sintetizada puede ocultar que la evidencia era parcial.
Las interfaces maduras deben mantener acceso al documento original.
Cuándo no usar RAG
Si la respuesta depende de un cálculo determinista simple, una API o función puede ser mejor.
Si la base es pequeña y estable, una búsqueda convencional puede ser suficiente.
Si el dato está altamente estructurado, las consultas SQL pueden ser más confiables.
RAG es adecuado cuando existe conocimiento documental amplio y variable, no como patrón obligatorio para cualquier problema.
Gobernanza y ciclo de vida
El corpus cambia. Los documentos se revisan, sustituyen y cancelan.
La aplicación debe saber actualizar el índice, eliminar contenido y preservar trazabilidad.
Cambios de embedding, chunking, retrieval o modelo pueden alterar el resultado. Las versiones deben controlarse y volver a probarse.
NIST AI RMF e ISO/IEC 42001 ayudan a estructurar riesgos, responsabilidades, evaluación y mejora continua.
Cómo diseñar el corpus para distintas familias documentales
Un único índice puede ser técnicamente simple, pero no siempre produce la mejor recuperación. Normas, memorias, actas, planos, manuales y data sheets tienen estructuras y patrones de consulta diferentes. En aplicaciones maduras, el diseño del corpus considera estas diferencias desde la ingesta.
Las normas exigen preservar jerarquía y versión. Las actas exigen identificar decisión, responsable y fecha. Los manuales pueden requerir producto, modelo y revisión. Los data sheets dependen de campos y unidades. Los informes pueden requerir relación con proyecto, activo o evento.
Cuando estas características se convierten en metadatos, el retrieval puede combinar semántica con filtros de contexto. La calidad deja de depender solo del embedding y pasa a utilizar conocimiento explícito sobre el documento.
Arquitectura de actualización y reindexación
RAG en ingeniería debe acompañar el ciclo de vida documental. Un documento nuevo puede sustituir a otro, una revisión puede cancelarse y un manual puede cambiar después de una actualización de equipo. El índice debe reflejar estos cambios en un plazo compatible con el uso.
Eventos de actualización
La reindexación puede activarse por publicación de una nueva revisión, cambio de estado, modificación de permisos o inclusión de una nueva fuente. Cada evento debe preservar historial suficiente para auditoría y retirar la versión anterior del conjunto de resultados activos cuando haya sido sustituida.
Reindexación parcial
Reprocesar todo el acervo ante cada cambio puede ser costoso y lento. Los pipelines bien diseñados identifican documentos modificados y actualizan solo lo necesario, manteniendo consistencia entre metadatos, chunks y embeddings.
Cómo tratar respuestas conflictivas entre fuentes
Los proyectos reales contienen conflictos. Una especificación puede diferir de un plano, un acta puede modificar una decisión anterior y un manual del fabricante puede no reflejar una condición contractual específica.
El sistema no debe ocultar ese conflicto produciendo una única respuesta sintética. Una estrategia más segura es presentar las fuentes divergentes, indicar revisión y contexto y derivar la decisión a análisis técnico.
Esto exige instrucciones explícitas al modelo: cuando fuentes relevantes discrepen, señalar el conflicto en lugar de elegir silenciosamente una de ellas.
RAG como infraestructura de conocimiento, no solo interfaz de chat
Aunque el chat sea la interfaz más visible, la misma arquitectura puede alimentar otros workflows. Un servicio puede consultar requisitos durante Design Review, completar metadatos, apoyar la clasificación de RFI, verificar documentación de proveedores o generar contexto para un agente.
Tratar RAG como infraestructura reutilizable cambia las decisiones de arquitectura: APIs, índices, política de acceso, observabilidad y evaluación pasan a ser activos corporativos. El front-end puede cambiar sin reconstruir toda la base de conocimiento.
Este enfoque también facilita separar responsabilidades. El equipo documental gobierna las fuentes; el equipo de plataforma mantiene ingesta e índices; ingeniería valida criterios y casos de uso; seguridad controla el acceso. El modelo de lenguaje es solo una capa de este sistema.
Consideraciones finales
RAG es una de las aplicaciones de IA con mayor afinidad con la ingeniería porque trabaja directamente sobre conocimiento documental.
Su valor no está en “conversar con PDFs”, sino en reducir el tiempo de búsqueda preservando contexto, fuente y control.
Una arquitectura confiable exige acervo gobernado → ingesta → chunking → metadatos → retrieval → contexto → generación → citación → evaluación → operación.
Cuando esta cadena está bien gestionada, RAG puede transformar grandes acervos en una interfaz de conocimiento técnico sin ocultar la fuente que sustenta cada decisión.
En arquitecturas con distintos proveedores para GED, cloud, modelo y aplicación, el propietario necesita mantener requisitos, seguridad, interfaces y aceptación independientes de cada plataforma.
Referencias técnicas
[1] AMAZON WEB SERVICES. What is RAG? Retrieval-Augmented Generation AI Explained. Disponible en: https://aws.amazon.com/what-is/retrieval-augmented-generation/
[2] AMAZON WEB SERVICES. Retrieval Augmented Generation options and architectures on AWS — Understanding RAG. Disponible en: https://docs.aws.amazon.com/prescriptive-guidance/latest/retrieval-augmented-generation-options/what-is-rag.html
[3] MICROSOFT. Retrieval augmented generation (RAG) and indexes in Microsoft Foundry. Microsoft Learn, 2026. Disponible en: https://learn.microsoft.com/en-us/azure/foundry/concepts/retrieval-augmented-generation
[4] MICROSOFT. Diseñar y desarrollar una solución RAG en Azure. Azure Architecture Center, 2026. Disponible en: https://learn.microsoft.com/pt-br/azure/architecture/ai-ml/guide/rag/rag-solution-design-and-evaluation-guide
[5] NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. Disponible en: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
Preguntas frecuentes
RAG combina recuperación de información con un modelo de lenguaje. El sistema recupera contenido relevante de una fuente externa, añade ese contexto a la pregunta y genera una respuesta fundamentada.
Porque el conocimiento técnico está distribuido en normas, proyectos, especificaciones, informes y manuales. RAG permite consultar ese acervo manteniendo vínculo con fuentes y revisiones.
No. Puede reducir respuestas sin fundamento, pero un retrieval deficiente, un documento obsoleto, contexto incompleto o generación inadecuada todavía pueden producir errores.
Son representaciones numéricas de contenido utilizadas para medir similitud semántica. En RAG, ayudan a localizar fragmentos relacionados con el significado de la consulta.
Es la división de documentos en fragmentos consultables. El tamaño, solapamiento y estructura de los chunks influyen fuertemente en la calidad de la recuperación.
No necesariamente. La ingeniería utiliza códigos, TAGs, normas e identificadores exactos, por lo que una búsqueda híbrida léxica y vectorial puede ser más adecuada.
Separando retrieval y generación. Las métricas pueden medir documentos recuperados, groundedness, corrección de las citas, completitud, relevancia, latencia, costo y seguridad.
No. RAG proporciona información externa en el momento de la consulta; fine-tuning modifica el comportamiento del modelo mediante entrenamiento adicional. Los enfoques pueden combinarse.
Materiales técnicos complementarios
Servicios relacionados
- Gestión BIM e Información de Ingeniería
- Servicios Continuados de Ingeniería Consultiva
- Design Review en Proyectos de Ingeniería
- Owner’s Engineering
- Proyectos en BIM
Contenidos principales sobre el tema
- Inteligencia Artificial en Ingeniería
- IA Generativa en Ingeniería
- Gestión de la Información en BIM
- CDE BIM
- Digital Twin
