Teoría · DacaCode

RAG: Pipeline de Indexación con Chunking, Embeddings y FAISS

Dacadev — Thu, 30 Jul 2026 00:00:00 -0500

Tabla de Contenido

En el artículo anterior de esta serie vimos que el indexing pipeline se compone de cuatro etapas: carga, fragmentación, conversión y almacenamiento. Hoy vamos a construir cada una de esas etapas con código real, usando como hilo conductor el ejemplo del primer artículo: un LLM que no sabe qué equipos jugarán la semifinal del Mundial 2026 porque su conocimiento no llega hasta esa fecha.

Note

Este es el tercer artículo de la serie RAGs. Vamos a implementar el indexing pipeline completo en Python: carga de datos, chunking, embeddings y una base de datos vectorial con FAISS. El código se irá acumulando en cada sección hasta terminar en un script único, listo para usar. 🚀

Carga de datos

El primer paso es traer la información desde su fuente original, sin importar si esta es una página web, un PDF o una API. Aunque suena trivial, esta etapa suele resolver varios problemas antes de entregar texto limpio: conexión y autenticación con la fuente, límites de rate limit, paginación y el formato en el que llegan los datos.

flowchart LR
 S["📂 Fuente"] --> C["🔌 Conector<br/>conexión y auth"]
 C --> E["📑 Extractor<br/>parseo de texto"]
 E --> M["🏷️ Metadatos<br/>añade/actualiza"]
 M --> T["🧹 Transformador<br/>limpieza y formato"]
 T --> OUT["📄 Texto plano"]

Para nuestro ejemplo usaremos la página de Wikipedia de la Copa Mundial de Fútbol de 2026. Con LangChain podemos descargar el HTML de forma asíncrona y transformarlo a texto plano en pocas líneas.

import asyncio
from typing import Final

from langchain_community.document_loaders import AsyncHtmlLoader
from langchain_community.document_loaders.async_html import default_header_template
from langchain_community.document_transformers import Html2TextTransformer

URL_OBJETIVO: Final[str] = (
 "https://es.wikipedia.org/wiki/Copa_Mundial_de_F%C3%BAtbol_de_2026"
)


async def cargar_y_limpiar_documento(url: str = URL_OBJETIVO) -> str:
 """
 Descarga el contenido HTML de una URL de forma asíncrona
 y lo transforma a texto plano.
 """
 # Wikipedia exige identificar el User-Agent en las peticiones (https://w.wiki/4wJS)
 encabezados = dict(default_header_template)
 encabezados["User-Agent"] = "DacaDev/0.0 (mi_correo@gmail.com)"

 cargador_html = AsyncHtmlLoader(url, header_template=encabezados)
 documentos_html = cargador_html.load()

 transformador_html_a_texto = Html2TextTransformer()
 documentos_texto_plano = transformador_html_a_texto.transform_documents(
 documentos_html
 )

 return documentos_texto_plano[0].page_content

Info

Dependencias usadas en esta sección: langchain, langchain-community, bs4 y html2text.

Segmentación en chunks

Con el texto limpio en mano, el siguiente problema es que no podemos meter un documento entero en cada consulta al LLM. Dividirlo en fragmentos —chunks— ataca tres limitaciones que ya vimos en el primer artículo:

Context window limitado: si llenamos el contexto con un documento completo para usar solo una parte, desperdiciamos capacidad del modelo.
Lost in the middle: en documentos largos, el modelo tiende a perder información ubicada en la mitad del texto.
Precisión de la búsqueda semántica: chunks pequeños y enfocados producen coincidencias más relevantes que un documento gigante.

El proceso de chunking sigue siempre la misma lógica, sin importar la herramienta que uses:

flowchart LR
 D["📄 Documento<br/>cargado"] --> P1["1️⃣ Dividir en<br/>unidades pequeñas"]
 P1 --> P2["2️⃣ Fusionar en<br/>chunks de tamaño objetivo"]
 P2 --> P3["3️⃣ Agregar overlap<br/>entre chunks"]
 P3 --> CH[("🧩 Chunks")]

El overlap (solapamiento) repite un pequeño trozo del chunk anterior al inicio del siguiente, para no cortar una idea justo en la frontera entre dos fragmentos.

Métodos de chunking

No todos los métodos dividen el texto de la misma forma. Estos son los más comunes:

Ancho fijo
Recursivo
Por tokens
Estructural

Corta por un carácter específico (\n, por ejemplo) y mide el tamaño en caracteres. Es el método más simple y predecible.

from langchain_text_splitters import CharacterTextSplitter

separador = CharacterTextSplitter(
 separator="\n",
 chunk_size=1000,
 chunk_overlap=200,
)
fragmentos = separador.create_documents([texto])

Prueba una lista de separadores en orden de jerarquía (párrafos, líneas, oraciones, palabras) hasta lograr chunks del tamaño deseado. Es el método recomendado para texto genérico.

from langchain_text_splitters import RecursiveCharacterTextSplitter

separador = RecursiveCharacterTextSplitter(
 separators=["\n\n", "\n", ".", " ", ""],
 chunk_size=1000,
 chunk_overlap=200,
)
fragmentos = separador.create_documents([texto])

Igual que el ancho fijo o el recursivo, pero mide chunk_size y chunk_overlap en tokens en vez de caracteres, usando el encoder de un tokenizer.

separador = RecursiveCharacterTextSplitter.from_tiktoken_encoder(
 encoding_name="cl100k_base",
 chunk_size=100,
 chunk_overlap=10,
)

Divide según la estructura del documento (encabezados HTML, tablas) en vez de un tamaño fijo. Útil cuando el formato original aporta información.

from langchain_text_splitters import HTMLSectionSplitter

secciones = [("h1", "Encabezado 1"), ("h2", "Encabezado 2"), ("table", "Tabla")]
segmentador = HTMLSectionSplitter(secciones)
fragmentos = segmentador.split_text(contenido_html)

Tip

No existe un método “correcto” universal: depende del tipo de contenido, del tamaño esperado de las consultas y del modelo de embeddings que uses. Para nuestro caso —texto genérico proveniente de Wikipedia— el splitter recursivo es la mejor opción por defecto.

Sumamos esta etapa a nuestro flujo:

from langchain_core.documents import Document
from langchain_text_splitters import RecursiveCharacterTextSplitter


def dividir_texto_en_fragmentos(texto: str) -> list[Document]:
 """
 Divide un texto intentando mantener oraciones y párrafos completos.
 """
 separador_recursivo = RecursiveCharacterTextSplitter(
 separators=["\n\n", "\n", ".", " ", ""],
 chunk_size=1000,
 chunk_overlap=200,
 )
 return separador_recursivo.create_documents([texto])

Dependencia añadida: langchain-text-splitters.

Conversión a embeddings

Ya tenemos los chunks, pero un motor de búsqueda no entiende texto: entiende números. Los embeddings son la solución — representaciones vectoriales donde textos con significado similar quedan ubicados cerca entre sí en el espacio vectorial.

Con una sola dimensión apenas podemos ordenar palabras en una línea, lo que deja fuera relaciones de significado más ricas:

Al aumentar las dimensiones ganamos flexibilidad para ubicar cada palabra según su relación real con las demás:

Un modelo de embeddings generaliza esta idea a n dimensiones: convierte cada texto en un vector numérico que captura su significado.

Estos modelos se entrenan sobre grandes corpus de texto usando arquitecturas como Word2Vec, GloVe o BERT. Algunos de los modelos preentrenados más usados hoy:

Proveedor	Modelo	Dimensiones
OpenAI	`text-embedding-3-small/large`	1536 / 3072
Google	`text-embedding-004`	hasta 768
Voyage AI	`voyage-large-2`	1536
Cohere	`embed-multilingual-v3.0`	1024
Open source (HF)	`sentence-transformers`	varía (ej. 768)

Cómo se mide la similitud

Una vez que dos textos son vectores, ¿cómo sabemos si son “parecidos”? La métrica más usada es la similitud coseno: el coseno del ángulo entre dos vectores. Cuanto más cercano a 1, más similares son; cercano a 0 implica que no están relacionados, y cercano a -1 indica significados opuestos.

Para nuestro pipeline usaremos un modelo open source de sentence-transformers vía LangChain, que genera embeddings de 768 dimensiones sin depender de una API externa:

from langchain_huggingface import HuggingFaceEmbeddings


def crear_modelo_embeddings() -> HuggingFaceEmbeddings:
 """
 Instancia el modelo de embeddings que convertirá cada chunk en un vector.
 """
 return HuggingFaceEmbeddings(model_name="sentence-transformers/all-mpnet-base-v2")

Info

También podrías usar modelos privados como los de OpenAI (OpenAIEmbeddings) o Voyage AI simplemente cambiando esta función; el resto del pipeline no cambia.

Dependencias añadidas: langchain-huggingface, sentence-transformers.

Almacenamiento en una base de datos vectorial

Ya tenemos vectores; ahora necesitamos guardarlos en algún lugar donde se puedan buscar por similitud de forma rápida. Ahí entran las bases de datos vectoriales, optimizadas para indexar y consultar vectores de alta dimensión.

Categoría	Ejemplos
Índices vectoriales	FAISS, ANNOY, ScaNN
Bases especializadas	Pinecone, Chroma, Qdrant, Milvus, Weaviate
Plataformas de búsqueda	Elasticsearch, OpenSearch
SQL con soporte vectorial	PostgreSQL (`pgvector`), Azure SQL
NoSQL con soporte vectorial	MongoDB

Para este ejemplo usaremos FAISS (Facebook AI Similarity Search): una librería ligera, local y suficiente para un prototipo o un proyecto pequeño.

from langchain_community.vectorstores import FAISS


def construir_base_vectorial(
 fragmentos: list[Document], modelo_embeddings: HuggingFaceEmbeddings
) -> FAISS:
 """
 Genera el embedding de cada chunk y los indexa en una base vectorial FAISS.
 """
 return FAISS.from_documents(fragmentos, modelo_embeddings)

Tip

FAISS se puede persistir en disco con base_vectorial.save_local(ruta) y recuperar después con FAISS.load_local(ruta, modelo_embeddings), sin necesidad de recalcular los embeddings cada vez que arranca la aplicación.

Al elegir una base de datos vectorial para producción, más allá de FAISS, vale la pena evaluar:

Factor	Qué implica
Precisión vs. velocidad	Índices más precisos suelen ser más lentos de consultar.
Local vs. cloud	Acceso rápido y control total vs. escalabilidad y redundancia administradas.
Costo	Autohospedado con costo de infraestructura vs. servicio administrado con costo por uso.

Pipeline completo

Con las cuatro etapas listas, así queda el script completo: descarga la página, la limpia, la fragmenta, genera los embeddings y los indexa en FAISS.

import asyncio
from typing import Final

from langchain_community.document_loaders import AsyncHtmlLoader
from langchain_community.document_loaders.async_html import default_header_template
from langchain_community.document_transformers import Html2TextTransformer
from langchain_community.vectorstores import FAISS
from langchain_core.documents import Document
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_text_splitters import RecursiveCharacterTextSplitter

URL_OBJETIVO: Final[str] = (
 "https://es.wikipedia.org/wiki/Copa_Mundial_de_F%C3%BAtbol_de_2026"
)
RUTA_INDICE: Final[str] = "indice_mundial_2026"


async def cargar_y_limpiar_documento(url: str = URL_OBJETIVO) -> str:
 """
 Descarga el contenido HTML de una URL de forma asíncrona
 y lo transforma a texto plano.
 """
 encabezados = dict(default_header_template)
 encabezados["User-Agent"] = "DacaDev/0.0 (mi_correo@gmail.com)"

 cargador_html = AsyncHtmlLoader(url, header_template=encabezados)
 documentos_html = cargador_html.load()

 transformador_html_a_texto = Html2TextTransformer()
 documentos_texto_plano = transformador_html_a_texto.transform_documents(
 documentos_html
 )
 return documentos_texto_plano[0].page_content


def dividir_texto_en_fragmentos(texto: str) -> list[Document]:
 """
 Divide un texto intentando mantener oraciones y párrafos completos.
 """
 separador_recursivo = RecursiveCharacterTextSplitter(
 separators=["\n\n", "\n", ".", " ", ""],
 chunk_size=1000,
 chunk_overlap=200,
 )
 return separador_recursivo.create_documents([texto])


def crear_modelo_embeddings() -> HuggingFaceEmbeddings:
 """
 Instancia el modelo de embeddings que convertirá cada chunk en un vector.
 """
 return HuggingFaceEmbeddings(model_name="sentence-transformers/all-mpnet-base-v2")


def construir_base_vectorial(
 fragmentos: list[Document], modelo_embeddings: HuggingFaceEmbeddings
) -> FAISS:
 """
 Genera el embedding de cada chunk y los indexa en una base vectorial FAISS.
 """
 return FAISS.from_documents(fragmentos, modelo_embeddings)


async def ejecutar_flujo_indexacion() -> None:
 """
 Flujo principal: carga, fragmenta, convierte a embeddings e indexa.
 """
 print("Iniciando la descarga y procesamiento del documento...")
 contenido_limpio = await cargar_y_limpiar_documento()

 fragmentos = dividir_texto_en_fragmentos(contenido_limpio)
 print(f"Se crearon {len(fragmentos)} fragmentos")

 modelo_embeddings = crear_modelo_embeddings()
 base_vectorial = construir_base_vectorial(fragmentos, modelo_embeddings)
 base_vectorial.save_local(RUTA_INDICE)
 print(f"Se indexaron {base_vectorial.index.ntotal} fragmentos en '{RUTA_INDICE}'")


if __name__ == "__main__":
 asyncio.run(ejecutar_flujo_indexacion())

Verificación rápida

Con la base vectorial ya construida, podemos comprobar que la indexación funcionó haciendo una búsqueda por similitud directamente sobre FAISS, sin pasar todavía por un LLM:

base_vectorial = FAISS.load_local(
 RUTA_INDICE, crear_modelo_embeddings(), allow_dangerous_deserialization=True
)

resultados = base_vectorial.similarity_search(
 "¿Qué equipos jugarán la semifinal de la Copa del Mundo 2026?"
)
print(resultados[0].page_content)

Si todo salió bien, el chunk más relevante debería contener información sobre las semifinales del torneo — justo lo que el LLM no podía responder en el primer artículo de la serie.

Conclusión y próximos pasos

Ya tenemos un indexing pipeline funcional de punta a punta: carga los datos, los fragmenta en chunks manejables, los convierte en embeddings y los almacena en una base vectorial lista para consultarse. Esa base es exactamente lo que el retriever necesita para hacer su trabajo.

En el siguiente artículo construiremos el retrieval pipeline: cómo el retriever consulta esta base vectorial, arma el contexto y lo combina con el prompt del usuario antes de llegar al LLM.

Arquitectura de un RAG: Indexing y Retrieval Pipeline

Dacadev — Tue, 14 Jul 2026 00:00:00 -0500

Tabla de Contenido

En el artículo anterior de esta serie se habló de qué es un RAG y cómo ayuda a proveer de conocimiento privado y actualizado a los LLMs. Ahora abordemos el tema de “cómo se estructura internamente un sistema RAG (Retrieval Augmented Generation)”.

Note

Este es el segundo artículo de la serie RAGs. Al terminar comprenderás la arquitectura de un RAG: el indexing pipeline que prepara el conocimiento, el retrieval pipeline que responde en tiempo real, y el componente de evaluación que garantiza la calidad en producción. 🚀

Los dos pipelines de un sistema RAG

Un sistema RAG se puede descomponer en dos pipelines complementarios: el indexing pipeline (pipeline de indexación) y el retrieval pipeline (pipeline de recuperación).

La distinción es fundamentalmente temporal. El indexing pipeline se ejecuta de forma offline o asíncrona, preparando la base de conocimiento. El retrieval pipeline se ejecuta en tiempo real y es el encargado de responder a cada petición del usuario consumiendo el conocimiento ya indexado.

El indexing pipeline

El indexing pipeline es el responsable de tomar los datos crudos, dividirlos en fragmentos procesables, convertirlos en vectores numéricos —los embeddings— y almacenarlos en una base de datos, típicamente una base de datos vectorial.

El flujo parte de la fuente de datos y encadena cuatro etapas de procesamiento hasta almacenar el conocimiento en la base de datos vectorial:

flowchart LR
 F["📄 Fuente de datos"] --> CA["📥 Carga"]
 CA --> FR["✂️ Fragmentación"]
 FR --> CO["🧮 Conversión"]
 CO --> AL[("🗄️ Almacenamiento")]

Cada nodo del diagrama se corresponde con una etapa lógica bien definida:

Fuente de datos: el origen de la información cruda —bases de datos, APIs, archivos o páginas web— que alimenta el sistema.
Carga: se conecta a las fuentes externas, extrae los documentos y parsea su contenido a texto plano.
Fragmentación: divide los documentos extensos en piezas más pequeñas y manejables, denominadas chunks.
Conversión: transforma cada chunk en un vector numérico —el embedding— que captura su significado semántico.
Almacenamiento: persiste los embeddings en una base de datos vectorial, lista para la fase de recuperación.

Info

El indexing pipeline no se ejecuta en cada consulta. Su activación depende de la volatilidad de la fuente de datos y suele responder a disparadores concretos: la carga de un documento nuevo, la actualización de un registro o una reindexación programada. Al ser un proceso offline, podemos permitirnos operaciones costosas sin afectar la latencia de respuesta al usuario.

Tanto la estrategia de chunking como la generación de embeddings son decisiones de diseño con un impacto directo en la calidad del sistema. Las abordaremos en profundidad más adelante en la serie.

El retrieval pipeline

El retrieval pipeline es el que opera en tiempo real. Su responsabilidad es analizar la petición del usuario, recuperar de la base de datos vectorial los fragmentos de información más relacionados con ella, inyectarlos en el prompt junto con la consulta original, enviar el resultado al LLM y devolver la respuesta.

flowchart LR
 U["👤 Usuario<br/>(prompt)"] --> R["🔎 Retriever"]
 R -->|"search query"| DB[("🗄️ Vector DB<br/>memoria no paramétrica")]
 DB -->|"fetch information"| R
 R -->|"prompt + contexto"| L["🧠 LLM<br/>memoria paramétrica"]
 L --> RESP["💬 Respuesta"]

Este flujo introduce una distinción conceptual relevante entre dos tipos de memoria:

Memoria paramétrica: el conocimiento codificado en los pesos del LLM durante su entrenamiento.
Memoria no paramétrica: el conocimiento externo almacenado en la base de datos vectorial, que el sistema consulta dinámicamente.

El retrieval pipeline es, en esencia, el mecanismo que combina ambas memorias para producir una respuesta fundamentada y este se organiza en tres fases secuenciales, cada una soportada por un componente:

flowchart LR
 A["🔎 Retrieval<br/>recupera contexto"] --> B["🧩 Augmentation<br/>construye el prompt"]
 B --> G["🧠 Generation<br/>genera la respuesta"]

Retrieval: el Retriever es el componente central del RAG. Busca en la base de conocimiento y recupera los fragmentos relevantes para la consulta.
Augmentation: la capa de gestión de prompts combina la información recuperada con la petición original para construir el prompt final.
Generation: el componente LLM genera la respuesta definitiva. Puede apoyarse en modelos fundacionales o afinados, de código abierto o cerrado.

Tip

La calidad de la respuesta está acotada por la fase de Retrieval. Si el Retriever recupera fragmentos irrelevantes, ninguna capacidad del LLM compensará ese contexto deficiente. Optimizar la recuperación suele rendir más que cambiar a un modelo más potente.

Arquitectura completa

Ambos pipelines no operan de forma aislada; convergen en la base de conocimiento. El indexing pipeline la construye y la mantiene actualizada, mientras que el retrieval pipeline la consulta para fundamentar cada respuesta.

Esta arquitectura desacoplada es lo que confiere al patrón RAG su principal ventaja operativa: actualizar el conocimiento del sistema no requiere reentrenar el modelo, sino únicamente ejecutar el indexing pipeline sobre los nuevos datos.

Evaluación

Hasta aquí hemos descrito los dos componentes estructurales del sistema. Sin embargo, en un entorno de producción es crucial incorporar un tercer componente: la evaluación, encargada de medir si las respuestas que entrega el sistema son correctas y relevantes.

Un punto de partida sólido es el RAG Triad propuesto por TruEra, un marco que evalúa la coherencia entre las tres piezas de una interacción: la consulta del usuario, el contexto recuperado y la respuesta generada.

El marco define tres validaciones, una por cada arista del triángulo:

Context relevance: ¿el contexto recuperado de la base de conocimiento es relevante para la consulta del usuario? Evalúa la calidad de la fase de Retrieval.
Groundedness: ¿la respuesta del LLM se apoya fielmente en el contexto recuperado, en lugar de alucinar? Evalúa que el modelo utilice la información proporcionada.
Answer relevance: ¿la respuesta final responde efectivamente a la consulta del usuario? Evalúa la utilidad del resultado.

Warning

Un sistema RAG sin evaluación es un sistema opaco. Sin medir context relevance, groundedness y answer relevance no podrás distinguir si un fallo proviene de una recuperación deficiente o de una generación defectuosa, lo que vuelve la depuración prácticamente imposible.

Conclusión y próximos pasos

La arquitectura de un RAG se sostiene sobre dos pipelines desacoplados —indexación offline y recuperación en tiempo real— que convergen en una base de conocimiento vectorial, más un componente transversal de evaluación que garantiza su fiabilidad en producción.

Con este mapa arquitectónico claro, las próximas entregas de la serie RAGs profundizarán en cada pieza:

Estrategias de chunking: cómo fragmentar los documentos sin perder contexto.
Embeddings: qué son, cómo se generan y cómo capturan el significado semántico.
Bases de datos vectoriales: indexación y búsqueda por similitud.
Métricas y herramientas para evaluar sistemas RAG de forma rigurosa.

En el siguiente artículo comenzaremos a construir el indexing pipeline, empezando por la fase de carga y fragmentación de datos.

RAG: Qué es y Cómo Funciona Retrieval Augmented Generation

Dacadev — Mon, 13 Jul 2026 00:00:00 -0500

Tabla de Contenido

Supongamos que debemos desplegar un asistente conversacional sobre la documentación interna de una organización: manuales técnicos, contratos y políticas que se actualizan cada semana. El modelo base responde con fluidez sobre conocimiento general, pero desconoce por completo esos documentos privados e inventa respuestas con total seguridad cuando se le pregunta por ellos. Aquí es donde RAG (Retrieval Augmented Generation) se convierte en la aproximación arquitectónica más rentable para dotar a un LLM de información precisa, privada y actualizada.

Note

Este es el primer artículo de la serie RAGs. Al terminar podrás explicar qué es un RAG, cómo funciona a alto nivel y por qué se ha vuelto una pieza central en el diseño de aplicaciones de IA generativa. 🚀

Las limitaciones estructurales de los LLMs

Antes de definir qué es un RAG, es crucial entender las limitaciones de los LLMs que esta técnica resuelve. Un modelo de lenguaje, por potente que sea, arrastra tres restricciones inherentes a la forma en que fue entrenado.

Alucinaciones

Las alucinaciones son uno de los problemas más severos de los LLMs. Consisten en que el modelo responde con información incorrecta o inventada, pero con un nivel de confianza que induce al usuario a asumirla como válida.

En aplicaciones comerciales esto representa un riesgo directo: si la información de entrada es incorrecta, todo el proceso que dependa de ella heredará el error. Consideremos un asistente en el dominio médico; una respuesta errónea sobre la dosificación de un medicamento puede tener consecuencias fatales. La confianza aparente del modelo no es un indicador de veracidad.

Conocimiento con fecha de corte

Los LLMs se entrenan con grandes volúmenes de datos públicos —libros, artículos, páginas web— hasta una fecha de corte determinada. Todo evento posterior a esa fecha queda fuera de su conocimiento.

Si un modelo fue entrenado con datos hasta 2025, no dispone de información sobre hechos ocurridos después. Ante una consulta de este tipo, el modelo o bien reconoce su desconocimiento, o bien alucina para completar la respuesta.

Ausencia de conocimiento privado

Al entrenarse sobre datos públicos, los LLMs no tienen acceso a datos privados: manuales internos, contratos, bases de conocimiento corporativas o historiales de clientes. Esta es una limitación esperada, pero decisiva.

La alternativa que uno creeria de adjuntar todos los documentos privados en cada conversación no es técnicamente viable, implica un consumo desmedido de tokens y latencia en cada llamada, además de chocar contra los límites de la ventana de contexto.

flowchart TD
 L[🧠 LLM entrenado con datos públicos]
 L --> A[❌ Alucinaciones<br/>respuestas inventadas]
 L --> B[❌ Fecha de corte<br/>sin datos recientes]
 L --> C[❌ Sin conocimiento privado<br/>manuales, contratos, datos internos]

Alternativas antes de llegar a RAG

RAG no es la única técnica para inyectar conocimiento en un LLM. Es importante situarla frente a otras dos aproximaciones habituales y comprender sus contrapartidas.

Agentes

Los agentes han ganado tracción gracias a las amplias ventanas de contexto actuales, que permiten al modelo procesar grandes cantidades de información para resolver tareas complejas de manera autonoma. Sin embargo, cuando el volumen documental es elevado, el agente debería leer toda la información en cada ejecución.

Incluso apoyándose en mecanismos de caché, el costo en tokens y tiempo escala de forma prohibitiva. Procesar íntegramente un manual extenso solo para resolver una consulta puntual es análogo a recorrer una biblioteca completa para responder una única pregunta: funciona, pero es ineficiente.

Fine-tuning

