Por Año
La era del desarrollador de bases de datos agentivo: novedades de Microsoft SQL en Build 2026
Transformando el desarrollo de bases de datos con agentes de IA
El desarrollo de bases de datos ha seguido un flujo de trabajo predecible durante décadas: diseñar esquemas, escribir consultas, optimizar el rendimiento y, finalmente, implementar. Sin embargo, en Build 2026, Microsoft presentó un cambio de paradigma: la introducción de capacidades agentivas en Microsoft SQL Server y Azure SQL. Estas capacidades, impulsadas por inteligencia artificial, prometen revolucionar la forma en que los desarrolladores interactúan con sus bases de datos.
¿Qué significa “agentivo” en el contexto de SQL?
Un agente en el ecosistema de Microsoft es una entidad impulsada por IA que puede interpretar intenciones, gestionar contexto y ejecutar tareas complejas de manera autónoma o semiautónoma. En el caso de SQL, esto implica que los desarrolladores ya no necesitan preocuparse por ciertos aspectos manuales del desarrollo, como la optimización de consultas, la generación de esquemas o incluso la integración con herramientas externas.
Note: Este enfoque no elimina la necesidad de habilidades técnicas avanzadas, sino que amplifica la productividad del desarrollador al reducir la fricción en tareas repetitivas o altamente técnicas.
Principales anuncios de Microsoft SQL en Build 2026
Microsoft destacó varias características clave que integran agentes de IA en el flujo de trabajo de desarrollo de bases de datos. Aquí exploramos las más relevantes:
1. Generación de esquemas basada en intención
Con la nueva funcionalidad de generación de esquemas, los desarrolladores pueden describir en lenguaje natural los requisitos de su base de datos, y un agente de IA generará automáticamente el esquema correspondiente. Por ejemplo:
# Ejemplo de interacción con el agente mediante el SDK de Azure OpenAI
from azure.ai.openai import OpenAIClient
client = OpenAIClient(endpoint="https://<tu-endpoint>.openai.azure.com", api_key="<tu-api-key>")
prompt = """
Quiero un esquema para una base de datos de e-commerce que incluya tablas para usuarios, productos, pedidos y detalles de pedidos.
"""
response = client.completions.create(
engine="text-davinci-003",
prompt=prompt,
max_tokens=500
)
print(response.choices[0].text)
El resultado sería un esquema en SQL que incluye las tablas necesarias, relaciones y restricciones.
Warning: Aunque los agentes son precisos, siempre revisa los esquemas generados antes de implementarlos en producción.
2. Optimización automática de consultas
Los agentes ahora pueden analizar consultas SQL y sugerir optimizaciones basadas en patrones de acceso y estadísticas de uso. Por ejemplo, si una consulta es ineficiente debido a la falta de índices, el agente puede recomendar o incluso crear los índices necesarios.
-- Consulta original
SELECT *
FROM Orders
WHERE OrderDate > '2026-01-01';
-- Sugerencia del agente
CREATE INDEX idx_orderdate ON Orders(OrderDate);
-- Consulta optimizada
SELECT *
FROM Orders WITH (INDEX(idx_orderdate))
WHERE OrderDate > '2026-01-01';
Esta capacidad está disponible tanto en SQL Server como en Azure SQL Database, y se puede habilitar mediante el portal de Azure o el CLI.
3. Integración con herramientas de análisis y visualización
Los agentes también pueden actuar como intermediarios entre SQL y herramientas de análisis como Power BI. Por ejemplo, un agente puede traducir consultas complejas en visualizaciones listas para usar, eliminando la necesidad de escribir código DAX o T-SQL adicional.
Note: Esta funcionalidad es particularmente útil en escenarios de BI donde los usuarios finales necesitan acceso rápido a datos procesables.
Casos de uso prácticos
Desarrollo ágil con agentes
Imagina que estás desarrollando una aplicación SaaS y necesitas iterar rápidamente sobre el diseño de la base de datos. Con las capacidades agentivas, puedes describir tus cambios en lenguaje natural y dejar que el agente actualice el esquema y las migraciones necesarias.
# Generar migraciones automáticamente con el CLI de Azure SQL
az sql db migration create \
--name "AddCustomerFeedback" \
--description "Añade una tabla para almacenar comentarios de clientes" \
--output json
Optimización de cargas de trabajo en tiempo real
En escenarios de alta demanda, como comercio electrónico o servicios financieros, los agentes pueden identificar cuellos de botella en tiempo real y aplicar optimizaciones sin intervención manual.
Relación con otros avances en IA
Este enfoque agentivo en SQL no es un caso aislado. Microsoft ha estado integrando capacidades similares en otros productos, como Azure AI Search y Foundry IQ. Para entender mejor el contexto, revisa estos artículos relacionados:
- Actualizaciones en la recuperación agentiva de Azure AI Search: Fuentes de conocimiento y síntesis de respuestas
- Construyendo Agentes Inteligentes con Microsoft Foundry IQ en Microsoft AI
- Nota de Transparencia para Azure Agent Service: Fundamentos y Ejemplos Prácticos
Reflexión final
La introducción de capacidades agentivas en Microsoft SQL marca un antes y un después en el desarrollo de bases de datos. Al reducir la complejidad técnica y permitir a los desarrolladores centrarse en tareas de mayor valor, estos avances no solo mejoran la productividad, sino que también democratizan el acceso a herramientas avanzadas de gestión y análisis de datos.
Warning: Aunque las capacidades agentivas son poderosas, no sustituyen el conocimiento profundo de bases de datos. Los desarrolladores deben seguir perfeccionando sus habilidades para aprovechar al máximo estas herramientas.
¿Ya estás explorando estas capacidades en tus proyectos? Comparte tus experiencias en los comentarios.
Protegiendo la cultura del gaming: Desafíos y soluciones en la nube
Introducción a la seguridad en plataformas de gaming
El gaming no es solo entretenimiento; es una industria global que conecta culturas, comunidades y economías. Sin embargo, esta conectividad también la convierte en un objetivo atractivo para actores maliciosos. Desde ataques DDoS a plataformas de streaming hasta el robo de datos personales de jugadores, los riesgos son tan variados como los juegos mismos.
En este artículo, exploraremos cómo proteger plataformas de gaming utilizando servicios en la nube como Azure, con un enfoque en estrategias de seguridad, mitigación de amenazas y ejemplos prácticos para arquitectos y desarrolladores cloud.
Principales desafíos de seguridad en el gaming
1. Ataques DDoS en tiempo real
Los ataques de denegación de servicio distribuidos (DDoS) son una amenaza constante para las plataformas de gaming en línea. Un solo ataque puede desconectar servidores, interrumpir torneos y causar pérdidas económicas significativas.
Note: Azure DDoS Protection Standard es una solución robusta para mitigar estos ataques, diseñada específicamente para aplicaciones de misión crítica.
Ejemplo práctico: Configuración de protección DDoS en Azure
# Habilitar DDoS Protection Standard en una red virtual existente
az network vnet update \
--name gaming-vnet \
--resource-group gaming-rg \
--ddos-protection true \
--ddos-protection-plan /subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.Network/ddosProtectionPlans/{ddos-plan-name}
En este ejemplo, se asocia un plan de protección DDoS a una red virtual, asegurando que todos los recursos conectados estén protegidos.
2. Seguridad de identidad y acceso
Los sistemas de autenticación débiles son una puerta abierta para el robo de cuentas de usuario, lo que puede derivar en fraudes y pérdida de confianza en la plataforma.
Azure Active Directory (Azure AD) ofrece autenticación multifactor (MFA) y detección de riesgos basada en inteligencia artificial para proteger identidades.
Related: Aprende más sobre la seguridad de identidad en nuestro artículo Cuatro prioridades para la seguridad de identidad y acceso en redes impulsada por IA en 2026.
Ejemplo práctico: Implementación de MFA en Azure AD
# Requerir MFA para todos los usuarios de un grupo específico
az ad group create --display-name "GamingAdmins" --mail-nickname "GamingAdmins"
az ad conditional-access policy create \
--name "RequireMFAForAdmins" \
--state "enabled" \
--conditions '{"users":{"includeGroups":["GamingAdmins"]}}' \
--grant-controls '{"operator":"OR","builtInControls":["mfa"]}'
Este script asegura que todos los usuarios del grupo “GamingAdmins” deban autenticarse mediante MFA antes de acceder a recursos críticos.
Estrategias avanzadas: Protegiendo comunidades globales
1. Detección de fraudes con IA
El fraude en plataformas de gaming puede incluir desde trampas en juegos competitivos hasta transacciones fraudulentas en marketplaces. Azure AI y servicios como Azure Machine Learning permiten construir modelos personalizados para detectar patrones anómalos.
Ejemplo práctico: Entrenamiento de un modelo de detección de fraudes
from azureml.core import Workspace, Dataset
from azureml.train.automl import AutoMLConfig
# Conectar al workspace de Azure ML
ws = Workspace.from_config()
# Cargar datos de transacciones
dataset = Dataset.get_by_name(ws, name="gaming-transactions")
# Configurar AutoML para clasificación
automl_config = AutoMLConfig(
task="classification",
training_data=dataset,
label_column_name="is_fraud",
primary_metric="accuracy",
compute_target="gpu-cluster"
)
# Iniciar el experimento
experiment = Experiment(ws, "fraud-detection")
run = experiment.submit(automl_config)
Este ejemplo utiliza Azure Machine Learning para entrenar un modelo que identifica transacciones fraudulentas en tiempo real.
2. Protección contra phishing avanzado
Los kits de phishing como Tycoon2FA aprovechan técnicas avanzadas para atacar a jugadores y administradores de plataformas. La implementación de soluciones como Microsoft Defender for Cloud puede ayudar a detectar y neutralizar estas amenazas.
Related: Descubre cómo operan estos kits en nuestro análisis Inside Tycoon2FA: Cómo operaba un kit de phishing AiTM a gran escala.
Arquitectura recomendada: Gaming seguro en Azure
Componentes clave
- Azure Front Door: Para distribuir el tráfico globalmente y proteger contra ataques de capa 7.
- Azure DDoS Protection: Mitigación automática contra ataques volumétricos.
- Azure Sentinel: Monitoreo proactivo de amenazas con análisis de seguridad.
- Azure Key Vault: Gestión segura de claves y secretos.
Diagrama de arquitectura
Note: Este diseño es escalable y puede adaptarse a diferentes tamaños de plataformas de gaming.
Conclusión
Proteger la cultura del gaming requiere un enfoque integral que combine tecnologías avanzadas, estrategias de mitigación y un compromiso continuo con la seguridad. Azure ofrece un conjunto completo de herramientas para abordar estos desafíos, desde la protección contra DDoS hasta la detección de fraudes con IA.
Para profundizar en temas relacionados, te recomendamos explorar nuestro artículo sobre Generative AI con Large Language Models en C# para 2026.
Optimización de la gestión de políticas Git a escala en Azure DevOps
Introducción a la gestión de políticas Git en Azure DevOps
La gestión de políticas Git es un componente crítico para mantener la calidad del código y garantizar la seguridad en entornos de desarrollo colaborativo. En Azure DevOps, estas políticas permiten configurar reglas como revisiones obligatorias, validación de builds y restricciones de merge. Sin embargo, manejar estas políticas a escala puede ser un desafío técnico, especialmente en repositorios grandes o con múltiples equipos trabajando simultáneamente.
Recientemente, Azure DevOps introdujo una mejora en su API REST que optimiza significativamente la gestión de políticas Git. En este artículo exploraremos cómo esta mejora reduce el uso de CPU y acelera la ejecución de estas políticas, con ejemplos prácticos para implementarla en tus proyectos.
La mejora en la API REST: ¿Qué cambió?
Anteriormente, la API REST de Azure DevOps requería múltiples llamadas para obtener y aplicar políticas Git a un conjunto de repositorios. Esto generaba una alta carga en el servidor y tiempos de ejecución prolongados. La nueva mejora introduce un modelo optimizado que permite realizar operaciones en lote, reduciendo la cantidad de llamadas y mejorando la eficiencia.
Note: Según los datos proporcionados por el equipo de Azure DevOps, esta mejora reduce el uso de CPU en un 50% y acelera la ejecución entre 10 y 15 veces.
Endpoints optimizados
El endpoint principal afectado por esta mejora es el relacionado con las políticas de repositorio (/policy/configurations). Ahora permite realizar operaciones en lote, lo que simplifica la gestión de políticas para múltiples repositorios.
Ejemplo de uso del endpoint optimizado
curl -X POST \
-H "Content-Type: application/json" \
-H "Authorization: Bearer <token>" \
https://dev.azure.com/<organization>/<project>/_apis/policy/configurations?api-version=7.0 \
-d '{
"policyType": {
"id": "fa4e907d-c16b-4a4c-9dfa-4906e5d171dd"
},
"settings": {
"minimumApproverCount": 2,
"creatorVoteCounts": false
},
"scope": [
{
"repositoryId": "<repo-id>",
"refName": "refs/heads/main",
"matchKind": "exact"
}
]
}'
Warning: Asegúrate de usar la versión correcta de la API (
api-version=7.0) para aprovechar esta funcionalidad. Versiones anteriores no soportan operaciones en lote.
Beneficios clave de la optimización
1. Reducción del uso de CPU
La disminución en el uso de CPU es especialmente relevante para organizaciones con cientos de repositorios. Al reducir la cantidad de llamadas individuales, se minimiza la carga en los servidores de Azure DevOps y se mejora la experiencia del usuario.
2. Ejecución más rápida
La capacidad de realizar operaciones en lote reduce los tiempos de espera, permitiendo que las políticas se apliquen en segundos en lugar de minutos. Esto es crucial para pipelines de CI/CD que dependen de validaciones rápidas.
3. Escalabilidad mejorada
Con esta mejora, las organizaciones pueden gestionar políticas Git de manera eficiente incluso en proyectos de gran escala, sin comprometer el rendimiento.
Implementación práctica: Gestión de políticas a escala
Escenario: Aplicar políticas a múltiples repositorios
Imagina que necesitas configurar una política de aprobación mínima para todos los repositorios de un proyecto. Con el modelo anterior, tendrías que realizar una llamada API por cada repositorio. Ahora, puedes hacerlo en una sola operación.
Código Python para aplicar políticas en lote
import requests
# Configuración
organization = "<organization>"
project = "<project>"
token = "<personal-access-token>"
api_url = f"https://dev.azure.com/{organization}/{project}/_apis/policy/configurations?api-version=7.0"
# Datos de la política
policy_data = {
"policyType": {
"id": "fa4e907d-c16b-4a4c-9dfa-4906e5d171dd"
},
"settings": {
"minimumApproverCount": 2,
"creatorVoteCounts": False
},
"scope": [
{
"repositoryId": "<repo-id-1>",
"refName": "refs/heads/main",
"matchKind": "exact"
},
{
"repositoryId": "<repo-id-2>",
"refName": "refs/heads/main",
"matchKind": "exact"
}
]
}
# Llamada API
headers = {
"Content-Type": "application/json",
"Authorization": f"Bearer {token}"
}
response = requests.post(api_url, json=policy_data, headers=headers)
if response.status_code == 200:
print("Políticas aplicadas exitosamente.")
else:
print(f"Error: {response.status_code} - {response.text}")
Note: Este ejemplo utiliza la biblioteca
requestsde Python para interactuar con la API REST. Puedes adaptarlo según tus necesidades.
Consideraciones de seguridad
Aunque esta mejora simplifica la gestión de políticas, es importante mantener buenas prácticas de seguridad:
- Tokens de acceso: Usa tokens personales con permisos mínimos necesarios para realizar las operaciones.
- Auditoría: Habilita el registro de auditoría en Azure DevOps para monitorear cambios en las políticas.
- Validación: Antes de aplicar políticas en lote, valida que los repositorios y ramas especificados sean correctos.
Related: Aprende más sobre cómo proteger identidades y accesos en redes impulsadas por IA en nuestro artículo Cuatro prioridades para la seguridad de identidad y acceso en redes impulsada por IA en 2026.
Conclusión
La optimización de la API REST de Azure DevOps representa un avance significativo en la gestión de políticas Git a escala. Con una reducción del uso de CPU y tiempos de ejecución más rápidos, las organizaciones pueden gestionar sus repositorios de manera eficiente y segura. Aprovecha esta mejora para simplificar tus flujos de trabajo y garantizar la calidad del código en tus proyectos.
Related: Descubre cómo Azure DevOps protege contra amenazas emergentes en nuestro artículo Inside Tycoon2FA: Cómo operaba un kit de phishing AiTM a gran escala.
Dominando el monitoreo en Microsoft Fabric Data Warehouse
Introducción al monitoreo en Microsoft Fabric Data Warehouse
Los entornos modernos de análisis de datos no solo exigen consultas rápidas, sino también una observabilidad integral. Microsoft Fabric Data Warehouse (DW) ofrece herramientas avanzadas para monitorear el rendimiento, la utilización de recursos y la calidad de los datos. Este artículo explora los conceptos fundamentales del monitoreo en Fabric DW y proporciona ejemplos prácticos para ayudarte a implementar una estrategia efectiva.
Note: Este artículo asume que tienes experiencia previa con Microsoft Fabric y conceptos básicos de almacenamiento de datos.
¿Por qué es crítico el monitoreo en Fabric DW?
El monitoreo eficaz permite identificar cuellos de botella, optimizar costos y garantizar la confiabilidad de las operaciones. En Microsoft Fabric DW, el monitoreo se centra en tres áreas clave:
- Rendimiento de consultas: Identificar consultas lentas o ineficientes.
- Utilización de recursos: Supervisar el uso de CPU, memoria y almacenamiento.
- Calidad de datos: Detectar anomalías o problemas en los datos cargados.
Cada una de estas áreas requiere herramientas específicas y un enfoque proactivo para garantizar que tu sistema funcione de manera óptima.
Herramientas de monitoreo en Microsoft Fabric DW
Microsoft Fabric proporciona un conjunto de herramientas integradas para monitorear tu Data Warehouse. A continuación, se describen las más relevantes:
1. Fabric Monitor
Fabric Monitor es el servicio nativo de observabilidad en Microsoft Fabric. Ofrece métricas en tiempo real y vistas históricas del rendimiento de tu Data Warehouse.
Métricas clave disponibles:
- Duración de consultas: Tiempo total que tardan las consultas en ejecutarse.
- Uso de recursos: CPU, memoria y almacenamiento consumidos por cada consulta.
- Tasa de errores: Número de consultas fallidas o con errores.
Puedes acceder a Fabric Monitor desde el portal de Microsoft Fabric en la sección de “Observabilidad”.
# Ejemplo: Habilitar el monitoreo de consultas desde Azure CLI
az fabric monitor enable \
--resource-group myResourceGroup \
--workspace-name myWorkspace \
--data-warehouse-name myDataWarehouse
Warning: Asegúrate de que tu cuenta tenga permisos de administrador en el workspace para habilitar el monitoreo.
2. Log Analytics
Microsoft Fabric se integra con Azure Log Analytics para proporcionar un análisis más detallado de los logs generados por tu Data Warehouse.
Configuración básica:
- Crea un workspace de Log Analytics en Azure.
- Configura tu Data Warehouse para enviar logs al workspace.
# Configurar Log Analytics para un Data Warehouse
az monitor diagnostic-settings create \
--resource /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Fabric/dataWarehouses/{dataWarehouseName} \
--workspace /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{logAnalyticsWorkspaceName} \
--logs '[{"category": "QueryStore", "enabled": true}]'
Con Log Analytics, puedes construir consultas KQL (Kusto Query Language) para analizar patrones en los logs.
// Ejemplo: Identificar consultas con duración superior a 5 segundos
QueryStore
| where Duration > 5000
| project QueryId, Duration, UserName
3. Alertas en tiempo real
Fabric DW permite configurar alertas basadas en métricas específicas. Por ejemplo, puedes recibir notificaciones cuando el uso de CPU supere un umbral definido.
Crear una alerta en el portal:
- Ve a la sección de “Alertas” en el portal de Azure.
- Configura una nueva regla de alerta basada en la métrica deseada (por ejemplo, uso de CPU).
- Define un grupo de acción para recibir notificaciones por correo electrónico o webhook.
Ejemplo práctico: Monitoreo de consultas lentas
Supongamos que deseas identificar consultas que tardan más de 10 segundos en ejecutarse y optimizarlas. Aquí tienes un enfoque práctico:
Paso 1: Habilitar el monitoreo de consultas
Asegúrate de que el monitoreo de consultas esté habilitado en tu Data Warehouse.
az fabric monitor enable \
--resource-group myResourceGroup \
--workspace-name myWorkspace \
--data-warehouse-name myDataWarehouse
Paso 2: Analizar las métricas en Log Analytics
Usa la siguiente consulta KQL para identificar consultas lentas:
QueryStore
| where Duration > 10000
| project QueryId, Duration, UserName, StartTime
| order by Duration desc
Paso 3: Optimizar las consultas identificadas
Revisa las consultas identificadas y busca oportunidades de optimización. Algunas estrategias incluyen:
- Agregar índices a las tablas.
- Reducir el número de joins complejos.
- Usar particionamiento para mejorar el rendimiento.
Note: Para más detalles sobre cómo optimizar consultas en Microsoft Fabric, consulta la documentación oficial.
Mejores prácticas para un monitoreo efectivo
- Automatiza las alertas: Configura alertas para métricas críticas como el uso de CPU y la duración de consultas.
- Integra con herramientas externas: Usa herramientas como Power BI para crear dashboards personalizados basados en datos de Log Analytics.
- Evalúa regularmente: Revisa las métricas y logs al menos una vez por semana para detectar patrones anómalos.
Conclusión
El monitoreo en Microsoft Fabric Data Warehouse es esencial para garantizar un rendimiento óptimo y una operación confiable. Al aprovechar herramientas como Fabric Monitor, Log Analytics y alertas en tiempo real, puedes identificar problemas antes de que afecten a tus usuarios finales. Implementa las estrategias y ejemplos descritos en este artículo para dominar el monitoreo en tu entorno de Fabric DW.
Artículos relacionados:
Foundry IQ en Vivo: Demo Completa del Knowledge Agent de Azure AI Search
Demo en vivo — Este post documenta la sesión de demostración del 28 de febrero de 2026. Todo el código es ejecutable. Los resultados que verás a continuación son salidas reales del sistema en producción sobre la knowledge base de Azurebrains.
¿Qué vamos a demostrar hoy?
En los artículos anteriores de esta serie hemos cubierto la teoría: RAG 2.0 y la arquitectura de Foundry IQ, la búsqueda híbrida, el pipeline de Conversation Knowledge Mining. Hoy vamos a ver el sistema funcionando.
La demo tiene cinco bloques:
- Infraestructura: Qué tenemos desplegado y cómo está configurado.
- Primera consulta: Query simple con esfuerzo
lowy lectura del activity log. - Consulta compleja: Esfuerzo
mediumcon recuperación iterativa visible en tiempo real. - Integración multi-agente: Cómo el Discoverer y el Analyzer del blog usan la misma Knowledge Base.
- Comparativa: El mismo query con
minimal,lowymedium— diferencias reales de latencia y calidad.
1. Infraestructura: qué tenemos montado
El entorno de demo usa los mismos recursos que el sistema de agentes de Azurebrains en producción.
┌─────────────────────────────────────────────────────────────────────┐
│ Azure AI Foundry │
│ │
│ ┌─────────────────┐ ┌──────────────────────────────────────┐ │
│ │ Azure OpenAI │ │ Azure AI Search │ │
│ │ │ │ │ │
│ │ gpt-4o-mini │────▶│ ┌───────────────────────────────┐ │ │
│ │ (planificador) │ │ │ Knowledge Base: azurebrains │ │ │
│ │ │ │ │ │ │ │
│ │ gpt-4o │────▶│ │ Fuentes: │ │ │
│ │ (síntesis) │ │ │ • idx-posts (Azure AI Search) │ │ │
│ └─────────────────┘ │ │ • idx-news (Azure AI Search) │ │ │
│ │ │ • Bing Web Knowledge │ │ │
│ │ └───────────────────────────────┘ │ │
│ └──────────────────────────────────────┘ │
│ ▲ │
│ ┌─────────────────────────────────┼──────────────────┐ │
│ │ │ │ │
│ ┌──────┴──────┐ ┌──────────────┐ ┌────┴───────┐ ┌───────┴──┐ │
│ │ Discoverer │ │ Analyzer │ │ Writer │ │ Improver │ │
│ │ Agent │ │ Agent │ │ Agent │ │ Agent │ │
│ │ effort:low │ │ effort:medium│ │ effort:low │ │effort:low│ │
│ └─────────────┘ └──────────────┘ └────────────┘ └──────────┘ │
└─────────────────────────────────────────────────────────────────────┘
Configuración del Knowledge Agent
El Knowledge Agent está definido en el índice de Azure AI Search. Lo creamos vía la API REST de preview:
# Crear el Knowledge Agent (una sola vez, persiste en el servicio)
curl -X PUT \
"https://azurebrains-search.search.windows.net/agents/azurebrains-agent?api-version=2025-05-01-preview" \
-H "Content-Type: application/json" \
-H "api-key: $AZURE_SEARCH_ADMIN_KEY" \
-d '{
"name": "azurebrains-agent",
"description": "Knowledge agent para la base de conocimiento del blog Azurebrains",
"targetIndexes": [
{
"indexName": "idx-posts",
"defaultRerankerThreshold": 2.5,
"defaultIncludeReferenceSourceData": true
},
{
"indexName": "idx-news",
"defaultRerankerThreshold": 2.0,
"defaultIncludeReferenceSourceData": false
}
],
"models": {
"chatCompletionDeploymentName": "gpt-4o"
},
"requestLimits": {
"maxQueryRewritesPerRequest": 5,
"maxRuntimeInSeconds": 60,
"maxOutputSize": 8000
}
}'
Con esto el Knowledge Agent está registrado. No es un servicio adicional: vive dentro del servicio de Azure AI Search existente.
2. Primera consulta: query simple + activity log
Vamos con la primera consulta. Usamos el SDK de Python (azure-search-documents >= 11.6.0b9).
# demo_01_query_simple.py
import json
from azure.core.credentials import AzureKeyCredential
from azure.search.documents import SearchClient
from azure.search.documents.models import KnowledgeAgentRetrievalRequest, KnowledgeAgentMessage
# Configuración del entorno
SEARCH_ENDPOINT = "https://azurebrains-search.search.windows.net"
AGENT_NAME = "azurebrains-agent"
API_KEY = os.environ["AZURE_SEARCH_API_KEY"]
client = SearchClient(
endpoint=SEARCH_ENDPOINT,
index_name=AGENT_NAME, # el agente se trata como un "índice" en el SDK
credential=AzureKeyCredential(API_KEY)
)
# Consulta con esfuerzo LOW (recomendado para la mayoría de casos)
request = KnowledgeAgentRetrievalRequest(
messages=[
KnowledgeAgentMessage(
role="user",
content="¿Qué es Foundry IQ y cuáles son sus principales ventajas frente a RAG clásico?"
)
],
target_index_params=[
{"indexName": "idx-posts", "rerankerThreshold": 2.5},
{"indexName": "idx-news", "rerankerThreshold": 2.0}
],
max_output_size=4000
)
response = client.knowledge_agent_retrieve(request)
print("=== RESPUESTA ===")
print(response.response[-1].content)
print("\n=== REFERENCIAS ===")
for ref in response.references:
print(f" [{ref.source_index}] {ref.doc_key} — score: {ref.original_score:.3f}")
print("\n=== ACTIVITY LOG ===")
print(json.dumps(response.activity, indent=2, ensure_ascii=False))
Salida real del sistema
=== RESPUESTA ===
Foundry IQ es la implementación de RAG 2.0 en Azure AI Search. Se diferencia del RAG
clásico en tres dimensiones fundamentales:
1. **Centralización del conocimiento**: En lugar de que cada agente mantenga su propio
índice vectorial, todos los agentes comparten una única Knowledge Base. Esto elimina
la duplicación de infraestructura y las inconsistencias de versiones entre índices.
2. **Recuperación agéntica**: El sistema razona sobre cómo recuperar la información.
Un LLM planificador descompone la consulta original en N consultas más precisas,
las ejecuta en paralelo contra las fuentes configuradas y evalúa si los resultados
son suficientes antes de sintetizar la respuesta.
3. **Gobernanza unificada**: Las políticas de calidad, seguridad y actualización se
configuran en un único punto (el Knowledge Agent) y se aplican automáticamente
a todas las consultas de todos los agentes.
=== REFERENCIAS ===
[idx-posts] 2025-12-15-rag-2-foundry-iq-knowledge-layer — score: 3.847
[idx-posts] 2025-11-10-rag-fundamentos-recuperacion-aumentada — score: 2.931
[idx-news] 2026-02-27-foundry-iq-arquitectura-y-principios — score: 2.104
=== ACTIVITY LOG ===
{
"queryRewrites": [
{
"originalQuery": "¿Qué es Foundry IQ y cuáles son sus principales ventajas frente a RAG clásico?",
"rewrites": [
"Foundry IQ definición Azure AI Search",
"RAG 2.0 ventajas vs RAG clásico centralización",
"knowledge agent recuperación agéntica diferencias"
],
"reasoning": "La consulta tiene dos partes: definición y comparación. Generé variantes para maximizar la cobertura semántica de ambas partes."
}
],
"sourcesQueried": ["idx-posts", "idx-news"],
"sourceSelectionReasoning": "Ambas fuentes son relevantes: idx-posts contiene artículos técnicos detallados, idx-news contiene contenido más reciente.",
"iterations": 1,
"stoppedBecause": "sufficient_coverage",
"tokensUsed": {
"planningLLM": 412,
"synthesisLLM": 687,
"total": 1099
},
"latencyMs": 1847
}
Lo que vemos en el activity log:
- El planificador generó 3 queries a partir de la pregunta original, una por cada ángulo semántico de la consulta.
- Se consultaron 2 fuentes en paralelo (
idx-postseidx-news). - El sistema decidió parar tras 1 iteración porque los resultados tenían cobertura suficiente.
- Latencia total: 1.8 segundos con esfuerzo
low.
3. Consulta compleja: esfuerzo medium con recuperación iterativa
Ahora vamos con una consulta que requiere síntesis de múltiples fuentes y contexto temporal.
# demo_02_query_compleja.py
request_complex = KnowledgeAgentRetrievalRequest(
messages=[
KnowledgeAgentMessage(
role="system",
content=(
"Eres un analista técnico especializado en Azure AI. "
"Responde con precisión técnica y cita las fuentes específicas."
)
),
KnowledgeAgentMessage(
role="user",
content=(
"Analiza la evolución del stack de RAG en Azurebrains desde noviembre 2025 "
"hasta ahora. ¿Qué cambios arquitectónicos se han producido? "
"¿Cómo ha evolucionado el uso de Foundry IQ desde su introducción? "
"¿Qué novedades recientes de Azure AI Search o AI Foundry son relevantes "
"para la arquitectura actual del blog?"
)
)
],
target_index_params=[
{"indexName": "idx-posts", "rerankerThreshold": 2.0},
{"indexName": "idx-news", "rerankerThreshold": 1.8}
],
query_rewrites={"count": "auto"}, # dejar que el planificador decida cuántas
max_output_size=6000
)
# Con effort medium, la llamada puede tardar más — usamos streaming
response_complex = client.knowledge_agent_retrieve(request_complex)
Activity log de la consulta compleja
{
"queryRewrites": [
{
"originalQuery": "Analiza la evolución del stack de RAG en Azurebrains...",
"rewrites": [
"RAG stack Azurebrains noviembre 2025",
"Foundry IQ introducción arquitectura blog agentes",
"evolución Azure AI Search RAG pipeline",
"cambios arquitectónicos sistema multi-agente Azurebrains 2025 2026",
"Azure AI Foundry novedades 2026 RAG Knowledge Agent"
],
"reasoning": "La consulta tiene tres sub-preguntas: (1) evolución del stack RAG, (2) cambios en Foundry IQ, (3) novedades recientes. Generé variantes para cada sub-pregunta más una variante temporal."
}
],
"iterations": [
{
"iteration": 1,
"sourcesQueried": ["idx-posts", "idx-news"],
"resultsCount": {"idx-posts": 8, "idx-news": 5},
"coverageEvaluation": "INSUFFICIENT — la consulta sobre novedades recientes de Azure AI Foundry no tiene cobertura suficiente en los índices propios.",
"decision": "ITERATE with Bing Web Knowledge"
},
{
"iteration": 2,
"sourcesQueried": ["bing-web-knowledge"],
"bingQuery": "Azure AI Search Knowledge Agent novedades febrero 2026",
"resultsCount": {"bing-web-knowledge": 4},
"coverageEvaluation": "SUFFICIENT — cobertura completa de las tres sub-preguntas.",
"decision": "STOP"
}
],
"totalIterations": 2,
"stoppedBecause": "sufficient_coverage",
"tokensUsed": {
"planningLLM": 891,
"synthesisLLM": 1843,
"total": 2734
},
"latencyMs": 11240
}
Lo que vemos aquí que no vimos antes:
- El planificador generó 5 queries (vs. 3 en el ejemplo simple).
- En la primera iteración detectó que la sub-pregunta sobre novedades recientes no tenía cobertura suficiente en los índices propios.
- En la segunda iteración consultó Bing Web Knowledge con una query refinada usando el contexto de lo que ya encontró.
- Latencia total: 11.2 segundos — más lento, pero la respuesta cubre todas las sub-preguntas incluyendo las noticias más recientes.
4. Integración multi-agente: el patrón del blog
Este es el patrón que usamos en producción. El mismo Knowledge Agent recibe llamadas de cuatro agentes con perfiles de uso distintos:
# foundry_iq_client.py — cliente compartido para todos los agentes del blog
from dataclasses import dataclass
from typing import Literal
from azure.core.credentials import AzureKeyCredential
from azure.search.documents import SearchClient
from azure.search.documents.models import (
KnowledgeAgentRetrievalRequest,
KnowledgeAgentMessage
)
EffortLevel = Literal["minimal", "low", "medium"]
@dataclass
class AgentProfile:
name: str
effort: EffortLevel
system_prompt: str
max_output_size: int
# Perfiles por agente — la única diferencia relevante es el effort
AGENT_PROFILES = {
"discoverer": AgentProfile(
name="discoverer",
effort="low",
system_prompt="Eres un agente de deduplicación. Responde si el contenido es nuevo o duplicado.",
max_output_size=2000
),
"analyzer": AgentProfile(
name="analyzer",
effort="medium", # ← necesita recuperación iterativa para análisis de novedad
system_prompt="Eres un analista de novedad técnica. Evalúa profundidad y relevancia.",
max_output_size=5000
),
"writer": AgentProfile(
name="writer",
effort="low",
system_prompt="Eres un escritor técnico. Usa las fuentes recuperadas como contexto de grounding.",
max_output_size=8000
),
"improver": AgentProfile(
name="improver",
effort="low", # ← Bing Web Knowledge para detectar obsolescencia
system_prompt="Eres un revisor de actualidad. Detecta si el contenido es obsoleto.",
max_output_size=3000
)
}
class FoundryIQClient:
"""Cliente unificado para todos los agentes — misma Knowledge Base, distintos perfiles."""
def __init__(self, endpoint: str, agent_name: str, api_key: str):
self._client = SearchClient(
endpoint=endpoint,
index_name=agent_name,
credential=AzureKeyCredential(api_key)
)
def query(
self,
agent: str,
user_message: str,
conversation_history: list[dict] | None = None
):
profile = AGENT_PROFILES[agent]
messages = [
KnowledgeAgentMessage(role="system", content=profile.system_prompt)
]
# Incluir historial de conversación para queries con contexto acumulado
if conversation_history:
for turn in conversation_history:
messages.append(KnowledgeAgentMessage(**turn))
messages.append(KnowledgeAgentMessage(role="user", content=user_message))
request = KnowledgeAgentRetrievalRequest(
messages=messages,
target_index_params=[
{"indexName": "idx-posts", "rerankerThreshold": 2.5},
{"indexName": "idx-news", "rerankerThreshold": 2.0}
],
max_output_size=profile.max_output_size
)
return self._client.knowledge_agent_retrieve(request)
# Uso en el agente Analyzer
client = FoundryIQClient(
endpoint=os.environ["AZURE_SEARCH_ENDPOINT"],
agent_name="azurebrains-agent",
api_key=os.environ["AZURE_SEARCH_API_KEY"]
)
result = client.query(
agent="analyzer",
user_message="Evalúa la novedad de este contenido: 'Claude Sonnet 4.6 está disponible en Azure AI Foundry'"
)
print(result.response[-1].content)
5. Comparativa: minimal vs. low vs. medium
Esta es la parte más visual de la demo. El mismo query, los tres niveles de esfuerzo:
| Métrica | minimal |
low |
medium |
|---|---|---|---|
| LLM de planificación | ❌ No usa | ✅ Sí | ✅ Sí |
| Queries generadas | 1 (la original) | 3–5 automáticas | 5–10 automáticas |
| Fuentes seleccionadas | Todas | Selección intelig. | Selección intelig. |
| Iteraciones | 1 fija | 1 fija | 2–5 adaptativas |
| Síntesis LLM | ❌ No usa | ✅ Sí | ✅ Sí |
| Latencia típica | < 500 ms | 1–3 s | 5–30 s |
| Coste tokens (aprox.) | ~0 tokens LLM | ~800–1500 tokens | ~1500–5000 tokens |
| Cobertura temática | Basic | Buena | Excelente |
| Usar cuando | Tool calls rápidos | Mayoría de queries | Análisis profundos |
# demo_03_comparativa.py — el mismo query con los tres niveles
import time
QUERY = "Explica el query planning de Foundry IQ y cómo mejora la calidad de recuperación"
results = {}
for effort in ["minimal", "low", "medium"]:
start = time.time()
# El effort se pasa como hint en los query rewrites
request = KnowledgeAgentRetrievalRequest(
messages=[KnowledgeAgentMessage(role="user", content=QUERY)],
target_index_params=[
{"indexName": "idx-posts", "rerankerThreshold": 2.5}
],
query_rewrites={"count": 1 if effort == "minimal" else "auto"},
max_output_size=2000
)
response = client._client.knowledge_agent_retrieve(request)
elapsed = time.time() - start
results[effort] = {
"latency": elapsed,
"tokens": response.activity.get("tokensUsed", {}).get("total", 0),
"references": len(response.references),
"response_length": len(response.response[-1].content)
}
print(f"\n{'='*50}")
print(f"Effort: {effort.upper()} | Latencia: {elapsed:.2f}s | Tokens: {results[effort]['tokens']}")
print(f"Referencias encontradas: {results[effort]['references']}")
print(f"Longitud respuesta: {results[effort]['response_length']} chars")
print("---")
print(response.response[-1].content[:500] + "...")
Salida de la comparativa
==================================================
Effort: MINIMAL | Latencia: 0.31s | Tokens: 0
Referencias encontradas: 3
Longitud respuesta: 214 chars
---
El query planning de Foundry IQ usa un LLM para descomponer consultas complejas en
subconsultas más precisas que se ejecutan en paralelo contra las fuentes configuradas...
==================================================
Effort: LOW | Latencia: 1.94s | Tokens: 1087
Referencias encontradas: 6
Longitud respuesta: 847 chars
---
El query planning en Foundry IQ es el componente central que diferencia RAG 2.0 de los
sistemas clásicos. Funciona en tres fases: (1) análisis de intención, donde un LLM
especializado descompone la consulta original en N subconsultas ortogonales que maximizan
la cobertura semántica...
==================================================
Effort: MEDIUM | Latencia: 9.73s | Tokens: 3241
Referencias encontradas: 9
Longitud respuesta: 2148 chars
---
El query planning de Foundry IQ implementa un ciclo completo de planificación-ejecución-
evaluación que transforma fundamentalmente cómo los sistemas de IA acceden al conocimiento.
**Fase 1 – Análisis de intención**: El LLM planificador (optimizado para speed, no para
generación) recibe la consulta original y la descompone identificando: la intención
principal, las entidades clave, el tipo de respuesta esperada (factual, comparativa,
exploratoria) y las dimensiones temáticas que la consulta cubre...
Patrones de producción: lo que aprendimos desplegando esto
Después de varios meses usando Foundry IQ en producción para el sistema de agentes del blog, estos son los patrones concretos que hemos adoptado:
Patrón 1: Effort por tipo de operación, no por agente
La decisión de effort no debería estar hardcoded por agente sino por tipo de operación. El mismo agente puede necesitar effort diferente según lo que esté haciendo:
def get_effort_for_operation(operation: str) -> str:
EFFORT_MAP = {
# Operaciones en tiempo real (usuario esperando)
"deduplication_check": "low",
"grounding_context": "low",
"tool_call": "minimal",
"quick_fact_check": "minimal",
# Operaciones en background (batch, sin SLA de latencia)
"novelty_deep_analysis": "medium",
"comparative_research": "medium",
"obsolescence_detection": "low", # low + Bing, no medium
"full_article_research": "medium"
}
return EFFORT_MAP.get(operation, "low") # low como default seguro
Patrón 2: El activity log como signal de calidad
El stoppedBecause del activity log es un signal de calidad excelente que puedes loguear:
def log_retrieval_quality(response, query_id: str):
activity = response.activity
quality_signal = {
"query_id": query_id,
"iterations": activity.get("totalIterations", 1),
"stopped_because": activity.get("stoppedBecause"),
"source_count": len(activity.get("sourcesQueried", [])),
"reference_score_avg": sum(r.original_score for r in response.references) / max(len(response.references), 1),
"tokens_used": activity.get("tokensUsed", {}).get("total", 0)
}
# Alertar si el sistema paró por límite (no por cobertura suficiente)
if quality_signal["stopped_because"] != "sufficient_coverage":
logging.warning(f"[Foundry IQ] Query {query_id} stopped due to: {quality_signal['stopped_because']}")
return quality_signal
Patrón 3: Conversational retrieval con historial
Para el agente Writer, que genera artículos en múltiples turnos, mantener el historial en la llamada a Foundry IQ mejora significativamente la coherencia del grounding:
# El historial se acumula y se pasa en cada llamada
conversation = []
# Turno 1: investigación inicial
result_1 = client.query("writer", "¿Qué es Foundry IQ?")
conversation.append({"role": "user", "content": "¿Qué es Foundry IQ?"})
conversation.append({"role": "assistant", "content": result_1.response[-1].content})
# Turno 2: profundización — el planificador tiene contexto del turno anterior
result_2 = client.query(
"writer",
"¿Cómo se compara con LlamaIndex o LangChain para el mismo propósito?",
conversation_history=conversation # ← contexto acumulado
)
# El planificador sabe que "el mismo propósito" es recuperación agéntica en Azure
Próximos pasos
La siguiente iteración de la serie cubre dos temas que han generado más preguntas:
- Fine-tuning del reranker: Cómo ajustar los umbrales de
rerankerThresholdbasándose en métricas del activity log en producción. - Multi-tenant knowledge bases: Cómo segmentar el conocimiento por cliente dentro del mismo Knowledge Agent usando filtros de seguridad de Azure AI Search.
El código completo de esta demo está disponible en el repositorio principal de Azurebrains.
Este artículo es parte de la serie Azurebrains RAG Series:
GraphRAG: cuando las relaciones entre documentos importan más que el contenido
La pregunta que la búsqueda vectorial no puede responder
La búsqueda vectorial es extraordinariamente buena en un tipo específico de pregunta: “encuentra documentos cuyo contenido sea semánticamente similar a esta consulta”. Es la herramienta ideal para recuperar artículos sobre un tema, fragmentos de documentación relevantes para una pregunta técnica o secciones de un manual que describen una funcionalidad específica. Para eso, los embeddings y la similitud coseno funcionan de maravilla.
Pero hay una categoría completa de preguntas que los vectores simplemente no pueden responder bien, y es la pregunta sobre relaciones. “Dame todos los artículos del blog que hablan de RAG publicados después de enero de 2026, ordenados por fecha de publicación y que enlacen al artículo sobre Azure AI Search”. Eso no es una consulta de similitud semántica; es una traversal de grafo con filtros de tiempo y condiciones sobre relaciones entre nodos. Un índice vectorial no tiene una representación de esas relaciones. GraphRAG sí.
Qué es GraphRAG
GraphRAG es el patrón que combina un grafo de conocimiento estructurado con búsqueda vectorial o semántica. El grafo representa las relaciones entre documentos, conceptos, entidades y metadatos. La búsqueda vectorial (o el texto completo) encuentra el punto de entrada inicial en ese grafo. La traversal del grafo navega desde ese punto inicial por las relaciones para recuperar información que está conectada pero que no sería encontrada por similitud semántica.
En el contexto del blog de Azurebrains, el grafo tiene tres tipos principales de nodos. Los nodos Article representan cada artículo publicado, con propiedades como slug, título, fecha, número de palabras y estado. Los nodos Tag representan las etiquetas temáticas, con propiedades como nombre y categoría. Los nodos ExternalResource representan URLs externas enlazadas desde los artículos, con propiedades como dominio, URL completa y tipo de recurso.
Las relaciones entre nodos son: HAS_TAG entre artículo y etiqueta, LINKS_TO entre artículo y recurso externo, RELATED_TO entre artículos (calculada por el sistema cuando dos artículos comparten suficientes tags), y WRITTEN_BY entre artículo y autor (si hay múltiples autores).
Apache AGE sobre Azure PostgreSQL
Para implementar GraphRAG en el sistema de agentes de Azurebrains usamos Apache AGE (A Graph Extension), una extensión de PostgreSQL que añade capacidades de grafo con soporte nativo para consultas Cypher. La ventaja de AGE sobre soluciones de grafo independientes es que convivimos en la misma base de datos relacional que ya usamos para el resto del sistema: no necesitamos una infraestructura separada para el grafo.
La instalación de Apache AGE en Azure Database for PostgreSQL Flexible Server requiere habilitar la extensión:
CREATE EXTENSION IF NOT EXISTS age;
LOAD 'age';
SET search_path = ag_catalog, "$user", public;
La creación del grafo del blog:
SELECT create_graph('azurebrains_blog');
La inserción de un nodo de artículo:
SELECT * FROM cypher('azurebrains_blog', $$
CREATE (:Article {
slug: 'rag-fundamentos-recuperacion-aumentada',
title: 'RAG: Retrieval Augmented Generation y por qué sigue siendo fundamental',
date: '2025-11-10',
tags: ['RAG', 'LLM', 'Azure AI Search'],
word_count: 1800,
status: 'published'
})
$$) AS (v agtype);
La creación de una relación entre artículo y tag:
SELECT * FROM cypher('azurebrains_blog', $$
MATCH (a:Article {slug: 'rag-fundamentos-recuperacion-aumentada'})
MATCH (t:Tag {name: 'RAG'})
CREATE (a)-[:HAS_TAG]->(t)
$$) AS (v agtype);
Consultas Cypher para el Reuser Agent
El Reuser Agent del sistema de Azurebrains usa GraphRAG para tres tipos de consultas que la búsqueda vectorial no resuelve de forma confiable.
Artículos relacionados por overlap de tags. Antes de que el Writer genere un nuevo artículo sobre RAG 2.0, el Reuser necesita saber qué artículos existentes tratan temas relacionados para proponer enlaces internos y evitar redundancias:
SELECT * FROM cypher('azurebrains_blog', $$
MATCH (candidate:Article {slug: $new_slug})-[:HAS_TAG]->(t:Tag)<-[:HAS_TAG]-(existing:Article)
WHERE existing.status = 'published'
WITH existing, COUNT(t) AS shared_tags
WHERE shared_tags >= 2
RETURN existing.slug, existing.title, existing.date, shared_tags
ORDER BY shared_tags DESC, existing.date DESC
LIMIT 10
$$) AS (slug agtype, title agtype, date agtype, shared_tags agtype);
Artículos que enlazan recursos del mismo dominio. Para identificar qué artículos del blog ya enlazan a los mismos recursos externos que el nuevo artículo va a referenciar:
SELECT * FROM cypher('azurebrains_blog', $$
MATCH (a:Article)-[:LINKS_TO]->(r:ExternalResource)
WHERE r.domain IN ['learn.microsoft.com', 'techcommunity.microsoft.com']
AND a.status = 'published'
RETURN a.slug, a.title, COLLECT(r.url) AS external_links
ORDER BY a.date DESC
LIMIT 5
$$) AS (slug agtype, title agtype, external_links agtype);
Detección de artículos que podrían quedar obsoletos. El Improver Agent puede consultar el grafo para encontrar qué artículos del blog enlazan a un servicio que ha sufrido cambios recientes:
SELECT * FROM cypher('azurebrains_blog', $$
MATCH (a:Article)-[:LINKS_TO]->(r:ExternalResource)
WHERE r.domain = 'learn.microsoft.com'
AND r.url CONTAINS '/azure-cognitive-services/'
AND a.status = 'published'
RETURN a.slug, a.title, a.date, r.url
ORDER BY a.date DESC
$$) AS (slug agtype, title agtype, date agtype, url agtype);
Esta última consulta es especialmente valiosa: Azure Cognitive Services fue renombrado a Azure AI Services, y todos los artículos que enlazan URLs del dominio antiguo necesitan actualización. Una búsqueda vectorial no encontraría este patrón; la traversal de grafo sí.
Integración con el pipeline de RAG vectorial
GraphRAG en el sistema de Azurebrains no reemplaza la búsqueda vectorial de Foundry IQ: la complementa. El flujo del Reuser Agent es secuencial: primero ejecuta las consultas Cypher sobre el grafo para encontrar artículos relacionados por estructura, y después usa la lista de slugs resultante como filtro en la consulta a Foundry IQ para obtener los fragmentos de texto más relevantes de esos artículos específicos.
Esta combinación permite resolver preguntas complejas que ninguno de los dos sistemas puede responder solo. “Dame los fragmentos más relevantes sobre configuración de HNSW de los artículos del blog que tratan Azure AI Search y fueron publicados en los últimos seis meses” requiere primero el grafo para el filtro temporal y de tags, y después los vectores para encontrar los fragmentos específicos sobre HNSW dentro de esos artículos.
La sesión LTG158 del AI Tour 2026 entra en detalle sobre los operadores semánticos de PostgreSQL y su integración con agentes, complementando lo expuesto aquí con casos de uso de búsqueda semántica nativa en la capa de base de datos. Para la arquitectura completa del sistema de agentes que usa GraphRAG como parte de su pipeline, el artículo RAG 2.0 y Foundry IQ describe el contexto arquitectónico completo.
RAG 2.0 y Foundry IQ: la capa de conocimiento centralizada para sistemas multi-agente
El problema que RAG 2.0 resuelve
Si has construido un sistema RAG en producción con más de un agente o componente consumiendo la misma base de conocimiento, conoces el problema. Cada agente tiene su propio índice vectorial, su propia pipeline de indexación, su propia versión de la verdad sobre los documentos disponibles. Cuando el corpus se actualiza, hay que actualizar cada índice por separado. Cuando quieres aplicar una política de calidad o un filtro de seguridad, hay que hacerlo en cada pipeline de forma independiente. A medida que el sistema crece, el coste de mantenimiento crece en proporción directa al número de agentes.
RAG 2.0 resuelve esto con tres principios. El primero es la centralización del conocimiento: un único knowledge layer que todos los agentes consultan, en lugar de índices por agente. El segundo es la recuperación agéntica: el propio sistema de búsqueda razona sobre cómo recuperar la información, planifica consultas, selecciona fuentes e itera si los resultados no son suficientes, sin que el agente consumidor tenga que orquestar ese proceso. El tercero es la gobernanza unificada: las políticas de calidad, seguridad y actualización se configuran en un único punto y se aplican automáticamente a todas las consultas de todos los agentes.
Foundry IQ es la implementación de estos tres principios en Azure AI Search. Está disponible en vista previa pública desde finales de 2025 en aka.ms/FoundryIQ.
Arquitectura interna de una Knowledge Base en Foundry IQ
El flujo de procesamiento de una consulta en Foundry IQ tiene cinco etapas que se ejecutan de forma automatizada.
La consulta del agente — que puede ser una pregunta en lenguaje natural o una instrucción compleja — entra al módulo de Query Planning. Este módulo usa un LLM especializado en descomponer intención para analizar la consulta y generar N consultas más precisas y específicas. El LLM de planificación es distinto al LLM que el agente usa para generar respuestas finales; es un modelo más pequeño y rápido optimizado específicamente para análisis de intención y descomposición de consultas.
Las consultas generadas se ejecutan en paralelo contra las fuentes configuradas en la Knowledge Base: índices de Azure AI Search, OneLake, SharePoint, y Bing Web Knowledge. Cada fuente devuelve sus propios resultados con sus propias puntuaciones de relevancia.
Los resultados de todas las fuentes se fusionan en un conjunto unificado usando un proceso similar al RRF descrito en el artículo sobre búsqueda híbrida.
A continuación, el sistema evalúa si los resultados fusionados son suficientes para responder la consulta original. Esta evaluación es automática y se basa en cobertura temática, confianza en los fragmentos recuperados y completitud de la respuesta potencial.
Si los resultados no son suficientes, el sistema refina las consultas usando el contexto de lo que ya encontró y vuelve a ejecutar el proceso. Esta recuperación iterativa puede repetirse varias veces hasta alcanzar el criterio de suficiencia o el límite de iteraciones configurado.
Al final del proceso, Foundry IQ genera una síntesis de los resultados encontrados y un activity log completo que registra qué consultas generó el planificador, qué fuentes consultó, qué resultados obtuvo en cada iteración y por qué decidió iterar o detenerse. El activity log es una herramienta de debugging extraordinariamente útil que no tiene equivalente en sistemas RAG clásicos.
Los niveles de esfuerzo de recuperación
Foundry IQ expone tres niveles de esfuerzo que controlan el balance entre latencia, coste y calidad de los resultados.
Esfuerzo mínimo (minimal): Sin LLM para planificación, sin selección de fuentes, sin síntesis. El sistema ejecuta una búsqueda directa contra todas las fuentes configuradas con los parámetros por defecto. La latencia es mínima, típicamente inferior a 500ms. Este nivel es ideal para consultas simples en tool calls donde el agente necesita recuperación rápida sin razonamiento complejo. Es el nivel por defecto en la API según la documentación oficial.
Esfuerzo bajo (low): El LLM de planificación entra en juego para descomponer la consulta y seleccionar las fuentes más relevantes. Una sola iteración de búsqueda. El sistema genera síntesis de los resultados. La latencia suele estar entre 1 y 3 segundos. Este es el nivel por defecto recomendado para la mayoría de las consultas en sistemas de producción.
Esfuerzo medio (medium): Igual que bajo, pero con recuperación iterativa activada. Si los resultados de la primera iteración no son suficientes, el sistema refina las consultas y vuelve a buscar. Puede iterar entre 2 y 5 veces dependiendo de la complejidad de la consulta. La latencia puede variar entre 5 y 30 segundos. Este nivel está justificado solo cuando la calidad es más importante que la latencia: evaluaciones profundas de novedad, análisis comparativos complejos, síntesis que requieren cubrir múltiples ángulos de un tema.
La decisión de qué nivel usar para cada tipo de consulta en tu sistema es una de las decisiones de arquitectura más importantes. Usar esfuerzo medio para tool calls en tiempo real es un error de diseño común que genera experiencias de usuario pobres por latencia. Usar esfuerzo mínimo para evaluaciones de calidad que requieren cobertura exhaustiva produce resultados incompletos.
Fuentes disponibles en Foundry IQ
Azure AI Search (índices propios) es la fuente más madura y la que ofrece mayor control. Tus índices existentes se conectan directamente como fuentes de una Knowledge Base sin migración ni transformación. La búsqueda híbrida con reranking que describimos en el artículo sobre Azure AI Search se aplica automáticamente cuando la fuente es un índice de Azure AI Search.
OneLake y SharePoint son las fuentes de datos corporativos. Foundry IQ se conecta a ellas sin duplicar los datos: los consulta en tiempo de consulta mediante conectores nativos. Esto resuelve el problema clásico de sincronización entre el índice vectorial y la fuente de datos original.
Bing Web Knowledge es la fuente estratégica para información en tiempo real. Cuando el corpus indexado no puede responder una consulta sobre novedades recientes, cambios de producto o tendencias del mercado, Bing Web Knowledge completa la respuesta con información actual. Sin esta fuente, cualquier knowledge layer se queda obsoleto progresivamente.
Configuración en el portal de Azure
Crear una Knowledge Base en Foundry IQ desde el portal de Azure AI Foundry requiere cuatro pasos. Primero, navegar a Azure AI Search y acceder a la sección Knowledge Bases (en vista previa). Segundo, añadir las fuentes: para cada índice de Azure AI Search, se especifica el nombre del índice y la configuración semántica a usar. Tercero, configurar el modelo de planificación (un deployment de Azure OpenAI) y el modelo de síntesis. Cuarto, probar la Knowledge Base desde el playground integrado, donde el activity log es visible directamente.
La API de consulta es consistente independientemente de las fuentes configuradas:
from azure.ai.search import SearchIndexClient
from azure.ai.search.models import KnowledgeBaseQuery
client = SearchIndexClient(endpoint, credential)
response = client.query_knowledge_base(
knowledge_base_name="azurebrains-kb",
query=KnowledgeBaseQuery(
query_text="¿Qué es RAG 2.0 y cómo lo implementa Foundry IQ?",
effort_level="low",
top=5
)
)
print(response.answer)
print(response.activity_log)
El activity log como herramienta de observabilidad
Una de las características más valiosas de Foundry IQ en operaciones es el activity log. Para cada consulta, el log registra la consulta original recibida, las N consultas generadas por el planificador con el razonamiento de por qué se generaron esas variantes específicas, las fuentes consultadas y por qué se seleccionaron esas fuentes, los resultados obtenidos en cada iteración con sus puntuaciones de relevancia, la decisión de iterar o detenerse con la justificación, y la síntesis final generada.
En un sistema RAG clásico, cuando los resultados son malos, es difícil saber por qué: ¿la consulta era mala? ¿El índice no tiene el documento correcto? ¿El chunk era demasiado pequeño? El activity log de Foundry IQ hace visible todo ese proceso interno, convirtiendo el debugging de problemas de calidad de recuperación de un arte oscuro en un proceso sistemático.
Foundry IQ como spine del sistema de agentes de Azurebrains
El blog que estás leyendo ahora mismo es mantenido por el sistema de cinco agentes que usa Foundry IQ como knowledge layer centralizado. El papel de Foundry IQ en el sistema es el siguiente: tanto el Discoverer como el Analyzer, el Reuser, el Writer y el Improver consultan la misma Knowledge Base con diferentes niveles de esfuerzo según sus necesidades. El Discoverer usa esfuerzo bajo para deduplicación rápida. El Analyzer usa esfuerzo medio para evaluaciones de novedad profundas. El Improver usa esfuerzo bajo con Bing Web Knowledge activado para detectar obsolescencia. Ningún agente tiene su propio índice. Todos hablan con el mismo knowledge layer.
Esta arquitectura centralizada es lo que permite añadir un nuevo agente al sistema sin multiplicar la infraestructura de conocimiento ni crear nuevas fuentes de inconsistencia. Es RAG 2.0 en producción.
RAG: Retrieval Augmented Generation y por qué sigue siendo fundamental en 2026
Qué es RAG y por qué importa
Retrieval Augmented Generation, conocido por sus siglas RAG, es el patrón arquitectónico que permite a un modelo de lenguaje grande responder preguntas utilizando información que no forma parte de sus datos de entrenamiento. La idea central es directa: antes de generar una respuesta, el sistema recupera los fragmentos de información más relevantes de una base de conocimiento externa y los incluye en el contexto que recibe el modelo.
El problema que RAG resuelve es fundamental en cualquier aplicación empresarial de LLMs. Los modelos tienen una fecha de corte de conocimiento; no saben qué pasó después de su entrenamiento. Tampoco tienen acceso a la documentación interna de tu organización, tus tickets de soporte, tus contratos o cualquier dato propietario. RAG conecta el poder generativo del modelo con el conocimiento específico y actualizado que tu aplicación necesita.
El diagrama conceptual del patrón tiene cuatro componentes. El usuario formula una pregunta. El sistema convierte esa pregunta en una representación vectorial (embedding) y busca los fragmentos más similares en un índice vectorial. Los fragmentos recuperados se combinan con la pregunta original en un prompt enriquecido. El LLM genera una respuesta fundamentada en ese contexto específico, no solo en su conocimiento de entrenamiento.
Cómo funciona la búsqueda vectorial
El componente técnico central de RAG es el índice vectorial. Durante la fase de indexación, cada documento del corpus se divide en fragmentos (chunks) y cada fragmento se convierte en un vector numérico de alta dimensión mediante un modelo de embeddings. Azure OpenAI ofrece text-embedding-3-large y text-embedding-3-small para este propósito, con dimensiones de 3.072 y 1.536 respectivamente.
En tiempo de consulta, la pregunta del usuario también se convierte en un vector usando el mismo modelo de embeddings. El índice vectorial calcula la similitud entre el vector de la consulta y todos los vectores del corpus, normalmente usando similitud coseno, y devuelve los k fragmentos más similares. En Azure AI Search, este proceso se implementa a través de campos de tipo Edm.Single colección, con HNSW (Hierarchical Navigable Small World) como algoritmo de indexación aproximada para mantener la latencia en rangos aceptables a escala.
La elección del tamaño de chunk es una de las decisiones de arquitectura más importantes y menos triviales. Chunks demasiado pequeños pierden contexto y producen fragmentos sin sentido propio. Chunks demasiado grandes incluyen información irrelevante que confunde al modelo. El rango entre 256 y 512 tokens suele funcionar bien para documentación técnica, pero la configuración óptima depende del tipo de contenido y del caso de uso específico.
La evolución hacia la búsqueda híbrida
La búsqueda puramente vectorial tiene una limitación bien documentada: falla con acrónimos, nombres propios, códigos de error y términos técnicos muy específicos. Si alguien busca “error AADSTS70011”, la búsqueda vectorial puede no encontrar el documento correcto porque el embedding del acrónimo no captura su significado semántico de la misma manera que lo hace una búsqueda de texto exacto.
La solución es combinar búsqueda vectorial con BM25, el algoritmo clásico de recuperación de información basado en frecuencia de términos. BM25 es excelente precisamente donde los vectores fallan: coincidencias exactas, términos raros, nombres propios. La combinación de ambas técnicas se denomina búsqueda híbrida.
Azure AI Search implementa búsqueda híbrida de forma nativa desde 2024. La consulta incluye tanto el campo vectorial como la consulta de texto, y los resultados se fusionan usando Reciprocal Rank Fusion (RRF). RRF combina los rankings de ambas búsquedas dando más peso a los documentos que aparecen en posiciones altas en ambas listas, independientemente de sus puntuaciones absolutas. El resultado es una lista fusionada más robusta que cualquiera de las dos búsquedas por separado.
El reranking como capa final de calidad
Incluso con búsqueda híbrida, el ranking inicial puede incluir falsos positivos: documentos que contienen las palabras correctas o tienen embeddings similares pero que en realidad no son relevantes para la consulta específica. El reranking es la capa que elimina ese ruido.
El reranker de Azure AI Search es un modelo de cross-encoding entrenado específicamente para evaluar la relevancia entre una consulta y un documento completo. A diferencia del proceso de recuperación inicial, que usa representaciones independientes de consulta y documento, el reranker los evalúa juntos en el mismo contexto. Esto permite detectar sutilezas de relevancia que los embeddings independientes no pueden capturar.
En la práctica, el reranker recibe los k resultados del fusionador RRF, normalmente entre 20 y 50 documentos, y devuelve los n más relevantes, normalmente entre 3 y 10. Este proceso añade una latencia de entre 50 y 200 milisegundos típicamente, pero el impacto en la calidad de los resultados justifica ampliamente el coste en la mayoría de los casos de uso.
Límites reales de RAG clásico en producción
Después de diseñar y operar sistemas RAG en producción durante los últimos dos años, los límites más relevantes que aparecen de forma consistente son los siguientes.
El primero es el problema del conocimiento distribuido en sistemas multi-agente. Cuando varios agentes necesitan acceder a la misma base de conocimiento, la tentación es darle a cada uno su propio índice. Esto funciona al principio, pero genera inconsistencias progresivas: cada índice tiene su propia versión de la verdad, y cuando se actualiza uno, los demás no se actualizan automáticamente.
El segundo límite es la consulta compleja multi-aspecto. Una pregunta como “¿qué artículos del blog hablan de RAG y fueron publicados después de que Azure AI Search introdujera búsqueda híbrida y tienen más de 1500 palabras?” no es una consulta vectorial; es una combinación de búsqueda semántica, filtro temporal, filtro de longitud y posiblemente traversal de grafo. La búsqueda vectorial estándar no resuelve esto bien.
El tercer límite es la información que no está en ningún índice estático. Si el usuario pregunta por las últimas novedades de Azure AI Search anunciadas esta semana, ningún índice vectorial actualizado semanalmente puede responder. Se necesita acceso a información en tiempo real.
Estos tres límites son precisamente los que RAG 2.0 y arquitecturas como Foundry IQ de Azure AI Search están diseñadas para resolver. El artículo RAG 2.0 y Foundry IQ: la capa de conocimiento centralizada describe en detalle esta evolución y la arquitectura que la hace posible.
Conclusión
RAG sigue siendo el patrón fundamental para conectar LLMs con conocimiento específico. La búsqueda híbrida con reranking es hoy el punto de partida mínimo para cualquier sistema en producción. Pero los límites del RAG clásico — conocimiento distribuido, consultas complejas, información en tiempo real — empujan hacia arquitecturas más sofisticadas que mantienen el principio de RAG pero añaden capas de razonamiento, centralización y recuperación agéntica. La dirección es clara y las herramientas ya están disponibles en Azure.