Introducción Inteligencia Artificial Generativa
FranciscoAlfaro70
19 views
74 slides
Nov 02, 2025
Slide 1 of 74
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
About This Presentation
Introducción a la Inteligencia Artificial Generativa y los Modelos de Lenguaje (LLMs).
Explica los fundamentos de ML/AI, el ciclo de vida de proyectos de datos, y las primeras aplicaciones de LLMs en Ingeniería de Software. Incluye nociones de prompting, búsqueda semántica, RAG (Retrieval-Augmen...
Slide Content
Introducción a LLMs y
Agentes
Arquitecturas y Aplicaciones
en Ingeniería de Software
IV ESCUELA DE INFORMÁTICA
J. ANDRÉS DÍAZ PACE
2025
Agentes
Arquitecturas y Aplicaciones
en Ingeniería de Software
IV ESCUELA DE INFORMÁTICA
J. ANDRÉS DÍAZ PACE
2025
•Profesor titular en UNICEN (Tandil,
Argentina)
•Arquitecto de soluciones y Científico de
Datos Sr. en Globant (Argentina)
•Investigador principal en CONICET-
Argentina
•Miembro del Software Engineering Institute
(SEI, CMU) – 2007-2010
•Dr. in Ciencias de la Computación
Presentaciones
[email protected]
Argentina)
•Arquitecto de soluciones y Científico de
Datos Sr. en Globant (Argentina)
•Investigador principal en CONICET-
Argentina
•Miembro del Software Engineering Institute
(SEI, CMU) – 2007-2010
•Dr. in Ciencias de la Computación
Presentaciones
[email protected]
Agenda tentativa
1.Introducción a ML/AI
2.Posibles aplicaciones a Ing/Arq. de Software
3.Conceptos básicos de LLMs y prompting
4.Búsqueda semántica y RAG
5.Workflows
6.Agentes y tools (MCP)
7.Perspectiva
1.Introducción a ML/AI
2.Posibles aplicaciones a Ing/Arq. de Software
3.Conceptos básicos de LLMs y prompting
4.Búsqueda semántica y RAG
5.Workflows
6.Agentes y tools (MCP)
7.Perspectiva
IA, Machine Learning y GenAI
AI
ML
Algoritmos capaces de realizar tareas humanas,
de la misma forma que un humano
Algoritmos que permiten a las computadoras aprender por
sí mismas cómo realizar una tarea humana, sin ser
programadas específicamente para ello
•ML es un subconjunto de la AI
•Permite detectar automáticamente patrones en los datos
•Normalmente basado en modelado estadístico
•El modelo es entrenado automáticamente
•Y puede mejorarse en base a mayor cantidad de datos
AI
ML
Algoritmos capaces de realizar tareas humanas,
de la misma forma que un humano
Algoritmos que permiten a las computadoras aprender por
sí mismas cómo realizar una tarea humana, sin ser
programadas específicamente para ello
•ML es un subconjunto de la AI
•Permite detectar automáticamente patrones en los datos
•Normalmente basado en modelado estadístico
•El modelo es entrenado automáticamente
•Y puede mejorarse en base a mayor cantidad de datos
Noción de Modelo de ML
•Es una representación aproximada de un fenómeno complejo
•Datos ciertos datos de entrada (features) produce una salida (target), que generalmente
toma la forma de una predicción
•Existen distintos algoritmos para construir/entrenar un modelo
en base a un conjunto de datos
•Ejemplo1: ¿Cómo puedo estimar
el peso estimado de una valija?
•Ejemplo2 (Ing. de Soft.): ¿Cómo puedo
estimar si un componente tendrá fallas o no?
¿Cómo puedo clasificar un requerimiento?
•Es una representación aproximada de un fenómeno complejo
•Datos ciertos datos de entrada (features) produce una salida (target), que generalmente
toma la forma de una predicción
•Existen distintos algoritmos para construir/entrenar un modelo
en base a un conjunto de datos
•Ejemplo1: ¿Cómo puedo estimar
el peso estimado de una valija?
•Ejemplo2 (Ing. de Soft.): ¿Cómo puedo
estimar si un componente tendrá fallas o no?
¿Cómo puedo clasificar un requerimiento?
Modelo de Ciclo de Vida
https://docs.microsoft.com/en-us/azure/architecture/data-
science-process/lifecycle
https://docs.microsoft.com/en-us/azure/architecture/data-
science-process/lifecycle
Casos de Uso
•La estrategia de base es data-driven
•Análisis de imágenes de productos para clasificarlos de forma automática
•Análisis y clasificación automática de texto (por ej., noticias, tweets, spam, hate speech)
•Resúmenes automáticos de documentos (textuales)
•Chatbots para asistentes personales
•Predicción de indicadores (en base a información histórica)
•Detección de fraudes, o anomalías en datos
•Agrupamiento de items u entidades en base a distintos criterios (clustering)
•Sistemas de recomendación
•Recuperar documentos relevantes para un tema o consulta
•Q&A sobre documentos
•La estrategia de base es data-driven
•Análisis de imágenes de productos para clasificarlos de forma automática
•Análisis y clasificación automática de texto (por ej., noticias, tweets, spam, hate speech)
•Resúmenes automáticos de documentos (textuales)
•Chatbots para asistentes personales
•Predicción de indicadores (en base a información histórica)
•Detección de fraudes, o anomalías en datos
•Agrupamiento de items u entidades en base a distintos criterios (clustering)
•Sistemas de recomendación
•Recuperar documentos relevantes para un tema o consulta
•Q&A sobre documentos
Cosas que no son ML/IA …
•Buscar en una base de datos
•Aplicación de heurísticas
•Código hardcodeado
•Sistemas basados en reglas
(por mas que pueda parecer “inteligente”
desde la percepción del usuario)
•Buscar en una base de datos
•Aplicación de heurísticas
•Código hardcodeado
•Sistemas basados en reglas
(por mas que pueda parecer “inteligente”
desde la percepción del usuario)
Ejemplo: Clasificación de texto
•La asignación de una etiqueta depende del
uso de ciertas palabras en el texto, y en su
contexto
•Aplicable también a artefactos textuales de
software
•La asignación de una etiqueta depende del
uso de ciertas palabras en el texto, y en su
contexto
•Aplicable también a artefactos textuales de
software
Clasificación de texto en Ing. de Software
•Clasificar requerimientos
•Clasificar decisiones de diseño (ADRs)
•Otras?
•Clasificar requerimientos
•Clasificar decisiones de diseño (ADRs)
•Otras?
Metodología “ad-hoc” y con ML/IA
Consideraciones sobre los Datos
•Los datos tienen gran influencia en la “calidad” del modelo a desarrollar
•De dónde provienen los datos?
•Qué proceso se utilizó para extraerlos?
•Hay suficientes datos?
•Son lo suficientemente heterogéneos?
•Existe algún tipo de sesgo potencial en los datos?
•Describen la población que quiero caracterizar?
•Hay features faltantes, o con valores inválidos?
•Necesito “combinar” distintos conjuntos de datos?
•Los datos tienen gran influencia en la “calidad” del modelo a desarrollar
•De dónde provienen los datos?
•Qué proceso se utilizó para extraerlos?
•Hay suficientes datos?
•Son lo suficientemente heterogéneos?
•Existe algún tipo de sesgo potencial en los datos?
•Describen la población que quiero caracterizar?
•Hay features faltantes, o con valores inválidos?
•Necesito “combinar” distintos conjuntos de datos?
Aplicaciones a SE
https://arxiv.org/abs/2005.13299(2020)
Machine Learning for Software Engineering: A Systematic Mapping
Figure 5:MLSE Taxonomy
Figure 6:Articles by ML Type
research facet. 173 out of 227 (76%) articles have contri-
butions with empirically evaluated propositions, whereas 43
out of 227 (19%) articles are knowledge-based, 11 out of 227
(5%) articles have proposed solutions without any empirical
evaluation.
The evaluation facet represents the type of evaluation
that has been performed in the articles in order to evalu-
ate the propositions. The articles by the evaluation facet
are shown in Fig.11. Controlled Experiments have been
performed in 130 out 227 (57%) articles followed by Case
Studies in 46 out of 227 (20%) articles and Surveys in 14
out of 227 (6%) articles. 2 out of 227 (1%) articles have em-
ployed both a controlled experiment and a case study for an
empirical evaluation; whereas, rest of the articles – 35 out of
227 (15%) – did not use any empirical method for evaluation
purposes. Moreover, we found no article employing ethnog-
raphy or action research as empirical methods for evaluation.
Among the articles those performed control experiments, 63
articles proposed approaches/techniques/methods and 36 ar-
ticles proposed models/frameworks.
Saad Shafiq et al.:Preprint submitted to Elsevier Page 8 of 20
Machine Learning for Software Engineering: A Systematic Mapping
Figure 5:MLSE Taxonomy
Figure 6:Articles by ML Type
research facet. 173 out of 227 (76%) articles have contri-
butions with empirically evaluated propositions, whereas 43
out of 227 (19%) articles are knowledge-based, 11 out of 227
(5%) articles have proposed solutions without any empirical
evaluation.
The evaluation facet represents the type of evaluation
that has been performed in the articles in order to evalu-
ate the propositions. The articles by the evaluation facet
are shown in Fig.11. Controlled Experiments have been
performed in 130 out 227 (57%) articles followed by Case
Studies in 46 out of 227 (20%) articles and Surveys in 14
out of 227 (6%) articles. 2 out of 227 (1%) articles have em-
ployed both a controlled experiment and a case study for an
empirical evaluation; whereas, rest of the articles – 35 out of
227 (15%) – did not use any empirical method for evaluation
purposes. Moreover, we found no article employing ethnog-
raphy or action research as empirical methods for evaluation.
Among the articles those performed control experiments, 63
articles proposed approaches/techniques/methods and 36 ar-
ticles proposed models/frameworks.
Saad Shafiq et al.:Preprint submitted to Elsevier Page 8 of 20
•Mejora de prácticas
ingenieriles para el desarrollo
de software
•Por ej., en aspecto de
automatización, calidad, etc.
•Ciertamente, también
aplicable a otras áreas o
dominios conducidos por
datos
•Por ej., gestión
https://arxiv.org/abs/2005.13299(2020)
Machine Learning for Software Engineering: A Systematic Mapping
Figure 5:MLSE Taxonomy
Figure 6:Articles by ML Type
research facet. 173 out of 227 (76%) articles have contri-
butions with empirically evaluated propositions, whereas 43
out of 227 (19%) articles are knowledge-based, 11 out of 227
(5%) articles have proposed solutions without any empirical
evaluation.
The evaluation facet represents the type of evaluation
that has been performed in the articles in order to evalu-
ate the propositions. The articles by the evaluation facet
are shown in Fig.11. Controlled Experiments have been
performed in 130 out 227 (57%) articles followed by Case
Studies in 46 out of 227 (20%) articles and Surveys in 14
out of 227 (6%) articles. 2 out of 227 (1%) articles have em-
ployed both a controlled experiment and a case study for an
empirical evaluation; whereas, rest of the articles – 35 out of
227 (15%) – did not use any empirical method for evaluation
purposes. Moreover, we found no article employing ethnog-
raphy or action research as empirical methods for evaluation.
Among the articles those performed control experiments, 63
articles proposed approaches/techniques/methods and 36 ar-
ticles proposed models/frameworks.
Saad Shafiq et al.:Preprint submitted to Elsevier Page 8 of 20
Machine Learning for Software Engineering: A Systematic Mapping
Figure 5:MLSE Taxonomy
Figure 6:Articles by ML Type
research facet. 173 out of 227 (76%) articles have contri-
butions with empirically evaluated propositions, whereas 43
out of 227 (19%) articles are knowledge-based, 11 out of 227
(5%) articles have proposed solutions without any empirical
evaluation.
The evaluation facet represents the type of evaluation
that has been performed in the articles in order to evalu-
ate the propositions. The articles by the evaluation facet
are shown in Fig.11. Controlled Experiments have been
performed in 130 out 227 (57%) articles followed by Case
Studies in 46 out of 227 (20%) articles and Surveys in 14
out of 227 (6%) articles. 2 out of 227 (1%) articles have em-
ployed both a controlled experiment and a case study for an
empirical evaluation; whereas, rest of the articles – 35 out of
227 (15%) – did not use any empirical method for evaluation
purposes. Moreover, we found no article employing ethnog-
raphy or action research as empirical methods for evaluation.
Among the articles those performed control experiments, 63
articles proposed approaches/techniques/methods and 36 ar-
ticles proposed models/frameworks.
Saad Shafiq et al.:Preprint submitted to Elsevier Page 8 of 20
•Mejora de prácticas
ingenieriles para el desarrollo
de software
•Por ej., en aspecto de
automatización, calidad, etc.
•Ciertamente, también
aplicable a otras áreas o
dominios conducidos por
datos
•Por ej., gestión
•Tipos de aplicaciones:
•Requirements to Architecture
•Architecture to Code
•Requirements to Architecture to
Code
•Code to Architecture
•Architecture to Architecture
“LLMs are most frequently applied in the
Requirement-to-Architecture (40%) and
Architecture-to-Code (32%) transitions, while
Architecture-to-Architecture (3%) is the least
explored”
Contents lists available at ScienceDirect
The Journal of Systems & Software
journal homepage: www.elsevier.com/locate/jss
Generative AI for software architecture.
Applications, challenges, and future directions
I
Matteo Esposito
a
, Xiaozhou Li
a
, Sergio Moreschini
a,b
, Noman Ahmad
a
,
Tomas Cerny
c
, Karthik Vaidhyanathan
d
, Valentina Lenarduzzi
a
, Davide Taibi
a,<
a
University of Oulu, Finland
b
Tampere University, Finland
c
University of Arizona, USA
d
Software Engineering Research Center, IIIT Hyderabad, India
A R T I C L E I N F O
Dataset link:https://doi.org/10.5281/zenodo.1
5032395
Keywords:
Generative AI
Software architecture
Multivocal literature review
Large language model
Prompt engineering
Model human interaction
XAI
A B S T R A C T
Context:Generative Artificial Intelligence (GenAI) is transforming much of software development, yet its
application in software architecture is still in its infancy.
Aim:Systematically synthesize the use, rationale, contexts, usability, and challenges of GenAI in software
architecture.
Method:Multivocal literature review (MLR), analyzing peer-reviewed and gray literature, identifying current
practices, models, adoption contexts, reported challenges, and extracting themes via open coding.
Results:This review identifies a significant adoption of GenAI for architectural decision support and architec-
tural reconstruction. OpenAI GPT models are predominantly applied, and there is consistent use of techniques
such as few-shot prompting and retrieval-augmented generation (RAG). GenAI has been applied mostly to
the initial stages of the Software Architecture Life Cycle (SALC), such as Requirements-to-Architecture and
Architecture-to-Code. Monolithic and microservice architectures were the main targets. However, rigorous
testing of GenAI outputs was typically missing from the studies. Among the most frequent challenges are
model precision, hallucinations, ethical aspects, privacy issues, lack of architecture-specific datasets, and the
absence of sound evaluation frameworks.
Conclusions:GenAI shows significant potential in software design, but there are several challenges on its way
towards greater adoption. Research efforts should target designing general evaluation methodologies, handling
ethics and precision, increasing transparency and explainability, and promoting architecture-specific datasets
and benchmarks to overcome the gap between theoretical possibility and practical use.
Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.
1. Introduction
Generative AI (GenAI) is driven by the need to create, innovate, and
automate complex tasks that traditionally require human creativity.
It empowers companies and individuals to unlock new possibilities,
promote innovation, and improve productivity (Esposito et al., 2024a).
In software engineering, GenAI is revolutionizing the way develop-
ers design, write, and maintain code (Russo, 2024). Given its potential
and benefits, the integration of GenAI within the domain of software
engineering has gained increasing attention as it has a transformative
I
Editor: Heiko Koziolek.
<
Corresponding author.
E-mail addresses: [email protected] (M. Esposito), [email protected] (X. Li), [email protected] (S. Moreschini), [email protected]
(N. Ahmad), [email protected] (T. Cerny), [email protected] (K. Vaidhyanathan), [email protected] (V. Lenarduzzi),
[email protected] (D. Taibi).
potential to enhance and automate various aspects of the software
development lifecycle (Sauvola et al., 2024).
Although GenAI has shown its capabilities in areas such as code
generation, software documentation, and software testing (Jahi¢ and
Sami, 2024; Esposito et al., 2024b), its application in software architec-
ture remains an emerging area of research, with ongoing debates about
its effectiveness (Dhar et al., 2024a), reliability (Raghavan, 2024), and
best practices (Soliman and Keim, 2025). Researching the application
of GenAI in software architecture is crucial because it has the potential
https://doi.org/10.1016/j.jss.2025.112607
Received 17 March 2025; Received in revised form 12 August 2025; Accepted 26 August 2025
TheJournalofSystemsandSoftware231 112607
Availableonline17September2025
0164-1212/©2025TheAuthors.PublishedbyElsevierInc.ThisisanopenaccessarticleundertheCCBYlicense664(6.200224/.)
GenAI for SA: What has been done?
Just accepted at JSS
38https://arxiv.org/abs/2503.13310(2025)
Aplicaciones a SE
•Requirements to Architecture
•Architecture to Code
•Requirements to Architecture to
Code
•Code to Architecture
•Architecture to Architecture
“LLMs are most frequently applied in the
Requirement-to-Architecture (40%) and
Architecture-to-Code (32%) transitions, while
Architecture-to-Architecture (3%) is the least
explored”
Contents lists available at ScienceDirect
The Journal of Systems & Software
journal homepage: www.elsevier.com/locate/jss
Generative AI for software architecture.
Applications, challenges, and future directions
I
Matteo Esposito
a
, Xiaozhou Li
a
, Sergio Moreschini
a,b
, Noman Ahmad
a
,
Tomas Cerny
c
, Karthik Vaidhyanathan
d
, Valentina Lenarduzzi
a
, Davide Taibi
a,<
a
University of Oulu, Finland
b
Tampere University, Finland
c
University of Arizona, USA
d
Software Engineering Research Center, IIIT Hyderabad, India
A R T I C L E I N F O
Dataset link:https://doi.org/10.5281/zenodo.1
5032395
Keywords:
Generative AI
Software architecture
Multivocal literature review
Large language model
Prompt engineering
Model human interaction
XAI
A B S T R A C T
Context:Generative Artificial Intelligence (GenAI) is transforming much of software development, yet its
application in software architecture is still in its infancy.
Aim:Systematically synthesize the use, rationale, contexts, usability, and challenges of GenAI in software
architecture.
Method:Multivocal literature review (MLR), analyzing peer-reviewed and gray literature, identifying current
practices, models, adoption contexts, reported challenges, and extracting themes via open coding.
Results:This review identifies a significant adoption of GenAI for architectural decision support and architec-
tural reconstruction. OpenAI GPT models are predominantly applied, and there is consistent use of techniques
such as few-shot prompting and retrieval-augmented generation (RAG). GenAI has been applied mostly to
the initial stages of the Software Architecture Life Cycle (SALC), such as Requirements-to-Architecture and
Architecture-to-Code. Monolithic and microservice architectures were the main targets. However, rigorous
testing of GenAI outputs was typically missing from the studies. Among the most frequent challenges are
model precision, hallucinations, ethical aspects, privacy issues, lack of architecture-specific datasets, and the
absence of sound evaluation frameworks.
Conclusions:GenAI shows significant potential in software design, but there are several challenges on its way
towards greater adoption. Research efforts should target designing general evaluation methodologies, handling
ethics and precision, increasing transparency and explainability, and promoting architecture-specific datasets
and benchmarks to overcome the gap between theoretical possibility and practical use.
Editor’s note: Open Science material was validated by the Journal of Systems and Software Open Science Board.
1. Introduction
Generative AI (GenAI) is driven by the need to create, innovate, and
automate complex tasks that traditionally require human creativity.
It empowers companies and individuals to unlock new possibilities,
promote innovation, and improve productivity (Esposito et al., 2024a).
In software engineering, GenAI is revolutionizing the way develop-
ers design, write, and maintain code (Russo, 2024). Given its potential
and benefits, the integration of GenAI within the domain of software
engineering has gained increasing attention as it has a transformative
I
Editor: Heiko Koziolek.
<
Corresponding author.
E-mail addresses: [email protected] (M. Esposito), [email protected] (X. Li), [email protected] (S. Moreschini), [email protected]
(N. Ahmad), [email protected] (T. Cerny), [email protected] (K. Vaidhyanathan), [email protected] (V. Lenarduzzi),
[email protected] (D. Taibi).
potential to enhance and automate various aspects of the software
development lifecycle (Sauvola et al., 2024).
Although GenAI has shown its capabilities in areas such as code
generation, software documentation, and software testing (Jahi¢ and
Sami, 2024; Esposito et al., 2024b), its application in software architec-
ture remains an emerging area of research, with ongoing debates about
its effectiveness (Dhar et al., 2024a), reliability (Raghavan, 2024), and
best practices (Soliman and Keim, 2025). Researching the application
of GenAI in software architecture is crucial because it has the potential
https://doi.org/10.1016/j.jss.2025.112607
Received 17 March 2025; Received in revised form 12 August 2025; Accepted 26 August 2025
TheJournalofSystemsandSoftware231 112607
Availableonline17September2025
0164-1212/©2025TheAuthors.PublishedbyElsevierInc.ThisisanopenaccessarticleundertheCCBYlicense664(6.200224/.)
GenAI for SA: What has been done?
Just accepted at JSS
38https://arxiv.org/abs/2503.13310(2025)
Aplicaciones a SE
1
Fundamentos de LLMs
Comprensión de modelos de lenguaje, prompting y
funcionamiento interno
2
RAG(Retrieval Augmented Generation)
Técnicas para enriquecer respuestas con info externa
3
Copilots
Desarrollo de sistemas de apoyo para usuarios
4
Agentes
Creación de sistemas con capacidad de decisión y acción
5
Sistemas Multiagente
Integración de múltiples agentes especializados
Nuestra hoja de ruta
Fundamentos de LLMs
Comprensión de modelos de lenguaje, prompting y
funcionamiento interno
2
RAG(Retrieval Augmented Generation)
Técnicas para enriquecer respuestas con info externa
3
Copilots
Desarrollo de sistemas de apoyo para usuarios
4
Agentes
Creación de sistemas con capacidad de decisión y acción
5
Sistemas Multiagente
Integración de múltiples agentes especializados
Nuestra hoja de ruta
Fundamentos de LLMs
Conceptos básicos
Los Modelos de Lenguaje de Gran Escala (LLMs) representan un avance fundamental en la inteligencia artificial
generativa, con capacidades que transforman nuestra interacción con la tecnología.
Modelo probabilístico sofisticado
Un LLM funciona como un sistema que, a partir de una entrada, genera salidas basadas en patrones
estadísticos que ha aprendido durante su entrenamiento con enormes volúmenes de texto.
Condicionamiento mediante prompting
El promptinges un mecanismo para dirigir las salidas del LLM, proporcionándole instrucciones y contexto
específicos que influyen en cómo responde el modelo.
``
Los Modelos de Lenguaje de Gran Escala (LLMs) representan un avance fundamental en la inteligencia artificial
generativa, con capacidades que transforman nuestra interacción con la tecnología.
Modelo probabilístico sofisticado
Un LLM funciona como un sistema que, a partir de una entrada, genera salidas basadas en patrones
estadísticos que ha aprendido durante su entrenamiento con enormes volúmenes de texto.
Condicionamiento mediante prompting
El promptinges un mecanismo para dirigir las salidas del LLM, proporcionándole instrucciones y contexto
específicos que influyen en cómo responde el modelo.
``
Ingeniería de LLMs
La ingeniería de LLMs se centra en la construcción de aplicaciones prácticas
potenciadas por modelos de lenguaje avanzados, integrando estas capacidades en
soluciones de software funcionales.
Objetivo principal:
Desarrollar aplicaciones de software que aprovechen las capacidades de los LLMs para
resolver problemas reales, como chatbots, generadores de contenido, asistentes
virtuales y herramientas de productividad.
"La ingeniería de LLMs no se trata solo de prompting efectivo, sino de diseñar
sistemas robustos que integren estos modelos dentro de una arquitectura de
software coherente, considerando aspectos como rendimiento, seguridad y
mantenimiento."
Para profundizar en buenas prácticas de ingeniería con LLMs, recomendamos
el artículo de Martin Fowler: Engineering Practices for LLM Applications
La ingeniería de LLMs se centra en la construcción de aplicaciones prácticas
potenciadas por modelos de lenguaje avanzados, integrando estas capacidades en
soluciones de software funcionales.
Objetivo principal:
Desarrollar aplicaciones de software que aprovechen las capacidades de los LLMs para
resolver problemas reales, como chatbots, generadores de contenido, asistentes
virtuales y herramientas de productividad.
"La ingeniería de LLMs no se trata solo de prompting efectivo, sino de diseñar
sistemas robustos que integren estos modelos dentro de una arquitectura de
software coherente, considerando aspectos como rendimiento, seguridad y
mantenimiento."
Para profundizar en buenas prácticas de ingeniería con LLMs, recomendamos
el artículo de Martin Fowler: Engineering Practices for LLM Applications
Otra visión de un LLM
Procesamiento basado en
tokens
Lo que entra y sale de un LLM se
procesa y monetiza en unidades
llamadas tokens, que representan
palabras o partes de palabras en el
vocabulario del modelo.
Los tokens son la unidad fundamental
de procesamiento y determinan:
•El costo de utilizar el modelo
•La longitud máxima de texto que
puede procesar
•La eficiencia del procesamiento
Memoria contextual
La conversación entre el LLM y el
usuario mantiene una "ventana" de
contexto que funciona como memoria
a corto plazo.
Esta ventana de contexto:
•Tiene un límite de tokens (4K, 8K,
16K, 32K o más)
•Permite al modelo recordar partes
previas de la conversación
•Influye en la coherencia de
respuestas sucesivas
•Representa un desafío para
conversaciones largas
Herramienta para explorar tokenización: https://tiktokenizer.vercel.app/
Procesamiento basado en
tokens
Lo que entra y sale de un LLM se
procesa y monetiza en unidades
llamadas tokens, que representan
palabras o partes de palabras en el
vocabulario del modelo.
Los tokens son la unidad fundamental
de procesamiento y determinan:
•El costo de utilizar el modelo
•La longitud máxima de texto que
puede procesar
•La eficiencia del procesamiento
Memoria contextual
La conversación entre el LLM y el
usuario mantiene una "ventana" de
contexto que funciona como memoria
a corto plazo.
Esta ventana de contexto:
•Tiene un límite de tokens (4K, 8K,
16K, 32K o más)
•Permite al modelo recordar partes
previas de la conversación
•Influye en la coherencia de
respuestas sucesivas
•Representa un desafío para
conversaciones largas
Herramienta para explorar tokenización: https://tiktokenizer.vercel.app/
Algunos patrones para construir con LLMs
La creación de aplicaciones efectivas basadas en LLMs requiere diferentes enfoques según el caso de uso, cada uno con
sus propias ventajas y limitaciones.
Prompting
Diseño de instrucciones para obtener respuestas específicas del modelo. Es el método más directo pero
limitado por el contexto.
Fine-tuning
Adaptación del modelo a dominios específicos mediante entrenamiento adicional con datos relevantes.
RAG (Retrieval Augmented Generation)
Enriquecimiento de respuestas mediante la recuperación de información externa relevante al contexto.
Workflows
Secuencias de operaciones que combinan LLMs con otros componentes para tareas complejas.
Agentes
Sistemas autónomos que toman decisiones y ejecutan acciones basadas en objetivos definidos.
La creación de aplicaciones efectivas basadas en LLMs requiere diferentes enfoques según el caso de uso, cada uno con
sus propias ventajas y limitaciones.
Prompting
Diseño de instrucciones para obtener respuestas específicas del modelo. Es el método más directo pero
limitado por el contexto.
Fine-tuning
Adaptación del modelo a dominios específicos mediante entrenamiento adicional con datos relevantes.
RAG (Retrieval Augmented Generation)
Enriquecimiento de respuestas mediante la recuperación de información externa relevante al contexto.
Workflows
Secuencias de operaciones que combinan LLMs con otros componentes para tareas complejas.
Agentes
Sistemas autónomos que toman decisiones y ejecutan acciones basadas en objetivos definidos.
Prompting
Prompting como direccionador /
contexto
El prompting actúa como un conjunto de instrucciones que orientan al LLM sobre cómo
interpretar una solicitud y qué tipo de respuesta generar.
Ejemplos de diferentes contextos
Prompt 1:Tell me about: Apple
Prompt 2:Tell me about: Apple fruit
Prompt 3:Tell me about: Apple of my eye
Adaptación a diferentes roles
Prompt 4:You are a preschool teacher. Explain how attention in LLMs works.
Prompt 5:You are an NLP professor. Explain how attention in LLMs works.
Estos ejemplos demuestran cómo pequeños cambios en el prompt pueden alterar
radicalmente la respuesta del modelo, permitiéndonos obtener información con el
enfoque y nivel de detalle deseados.
contexto
El prompting actúa como un conjunto de instrucciones que orientan al LLM sobre cómo
interpretar una solicitud y qué tipo de respuesta generar.
Ejemplos de diferentes contextos
Prompt 1:Tell me about: Apple
Prompt 2:Tell me about: Apple fruit
Prompt 3:Tell me about: Apple of my eye
Adaptación a diferentes roles
Prompt 4:You are a preschool teacher. Explain how attention in LLMs works.
Prompt 5:You are an NLP professor. Explain how attention in LLMs works.
Estos ejemplos demuestran cómo pequeños cambios en el prompt pueden alterar
radicalmente la respuesta del modelo, permitiéndonos obtener información con el
enfoque y nivel de detalle deseados.
Prompting: Guía básica
Un prompt efectivo es la base para obtener resultados precisos y útiles de un LLM. La estructura adecuada puede marcar
la diferencia entre una respuesta genérica y una solución adaptada a tus necesidades.
Definición del rol
Especifica qué papel debe asumir el modelo (experto en marketing, profesor, programador...)
Planteamiento del problema
Describe claramente el contexto y el objetivo que se busca resolver
Descripción de la tarea
Detalla qué acción específica debe realizar el modelo
Instrucciones detalladas
Proporciona pautas sobre el formato, tono, extensión y otros requisitos
Ejemplos ilustrativos
Incluye casos de muestra para guiar el estilo y enfoque de la respuesta
Consideraciones adicionales
Añade restricciones, preferencias o cualquier información contextual relevante
Un prompt efectivo es la base para obtener resultados precisos y útiles de un LLM. La estructura adecuada puede marcar
la diferencia entre una respuesta genérica y una solución adaptada a tus necesidades.
Definición del rol
Especifica qué papel debe asumir el modelo (experto en marketing, profesor, programador...)
Planteamiento del problema
Describe claramente el contexto y el objetivo que se busca resolver
Descripción de la tarea
Detalla qué acción específica debe realizar el modelo
Instrucciones detalladas
Proporciona pautas sobre el formato, tono, extensión y otros requisitos
Ejemplos ilustrativos
Incluye casos de muestra para guiar el estilo y enfoque de la respuesta
Consideraciones adicionales
Añade restricciones, preferencias o cualquier información contextual relevante
Uso de LLMs para Clasificación y Regresión
Clasificación
La clasificaciónconsiste en asignar una etiqueta predefinida a un texto o entrada,
categorizando la información según criterios establecidos.
Ejemplos de aplicación:
•Clasificación de gastos por categoría (viáticos, oficina, transporte)
•Categorización de tickets de soporte por prioridad
•Análisis de sentimiento en comentarios (positivo, negativo, neutral)
•Clasificación de correos por departamento destinatario
Regresión
La regresiónimplica predecir un valor numérico basado en datos de entrada,
extrapolando información para obtener estimaciones cuantitativas.
Ejemplos de aplicación:
•Predicción de precios de productos o servicios
•Estimación de tiempos de entrega
•Cálculo de presupuestos aproximados
•Predicción de ventas futuras
Enfoques de prompting para tareas analíticas
Zero-shot
El modelo realiza la tarea sin ejemplos previos,
basándose únicamente en las instrucciones
One-shot
Se proporciona un único ejemplo para guiar al
modelo en la tarea solicitada
Few-shots
Se incluyen varios ejemplos que establecen un
patrón claro para que el modelo lo siga
Una ventaja clave de los LLMs es que pueden complementar sus clasificaciones o predicciones con explicaciones detalladas del razonamiento utilizado.
Clasificación
La clasificaciónconsiste en asignar una etiqueta predefinida a un texto o entrada,
categorizando la información según criterios establecidos.
Ejemplos de aplicación:
•Clasificación de gastos por categoría (viáticos, oficina, transporte)
•Categorización de tickets de soporte por prioridad
•Análisis de sentimiento en comentarios (positivo, negativo, neutral)
•Clasificación de correos por departamento destinatario
Regresión
La regresiónimplica predecir un valor numérico basado en datos de entrada,
extrapolando información para obtener estimaciones cuantitativas.
Ejemplos de aplicación:
•Predicción de precios de productos o servicios
•Estimación de tiempos de entrega
•Cálculo de presupuestos aproximados
•Predicción de ventas futuras
Enfoques de prompting para tareas analíticas
Zero-shot
El modelo realiza la tarea sin ejemplos previos,
basándose únicamente en las instrucciones
One-shot
Se proporciona un único ejemplo para guiar al
modelo en la tarea solicitada
Few-shots
Se incluyen varios ejemplos que establecen un
patrón claro para que el modelo lo siga
Una ventaja clave de los LLMs es que pueden complementar sus clasificaciones o predicciones con explicaciones detalladas del razonamiento utilizado.
Ejemplo: Clasificación de Gastos
Un caso práctico de clasificación utilizando LLMs es la categorización automática de gastos
empresariales, que simplifica la gestión contable y facilita el análisis financiero.
Prompt:Clasifica los siguientes gastos según su tipo: viáticos, oficina, transporte u otros.
Concepto Clasificación
Cena con cliente en restaurante Viáticos
Taxi a reunión en otra ciudad Transporte
Compra de hojas A4 Oficina
Estacionamiento en el aeropuerto Transporte
Pasaje aéreo a Córdoba Transporte
Toner para impresora Oficina
Alojamiento en hotel por viaje de negocios Viáticos
Este tipo de clasificación puede integrarse en sistemas contables para automatizar la
categorización de facturas y recibos, ahorrando tiempo y reduciendo errores humanos.
Un caso práctico de clasificación utilizando LLMs es la categorización automática de gastos
empresariales, que simplifica la gestión contable y facilita el análisis financiero.
Prompt:Clasifica los siguientes gastos según su tipo: viáticos, oficina, transporte u otros.
Concepto Clasificación
Cena con cliente en restaurante Viáticos
Taxi a reunión en otra ciudad Transporte
Compra de hojas A4 Oficina
Estacionamiento en el aeropuerto Transporte
Pasaje aéreo a Córdoba Transporte
Toner para impresora Oficina
Alojamiento en hotel por viaje de negocios Viáticos
Este tipo de clasificación puede integrarse en sistemas contables para automatizar la
categorización de facturas y recibos, ahorrando tiempo y reduciendo errores humanos.
Ejemplo: Estimar costo mensual
La regresión mediante LLMs permite estimar valores numéricos basados en patrones identificados en datos de
ejemplo, como en este caso de costos de auditoría.
Datos de referencia proporcionados:
Industria Empleados Facturación Anual Ubicación Costo
Auditoría
Comercio 25 $120.000.000 Buenos Aires $220.000
Manufactura 100 $500.000.000 Córdoba $600.000
Servicios 10 $80.000.000 Rosario $180.000
Servicios 30 $250.000.000 Buenos Aires $320.000
Comercio 50 $300.000.000 Mendoza $400.000
Estimaciones solicitadas:
Caso 1:Manufactura –70 empleados –$400.000.000 –RosarioEstimación:Aproximadamente $520.000
Caso 2:Servicios –15 empleados –$150.000.000 –CórdobaEstimación:Aproximadamente $240.000
El LLM no solo proporciona la estimación, sino que puede explicar los factores considerados en su cálculo,
como la correlación entre tamaño de empresa, industria y ubicación.
La regresión mediante LLMs permite estimar valores numéricos basados en patrones identificados en datos de
ejemplo, como en este caso de costos de auditoría.
Datos de referencia proporcionados:
Industria Empleados Facturación Anual Ubicación Costo
Auditoría
Comercio 25 $120.000.000 Buenos Aires $220.000
Manufactura 100 $500.000.000 Córdoba $600.000
Servicios 10 $80.000.000 Rosario $180.000
Servicios 30 $250.000.000 Buenos Aires $320.000
Comercio 50 $300.000.000 Mendoza $400.000
Estimaciones solicitadas:
Caso 1:Manufactura –70 empleados –$400.000.000 –RosarioEstimación:Aproximadamente $520.000
Caso 2:Servicios –15 empleados –$150.000.000 –CórdobaEstimación:Aproximadamente $240.000
El LLM no solo proporciona la estimación, sino que puede explicar los factores considerados en su cálculo,
como la correlación entre tamaño de empresa, industria y ubicación.
Ejemplo multi-modal: Estimar bien mueble
Datos de referencia proporcionados:
Marca/Modelo Año Kilómetros Estado Valor estimado
Toyota Yaris 2020 45.000 Muy bueno $7.200.000
Ford Focus 2018 80.000 Bueno $5.500.000
Peugeot 208 2021 25.000 Excelente $8.100.000
Renault Sandero 2019 60.000 Regular $4.200.000
Caso a evaluar:
Vehículo:Volkswagen Gol TrendAño:2020Kilómetros:
50.000Estado:BuenoUbicación:Córdoba
Proceso de estimación:
1.Análisis de vehículos comparables en antigüedad
2.Ajuste por kilometraje (penalización por mayor uso)
3.Evaluación del estado general
4.Consideración del mercado local (Córdoba)
5.Comparación con valores de referencia del modelo
Resultado:
Estimación:$5.800.000
Datos de referencia proporcionados:
Marca/Modelo Año Kilómetros Estado Valor estimado
Toyota Yaris 2020 45.000 Muy bueno $7.200.000
Ford Focus 2018 80.000 Bueno $5.500.000
Peugeot 208 2021 25.000 Excelente $8.100.000
Renault Sandero 2019 60.000 Regular $4.200.000
Caso a evaluar:
Vehículo:Volkswagen Gol TrendAño:2020Kilómetros:
50.000Estado:BuenoUbicación:Córdoba
Proceso de estimación:
1.Análisis de vehículos comparables en antigüedad
2.Ajuste por kilometraje (penalización por mayor uso)
3.Evaluación del estado general
4.Consideración del mercado local (Córdoba)
5.Comparación con valores de referencia del modelo
Resultado:
Estimación:$5.800.000
Más sobre Prompting
Las técnicas avanzadas de prompting permiten obtener respuestas más precisas y razonadas de
los LLMs, dirigiendo su proceso de pensamiento de manera específica.
Objetivo principal
Conseguir respuestas más efectivas o
acertadas mediante instrucciones
estratégicamente diseñadas que guíen el
razonamiento del modelo.
Enfoques según necesidad
Zero-shot:Sin ejemplos, solo
instrucciones
Few-shot:Con ejemplos que establezcan
el patrón deseado
Chain-of-Thought (CoT):Guiar al modelo
para que razone paso a paso
Técnicas específicas
Instrucciones como "think step by step" o "let's solve this systematically" pueden mejorar
significativamente la calidad de respuestas en problemas complejos.
Nota importante:Algunas técnicas avanzadas de prompting requieren mecanismos
adicionales como memoria para mantener el contexto a lo largo de múltiples
intercambios, especialmente en razonamientos extensos.
Las técnicas avanzadas de prompting permiten obtener respuestas más precisas y razonadas de
los LLMs, dirigiendo su proceso de pensamiento de manera específica.
Objetivo principal
Conseguir respuestas más efectivas o
acertadas mediante instrucciones
estratégicamente diseñadas que guíen el
razonamiento del modelo.
Enfoques según necesidad
Zero-shot:Sin ejemplos, solo
instrucciones
Few-shot:Con ejemplos que establezcan
el patrón deseado
Chain-of-Thought (CoT):Guiar al modelo
para que razone paso a paso
Técnicas específicas
Instrucciones como "think step by step" o "let's solve this systematically" pueden mejorar
significativamente la calidad de respuestas en problemas complejos.
Nota importante:Algunas técnicas avanzadas de prompting requieren mecanismos
adicionales como memoria para mantener el contexto a lo largo de múltiples
intercambios, especialmente en razonamientos extensos.
Tiposde LLMs (modelos)
Los modelos de lenguaje actuales se han especializado para destacar en diferentes tipos de tareas, cada uno con fortalezas particulares.
Generación
Especializados en crear contenido como
texto, código o ideas creativas. Ejemplos:
GPT-4, Claude, Llama 2.
•Creación de contenido creativo
•Redacción de documentos
•Generación de código
•Traducción y parafraseo
Razonamiento
Optimizados para resolver problemas
complejos que requieren análisis lógico.
Ejemplos: DeepMind's Chinchilla, PaLM 2.
•Resolución de problemas
matemáticos
•Análisis lógico
•Toma de decisiones estructuradas
•Inferencia causal
Multimodal
Capaces de procesar y generar
contenido en múltiples formatos.
Ejemplos: GPT-4V, Gemini, Claude 3.
•Análisis de imágenes
•Comprensión de gráficos
•Interpretación de datos visuales
•Generación de contenido visual
Para profundizar en los modelos de razonamiento, recomendamos esta guía visual: A Visual Guide to Reasoning LLMs
Los modelos de lenguaje actuales se han especializado para destacar en diferentes tipos de tareas, cada uno con fortalezas particulares.
Generación
Especializados en crear contenido como
texto, código o ideas creativas. Ejemplos:
GPT-4, Claude, Llama 2.
•Creación de contenido creativo
•Redacción de documentos
•Generación de código
•Traducción y parafraseo
Razonamiento
Optimizados para resolver problemas
complejos que requieren análisis lógico.
Ejemplos: DeepMind's Chinchilla, PaLM 2.
•Resolución de problemas
matemáticos
•Análisis lógico
•Toma de decisiones estructuradas
•Inferencia causal
Multimodal
Capaces de procesar y generar
contenido en múltiples formatos.
Ejemplos: GPT-4V, Gemini, Claude 3.
•Análisis de imágenes
•Comprensión de gráficos
•Interpretación de datos visuales
•Generación de contenido visual
Para profundizar en los modelos de razonamiento, recomendamos esta guía visual: A Visual Guide to Reasoning LLMs
https://newsletter.maartengrootendorst.com/p/a-visual-guide-to-reasoning-llms
Modelos de “razonamiento”
Modelos de “razonamiento”
Implementación
Modelos
Abstracciones para interactuar con diferentes
LLMs (OpenAI, Hugging Face, Anthropic, etc.) a
través de una interfaz unificada.
Prompts
Plantillas y herramientas para crear, gestionar y
optimizar prompts, incluyendo técnicas
avanzadas como few-shot learning.
Cadenas (Chains)
Secuencias de operaciones que combinan
modelos, prompts y herramientas para realizar
tareas complejas mediante pasos intermedios.
Memoria
Mecanismos para mantener el estado y el
contexto a lo largo de múltiples interacciones en
una conversación.
Vectorstores
Integración con bases de datos vectoriales para
implementar sistemas RAG eficientes.
Agentes
Sistemas que combinan LLMs con herramientas y
razonamiento para resolver problemas de forma autónoma.
Callbacks
Sistema de eventos para monitorizar, registrar y
depurar el funcionamiento de aplicaciones
complejas.
Modelos
Abstracciones para interactuar con diferentes
LLMs (OpenAI, Hugging Face, Anthropic, etc.) a
través de una interfaz unificada.
Prompts
Plantillas y herramientas para crear, gestionar y
optimizar prompts, incluyendo técnicas
avanzadas como few-shot learning.
Cadenas (Chains)
Secuencias de operaciones que combinan
modelos, prompts y herramientas para realizar
tareas complejas mediante pasos intermedios.
Memoria
Mecanismos para mantener el estado y el
contexto a lo largo de múltiples interacciones en
una conversación.
Vectorstores
Integración con bases de datos vectoriales para
implementar sistemas RAG eficientes.
Agentes
Sistemas que combinan LLMs con herramientas y
razonamiento para resolver problemas de forma autónoma.
Callbacks
Sistema de eventos para monitorizar, registrar y
depurar el funcionamiento de aplicaciones
complejas.
•Configurar/usar unLLM(Python)
•Templates de prompting
•Salidaestructurada
Notebooks
•Templates de prompting
•Salidaestructurada
Notebooks
Aplicación a Ingeniería de Software
•Clasificación de ADRs
•Taxonomía de Kruchten
•Atributo de calidad preponderante?
•Técnica: Prompting one-shot (por categoría)
TABLE I
KRUCHTEN[5]’SARCHITECTURALDECISIONONTOLOGY
Existence
(ontocrisis)
These decisions declare that an element or artifact will
exist in the design or implementation. Includes structural
decisions (e.g., layers, components) and behavioral deci-
sions (e.g., connectors, interactions). Structural decisions
lead to the creation of subsystems, layers, partitions, or
components. Behavioral decisions are more related to how
the elements interact together to provide functionality or to
satisfy some non-functional requirement (quality attribute),
or connectors.
Ban/Non-
existence
(anticrisis)
These decisions declare that an element will not exist in
the design or implementation and often used to rule out
alternatives.
Property
(diacrisis)
These decisions state a general, enduring quality or con-
straint of the system. These are often cross-cutting concerns
or design rules (positive) or constraints (negative).
Executive
(pericrisis)
These decisions refer to decisions that do not relate directly
to the design elements or their qualities but are driven more
by the business environment (financial), and affect the de-
velopment process (methodological), the people (education
and training), the organization, and to a large extend the
choices of technologies and tools.
step towards addressing this gap by analyzing the thematic and
structural content of ADRs at scale, considering the types of
decisions, concerns, and quality attributes covered in practice.
Types of Architecture Decisions
To better structure and understand architectural decision-
making, several taxonomies have been proposed in the AK
literature. These taxonomies categorize the types of decisions
made, the knowledge they capture, and their relationship to
quality attributes or architectural intent. One of the first and
widely referenced models is Kruchten’s ontology of archi-
tectural decisions [5], which identifies three types of deci-
sions commonly made during architecture design:existence
decisions,property decisions, andexecutive decisions. These
decisions can include attributes such as rationale, scope, status,
cost, and risk, among others. Furthermore, decisions can have
relations with each other to denote constraints, enablement,
conflicts, or subsumption relations, among others. For the
purpose of this work, we focus on the three main classes,
which are summarized in Table I. For example, our ADR in
Fig. 1 can be categorized as an existence decision.
An expert survey [14] found that⇡65%of the architectural
decisions made by practitioners are existence decisions, pri-
marily structural ones, while executive and property decisions
are less common, comprising27%and8%respectively. No-
tably, non-existence decisions were not identified, despite their
importance. As Kruchten [5] emphasized, such decisions are
critical to document because they are not evident in the system
structure or implementation and can easily be overlooked.
On the other hand, a design decision can be classified
according to itsmain concern or focus[9], for example,
choosing a programming language, architectural pattern, de-
ployment technology, or middleware asset, could all have
architectral implications. In this regard, Zimmermann et al.
[15], Zimmermann [16] introduced a classification as part of
their reusable architectural decision model, including: design,
technology, infrastructure, organizational/process, constraints,
TABLE II
CLASSIFICATION OF DECISIONS BASED ON THEIR MAIN CONCERN
Design They concern the logical organization, structure, and
decomposition of the system. Related to patterns, com-
ponents, layering, interfaces, data modeling.
Technology They concern the selection of technologies, platforms,
frameworks, libraries, or standards.
InfrastructureThey involve the deployment environment, hosting, run-
time platforms, networking, and hardware concerns.
Organizational
Process
They concern team structures, roles, responsibilities,
workflows, and processes that affect architecture.
ConstraintsThey refer to mandatory conditions from the business,
regulations, or existing systems that limit architectural
choices.
Crosscutting
Concerns
They relate to decisions that impact multiple parts of
the system simultaneously, often aspects like logging,
monitoring, security mechanisms.
Code-level
Decisions
They affect internal code structure, patterns at the class
or method level, or maintainability mechanisms, but are
not architectural in scope.
Fig. 3. ADR mining and processing pipeline.
quality attributes, crosscutting concerns, or code-level deci-
sions, as summarized in Table II. Our example ADR corre-
sponds mainly to a design decision, although it also includes
technology concerns.
The consideration of quality attributes is foundational to
architectural reasoning and knowledge management [1], as de-
cisions can target functional requirements or quality properties,
and also have side-effects on them. The latter two aspects
often entails architectural significance [17]. Along this line,
we adopt a classification of quality attributes grounded in the
ISO/IEC 25010 Standard for System and Software Quality
Models
5
, complemented with the attributes proposed by Bass
et al. [17]. In particular, we considered performance, reliability,
security, maintainability, scalability, usability, portability, com-
patibility, and testability. Coming back to our example ADR,
it explicitly mentions the attributes of performance, scalability
and maintainability.
III. STUDYDESIGN
We defined a data mining pipeline for processing ADRs,
extracting key pieces of information from them, and perform-
ing different classification and analysis tasks. We faced a
challenge related to the large number of ADRs to be processed,
which makes manual examination and annotation of all ADRs
unfeasible. The pipeline consists of the following four stages,
as outlined in Fig. 3:
1)Pre-processing.It involves the collection of ADRs from
projects in open-source repositories, an explorative data analy-
5
https://www.iso25000.com/index.php/en/iso-25000-standards/iso-25010
https://github.com/joelparkerhenderson/architecture-decision-record/tree/main
•Clasificación de ADRs
•Taxonomía de Kruchten
•Atributo de calidad preponderante?
•Técnica: Prompting one-shot (por categoría)
TABLE I
KRUCHTEN[5]’SARCHITECTURALDECISIONONTOLOGY
Existence
(ontocrisis)
These decisions declare that an element or artifact will
exist in the design or implementation. Includes structural
decisions (e.g., layers, components) and behavioral deci-
sions (e.g., connectors, interactions). Structural decisions
lead to the creation of subsystems, layers, partitions, or
components. Behavioral decisions are more related to how
the elements interact together to provide functionality or to
satisfy some non-functional requirement (quality attribute),
or connectors.
Ban/Non-
existence
(anticrisis)
These decisions declare that an element will not exist in
the design or implementation and often used to rule out
alternatives.
Property
(diacrisis)
These decisions state a general, enduring quality or con-
straint of the system. These are often cross-cutting concerns
or design rules (positive) or constraints (negative).
Executive
(pericrisis)
These decisions refer to decisions that do not relate directly
to the design elements or their qualities but are driven more
by the business environment (financial), and affect the de-
velopment process (methodological), the people (education
and training), the organization, and to a large extend the
choices of technologies and tools.
step towards addressing this gap by analyzing the thematic and
structural content of ADRs at scale, considering the types of
decisions, concerns, and quality attributes covered in practice.
Types of Architecture Decisions
To better structure and understand architectural decision-
making, several taxonomies have been proposed in the AK
literature. These taxonomies categorize the types of decisions
made, the knowledge they capture, and their relationship to
quality attributes or architectural intent. One of the first and
widely referenced models is Kruchten’s ontology of archi-
tectural decisions [5], which identifies three types of deci-
sions commonly made during architecture design:existence
decisions,property decisions, andexecutive decisions. These
decisions can include attributes such as rationale, scope, status,
cost, and risk, among others. Furthermore, decisions can have
relations with each other to denote constraints, enablement,
conflicts, or subsumption relations, among others. For the
purpose of this work, we focus on the three main classes,
which are summarized in Table I. For example, our ADR in
Fig. 1 can be categorized as an existence decision.
An expert survey [14] found that⇡65%of the architectural
decisions made by practitioners are existence decisions, pri-
marily structural ones, while executive and property decisions
are less common, comprising27%and8%respectively. No-
tably, non-existence decisions were not identified, despite their
importance. As Kruchten [5] emphasized, such decisions are
critical to document because they are not evident in the system
structure or implementation and can easily be overlooked.
On the other hand, a design decision can be classified
according to itsmain concern or focus[9], for example,
choosing a programming language, architectural pattern, de-
ployment technology, or middleware asset, could all have
architectral implications. In this regard, Zimmermann et al.
[15], Zimmermann [16] introduced a classification as part of
their reusable architectural decision model, including: design,
technology, infrastructure, organizational/process, constraints,
TABLE II
CLASSIFICATION OF DECISIONS BASED ON THEIR MAIN CONCERN
Design They concern the logical organization, structure, and
decomposition of the system. Related to patterns, com-
ponents, layering, interfaces, data modeling.
Technology They concern the selection of technologies, platforms,
frameworks, libraries, or standards.
InfrastructureThey involve the deployment environment, hosting, run-
time platforms, networking, and hardware concerns.
Organizational
Process
They concern team structures, roles, responsibilities,
workflows, and processes that affect architecture.
ConstraintsThey refer to mandatory conditions from the business,
regulations, or existing systems that limit architectural
choices.
Crosscutting
Concerns
They relate to decisions that impact multiple parts of
the system simultaneously, often aspects like logging,
monitoring, security mechanisms.
Code-level
Decisions
They affect internal code structure, patterns at the class
or method level, or maintainability mechanisms, but are
not architectural in scope.
Fig. 3. ADR mining and processing pipeline.
quality attributes, crosscutting concerns, or code-level deci-
sions, as summarized in Table II. Our example ADR corre-
sponds mainly to a design decision, although it also includes
technology concerns.
The consideration of quality attributes is foundational to
architectural reasoning and knowledge management [1], as de-
cisions can target functional requirements or quality properties,
and also have side-effects on them. The latter two aspects
often entails architectural significance [17]. Along this line,
we adopt a classification of quality attributes grounded in the
ISO/IEC 25010 Standard for System and Software Quality
Models
5
, complemented with the attributes proposed by Bass
et al. [17]. In particular, we considered performance, reliability,
security, maintainability, scalability, usability, portability, com-
patibility, and testability. Coming back to our example ADR,
it explicitly mentions the attributes of performance, scalability
and maintainability.
III. STUDYDESIGN
We defined a data mining pipeline for processing ADRs,
extracting key pieces of information from them, and perform-
ing different classification and analysis tasks. We faced a
challenge related to the large number of ADRs to be processed,
which makes manual examination and annotation of all ADRs
unfeasible. The pipeline consists of the following four stages,
as outlined in Fig. 3:
1)Pre-processing.It involves the collection of ADRs from
projects in open-source repositories, an explorative data analy-
5
https://www.iso25000.com/index.php/en/iso-25000-standards/iso-25010
https://github.com/joelparkerhenderson/architecture-decision-record/tree/main
Aplicación a Ingeniería de Software
•Actividad: Escribir un prompt que permita chequear la calidad de una
ADR, en el sentido de que tenga las secciones necesarias
(obligatorias, opcionales) de MADR, y si es posible, los contenidos
esperados por sección
•La evaluación debiera retornar un score de 1-100% y una explicación
Metadata: Status, date, Stakeholders
Options Pros
and Cons
Additional
information
Decision
drivers
Context and
Problem
Statement
Decision
outcome (with
justification)
Title
Considered
options
Consequences
(good, bad)
Validation
https://adr.github.io/madr/
•Actividad: Escribir un prompt que permita chequear la calidad de una
ADR, en el sentido de que tenga las secciones necesarias
(obligatorias, opcionales) de MADR, y si es posible, los contenidos
esperados por sección
•La evaluación debiera retornar un score de 1-100% y una explicación
Metadata: Status, date, Stakeholders
Options Pros
and Cons
Additional
information
Decision
drivers
Context and
Problem
Statement
Decision
outcome (with
justification)
Title
Considered
options
Consequences
(good, bad)
Validation
https://adr.github.io/madr/
Búsqueda Semántica
La búsqueda semántica va más allá de la coincidencia de palabras clave, utilizando el significado contextual de las consultaspara devolver
resultados relevantes incluso cuando no hay coincidencias exactas de términos.
A diferencia de la búsqueda tradicional que se basa en coincidencias léxicas, la búsqueda semántica entiende la intención y el
contexto de la consulta del usuario.
resultados relevantes incluso cuando no hay coincidencias exactas de términos.
A diferencia de la búsqueda tradicional que se basa en coincidencias léxicas, la búsqueda semántica entiende la intención y el
contexto de la consulta del usuario.
Arquitectura de un
sistema de búsqueda
semántica
Los sistemas de búsqueda semántica combinan técnicas de
procesamiento de lenguaje natural, embeddings vectoriales y
algoritmos de recuperación para proporcionar resultados
relevantes basados en el significado.
El proceso típicamente incluye la conversión de
documentos y consultas a vectores, el
almacenamiento eficiente en bases de datos
vectoriales y la recuperación basada en similitud.
sistema de búsqueda
semántica
Los sistemas de búsqueda semántica combinan técnicas de
procesamiento de lenguaje natural, embeddings vectoriales y
algoritmos de recuperación para proporcionar resultados
relevantes basados en el significado.
El proceso típicamente incluye la conversión de
documentos y consultas a vectores, el
almacenamiento eficiente en bases de datos
vectoriales y la recuperación basada en similitud.
Embeddings: Representaciones vectoriales
Concepto fundamental para agentes de IA
Los modelos de embedding son algoritmos entrenados para encapsular información en
representaciones densas dentro de un espacio multidimensional.
Losembeddings permiten a las máquinas
entender relaciones semánticas entre palabras,
frases, imágenes y otros tipos de datos.
Estas representaciones vectoriales capturan el
significado y contexto, permitiendo:
•Búsquedas semánticas
•Recomendaciones
•Clasificación de contenido
•Agrupación de datos similares
•Detección de anomalías
Concepto fundamental para agentes de IA
Los modelos de embedding son algoritmos entrenados para encapsular información en
representaciones densas dentro de un espacio multidimensional.
Losembeddings permiten a las máquinas
entender relaciones semánticas entre palabras,
frases, imágenes y otros tipos de datos.
Estas representaciones vectoriales capturan el
significado y contexto, permitiendo:
•Búsquedas semánticas
•Recomendaciones
•Clasificación de contenido
•Agrupación de datos similares
•Detección de anomalías
Matemática intuitiva detrás
de los vectores
La similitud coseno mide el coseno del ángulo entre dos vectores,
proporcionando un valor entre -1 y 1. Cuanto más cercano a 1, más
similares son los vectores en dirección, independientemente de su
magnitud.
de los vectores
La similitud coseno mide el coseno del ángulo entre dos vectores,
proporcionando un valor entre -1 y 1. Cuanto más cercano a 1, más
similares son los vectores en dirección, independientemente de su
magnitud.
Aplicaciones de la búsqueda
semántica
Motores de búsqueda avanzados
Mejora de resultados basados en la intención del usuario y no solo en
palabras clave
Sistemas RAG
Recuperación aumentada de generación para LLMs, proporcionando
contexto relevante desde fuentes externas
Bases de conocimiento
Organización inteligente de documentación técnica y recursos
empresariales
Chatbots y asistentes
Mejora de la comprensión contextual en sistemas conversacionales
semántica
Motores de búsqueda avanzados
Mejora de resultados basados en la intención del usuario y no solo en
palabras clave
Sistemas RAG
Recuperación aumentada de generación para LLMs, proporcionando
contexto relevante desde fuentes externas
Bases de conocimiento
Organización inteligente de documentación técnica y recursos
empresariales
Chatbots y asistentes
Mejora de la comprensión contextual en sistemas conversacionales
Articulación de búsqueda semántica con LLM
Pausa
RAG (Retrieval Augmented
Generation)
Generation)
Retrieval Augmented Generation (RAG)
RAG es una técnica que permite a los modelos de lenguaje acceder ainformación externa y específica, superando las
limitaciones de su conocimiento entrenado.
"Habla con tus documentos"
Ingestión de documentos
Procesamiento de documentos específicos de un tema o dominio particular parasu posterior consulta
Conversión en contexto
Transformación de los documentos en información estructurada que puede ser recuperada eficientemente
Recuperación contextual
Selección de fragmentos relevantes en función de la consulta del usuario
Generación fundamentada
Uso de los fragmentos recuperados como contexto adicional para que el LLM genere respuestas precisas
El efecto principal de RAG es que el LLM se "enfoca"(grounding) en los documentos proporcionados para generar
respuestas más precisas y relevantes, expandiendo y especializando su conocimiento de manera efectiva.
RAG es una técnica que permite a los modelos de lenguaje acceder ainformación externa y específica, superando las
limitaciones de su conocimiento entrenado.
"Habla con tus documentos"
Ingestión de documentos
Procesamiento de documentos específicos de un tema o dominio particular parasu posterior consulta
Conversión en contexto
Transformación de los documentos en información estructurada que puede ser recuperada eficientemente
Recuperación contextual
Selección de fragmentos relevantes en función de la consulta del usuario
Generación fundamentada
Uso de los fragmentos recuperados como contexto adicional para que el LLM genere respuestas precisas
El efecto principal de RAG es que el LLM se "enfoca"(grounding) en los documentos proporcionados para generar
respuestas más precisas y relevantes, expandiendo y especializando su conocimiento de manera efectiva.
DB Vectoriales
Funcionamiento básico
Convierten contenido a vectores numéricos
multidimensionales donde la cercanía en el espacio vectorial
representa similitud semántica
Ventajas clave
•Búsqueda por similitud conceptual
•Comprensión de sinónimos y relaciones
•Recuperación eficiente en grandes volúmenes
•Soporte para consultas multimodales
Aplicaciones en RAG
Permiten recuperar rápidamente los fragmentos más
relevantes para una consulta, incluso cuando no hay
coincidencia literal de términos
Funcionamiento básico
Convierten contenido a vectores numéricos
multidimensionales donde la cercanía en el espacio vectorial
representa similitud semántica
Ventajas clave
•Búsqueda por similitud conceptual
•Comprensión de sinónimos y relaciones
•Recuperación eficiente en grandes volúmenes
•Soporte para consultas multimodales
Aplicaciones en RAG
Permiten recuperar rápidamente los fragmentos más
relevantes para una consulta, incluso cuando no hay
coincidencia literal de términos
Funcionamiento de un RAG
Esquemade LLM con RAG
El flujo de información en un sistema RAG sigue un proceso estructurado que enriquece las consultas del usuario con conocimientoexterno relevante.
Consulta inicial
El usuario formula una pregunta o solicitud al
sistema
Búsqueda semántica
El sistema busca fragmentos relevantes en la
base de datos vectorial
Recuperación contextual
Se seleccionan los fragmentos más
pertinentes para la consulta
Inyección de contexto
Los fragmentos recuperados se añaden al
prompt original
Procesamiento en LLM
El modelo genera una respuesta basada en la
consulta enriquecida
Respuesta fundamentada
Se entrega al usuario una respuesta basada en
hechos verificables
La inyección de contexto externo hace que la respuesta sea más factual y basada en la información específica de la base de datos, reduciendo las
alucinaciones y aumentando la precisión.
El flujo de información en un sistema RAG sigue un proceso estructurado que enriquece las consultas del usuario con conocimientoexterno relevante.
Consulta inicial
El usuario formula una pregunta o solicitud al
sistema
Búsqueda semántica
El sistema busca fragmentos relevantes en la
base de datos vectorial
Recuperación contextual
Se seleccionan los fragmentos más
pertinentes para la consulta
Inyección de contexto
Los fragmentos recuperados se añaden al
prompt original
Procesamiento en LLM
El modelo genera una respuesta basada en la
consulta enriquecida
Respuesta fundamentada
Se entrega al usuario una respuesta basada en
hechos verificables
La inyección de contexto externo hace que la respuesta sea más factual y basada en la información específica de la base de datos, reduciendo las
alucinaciones y aumentando la precisión.
Visualización de un RAG
Las herramientas de visualización como RAGxplorer permiten
comprender mejor cómo funcionan internamente los sistemas
RAG, facilitando su optimización y depuración.
Características principales de RAGxplorer
•Visualización interactiva de espacios vectoriales en 3D
•Exploración de relaciones entre documentos y consultas
•Identificación de clusters temáticos en la base de
conocimiento
•Análisis de la efectividad de diferentes estrategias de
chunking
•Evaluación visual de la calidad de recuperación
Esta herramienta de código abierto es especialmente útil para
desarrolladores de sistemas RAG que necesitan ajustar y optimizar
sus implementaciones.
https://github.com/gabrielchua/RAGxplorer
Las herramientas de visualización como RAGxplorer permiten
comprender mejor cómo funcionan internamente los sistemas
RAG, facilitando su optimización y depuración.
Características principales de RAGxplorer
•Visualización interactiva de espacios vectoriales en 3D
•Exploración de relaciones entre documentos y consultas
•Identificación de clusters temáticos en la base de
conocimiento
•Análisis de la efectividad de diferentes estrategias de
chunking
•Evaluación visual de la calidad de recuperación
Esta herramienta de código abierto es especialmente útil para
desarrolladores de sistemas RAG que necesitan ajustar y optimizar
sus implementaciones.
https://github.com/gabrielchua/RAGxplorer
Estrategiasde Chunking e Indexado
El rendimiento de un sistema RAG depende en gran medida de cómo se dividen e indexan los documentos originales,
un proceso que requiere equilibrar diversos factores.
El desafío del chunking
El problema central consiste en encontrar el particionamiento "correcto" que:
•Preserve el contexto y la estructura lógica del documento
•Facilite la búsqueda eficiente de fragmentos relevantes
•Aproveche la información semántica para mejorar la recuperación
Chunking por estructura lingüística
División basada en oraciones, párrafos o secciones
naturales del texto
Particionamiento recursivo
División jerárquica que mantiene la relación entre
fragmentos de diferentes niveles
Enriquecimiento por contexto
Inclusión de metadatos o fragmentos de contexto
circundante para mejorar la comprensión
Chunking por modalidad
Tratamiento específico según el tipo de contenido:
texto, tablas, imágenes, etc.
Chunking semántico
División basada en unidades de significado o temas,
independientemente de la estructura formal
El rendimiento de un sistema RAG depende en gran medida de cómo se dividen e indexan los documentos originales,
un proceso que requiere equilibrar diversos factores.
El desafío del chunking
El problema central consiste en encontrar el particionamiento "correcto" que:
•Preserve el contexto y la estructura lógica del documento
•Facilite la búsqueda eficiente de fragmentos relevantes
•Aproveche la información semántica para mejorar la recuperación
Chunking por estructura lingüística
División basada en oraciones, párrafos o secciones
naturales del texto
Particionamiento recursivo
División jerárquica que mantiene la relación entre
fragmentos de diferentes niveles
Enriquecimiento por contexto
Inclusión de metadatos o fragmentos de contexto
circundante para mejorar la comprensión
Chunking por modalidad
Tratamiento específico según el tipo de contenido:
texto, tablas, imágenes, etc.
Chunking semántico
División basada en unidades de significado o temas,
independientemente de la estructura formal
•RAG simple con base vectorial
Notebooks
Notebooks
RAGs en Ing. de Software
•Generación de documentación (por ej., ADRs)
•Q&A sobre arquitecturas de referencia (por ej., AWS)
•Otros?
https://awslabs.github.io/mcp/servers/aws-knowledge-mcp-server
•Generación de documentación (por ej., ADRs)
•Q&A sobre arquitecturas de referencia (por ej., AWS)
•Otros?
https://awslabs.github.io/mcp/servers/aws-knowledge-mcp-server
Técnicas de RAG avanzadas
Más allá del RAG básico, existen numerosas técnicas avanzadas que mejoran la calidad, precisión y
eficiencia de la recuperación y generación de información.
Mejoras en la recuperación
Reranking
Reordenamiento de resultados mediante
un segundo modelo más preciso
Hybrid search
Combinación de búsqueda semántica y
por palabras clave
Query expansion
Generación de múltiples versiones de la
consulta para ampliar la cobertura
Mejoras en la generación
Self-query
El LLM reformula la consulta original para
optimizar la recuperación
Generación con citaciones
Inclusión de referencias a las fuentes de
información utilizadas
Post-procesamiento
Verificación de la respuesta generada
contra las fuentes recuperadas
Más información: https://www.ibm.com/think/topics/rag-techniques
Más allá del RAG básico, existen numerosas técnicas avanzadas que mejoran la calidad, precisión y
eficiencia de la recuperación y generación de información.
Mejoras en la recuperación
Reranking
Reordenamiento de resultados mediante
un segundo modelo más preciso
Hybrid search
Combinación de búsqueda semántica y
por palabras clave
Query expansion
Generación de múltiples versiones de la
consulta para ampliar la cobertura
Mejoras en la generación
Self-query
El LLM reformula la consulta original para
optimizar la recuperación
Generación con citaciones
Inclusión de referencias a las fuentes de
información utilizadas
Post-procesamiento
Verificación de la respuesta generada
contra las fuentes recuperadas
Más información: https://www.ibm.com/think/topics/rag-techniques
Técnicas de RAG avanzadas
Arquitecturas avanzadas
RAG recursivo
Múltiples ciclos de recuperación y generación para refinar
progresivamente la respuesta
RAG multi-vectorial
Uso de diferentes representaciones vectoriales para el mismo
contenido, optimizadas para distintos tipos de consultas
Chunking adaptativo
Fragmentación dinámica basada en la estructura semántica del
documento y el tipo de consulta
Knowledge graphs
Integración de grafos de conocimiento para representar
relaciones entre entidades y conceptos
Arquitecturas avanzadas
RAG recursivo
Múltiples ciclos de recuperación y generación para refinar
progresivamente la respuesta
RAG multi-vectorial
Uso de diferentes representaciones vectoriales para el mismo
contenido, optimizadas para distintos tipos de consultas
Chunking adaptativo
Fragmentación dinámica basada en la estructura semántica del
documento y el tipo de consulta
Knowledge graphs
Integración de grafos de conocimiento para representar
relaciones entre entidades y conceptos
¿Y si no usara RAG sino la ventana de contexto?
RAG (Retrieval Augmented Generation)
Características:
•Recuperación dinámica basada en la consulta
•Selección precisa de información relevante
•Menos dependiente del tamaño de contexto
•Mayor eficiencia para bases de conocimiento grandes
•Requiere infraestructura de búsqueda
CAG (Context-aware Generation)
Características:
•Carga directa de documentos completos en el contexto
•Aprovecha ventanas de contexto extensas (32K, 100K+ tokens)
•Implementación más simple
•Mejor comprensión del documento completo
•Limitado por el tamaño máximo de contexto
Más información: https://pair.gov.sg/articles/beyond-rag
RAG (Retrieval Augmented Generation)
Características:
•Recuperación dinámica basada en la consulta
•Selección precisa de información relevante
•Menos dependiente del tamaño de contexto
•Mayor eficiencia para bases de conocimiento grandes
•Requiere infraestructura de búsqueda
CAG (Context-aware Generation)
Características:
•Carga directa de documentos completos en el contexto
•Aprovecha ventanas de contexto extensas (32K, 100K+ tokens)
•Implementación más simple
•Mejor comprensión del documento completo
•Limitado por el tamaño máximo de contexto
Más información: https://pair.gov.sg/articles/beyond-rag
Aplicación a Ingeniería de Software
•Archmind
•Un conjunto de chatbots para practicar
toma de decisiones de arquitectura
•Técnica: RAG con prompts especializados y
bases de conocimiento de patterns
https://archmindv2-test.streamlit.app/
https://github.com/tommantonela/archmind
•Archmind
•Un conjunto de chatbots para practicar
toma de decisiones de arquitectura
•Técnica: RAG con prompts especializados y
bases de conocimiento de patterns
https://archmindv2-test.streamlit.app/
https://github.com/tommantonela/archmind
Aplicación a Ingeniería de Software
•Actividad: Realizar un RAG que permita contestar preguntas
sobre una fuente de conocimiento específica, relacionada con
Ingeniería de Software
•Actividad: Realizar un RAG que permita contestar preguntas
sobre una fuente de conocimiento específica, relacionada con
Ingeniería de Software
Copilots
Copilots
Los asistentes o copilots representan un nivel intermedio entre un simple chatbot y un agente autónomo, ofreciendo apoyo contextualizado
sin tomar decisiones por el usuario.
Características principales
•Memoria persistente de
conversaciones previas
•Implementación frecuente sobre
arquitectura RAG
•Capacidad para entender el
contexto del usuario
•Interfaz conversacional natural
Límites de autonomía
A diferencia de los agentes, los
asistentes no tienen autonomía para
decidir o ejecutar acciones, sino que se
limitan a sugerir, recomendar o generar
información que el usuario puede
aceptar, rechazar o modificar.
Aplicaciones comunes
•Asistentes de programación (GitHub
Copilot)
•Ayudantes de redacción y edición
•Soporte para análisis de datos
•Asistentes de productividad
integrados en aplicaciones
Los asistentes o copilots representan un nivel intermedio entre un simple chatbot y un agente autónomo, ofreciendo apoyo contextualizado
sin tomar decisiones por el usuario.
Características principales
•Memoria persistente de
conversaciones previas
•Implementación frecuente sobre
arquitectura RAG
•Capacidad para entender el
contexto del usuario
•Interfaz conversacional natural
Límites de autonomía
A diferencia de los agentes, los
asistentes no tienen autonomía para
decidir o ejecutar acciones, sino que se
limitan a sugerir, recomendar o generar
información que el usuario puede
aceptar, rechazar o modificar.
Aplicaciones comunes
•Asistentes de programación (GitHub
Copilot)
•Ayudantes de redacción y edición
•Soporte para análisis de datos
•Asistentes de productividad
integrados en aplicaciones
Agentes
Herramientas para
construir Agentes de IA
construir Agentes de IA
Frameworks
LangChain
LangChainis a framework for
building LLM-powered
applications.
LlamaIndex
Build agentic workflows to
extract information, synthesize
insights, and take actions over
the most complex enterprise
documents.
Agno
Agnois a python framework for
building multi-agent systems
with shared memory,
knowledge and reasoning.
Semantic Kernel
Semantic Kernelis a
lightweight, open-source
development kit that lets you
easily build AI agents and
integrate the latest AI models
into your C#, Python, or Java
codebase. It serves as an
efficient middleware that
enables rapid delivery of
enterprise-grade solutions.
LangChain
LangChainis a framework for
building LLM-powered
applications.
LlamaIndex
Build agentic workflows to
extract information, synthesize
insights, and take actions over
the most complex enterprise
documents.
Agno
Agnois a python framework for
building multi-agent systems
with shared memory,
knowledge and reasoning.
Semantic Kernel
Semantic Kernelis a
lightweight, open-source
development kit that lets you
easily build AI agents and
integrate the latest AI models
into your C#, Python, or Java
codebase. It serves as an
efficient middleware that
enables rapid delivery of
enterprise-grade solutions.
Frameworks
HayStack
Haystackis an open-source AI
orchestration framework built
by deepset that empowers
Python developers to build
real-world, compound, agentic
LLM applications.
CrewAI
CrewAIis an open source
multiagent orchestration
framework.
AutoGen
AutoGenis a framework for
creating multi-agent AI
applications that can act
autonomously or work
alongside humans.
Azure AI Foundry
This foundation combines
production-grade
infrastructure with friendly
interfaces, enabling developers
to focus on building
applications rather than
managing infrastructure.
HayStack
Haystackis an open-source AI
orchestration framework built
by deepset that empowers
Python developers to build
real-world, compound, agentic
LLM applications.
CrewAI
CrewAIis an open source
multiagent orchestration
framework.
AutoGen
AutoGenis a framework for
creating multi-agent AI
applications that can act
autonomously or work
alongside humans.
Azure AI Foundry
This foundation combines
production-grade
infrastructure with friendly
interfaces, enabling developers
to focus on building
applications rather than
managing infrastructure.
Alternativa: Flowise
Flowise es una plataforma low-codeque democratiza el desarrollo de aplicaciones basadas en IA, permitiendo a usuarios sin experiencia en
programación crear sistemas sofisticados.
Características principales
•Interfaz visual de "arrastrar y soltar" para diseñar flujos
•Configuración intuitiva de bloques y conexiones
•Integración con múltiples frameworks y herramientas de IA
•Compatibilidad con diversas bases de datos y fuentes de
información
•Plantillas prediseñadas para casos de uso comunes
•Despliegue simplificado en la nube
Ventajaspara desarrolladores
•Prototipado rápido de soluciones de IA
•Reducción significativa del tiempo de desarrollo
•Visualización clara de flujos de trabajo complejos
•Fácil experimentación con diferentes enfoques
•Depuración visual de problemas
•Colaboración mejorada con equipos multidisciplinares
Flowise es una plataforma low-codeque democratiza el desarrollo de aplicaciones basadas en IA, permitiendo a usuarios sin experiencia en
programación crear sistemas sofisticados.
Características principales
•Interfaz visual de "arrastrar y soltar" para diseñar flujos
•Configuración intuitiva de bloques y conexiones
•Integración con múltiples frameworks y herramientas de IA
•Compatibilidad con diversas bases de datos y fuentes de
información
•Plantillas prediseñadas para casos de uso comunes
•Despliegue simplificado en la nube
Ventajaspara desarrolladores
•Prototipado rápido de soluciones de IA
•Reducción significativa del tiempo de desarrollo
•Visualización clara de flujos de trabajo complejos
•Fácil experimentación con diferentes enfoques
•Depuración visual de problemas
•Colaboración mejorada con equipos multidisciplinares
Alternativa: Flowise
Alternativa: Flowise
Chatbots personalizados
Asistentesconversacionalesadaptadosa dominiosespecíficos
Análisis documental
Sistemas para extraer y procesar información de documentos
Automatizaciones
Flujos de trabajo que integran IA para tareas repetitivas
Sistemas RAG
Soluciones de búsqueda y respuesta basadas en conocimiento
específico
Curso recomendado: Curso de Flowise por Gabriel Merlo
Chatbots personalizados
Asistentesconversacionalesadaptadosa dominiosespecíficos
Análisis documental
Sistemas para extraer y procesar información de documentos
Automatizaciones
Flujos de trabajo que integran IA para tareas repetitivas
Sistemas RAG
Soluciones de búsqueda y respuesta basadas en conocimiento
específico
Curso recomendado: Curso de Flowise por Gabriel Merlo
Otra alternativa: AgentKit / AgentBuilder (OpenAI)
Aplicación a Ingeniería de Software
•Actividad (opcional): Tanto la actividad de prompting
para clasificación como la actividad de RAG podrían
realizarse con un editor no/low-code
•Actividad (opcional): Tanto la actividad de prompting
para clasificación como la actividad de RAG podrían
realizarse con un editor no/low-code
Sistemas Multiagente
Volviendoal LLM: Un punto de quiebre
A medida que los proyectos de IA se vuelven más complejos, los enfoques basados únicamente
en prompts empiezan a mostrar limitaciones significativas.
Limitaciones del super-prompt
Un prompt único, por muy sofisticado que sea,
no siempre resulta efectivo para resolver tareas
complejas que requieren múltiples pasos o
tipos de razonamiento diferentes.
Complejidad de los flujos
Al desarrollar aplicaciones con múltiples
invocaciones a LLMs, el proceso se vuelve cada
vez más difícil de implementar, evaluar y ajustar
de manera coherente.
Desafíos de orquestación
La coordinación de decisiones secuenciales en flujos de trabajo complejos (por ejemplo, selección
de candidatos para un perfil laboral) introduce nuevas capas de complejidad.
La transición de prompts individuales a sistemas modularizados representa un punto de
inflexión en el desarrollo de aplicaciones de IA, similar al paso de scripts monolíticos a
arquitecturas de software bien estructuradas.
A medida que los proyectos de IA se vuelven más complejos, los enfoques basados únicamente
en prompts empiezan a mostrar limitaciones significativas.
Limitaciones del super-prompt
Un prompt único, por muy sofisticado que sea,
no siempre resulta efectivo para resolver tareas
complejas que requieren múltiples pasos o
tipos de razonamiento diferentes.
Complejidad de los flujos
Al desarrollar aplicaciones con múltiples
invocaciones a LLMs, el proceso se vuelve cada
vez más difícil de implementar, evaluar y ajustar
de manera coherente.
Desafíos de orquestación
La coordinación de decisiones secuenciales en flujos de trabajo complejos (por ejemplo, selección
de candidatos para un perfil laboral) introduce nuevas capas de complejidad.
La transición de prompts individuales a sistemas modularizados representa un punto de
inflexión en el desarrollo de aplicaciones de IA, similar al paso de scripts monolíticos a
arquitecturas de software bien estructuradas.
Modularización: Divide, Conquista y Autonomía
La evolución natural de la modularización es el desarrollo de sistemas multiagente, donde cada componente
Tiene razonamientopropio
Cada agente aplica capacidades específicas de razonamiento a
su dominio de especialización
Se enfocaenobjetivosconcretos
Los agentes se concentran en resolver aspectos específicos del
problema global
Se comunicacon otrosagentes
Los agentes intercambian información y colaboran para alcanzar
objetivos comunes
Toma decisionesautónomas
Dentro de su ámbito, cada agente puede decidir cómo abordar
mejor los problemas
La evolución natural de la modularización es el desarrollo de sistemas multiagente, donde cada componente
Tiene razonamientopropio
Cada agente aplica capacidades específicas de razonamiento a
su dominio de especialización
Se enfocaenobjetivosconcretos
Los agentes se concentran en resolver aspectos específicos del
problema global
Se comunicacon otrosagentes
Los agentes intercambian información y colaboran para alcanzar
objetivos comunes
Toma decisionesautónomas
Dentro de su ámbito, cada agente puede decidir cómo abordar
mejor los problemas
Agente(s) con tool(s)
Sistemas Multiagente
1
2
3
4
5
Agentes
especializados
Entidades con roles
específicos y habilidades
diferenciadas (investigador,
crítico, sintetizador, etc.)
Protocolos de
comunicación
Mecanismos estructurados
para el intercambio de
información entre agentes
Orquestador central
Componente que coordina
las interacciones y el flujo
de trabajo entre agentes
Memoria compartida
Repositorio común de
información accesible para
todos los agentes del
sistema
Mecanismos de toma
de decisiones
Procesos para resolver
conflictos y determinar
acciones basadas en
múltiples inputs
1
2
3
4
5
Agentes
especializados
Entidades con roles
específicos y habilidades
diferenciadas (investigador,
crítico, sintetizador, etc.)
Protocolos de
comunicación
Mecanismos estructurados
para el intercambio de
información entre agentes
Orquestador central
Componente que coordina
las interacciones y el flujo
de trabajo entre agentes
Memoria compartida
Repositorio común de
información accesible para
todos los agentes del
sistema
Mecanismos de toma
de decisiones
Procesos para resolver
conflictos y determinar
acciones basadas en
múltiples inputs
Próximos pasos
Tags
Categories
EducationDownload
Download Slideshow Get the original presentation fileQuick Actions
Statistics
- Views 19
- Slides 74
- Age 5 days
Related Slideshows
11
TLE-9-Prepare-Salad-and-Dressing.pptxkkk
0 views
12
LESSON 1 ABOUT MEDIA AND INFORMATION.pptx
0 views
60
GRADE-8-AQUACULTURE-WEEKQ1.pdfdfawgwyrsewru
0 views
26
Feelings PP Game FOR CHILDREN IN ELEMENTARY SCHOOL.pptx
0 views
![Jeopardy_Figures_of_Speech_Template.pptx [Autosaved].pptx](https://slidepub.com/thumb/5828/284015828.jpg)
54
Jeopardy_Figures_of_Speech_Template.pptx [Autosaved].pptx
0 views
7
Jeopardy_Figures_of_Speech.pptxvdsvdsvsdvsd
0 views