Profundiza en tus documentos con Search Tuning usando Google Cloud Vertex AI Agent Builder

Lo primero es lo primero: como developers, los nombres nos importan, y como puede haber sido difícil seguirles el ritmo a los nombres de producto de estas funciones, vamos a aclararlo. Inicialmente se presentó como Gen App Builder a principios de 2023; poco después pasó a llamarse Vertex AI Search and Conversation, y hoy se conoce como Vertex AI Agent Builder.

Ahora que aclaramos eso y sabemos cómo llamarlo, ¡veamos qué puede hacer por nosotros!

Vertex AI Agent Builder es la forma en que Google Cloud te facilita, a ti y a tu negocio, sacarle partido a la IA generativa. Abstrae gran parte del trabajo necesario para construir una IA conversacional, una experiencia de búsqueda semántica o incluso un sistema de Retrieval Augmented Generation (RAG), y te permite apoyarte en sus modelos fundacionales de última generación y en su tecnología de búsqueda mundialmente reconocida, fruto de 25 años de desarrollo.

En comparación con otras propuestas de la suite Vertex AI (por ejemplo, la API de Gemini 1.5 Pro o Vector Search), se ubica en el extremo más gestionado del espectro y, por lo tanto, ofrece menos personalización y flexibilidad, algo que se compensa con un menor time-to-market y una menor dependencia de talento interno especializado, que suele escasear.

Dentro de Vertex AI Agent Builder tenemos acceso a Vertex AI Agents y a Vertex AI Search:

• Vertex AI Agents ofrece una forma sencilla de construir interfaces conversacionales sobre una plataforma de comprensión del lenguaje natural basada en grandes modelos de lenguaje (LLM).
• Vertex AI Search, por su parte, te ayuda a crear experiencias de búsqueda y recomendación con IA.

Hoy nos enfocaremos en Vertex AI Search, ya que es el producto que ofrece Search Tuning y para el cual presentaremos un script de verificación de datos.

Para una introducción completa, consulta la documentación aquí.

Dentro de Vertex AI Search tenemos la opción de construir apps de búsqueda y apps de recomendación. Hoy nos centraremos en las apps de búsqueda.

Algunas de las funciones clave son:

• Comprensión del lenguaje natural y búsqueda semántica listas para usar. La búsqueda semántica entiende el contexto y la intención detrás de una consulta. En cambio, los enfoques más tradicionales, como la búsqueda por palabras clave, dependen de la coincidencia exacta de términos específicos sin comprender el razonamiento ni el contexto detrás de ellos. Por ejemplo, cuando buscamos: "¿Cuándo anunció Apple el último iPhone?", la búsqueda semántica entenderá que estamos hablando de Apple Inc. y no de tu fruta favorita.
• Capacidades listas para usar para entender sinónimos, corregir la ortografía y autosugerir búsquedas.
• Resúmenes y búsqueda conversacional con IA generativa para documentos no estructurados. Por ejemplo, podemos decidir qué tipo de respuestas se devuelven:

- Búsqueda (de un solo turno)

- Búsqueda con respuesta (búsqueda de un solo turno con resumen)

- Búsqueda con seguimientos (búsqueda multiturno)

Configurar Vertex AI Search consta, a alto nivel, de 2 etapas:

1. Preparación: configuramos un data store e ingestamos nuestros datos estructurados o no estructurados. Estos se procesan, se dividen en chunks y se les generan embeddings junto con sus metadatos. Se almacenan para su recuperación en la base de datos vectorial de alto rendimiento de Google Cloud, llamada Vector Search. Aún así, tienes algunas opciones de personalización: puedes aportar tu propio esquema, tus propios embeddings (en Preview al momento de escribir esto) e incluso personalizar el parseo y el chunking.
2. Tiempo de ejecución: aquí es cuando hacemos la consulta real con la entrada del usuario. Se recuperan los documentos relevantes y se genera una respuesta a partir de ellos (si así lo deseas). También aquí hay margen para personalizar: por supuesto, puedes traer tus propios prompts, especificar ciertos controles, por ejemplo para filtrar los resultados devueltos, y decidir si quieres respuestas cortas (snippets) o párrafos más largos (extractive answers o segmentos) en tus respuestas. Lo que no puedes hacer es traer tu propio ranker, ¡pero más sobre eso a continuación!

Ejemplo de un segmento extractivo en un data store de datos no estructurados (PDF). Observa que el número de página del archivo original se incluye en la referencia. (captura ajustada por motivos de espacio)

