Cualquier forma de contexto en la ingeniería de consultas es una referencia inestimable para generar una respuesta adecuada y precisa. Pero, ¿cómo dar cabida a una mayor cantidad de datos contextuales en una consulta generativa de OpenAI?
Tabla de contenidos
Introducción
Prompt Engineering for Generative LLMs ha surgido como una «cosa» con usuarios aprendiendo que un LLM no puede ser instruido directamente. Más bien, a través de un proceso de simulación e influencia del usuario, el LLM se diseña para dar la respuesta correcta, si tu quieres.
Las instrucciones contextuales suelen constar de tres secciones: instrucción, contexto y pregunta.
En un artículo anterior escribí sobre la importancia del contexto como referencia para los LLM generativos y cómo la alucinación de LLM puede ser negada por esto.
Sin embargo, uno de los retos que surgieron del artículo anterior fue cómo se puede utilizar un cuerpo de texto más grande (corpus) como referencia contextual.
De ahí que aquí recorra paso a paso el proceso de obtención de datos relevantes de Wikipedia sobre un tema concreto y su transformación. Creación de embeddings, y por último, cómo hacer referencia a los datos contextuales en una consulta.
🌟 Sígueme en LinkedIn para actualizaciones sobre IA conversacional 🙂
Embeddings
El reto es que a medida que las implementaciones de OpenAI crecen en complejidad, la experiencia del usuario salta muy rápidamente de un entorno sin código a un entorno con código.
Para poder buscar en un corpus más amplio relacionado con la información sobre olimpiadas que hemos estado utilizando, es necesario crear embeddings de texto.
Las embeddings de texto de OpenAI miden la similitud semántica entre cadenas de texto.
Las embeddings son relevantes siempre que sea necesario detectar cualquier tipo de similitud semántica. Por ejemplo, búsquedas, clasificaciones, agrupaciones, etc.
En palabras de OpenAI:
Un embedding es un vector (lista) de números en coma flotante. La distancia entre dos vectores mide su parentesco. Las distancias pequeñas sugieren un alto grado de parentesco y las distancias grandes, un bajo grado.
A continuación se muestra un fragmento del archivo de datos pertinente de Wikipedia…
df = pd.read_csv('https://cdn.openai.com/API/examples/data/olympics_sections_text.csv') df = df.set_index(["title", "heading"]) print(f"{len(df)} rows in the data.") df.sample(5)
Y aquí puede ver el formato del archivo después de que se hayan creado las embeddings utilizando el modelo text-embedding-ada-002.
datafile_path = '/olympics_sections_document_embeddings.csv' df = pd.read_csv(datafile_path) df.sample(5)
El proceso de manipulación de datos y código es un proceso avanzado. Lea más sobre el aspecto de los datos y vea ejemplos de cuadernos aquí.
El resultado final, a continuación se ve una pregunta formulada con el resultado relevante.
Encontrarás toda la información en este enlace.
En conclusión
Para la búsqueda semántica, OpenAI ha abandonado su enfoque de búsqueda de documentos y lo ha sustituido por un embeddings model.
Se ha hablado mucho de aprovechar los LLM y crear resultados más predecibles y fiables. Siempre he sostenido que la única solución es afinar los LLM y crear modelos LLM personalizados para cada implementación específica.
Desde la perspectiva de OpenAI, no existe un panel de control ni un estudio de diseño de NLU/NLG, y la recopilación, transformación e ingestión de datos requiere un desarrollo personalizado.
Sin embargo, para lograr esto a escala, se requiere un enfoque de estudio sin código donde con una supervisión débil, los datos de entrenamiento no estructurados se pueden convertir en datos de NLU y NLG Design.
🌟 Sígueme en LinkedIn para actualizaciones sobre IA conversacional 🙂