El fine-tuning consiste en reentrenar un LLM sobre datos específicos para ajustar sus pesos y especializarlo en un dominio. Esta técnica genera una nueva versión del modelo con el conocimiento incorporado directamente en sus parámetros.

El problema es su costo operativo: requiere tiempo, recursos y datos de entrenamiento cuidados. Además, cada vez que la información cambia, es necesario reentrenar. En un escenario donde los datos se actualizan cada semana, o cada día, el fine-tuning se vuelve inviable como estrategia principal.

Info

Estas alternativas no son deficientes; simplemente resuelven problemas distintos. Los agentes son idóneos para explorar código o ejecutar flujos de trabajo dinámicos, y el fine-tuning brilla cuando el conocimiento es estable y muy específico. RAG destaca precisamente donde estas fallan: conocimiento amplio, cambiante y verificable.

Qué es un RAG (Retrieval Augmented Generation)

Un RAG (Retrieval Augmented Generation) es una técnica que recupera información relevante desde una fuente de datos externa y la incorpora al contexto del LLM en tiempo de inferencia, de modo que el modelo pueda responder con información verídica y actualizada.

La idea central es desacoplar el conocimiento del modelo. En lugar de codificar los datos en los pesos, como hace el fine-tuning, o de arrastrar todo el corpus en cada llamada, como hace un agente, el RAG selecciona únicamente los fragmentos pertinentes para cada consulta y los añade al prompt.

Analicemos un caso concreto. Supongamos un modelo cuyo conocimiento llega hasta mayo de 2026 y le preguntamos por un evento posterior a esa fecha:

prompt: ¿Qué equipos jugarán la semifinal de la Copa del Mundo 2026?

LLM: Lo siento, no dispongo de información sobre los equipos que jugarán
 la semifinal de la Copa del Mundo 2026. Mi conocimiento está
 actualizado hasta mayo de 2026.

Ahora enriquezcamos ese mismo prompt con un bloque de contexto recuperado desde una fuente externa:

prompt: ¿Qué equipos jugarán la semifinal de la Copa del Mundo 2026?

----- contexto inyectado -----
Contexto: Los equipos que disputarán la semifinal de la Copa del Mundo 2026 son:
- Francia
- España
- Inglaterra
- Argentina
----- fin del contexto -----

LLM: Los equipos que jugarán la semifinal de la Copa del Mundo 2026 son
 Francia, España, Inglaterra y Argentina.

La diferencia está en el campo de contexto. Ese bloque, recuperado dinámicamente, es lo que permite al modelo responder con precisión sin haber sido entrenado con esa información. En esto consiste, en esencia, un RAG: obtener el conocimiento relevante desde una fuente de datos y aumentar con él el contexto del LLM.

Si pensamos esto en el caso de la documentación extensa, un RAG permite extraer las secciones pertinentes de un manual o contrato y añadirlas al prompt, de modo que el modelo pueda responder con información verídica y actualizada sin necesidad de reentrenar ni de procesar todo el documento en cada consulta. Es decir que solo cargamos una parte del documento y no todo su contenido.

Cómo funciona un RAG a alto nivel

Su nombre describe con exactitud las tres fases del proceso: Retrieval (recuperación), Augmented (aumento) y Generation (generación).

Retrieval (Recuperación): ante una consulta del usuario, el sistema busca en una base de conocimiento externa los fragmentos de información más relevantes. Esta búsqueda suele apoyarse en similitud semántica, un mecanismo que abordaremos en detalle más adelante en la serie.
Augmented (Aumento): los fragmentos recuperados se combinan con la consulta original para construir un prompt enriquecido. El modelo recibe así, junto a la pregunta, el contexto necesario para responderla.
Generation (Generación): el LLM genera la respuesta final apoyándose en el contexto inyectado, no solo en su conocimiento paramétrico.

Tip

La calidad de un RAG depende directamente de la fase de recuperación. Si los fragmentos recuperados son irrelevantes o incompletos, el modelo generará una respuesta pobre por muy capaz que sea. En RAG, la máxima “basura entra, basura sale” aplica con especial fuerza.

Ventajas de adoptar un RAG

Más allá de mitigar las limitaciones descritas, el patrón RAG ofrece beneficios concretos de ingeniería:

Eficiencia y costo: aporta conocimiento profundo y específico al modelo sin el costo de reentrenar ni de procesar el documento completo en cada llamada.
Información verificable: al recuperar fragmentos de fuentes reales, el modelo puede citar su origen, de modo que el usuario contraste la respuesta con la fuente original.
Actualización simple: mantener el sistema al día se reduce a actualizar la base de conocimiento, sin tocar el modelo.
Reducción de alucinaciones: al fundamentar la respuesta en datos recuperados, disminuye de forma significativa la probabilidad de que el modelo invente información.

Warning

Un RAG reduce las alucinaciones, pero no las elimina por completo. El modelo aún puede malinterpretar el contexto recuperado o combinarlo con su conocimiento paramétrico de forma incorrecta. El diseño del prompt y la evaluación rigurosa siguen siendo responsabilidad del ingeniero.

Patrones de Diseño: Factory

Dacadev — Tue, 07 Jul 2026 00:00:00 +0000

Tabla de Contenido

La instanciación directa de clases concretas es uno de los puntos más costosos de acoplamiento en un diseño orientado a objetos. Cada new o llamada explícita a un constructor ata al cliente a una implementación específica, dificultando la extensión y la sustitución de componentes. Los patrones factory encapsulan esa decisión en un lugar controlado, permitiendo evolucionar la creación de objetos sin propagar cambios a todo el código consumidor.

Note

🚀 Los patrones factory encapsulan la creación de objetos y desacoplan al cliente de las clases concretas que necesita instanciar.

Este artículo forma parte de la serie de patrones de diseño. Analizaremos tres variantes de fabricación (Simple Factory, Factory Method y Abstract Factory), su relación con el Principio de Inversión de Dependencias y los trade-offs que conviene considerar al elegir uno u otro.

Simple Factory

El Simple Factory no es un patrón de diseño formal del catálogo GoF, sino un idiom recurrente: encapsular la lógica de creación de objetos dentro de un método (usualmente estático) que decide qué instancia devolver en función de un parámetro. Es un buen punto de partida para entender los patrones que veremos a continuación.

Info

GoF significa “Gang of Four” (la “Banda de los Cuatro”): los cuatro autores del libro Design Patterns (1994) que catalogó los 23 patrones de diseño clásicos. Cuando decimos que un patrón “es GoF”, significa que aparece en ese catálogo original.

Supongamos una pizzería que produce distintos tipos de pizzas. Sin un factory, el cliente tendría que conocer todas las clases concretas y decidir cuál instanciar. Con un SimpleFactory esa decisión queda centralizada:

classDiagram
 class PizzaStore {
 -factory: SimplePizzaFactory
 +order_pizza(kind) Pizza
 }
 class SimplePizzaFactory {
 +create_pizza(kind) Pizza
 }
 class Pizza {
 <<abstract>>
 +prepare()
 +bake()
 +box()
 }
 class CheesePizza
 class VeggiePizza
 class PepperoniPizza

 PizzaStore --> SimplePizzaFactory : usa
 SimplePizzaFactory ..> Pizza : crea
 Pizza <|-- CheesePizza
 Pizza <|-- VeggiePizza
 Pizza <|-- PepperoniPizza

Implementación mínima en Python:

from abc import ABC, abstractmethod


class Pizza(ABC):
 @abstractmethod
 def prepare(self) -> None: ...

 def bake(self) -> None:
 print("Horneando la pizza")

 def box(self) -> None:
 print("Empacando la pizza")


class CheesePizza(Pizza):
 def prepare(self) -> None:
 print("Preparando pizza de queso")


class VeggiePizza(Pizza):
 def prepare(self) -> None:
 print("Preparando pizza vegetariana")


class SimplePizzaFactory:
 def create_pizza(self, kind: str) -> Pizza:
 if kind == "cheese":
 return CheesePizza()
 if kind == "veggie":
 return VeggiePizza()
 raise ValueError(f"Tipo de pizza no soportado: {kind}")


class PizzaStore:
 def __init__(self, factory: SimplePizzaFactory) -> None:
 self.factory = factory

 def order_pizza(self, kind: str) -> Pizza:
 pizza = self.factory.create_pizza(kind)
 pizza.prepare()
 pizza.bake()
 pizza.box()
 return pizza

El cliente (PizzaStore) ya no depende de las clases concretas; toda la lógica de selección vive en el factory. La limitación es evidente: si necesitamos que distintas sucursales produzcan variantes propias de cada pizza, el if/elif termina explotando. Ese es exactamente el problema que resuelve Factory Method.

Info

El Simple Factory es útil como técnica de refactor cuando queremos aislar una serie de condicionales de creación, pero no ofrece extensibilidad vía herencia.

Factory Method

Note

El Factory Method define una interfaz para crear un objeto, pero delega en las subclases la decisión de qué clase concreta instanciar.

En lugar de tener una única clase factory que decide con condicionales, el Factory Method define un método abstracto de creación en la superclase. Cada subclase implementa ese método y devuelve el producto concreto que corresponda. La instanciación se difiere a las subclases.

classDiagram
 class Creator {
 <<abstract>>
 +factory_method() Product
 +operation()
 }
 class ConcreteCreatorA {
 +factory_method() Product
 }
 class ConcreteCreatorB {
 +factory_method() Product
 }
 class Product {
 <<abstract>>
 }
 class ConcreteProductA
 class ConcreteProductB

 Creator <|-- ConcreteCreatorA
 Creator <|-- ConcreteCreatorB
 Product <|-- ConcreteProductA
 Product <|-- ConcreteProductB
 ConcreteCreatorA ..> ConcreteProductA : crea
 ConcreteCreatorB ..> ConcreteProductB : crea

Consideremos un ejemplo canónico: una jerarquía de animales donde cada subclase decide qué instancia producir. La superclase define el flujo (show_animal) que consume el producto creado por el factory_method:

from abc import ABC, abstractmethod


class Animal(ABC):
 @abstractmethod
 def make_sound(self) -> str: ...

 @abstractmethod
 def create_animal(self) -> "Animal": ...

 def show_animal(self) -> None:
 animal = self.create_animal()
 print(f"El animal dice: {animal.make_sound()}")


class Dog(Animal):
 def make_sound(self) -> str:
 return "Guau!"

 def create_animal(self) -> Animal:
 return Dog()


class Cat(Animal):
 def make_sound(self) -> str:
 return "Miau!"

 def create_animal(self) -> Animal:
 return Cat()


Dog().show_animal() # El animal dice: Guau!
Cat().show_animal() # El animal dice: Miau!

El punto clave es que Animal.show_animal es agnóstico a la clase concreta: opera sobre la abstracción Animal y delega la instanciación a create_animal. Añadir un nuevo animal implica una nueva subclase, no modificar código existente — cumpliendo el principio abierto/cerrado.

Tip

Factory Method depende de herencia: cada subclase implementa el método de creación. Es ideal cuando la variación entre productos está atada a la variación de la clase creadora.

Abstract Factory

Mientras Factory Method crea un producto, el Abstract Factory crea familias completas de productos relacionados sin acoplar al cliente a las clases concretas de cada familia.

Un caso clásico: una aplicación que renderiza componentes de UI para distintos sistemas operativos. Botones y checkboxes de Windows deben usarse juntos, igual que los de macOS; mezclarlos rompe la coherencia visual. El Abstract Factory garantiza que solo se combinen componentes de la misma familia.

classDiagram
 class GUIFactory {
 <<abstract>>
 +create_button() Button
 +create_checkbox() Checkbox
 }
 class WindowsFactory
 class MacFactory
 class Button {
 <<abstract>>
 +render()
 }
 class Checkbox {
 <<abstract>>
 +render()
 }
 class WindowsButton
 class WindowsCheckbox
 class MacButton
 class MacCheckbox

 GUIFactory <|-- WindowsFactory
 GUIFactory <|-- MacFactory
 Button <|-- WindowsButton
 Button <|-- MacButton
 Checkbox <|-- WindowsCheckbox
 Checkbox <|-- MacCheckbox
 WindowsFactory ..> WindowsButton : crea
 WindowsFactory ..> WindowsCheckbox : crea
 MacFactory ..> MacButton : crea
 MacFactory ..> MacCheckbox : crea

Implementación en Python:

from abc import ABC, abstractmethod


class Button(ABC):
 @abstractmethod
 def render(self) -> None: ...


class Checkbox(ABC):
 @abstractmethod
 def render(self) -> None: ...


class WindowsButton(Button):
 def render(self) -> None:
 print("Renderizando botón de Windows")


class WindowsCheckbox(Checkbox):
 def render(self) -> None:
 print("Renderizando checkbox de Windows")


class MacButton(Button):
 def render(self) -> None:
 print("Renderizando botón de macOS")


class MacCheckbox(Checkbox):
 def render(self) -> None:
 print("Renderizando checkbox de macOS")


class GUIFactory(ABC):
 @abstractmethod
 def create_button(self) -> Button: ...

 @abstractmethod
 def create_checkbox(self) -> Checkbox: ...


class WindowsFactory(GUIFactory):
 def create_button(self) -> Button:
 return WindowsButton()

 def create_checkbox(self) -> Checkbox:
 return WindowsCheckbox()


class MacFactory(GUIFactory):
 def create_button(self) -> Button:
 return MacButton()

 def create_checkbox(self) -> Checkbox:
 return MacCheckbox()


class Application:
 def __init__(self, factory: GUIFactory) -> None:
 self.factory = factory

 def create_ui(self) -> None:
 button = self.factory.create_button()
 checkbox = self.factory.create_checkbox()
 button.render()
 checkbox.render()


factory: GUIFactory = WindowsFactory() # o MacFactory()
Application(factory).create_ui()

Application depende exclusivamente de GUIFactory, Button y Checkbox — todas abstracciones. Cambiar de familia consiste en inyectar una factory distinta; el resto del código permanece intacto.

Factory Method vs Abstract Factory

Aunque comparten espíritu, no son intercambiables:

Factory Method usa herencia: la subclase decide qué producto crear implementando un método.
Abstract Factory usa composición: el cliente recibe una factory y llama a varios métodos de creación sobre ella, obteniendo una familia de productos coherentes.
Factory Method escala en la dimensión de “un producto que varía”; Abstract Factory escala en la dimensión de “múltiples productos que varían de forma correlacionada”.

Static Factory

El Static Factory es una variante ligera que expone métodos de clase estáticos para construir instancias, en lugar de exponer constructores públicos. Es común en librerías del ecosistema Java y en APIs de Python que ofrecen métodos como datetime.now() o Path.home().

class Connection:
 def __init__(self, dsn: str) -> None:
 self._dsn = dsn

 @classmethod
 def from_env(cls) -> "Connection":
 import os
 return cls(dsn=os.environ["DATABASE_URL"])

 @classmethod
 def in_memory(cls) -> "Connection":
 return cls(dsn="sqlite://:memory:")

Ventajas: los métodos estáticos pueden tener nombres semánticos (from_env, in_memory) que documentan la intención mucho mejor que un constructor sobrecargado. Limitación: no permite polimorfismo — no es reemplazable en tiempo de ejecución como sí lo son Factory Method o Abstract Factory.

Principio de Inversión de Dependencias

El Principio de Inversión de Dependencias (DIP, la “D” de SOLID) enuncia dos reglas:

Los módulos de alto nivel no deben depender de módulos de bajo nivel. Ambos deben depender de abstracciones.
Las abstracciones no deben depender de detalles. Los detalles deben depender de abstracciones.

Los patrones factory son una herramienta natural para aplicar DIP: al centralizar la creación en una abstracción, el módulo de alto nivel deja de instanciar clases concretas. Volviendo al ejemplo de la pizzería:

flowchart LR
 subgraph Antes["Sin DIP"]
 A1[PizzaStore] --> A2[CheesePizza]
 A1 --> A3[VeggiePizza]
 A1 --> A4[PepperoniPizza]
 end
 subgraph Despues["Con DIP + Factory"]
 B1[PizzaStore] --> B2[Pizza abstracta]
 B3[CheesePizza] --> B2
 B4[VeggiePizza] --> B2
 B5[PepperoniPizza] --> B2
 end

En “Antes”, el flujo de dependencia va de alto a bajo nivel: PizzaStore conoce todas las pizzas concretas. En “Después”, ambos dependen de la abstracción Pizza: la dependencia queda invertida.

Un ejemplo aislado en Python que muestra el patrón:

from abc import ABC, abstractmethod


class MessageSender(ABC):
 @abstractmethod
 def send(self, message: str) -> None: ...


class EmailSender(MessageSender):
 def send(self, message: str) -> None:
 print(f"Enviando email: {message}")


class SmsSender(MessageSender):
 def send(self, message: str) -> None:
 print(f"Enviando SMS: {message}")


class NotificationService:
 def __init__(self, sender: MessageSender) -> None:
 self._sender = sender

 def notify(self, message: str) -> None:
 self._sender.send(message)


NotificationService(EmailSender()).notify("Nuevo despliegue exitoso")

NotificationService no conoce EmailSender ni SmsSender; solo la abstracción MessageSender. Un factory puede alimentar esa dependencia según configuración, entorno o feature flags, sin tocar NotificationService.

Consideraciones

Todos los factories encapsulan la creación de objetos y reducen el acoplamiento a implementaciones concretas.
Simple Factory no es un patrón GoF; es un idiom útil para aislar condicionales de creación en un único lugar.
Factory Method depende de herencia: cada subclase implementa el método de creación y decide el producto concreto.
Abstract Factory depende de composición: el cliente recibe una factory y obtiene familias de productos coherentes.
Los tres refuerzan el Principio de Inversión de Dependencias al hacer que el código cliente dependa de abstracciones, no de tipos concretos.
El DIP es una guía transversal, no un patrón: aplica siempre que quieras evitar el acoplamiento con implementaciones específicas.
Factory es una técnica de diseño, no una clase específica. Su nombre puede variar (build, create, from_x), lo importante es la intención: encapsular la construcción de objetos.

Note

🚀 Elige Simple Factory para aislar condicionales, Factory Method cuando la variación está atada a la jerarquía del creador, y Abstract Factory cuando necesitas coherencia entre múltiples productos relacionados.

Continúa la serie

Si te interesa seguir explorando patrones de diseño, revisa los otros artículos de la serie:

TypeScript: Tipos avanzados, subtipos y varianza

Dacadev — Sun, 21 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Octavo artículo de la serie sobre TypeScript. Abordaremos la teoría que sustenta el sistema de tipos: subtipos, supertipos, la jerarquía completa, los tipos unknown y never, y la varianza.

Comprender la relación entre tipos es lo que separa a quien usa TypeScript de quien lo domina. El compilador decide qué asignaciones son válidas aplicando reglas de subtipado y varianza. Una vez interiorizadas estas reglas, los errores del typechecker dejan de ser obstáculos crípticos y se convierten en información precisa sobre el diseño de tus tipos.

Subtipos

La regla fundamental del subtipado se enuncia así:

Info

Si tienes un tipo A y un tipo B donde B es subtipo de A, entonces puedes usar B en cualquier lugar donde se espere un A.

Algunas relaciones de subtipo en TypeScript:

Array es subtipo de Object.
Tuple es subtipo de Array.
Todo es subtipo de any.
never es subtipo de todo.
Si una clase Bird extiende Animal, entonces Bird es subtipo de Animal.

Aplicado a la práctica, esto significa que donde se necesite un Object puedes usar un Array; donde se necesite un Array puedes usar una Tuple; y donde se necesite un Animal puedes usar un Bird.

Supertipos

Un supertipo es la relación inversa:

Info

Si tienes un tipo A y un tipo B donde B es supertipo de A, entonces puedes usar A en cualquier lugar donde se espere un B.

Las relaciones de supertipo reflejan en espejo a las anteriores:

Array es supertipo de Tuple.
Object es supertipo de Array.
any es supertipo de todo.
Animal es supertipo de Bird.

La jerarquía de tipos

Todas estas relaciones forman una jerarquía con un tipo en la cúspide (top type) y otro en el fondo (bottom type):

flowchart TD
 Unknown[unknown - top type] --> Any[any]
 Any --> Number
 Any --> BigInt
 Any --> Boolean
 Any --> String
 Any --> Symbol
 Any --> Object
 Any --> Void
 Any --> Null
 Any --> Undefined
 Object --> Array
 Array --> Tuple
 Object --> Function
 Number --> Never[never - bottom type]
 String --> Never
 Boolean --> Never
 Object --> Never
 Tuple --> Never

unknown es el top type: todo es asignable a él, pero no permite operar sin acotar primero.
never es el bottom type: es subtipo de cualquier otro tipo y representa lo que nunca ocurre.

Los tipos especiales: null, undefined, void y never

Estos cuatro tipos modelan la ausencia de valor con matices distintos:

Tipo	Significado
`null`	Ausencia explícita de valor
`undefined`	Variable que aún no recibió un valor
`void`	Función que no tiene sentencia `return`
`never`	Función que nunca retorna

La distinción entre void y never es sutil pero importante. Una función void termina sin devolver nada útil; una función never no termina en absoluto, ya sea porque lanza una excepción o porque entra en un bucle infinito:

// void: termina, no retorna valor
function log(msg: string): void {
 console.log(msg)
}

// never: nunca completa su ejecución
function fail(message: string): never {
 throw new Error(message)
}

function loopForever(): never {
 while (true) {}
}

Tip

never es especialmente útil en la verificación de exhaustividad: si un switch cubre todos los casos de una unión, la rama default puede asignar el valor a un never, y el compilador detectará en tiempo de compilación cualquier caso olvidado al ampliar la unión.

Varianza

Determinar si un tipo es sub o supertipo de otro no siempre es evidente, sobre todo al combinar estructuras y funciones. TypeScript dispone de una notación formal para razonar sobre estas relaciones:

A <: B significa “A es subtipo de, o el mismo tipo que, B”.
A >: B significa “A es supertipo de, o el mismo tipo que, B”.

La varianza describe cómo se propagan estas relaciones cuando los tipos se anidan en estructuras (arreglos, objetos) o en firmas de función. Es el motivo por el que, por ejemplo, un arreglo de un subtipo no siempre es intercambiable con un arreglo de su supertipo: la mutabilidad introduce restricciones que el compilador debe respetar para mantener la solidez del sistema.

Conclusión

El sistema de tipos de TypeScript es una jerarquía gobernada por reglas de subtipado y varianza, con unknown como tipo superior y never como tipo inferior. Distinguir null, undefined, void y never, y comprender cómo B <: A permite sustituir un tipo por otro, te da una intuición precisa de por qué el compilador acepta o rechaza una asignación.

En el siguiente artículo aplicaremos metaprogramación con decoradores, funciones que extienden el comportamiento de clases, métodos y propiedades.

TypeScript: Tipos básicos y el sistema de tipos

Dacadev — Mon, 15 Jun 2026 00:00:00 -0500

Tabla de Contenido

Note

Segundo artículo de la serie sobre TypeScript. Recorreremos el alfabeto de tipos del lenguaje: desde any y unknown hasta uniones, intersecciones, tuplas y alias de tipo.

Cuando el typechecker sabe que un valor es de tipo T, no solo conoce su naturaleza: también sabe exactamente qué operaciones son válidas sobre ese valor y cuáles no. Ese es el propósito del sistema de tipos. Comprender el catálogo de tipos básicos en TypeScript es la base sobre la que se construye todo lo demás, así que dediquémosle la atención que merece.

Por qué importan los tipos: un ejemplo concreto

Los tipos transmiten intención de forma explícita y verificable. Comparemos la misma función en JavaScript y en TypeScript:

// JavaScript
function squareOf(n) {
 return n * n
}
squareOf(2) // 4
squareOf('z') // NaN — falla en silencio

// TypeScript
function squareOf(n: number) {
 return n * n
}
squareOf(2) // 4
squareOf('z') // Error TS2345: el argumento de tipo 'string' no es
 // asignable al parámetro de tipo 'number'.

En JavaScript, squareOf('z') devuelve NaN sin protestar y el error se propaga aguas abajo. En TypeScript el compilador lo intercepta en el sitio exacto donde se cometió.

any: la puerta de escape del sistema de tipos

any indica que una variable puede contener cualquier tipo de dato. Desactiva por completo la verificación:

let avenger: any = 123;
avenger = 'Dr. Strange';
console.log((avenger as string).charAt(0));

avenger = 15.23425;
console.log((<number>avenger).toFixed(2));

Cuando usas any, el typechecker deja de ayudarte. Puedes reorientarlo mediante un cast —indicar manualmente qué tipo debe asumir en un punto dado— con la sintaxis (variable as Tipo) o <Tipo>variable.

Warning

Evita any salvo en migraciones puntuales o fronteras con código sin tipado. Cada any es un agujero por el que se filtran errores que el compilador debería haber detenido.

unknown: la alternativa segura a any

unknown es el primo responsable de any. Acepta cualquier valor, pero TypeScript prohíbe operar sobre él hasta que acotes su tipo mediante una comprobación. Esto añade una capa de seguridad: sí admite operaciones de comparación e identidad (==, ===, ||, &&, el operador ternario ?) y negación con !, pero no el acceso a propiedades arbitrarias.

let dato: unknown = obtenerValor();

// dato.toFixed(2) // Error: 'dato' es de tipo 'unknown'
if (typeof dato === 'number') {
 dato.toFixed(2) // OK: dentro del guard, dato es number
}

Usa unknown siempre que recibas datos externos (respuestas de API, entrada del usuario) en lugar de any.

boolean

Acepta las operaciones ==, ===, ||, &&, el ternario ? y la negación !:

let a = true // boolean
const c = true // true (tipo literal)
let d: boolean = true // boolean
let e: true = true // true
let f: true = false // Error TS2322: 'false' no es asignable a 'true'.