Entonces, ¿qué pasa si no estás 100% satisfecho con la calidad de los resultados de búsqueda que obtienes? Puedes recurrir a la función Search Tuning (en Preview al momento de escribir esto) para tus data stores no estructurados. Imagina que los datos sobre los que quieres buscar son muy específicos de tu empresa: eso puede dificultarle a un modelo genérico hacer una recuperación precisa. Pero podemos ayudar; ¡y para eso solo necesitamos darle algunos datos!

¿Cómo se usa Search Tuning?

En concreto, necesitarás aportar 3 conjuntos de datos de entrenamiento, y potencialmente un cuarto:

1. Consultas de entrenamiento: son las consultas de búsqueda que esperas que tus usuarios hagan al sistema. Por ejemplo:

¿Cuál es la proporción máxima de estudiantes por instructor para inmersiones en aguas confinadas?

2. Segmentos extractivos: son fragmentos tomados de los documentos del data store (tu corpus). Algunos segmentos deberán responder a algunas de las consultas definidas arriba, otros no (cada tipo cumple su propio propósito: refuerzan al modelo de forma positiva o de forma negativa). Estos segmentos también deben tener una longitud suficiente. Por ejemplo:

## Proporciones

### Aguas confinadas 10:1 — Pueden añadirse cuatro estudiantes buzos por asistente certificado.

### Aguas abiertas 8:1 — Pueden añadirse dos estudiantes buzos por asistente certificado.

3. Puntuaciones de relevancia: estas etiquetas de entrenamiento relacionan las consultas con los segmentos extractivos mediante una puntuación (entero no negativo) en la que 0 indica que el segmento no es relevante para la consulta, y cuanto más alta es la puntuación, más relevante es el segmento para una consulta determinada. Por ejemplo:

La puntuación de relevancia en este caso sería 1, ya que el segmento es relevante para la pregunta planteada.

4. (Opcional) Etiquetas de prueba: estos datos son similares a las puntuaciones de relevancia, pero se usan para evaluar el rendimiento del modelo afinado. Si no proporcionamos estos datos por nuestra cuenta, Search Tuning utilizará el 20% de las consultas de las etiquetas de entrenamiento definidas en el punto 3.

¿Qué podría salir mal?

Estos datos se entregan como archivos y deben tener un formato específico, además de cumplir ciertos requisitos. Sin embargo, algunos de nuestros clientes tuvieron problemas al intentar usar el servicio: les aparecía el código de error 13, con el mensaje "Internal error encountered. Please try again. If the issue persists, please contact our support team.".

La causa raíz resultó ser que no todos los archivos cumplían con los requisitos descritos en la documentación, pero, lamentablemente, el mensaje de error no daba esa pista. ¡No te desesperes; DoiT al rescate! Programamos algunas verificaciones simples que te ayudarán a detectar cuanto antes los archivos mal formateados y a evitar el error. Está disponible en GitHub y se ejecuta de forma muy sencilla:

python search_tuning_checks.py.py <corpus_path> <query_path> <scoring_path>`.

Un ejemplo de salida podría verse así:

General dataset checks
 - - - - - - - - - - -
Number of segments in Corpus file that don't have a match in Scoring file: 6030
Number of segments in Scoring file that don't have a match in Corpus file: 1551
Number of queries in Query file that don't have a match in Scoring file: 0
Number of queries in Scoring file that don't have a match in Query file: 0
Documentation dataset checks
 - - - - - - - - - - - - - -
Training query requirements met: ✅ met
|___ Subcheck: At least one extractive segment per query: ✅ met
|___ Subcheck: At least 10 000 additional extractive segments: ✅ met
Extractive segment requirements met: ✅ met
Relevance score requirements met: ✅ met
|___ Subcheck: At least 100 segments that contain query answers: ✅ met
|___ Subcheck: At least 10 000 random segments: ❌ not met
|___ Subcheck: At least 10 000 segments with 0 as score: ✅ met
Corpus file requirements met: ❌ not met
Query file requirements met: ✅ met
|___ Subcheck: Same ids in query and scoring data: ✅ met
|___ Subcheck: Column 'score' contains non-negative integer values: ✅ met
Training labels requirements met: ✅ met

Las `general data checks` simplemente hacen una verificación de integridad de los datos proporcionados: que todos los IDs de los segmentos correspondan a una puntuación, por un lado, y que todos los IDs de las consultas correspondan a una puntuación, por el otro.

Las `documentation dataset checks` ejecutan las siguientes verificaciones, recogidas en la documentación de Google Cloud:

• Para los datos de entrenamiento en general (las primeras 3 verificaciones)
• Para el archivo Corpus
• Para el archivo Query
• Para el archivo Training labels

Vale la pena asegurarse de tener un '✅' en todo antes de enviar los archivos, ya que el ciclo de feedback puede tardar varias horas.