Inteligencia Artificial · 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.

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!

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!

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.

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.

GitHub Copilot: Beneficios, Desventajas y Precauciones

Dacadev — Mon, 27 May 2024 00:00:00 -0500

Tabla de Contenido

Note

Este artículo nace como una iniciativa para centralizar el conocimiento que he adquirido en el manejo de la herramienta de GitHub Copilot gracias a su uso diario, cursos y consejos que he encontrado en diversos recursos.

La herramienta la puedes encontrar en el siguiente enlace: GitHub Copilot

GitHub Copilot es una herramienta de inteligencia artificial que nos ofrece toda la potencia de los modelos de lenguaje a gran escala (LLM, por sus siglas en inglés) enfocada específicamente en el campo del desarrollo de software y programación. Es una herramienta que ha revolucionado la manera de escribir código y aún tiene mucho más por aportar. Veamos algunas de sus funcionalidades y beneficios, así como desventajas y riesgos de usar esta herramienta.

¿Qué es GitHub Copilot?

Mi definición de lo que es Copilot sería:

GitHub Copilot es una herramienta de programación de pair programming que extiende las habilidades de los desarrolladores permitiendo enfocarse en el diseño, delegando la “carpintería” al copiloto.

Adicionalmente, si queremos ser un poco más técnicos al respecto y definir qué es Copilot técnicamente, debemos decir que Copilot trabaja sobre las mismas bases de los LLMs como ChatGPT, con la salvedad de que fue afinado para que su enfoque sea 100% en la escritura de código.

Los datos usados para ajustar el modelo que alimenta a GitHub Copilot fueron todos los repositorios públicos que se encuentran en GitHub, siendo esta la plataforma más usada para alojar proyectos alrededor del mundo. Esto significa que el conjunto de datos de entrenamiento es inmenso y muy completo.

Por último, como Copilot está basado en la tecnología de los LLMs, en general lo que busca es predecir, a partir de probabilidades, cuál sería el código que seguiría a medida que vas escribiendo.

¿Debo preocuparme por el manejo de datos?

Una de las principales dudas al momento de usar Copilot, incluso podría pensar que la primera duda, es ¿Copilot usará mis datos y mi código para futuras sugerencias? o en palabras más simples ¿Copilot va a robar mi código?

La respuesta es un NO rotundo. Copilot no usará tu código o el código generado con la herramienta para reentrenar el modelo, ya que, como mencioné antes, esta herramienta solo es entrenada con datos públicos que se obtienen de los repositorios públicos de GitHub.

Además, el código generado a partir de Copilot no es alojado para realizar una futura realimentación del modelo, por lo que puedes estar seguro de la privacidad de tu código y de tu negocio a fin de cuentas.

Note

En este punto debo mencionar algo y es la propiedad intelectual. Puede que Copilot no respete la propiedad intelectual si esta es en un repositorio público, por lo que si quieres tener este tipo de protección y a la vez tener un código abierto, es mejor asesorarte.

¿Cuáles son los alcances de Copilot?

Como mencionamos antes, Copilot es tu compañero de programación en pareja, esto significa que te ayudará a escribir código brindando sugerencias durante la escritura del mismo, pero aquí puede surgir una pregunta muy importante: ¿Puede Copilot ayudarme sin importar el lenguaje?

La respuesta a esta pregunta es ambigua, sí y no. Es un sí porque recuerda que el modelo fue entrenado usando todo el código público alojado en GitHub, y entre estos encontramos una diversidad inmensa de lenguajes, frameworks, estilos, prácticas, etc. Sin embargo, también debemos tener en cuenta que los lenguajes más populares como JavaScript o Python son los que más proyectos tienen alojados en GitHub, lo que significa que el modelo aprendió más de estos lenguajes, haciéndolo mucho más eficiente para estos tipos de lenguajes o frameworks.

Si intentas utilizar Copilot con algún lenguaje que no es tan popular como COBOL, es posible que Copilot no haga un muy buen trabajo, pero lo intentará.

Tip

Si tienes miedo de que la IA te pueda arrebatar el trabajo, tiene sentido buscar aquello en lo que la IA no es realmente buena… ¿aún? Esto es solo una opinión que podría ser una buena discusión, ¿qué opinas?

¿Es acertado Copilot en sus predicciones?

Esta es una pregunta que muchas personas se hacen, sin importar el nivel de experiencia que tengan, y volviendo a retomar la idea de antes, sus predicciones mejorarán a medida que sea usado para escribir código de lenguajes o contextos populares, ya que tendrá más conocimiento de dónde echar mano.

