La creación y gestión eficiente de índices es esencial para aprovechar al máximo los sistemas inteligentes basados en Azure AI Search. Durante este módulo exploraremos cómo utilizar Jupyter Notebooks para automatizar y gestionar múltiples índices, ampliando considerablemente nuestra base de datos vectorial. Al implementar distintos modos de compresión y organizar diferentes estructuras, este proceso permitirá entender claramente la importancia crucial del indexing en sistemas de Inteligencia Artificial operados desde la nube.
¿Por qué es importante crear múltiples índices en Azure AI Search?
Crear varios índices en Azure AI Search es indispensable para manipular adecuadamente grandes volúmenes de información. Al comparar múltiples índices con diferentes configuraciones, podremos evaluar claramente el rendimiento, el consumo de recursos y cuál es el mejor escenario según nuestro propósito específico.
¿Qué son los algoritmos de indexación y por qué utilizarlos?
Los algoritmos de indexación nos permiten fragmentar y procesar información para alojarla eficientemente en bases de datos vectoriales. Entre los principales encontramos:
Baseline: el método más sencillo.
Baseline S: variante que considera embedding almacenado.
Scalar Full: implementación avanzada en términos de compresión.
Elegir un algoritmo adecuado impacta directamente en la manera como se distribuye y almacena nuestra información.
¿Cómo organizamos el proceso desde Jupyter Notebook?
Desde Jupyter Notebook, el proceso se realiza mediante pasos concretos y fáciles de seguir:
Instalación y declaración de importaciones necesarias para desplegar la información.
Configuración de variables globales, como los endpoints y claves obtenidas previamente desde Azure y OpenAI.
Carga y definición del archivo JSON para configurar los índices y establecer parámetros específicos de compresión y fragmentación.
Ejecución del código encargado de crear, desplegar y vincular los índices al servicio Azure Search.
Este flujo operativo permite al usuario tener un control claro y organizado sobre cada aspecto del proceso.
¿Qué ventajas ofrece gestionar índices con diferentes métodos de compresión?
Cada método de compresión afecta la velocidad del proceso, el consumo de almacenamiento y cómo organizamos la información en nuestra base de datos. Al experimentar con varios métodos desde una única plataforma, puedes evaluar:
Optimización en velocidad de búsqueda.
Consumo de recursos (memoria y CPU).
Formatos ideales para diferentes volúmenes y tipos de datos.
Te invitamos a experimentar con diferentes configuraciones y observar cómo estas influyen en el rendimiento general de tus sistemas basados en Inteligencia Artificial.
Me está gustando el curso, pero hay demasiadas cosas que se dan por sentadas y no se explican por completo. Uno termina viendo solo código para copiar y pegar, sin una comprensión de lo que está haciendo o por qué lo hace. Investigué un poco y le hice ciertas preguntas a ChatGPT.
Este es un resumen de lo que menciona y me parece útil para entender esta parte del curso:
---
1. ¿Qué es un SearchIndex en Azure Cognitive Search?
Un SearchIndex es como el esquema de una base de datos, pero diseñado para búsquedas avanzadas de texto y búsqueda vectorial.
Define:
Qué campos tendrá tu documento (texto, metadatos, embeddings, etc.)
Cómo pueden consultarse (búsqueda por texto, filtrado, ordenado, etc.)
Cómo se configurará la búsqueda vectorial (si usas embeddings para RAG)
Ejemplo en Python usandoazure-search-documents:
from azure.search.documents.indexes.modelsimportSearchIndexindex =SearchIndex( name="indice-noticias", fields=[...], # se definen más adelante
vector_search=..., # se define más adelante
)
2. ¿Qué es un SearchField y por qué hay varios?
Un SearchField es como una columna en una base de datos tradicional, pero con propiedades especiales para búsqueda.
En SQL podrías tener columnas como id, titulo, contenido, categoria.
En Azure Cognitive Search defines esos mismos campos como SearchFields, pero puedes marcar cada uno como:
searchable → si se puede buscar texto libre en él
filterable → si se puede usar en filtros (ej. "solo categoría = Deportes")
sortable → si se puede ordenar (ej. "ordenar por fecha")
facetable → si se puede agrupar (ej. "mostrar cuántos artículos hay por categoría")
key → si es la clave primaria única (como un ID en SQL)
Ejemplo realista: artículos de noticias para un sistema RAG
Supongamos que tenemos documentos con:
3. ¿Qué es VectorSearch y cómo se estructura ahora?
vector_search configura cómo funciona la búsqueda vectorial.
La nueva API de Azure permite dividirlo en 3 bloques:
(a) Algorithms – cómo buscar vecinos más cercanos (ANN)
Define el algoritmo de búsqueda vectorial. Actualmente Azure soporta HNSW:
from azure.search.documents.indexes.modelsimportVectorSearch,HnswAlgorithmConfigurationvector_search =VectorSearch( algorithms=[HnswAlgorithmConfiguration(name="hnsw-config", parameters={"m":4,"efConstruction":400})])
(b) Profiles – presets reutilizables para cada campo vectorial
Un perfil indica qué algoritmo y qué compresión usar para un campo específico:
from azure.search.documents.indexes.modelsimportVectorSearchProfilevector_search.profiles=[VectorSearchProfile( name="perfil-busqueda", algorithm_configuration_name="hnsw-config")]
Sirve para ahorrar memoria y costo usando quantization (ej. int8):
from azure.search.documents.indexes.modelsimportVectorSearchCompressionvector_search.compressions=[VectorSearchCompression(name="int8-compression", kind="quantized", parameters={"quantization":"int8"})]
4. Ejemplo completo de índice con VectorSearch
from azure.search.documents.indexes.modelsimportSearchIndexindex =SearchIndex( name="indice-noticias", fields=fields, # definidos antes
vector_search=vector_search # con algorithms, profiles, compressions
)
5. ¿Cómo funciona esto en RAG (Retrieval-Augmented Generation)?
Indexas tus documentos
Generas embeddings con Azure OpenAI u otro modelo.
Guardas texto + embeddings + metadatos en Azure Cognitive Search.
Consultas el índice
Conviertes la pregunta del usuario en un embedding.
Azure busca los chunks más parecidos usando HNSW.
(Opcional) Combinas búsqueda de texto tradicional y vectorial → hybrid search.
Pasas los resultados al LLM
El modelo genera la respuesta usando únicamente la información recuperada.
6. Diferencias clave entre parámetros
vector_search (a nivel índice) → define todas las configuraciones vectoriales disponibles.
vector_search_profile (a nivel campo) → indica qué perfil usa ese campo en particular.
algorithms / profiles / compressions → el formato nuevo separa responsabilidades, mucho más flexible que el viejo algorithm_configurations plano.
7. ¿Cuándo usar varios perfiles o compresiones?
Campo principal sin compresión → máxima precisión.
Campo secundario con compresión int8 → menor costo y velocidad de búsqueda.
Perfiles diferentes →
uno para consultas rápidas (menos precisión),
otro para consultas críticas (máxima precisión, más lento).
---
Adicionalmente:
Aquí está la documentación oficial de los SearchField (para ver todos los parámetros posibles):
El quiz de Etapas de RAG me redirigió a esta clase, se salta un módulo, me paso 2 veces
+1
+2
Esta clase me ha parecido especialmente buenísima. Aquí podemos empezar a verle las tripas al RAG
Voy a resumir en gran medida las cosas que se pueden tunear de nuestros indexers
En esencia, podemos tunear 3 atributos: El compression type (None, Scalar, Binary), el truncate dims (None, K) y la opción de Reranking aquí abstraída como discard_originals (True, False)
Rápidamente, hay que pensar en que las búsquedas que se van a hacer son costosas a nivel computacional, podemos tener decenas de miles de índices que hay que calcular 1 a 1 (o en este caso. Lo primero, es que para evitar ese peso se usa el algoritmo HNSW, el cual clusteriza en grafos diferentes índices
Lo segundo es como reducimos el peso en memoria de esos vectores, para eso comprimimos, podemos pasar los flotantes a int8 o binary (0 para negativos, 1 para positivos), esto va a remover información pero hacer los cálculos más rápidos
Lo tercero es el truncado, aquí quitamos dimensiones del vector de embedding. Esto en el papel debería ser devastador para el contexto, pero en la realidad solo reduce levemente la precisión de la búsqueda levemente
Lo cuarto es el reranking, una vez han sido calculados comprimidos, podemos tomar aquel top K (digamos top 100) y volver a calcularlos, esta vez bajo el vector entero sin compresión, rankeandolos nuevamente bajo su contexto entero y obteniendo los resultados más precisos
Hay que aclarar que si se descartan los vectores originales no se puede hacer reranking y solo podremos tener los resultados desde la compresión
Con esas intuiciones se puede entender el código y el contento más sencillamente
gracias ya que el profesor muy malo para explicar.
no entiendo la pregunta del quiz. Júpiter no reconoce Endpoint? cómo eso se contesta con esta clase?
Off Topic: He tenido que poner mis credenciales en Platzi cada vez que se termina un video o a mitad de la clase.
Siento que tienen sistemas de seguridad realmente malos, a quienes pagamos la suscripción nos tratan como delincuentes, es demasiado frecuente la solicitud de usuario/clave.
Creo que fue un error temporal. No me ha pasado nunca algo así, en 5 años en Platzi. Asegurate de no estar borrando cookies o algo así. En todo caso, reportalo a , no sirve de nada quejarse acá.
Crear índices es crucial en el contexto de Azure AI Search y RAG porque permiten una búsqueda eficiente y estructurada de datos. Los índices organizan y optimizan la información, facilitando la recuperación de datos específicos de manera rápida. Esto mejora la precisión de las consultas y permite manejar grandes volúmenes de información, haciendo más efectiva la integración de modelos de lenguaje con tus datos. Al implementar múltiples índices, puedes experimentar con diferentes estructuras y compresiones, lo que resulta en un sistema más robusto y adaptable.
