El comienzo
Hace unos meses, mientras trabajaba en el taller Databricks con R, me encontré con algunas de sus funciones SQL personalizadas. Estas funciones particulares tienen el prefijo “ai_” y ejecutan PNL con una easy llamada SQL:
> SELECT ai_analyze_sentiment('I'm blissful');
constructive
> SELECT ai_analyze_sentiment('I'm unhappy');
unfavourableEsto fue una revelación para mí. Mostró una nueva forma de utilizar los LLM en nuestro trabajo diario como analistas. Hasta la fecha, había contratado LLM principalmente para tareas de desarrollo y finalización de código. Sin embargo, este nuevo enfoque se centra en utilizar LLM directamente contra nuestros datos.
Mi primera reacción fue intentar acceder a las funciones personalizadas a través de R. Con
dbplyr podemos acceder a funciones SQL en R, y fue genial verlas funcionar:
orders |>
mutate(
sentiment = ai_analyze_sentiment(o_comment)
)
#> # Supply: SQL [6 x 2]
#> o_comment sentiment
#> <chr> <chr>
#> 1 ", pending theodolites … impartial
#> 2 "uriously particular foxes … impartial
#> 3 "sleep. courts after the … impartial
#> 4 "ess foxes could sleep … impartial
#> 5 "ts wake blithely uncommon … blended
#> 6 "hins sleep. fluffily … impartialUna desventaja de esta integración es que, aunque se puede acceder a él a través de R, necesitamos una conexión activa a Databricks para poder utilizar un LLM de esta manera, lo que limita la cantidad de personas que pueden beneficiarse de él.
Según su documentación, Databricks está aprovechando el modelo Llama 3.1 70B. Si bien se trata de un modelo de lenguaje grande muy eficaz, su enorme tamaño plantea un desafío importante para la mayoría de las máquinas de los usuarios, lo que hace que no sea práctico ejecutarlo en {hardware} estándar.
Alcanzando la viabilidad
El desarrollo de LLM se ha acelerado a un ritmo rápido. Inicialmente, sólo los modelos de lenguaje grande (LLM) en línea eran viables para el uso diario. Esto generó preocupaciones entre las empresas que dudaban en compartir sus datos externamente. Además, el costo de utilizar LLM en línea puede ser sustancial y los cargos por token pueden acumularse rápidamente.
La solución perfect sería integrar un LLM en nuestros propios sistemas, requiriendo tres componentes esenciales:
- Un modelo que cabe cómodamente en la memoria
- Un modelo que logra suficiente precisión para tareas de PNL
- Una interfaz intuitiva entre el modelo y el portátil del usuario.
El año pasado, tener estos tres elementos period casi imposible. Los modelos capaces de encajar en la memoria eran inexactos o excesivamente lentos. Sin embargo, avances recientes, como llama de meta
y motores de interacción multiplataforma como Ollamahan hecho factible la implementación de estos modelos, ofreciendo una solución prometedora para las empresas que buscan integrar LLM en sus flujos de trabajo.
el proyecto
Este proyecto comenzó como una exploración, impulsada por mi interés en aprovechar un LLM de “propósito common” para producir resultados comparables a los de las funciones de IA de Databricks. El desafío principal fue determinar cuánta configuración y preparación se requeriría para que un modelo de este tipo entregara resultados confiables y consistentes.
Sin acceso a un documento de diseño o código fuente abierto, confié únicamente en los resultados del LLM como campo de pruebas. Esto presentó varios obstáculos, incluidas las numerosas opciones disponibles para ajustar el modelo. Incluso dentro de una ingeniería rápida, las posibilidades son enormes. Para asegurarme de que el modelo no fuera demasiado especializado ni se centrara en un tema o resultado específico, necesitaba lograr un delicado equilibrio entre precisión y generalidad.
Afortunadamente, después de realizar pruebas exhaustivas, descubrí que un easy mensaje “de una sola vez” daba los mejores resultados. Por “mejor” quiero decir que las respuestas fueron precisas para una fila determinada y consistentes en varias filas. La coherencia period essential, ya que significaba proporcionar respuestas que fueran una de las opciones especificadas (positivas, negativas o neutrales), sin explicaciones adicionales.
El siguiente es un ejemplo de un mensaje que funcionó de manera confiable en Llama 3.2:
>>> You're a useful sentiment engine. Return solely one of many
... following solutions: constructive, unfavourable, impartial. No capitalization.
... No explanations. The reply is predicated on the next textual content:
... I'm blissful
constructiveComo nota al margen, mis intentos de enviar varias filas a la vez no tuvieron éxito. De hecho, dediqué una cantidad significativa de tiempo a explorar diferentes enfoques, como enviar 10 o 2 filas simultáneamente y formatearlas en formatos JSON o CSV. Los resultados fueron a menudo inconsistentes y no parecían acelerar el proceso lo suficiente como para que valiera la pena el esfuerzo.
Una vez que me sentí cómodo con el enfoque, el siguiente paso fue incluir la funcionalidad dentro de un paquete R.
El enfoque
Uno de mis objetivos period hacer que el paquete del centro comercial fuera lo más “ergonómico” posible. En otras palabras, quería asegurarme de que el uso del paquete en R y Python se integra perfectamente con la forma en que los analistas de datos usan su lenguaje preferido a diario.
Para R, esto fue relativamente sencillo. Simplemente necesitaba verificar que las funciones funcionaran bien con las tuberías (%>% y |>) y podría incorporarse fácilmente en paquetes como los del tidyverse:
evaluations |>
llm_sentiment(evaluation) |>
filter(.sentiment == "constructive") |>
choose(evaluation)
#> evaluation
#> 1 This has been the most effective TV I've ever used. Nice display screen, and sound.Sin embargo, para Python, ser un lenguaje no nativo para mí significó que tuve que adaptar mi forma de pensar sobre la manipulación de datos. Específicamente, aprendí que en Python, los objetos (como los Pandas DataFrames) “contienen” funciones de transformación por diseño.
Esta concept me llevó a investigar si la API de Pandas permite extensiones y, afortunadamente, ¡así lo hizo! Después de explorar las posibilidades, decidí empezar con Polar, lo que me permitió ampliar su API creando un nuevo espacio de nombres. Esta easy adición permitió a los usuarios acceder fácilmente a las funciones necesarias:
>>> import polars as pl
>>> import mall
>>> df = pl.DataFrame(dict(x = ["I am happy", "I am sad"]))
>>> df.llm.sentiment("x")
form: (2, 2)
┌────────────┬───────────┐
│ x ┆ sentiment │
│ --- ┆ --- │
│ str ┆ str │
╞════════════╪═══════════╡
│ I'm blissful ┆ constructive │
│ I'm unhappy ┆ unfavourable │
└────────────┴───────────┘Al mantener todas las funciones nuevas dentro del espacio de nombres llm, resulta muy fácil para los usuarios encontrar y utilizar las que necesitan:
¿Qué sigue?
Creo que será más fácil saber lo que vendrá. mall una vez que la comunidad lo usa y proporciona retroalimentación. Anticipo que la solicitud principal será agregar más backends de LLM. La otra posible mejora será cuando haya nuevos modelos actualizados disponibles, entonces es posible que sea necesario actualizar las indicaciones para ese modelo determinado. Experimenté esto al pasar de Llama 3.1 a Llama 3.2. Period necesario modificar una de las indicaciones. El paquete está estructurado de manera que los ajustes futuros como ese serán adiciones al paquete y no reemplazos de las indicaciones, para conservar la compatibilidad con versiones anteriores.
Esta es la primera vez que escribo un artículo sobre la historia y estructura de un proyecto. Este esfuerzo en explicit fue tan único debido a R + Python y sus aspectos LLM, que pensé que vale la pena compartirlo.
Si deseas aprender más sobre mallno dudes en visitar su sitio oficial:
https://mlverse.github.io/mall/