Dado lo anterior, es MUY IMPORTANTE que tú, como desarrollador, supervises siempre el resultado de Copilot. No importa qué tan sencillo o simple sea, hazlo como una nueva práctica para el uso de esta herramienta ya que Copilot solo predice, no piensa realmente… ¿aún? 🤔

Aquí quiero hacer un énfasis que es mandatorio, y es el de la supervisión. Tu responsabilidad como programador es supervisar el resultado de Copilot, y esto se puede hacer eficientemente solamente si:

Conoces la tecnología, lenguaje, frameworks, etc. que Copilot te está ayudando a construir.
Entiendes lo que estás construyendo y el propósito, la lógica de negocio.
Entiendes a nivel macro el impacto de tu trabajo, Copilot te ayudará con lo micro.

Tip

Debes ser siempre consciente de lo que estás construyendo, siempre recuérdalo porque con el uso de Copilot es fácil caer en la tentación de dejar pasar algunas cosas.

Beneficios de usar Copilot

Hablemos ahora de cuáles son los beneficios de usar Copilot. ¡Hay muchos!

Incrementa la productividad, ya que no gastarás tiempo escribiendo y reescribiendo código, sobre todo si son piezas pequeñas pero tediosas.
Reduce los errores en el código, aunque debamos supervisar el resultado de Copilot, este siempre nos ayudará a reducir errores comunes como los typos o referencias mal realizadas.
Permite tener una gran diversidad de código, ya que puedes pedirle a Copilot que te dé no solo una, sino más sugerencias, permitiéndonos ahondar en múltiples estilos o diseños de código.
Soporta múltiples lenguajes, con mejor rendimiento en unos más que en otros.
Te permite aprender y desarrollar al mismo tiempo. Cuando Copilot te ayuda a escribir código, puede implementar técnicas o ideas nuevas para ti y te permitirá aprender de ellas. Para ello, debes ser consciente y supervisar el resultado, no confíes 100% en su respuesta. Valida en la documentación o en recursos de confianza.
Copilot se ajustará a tu tipo de código. A medida que lo uses, entenderá cuál es el estilo de código en base a lo ya escrito en el proyecto. Tú lo orientas en base a cómo escribas código. Esto significa que si cambias de proyecto y este tiene otras reglas, Copilot se adaptará. Él no aprende de ti.

Precauciones y desventajas de Copilot

Su precisión es variable dependiendo del contexto del prompt y del mismo código que tienes en ese archivo. Esto depende del tiempo de trabajo en el proyecto con Copilot, los archivos abiertos y el código de referencia.
Riesgos de seguridad potenciales. Debes supervisar el resultado, sobre todo si trabajas con partes sensibles del código como SQL, ORMs, código de lógica de negocio, etc. Valida el código que propone Copilot y, si no lo conocías, valida su uso en la documentación o un recurso de confianza.
Depender demasiado de la herramienta. Para que esto no suceda, debes conocer bien la tecnología, lenguaje y sistema que estás construyendo, para tener el criterio y confianza de que lo que estás haciendo lo podrías hacer sin ayuda de Copilot.
Una “desventaja” es que tiene un costo, no tiene opción de uso gratuito o similar, y es más costoso a medida que se implementa en organizaciones. Esto, en algunos casos como personas/empresas que están empezando, puede ser un valor difícil de asumir. Debes tener claro el valor que agrega en el equipo y ese gasto adicional incluirlo en tus cuentas.
Límite en el contexto de la herramienta. Esta es una desventaja de los LLMs en general y, aunque es algo que está en constante mejora, es muy difícil (por lo menos hasta ahora) incluir todo un proyecto en el contexto de un LLM y adicionalmente compartir qué es lo que se busca hacer. Por lo que para tareas muy grandes con un código fuente enorme, tiende a no ser tan preciso.

Conclusión

GitHub Copilot ha revolucionado la forma en que los desarrolladores escriben código, ofreciendo beneficios significativos como el aumento de la productividad y la reducción de errores. Sin embargo, es crucial supervisar sus sugerencias y estar consciente de sus limitaciones y riesgos. A medida que la tecnología avanza, Copilot seguirá mejorando, pero siempre será necesario el criterio humano para garantizar la calidad y la seguridad del código.

Info

Este artículo se actualiza periódicamente conforme evolucionan las funcionalidades de GitHub Copilot. Si tienes experiencias o consejos adicionales, no dudes en compartirlos a través de la página de contacto.