Info

El tipo true (literal) es más restrictivo que boolean: además de exigir un booleano, exige que su valor sea exactamente true. Los tipos literales son una herramienta poderosa para modelar estados precisos.

number y bigint

number cubre enteros, flotantes, Infinity, NaN y valores positivos y negativos:

let a = 1234 // number
const c = 5678 // 5678 (literal)
let e: number = 100 // number
let f: 26.218 = 26.218 // 26.218 (literal)
let g: 26.218 = 10 // Error TS2322

Un number representa con precisión hasta 2^53. Para enteros mayores existe bigint:

let a = 1234n // bigint
const b = 5678n // 5678n
let e = 88.5n // Error TS1353: un literal bigint debe ser entero.
let h: bigint = 100 // Error TS2322: '100' no es asignable a 'bigint'.

string

let a = 'hello' // string
const c = '!' // '!' (literal)
let e: string = 'zoom' // string
let f: 'john' = 'john' // 'john' (literal)
let g: 'john' = 'zoe' // Error TS2322

symbol

Un symbol representa un identificador único. Se crea con Symbol() y admite una descripción opcional útil para depurar:

let id = Symbol("id"); // symbol con descripción "id"

La garantía clave: dos símbolos nunca son iguales, aunque compartan descripción. La descripción es solo una etiqueta sin efecto sobre la identidad.

let id1 = Symbol("id");
let id2 = Symbol("id");
console.log(id1 === id2); // false

let d = id1 + 'x' // Error TS2469: el operador '+' no aplica a 'symbol'.

Objetos

Hay dos formas de tipar objetos. La primera usa la palabra clave object, que solo garantiza que el valor no es null pero no expone sus propiedades, porque TypeScript no sabe qué objeto es:

let a: object = { b: 'x' }
// a.b // Error: la propiedad 'b' no existe en el tipo 'object'

La segunda —y recomendada— describe la forma exacta del objeto:

let c: {
 firstName: string
 lastName: string
} = {
 firstName: 'john',
 lastName: 'barrowman'
}

Las definiciones de objeto admiten campos opcionales (?), índices dinámicos y propiedades de solo lectura:

let a: {
 b: number // obligatorio, number
 c?: string // opcional, string
 [key: number]: boolean // cualquier clave numérica → boolean
}

let user: {
 readonly firstName: string
} = { firstName: 'abby' }

user.firstName = 'abbey' // Error TS2540: propiedad de solo lectura.

Tip

Evita tipar con el objeto vacío {}. Acepta cualquier valor distinto de null o undefined (incluso números o arreglos), lo que vacía de sentido la anotación.

Alias de tipo

Los alias asignan un nombre semántico a un tipo, mejorando la legibilidad sin alterar la verificación:

type Age = number

type Person = {
 name: string
 age: Age
}

let driver: Person = {
 name: 'James May',
 age: 55
}

Como Age es solo un alias de number, sigue siendo compatible con cualquier number. Ten presente que un alias solo puede declararse una vez por ámbito; aplica las mismas reglas de shadowing que let, const y var.

Tipos unión e intersección

Recurriendo a la teoría de conjuntos: la unión (|) admite uno u otro tipo —o ambos—, mientras que la intersección (&) exige cumplir simultáneamente todas las formas combinadas.

flowchart LR
 subgraph Union["A | B"]
 U[Cualquier valor que sea A, B o ambos]
 end
 subgraph Inter["A & B"]
 I[Solo valores que cumplen A y B a la vez]
 end

type Cat = { name: string, purrs: boolean }
type Dog = { name: string, barks: boolean, wags: boolean }

type CatOrDogOrBoth = Cat | Dog // unión
type CatAndDog = Cat & Dog // intersección

Un valor Cat | Dog puede ser un gato, un perro o un objeto que cumpla ambas formas. Un valor Cat & Dog, en cambio, está obligado a tener name, purrs, barks y wags al mismo tiempo.

Arreglos

let a = [1, 2, 3] // number[]
let d = [1, 'a'] // (string | number)[]
let h: number[] = []
h.push(1) // OK
h.push('red') // Error TS2345

Un arreglo declarado vacío sin anotación arranca como any[] y va ampliando su tipo según lo que insertes —otra razón para anotar explícitamente las colecciones en las fronteras del sistema.

Tuplas

Las tuplas son un subconjunto de los arreglos con longitud fija y tipos posicionales:

let a: [number] = [1]

// [nombre, apellido, año de nacimiento]
let b: [string, string, number] = ['malcolm', 'gladwell', 1963]

b = ['queen', 'elizabeth', 'ii', 1926] // Error TS2322: posición/longitud inválida

También admiten posiciones opcionales:

// Tarifas de tren que a veces varían según la dirección
let trainFares: [number, number?][] = [
 [3.75],
 [8.25, 7.70],
 [10.50]
]

Conclusión

El sistema de tipos de TypeScript va mucho más allá de etiquetar variables: distingue entre any (inseguro) y unknown (seguro), modela estados exactos con tipos literales, compone formas mediante uniones e intersecciones y garantiza estructuras rígidas con tuplas. Dominar este catálogo es el prerrequisito para los temas avanzados de la serie.

En el siguiente artículo aplicaremos estos fundamentos a los objetos y tipos personalizados, donde los alias de tipo se vuelven el centro del diseño.

Estilos CSS: Selectores, combinadores y pseudo-clases

Dacadev — Thu, 04 Jun 2026 00:00:00 -0500

Tabla de Contenido

Un selector es el mecanismo con el que CSS apunta a los elementos que vas a estilizar. Elegir el selector correcto no es solo cuestión de que “funcione”: impacta directamente en la especificidad, en el acoplamiento de tus estilos y en la facilidad para mantenerlos. CSS ofrece un catálogo amplio de selectores, y conocerlos a fondo te evita escribir reglas frágiles.

Este artículo es la segunda entrega de la serie Estilos CSS. Recorreremos los selectores básicos, los combinadores, las pseudo-clases, los pseudo-elementos y los selectores de atributo, con ejemplos que puedes ver renderizados aquí mismo.

Note

Repasaremos cada familia de selectores con su especificidad y demostraciones en vivo, para que puedas elegir siempre la opción más precisa y de menor acoplamiento.

Selectores básicos

Son los cuatro selectores fundamentales sobre los que se construye todo lo demás:

