De un piloto fallido a un sistema ideal: cómo aprendimos a trabajar con proyectos LLM
LLM es una de las áreas más desafiantes e interesantes de Data Light. Soy Victoria Yanysheva y participo en proyectos de LLM en la empresa.
En este artículo, le contaré cómo realicé el primer piloto fallido con mi equipo, qué conocimientos sobre el proceso aprendí de él y cómo los apliqué posteriormente en proyectos exitosos. Hablemos de trabajar con evaluadores y validadores y de cómo hacer un producto de calidad en un campo cuya principal especificidad es la subjetividad y la ausencia de una verdad única.
Si trabajas con proyectos LLM en tu empresa, y especialmente si estás pensando en hacerlo, ¡no dejes de leer este artículo! Te hablaré de los errores y cómo no repetirlos, y de los éxitos y cómo conseguirlos.
El primer piloto falló. ¿Qué salió mal?
Inicialmente, un cliente vino a nosotros con una tarea interesante: nos pidió crear un grupo de diálogos entre un niño y un asistente virtual. Nuestro problema fue nuestra falta de experiencia: no pudimos hacer las preguntas adecuadas al cliente y él tampoco proporcionó detalles ni buenos ejemplos en los que basarse. Pero asumimos esta tarea y comenzamos a crear.
Como resultado, fue un piloto muy difícil, pero el cliente, desafortunadamente, se fue con comentarios extraños: o los niños no preguntaron eso, o deberían haber usado una palabra diferente. Al final, el cliente escribió que volvería cuando tuviera criterios más precisos.
Fue difícil entender qué hicimos mal exactamente. Pero al final tomamos estos desarrollos para el siguiente proyecto y todo salió bien.
¿Cómo trabajamos en el primer piloto?
Para empezar, construí procesos y dividí a todos en tres equipos. El plan, que implementamos con modificaciones en los siguientes proyectos, fue el siguiente:
Decidimos asignar a cada equipo un área de responsabilidad específica. El primer equipo estaba generando un aviso, que tenía una plantilla y muchas opciones de combinación, es decir, una matriz con temas y contexto.
Luego había que añadir los diálogos a la plantilla: de qué se trataría ese diálogo, cómo se comportaría el asistente y cómo se comportaría el niño. Este producto tuvo que ingresarse en la tabla y verificar su singularidad. Implementamos esto en el siguiente proyecto, pero no tuvimos tiempo para este.
El segundo equipo incluía operadores que colocan el proyecto en ChatGPT, lo modifican mediante solicitudes adicionales y aquí también debería verificarse la unicidad mediante scripts. En esta etapa ya contábamos con redactores en el equipo para darle realismo a nuestros diálogos y adaptarlos a las reglas del pliego de condiciones técnicas.
Luego tuvimos la tercera etapa: los editores debían etiquetar por contexto y tema, así como por el número de réplicas. Los diálogos tuvieron que dividirse en tres partes: diálogos ordinarios, inaceptables (el niño dijo obscenidades) y diálogos tóxicos, que los evaluadores tuvieron que probar como parte del piloto.
¿Cómo fue tu primer proyecto exitoso?
Literalmente, un par de semanas después, otro cliente vino a nosotros con una tarea similar, pero con algunas diferencias. Era más fácil: requería crear diálogos entre el asistente del banco y el usuario de la plataforma.
Inicialmente, la idea era utilizar exactamente el mismo esquema que en el primer proyecto, es decir, volver a crear tres equipos separados. El primero son las personas que, utilizando una plantilla con una matriz de ejemplos, generan mensajes para ChatGPT. El segundo equipo son los evaluadores, quienes envían este mensaje a ChatGPT y lo mejoran con solicitudes adicionales.
El tercer equipo son las personas que hacen redacción, es decir, corrigen el texto, lo hacen más humano y también ponen ciertas etiquetas en este diálogo. El tercer equipo tendría que entender cuál es el humor de este diálogo: ¿agresivo, neutral, positivo? ¿Se utilizaron emoticones? ¿Qué temas se discutieron? Luego, los artistas tuvieron que agregar etiquetas para indicar el número de pares de líneas en el diálogo.
Este sistema sería perfecto para un proyecto más complejo, pero durante la prueba piloto nos dimos cuenta de que la tarea no requería un enfoque tan multinivel. Como resultado, reunimos todas estas funciones en un solo evaluador, que tendría que realizar tres etapas.
También en este proyecto, implementamos un script para verificar la unicidad. Esto era necesario para que cada uno de nuestros diálogos fuera exactamente diferente en tema y líneas. Usando el script, todas las indicaciones e ideologías de ChatGPT se recopilaron en una única base de datos y se compararon entre sí según la cantidad de caracteres coincidentes.
Primer proyecto de marcado LLM
Un poco más tarde, un cliente vino a nosotros con el primer proyecto de marcado LLM, donde nos dieron reseñas de servicios o productos, y con la ayuda de ChatGPT nuestro cliente generó boletines, es decir, las principales frases importantes que se destacaron dentro de la reseña. . Estas viñetas tuvieron que evaluarse en función de la retroalimentación.
Este fue el primer proyecto de marcado bastante complejo y contextual, así como el primer proyecto con este nivel de subjetividad. Nunca antes habíamos trabajado con tareas similares.
Para empezar, pusimos gran énfasis en la selección de los participantes, desarrollamos nuestra tarea de prueba, que evaluaba el pensamiento crítico, la atención, el conocimiento de la ortografía y la puntuación de una persona.
También comenzamos a aplicar nuevos enfoques en la comunicación: desarrollamos varios formatos de interacción con el equipo y nos reunimos para eventos interactivos, para los cuales preparamos algún tipo de presentación con anticipación. En la diapositiva mostramos los puntos principales en los que los evaluadores cometen errores. Al inicio de la reunión hablamos de todos ellos y añadimos información de las especificaciones técnicas.
Nuestra interacción entonces fue así: teníamos tres diapositivas para cada caso. Expresamos la tarea a los artistas y esperamos hasta que todos respondieron. Entonces comenzó la discusión.
Y sólo después de que todos hubieron hablado, mostramos la respuesta correcta. Juntos alineamos su lógica y corregimos errores. En la tercera diapositiva insertamos texto de las especificaciones técnicas, en las que se podría confiar para resolver un caso particular.
Además, como parte de este proyecto, por primera vez comenzamos a utilizar una utilidad para comprobar el idioma ruso. Cuando recién comenzamos nuestro primer proyecto LLM sobre marcado, no teníamos la condición de que fuera necesario volver a verificar la exactitud de las viñetas desde el punto de vista del idioma ruso. Y, aunque los artistas debían realizar una prueba de conocimientos de puntuación y ortografía antes de comenzar a trabajar, todavía era bastante básica y dentro del proyecto se encontraron reglas bastante complejas.
En el proceso nos dimos cuenta de que, al final, a menudo nos topamos con boletines redactados incorrectamente en los que no se respetan las reglas del idioma ruso, y nos dirigimos al cliente. Nuestro cliente escuchó y decidió agregar dicha resolución para luego poder corregirla por separado con la ayuda exclusivamente de redactores. Es por eso que presentamos una utilidad que resaltaba frases para artistas que estaban formuladas incorrectamente en términos de vocabulario y estilo.
Y en todas partes utilizamos también una utilidad de navegador para resaltar las raíces de las palabras con colores. Es decir, ingresamos de antemano una especie de lista de palabras que aparecen con bastante frecuencia y están resaltadas, para que el trabajo sea más rápido y el intérprete definitivamente no se pierda nada.
En su experiencia, ¿cuáles son las características específicas de los proyectos LLM?
Esto es principalmente subjetividad. Incluso desde el punto de vista de la validación, tanto el evaluador como el validador pueden tener razón, pero ¿cómo encontrar cuál es la respuesta correcta? Cada caso es único; no podemos componer las especificaciones técnicas de manera que describan cada caso que encuentra el marcador. Por supuesto, damos algunas anclas o direcciones, una lista de antiejemplos, analizamos casos extremos y decimos qué sería lo correcto aquí, pero no hay una verdad única.
¿Cómo organizar adecuadamente el trabajo con los evaluadores en la dirección de ML? 3 consejos principales de Victoria:
Interactuar muy estrechamente con los evaluadores, trabajar en su implicación y entender cómo motivarlos. Por eso, organizamos muchas reuniones y discusiones, controlamos el estado de ánimo y el estado.
Siempre les decimos a los evaluadores que nuestras llamadas, revisiones, capacitación y simuladores representan solo el 50% del éxito. El 50% restante depende sólo de ellos, de su deseo de resolverlo, de lo contrario no lo conseguirán.
También es necesario examinar cada regla y cada línea de las especificaciones técnicas desde ángulos completamente diferentes. Es decir, si en proyectos normales todo es bastante obvio, entonces al aplicar cualquier regla es necesario pensar en cómo puede afectar a todas las demás y mirar el panorama general desde el punto de vista de todo el proyecto para mantener la lógica. para los chicos y no romperles los marcadores.