Selector de tipo (p, h1) — apunta por nombre de etiqueta. Especificidad 0,0,1.
Selector de clase (.media) — apunta a los elementos con esa clase. Especificidad 0,1,0.
Selector de ID (#sidebar) — apunta al elemento con ese id. Especificidad 1,0,0.
Selector universal (*) — apunta a todos los elementos. Especificidad 0,0,0.

Combinadores

Los combinadores unen selectores simples para describir una relación entre elementos.

Combinador	Símbolo	Significado	Ejemplo
Descendiente	(espacio)	Cualquier descendiente	`.menu li`
Hijo directo	`>`	Hijo inmediato	`.lista > li`
Hermano adyacente	`+`	El elemento inmediatamente siguiente	`p + h2`
Hermano general	`~`	Todos los hermanos posteriores	`li.activo ~ li`

El combinador de hijo directo (>) solo afecta al primer nivel de descendientes. Observa la diferencia con el descendiente:

.lista > li { font-weight: bold; } /* solo hijos directos */

<ul class="lista">
 <li>Hijo directo (en negrita)</li>
 <li>Hijo directo (en negrita)
 <ul>
 <li>Nieto (sin negrita)</li>
 </ul>
 </li>
</ul>

Hijo directo (en negrita)
Hijo directo (en negrita)
- Nieto (sin negrita)

Selectores compuestos

Varios selectores simples se pueden unir sin espacios para formar un selector compuesto que exige que el elemento cumpla todas las condiciones. Por ejemplo, .dropdown.is-active apunta a <div class="dropdown is-active"> pero no a <div class="dropdown">.

Pseudo-clases

Las pseudo-clases apuntan a elementos según un estado: interacción del usuario o posición respecto a sus hermanos. Empiezan con un solo dos puntos (:) y tienen la especificidad de una clase (0,1,0).

Posición estructural

:first-child, :last-child, :only-child — primero, último o único hijo.
:nth-child(an + b) — apunta según una fórmula posicional entre sus hermanos.
:nth-last-child() — igual, pero contando desde el final.
:first-of-type, :last-of-type, :nth-of-type() — equivalentes, pero solo cuentan elementos del mismo tipo.
:not(<selector>) — apunta a lo que no coincide con el selector interno.
:empty — elementos sin hijos.

Un patrón clásico: aplicar un fondo alterno con :nth-child(even) para crear filas tipo “cebra”.

.zebra li:nth-child(even) { background: #ecf0f1; }

Fila 1
Fila 2 (resaltada)
Fila 3
Fila 4 (resaltada)

Estado e interacción

:hover — mientras el cursor está sobre el elemento.
:focus — cuando el elemento recibe foco (clic, toque o tabulación).
:root — el elemento raíz del documento.

Campos de formulario

Varias pseudo-clases describen el estado de los controles: :disabled, :enabled, :checked, :invalid, :valid, :required, :optional. Aquí, :invalid cambia el borde cuando el valor no es un correo válido:

input:invalid { border-color: #c0392b; }
input:valid { border-color: #27ae60; }

Escribe un correo:

Tip

La lista de pseudo-clases es extensa y evoluciona con cada nivel de la especificación. Consulta la documentación de MDN sobre pseudo-clases para el catálogo completo y el soporte por navegador.

Pseudo-elementos

Los pseudo-elementos no apuntan a un elemento existente, sino a una parte del documento que no tiene marcado propio, o inyectan contenido nuevo. Usan doble dos puntos (::) y tienen la especificidad de un selector de tipo (0,0,1).

::before — inserta un primer hijo virtual. Requiere la propiedad content.
::after — inserta un último hijo virtual. Requiere content.
::first-letter — estiliza la primera letra del texto.
::first-line — estiliza la primera línea.
::selection — estiliza el texto que el usuario resalta.

.nota::before { content: "★ "; color: #f39c12; }
.capitular::first-letter { font-size: 2.5em; font-weight: bold; color: #2a9da9; }

★ Texto precedido por un pseudo-elemento ::before.

Lorem ipsum con la primera letra estilizada como capitular.

Selectores de atributo

Apuntan a elementos según sus atributos HTML. Tienen la especificidad de una clase (0,1,0).

Selector	Coincide cuando el atributo…	Ejemplo
`[attr]`	existe	`input[disabled]`
`[attr="valor"]`	es exactamente igual	`input[type="radio"]`
`[attr^="valor"]`	empieza con el valor	`a[href^="https"]`
`[attr$="valor"]`	termina con el valor	`a[href$=".pdf"]`
`[attr*="valor"]`	contiene el valor	`[class*="sprite-"]`
`[attr~="valor"]`	es una lista separada por espacios que incluye el valor	`a[rel~="author"]`
`[attr\|="valor"]`	es igual o empieza con `valor-`	`[lang\|="es"]`

Por ejemplo, podemos marcar visualmente los enlaces externos y los que apuntan a un PDF:

a[href^="https"]::after { content: " ↗"; }
a[href$=".pdf"]::after { content: " (PDF)"; color: #c0392b; }

Enlace externo ↗ · Documento (PDF)

Info

Los selectores de atributo distinguen mayúsculas y minúsculas por defecto. La especificación nivel 4 añade un modificador i antes del corchete de cierre —input[value="search" i]— para hacerlos insensibles a mayúsculas. Verifica el soporte antes de usarlo en producción.

Conclusión

El catálogo de selectores de CSS es amplio y cada familia resuelve un problema distinto. La clave está en elegir el selector más preciso con la menor especificidad posible: eso mantiene tus estilos desacoplados y fáciles de sobrescribir cuando lo necesites.

Note

🚀 En la siguiente entrega abordamos el modelo de caja: cómo margin, border, padding y content definen el tamaño real de cada elemento y cómo box-sizing cambia las reglas del juego.

Estilos CSS: Cascada, especificidad, herencia y unidades

Dacadev — Tue, 02 Jun 2026 00:00:00 -0500

Tabla de Contenido

Cuando dos reglas de estilo compiten por el mismo elemento, el resultado no es aleatorio: el navegador aplica un algoritmo determinista para decidir cuál gana. Comprender ese algoritmo —la cascada, la especificidad y la herencia— es la diferencia entre pelear contra CSS a punta de !important y escribir hojas de estilo predecibles y mantenibles.

Este artículo abre la serie Estilos CSS. Analizaremos cómo el navegador resuelve conflictos, cómo se calcula el peso de un selector y cómo aprovechar las unidades relativas para construir interfaces que escalan.

Note

Al terminar entenderás el modelo mental que rige toda hoja de estilos: origen de los estilos, especificidad, orden del código, herencia y el sistema de unidades relativas (em, rem, vw) junto con las variables CSS.

La cascada: cómo el navegador resuelve conflictos

CSS significa Cascading Style Sheets. La cascada es precisamente el conjunto de reglas que determina qué declaración prevalece cuando varias apuntan a la misma propiedad de un elemento. El navegador evalúa tres criterios en orden:

Origen de la hoja de estilos — de dónde provienen los estilos.
Especificidad del selector — qué selector es más “específico”.
Orden en el código — cuál se declaró de último.

Origen de los estilos

Existen tres orígenes posibles, con prioridad creciente:

User agent styles — los estilos por defecto del navegador (por ejemplo, el margin de un <h1> o el subrayado de un enlace).
Author styles — los estilos que tú defines en tus archivos .css.
User styles — estilos configurados por el propio usuario en el navegador (accesibilidad, tamaños de fuente). Tienen prioridad sobre los anteriores.

Tus estilos (author) pisan a los del navegador, que es justo lo que esperas al escribir una hoja de estilos.

Especificidad: el peso de un selector

La especificidad se representa con la notación 0,0,0,0, donde cada posición cuenta, de izquierda a derecha: estilos inline, IDs, clases y nombres de etiqueta.

Componente	Ejemplo	Peso
Selector de etiqueta	`p`, `h1`	`0,0,0,1`
Selector de clase	`.nav-menu`	`0,0,1,0`
Selector de ID	`#sidebar`	`0,1,0,0`
Estilo inline	`style="..."`	`1,0,0,0`

Las reglas de desempate son sencillas:

Una declaración con !important gana por encima de todo (úsala con prudencia).
Gana el selector con más IDs.
Si hay empate, gana el que tenga más clases.
Si persiste el empate, gana el que tenga más etiquetas.

Tip

Las pseudo-clases (:hover) y los selectores de atributo ([type="text"]) cuentan como una clase (0,0,1,0). El selector universal * y los combinadores (>, +, ~) no aportan especificidad.

Observa cómo dos reglas compiten por el color del párrafo. La clase .destacado gana al selector de etiqueta p, aunque la regla de p se declare después:

p { color: #555; }
.destacado { color: #c0392b; }

<p>Texto con el color por defecto del selector de etiqueta.</p>
<p class="destacado">Este párrafo gana por especificidad de clase.</p>

Texto con el color por defecto del selector de etiqueta.

Este párrafo gana por especificidad de clase.

Orden del código: el último en hablar gana

Cuando dos declaraciones tienen el mismo origen y la misma especificidad, el navegador aplica la que aparece de última en el código fuente. Este comportamiento es crítico al ordenar las pseudo-clases de un enlace.

a:link { color: #2a7ae2; }
a:visited { color: #8e44ad; }
a:hover { text-decoration: underline; }
a:active { color: #c0392b; }

Como las cuatro pseudo-clases tienen la misma especificidad, su orden importa. La regla mnemotécnica es LoVe/HAte — link, visited, hover, active. Si inviertes :hover y :link, el :hover nunca se aplicaría.

Pasa el cursor sobre este enlace para ver el efecto del orden del código.

Herencia: propiedades que viajan hacia abajo

La herencia permite que ciertas propiedades de un elemento padre se transmitan a sus hijos. No todas las propiedades heredan: lo hacen principalmente las relacionadas con texto (color, font-family, line-height, text-align), mientras que las de caja (margin, padding, border) no.

.tarjeta { color: #1a5276; font-family: Georgia, serif; }

<div class="tarjeta">
 <h4>Título heredado</h4>
 <p>Este párrafo hereda <em>color</em> y <em>font-family</em> del contenedor.</p>
</div>

Título heredado

Este párrafo hereda color y font-family del contenedor.

Valores especiales: `inherit` e `initial`

Dos palabras clave te dan control explícito sobre la herencia:

inherit — fuerza a una propiedad a tomar el valor del padre, incluso en propiedades que normalmente no heredan.
initial — restablece la propiedad a su valor inicial según la especificación, ignorando la herencia.

Unidades absolutas vs. relativas

El píxel (px) es la unidad absoluta más común. Existen otras (pt, cm, in) con equivalencias fijas: 1in = 96px = 72pt. Sin embargo, las unidades relativas son las que permiten construir interfaces que escalan con el contexto.

`em`: relativo al elemento

Un em equivale al font-size del propio elemento. Es ideal para padding, margin y border-radius, porque estos escalan junto con el tamaño de fuente.

.caja { padding: 1em; border-radius: 1em; background: #ecf0f1; }
.caja--pequena { font-size: 12px; }
.caja--grande { font-size: 20px; }

padding 1em · 12px padding 1em · 20px

El padding de ambas cajas es 1em, pero al cambiar el font-size el espaciado escala proporcionalmente sin tocar la propiedad padding.

Info

Para convertir un tamaño en píxeles a em, divide el tamaño deseado entre el tamaño heredado: si quieres 16px y el padre tiene 12px, entonces 16 / 12 = 1.333em.

`rem`: relativo a la raíz

rem (root em) siempre toma como referencia el font-size del elemento raíz (<html> o :root). Esto te da un punto de control global: cambiar el tamaño de la raíz redimensiona todo el documento de forma coherente.

:root { font-size: 0.875em; }

@media (min-width: 800px) { :root { font-size: 1em; } }
@media (min-width: 1200px) { :root { font-size: 1.125em; } }

Una práctica habitual: usar rem para tipografía, px para bordes y em para padding, margin y border-radius.

Unidades relativas al viewport

vw — 1% del ancho del viewport.
vh — 1% del alto del viewport.
vmin — 1% de la dimensión más pequeña entre ancho y alto.
vmax — 1% de la dimensión más grande.

`calc()` para combinar unidades

calc() permite operar entre unidades de distinta naturaleza, algo imposible de otra forma. Es muy útil para tipografía fluida:

:root { font-size: calc(0.5em + 1vw); }

Números sin unidad y `line-height`

Si declaras un número sin unidad en line-height, este actúa como un factor multiplicador del font-size del elemento. Es la forma recomendada, porque cada descendiente calcula su propia altura de línea a partir de su tamaño de fuente.

body { line-height: 1.5; }

Custom properties (variables CSS)

Las variables CSS se declaran con el prefijo -- y se consumen con la función var(). A diferencia de las variables de un preprocesador, son dinámicas: viven en el DOM y respetan la cascada y la herencia.

:root {
 --color-marca: #2a9da9;
 --color-texto: #1c2833;
}

.panel {
 color: var(--color-texto);
 border-left: 4px solid var(--color-marca);
}

var() acepta un segundo argumento como valor de respaldo: var(--color-secundario, #888) usará #888 si la variable no está definida.

Redefinir variables por contexto

Como las variables respetan la cascada, puedes sobrescribirlas dentro de un bloque para crear temas locales. Aquí el mismo componente .panel se reconfigura dentro de .tema-oscuro cambiando solo las variables:

:root { --fondo: #fff; --texto: #111; }
.tema-oscuro { --fondo: #2c3e50; --texto: #ecf0f1; }

.panel {
 background: var(--fondo);
 color: var(--texto);
 padding: 1em;
 border-radius: .5em;
}

Panel claro

Usa las variables por defecto de :root.

Panel oscuro

Las mismas reglas, con las variables redefinidas.

El componente no cambió ni una línea: solo redefinimos las variables en un contenedor superior. Ese es el poder de combinar herencia y custom properties.

Conclusión

La cascada, la especificidad y la herencia forman el núcleo conceptual de CSS. Dominarlos te permite predecir qué regla gana sin recurrir a parches. Sumado a un buen uso de unidades relativas y variables, tienes la base para escribir estilos escalables y mantenibles.

Note

🚀 Próximo en la serie: los selectores de CSS, la herramienta con la que apuntamos con precisión a los elementos que queremos estilizar.

Agentes Especializados: Colaboración Multi-Agente y Nuevas Fronteras

Dacadev — Thu, 21 May 2026 00:00:00 -0500

Tabla de Contenido

Cuando un solo agente de Inteligencia Artificial intenta hacerlo todo —desde buscar en internet y escribir código hasta redactar correos o gestionar la base de datos—, suele toparse con un cuello de botella. Al igual que en un equipo de desarrollo de software no le pedirías a un diseñador UX que configure el cluster de Kubernetes, en la Inteligencia Artificial el futuro pertenece a los Agentes Especializados.

¿Cómo logramos que múltiples agentes colaboren entre sí de forma armoniosa?
¿Qué nuevas capacidades traen los agentes multimodales y de programación?
¿Y cómo resolvemos el gran problema del costo y consumo de tokens de estos sistemas?

Note

En este artículo profundizaremos enlos agentes especializados. Exploraremos la arquitectura de colaboración Multi-Agente, descubriremos el potencial de los Agentes Multimodales y Coding Agents, y analizaremos las estrategias para construir Tiny Agents sumamente eficientes. 🚀

El Universo de los Agentes Especializados

A medida que las necesidades de automatización se vuelven más complejas, los desarrolladores de IA hemos aprendido a fragmentar los problemas en lugar de crear un único agente monolítico. Esto nos lleva a cuatro categorías principales de especialización:

flowchart LR
 %% Categorías de Agentes Especializados
 Root[🧬 Agentes Especializados]

 Root --> MAC[🤝 Colaboración Multi-Agente]
 Root --> MM[👁️ Agentes Multimodales]
 Root --> CA[💻 Coding Agents]
 Root --> TA["⚡ Tiny Agents (Eficiencia)"]

 MAC --> MAC_Desc["Agentes que dividen tareas y colaboran entre sí"]
 MM --> MM_Desc["Comprenden y generan texto, audio, imagen y video"]
 CA --> CA_Desc["Escriben, ejecutan y auto-depuran código"]
 TA --> TA_Desc["Modelos compactos optimizados para bajo costo e inferencia rápida"]

Colaboración Multi-Agente: Agente Único vs. Multi-Agente

En un sistema de Agente Único (Single Agent), un solo LLM generalista se encarga de procesar la consulta, gestionar la memoria, seleccionar las herramientas y generar el plan final. Aunque es un diseño sencillo y efectivo para tareas contenidas, genera una enorme presión sobre la ventana de contexto del modelo y aumenta drásticamente el riesgo de alucinaciones a medida que sumamos más herramientas al arsenal.

Por el contrario, un Sistema Multi-Agente (Multi-Agent System) divide las responsabilidades entre varios agentes especializados que interactúan entre sí. Cada agente cuenta con un rol definido, una memoria local ajustada a su función y un conjunto limitado de herramientas específicas. Esto reduce el ruido, optimiza el tamaño de los prompts y permite estructurar flujos de trabajo altamente modulares.

Comparemos estas dos aproximaciones de manera visual:

flowchart TD
 subgraph Multi["Sistema Multi-Agente (Multi-Agent)"]
 direction TB
 Q2[👤 Consulta] --> Supervisor[👑 Agente Supervisor]
 Supervisor <--> AgentA[💻 Agente de Código]
 Supervisor <--> AgentB[💬 Agente de Mensajería]
 Supervisor <--> AgentC[🔍 Agente de Búsqueda]
 AgentA & AgentB & AgentC --> Ans2[🎯 Respuesta]
 end

 subgraph Single["Un Solo Agente (Single Agent)"]
 direction TB
 Q1[👤 Consulta] --> SA[🧠 Agente Generalista]
 subgraph SABrain["Cerebro Complejo"]
 direction LR
 LLM1[Reasoning LLM] --- Mem1[(Memoria)]
 LLM1 --- Tools1[🔧 Herramientas]
 LLM1 --- Plan1[📋 Planificación]
 end
 SA --> Ans1[🎯 Respuesta]
 end

La Arquitectura del Agente Supervisor (Supervisor Agent)

Uno de los patrones de diseño más exitosos en sistemas multi-agente es el de Agente Supervisor (Supervisor Agent). En este patrón, el supervisor actúa como el “director de orquesta” o el gestor principal del equipo de desarrollo.

El Supervisor recibe la consulta compleja del usuario.
Analiza qué sub-tareas se necesitan resolver para cumplir la meta y descompone el problema general.
Asigna cada sub-tarea al agente especialista correspondiente (el Agente de Código, de Búsqueda o de Mensajería), tratándolos prácticamente como si fueran “herramientas avanzadas”.
Los agentes especialistas procesan las sub-tareas utilizando sus herramientas específicas y devuelven el resultado al supervisor.
El supervisor consolida las respuestas parciales y, si es necesario, replanifica el flujo antes de entregar la respuesta definitiva al usuario.

En este modelo, el Agente Supervisor suele estar respaldado por el LLM más potente debido a la complejidad que requiere la planificación y asignación de tareas, mientras que los especialistas pueden funcionar perfectamente con modelos más rápidos y económicos.

Observemos esta sofisticada estructura jerárquica en acción:

flowchart LR
 Query[👤 Consulta / Query] --> Sup[👑 Agente Supervisor]

 subgraph SupTools["Agentes como Herramientas (Supervisor)"]
 Sup --- ToolC[💻 Coding Tool]
 Sup --- ToolM[💬 Messaging Tool]
 Sup --- ToolS[🔍 Search Tool]
 end

 Sup <--> CA[💻 Coding Agent]
 Sup <--> MA[💬 Messaging Agent]
 Sup <--> SA[🔍 Search Agent]

 subgraph CATools["Herramientas del Agente de Código"]
 CA --- T_Py[🐍 python]
 CA --- T_VS[💻 vscode]
 CA --- T_GH[🐙 github]
 end

 subgraph MATools["Herramientas de Mensajería"]
 MA --- T_Sl[💬 slack]
 MA --- T_Ds[👾 discord]
 end

 subgraph SATools["Herramientas de Búsqueda"]
 SA --- T_Go[🔍 google]
 SA --- T_Ar[📄 ArXiv]
 SA --- T_Wi[🌐 Wikipedia]
 end

El Agente Multimodal

El mundo real y la web digital no se componen únicamente de texto plano. Para interactuar plenamente con nuestro entorno, necesitamos agentes capaces de operar en múltiples formatos de datos. Aquí es donde los Agentes Multimodales están ganando un enorme terreno.

La capacidad de que un agente sea multimodal depende enteramente del LLM que actúe como su “cerebro”. Definimos a un agente como multimodal cuando su modelo subyacente es capaz de:

Comprender múltiples modalidades (Entrada/Input): El modelo procesa de forma nativa imágenes, archivos PDF estructurados, diagramas, flujos de audio o incluso video sin necesidad de convertirlos previamente a texto mediante software secundario OCR.
Generar múltiples modalidades (Salida/Output): El agente puede responder dibujando diagramas, generando archivos de audio estructurados, creando código visual interactivo o interactuando directamente en interfaces visuales de usuario (mediante herramientas de Computer Use).

El Coding Agent (Agente de Programación)

Uno de los tipos de agentes especializados más populares es el Coding Agent. A diferencia de los asistentes de chat tradicionales (que se limitan a dar sugerencias de código en una ventana de conversación estática), un Coding Agent opera de forma activa sobre entornos de desarrollo:

Lectura e investigación: Lee el código fuente del repositorio y comprende la arquitectura general.
Planificación y desarrollo: Escribe nuevas funciones, modifica archivos específicos y gestiona el flujo de control.
Ejecución y pruebas: Ejecuta compiladores y motores de pruebas unitarias locales para validar sus cambios.
Auto-depuración (Self-debugging): Si el compilador o las pruebas devuelven un error, el agente analiza el mensaje de salida, actualiza su plan, corrige su código y vuelve a ejecutar las pruebas hasta lograr que todo compile y funcione de forma exitosa.

Tiny Agents: Resolviendo la Eficiencia y los Costos

Aunque los sistemas agénticos son sumamente potentes, tienen un gran inconveniente oculto: el costo. Un agente autónomo puede tomar docenas de pasos secuenciales para resolver una tarea, consumiendo millones de tokens en el proceso sin que el desarrollador o usuario puedan anticipar la cantidad exacta de antemano.

Para evitar que el uso y costo de agentes se salga de control, la comunidad científica de IA ha desarrollado los Tiny Agents: agentes ultra-eficientes y veloces basados en modelos pequeños optimizados para tareas muy puntuales.

Existen cuatro categorías clave donde podemos buscar optimizaciones para nuestros agentes:

1. Creación de Modelos más Pequeños (Distillation)

Mediante técnicas de destilación de conocimiento (knowledge distillation), podemos entrenar un modelo pequeño (ej. de 1.5B o 3B parámetros) utilizando las respuestas detalladas y las trayectorias de razonamiento generadas por modelos gigantes (ej. de 405B parámetros). De esta manera, el modelo compacto conserva una alta tasa de acierto en tareas específicas pero a una fracción del costo y tamaño.

2. Arquitecturas de LLM más Eficientes (MoE y SSM)

Mixture of Experts (MoE): Modelos que solo activan una pequeña porción de sus redes neuronales (los “expertos”) para procesar un token específico, logrando una altísima velocidad de inferencia a bajo costo.
State Space Models (SSM): Arquitecturas alternativas a los Transformers tradicionales (como Mamba) que eliminan el crecimiento cuadrático del costo computacional de la atención en textos extremadamente largos, ideales para procesar enormes repositorios o históricos de conversación.

3. Disminución del Costo de Inferencia (Speculative Decoding)

La decodificación especulativa (speculative decoding) utiliza un modelo “asistente” sumamente pequeño y rápido para predecir (borrador) secuencialmente varios tokens de respuesta de manera rápida. Luego, el LLM principal (más grande y preciso) evalúa y valida estos tokens especulados en un solo paso paralelo, acelerando drásticamente el tiempo de generación final.

4. Modelos con Mayor Performance en Razonamiento (Hierarchical Decoding)

Consiste en implementar patrones lógicos jerárquicos y recursivos donde el agente descompone internamente el problema de forma recursiva antes de generar texto, evitando la generación redundante de tokens innecesarios y optimizando cada paso de inferencia al máximo.

Conclusión

El camino de los sistemas monolíticos hacia las redes de Agentes Especializados es una evolución natural y sumamente emocionante. Al combinar la orquestación modular de sistemas multi-agente, la flexibilidad de las capacidades multimodales y las optimizaciones de costo de los Tiny Agents, podemos diseñar soluciones de Inteligencia Artificial que no solo parezcan sacadas de la ciencia ficción, sino que sean escalables, rentables y robustas en el mundo real.

¡Con este artículo cerramos nuestra trilogía introductoria sobre la teoría y arquitectura de agentes de Inteligencia Artificial! En los próximos tutoriales prácticos empezaremos a picar código y a construir nuestros propios agentes colaborativos. ¡Manos a la obra!

Tablas Hash, Pilas y Colas: Estructuras de Datos de Alto Rendimiento

Dacadev — Tue, 19 May 2026 00:00:00 -0500

Tabla de Contenido

Hasta ahora hemos visto estructuras secuenciales como los Arrays, donde buscar un elemento requiere revisar celda por celda O(N) o usar búsqueda binaria O(log N) si están ordenados. Pero, ¿qué pasaría si te dijera que existe una estructura capaz de buscar, insertar y borrar datos en un solo paso O(1)?

Hoy explicaremos las Tablas Hash (Hash Tables),las Pilas (Stacks) y las Colas (Queues).

1. ¿Qué es una Tabla Hash (Hash Table)?

Una Tabla Hash (conocida en Python como diccionario, en JavaScript como objeto o Map, y en Go como map) es una estructura que asocia claves (keys) con valores (values).

A diferencia de los Arrays, donde los elementos están ordenados por índices numéricos continuos, las Tablas Hash son estructuras no ordenadas. Su velocidad absurda radica en su proceso interno: el Hashing.

¿Cómo funciona el Hashing?

Cuando guardamos un dato en una Tabla Hash (por ejemplo, {"cab" => "taxi"}), la computadora no busca una celda libre al azar. Utiliza una función hash (hash function) para convertir la clave de texto en un índice numérico específico.

Supongamos que inventamos una función hash súper simple que suma el valor alfabético de las letras de la clave:

A = 1, B = 2, C = 3, D = 4, E = 5

Si guardamos la clave "ACE":

A(1) + C(3) + E(5) = 9. El valor se almacena en el índice 9 de nuestra memoria física.

Si guardamos "CAB":

C(3) + A(1) + B(2) = 6. El valor se almacena en el índice 6.

flowchart LR
 Key["Clave: 'ACE'"] --> HashFunc["Función Hash<br/>(Suma de letras)"]
 HashFunc --> Index["Índice: 9"]
 Index --> Memory["[Celda 9] = 'star'"]

Cuando quieres buscar el valor asociado a "ACE", la computadora no recorre toda la tabla. Simplemente calcula de nuevo Hash("ACE") = 9 y accede de forma instantánea al índice 9 en 1 paso (O(1)). ¡Es brillante!

Colisiones y Load Factor

¿Qué pasa si intentamos insertar "DAB" en nuestro ejemplo anterior?

D(4) + A(1) + B(2) = 7 ¿Y si intentamos insertar "BAD"?
B(2) + A(1) + D(4) = 7

Ambas claves dan el mismo índice, a esto se le conoce como Colisión Hash. Cuando esto ocurre, la celda 7 debe almacenar una sub-lista de valores, lo que degrada el rendimiento de la búsqueda.

Para evitar colisiones en la vida real, las funciones hash usan matemáticas complejas y se rigen por la regla del Factor de Carga (Load Factor):

La proporción ideal es tener 10 celdas de memoria por cada 7 elementos almacenados (un factor de carga de 0.7). Esto mantiene un equilibrio perfecto entre uso de memoria y prevención de colisiones.

Eficiencia de las Operaciones en una Hash Table

Operación	Por Clave (Key)	Por Valor (Value)
Búsqueda	O(1) (Constante)	O(N) (Lineal)
Inserción	O(1) (Constante)	-
Eliminación	O(1) (Constante)	-

Note

La búsqueda de O(1) solo funciona en una dirección: desde la clave al valor. Si necesitas buscar una clave a partir de su valor, la computadora obligatoriamente deberá recorrer toda la estructura de forma lineal (O(N)).

Ejemplo Práctico: Optimizando código con Tablas Hash

Imagina que debes escribir una función en TypeScript que determine si un arreglo es un subconjunto de otro (es decir, si todos los elementos de un arreglo array2 existen en array1).

La versión lenta (O(N \cdot M)) - Bucles anidados:

function isSubsetSlow<T>(arr1: T[], arr2: T[]): boolean {
 // Compara cada elemento del segundo arreglo contra todos los del primero
 for (const val2 of arr2) {
 let found: boolean = false;
 for (const val1 of arr1) {
 if (val2 === val1) {
 found = true;
 break;
 }
 }
 if (!found) return false;
 }
 return true;
}

La versión veloz (O(N + M)) - Usando una Tabla Hash:

function isSubsetFast<T extends PropertyKey>(arr1: T[], arr2: T[]): boolean {
 const hashTable: Record<T, boolean> = {} as Record<T, boolean>;

 // Guardamos todos los elementos de arr1 en la tabla hash en O(N)
 for (const value of arr1) {
 hashTable[value] = true;
 }

 // Comprobamos la existencia de arr2 en O(M)
 for (const value of arr2) {
 if (!hashTable[value]) {
 return false;
 }
 }
 return true;
}

Al transformar la búsqueda lineal anidada en una búsqueda instantánea en una Tabla Hash, convertimos un algoritmo pesado de complejidad multiplicativa a uno de complejidad sumatoria. ¡Es la diferencia entre que un proceso tarde horas o milisegundos!

Pilas (Stacks)

Las Pilas (Stacks) son una estructura de datos abstracta y altamente restrictiva. A diferencia de un Array normal donde puedes leer o insertar en cualquier parte, en un Stack las reglas son estrictas.

Se rigen bajo el principio LIFO (Last In, First Out): el último elemento en entrar es el primero en salir. Imagínalo como una pila de platos en un restaurante, solo puedes interactuar con el plato de arriba.

flowchart TD
 subgraph Pila Stack - LIFO
 direction TB
 E3["[Plato 3] <-- Cima (Peek/Pop)"]
 E2["[Plato 2]"]
 E1["[Plato 1] <-- Base"]
 end

Sus 3 Reglas de Oro:

Los datos solo se pueden insertar al final (Push).
Los datos solo se pueden eliminar del final (Pop).
Solo se puede leer el último elemento (Peek o Cima).

¿Por qué usar una estructura tan restrictiva? Porque nos da seguridad. Al restringir las operaciones de acceso, garantizamos que nadie pueda corromper el orden de los datos intermedios. Es el motor detrás del botón “Deshacer” (Ctrl+Z) de tu editor de texto y del Call Stack de tu procesador.

Colas (Queues)

Las Colas (Queues) son la contraparte directa del Stack. Representan fielmente la fila de un banco o supermercado.

Se rigen por el principio FIFO (First In, First Out): el primer elemento en llegar es el primero en ser atendido.

flowchart LR
 subgraph Cola Queue - FIFO
 direction LR
 S1["[Cliente 1] En cabeza (Atender/Dequeue)"] --> S2["[Cliente 2]"] --> S3["[Cliente 3] En cola (Llegada/Enqueue)"]
 end

Sus 3 Reglas de Oro:

Los datos solo se insertan al final (Enqueue).
Los datos solo se eliminan del inicio (Dequeue).
Solo se puede leer el elemento del inicio.

Casos de uso comunes:

Colas de impresión: los documentos se imprimen exactamente en el orden en que fueron enviados.
Gestión de tareas asíncronas en servidores web (Message Queues).
Procesos de background en sistemas operativos.

Entendiendo la Notación Big O y los Algoritmos de Ordenamiento Básicos

Dacadev — Mon, 18 May 2026 00:00:00 -0500

Tabla de Contenido

¿Cómo podemos comparar dos algoritmos de manera formal? En el post anterior, vimos que contar los segundos es una mala idea porque depende del hardware. Aprendimos que contar los pasos es el camino correcto.

Hoy aprenderemos a usar la Notación Big O, el estándar que usamos en la industria para catalogar la eficiencia del software, y la aplicaremos analizando tres algoritmos de ordenamiento clásicos: Bubble Sort, Selection Sort e Insertion Sort.

¿Qué es la Notación Big O?

La Notación Big O es una herramienta matemática que describe la eficiencia de un algoritmo en función de cómo crece su número de pasos a medida que el tamaño de los datos de entrada (denotado como N) aumenta.

No nos dice la cantidad exacta de milisegundos que tardará un programa, sino la relación de crecimiento entre el volumen de datos y el esfuerzo del procesador.

Los tres perfiles más comunes que hemos visto hasta ahora son:

O(1) - Tiempo Constante: El algoritmo siempre requiere la misma cantidad de pasos, sin importar si N es 10 o 10 millones (por ejemplo, leer un índice en un Array).
O(N) - Tiempo Lineal: El número de pasos crece en proporción directa a los datos (por ejemplo, buscar un elemento mediante Búsqueda Lineal).
O(log N) - Tiempo Logarítmico: El algoritmo es sumamente eficiente. Cada vez que duplicamos los datos, solo se agrega un paso más al total (por ejemplo, la Búsqueda Binaria).

Note

Nota matemática: El logaritmo usado en Big O es en base 2 (log₂ N), no en base 10. Representa cuántas veces puedes dividir N a la mitad antes de llegar a 1.

Veamos gráficamente cómo se comparan estas curvas de crecimiento:

flowchart TD
 subgraph Eficiencia de Algoritmos
 direction TB
 C1["Excelente: O(1)"]
 C2["Muy Bueno: O(log N)"]
 C3["Aceptable: O(N)"]
 C4["Ineficiente: O(N²)"]
 end

Curvas de crecimiento de Big O

1. Ordenamiento Burbuja (Bubble Sort)

Bubble Sort es uno de los algoritmos de ordenamiento más simples e intuitivos. Se llama “Burbuja” porque los valores más altos van “flotando” gradualmente hacia el final del arreglo, como burbujas en el agua.

El proceso paso a paso:

Apuntas a los dos primeros elementos consecutivos del arreglo.
Si el de la izquierda es mayor que el de la derecha, los intercambias (swap).
Mueves los punteros una celda a la derecha y repites la comparación.
Repites el proceso hasta llegar al final del arreglo. Al terminar esta primera pasada, el número más alto está garantizado a estar en la última celda.
Regresas al inicio y realizas otra pasada completa.
El proceso termina cuando completas una pasada entera sin realizar ningún intercambio, lo que significa que todo está perfectamente ordenado.

flowchart TD
 Start["[4, 2, 7, 1]"] --> Step1["Comparar 4 y 2 -> ¡Intercambiar!"]
 Step1 --> Step2["[2, 4, 7, 1]"]
 Step2 --> Step3["Comparar 4 y 7 -> No intercambiar"]
 Step3 --> Step4["[2, 4, 7, 1]"]
 Step4 --> Step5["Comparar 7 y 1 -> ¡Intercambiar!"]
 Step5 --> EndPass["[2, 4, 1, 7] -> Primera pasada completada (7 está ordenado)"]

Implementación en Python:

def bubble_sort(arr: list[int]) -> list[int]:
 unsorted_until_index: int = len(arr) - 1
 is_sorted: bool = False

 while not is_sorted:
 is_sorted = True
 for i in range(unsorted_until_index):
 if arr[i] > arr[i+1]:
 # Intercambio rápido en Python:
 arr[i], arr[i+1] = arr[i+1], arr[i]
 is_sorted = False
 unsorted_until_index -= 1

 return arr

Eficiencia de Bubble Sort

Para ordenar un arreglo de tamaño N, en el peor de los casos realizamos aproximadamente N² comparaciones e intercambios.

Complejidad: O(N²) o Tiempo Cuadrático.
Veredicto: Altamente ineficiente para grandes conjuntos de datos. A medida que N se duplica, el número de pasos se multiplica por cuatro.

2. Ordenamiento por Selección (Selection Sort)

Selection Sort toma un camino diferente: en lugar de ir comparando parejas consecutivas, realiza una pasada completa para “seleccionar” el elemento más pequeño del arreglo y colocarlo en su posición final.

El proceso paso a paso:

Comienzas en el índice 0. Recorres todo el arreglo buscando el valor más pequeño.
Al terminar la pasada, intercambias el valor más pequeño con el elemento en el índice 0.
Te mueves al índice 1 y repites el proceso buscando el menor valor del resto del arreglo.
Repites esto aumentando el índice de inicio en 1 cada vez, hasta llegar al final.

flowchart TD
 Start["[4, 2, 7, 1]"] --> Step1["Buscar el menor desde índice 0 -> Es 1"]
 Step1 --> Swap1["Intercambiar 1 (menor) con 4 (índice 0)"]
 Swap1 --> Step2["[1, 2, 7, 4]"]
 Step2 --> Step3["Buscar el menor desde índice 1 -> Es 2"]
 Step3 --> Swap2["2 ya está en su lugar -> No hay cambios"]
 Swap2 --> Step4["[1, 2, 7, 4]"]
 Step4 --> Step5["Buscar el menor desde índice 2 -> Es 4"]
 Step5 --> Swap3["Intercambiar 4 con 7 (índice 2)"]
 Swap3 --> End["[1, 2, 4, 7] -> ¡Completamente Ordenado! 🎉"]

Implementación en Python:

def selection_sort(arr: list[int]) -> list[int]:
 for i in range(len(arr) - 1):
 lowest_number_index: int = i
 for j in range(i + 1, len(arr)):
 if arr[j] < arr[lowest_number_index]:
 lowest_number_index = j

 if lowest_number_index != i:
 arr[i], arr[lowest_number_index] = arr[lowest_number_index], arr[i]

 return arr

Eficiencia de Selection Sort

Si contamos los pasos de Selection Sort, en promedio realiza unas N²/2 comparaciones. Sin embargo, dado que Big O elimina las constantes (las fracciones y multiplicaciones por números fijos), su complejidad teórica también queda como O(N²).

Tip

¿Selection Sort o Bubble Sort? Aunque ambos son categorizados bajo el mismo grupo O(N²), Selection Sort es aproximadamente el doble de rápido en la vida real porque realiza un máximo de N intercambios, mientras que Bubble Sort puede realizar hasta N² intercambios.

3. Optimizando para Escenarios Optimistas (Insertion Sort)

Hasta ahora hemos analizado el rendimiento basándonos en el peor caso posible. Pero en el desarrollo real, muchas veces nos encontramos con arreglos que ya están parcialmente ordenados. Aquí es donde brilla Insertion Sort.

Insertion Sort funciona de manera similar a como ordenarías un mazo de cartas en tu mano.

El proceso paso a paso:

Comienzas en el índice 1 (la segunda celda). Remueves temporalmente el valor y lo guardas en una variable temporal (temp), dejando un “hueco”.
Comparas cada elemento a la izquierda del hueco con el valor en temp.
Si el elemento de la izquierda es mayor que temp, lo desplazas una posición hacia la derecha (el hueco se mueve hacia la izquierda).
Repites el paso 3 hasta encontrar un elemento menor o igual a temp, o llegar al inicio del arreglo.
Colocas el valor de temp en el hueco actual.
Repites el ciclo avanzando al siguiente índice.

Implementación en Python:

def insertion_sort(arr: list[int]) -> list[int]:
 for index in range(1, len(arr)):
 temp_value: int = arr[index]
 position: int = index - 1

 while position >= 0:
 if arr[position] > temp_value:
 arr[position + 1] = arr[position]
 position -= 1
 else:
 break

 arr[position + 1] = temp_value

 return arr

La gran revelación: El impacto de los escenarios

Analicemos la eficiencia de los tres algoritmos comparando sus mejores, peores y promedio casos:

Algoritmo	Peor Caso (Worst Case)	Caso Promedio (Average)	Mejor Caso (Best Case)
Bubble Sort	O(N²)	O(N²)	O(N) (si ya está ordenado)
Selection Sort	O(N²)	O(N²)	O(N²)
Insertion Sort	O(N²)	O(N²)	O(N)

¿Por qué Insertion Sort es tan especial?

Si le pasamos un arreglo que ya está ordenado a Insertion Sort, el bucle while interno se rompe inmediatamente en el primer paso (break). No hace ningún desplazamiento de datos. Por lo tanto, se ejecuta en un espectacular tiempo lineal O(N).

Si tus datos están mayoritariamente ordenados, Insertion Sort es por mucho la mejor opción entre los ordenamientos básicos.

Sistemas Agénticos: El Espectro de Autonomía y Desarrollo Responsable

Dacadev — Mon, 18 May 2026 00:00:00 -0500

Tabla de Contenido

Cuando empezamos a programar con LLMs (Large Language Models), a menudo nos quedamos en la fase de “pregunta-respuesta”. Le envías un prompt al modelo y este te devuelve una respuesta inmediata. Pero el verdadero poder de la Inteligencia Artificial (IA) surge cuando le damos libertad al modelo para actuar por sí mismo, tomar decisiones y corregir su camino.

Aquí es donde entramos al tema de los Sistemas Agénticos. Te has preguntado:

¿cuánta libertad debería tener realmente una IA?
¿Cómo nos aseguramos de que no tome acciones destructivas?
¿Cómo medimos si está haciendo bien su trabajo?

Note

En este artículo aprenderás qué define a un sistema agéntico, exploraremos el espectro de autonomía desde un simple prompt hasta agentes 100% autónomos, y analizaremos las mejores prácticas de desarrollo responsable y evaluación de sistemas agénticos. 🚀

¿Qué es un Sistema Agéntico?

Un sistema se considera agéntico en la medida en que el LLM tiene el control para tomar decisiones, elegir herramientas y definir los pasos a seguir para alcanzar un objetivo.

A diferencia de un software tradicional basado puramente en reglas rígidas y flujos de control fijos (if/else), un sistema agéntico exhibe un comportamiento orientado a metas (goal-directed behavior). Nosotros le decimos el qué (el objetivo final) y el agente decide el cómo (el plan de ejecución).

No obstante, la autonomía no es un interruptor binario de “todo o nada”. Existe un amplio espectro de control que podemos otorgar a nuestros agentes, dependiendo de la criticidad de la tarea y de los límites que queramos establecer.

El Espectro de Autonomía

Dependiendo del diseño del sistema, un agente de IA puede tener diferentes grados de libertad. En la práctica, podemos clasificar la autonomía en tres grandes niveles:

Nivel 1: Prompting Estándar (Baja Autonomía)

Es el nivel básico. El usuario envía un prompt, el LLM procesa la solicitud utilizando únicamente su conocimiento interno y genera una respuesta directa. No hay uso de herramientas externas ni toma de decisiones sobre el flujo de ejecución. El control es 100% del usuario.

flowchart LR
 P[User Prompt] --> LLM[🧠 LLM Tradicional] --> Ans1[Respuesta Directa]

Nivel 2: Pasos Fijos (Autonomía Orquestada / RAG)

En este nivel, el agente está integrado dentro de un flujo de trabajo predefinido (orquestado). Por ejemplo, un sistema RAG (Generación Aumentada por Recuperación) primero ejecuta una búsqueda vectorial en una base de datos de manera obligatoria (Paso 1) y luego le pasa ese contexto al LLM para que redacte la respuesta final (Paso 2). El modelo tiene cierta autonomía para elegir herramientas locales o resumir la información, pero no puede alterar el flujo global de los pasos.

flowchart LR
 P2[User Prompt] --> S1[🔍 Paso 1: Búsqueda Vectorial]
 S1 --> S2[🧠 Paso 2: Razonamiento y Herramientas]
 S2 --> Ans2[Respuesta Final]

Nivel 3: Agente Autónomo (Alta Autonomía)

Aquí el agente tiene total libertad dentro de un bucle de ejecución interactivo. El LLM recibe una meta, genera un plan inicial, ejecuta una acción (como llamar a una API o ejecutar código), observa el resultado del entorno, actualiza su plan y decide de forma autónoma si ha logrado cumplir el objetivo o si necesita seguir iterando.

flowchart TD
 P3[User Prompt] --> RLLM[🧠 LLM - Memoria y Herramientas]
 RLLM --> Plan[📋 Generar Plan]
 Plan --> Action[⚙️ Ejecutar Acción]
 Action --> Observe[👁️ Observar Resultado]
 Observe --> Decision{¿Meta cumplida?}
 Decision -->|No: Re-planificar| Update[🔄 Actualizar Plan]
 Update --> RLLM
 Decision -->|Sí| Ans3[Respuesta Final]

Casos de Uso del Mundo Real

Los sistemas agénticos ya están transformando múltiples industrias. Algunos de los ejemplos más destacados son:

Coding Agents (Agentes de Programación): Herramientas que no solo sugieren código, sino que pueden leer repositorios enteros, escribir pruebas unitarias, ejecutar programas en entornos de prueba seguros (sandboxes) y depurar errores por sí mismos hasta que el código funcione.
Búsqueda Profunda (DeepSearch): Agentes de investigación que realizan búsquedas web iterativas, cruzando múltiples fuentes de información, validando datos contradictorios y redactando reportes completos de manera autónoma.
Automatización de Procesos de Negocio: Agentes capaces de interactuar con software de facturación, responder correos electrónicos de clientes resolviendo problemas complejos y actualizar bases de datos sin intervención humana constante.

Desarrollo y Uso Responsable de Agentes IA

Darle autonomía a un agente digital conlleva grandes riesgos. Si le permites a un agente ejecutar comandos en tu terminal o enviar correos a tus clientes, un pequeño error de razonamiento o una alucinación podría causar pérdidas de información o daños reputacionales.

Por ello, el desarrollo ético y seguro de agentes requiere la implementación de tres pilares fundamentales:

1. Humano en el Bucle (Human-in-the-Loop)

Consiste en diseñar puntos de control donde el agente deba detener su ejecución y solicitar la aprobación explícita de un ser humano antes de realizar acciones críticas o irreversibles.

Tip

Regla de oro: Si una acción del agente tiene efectos directos en el mundo físico o digital real (ej. realizar un pago, enviar un email a un cliente, o borrar un archivo), siempre debes implementar una aprobación humana previa. 🚀

2. Guardrails (Límites y Barreras Técnicas)

Los guardrails son capas de software que rodean al agente y restringen lo que puede y no puede hacer. Algunas estrategias eficaces incluyen:

Validación Estricta de Entradas y Salidas: Analizar y limpiar los prompts enviados al LLM y las llamadas a herramientas generadas por este.
Presupuesto de Tokens y Pasos: Limitar el número de iteraciones máximas del bucle autónomo para evitar bucles infinitos muy costosos.
Entornos Seguros (Sandboxing): Ejecutar cualquier herramienta de código o comando del sistema dentro de contenedores aislados (como Docker) para proteger la máquina anfitriona.

3. Mitigación de Desinformación y Sesgos

Los agentes pueden propagar información falsa rápidamente si no se controlan sus fuentes de datos. Es vital dotar al agente de capacidades de contraste y verificación de datos cuando trabaja en entornos abiertos como internet, además de que de por si un LLM puede alucinar, dando respuestas que suenan plausibles pero son completamente inventadas.

Evaluando Sistemas Agénticos: Un Desafío Complejo

Si evaluar un LLM tradicional (que solo produce texto) ya es difícil, evaluar un agente es considerablemente más complejo. Un agente interactúa con su entorno, ejecuta múltiples pasos lógicos y toma decisiones secuenciales donde cada acción influye en el siguiente estado del sistema.

Al evaluar sistemas agénticos, no podemos limitarnos a verificar si el texto final “se lee bien”. Debemos evaluar el sistema completo bajo múltiples dimensiones:

Dimensión de Evaluación	Qué mide	Cómo se evalúa
Tasa de Éxito de la Tarea	Si el agente logró resolver la meta propuesta correctamente.	Pruebas de integración automatizadas con metas claras y verificables.
Eficiencia de la Trayectoria	El número de pasos y tokens utilizados. Un agente que resuelve el problema en 3 pasos es mejor que uno que toma 20.	Análisis de logs de ejecución y costos asociados.
Alineación y Cumplimiento	Si el agente respetó las políticas de seguridad y las barreras técnicas durante su ejecución.	Inyección de prompts maliciosos de prueba (Red Teaming).
Resiliencia ante Errores	Cómo reacciona el agente cuando una herramienta falla o una API devuelve un código de error.	Simulación de caídas de servicios y análisis de la capacidad de replanificación del agente.

La evaluación constante es la única forma de garantizar que el agente sea seguro, confiable y verdaderamente útil antes de desplegarlo en un entorno de producción crítico.

Conclusión

La autonomía de los agentes de IA abre un mundo lleno de posibilidades, pero también exige un alto nivel de responsabilidad de nuestra parte como desarrolladores. Al comprender el espectro de autonomía, diseñar e implementar guardrails técnicos sólidos e implementar metodologías de evaluación robustas, podemos construir herramientas agénticas que asombren a nuestros usuarios a la vez que se mantienen totalmente seguras.

En la próxima entrega de esta serie, exploraremos cómo podemos escalar estos sistemas haciendo que múltiples agentes con especialidades únicas colaboren entre sí. ¡Nos vemos en el próximo artículo!

Estructuras de Datos y Algoritmos: Los Fundamentos que Todo Dev Debe Saber

Dacadev — Sun, 17 May 2026 00:00:00 -0500

Tabla de Contenido

Si estás dando tus primeros pasos en el desarrollo de software, es muy común que midas el éxito de tu código con una única pregunta: ¿funciona y hace lo que se supone que debe hacer?

Sin embargo, a medida que avanzas en tu carrera, te das cuenta de que existe un mundo entero de otras métricas críticas, como por ejemplo: ¿Qué tan rápido se ejecuta? ¿Cuánta memoria consume? ¿Es escalable si el volumen de datos crece por mil?

Para escribir código que no solo funcione sino que sea verdaderamente profesional, debes dominar dos pilares fundamentales: las estructuras de datos y los algoritmos. Empecemos por lo básico: ¿qué son y por qué importan?

¿Por qué importa la estructura?

Consideremos una tarea sencilla: escribir una función en Python que imprima todos los números pares del 2 al 100.

Aquí tienes la versión uno (menos eficiente):

def print_numbers_version_one():
 number = 2

 while number <= 100:
 # Si el número es par, lo imprimimos:
 if number % 2 == 0:
 print(number)

 number += 1

Y aquí tienes la versión dos (más eficiente):

def print_numbers_version_two():
 number = 2

 while number <= 100:
 print(number)

 # Incrementamos por 2 directo al siguiente número par:
 number += 2

Ambos programas producen exactamente el mismo resultado. Pero la versión uno realiza 100 iteraciones y comprueba la paridad en cada paso. La versión dos solo hace 50 iteraciones y no realiza comprobaciones matemáticas innecesarias. Es el doble de eficiente.

¿Qué es una Estructura de Datos?

Una estructura de datos es la manera física y lógica en la que organizamos, gestionamos y almacenamos los datos en nuestro código. La forma en que eliges organizar tus datos afecta directamente la rapidez con la que tu programa puede operar con ellos.

Para un mismo propósito, puedes usar diferentes estructuras. Por ejemplo, si deseas unir tres palabras:

# Usando variables simples
x = "¡Hola! "
y "¿Cómo estás "
z = "hoy?"
print(x + y + z)

# Usando un Array (o Lista en Python)
array = ["¡Hola! ", "¿Cómo estás ", "hoy?"]
print(array[0] + array[1] + array[2])

Midiendo la velocidad del código

Un error clásico es medir la velocidad de un programa cronometrando los segundos que tarda en completarse. No es la mejor manera, El tiempo de ejecución en segundos varía según:

El procesador y hardware de la máquina.
Qué otros programas se están ejecutando en segundo plano.
El lenguaje de programación y su compilador o intérprete.

Para medir la velocidad de manera científica y objetiva, contamos la cantidad de pasos físicos que requiere un algoritmo para completarse.

El Array

El Array (o arreglo) es la estructura de datos más básica y el punto de partida de casi todo en computación. Físicamente, un array es un bloque continuo de memoria.

Un array tiene dos características clave:

Tamaño (Size): El número total de elementos que contiene.
Índice (Index): La posición numérica de cada celda. En la gran mayoría de lenguajes de programación, empezamos a contar desde 0.

array = ["manzanas", "bananas", "pepinos", "dátiles", "arándanos"]

Podemos representar la memoria de un array así:

flowchart LR
 a0["[0] manzanas<br/>Mem: 1000"]
 a1["[1] bananas<br/>Mem: 1001"]
 a2["[2] pepinos<br/>Mem: 1002"]
 a3["[3] dátiles<br/>Mem: 1003"]
 a4["[4] arándanos<br/>Mem: 1004"]
 a0 --- a1 --- a2 --- a3 --- a4

Las 4 Operaciones Fundamentales en un Array

Para evaluar qué tan eficiente es una estructura de datos, analizamos cuántos pasos le toma realizar las cuatro operaciones básicas:

1. Lectura (Read / Get)

Consiste en obtener el valor que está en un índice específico (por ejemplo, “¿qué hay en la posición 3?”).

¿Cómo lo hace la computadora? Al estar guardados en memoria de manera continua, la computadora hace un cálculo matemático simple: DirecciónInicio + (Índice * TamañoCelda). Va directo a la celda en 1 paso.
Eficiencia: 1 paso (constante).

2. Búsqueda (Search)

Consiste en encontrar el índice de un elemento sabiendo únicamente su valor (por ejemplo, “¿en qué posición están los ‘pepinos’?”).

¿Cómo lo hace? La computadora no puede ver el contenido de todo el array a la vez. Debe ir celda por celda, de izquierda a derecha, comprobando si el valor coincide. A esto se le llama Búsqueda Lineal.
Eficiencia: Si el elemento está al principio, toma 1 paso. Si está al final o no existe, toma N pasos (siendo N el tamaño del array). En el peor de los casos, la eficiencia es de N pasos.

3. Inserción (Insert)

Consiste en agregar un nuevo elemento al array. Aquí tenemos dos escenarios:

Insertar al final: Es súper sencillo. La computadora simplemente coloca el valor en la siguiente celda libre. Toma 1 paso.
Insertar al inicio o en medio: ¡Aquí viene el dolor de cabeza! Para meter un valor al inicio (índice 0), primero debemos mover todos los elementos existentes una celda hacia la derecha para abrir espacio.

flowchart TD
 subgraph Antes de Insertar
 A0["[0] A"] --> A1["[1] B"] --> A2["[2] C"]
 end
 subgraph Proceso de Desplazamiento
 D0["Desplazar C a [3]"] --> D1["Desplazar B a [2]"] --> D2["Desplazar A a [1]"]
 end
 subgraph Resultado Final
 R0["[0] NUEVO"] --> R1["[1] A"] --> R2["[2] B"] --> R3["[3] C"]
 end

Si el array tiene tamaño N, insertar al principio toma N desplazamientos + 1 inserción = N + 1 pasos.

4. Eliminación (Delete)

Consiste en borrar un elemento de un índice específico. Al igual que con la inserción, si borramos el elemento del inicio, dejamos un “hueco vacío”. Las reglas de los arrays exigen que no haya espacios vacíos intermedios, por lo que debemos desplazar todos los elementos de la derecha una posición hacia la izquierda.

Eficiencia: En el peor de los casos (eliminar el primer elemento), toma N - 1 pasos de desplazamiento.

Sets: Cómo una sola regla cambia toda la eficiencia

Un Set (conjunto) es un tipo especial de arreglo con una regla estricta: no se permiten valores duplicados.

Esta pequeña regla de negocio transforma drásticamente la eficiencia de la operación de inserción:

En un Array común, insertar al final toma 1 paso.
En un Set, antes de insertar un elemento al final, la computadora debe hacer una búsqueda lineal completa para asegurar que el elemento no exista previamente en el Set.

Por lo tanto, la inserción al final en un Set toma N pasos de búsqueda + 1 paso de inserción = N + 1 pasos.

Note

Aunque los Sets protegen la integridad de tus datos previniendo duplicados, debes tener en cuenta que su inserción es mucho más lenta en arreglos de gran tamaño.

Arreglos Ordenados

Un Arreglo Ordenado es un array cuyos valores se mantienen de forma ascendente o descendente de forma obligatoria.

Inserción en Arreglos Ordenados

Para insertar un valor en un arreglo ordenado (por ejemplo, meter el número 4 en [1, 3, 5, 8]), no podemos simplemente agregarlo al final. Debemos:

Buscar el lugar exacto donde corresponde el elemento para mantener el orden (después del 3 y antes del 5).
Desplazar los elementos mayores hacia la derecha (5 y 8).
Insertar el nuevo valor.

Esto hace que la inserción sea ligeramente más costosa en pasos que en un array normal, pero abre la puerta a un algoritmo de búsqueda revolucionario.

Búsqueda Binaria

Si tu arreglo no está ordenado, la única forma de buscar es la búsqueda lineal (celda por celda), lo que toma hasta N pasos.

Pero si tu arreglo sí está ordenado, puedes usar la Búsqueda Binaria. Este algoritmo consiste en:

Ir directo al elemento del medio del arreglo.
Si el valor buscado es menor, descartas toda la mitad derecha.
Si es mayor, descartas toda la mitad izquierda.
Repites el proceso en la mitad restante hasta encontrarlo o quedarte sin elementos.

flowchart TD
 Start["Buscar 11 en [2, 4, 6, 8, 11, 14, 18, 22]"] --> Step1["Valor central: 8 (índice 3)"]
 Step1 --> Check{"¿Es 11 == 8?"}
 Check -- No, es mayor --> DescartarIzq["Descartar [2, 4, 6, 8]"]
 DescartarIzq --> SubSearch["Buscar en [11, 14, 18, 22]"]
 SubSearch --> Step2["Valor central: 14 (índice 5)"]
 Step2 --> Check2{"¿Es 11 == 14?"}
 Check2 -- No, es menor --> DescartarDer["Descartar [14, 18, 22]"]
 DescartarDer --> Final["Buscar en [11] -> ¡Encontrado! 🎉"]

Búsqueda Binaria vs. Búsqueda Lineal

Tamaño del Arreglo (N)	Pasos Máximos (Lineal)	Pasos Máximos (Binaria)
8	8	3
100	100	7
10,000	10,000	14
1,000,000	1,000,000	20

La diferencia es notable. Buscar en una base de datos de un millón de registros toma un millón de pasos con búsqueda lineal, pero solo 20 pasos usando búsqueda binaria. Por eso, elegir el algoritmo correcto de acuerdo a la estructura de tus datos marca toda la diferencia del mundo.

En el siguiente post, aprenderemos la forma matemática formal en la que los desarrolladores expresamos estas diferencias de eficiencia: la Notación Big O, y cómo usarla para analizar nuestros primeros algoritmos de ordenamiento. ¡No te lo pierdas! 🚀

Agentes IA: ¿Qué es un Agente de Inteligencia Artificial?

Dacadev — Fri, 15 May 2026 00:00:00 -0500

Tabla de Contenido

En el mundo de la Inteligencia Artificial, los términos aparecen y se mezclan con una velocidad que a veces marea. Uno de los conceptos más poderosos —y más incomprendidos— es el de Agente de IA. Seguro has escuchado el término, pero ¿qué significa realmente? ¿Qué hace que un sistema deje de ser un simple chatbot y se convierta en un agente capaz de percibir, razonar y actuar sobre su entorno?

Note

En este artículo aprenderás qué es un agente de IA desde su definición formal, cómo un LLM actúa como su “cerebro”, y los módulos fundamentales que lo potencian: memoria, herramientas y planificación. 🚀

Definición formal de un Agente

An agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators.

Russell & Norvig, AI: A Modern Approach

Podemos descomponer esta definición en los componentes fundamentales que están en el corazón de todo agente:

Environment (Entorno): El mundo con el que el agente interactúa
Sensors (Sensores): Componentes que el agente usa para observar su entorno
Actuators (Actuadores): Herramientas que el agente usa para actuar sobre el entorno
Effector (Efector): El “cerebro” o las reglas que deciden cómo pasar de observaciones a acciones

flowchart LR
 E[🌍 Entorno] -->|percibe| S[📡 Sensores]
 S -->|observaciones| EF[🧠 Efector]
 EF -->|decisiones| A[🔧 Actuadores]
 A -->|actúa sobre| E

Imagina un robot aspiradora: sus sensores detectan obstáculos y suciedad (entorno), su “cerebro” decide qué dirección tomar (efector), y sus motores y cepillos ejecutan la acción (actuadores). Un agente de IA funciona con la misma lógica, pero en un entorno digital.

El Agente basado en LLM

En la práctica, el Efector o cerebro del agente tiende a ser un LLM con capacidad de razonamiento. A través de módulos adicionales —memoria, herramientas y planificación— este LLM es capaz de interactuar con su entorno.

Los Actuadores son las herramientas del LLM (APIs, funciones, búsquedas)
Los Sensores son las capacidades multimodales del LLM (texto, imágenes, audio)
El Usuario forma parte del entorno e influye directamente en cómo se inicia el agente

flowchart TD
 U[👤 Usuario] -->|prompt| LLM[🧠 LLM - Cerebro del Agente]
 LLM -->|usa| T[🔧 Herramientas / Tools]
 LLM -->|consulta| M[💾 Memoria]
 LLM -->|genera| P[📋 Plan]
 T -->|resultados| LLM
 M -->|contexto| LLM
 P -->|siguiente paso| LLM
 LLM -->|respuesta| U
 T -->|modifica| ENV[🌍 Entorno Digital]
 ENV -->|datos| LLM

Sin ninguna interacción del usuario, el LLM no tomará ninguna acción. El agente está fuertemente influenciado por cómo el usuario inicia la conversación.

Large Language Models (LLMs)

El LLM es considerado el “cerebro” del agente. Tradicionalmente, un LLM es un modelo que no hace más que predecir la siguiente palabra basándose en un texto de entrada.

Tokenización

El LLM primero descompone la consulta de entrada en tokens, que son sub-componentes de palabras que permiten al modelo generalizar a palabras que no ha visto antes. El modelo procesa estos tokens y hace una predicción sobre cuál podría ser el siguiente.

Autoregresión

El LLM predice el siguiente token, usa ese token predicho para actualizar su entrada, y luego continúa las predicciones. Al hacer esto de forma iterativa —lo que se llama autoregresión— puede crear respuestas completas a la consulta del usuario.

sequenceDiagram
 participant Input as Texto de entrada
 participant LLM as LLM
 participant Output as Texto generado

 Input->>LLM: "El gato está"
 LLM->>Output: "sentado"
 Note over Input,Output: Se agrega al input
 Input->>LLM: "El gato está sentado"
 LLM->>Output: "en"
 Note over Input,Output: Se agrega al input
 Input->>LLM: "El gato está sentado en"
 LLM->>Output: "la silla"
 Note over Output: Respuesta completa generada

Cada predicción se alimenta de las anteriores, construyendo la respuesta palabra por palabra.

LLMs con Razonamiento

El campo de los agentes de IA descubrió que las capacidades de los LLMs aumentarían sustancialmente si pudieran razonar. En lugar de que el modelo “piense” en silencio (a través de sus parámetros internos), ahora se entrenan para “pensar en voz alta” generando trazas de razonamiento antes de derivar la respuesta.

flowchart LR
 Q[📝 Consulta del usuario] --> T[💭 Pensamientos / Razonamiento]
 T --> R[✅ Respuesta final]

La idea principal es que al escribir sus pensamientos primero mediante su comportamiento autoregresivo, el LLM puede dedicar cómputo adicional a estructurar su razonamiento antes de generar la respuesta. Como los humanos, al estructurar sus pensamientos, las consultas complejas que requieren razonamiento multi-paso son más fáciles de resolver.

Tip

En la práctica, estos “pensamientos” están ocultos para el usuario. La respuesta que ves generalmente representa un resumen del razonamiento interno del modelo.

Ejemplo de razonamiento

Veamos cómo un LLM con razonamiento aborda un problema complejo:

El modelo genera una cadena de pensamientos internos, evalúa opciones y finalmente produce una respuesta bien fundamentada.

Aumentando las capacidades del LLM

Aunque los LLMs con razonamiento son vitales para los agentes de IA, siguen siendo incompletos. Como entidades estáticas de texto-a-texto, los LLMs no tienen control sobre su entorno, ni recuerdan sus interacciones, ni aprenden de ellas.

Para convertir un LLM en un verdadero agente, necesitamos proveerlo de tres módulos fundamentales:

flowchart TD
 LLM[🧠 LLM con Razonamiento]
 MEM[💾 Memoria]
 TOOLS[🔧 Herramientas]
 PLAN[📋 Planificación y Reflexión]

 MEM --> LLM
 TOOLS --> LLM
 PLAN --> LLM

 LLM --> AGENT[🤖 Agente de IA]

Memoria

Sin memoria, los LLMs operan en conversaciones de “single-turn”: una sola pregunta y una sola respuesta. La información no persiste entre llamadas.

sequenceDiagram
 participant U as Usuario
 participant L as LLM

 U->>L: ¿Cuál es la capital de Francia?
 L->>U: París
 Note over U,L: ❌ Sin contexto previo
 U->>L: ¿Y su población?
 L->>U: ¿De qué ciudad hablas?
 Note over L: No recuerda la conversación anterior

Afortunadamente, hay muchas formas de agregar módulos de memoria. La forma más común es simplemente añadir la conversación previa al prompt actual:

sequenceDiagram
 participant U as Usuario
 participant M as Memoria
 participant L as LLM

 U->>L: ¿Cuál es la capital de Francia?
 L->>U: París
 L->>M: Guardar contexto
 U->>L: ¿Y su población?
 M->>L: Contexto: hablamos de París
 L->>U: París tiene ~2.1 millones de habitantes
 Note over L: ✅ Recuerda el contexto

Warning

Los módulos de memoria pueden ser complejos. Si recibimos demasiada información, se vuelve difícil de procesar, lo que puede llevar a malas decisiones. Esto se llama sobrecarga de información y es un problema real incluso para los LLMs. Se necesita un balance entre la cantidad y calidad de la información en el prompt — esto es lo que se conoce como context engineering.

Los sistemas de memoria comparten similitudes con nuestros sistemas de memoria humana:

Memoria a corto plazo: La conversación actual, las últimas interacciones
Memoria a largo plazo: Hechos persistentes, preferencias del usuario, conocimiento acumulado

Herramientas (Tools)

Con la memoria, los LLMs recuerdan sus conversaciones previas, pero aún no son capaces de interactuar con su entorno. Los LLMs pueden interactuar con su entorno digital a través de herramientas externas que amplían sus capacidades: calculadoras, motores de búsqueda, APIs, shells de comandos, y más.

Sin embargo, los LLMs no son capaces de usar herramientas por sí mismos. Fundamentalmente, un LLM es una función de texto-entrada/texto-salida. Solo puede describir o expresar la intención de tomar una acción.

sequenceDiagram
 participant U as Usuario
 participant L as LLM
 participant R as Runtime / Orquestador
 participant T as Herramienta

 U->>L: ¿Cuánto es 847 × 392?
 L->>R: {"tool": "calculator", "params": {"expr": "847 * 392"}}
 Note over L,R: El LLM expresa INTENCIÓN
 R->>T: Ejecutar cálculo
 T->>R: 331,824
 R->>L: Resultado: 331,824
 L->>U: El resultado es 331,824

Info

El LLM puede expresar la intención de usar una herramienta, pero depende de nosotros convertir esa intención en una llamada real. Necesitamos escribir software que interprete el output del LLM (generalmente JSON) para elegir la herramienta correcta y completar sus parámetros.

Las herramientas varían en complejidad:

Simples: Calculadoras, conversor de unidades
Intermedias: Búsqueda web, consultas a bases de datos
Complejas: Acceso a terminal, entornos de código, APIs de GitHub

Planificación y Reflexión

El ingrediente final para ir de un LLM “regular” a un Agente de IA es su capacidad de planificar y reflexionar. Estas capacidades son fundamentales, ya que el agente necesita decidir qué pasos tomar, cómo tomarlos y cuándo.

Descomposición de tareas

Aquí es donde entra la planificación: descomponer una tarea grande en pasos más pequeños y ejecutables. Esto se conoce como task decomposition.

flowchart TD
 Q[📝 Query: Investiga papers recientes sobre RAG] --> P[📋 Plan]
 P --> T1[1. Buscar en Google Scholar]
 P --> T2[2. Buscar en ArXiv]
 P --> T3[3. Filtrar por fecha 2024-2025]
 P --> T4[4. Leer abstracts relevantes]
 P --> T5[5. Generar resumen comparativo]

 T1 --> E[⚡ Ejecución secuencial]
 T2 --> E
 T3 --> E
 T4 --> E
 T5 --> E

Ejecución iterativa con razonamiento

Al referirse continuamente a su plan, el LLM ejecuta cada tarea una por una. Hacerlas todas a la vez rara vez es eficiente, ya que cada tarea puede influir en otra. Después de completar una tarea específica, el LLM razona sobre qué pasos tomar a continuación.

flowchart TD
 START[🎯 Objetivo] --> PLAN[📋 Crear Plan]
 PLAN --> EXEC[⚡ Ejecutar Tarea]
 EXEC --> REASON[🤔 Razonar sobre resultado]
 REASON -->|siguiente tarea| EXEC
 REASON -->|plan completo| DONE[✅ Resultado Final]
 REASON -->|ajustar plan| REFLECT[🔄 Reflexionar]
 REFLECT -->|plan mejorado| PLAN

Reflexión

Crear un plan no es suficiente. El LLM puede descubrir a mitad del camino que algunos pasos no son apropiados. Por ejemplo, podría descubrir que Google y ArXiv son insuficientes y decidir agregar Semantic Scholar y PubMed como recursos adicionales.

Este comportamiento reflexivo hace que los agentes parezcan humanos: intentan descubrir sus fallos y hacer intentos por corregirlos. Al reflexionar sobre comportamiento pasado, el plan inicial puede mejorarse continuamente.

Note

La planificación y reflexión crean un ciclo iterativo: planificar tareas → ejecutar acciones → reflexionar sobre el resultado → ajustar el plan. Este ciclo es lo que diferencia a un verdadero agente de un simple modelo que responde preguntas. 🚀

Conclusión

Un agente de IA no es simplemente un LLM que responde preguntas. Es un sistema compuesto por:

Un LLM con razonamiento como cerebro central
Memoria para mantener contexto entre interacciones
Herramientas para interactuar con el entorno digital
Planificación y reflexión para abordar tareas complejas de forma iterativa

flowchart TD
 subgraph AGENT[🤖 Agente de IA]
 direction TB
 BRAIN[🧠 LLM con Razonamiento]
 MEM[💾 Memoria<br/>Corto y largo plazo]
 TOOLS[🔧 Herramientas<br/>APIs, búsqueda, código]
 PLAN[📋 Planificación<br/>Descomposición + Reflexión]

 MEM <--> BRAIN
 TOOLS <--> BRAIN
 PLAN <--> BRAIN
 end

 USER[👤 Usuario] <-->|interacción| AGENT
 AGENT <-->|percibe y actúa| ENV[🌍 Entorno]

La próxima vez que interactúes con un asistente de IA que busca información, ejecuta código y ajusta su enfoque basándose en los resultados, estarás interactuando con un agente. Y ahora entiendes la maquinaria que lo hace posible.

asyncio: Cómo Funcionan los Procesos, Hilos y el Event Loop

Dacadev — Mon, 11 May 2026 00:00:00 -0500

Tabla de Contenido

En el artículo anterior construimos un modelo mental sobre concurrencia, paralelismo y los tipos de multitarea. Ahora vamos a bajar un nivel: entender qué son los procesos y los hilos, por qué el GIL de Python cambia las reglas del juego, y cómo asyncio logra concurrencia con un solo hilo gracias al event loop.

Procesos e Hilos

¿Qué es un proceso?

Un proceso es una instancia de una aplicación en ejecución. Cada proceso tiene su propio espacio de memoria aislado — ningún otro proceso puede acceder a él directamente — y se ejecuta en un CPU o núcleo del sistema.

¿Qué es un hilo (thread)?

Un hilo es una unidad de ejecución más ligera que vive dentro de un proceso. A diferencia de los procesos, los hilos no tienen su propia memoria: comparten el espacio de memoria del proceso que los creó.

Todo proceso tiene al menos un hilo asociado, conocido como el hilo principal (main thread). Además, un proceso puede crear hilos adicionales, comúnmente llamados hilos de trabajo (worker threads) o hilos en segundo plano (background threads).

flowchart TB
 subgraph P1["Proceso (PID: 1234)"]
 direction TB
 M1["Memoria del proceso"]
 MT["Hilo principal\n(main thread)"]
 W1["Worker thread 1"]
 W2["Worker thread 2"]
 M1 <--> MT
 M1 <--> W1
 M1 <--> W2
 end

 style P1 fill:transparent,stroke:#64748b
 style M1 fill:#3b82f6,stroke:#1e40af,color:#fff
 style MT fill:#10b981,stroke:#065f46,color:#fff
 style W1 fill:#f59e0b,stroke:#b45309,color:#fff
 style W2 fill:#f59e0b,stroke:#b45309,color:#fff

Info

Todos los hilos dentro de un proceso comparten la misma memoria. Esto hace la comunicación entre hilos muy rápida, pero introduce el riesgo de condiciones de carrera si no se maneja con cuidado.

Verificándolo en Python

Puedes inspeccionar el proceso e hilo actual con los módulos os y threading:

import os
import threading

print(f'Proceso de Python con PID: {os.getpid()}')
total_threads = threading.active_count()
thread_name = threading.current_thread().name

print(f'Python está ejecutando {total_threads} hilo(s)')
print(f'El hilo actual es: {thread_name}')

# Output esperado
Proceso de Python con PID: 48672
Python está ejecutando 1 hilo(s)
El hilo actual es: MainThread

Por defecto, tu programa Python corre en un solo hilo (MainThread) dentro de un solo proceso.

El Global Interpreter Lock (GIL)

El GIL (Global Interpreter Lock) es uno de los temas más debatidos en la comunidad Python. En términos simples: el GIL impide que un proceso de Python ejecute más de una instrucción de bytecode a la vez, incluso si tienes múltiples hilos.

Esto significa que aunque crees varios hilos con threading, solo uno ejecuta código Python en cualquier instante.

sequenceDiagram
 participant GIL
 participant T1 as Hilo 1
 participant T2 as Hilo 2

 GIL->>T1: 🔓 GIL adquirido
 activate T1
 T1->>T1: Ejecuta bytecode
 T1->>GIL: 🔒 Libera GIL
 deactivate T1
 GIL->>T2: 🔓 GIL adquirido
 activate T2
 T2->>T2: Ejecuta bytecode
 T2->>GIL: 🔒 Libera GIL
 deactivate T2
 GIL->>T1: 🔓 GIL adquirido
 activate T1
 T1->>T1: Ejecuta bytecode
 deactivate T1

¿El GIL se libera alguna vez?

Sí. El GIL se libera durante las operaciones de I/O. Cuando un hilo hace una petición de red o una lectura de disco, libera el GIL, permitiendo que otro hilo tome el control y ejecute código Python mientras tanto.

Esto es lo que hace que threading sea útil para trabajo I/O-bound, pero ineficaz para trabajo CPU-bound.

flowchart LR
 A["Operación\nCPU-bound"] -->|"GIL retenido 🔒"| B["Solo 1 hilo\nejecuta a la vez"]
 C["Operación\nI/O-bound"] -->|"GIL liberado 🔓"| D["Otros hilos pueden\nejecutar código"]

 style A fill:#ef4444,stroke:#991b1b,color:#fff
 style B fill:#ef4444,stroke:#991b1b,color:#fff
 style C fill:#10b981,stroke:#065f46,color:#fff
 style D fill:#10b981,stroke:#065f46,color:#fff

`asyncio` y el GIL

asyncio aprovecha exactamente este comportamiento: como las operaciones de I/O liberan el GIL, puede lograr concurrencia con un solo hilo. En lugar de crear múltiples hilos, asyncio crea objetos llamados coroutines — que puedes pensar como hilos ultra-ligeros.

Note

Mientras una coroutine espera por una operación de I/O, el event loop ejecuta otras coroutines que estén listas. El resultado: concurrencia sin los problemas de sincronización del multithreading.

Concurrencia de Un Solo Hilo

La concurrencia de un solo hilo no se basa en hacer dos cosas simultáneamente (eso sería paralelismo), sino en aprovechar los tiempos de espera de las operaciones de I/O para ejecutar otras tareas. El mecanismo se apoya en tres pilares:

Sockets no bloqueantes
Delegación al SO
Event Loop

1. Sockets no bloqueantes

A diferencia de un socket estándar que detiene el programa hasta recibir una respuesta, un socket no bloqueante permite enviar una petición y devolver el control al programa inmediatamente, sin esperar el resultado.

2. Delegación al sistema operativo

Cuando el código llega a una operación de red o lectura de disco, Python le delega la espera al sistema operativo. El hilo de ejecución queda libre de inmediato.

3. El Event Loop como coordinador

Mientras el SO vigila los sockets, el hilo de Python sigue ejecutando otras tareas. Cuando el SO detecta que los datos llegaron, envía una notificación. El event loop recibe este aviso y “despierta” la tarea pausada para que procese la respuesta.

El siguiente diagrama de secuencia muestra cómo interactúan estos tres pilares:

sequenceDiagram
 participant MT as Main Thread
 participant EL as Event Loop
 participant OS as Sistema Operativo
 participant S1 as Socket 1
 participant S2 as Socket 2

 MT->>EL: Envía tareas
 EL->>EL: Ejecuta tarea 1 hasta I/O
 EL->>OS: Registra Socket 1 para monitoreo
 OS->>S1: Vigila socket
 EL->>EL: Ejecuta tarea 2 hasta I/O
 EL->>OS: Registra Socket 2 para monitoreo
 OS->>S2: Vigila socket
 S1-->>OS: Datos listos ✅
 OS-->>EL: Notifica Socket 1
 EL->>EL: Reanuda tarea 1
 S2-->>OS: Datos listos ✅
 OS-->>EL: Notifica Socket 2
 EL->>EL: Reanuda tarea 2

Cómo Funciona el Event Loop

En su forma más básica, un event loop es simplemente un bucle infinito que procesa mensajes de una cola, uno a la vez:

from collections import deque

messages = deque()

while True:
 if messages:
 message = messages.pop()
 process_message(message)

En asyncio, el event loop mantiene una cola de tasks (tareas) en lugar de mensajes simples. Cada task es un wrapper alrededor de una coroutine. Cuando una coroutine alcanza una operación de I/O, se pausa y le devuelve el control al event loop, que puede ejecutar otras tareas que no estén esperando I/O.

flowchart TD
 A["Event Loop inicia"] --> B["¿Hay tareas en la cola?"]
 B -->|Sí| C["Tomar siguiente tarea"]
 C --> D{"¿La tarea tiene\nI/O pendiente?"}
 D -->|No| E["Ejecutar hasta\nel próximo await"]
 E --> F{"¿La tarea alcanzó\nuna operación I/O?"}
 F -->|Sí| G["Pausar tarea y registrar\nsocket en el SO"]
 F -->|No| H["Tarea completada ✅\nRemover de la cola"]
 G --> B
 H --> B
 D -->|Sí, datos listos| I["Reanudar tarea"]
 I --> F
 D -->|Sí, esperando aún| B
 B -->|No| J["Esperar notificaciones\ndel SO"]
 J --> B

 style A fill:#3b82f6,stroke:#1e40af,color:#fff
 style H fill:#10b981,stroke:#065f46,color:#fff

Note

Este ciclo se repite indefinidamente hasta que todas las tareas se completan o el programa se cierra explícitamente. Si una coroutine ejecuta trabajo CPU-bound sin ceder control con await, bloqueará todo el event loop y ninguna otra tarea podrá avanzar.

En conclusión

Un proceso tiene memoria aislada; un hilo comparte memoria dentro de su proceso.
El GIL impide paralelismo real con hilos en Python, pero se libera durante operaciones de I/O.
asyncio aprovecha esta liberación del GIL para lograr concurrencia en un solo hilo mediante coroutines.
El event loop coordina las tareas: ejecuta coroutines hasta que alcanzan un await, las pausa, y reanuda otras que ya tengan datos listos.
Los sockets no bloqueantes y la delegación al SO son los mecanismos que permiten esta concurrencia sin crear múltiples hilos.

Referencias

asyncio: Los Fundamentos de la Programación Asíncrona en Python

Dacadev — Sun, 10 May 2026 00:00:00 -0500

Tabla de Contenido

Si alguna vez construiste un scraper que recorre decenas de páginas, un microservicio que atiende cientos de peticiones o un bot que consume múltiples APIs, seguro sentiste la frustración de esperar. Una petición termina, la siguiente arranca, y tu programa queda ahí sin hacer nada útil.

La librería asyncio de Python fue diseñada para resolver exactamente este problema. En este artículo vamos a construir un modelo mental sólido sobre los conceptos clave: concurrencia, paralelismo, multitarea y la diferencia entre operaciones limitadas por CPU y por E/S.

¿Qué es la programación asíncrona?

La programación asíncrona es un modelo donde las tareas de larga duración se ejecutan en segundo plano, separadas del flujo principal de tu aplicación. En lugar de bloquear todo mientras esperas una respuesta de red o una lectura de archivo, el sistema queda libre para hacer otro trabajo. Cuando la tarea termina, tu código recibe una notificación y puede procesar el resultado.

Note

asyncio — abreviación de asynchronous I/O — es la librería estándar de Python que implementa este modelo. Fue introducida en Python 3.4 y hoy es la base de frameworks modernos como FastAPI, aiohttp y Starlette.

CPU-bound vs. I/O-bound

Antes de avanzar, necesitas entender una distinción fundamental: ¿en qué está gastando tiempo tu código?

Operaciones limitadas por E/S (I/O-bound)

Tu programa pasa la mayor parte del tiempo esperando un sistema externo: la red, el disco, una base de datos. La CPU está prácticamente ociosa. Ejemplos:

Hacer peticiones HTTP.
Leer o escribir archivos en disco.
Consultar una base de datos.

Operaciones limitadas por CPU (CPU-bound)

El procesador es el cuello de botella. La CPU está activamente calculando, sin esperas externas. Ejemplos:

Calcular dígitos de pi.
Aplicar lógica de negocio sobre estructuras de datos grandes.
Procesamiento de imágenes o entrenamiento de modelos.

Ejemplo práctico

Considera este fragmento de código:

import requests

response = requests.get('https://www.example.com') # 1 - I/O-bound
items = response.headers.items()
headers = [f'{key}: {header}' for key, header in items] # 2 - CPU-bound

formatted_headers = '\n'.join(headers) # 3 - CPU-bound

with open('headers.txt', 'w') as file:
 file.write(formatted_headers) # 4 - I/O-bound

El siguiente diagrama muestra el flujo de ejecución y clasifica cada paso:

flowchart LR
 A["1. requests.get()"] -->|respuesta| B["2. List comprehension"]
 B --> C["3. join() headers"]
 C --> D["4. file.write()"]

 style A fill:#3b82f6,stroke:#1e40af,color:#fff
 style B fill:#f59e0b,stroke:#b45309,color:#fff
 style C fill:#f59e0b,stroke:#b45309,color:#fff
 style D fill:#3b82f6,stroke:#1e40af,color:#fff

🔵 Azul = I/O-bound (esperando red o disco) · 🟡 Amarillo = CPU-bound (procesando en memoria)

Info

asyncio brilla con cargas I/O-bound. Si tu cuello de botella es la CPU, necesitarás multiprocessing o concurrent.futures.

Concurrencia vs. Paralelismo

Estos dos términos se confunden constantemente, pero describen cosas distintas.

Concurrencia: alternar entre tareas

Concurrencia significa gestionar múltiples tareas en períodos de tiempo superpuestos, sin necesidad de ejecutarlas en el mismo instante. Piensa en un chef preparando dos platos: pica verduras para el plato A, lo mete al horno y empieza a trabajar en el plato B mientras el A se cocina. Solo hace una cosa a la vez, pero ambos platos avanzan.

En un sistema concurrente, una sola CPU alterna entre tareas. Mientras la tarea #1 espera por E/S, la CPU toma la tarea #2.

gantt
 title Concurrencia — Una sola CPU alternando entre tareas
 dateFormat X
 axisFormat %s

 section CPU
 App #1 :a1, 0, 2
 App #2 :a2, 2, 4
 App #1 :a3, 4, 6
 App #2 :a4, 6, 8
 App #1 :a5, 8, 10

Paralelismo: ejecución simultánea real

Paralelismo significa ejecutar múltiples tareas al mismo tiempo, lo cual requiere múltiples CPUs o núcleos.

gantt
 title Paralelismo — Múltiples CPUs ejecutando simultáneamente
 dateFormat X
 axisFormat %s

 section CPU 1
 App #1 :a1, 0, 10

 section CPU 2
 App #2 :b1, 0, 10

En palabras de Rob Pike (co-creador de Go): “La concurrencia se trata de lidiar con muchas cosas a la vez. El paralelismo se trata de hacer muchas cosas a la vez.”

Note

La concurrencia es un patrón de diseño; el paralelismo es un modelo de ejecución. asyncio logra concurrencia en un solo hilo, sin paralelismo.

Tipos de Multitarea

Existen dos enfoques principales para la multitarea, y entender la diferencia es clave para comprender dónde encaja asyncio.

Multitarea preventiva (Preemptive)

El sistema operativo decide cuándo cambiar entre tareas mediante un mecanismo llamado time slicing: divide el tiempo de CPU en intervalos pequeños y rota entre las tareas activas. Cuando el SO fuerza un cambio, se dice que está haciendo preemption.

En Python, este es el modelo que usan los módulos threading (hilos) y multiprocessing (procesos). La ventaja es que no tienes que pensar en cuándo ceder el control. La desventaja: los cambios pueden ocurrir en cualquier momento, lo que introduce condiciones de carrera y la necesidad de locks.

Multitarea cooperativa (Cooperative)

Las propias tareas deciden cuándo ceder el control. Cada tarea señala explícitamente: “Me pauso aquí, ejecuta otras tareas.” No hay intervención del SO.

Este es exactamente el modelo de asyncio. En Python, la palabra clave await es esa señal explícita:

import asyncio

async def obtener_datos():
 print("Obteniendo datos...")
 await asyncio.sleep(2) # 👈 "Me pauso aquí, ejecuta otras tareas"
 print("Datos obtenidos!")

async def procesar_datos():
 print("Procesando datos...")
 await asyncio.sleep(1) # 👈 Misma señal
 print("Datos procesados!")

async def main():
 await asyncio.gather(obtener_datos(), procesar_datos())

asyncio.run(main())

La ventaja es la predictibilidad: tú controlas exactamente dónde ocurren los cambios. El riesgo: si una tarea olvida hacer await o ejecuta una operación CPU-bound larga sin ceder control, bloquea todo el event loop.

El siguiente diagrama de secuencia ilustra cómo el event loop coordina las tareas cooperativamente:

sequenceDiagram
 participant EL as Event Loop
 participant T1 as obtener_datos()
 participant T2 as procesar_datos()

 EL->>T1: Ejecutar
 T1->>EL: await sleep(2) — cede control
 EL->>T2: Ejecutar
 T2->>EL: await sleep(1) — cede control
 EL->>T2: sleep completado — reanudar
 T2->>EL: Finalizada ✅
 EL->>T1: sleep completado — reanudar
 T1->>EL: Finalizada ✅

Comparación rápida

Preventiva
Cooperativa

Multitarea Preventiva

¿Quién cambia? El Sistema Operativo
Mecanismo: Time slicing
Herramientas en Python: threading, multiprocessing
Riesgo principal: Condiciones de carrera
Ideal para: Cargas CPU-bound o mixtas

Multitarea Cooperativa

¿Quién cambia? La propia tarea
Mecanismo: await / yield
Herramientas en Python: asyncio
Riesgo principal: Bloquear el event loop
Ideal para: Cargas I/O-bound

¿Dónde encaja `asyncio`?

Con todos estos conceptos claros, el siguiente diagrama te ayuda a decidir qué herramienta usar según tu caso:

flowchart TD
 A["¿Qué tipo de operación\nnecesitas optimizar?"] --> B{"¿Es I/O-bound?"}
 B -->|Sí| C{"¿Necesitas manejar\nmuchas conexiones?"}
 C -->|Sí| D["✅ asyncio"]
 C -->|No| E["threading o\nasyncio"]
 B -->|No| F{"¿Es CPU-bound?"}
 F -->|Sí| G{"¿Necesitas compartir\nmemoria entre tareas?"}
 G -->|Sí| H["threading\n+ locks"]
 G -->|No| I["multiprocessing"]
 F -->|Mixto| J["asyncio +\nrun_in_executor()"]

 style D fill:#10b981,stroke:#065f46,color:#fff
 style E fill:#10b981,stroke:#065f46,color:#fff
 style H fill:#f59e0b,stroke:#b45309,color:#fff
 style I fill:#3b82f6,stroke:#1e40af,color:#fff
 style J fill:#8b5cf6,stroke:#5b21b6,color:#fff

En conclusión

asyncio ofrece concurrencia, no paralelismo — todo corre en un solo hilo.
Usa multitarea cooperativa — tu código cede control explícitamente con await.
Destaca en cargas I/O-bound — peticiones de red, operaciones de archivo, consultas a bases de datos.
No es la solución para trabajo CPU-bound — para eso, combínalo con multiprocessing o usa loop.run_in_executor().

Referencias

Skills vs. MCP

Dacadev — Wed, 29 Apr 2026 00:00:00 -0500

Tabla de Contenido

En el mundo de la Inteligencia Artificial, los términos aparecen y se mezclan con una velocidad que a veces marea incluso a los desarrolladores más experimentados. Dos conceptos de estos conceptos son Skills (habilidades) y MCP (Model Context Protocol).

¿Son lo mismo? ¿Vienen los Skills a reemplazar al MCP? En este post vamos a desglosar estas tecnologías para entender que, lejos de competir, están diseñadas para trabajar en capas distintas del ecosistema de agentes.

Note

Este artículo busca aclarar estos dos conceptos, sobre todo para quienes están empezando a construir sus primeros agentes y se enfrentan a esta decisión arquitectónica.

El MCP (Model Context Protocol): el “enchufe” universal

El Model Context Protocol (MCP), impulsado originalmente por Anthropic, es una capa de infraestructura. Su objetivo es estandarizar cómo un LLM se conecta con el mundo exterior: bases de datos, APIs de Google Drive, Slack, GitHub, etc.

Imagina que quieres que tu IA lea tus correos. Antes, tenías que escribir un código específico para conectar esa IA con la API de Gmail. Si luego querías usar otra IA, debías repetir el proceso. El MCP actúa como un puerto USB-C: una vez que un servidor (como Gmail) implementa el protocolo MCP, cualquier cliente (un LLM como Claude o GPT) que hable MCP puede conectarse instantáneamente.

Lo que el MCP resuelve:

Conectividad de datos.
Exposición de herramientas (Tools).
Estandarización de recursos externos.

Tip

Si te suena familiar, es porque el MCP sigue una filosofía similar a la de protocolos como HTTP o LSP (Language Server Protocol). La idea es siempre la misma: estandarizar para no reinventar la rueda en cada integración.

Los Skills: relacionado con el “comportamiento”

Si el MCP es el cable que conecta la computadora a la corriente, un Skill es el programa especializado que corre en esa computadora.

Un Skill es una unidad modular de lógica de ejecución. No se trata solo de “tener acceso a una base de datos”, sino de saber cómo procesar esa información para cumplir un objetivo específico de negocio. Por ejemplo, “Procesar una devolución en un e-commerce” es un Skill. Este Skill puede usar varias herramientas MCP para lograr su fin, pero la “inteligencia” del proceso reside en el Skill.

Lo que los Skills resuelven:

Encapsulación de flujos de trabajo (Workflows).
Definición de “tono de voz” y reglas de negocio.
Orquestación de múltiples herramientas para una tarea compleja.

La analogía del restaurante

Para entenderlo de forma sencilla, imagina un restaurante de alta cocina:

El sistema de pedidos (MCP): Es la infraestructura que permite que la orden llegue de la mesa a la cocina. Es el protocolo que asegura que el camarero y el chef hablen el mismo idioma. No cocina, solo transporta la necesidad y los ingredientes.
El chef especializado (Skill): Es quien tiene el conocimiento para transformar los ingredientes en un plato específico (un “Skill de Repostería” o un “Skill de Parrilla”). El chef usa las herramientas (cuchillos, hornos, que serían las herramientas expuestas vía MCP) siguiendo una técnica específica para entregar un resultado de calidad.

El MCP le da a la IA las “manos” y el “acceso”, mientras que el Skill le da el “entrenamiento” y la “lógica”.

Visualizando la arquitectura

Para los que prefieren ver el flujo de datos, aquí tenemos un diagrama de secuencia que muestra cómo un Skill orquestador utiliza el protocolo MCP para interactuar con el mundo.

sequenceDiagram
 participant U as Usuario
 participant LLM as LLM (Cerebro)
 participant S as Skill (Lógica de Negocio)
 participant MCP as MCP Client / Server
 participant DB as Mundo Exterior (API/DB)

 U->>LLM: "Quiero devolver mi pedido #123"
 LLM->>S: Activa "Skill de Devoluciones"
 S->>S: Valida reglas (¿Está en fecha?, ¿Es premium?)
 Note over S: El Skill decide qué acción tomar
 S->>MCP: Llama a Tool: get_order_details(id: 123)
 MCP->>DB: Consulta a la base de datos
 DB-->>MCP: Retorna datos del pedido
 MCP-->>S: Envía JSON del pedido
 S->>S: Procesa lógica final
 S-->>LLM: Confirmación de proceso exitoso
 LLM-->>U: "Tu devolución ha sido procesada con éxito."

Fíjate en algo importante: el Skill es quien toma decisiones. El MCP solo ejecuta lo que se le pide. Esa diferencia, aunque parezca sutil, es la clave para entender por qué uno no reemplaza al otro.

Cuándo usar uno y cuándo usar el otro

No es una elección de “uno u otro”, sino de en qué parte del problema estás trabajando:

Característica	MCP (Protocolo)	Skill (Habilidad)
Nivel	Bajo / Infraestructura	Alto / Cognitivo
Propósito	Integración y acceso	Ejecución y decisión
Reutilización	Conectar la IA a cualquier API	Aplicar la misma lógica a diferentes IAs
Ejemplo	Conector de base de datos SQL	Procesador de reclamos de clientes

¿Cuándo usar MCP?

Úsalo cuando tu problema es de acceso a la información. Si necesitas que tu IA “vea” archivos locales, consulte una base de datos en tiempo real o use una herramienta externa de forma estandarizada, ahí es donde el MCP brilla.

¿Cuándo usar Skills?

Úsalo cuando tu problema es de comportamiento. Si necesitas definir cómo debe reaccionar tu agente ante un cliente enfadado, cómo debe seguir un protocolo de seguridad o cómo debe estructurar un reporte complejo combinando datos.

Tip

Una buena regla mental: si la respuesta a “¿qué hace falta para resolver esto?” es “que la IA pueda hablar con X sistema”, necesitas MCP. Si la respuesta es “que la IA sepa qué hacer cuando pase Y”, necesitas un Skill.

¿Los Skills reemplazan al MCP?

Definitivamente no. Los Skills se apoyan sobre el MCP. Sin MCP (o una capa de herramientas similar), un Skill sería una lógica “ciega” que no puede tocar el mundo real. Sin Skills, el MCP es solo un montón de cables conectados que no saben qué construir.

En el desarrollo moderno de agentes, el objetivo es construir una librería de Skills que definan la identidad y eficiencia de tu empresa, mientras utilizas el ecosistema MCP para asegurar que esos Skills tengan los mejores datos y herramientas disponibles sin tener que reinventar la rueda de la conectividad.

Conclusión

Skills y MCP no son rivales: son piezas complementarias del mismo rompecabezas. El MCP resuelve el problema de la conectividad universal, dándole a tu agente acceso estandarizado al mundo. Los Skills, por su parte, encapsulan la lógica de negocio y el comportamiento que hacen único a tu agente.

Cuando construyes un agente robusto, lo ideal es pensar en capas: una capa de infraestructura (MCP) que te da acceso a las herramientas, y una capa cognitiva (Skills) que decide qué hacer con esas herramientas. Si dominas esta separación, estarás mucho mejor preparado para construir agentes mantenibles, escalables y alineados con las necesidades reales de tu negocio.

Tipado en Python: Introducción

Dacadev — Fri, 09 Aug 2024 00:00:00 -0500

Tabla de Contenido

Note

Este artículo hace parte de una serie que explicará el tipado en Python, a continuación puedes ver la recopilación de todos los posts de la serie.

Ver serie

¿Por qué es importante el tipado?

Antes de ahondar en el uso de tipos en python, debemos hacer un pequeño énfasis de porque nace la necesidad de implementar “tipado” y análisis estático de código en Python

Info

Escribo tipado entre comillas porque realmente no implementamos tipado en python, sino que simulamos tener tipos en Python, esto lo veremos vas adelante, pero es importante tenerlo en cuenta.

Python, al ser un lenguaje interpretado, significa que el código es leído y ejecutado solamente cuando el interprete pasa por la línea de código, por lo que el error, si existe, solo aparecerá cuando ejecutamos dicha línea de código. Por el contrario en un lenguaje compilado como Go o Java, el código debe primero construido (compilado) y después usado, pero es en el proceso de compilación en donde se realizan validaciones de tipos dentro del código y estas validaciones permiten capturar errores tempranos.

Tipos de errores

En este punto vale la pena agrupar los errores en dos grupos:

Errores de excepción: Son errores que se generan cuando un programa falla al ejecutar una acción determinada, como por ejemplo abrir un archivo que no existe.
Errores de lógica: Son errores que no generan excepción sino que generan un resultado errado al esperado.

Warning

Los errores de lógica son los mas peligrosos ya que al no levantar una excepción normalmente permiten que el flujo de trabajo continue con los errores.

En ese orden de ideas nos centraremos en los errores de lógica ya que son los errores que podemos “capturar” gracias a los tipos, por ejemplo con ayuda de tipos podemos capturar errores tempranos como:

validar el uso de los tipos de datos dentro de nuestro código, por ejemplo si estamos usando un string en un lugar donde deberíamos de usar un entero
validar que los métodos que estamos llamando existan en el objeto que estamos usando
validar que los atributos que estamos usando en un objeto existan
validar que los argumentos que estamos pasando a una función sean los correctos

Veamos la forma tradicional de validar y capturar errores de tipos en Python. Para ello debemos de implementar una serie sentencias en nuestro código para asegurarnos que estamos usando los tipos correctos. esto puede afectar la legibilidad del código y la productividad, e incluso el rendimiento de nuestros programas en algunos casos.

def clean_text(a):
 assert isinstance(a, str), "Input must be a string"
 # process a

def calculate_sum(*nums):
 sum = 0

 for num in nums:
 if not isinstance(num, (int, float)):
 raise ValueError("Input must be a number")

 sum += num

 return sum

En el caso de clean_text estamos validando que el argumento a sea un string, en caso de que no sea un string, levantamos una excepción. En el caso de calculate_sum estamos validando que los argumentos que estamos pasando sean int o float, en caso de que no sea alguno de estos, levantamos una excepción.

Info

En el caso clean_text estamos usando assert para validar el tipo de dato, sin embargo assert no es recomendado para validar tipos de datos, ya que se puede desactivar en tiempo de ejecución, por lo que no es una buena práctica usarlo como captura de errores en código, sin embargo es probable que lo encuentres en tu día a día como desarrollador.

Si miramos a profundidad el código no esta mal, sino que estamos agregando lógica adicional que esta afectando la legibilidad del código, y un de los principales objetivos que tenemos como programadores es escribir código limpio y legible. para los demás o tu yo del futuro. Imagina si hicieramos esto en códigos mas complejos y extensos.

Note

La siguiente entrega de esta seria aborda el tema de como implementar tipado en Python, y como podemos mejorar la legibilidad del código y la productividad. para verla da click en el siguiente botón.

Tipado básico en Python

Tipado en Python: Serie de DacaDev

Dacadev — Thu, 08 Aug 2024 00:00:00 -0500

Python, al ser un lenguaje interpretado y dinámicamente tipado, no incluye de forma nativa la gestión y manejo de tipos. Esta característica es extremadamente útil y práctica, especialmente para quienes están comenzando en el mundo del desarrollo de software.

Sin embargo, a medida que los proyectos crecen, esta ventaja inicial puede convertirse en un desafío. La ausencia de un sistema de tipos explícito puede complicar la lectura del código, dificultar la depuración de errores y limitar la escalabilidad del proyecto.

Por esta razón, ha surgido la iniciativa de implementar tipado en Python. Con esta herramienta, los desarrolladores pueden tener un mayor control sobre los tipos de datos en su código, lo que permite capturar errores tempranos y mejorar la calidad del software desde las primeras etapas del desarrollo.

En DacaDev, hemos creado una serie de artículos que explican de manera detallada el tipado en Python. A continuación, puedes acceder a cada uno de los artículos de la serie:

Constantes en Go y conceptos clave

Dacadev — Sun, 09 Jun 2024 00:00:00 -0500

Tabla de Contenido

Note

En el siguiente artículo aprenderás conceptos clave para entender el funcionamiento de las constantes en Go y algunos conceptos de su funcionamiento que te ayudarán a escribir mejor código.

Constantes en Go

una constante es un valor que no cambia en el tiempo y que puede ser referenciado para efectuar operaciones en un programa. Algo particular de Go es que las constantes solo existen en tiempo de compilación. Como sabrás, Go es un lenguaje de programación compilado, por lo que para obtener el código final del programa debemos construirlo. Es aquí donde las constantes son transformadas en valores literales dentro del programa.

Esto implica que durante la ejecución del código, las constantes no son alojadas en un espacio de memoria como ocurre con otros lenguajes como JavaScript, sino que son valores quemados en el binario final. Esto optimiza el rendimiento del programa y evita que se alojen valores en memoria que no son necesarios.

Declaración de constantes

En Go, la forma de declarar constantes es muy simple y similar a otros lenguajes de programación. Tenemos varias maneras de hacerlo. Veamos cada uno de los casos:

Note

Las constantes en Go solo pueden hacer referencia a tipos de dato built-in del lenguaje.

// single constant
const miConstante = 1

// multi-assignment in one line
const a, b, c = 1, 2, 3

// multi-assignment in block
const (
	anotherConstant = 1
	stringConstant = "Hello, World!"
	finalConstant = true
)

Conceptos clave de las Constantes

Kind vs Type

En Go, las constantes pueden ser de dos tipos, conocidos como kind y type. La principal diferencia es que en una constante de tipo kind no se necesita especificar el tipo de dato que se está utilizando, mientras que en una constante de tipo type sí es necesario especificarlo. Esto lo podemos observar en el siguiente ejemplo:

// kind
const name = "John"
const a = 10

// type
const c int64 = 10
const d float32 = 10

La principal ventaja del uso de kind vs type se ve en tiempo de compilación. Este comportamiento se definirá en base al tipo de constante usado:

kind: El compilador hará un análisis para determinar cuál es el tipo de dato más óptimo para efectuar la operación definida.
type: El compilador no hará ninguna inferencia o análisis sobre cuál debe ser la operación a realizar, sino que siempre usará el mismo tipo de valor (tipo) en la constante.

Esto es importante porque, recuerda, Go no convierte valores automáticamente. Si vas a usar la constante para operar con otros tipos de datos, deberás efectuar la transformación requerida explícitamente.

Veamos algunos ejemplos con constantes de tipo kind:

package main

import "fmt"

func main() {
	const age = 20
	var bigNumber int32 = 1000
	agePlusNumber := age + bigNumber

	fmt.Printf("El resultado es: %d\n", agePlusNumber)
	fmt.Println("El tipo de dato de cada variable es:")
	fmt.Printf("age: %T\n", age)
	fmt.Printf("bigNumber: %T\n", bigNumber)
	fmt.Printf("agePlusNumber: %T\n", agePlusNumber)
}

El resultado del anterior ejemplo es:

[Running] go run "/home/dacacode/dacadev/test/tempCodeRunnerFile.go"
El resultado es: 1020
El tipo de dato de cada variable es:
age: int
bigNumber: int32
agePlusNumber: int32

Como puedes observar, el tipo de age es int, mientras que el de bigNumber y agePlusNumber es int32, debido a que el compilador define cuál es el tipo más óptimo.

Ahora veamos el mismo caso usando constantes de tipo type:

package main

import "fmt"

func main() {
	const age int8 = 20
	var bigNumber int32 = 1000
	agePlusNumber := age + bigNumber

	fmt.Printf("El resultado es: %d\n", agePlusNumber)
	fmt.Println("El tipo de dato de cada variable es:")
	fmt.Printf("age: %T\n", age)
	fmt.Printf("bigNumber: %T\n", bigNumber)
	fmt.Printf("agePlusNumber: %T\n", agePlusNumber)
}

El código no se podrá compilar e incluso el IDE nos debería mostrar un error ya que Go nos dirá que la operación enter un tipo de dato y otro no esta permitido, el erro deberá lucir como el siguiente:

Pseudo-enumerados

Una funcionalidad que podemos aprovechar de las constantes y tipos definidos por el usuario es la creación de lo que podemos denominar pseudo-enumerados. En Go no disponemos de una estructura de datos de tipo Enum. sin embargo, podemos emularlas (ojo, no es que sean Enums en la práctica, pero pueden cumplir funciones similares).

La creación de estos enumerados es sencilla y consiste en definir un tipo de dato personalizado y posteriormente declarar las constantes con este tipo de dato. Para entenderlo mejor, veamos un ejemplo:

type UserPermissions int

const (
	Admin UserPermissions = 1
	Read UserPermissions = 2
	Write UserPermissions = 3
)

func validateUserPermissions(permissions UserPermissions) bool {
	// hacer algo con el código
}

En el ejemplo podemos ver que al crear el tipo UserPermissions y luego constantes de este mismo tipo, estamos usando una constante de tipo type. De esta manera podríamos controlar y exportar estas constantes del paquete. Sin embargo, no olvides que es una emulación de enumeración.

iota

Quiero hacer énfasis en la declaración de las constantes en el bloque del anterior ejemplo. En ellas podemos observar el uso de un valor numérico secuencial, es decir, que empieza desde 0, 1, 2, … Esto es importante porque Go nos ofrece una forma rápida y sencilla de realizar este mismo proceso de manera automática. Para ello tenemos el concepto de iota, que nos permite declarar la secuencia de constantes en bloque empezando desde cero.

Veamos algunos ejemplos:

const (
 A = iota // 0
 B // 1
 C // 2
)

func main() {
 fmt.Println(A, B, C) // 0 1 2
}

En el ejemplo anterior, podemos observar que estamos declarando las constantes A, B, y C y estas tendrán el valor de 0, 1 y 2 respectivamente. Lo que debemos destacar es el uso de la sintaxis iota. Si ejecutamos el código, veremos el siguiente resultado:

[Running] go run "/home/dacacode/dacadev/test/main.go"
0 1 2

De igual manera, podemos agregar operadores al valor de iota, siempre teniendo claro que el valor inicia en cero y es incremental de a 1 unidad. Veamos unos ejemplos:

const (
 KB = 1 << (10 * iota) // 1 << (10*0) = 1
 MB // 1 << (10*1) = 1024
 GB // 1 << (10*2) = 1048576
 TB // 1 << (10*3) = 1073741824
)

const (
 A = iota // 0
 B // 1
 C // 2
)

const (
 D = iota // 0
 E // 1
 F // 2
)

También podemos saltarnos los valores secuenciales de iota si estos no fueran necesarios empleando el caracter _ para ignorar el valor. Veamos un ejemplo:

const (
 _ = iota // Ignora el valor 0
 One // 1
 Two // 2
 Three // 3
 _ // Ignora el valor 4
 Five // 5
 Ten = iota * 2 // 6 * 2 = 12
 Eleven // 7 * 2 = 14
)

Con el concepto de iota ya claro, podemos facilitar la escritura de pseudo-enumeraciones de la siguiente manera:

type UserPermissions int

const (
	Admin UserPermissions = iota + 1 // 1
	Read UserPermissions // 2
	Write UserPermissions // 3
)

func validateUserPermissions(permissions UserPermissions) bool {
	// hacer algo con el código
}

Note

El término proviene de la letra griega ι (iota), que es la novena letra del alfabeto griego. Históricamente, la letra iota se usa en matemáticas y lógica para representar el elemento más pequeño en un conjunto o una secuencia, lo cual es apropiado dada su función en Go.

MicroPython: Manejo de pines

Dacadev — Wed, 08 May 2024 09:00:00 +0000

Tabla de Contenido

Note

En este artículo aprenderás que es la clase Pin de Micropython 🐍 y como esta gestiona las diferentes funcionalidades genéricas de los pines de cualquier tipo de chip. Además, verás ejemplos de cómo configurarla y usarla con la RP2040.

¿Qué es la clase `Pin`?

Empecemos definiendo qué es un pin dentro de nuestro microcontrolador (uM), un pin hace referencia a una interfaz I/O asociada a un pin físico de nuestro uM. Con él podemos interactuar con el mundo real, ya sea leyendo o escribiendo señales digitales, o incluso analógicas.

La clase Pin es una de las principales clases que provee Micropython 🐍, ya que es la que nos permitirá interactuar con los pines de nuestros uM. Esta clase se encuentra en el paquete machine.

Instancia de la Clase `Pin`

La clase Pin, tiene la siguiente firma de constructor

class Pin(id, mode=-1, pull=-1, *, value=None, drive=0, alt=-1)

En donde:

controla cuál será el comportamiento del pin. En Micropython 🐍 encuentras constantes que te ayudan a establecer el funcionamiento:

id es el unico parámetro obligatorio y hace referencia al pin que quieres controlar. Cada uM tiene su propio mapeo de pines, por lo que deberás de consultar la documentación de tu uM para saber que pines puedes controlar.
mode* controla cuál será el comportamiento del pin. En *Micropython 🐍* encuentras constantes que te ayudan a establecer el funcionamiento:
- Pin.IN establece el pin como entrada.
- Pin.OUT establece el pin como salida.
- Pin.OPEN_DRAIN establece el pin como salida de tipo Open-drain (colector abierto), lo que significa que, si la salida está en nivel bajo, es un cero lógico, y si está en alto (1), se configura como alta impedancia.
- Pin.ALT establece el pin para funcionar de manera alterna, utilizando un propósito específico del hardware.
- Pin.ALT_OPEN_DRAIN es la combinación de Pin.ALT y Pin.OPEN_DRAIN
- Pin.ANALOG establece el pin como entrada analógica
pull* activas o no la opción de usar una resistencia de pull-up o pull-down, sus opciones validas son:
- Pin.PULL_UP
- Pin.PULL_DOWN
- None = No se activa ninguna resistencia, es el valor por defecto
value es el valor inicial que quieres asignar al pin y solo funciona cuando el pin es configurado como salida, es decir que Pin.OUT o Pin.OPEN_DRAIN
drive se utiliza para especificar la fuerza de la salida del pin. Esto es importante cuando conectas el pin a circuitos que tienen diferentes requerimientos de corriente. Los valores típicos para drive son algo así como Pin.DRIVE_0, Pin.DRIVE_1, etc., donde los números más altos representan una mayor capacidad de corriente de salida.
alt* cuando el pin está configurado como Pin.ALT o Pin.ALT_OPEN_DRAIN, este parámetro se utiliza para especificar la función alternativa que se desea utilizar.

Note

* No todos los pines tiene disponibles todas las configuraciones descritas, para validarlo debes de consultar la documentación de tu uM

Métodos de la Clase `Pin`

Pin.init

Pin.init(mode=-1, pull=-1, *, value=None, drive=0, alt=-1)

Una vez tengas una instancia de la clase Pin, puedes cambiar su configuración inicial usando el método init el cual recibe los mismos atributos del constructor salvo el identificador id. Un ejemplo de su uso sería

from machine import Pin

led = Pin(25)
led.init(mode=Pin.OUT, value=True)

En el ejemplo anterior, estoy creando una instancia asociada al pin 25 (mapeado de mi uM) y posteriormente configurándolo con el método init

Pin.value

Pin.value([x])

Este método se utiliza para leer o escribir el valor del pin. Si no se pasa ningún parámetro, el método se comporta como un lector. Si se pasa un valor, el método se comporta como un escritor. Un ejemplo de su uso sería

from machine import Pin

led = Pin(25, Pin.OUT)
led.value(1)

print(led.value())

En el ejemplo, estamos creando un pin como salida y configurando su valor a 1, para luego leer el valor del pin.

Pin.on()

Este método es un atajo para configurar el valor del pin a 1, es decir, que el pin se configura en alto, lo cual sería lo mismo que hacer:

Pin.value(1)

Pin.off()

Este método es un atajo para configurar el valor del pin a 0, es decir, que el pin se configura en bajo, lo cual sería lo mismo que hacer:

Pin.value(0)

Pin.toggle()

Este método es un atajo para cambiar el valor del pin. Si el pin está en 1, lo cambia a 0 y viceversa, lo cual sería lo mismo que hacer:

Pin.value(not Pin.value())

Pin.irq()

Pin.irq(handler=None, trigger=Pin.IRQ_FALLING | Pin.IRQ_RISING, *, priority=1, wake=None, hard=False)¶

Este método es muy importante, ya que sirve para configurar los pines para que sean asociados a interrupciones y poder ejecutar un callback cuando se cumpla una condición. Los parámetros que recibe son:

handler: Es un callable de python, es decir, una función o método de clase que recibe como parámetro únicamente un objeto de tipo Pin, que será la instancia del pin que activó la interrupción.
trigger: A través de este atributo controlaremos el tipo de comportamiento que se deberá cumplir para activar la interrupción. Para entender los posibles valores que podemos asignar, veamos primero cómo es una señal digital.Una señal digital oscila entre dos valores, 0 o 1, y la transición entre esos valores es lo que llamamos flancos. Como hay dos valores, tenemos 2 tipos de flancos. Los flancos de subida ocurren cuando cambiamos de 0 a 1 y los flancos de bajada cuando cambiamos de 1 a 0. De esta manera, en Micropython encontramos 4 tipos de activadores que podemos configurar en nuestra interrupción por pin:
- Pin.IRQ_FALLING: Configura la interrupción para que se active cuando el pin cambie de 1 a 0
- Pin.IRQ_RISING: Configura la interrupción para que se active cuando el pin cambie de 0 a 1
- Pin.IRQ_LOW_LEVEL: Configura la interrupción para que se active cuando el pin se encuentre en 0
- Pin.IRQ_HIGH_LEVEL: Configura la interrupción para que se active cuando el pin se encuentre en 1
En el siguiente diagrama puedes visualizar las fases de la señal:

Note

En el siguiente artículo te explico más del tema de interrupciones con Micropython 🐍.

Ejemplos prácticos de `Pin` con RP2040

En el siguiente embebido estamos creando un proyecto en la plataforma Wokwi, que nos permite simular proyectos con tarjetas como Arduino Uno, ESP32, Raspberry Pi Pico, entre otras, junto con un amplio conjunto de sensores y actuadores. En este caso, estamos utilizando una Raspberry Pi Pico y conjunto de LEDs y botones para mostrar cómo se puede controlar un pin con la clase Pin de Micropython 🐍

En el ejemplo podemos ver 4 casos de uso sencillos para la clase Pin

Caso 1: Configuramos un pin como salida y lo encendemos en la función main en un intervalo de 500ms con la fuinción sleep
Caso 2: Declaramos un pin como salida, pero primero instanciamos la clase Pin y luego configuramos el pin con el método init.
Case 3: Configuramos dos pines con la clase Pin, uno como salida y otro como entrada. Leemos el valor del pin de entrada y lo asignamos al pin de salida
Caso 4: Configuramos un pin como entrada y configuramos una interrupción para que se active cuando el pin cambie de 0 a 1. En el callback simplemente cambiamos el valor del pin de salida.

Note

En el siguiente enlace puedes ver el código fuente del proyecto en una nueva pestaña.
El caso 4 de nuestro proyecto funciona con interrupciones, y es posible que en la simulación no funcione correctamente debido a que no se está procesando el debounce del botón.

Info

Podrás encontrar toda la documentación de la clase Pin para micropython 🐍 en el siguiente link

Patrones de Diseño: Decorador

Dacadev — Wed, 21 Feb 2024 21:25:17 +0000

Tabla de Contenido

Objetivo del patrón decorador

Note

El patrón decorador agrega dinamismo a la extensión de funcionalidades.

El objetivo del patrón decorador es crear una clase abstracta, la cual usaremos para crear (a través de herencia) los objetos base. Los decoradores serán clases especiales que extienden las funcionalidades de la clase abstracta, agregando un campo que contendrá una instancia de la clase abstracta, o en su defecto, un hijo de la misma.

Veamos un ejemplo de cómo los decoradores pueden funcionar. Supongamos que estamos creando una aplicación para llevar el control de costos de bebidas, donde el costo de estas bebidas depende de los ingredientes adicionales que le añadamos, como por ejemplo, chocolate rallado, crema, etc.

Ejemplo de uso

Ahora, supongamos que tenemos una clase base café a la cual queremos agregar dos ingredientes nuevos: chocolate y crema chantilly. Gráficamente, se vería algo como

De este ejemplo, podemos ver que para calcular el costo total de la bebida debemos sumar el valor de costo de cada uno de los decoradores o de las clases decoradoras. Para ello, la clase base debe tener la capacidad de identificar si tiene un hijo para retornar su valor de costo por defecto y así encadenar la suma.

Antes de pasar al código de implementación, veamos algunas características que debemos tener en cuenta para este patrón.

Características del patrón decorador

El decorador debe tener el mismo supertipo que el objeto que están decorando; es decir, ambas clases, la clase decoradora y la que se está decorando, deben heredar de la misma clase.
Puedes usar uno o más decoradores para encapsular un objeto, lo que significa que no hay límite en la cantidad de objetos decoradores que se utilicen sobre un objeto.
Cuando se le da el mismo supertipo al decorado y a la clase que está decorando, podemos pasar dicho elemento decorado en lugar del objeto original encapsulado.
El decorador agrega su propio comportamiento antes o después de que el objeto decorado realice su trabajo.
Los objetos pueden ser decorados en cualquier momento, lo que permite que sean decorados de manera dinámica en tiempo de ejecución.

Note

🚀 El patrón decorador adiciona responsabilidades de manera dinámica a un objeto, ofreciendo flexibilidad y una alternativa al uso de subclases.

Implementación del ejemplo en código

Teoría

Para la implementación de nuestro ejemplo, veamos como funcionaría el diagrama de clases

classDiagram
 class Component {
 methodA()
 methodB()
 otherMethods()
 }
 class ConcreteComponent {
 methodA()
 methodB()
 }
 class Decorator {
 WrappedObj Component
 methodA()
 methodB()
 otherMethods()
 }
 class ConcreteDecoratorA {
 WrappedObj Component
 methodA()
 methodB()
 otherMethods()
 }
 class ConcreteDecoratorB {
 WrappedObj Component
 methodA()
 methodB()
 otherMethods()
 }
 Component <|-- ConcreteComponent
 Component <|-- Decorator
 Decorator <|-- ConcreteDecoratorA
 Decorator <|-- ConcreteDecoratorB

Tendremos una clase base (nuestra clase abstracta) que en el diagrama se llama Component. De esta clase creamos dos clases: una es la clase ConcreteComponent, que es la que usaremos para instanciar nuestros objetos, y otra clase llamada Decorator, que es la que usaremos para crear todos los decoradores que podemos usar con nuestro objeto ConcreteComponent.

Decorator es una clase abstracta que será usada para crear nuestros decoradores específicos. Esta clase definirá los métodos y demás lógica que debe ser implementada para que otras clases sean decoradores válidos.

Ejemplo

Aplicando el anterior esquema a un ejemplo, podemos suponer que queremos crear tipos de bebidas que varían su combinación

classDiagram
 class Beverage {
 -description
 +getDescription()
 +cost()
 }
 class Coffee {
 +cost()
 }
 class Decaf {
 +cost()
 }
 class HouseBlend {
 +cost()
 }
 class IngredientDecorator {
 -beverage Beverage
 +getDescription()
 }
 class Milk {
 +cost()
 +getDescription()
 }
 class Mocha {
 +cost()
 +getDescription()
 }
 class Soy {
 +cost()
 +getDescription()
 }
 class Chantilly {
 +cost()
 +getDescription()
 }
 class Chocolate {
 +cost()
 +getDescription()
 }
 Beverage <|-- Coffee
 Beverage <|-- Decaf
 Beverage <|-- HouseBlend
 Beverage <|-- IngredientDecorator
 IngredientDecorator <|-- Milk
 IngredientDecorator <|-- Mocha
 IngredientDecorator <|-- Soy
 IngredientDecorator <|-- Chantilly
 IngredientDecorator <|-- Chocolate

La implementación del anterior diagrama se haría de la siguiente manera (en Python) empezaremos por la implementación de las clases abstractas

from abc import ABC


class Beverage(ABC):
 def cost(self) -> float:
 pass

 def description(self) -> str:
 pass


class IngredientDecorator(ABC):
 def __init__(self, beverage: Beverage):
 self.beverage = beverage

 def cost(self) -> float:
 pass

 def description(self) -> str:
 pass

Ahora haciendo uso de nuestras clases abstractas, podemos crear nuestros objetos y decoradores concretos, nuestros objetos lucirían de la siguiente forma:

from abc_classes import Beverage


class Coffee(Beverage):
 def cost(self) -> float:
 return 1.99

 def description(self) -> str:
 return "Coffee"


class Decaf(Beverage):
 def cost(self) -> float:
 return 1.25

 def description(self) -> str:
 return "Decaf"


class HouseBlend(Beverage):
 def cost(self) -> float:
 return 0.89

 def description(self) -> str:
 return "House Blend"

y nuestros decoradores

from abc_classes import IngredientDecorator


class Milk(IngredientDecorator):
 def cost(self) -> float:
 return self.beverage.cost() + 0.10

 def description(self) -> str:
 return self.beverage.description() + ", Milk"


class Mocha(IngredientDecorator):
 def cost(self) -> float:
 return self.beverage.cost() + 0.20

 def description(self) -> str:
 return self.beverage.description() + ", Mocha"


class Soy(IngredientDecorator):
 def cost(self) -> float:
 return self.beverage.cost() + 0.15

 def description(self) -> str:
 return self.beverage.description() + ", Soy"


class Chantilly(IngredientDecorator):
 def cost(self) -> float:
 return self.beverage.cost() + 0.25

 def description(self) -> str:
 return self.beverage.description() + ", Chantilly"


class Chocolate(IngredientDecorator):
 def cost(self) -> float:
 return self.beverage.cost() + 0.30

 def description(self) -> str:
 return self.beverage.description() + ", Chocolate"

y su uso dentro de nuestro código sería

from concrete_classes import Coffee, Decaf, HouseBlend
from decorators import Milk, Mocha, Soy, Chantilly, Chocolate

if __name__ == "__main__":

 chocolate_blend = Chantilly(Chocolate(HouseBlend()))
 soy_decaf = Soy(Decaf())
 moccachino = Mocha(Chocolate(Milk(Coffee())))

 print(chocolate_blend.cost())
 print(chocolate_blend.description())

 print(soy_decaf.cost())
 print(soy_decaf.description())

 print(moccachino.cost())
 print(moccachino.description())

cuando ejecutemos este código podremos ver que en nuestro resultado obtendremos

1.44
House Blend, Chocolate, Chantilly
1.4
Decaf, Soy
2.59
Coffee, Milk, Chocolate, Mocha

Consideraciones del patrón decorador

la herencia es una forma de extensión, pero no necesariamente la mejor forma de alcanzar la flexibilidad de nuestros diseños
En nuestros diseños debemos de habilitar la extensión de nuevos comportamientos evitando la modificación del código actual
la composición y la delegación pueden ser usados para agregar nuevos comportamientos en tiempo de ejecución
El patrón decorador provee una alternativa al uso de subclases para extender el comportamiento
El patrón decorador involucra el uso de clases decoradores que son usadas para encapsular componentes del mismo tipo en concreto
Las clases decoradoras tienen el mismo tipo de la clase que decoran o encapsulan
Los decoradores agregan nuevos comportamientos antes o después de que el objeto encapsulado realiza su trabajo
Los decoradores normalmente son transparentes al cliente del componente
Los decoradores pueden resultar en muchos objetos pequeños en nuestros diseños y el sobre uso del mismo puede derbar en crear código complejo y difícil de mantener

Patrones de Diseño: Observador

Dacadev — Mon, 08 Jan 2024 01:25:17 +0000

Tabla de Contenido

Note

El patrón observador define una relación uno-a-muchos entre objetos: cuando un objeto cambia de estado, todos sus dependientes son notificados automáticamente.

Teoría

El patrón observador es muy útil cuando se desea actualizar diversos objetos en función de los cambios en otros, siendo ampliamente implementado en frameworks frontend como React o Vue.

Este patrón se basa en dos partes clave: los publishers u observables, que son los objetos emisores de valores, y los suscriptores, conocidos como observadores o subscribers. Estos últimos reciben los valores emitidos por los publishers.

Note

Publishers + Suscribers = Observer Pattern

La esencia de este patrón es permitir que un publisher emita eventos a sus subscribers, teniendo además la capacidad de agregar o eliminar suscriptores de sus listas.

Veamos gráficamente cómo funciona este patrón.

En el caso 1, observamos un Objeto Publisher emitiendo valores constantemente, compartidos con todos los Suscribers registrados en su lista. En este ejemplo, no hay suscriptores.

En el caso 2, dos objetos están suscritos al objeto Publisher, recibiendo el valor emitido en el momento de su emisión.

Note

El patrón Observer permite relacionar objetos de manera comprensible, eficiente y mantenible. Es una relación One-to-Many.

Implementación

Implementaremos el patrón observer en Python definiendo dos clases abstractas: Publisher y Subscriber. Luego, crearemos clases derivadas que emitan valores (Publisher) y que se registren para recibir datos (Subscribers).

Comenzamos con las clases abstractas:

from abc import ABC, abstractmethod

class Suscriber(ABC):
 def __init__(self):
 pass

 @abstractmethod
 def update(self, value) -> None:
 raise NotImplementedError("You must implement this method")

class Publisher(ABC):
 def __init__(self):
 self.subscribers: list[Suscriber] = list()

 def add_suscriber(self, subscriber: Suscriber):
 self.subscribers.append(subscriber)

 def remove_suscriber(self, suscriber: Suscriber):
 self.subscribers.remove(suscriber)

 def notify_suscribers(self, value):
 for suscriber in self.subscribers:

En este código, definimos dos clases:

Subscriber: Representa a los suscriptores o observadores, exigiendo la implementación del método update, que recibe el dato actualizado.
Publisher: Define tres métodos clave: - add_subscriber: Registra un nuevo suscriptor. - remove_subscriber: Elimina un suscriptor específico. - notify_subscribers: Actualiza el valor a todos los suscriptores.

Note

Este código es una guía sobre cómo funciona el patrón y puede mejorarse según las necesidades de cada proyecto.

Ahora, implementemos este patrón en un ejemplo práctico: un sistema de IoT en casa que mide la radiación ultravioleta. Queremos compartir estos datos con dos sistemas: uno que almacena información para la protección infantil contra los rayos UV y otro para un sistema de riego basado en estas mediciones.

Implementaremos tres clases:

UVSolarSystem (Publisher)
UVTracker (Suscriber)
UVPlantTracker (Suscriber)

class UVSolarSystem(Publisher):

 def emit_value(self):
 value = randint(0, 100)
 self.notify_suscribers(value)

class UVTracker(Suscriber):

 def update(self, value) -> None:
 print(f"UVTracker: {value}")
 print("Doing funny stuff with this value :D")

class UVPlantTracker (Suscriber):

 def update(self, value) -> None:
 print(f"UVPlantTracker: {value}")
 print("Doing funny stuff for the plants with this value :D")

En el código, el método emit_value en UVSolarSystem es personalizado y utiliza notify_subscribers. Las clases Subscriber implementan el método update.

Probemos el código:

print("Stage 1".center(50, "="))
# define the publisher
solar_system = UVSolarSystem()

solar_system.emit_value()

print("Stage 2".center(50, "="))
# first suscriber
uv_tracker = UVTracker()

solar_system.add_suscriber(uv_tracker)
solar_system.emit_value()

print("Stage 3".center(50, "="))
# second suscriber
uv_plant_tracker = UVPlantTracker()

solar_system.add_suscriber(uv_plant_tracker)
solar_system.emit_value()

print("Stage 4".center(50, "="))
# remove the first suscriber
solar_system.remove_suscriber(uv_tracker)

La salida sería

>>> $ python main.py
=====================Stage 1======================
=====================Stage 2======================
UVTracker: 2
Doing funny stuff with this value :D
=====================Stage 3======================
UVTracker: 79
Doing funny stuff with this value :D
UVPlantTracker: 79
Doing funny stuff for the plants with this value :D
=====================Stage 4======================
UVPlantTracker: 73

Podemos mejorar el Publisher inicial agregando la posibilidad de retener el último valor emitido. Esto permite a los suscriptores acceder al valor cuando lo necesiten. El cambio en la clase Publisher sería:

class PublisherImprove(ABC):
 def __init__(self) -> None:
 self.subscribers: list[Suscriber] = list()
 self._value = None

 def add_suscriber(self, subscriber: Suscriber):
 self.subscribers.append(subscriber)

 def remove_suscriber(self, suscriber: Suscriber):
 self.subscribers.remove(suscriber)

 def notify_suscribers(self):
 for suscriber in self.subscribers:
 suscriber.update(self._value)

 @property
 def get_value(self):
 return self._value

Agregamos el getter get_value para acceder al valor actual del Publisher, alojado como atributo privado self._value.

Consideraciones del patrón observador

Define una relación one-to-many entre objetos.
Los observables actualizan a los observadores a través de una interfaz común.
Cualquier observador puede participar si cumple con la interfaz común.
Los observadores deben estar desacoplados del observable.
Es posible acceder a los datos del observable cuando sea necesario, en vez de esperar cada evento.

Patrones de Diseño: Estrategia

Dacadev — Thu, 28 Dec 2023 01:25:17 +0000

Tabla de Contenido

Note

El patrón estrategia define una familia de algoritmos intercambiables, encapsulando cada uno de ellos para que puedan ser usados de manera flexible en tiempo de ejecución.

Este patrón consiste en definir/identificar un conjunto de comportamientos comunes de un objeto y encapsular dichos comportamientos como una familia de algoritmos que, por definición, serán comunes entre ellos. De esta manera, si un objeto hace uso de dichos comportamientos, cada uno de ellos sería reemplazable por alguno de la misma familia.

Apliquemos el concepto agnóstico y posteriormente lo aplicaremos en código.

Supongamos que queremos crear un conjunto de clases que estén relacionadas con aves. Cada una de nuestras aves tendrá la capacidad de volar. Para aplicar el patrón estrategia, debemos identificar primero cuáles son esos comportamientos comunes que tienen nuestro conjunto de clases (Aves), para lo cual sería el método de volar, y vamos a encapsular este tipo de comportamiento. Esta idea se ilustra en el siguiente diagrama:

classDiagram
 class Ave {
 +volar()
 }
 class NoVolar {
 ejecutarVuelo()
 }
 class SiVolar {
 ejecutarVuelo()
 }
 ComportamientoVolar <|-- NoVolar
 ComportamientoVolar <|-- SiVolar
 class ComportamientoVolar {
 +ejecutarVuelo()
 }
 Ave <|-- Pato
 Ave <|-- Gallina
 Ave --|> ComportamientoVolar

Para este proceso optaremos por definir las clases abstractas de Aves y del comportamiento de volar, de esta manera podemos crear nuestras diversas clases y estas podrán emplear cualquiera de las clases que implementen la clase base de comportamientoVolar.

Este código implementado en Python se vería de la siguiente manera:

from abc import ABC, abstractclassmethod

# Clases abstractas
class FlightBehavior(ABC):
 def __init__(self):
 pass

 @abstractclassmethod
 def execute_fly(self):
 pass

class Bird(ABC):
 def __init__(self, flys_behavior: FlightBehavior):
 self.flys_behavior = flys_behavior

 def fly(self):
 self.flys_behavior.execute_fly()

# Cómo utilizarlo
# 1. Definir las clases que implementan las clases abstractas

# Estrategias
class NoFly(FlightBehavior):
 def __init__(self):
 super().__init__()

 def execute_fly(self):
 print("I can't fly")

class Fly(FlightBehavior):
 def __init__(self):
 super().__init__()

 def execute_fly(self):
 print("I can fly")

# Clases que implementan la estrategia
class Hen(Bird):
 def __init__(self, flys_behavior: FlightBehavior):
 super().__init__(flys_behavior=flys_behavior)

class Duck(Bird):
 def __init__(self, flys_behavior: FlightBehavior):
 super().__init__(flys_behavior=flys_behavior)

# 2. Crear los objetos
if __name__ == '__main__':
 hen = Hen(NoFly())
 hen.fly()

 duck = Duck(Fly())
 duck.fly()

Este patrón es útil en situaciones en las que tienes una clase que tiene varios comportamientos y quieres que el comportamiento se seleccione en tiempo de ejecución, según las necesidades de tu aplicación. Por ejemplo, puedes tener una clase que realiza operaciones matemáticas y quieres poder cambiar la operación que realiza en tiempo de ejecución, según las necesidades de la aplicación.

Tip

El patrón estrategia es ideal cuando tienes múltiples algoritmos para una tarea y necesitas cambiar entre ellos de forma dinámica. Piensa en sistemas de pago, algoritmos de ordenamiento o validaciones configurables.

A continuación, un ejemplo de Python de este caso de cambio de estrategia en tiempo de ejecución:

from abc import ABC, abstractmethod

class Context:
 def __init__(self, strategy: 'Strategy') -> None:
 self._strategy = strategy

 def execute_strategy(self, x: int, y: int) -> int:
 return self._strategy.execute(x, y)

class Strategy(ABC):
 @abstractmethod
 def execute(self, x: int, y: int) -> int:
 pass

class AddStrategy(Strategy):
 def execute(self, x: int, y: int) -> int:
 return x + y

class SubtractStrategy(Strategy):
 def execute(self, x: int, y: int) -> int:
 return x - y

# Uso de las clases
context = Context(AddStrategy())
print(context.execute_strategy(10, 5)) # Salida: 15

context = Context(SubtractStrategy())
print(context.execute_strategy(10, 5)) # Salida: 5

Patrones de diseño: Qué son?

Dacadev — Sat, 02 Dec 2023 00:29:10 +0000

Tabla de Contenido

Los patrones de diseño, en general, se pueden definir como soluciones estandarizadas a problemas comunes en el diseño de software. No son fragmentos de código específicos, sino más bien guías o plantillas que se pueden aplicar en diversos contextos de programación.

Estos patrones son especialmente útiles porque permiten reutilizar conocimientos y enfoques que han sido probados y perfeccionados a lo largo de los años, y proporcionan un punto de partida para tus proyectos de software.

Note

Los patrones de diseño son guías que pueden ser adaptadas para cada propósito específico según se requiera.

Los patrones de diseño se dividen en tres categorías principales:

Patrones Creacionales: Estos patrones se relacionan con los procesos de creación de objetos. Su objetivo es abstraer los detalles de la instanciación de clases, haciendo los sistemas más independientes de cómo sus objetos son creados y representados. Dentro de esta categoría encontramos los patrones:
- Singleton
- Factory Method
- Abstract Factory
- Builder
- Prototype.
Patrones Estructurales: Estos patrones se enfocan en cómo las clases y objetos se componen para formar estructuras más grandes. Los patrones estructurales facilitan el diseño al identificar formas sencillas de realizar relaciones entre entidades. Dentro de esta categoría encontramos los patrones:
- Adapter
- Bridge
- Composite
- Decorator
- Facade
- Flyweight
- Proxy.
Patrones de Comportamiento: Estos patrones se centran en la comunicación entre objetos. Son útiles para definir patrones de comunicación entre clases y objetos, haciéndolos más flexibles y eficientes. Encontraremos patrones como:
- Observer [más info]
- Mediator
- Iterator
- Strategy [más info]
- Command
- State
- Visitor.

Cada patrón tiene su propio conjunto de reglas y contextos donde es más adecuado. Lo importante es entender que no existe un patrón que sea mejor que los otros en todas las situaciones.

Principios de diseño

Antes de adentrarte en los patrones de diseño, es buena idea tener unas bases y conceptos iniciales que te ayudarán al momento de estudiar cada uno de los patrones. Estos principios son:

Identifica los aspectos de tu aplicación que pueden cambiar y sepáralos de aquellos que probablemente seguirán igual.
Programa para una interfaz, no para una implementación. Programar para interfaces significa programar para supertipos.
Prefiere la composición sobre la herencia en OO. Es decir, si debes escoger entre una u otra, es más flexible y fácil implementar la composición, ya que esta se define a través de interfaces.
Esfuérzate por lograr diseños con acoplamientos débiles entre objetos que interactúan. Es decir, disminuye al máximo la dependencia entre los objetos de tu aplicación.
Las clases deben ser abiertas a código nuevo y cerradas a la modificación del mismo. Es decir, se debe evitar modificar lo existente siempre que sea posible.
Depende de abstracciones, no de clases concretas. Es decir, no utilices una clase como dependencia de otra; en su lugar, usa una clase abstracta o una interfaz

Qué No Hacer al Usar Patrones de Diseño

Al momento de estudiar y trabajar con los patrones de diseño, es importante tener en cuenta los siguientes puntos:

Conocer las bases de Orientación a Objetos (OO) no te hace un buen diseñador de OO.
Un buen diseño de OO es reutilizable, extensible y mantenible a lo largo del tiempo.
Los patrones te muestran cómo construir buenos sistemas usando cualidades de OO.
Los patrones son experiencias probadas orientadas a objetos.
Los patrones no te dan código; ellos te dan una solución general a problemas de diseño. Tu objetivo como programador e ingeniero de Software es aplicarlos y adaptarlos a tus casos específicos.
Los patrones no son inventados, son descubiertos. Tú podrías encontrar otro a lo largo de tu carrera.
La mayoría de los patrones y principios son capaces de manejar el constante cambio en el software, permitiéndote adaptar tu código a nuevos requerimientos sin grandes refactorizaciones.

Tip

No intentes aplicar todos los patrones de una vez. Empieza por entender el problema que resuelve cada uno y úsalos cuando el contexto lo requiera. La sobreingeniería es tan perjudicial como la falta de diseño.

Código Limpio: Escribe nombres significativos

Dacadev — Thu, 14 Sep 2023 02:18:24 +0000

Tabla de Contenido

Al momento de escribir código, una tarea difícil de la que nadie habla es el hecho de nombrar nuestras variables, funciones, clases, etc. Y si no lo sientes así, déjame contarte por qué es algo a lo que deberías prestarle atención 😉.

Te voy a compartir algunos consejos que te ayudarán a la hora de definir dichos nombres y el porqué es buena práctica. Dentro de estos consejos encontramos…

Note

🚀 El contenido de este post está basado en las enseñanzas del libro “Código Limpio” y lo que he aprendido a lo largo de mi carrera como programador.

Nombres significativos

Los nombres deben transmitir claramente cuál es el propósito del código, es decir, que con el hecho de leer la variable o función, se debe entender qué contiene.

// Incorrecto
const a: string[] = [];

// Correcto
const users: string[] = [];

En el ejemplo anterior podemos ver que en la primera parte estamos definiendo nombres aleatorios para nuestro código lo cual no nos dice nada y en dado caso debemos leer más a fondo el código para entender qué es lo que hace, mientras que en la segunda parte podemos ver claramente que la variable será un arreglo de usuarios.

Transmitir el propósito del código

Los nombres deben transmitir claramente cuál es la intención o uso del código. Por ejemplo, en el siguiente ejemplo podemos ver que en la primera parte el nombre no nos dice nada sobre lo que hace la función, mientras que en la segunda parte podemos ver que el nombre nos dice claramente que dicha función escribirá Hello World.

// Incorrecto
function foo(): void {
 console.log("Hello World");
}

// Correcto
function printHelloWorld(): void {
 console.log("Hello World");
}

Note

🚀 Incluso podemos mejorar el nombre de la función printHelloWorld a printHelloWorldToConsole para ser más explícitos.

Sé explícito y puntual

Los nombres que des dentro de tu código deben ser explícitos, esto significa que deben ser claros al transmitir información, esto ya lo mencioné, pero no caigas en hacerlo en exceso. Observa el siguiente ejemplo.

// Incorrecto
const usersStringNameArray: string[] = ["John", "Mary", "Sam"];

// Correcto
const userNames: string[] = ["John", "Mary", "Sam"];

En el ejemplo observamos que estamos repitiendo información que ya nos brinda el tipado, como por ejemplo nombrar que es un arreglo de strings, lo que termina siendo redundante ya que el tipo de dato está implícito en el tipado string[].

Variables similares

Habrá casos en donde tengas variables cuyo comportamiento es similar o que hagan referencia a un mismo valor y puede ser difícil nombrarlas. Usa nombres que realmente distingan la funcionalidad de dicha variable y cuál es su objetivo, como en el siguiente código:

// Incorrecto
function copyChars(a1: string[], a2: string[]): void {
 for (let i = 0; i < a1.length; i++) {
 a2[i] = a1[i];
 }
}

// Correcto
function copyChars(source: string[], destination: string[]): void {
 for (let i = 0; i < source.length; i++) {
 destination[i] = source[i];
 }
}

Para el ejemplo anterior, podemos observar que el uso de source y destination en lugar de a1 y a2 transmite claramente la funcionalidad de cada variable a pesar de ser similares.

Nombres pronunciables

Usa nombres que sean pronunciables y que estén relacionados con el lenguaje que se esté usando al momento de escribir código. De esta manera, al leer el código no tendrás que hacer mapas mentales de los nombres.

Nombres fáciles de buscar

En concordancia con el punto anterior, además de tener nombres pronunciables, también piensa en que sean fáciles de buscar dentro del código o incluso dentro del proyecto.

Intenta evitar el uso de variables sencillas como a, además de que no transmiten nada, encontrarlas es difícil. ¿Cuántas palabras no tienen una ‘a’? 🙃

Note

🚀 Solo en casos en donde la variable se use una vez en códigos pequeños, como ciclos for, podemos optar por usar variables simples como e.

for (let j: number = 0; j < 34; j++) {
 s += (t[j] * 4) / 5;
}

No permitas los mapas mentales

Cuando nos referimos a mapas mentales del código, estamos pensando en los demás (inclusive en tu yo del futuro). Cuando estás leyendo código y empiezas a crear mapas en tu cabeza con las relaciones de cada nombre de variable, función, etc., estás agregando una tarea adicional e innecesaria porque en sí tienes que entender el código y ahora tener ese mapa de nombres en la cabeza. ¿Imagínate si tienes muchas variables o nombres?

Para evitar esto, no uses nombres simples como i, j (muy común en ciclos for) o r para decir url o response. Simplemente coloca el nombre que corresponde.

Nombres en las clases

Además de los consejos ya presentados, en las clases debemos tener en cuenta también otros casos para escribir código entendible y mantenible. Ten en cuenta estas consideraciones:

Las clases deben tener nombres sustantivos y NO verbales o de acciones. Un sustantivo es una palabra que se utiliza para nombrar personas, animales, cosas, lugares o ideas.
Los métodos de las clases deben tener nombres que hagan referencia a verbos o frases verbales, como postPayment, deletePage o save.
Los accesores, mutadores, getters o setters deben ser nombrados según su valor y llevar el prefijo get/set e is.
Define una forma de nombrar las acciones y aférrate a ella. Por ejemplo, si usas get, no uses fetch en otros. De esta manera mantienes la consistencia a través del código y/o proyecto.

Teoría · DacaCode

RAG: Pipeline de Indexación con Chunking, Embeddings y FAISS

Carga de datos

Segmentación en chunks

Métodos de chunking

Conversión a embeddings

Cómo se mide la similitud

Almacenamiento en una base de datos vectorial

Pipeline completo

Verificación rápida

Conclusión y próximos pasos

Arquitectura de un RAG: Indexing y Retrieval Pipeline

Los dos pipelines de un sistema RAG

El indexing pipeline

El retrieval pipeline

Arquitectura completa

Evaluación

Conclusión y próximos pasos

RAG: Qué es y Cómo Funciona Retrieval Augmented Generation

Las limitaciones estructurales de los LLMs

Alucinaciones

Conocimiento con fecha de corte

Ausencia de conocimiento privado

Alternativas antes de llegar a RAG

Agentes

Fine-tuning

Qué es un RAG (Retrieval Augmented Generation)

Cómo funciona un RAG a alto nivel

Ventajas de adoptar un RAG

Patrones de Diseño: Factory

Simple Factory

Factory Method

Abstract Factory

Factory Method vs Abstract Factory

Static Factory

Principio de Inversión de Dependencias

Consideraciones

Continúa la serie

TypeScript: Tipos avanzados, subtipos y varianza

Subtipos

Supertipos

La jerarquía de tipos

Los tipos especiales: null, undefined, void y never

Varianza

Conclusión

TypeScript: Tipos básicos y el sistema de tipos

Por qué importan los tipos: un ejemplo concreto

any: la puerta de escape del sistema de tipos

unknown: la alternativa segura a any

boolean

number y bigint

string

symbol

Objetos

Alias de tipo

Tipos unión e intersección

Arreglos

Tuplas

Conclusión

Estilos CSS: Selectores, combinadores y pseudo-clases

Selectores básicos

Combinadores

Selectores compuestos

Pseudo-clases

Posición estructural

Estado e interacción

Campos de formulario

Pseudo-elementos

Selectores de atributo

Conclusión

Estilos CSS: Cascada, especificidad, herencia y unidades

La cascada: cómo el navegador resuelve conflictos

Origen de los estilos

Especificidad: el peso de un selector

Orden del código: el último en hablar gana

Herencia: propiedades que viajan hacia abajo

Título heredado

Valores especiales: inherit e initial

Unidades absolutas vs. relativas

em: relativo al elemento

Valores especiales: `inherit` e `initial`

`em`: relativo al elemento

`rem`: relativo a la raíz

`calc()` para combinar unidades

Números sin unidad y `line-height`