Potenciando el Asistente de Código Cody utilizando LLMs

Genial. Buenas tardes a todos. Gracias por volver. Gracias por quedarse. Es como una sala vacía. Esperemos que la gente participe.

Mi nombre es Rishabh. Esta introducción está desactualizada porque estaba trabajando en personalización, y ahora estoy trabajando en ML generativo. Soy el jefe de IA en SourceCraft.

Solo una rápida muestra de manos, ¿cuántos de ustedes conocen a Cody? ¿Algunos? Ok. Bien. ¿Cuántos de ustedes están usando algún asistente de codificación, incluyendo Copilot o Cody? Algunos. Bien, genial. Así que hoy vamos a hablar mucho sobre qué tipo de problemas de ML enfrentamos, a alto nivel, cuáles son los diferentes componentes del sistema y cómo evaluamos esto, cómo pensamos en el contexto alrededor de esto, en esencia.

Un poco de contexto. Crecí en India. Estaba haciendo mi doctorado en búsqueda y recomendaciones. Estaba en Spotify investigando sobre recomendaciones de música, toma de decisiones multiobjetivo y recientemente estoy trabajando en ML de código. Así que vengo de un fondo de aprendizaje automático y lo aplico a las recomendaciones de medios y ahora al dominio de la codificación.

Hoy vamos a hablar sobre cuatro temas principales. Cinco minutos cada uno, aproximadamente. Comenzaremos hablando sobre qué hacen en general los asistentes de codificación. Esto es similar a lo que hacen Cody, Copilot y otros, pero mencionaré uno o dos matices sobre estos problemas. Pasaremos la mayor parte del tiempo hablando sobre cómo se ve el stack, qué problemas hay en el contexto, qué problemas hay en los modelos, qué problemas hay en la evaluación y cuáles son los matices allí. Hacia el final de los últimos cinco a ocho minutos, resumiré hacia dónde vamos ¿Cómo se ve el nivel de IA en el código? ¿Dónde estamos ahora, qué creemos que podría venir en el futuro y luego mi tema favorito, la automatización de tareas complejas, y compartir algunas ideas al respecto.

Genial. Si comenzamos con Cody, entonces Cody es un asistente de codificación. Vive en tu navegador, en tu IDE. Así que si estás usando VSCode, JetBrains, Eclipse, cualquiera de estos IDE con los que estés trabajando, es un tipo de asistente de codificación que te ayuda a ser un desarrollador más productivo. Y especialmente lo que eso significa es que tenemos características como autocompletar que dice que si estás escribiendo código, podemos ayudarte a escribir código más rápido.

Así que puedes code más rápido utilizando LLMs. Un ejemplo aquí sería que, oye, estoy escribiendo code, pero lo estoy haciendo en un repositorio grande. Así que hay un contexto sobre lo que estoy tratando de hacer. Y no se trata solo de este archivo, hay algún otro contexto en alguna otra parte del repositorio o tal vez en algunos otros repositorios también. Comienzas a escribir el completado correcto. Sugerir eso. Y cuando estás sugiriendo, puedes hacer un completado de una sola línea o un completado de varias líneas también. Y luego las latencias y todo tipo de factores entran en juego allí. Así es como se ve el completado.

También puedes chatear sobre repositorios, sobre tu code. Imagina que eres un nuevo desarrollador en un equipo y quieres entender de qué se trata esta base de código. Entonces entrarás y dirás, oye, cuéntame sobre esto. O si quiero hacer esto, simplemente chatea sobre tu base de código, básicamente. También puedes comenzar a ver la generación de unit test. Y el problema sería que selecciono un fragmento de code y luego puedo ir a Coddy y decir, ¿puedes generar una unit test para esto, por favor? También puedes ver la explicación del code. Y puedes decir simplemente ponerse al día. Similar al chat, pero más centrado en la explicación. También puedes ver los malos olores en el code. Así que los malos olores en el code son formas de encontrar cómo puedo optimizar un poco más este code. También puedes extenderlo a la security y detección de vulnerabilidades y muchas otras cosas. Y la lista continúa. También puedes crear comandos personalizados, lo que significa que si hay algo que haces diez veces al día, es mejor crear un comando personalizado y dejar que Coddy lo haga por ti. Estos son los casos de uso por los que la gente está utilizando actualmente Coddy. Ahora la pregunta es qué se necesita para construir esto. ¿Y de qué estamos hablando? Y parte de esto, el 70% de esto se superpone no solo con el asistente de codificación, sino también con cualquier co-piloto que veas en el mundo. Incluso si es un co-piloto de ventas, un co-piloto de marketing, un analista de riesgos, todas estas personas intentando desarrollar estos agentes para ayudar a algunos desarrolladores en la industria. La mayoría de estos problemas también son bastante comunes allí. Así que vamos a hablar de tres problemas aquí. El contexto, los modelos y la evaluación. Y todos estos son muy importantes. Y no es la primera vez que los vemos.

Estaba desarrollando una recomendación en Spotify. En Spotify teníamos el mismo problema. No sé lo que quieres. Quiero entender tu contexto. Quiero descubrir qué tipo de música quieres escuchar. Entonces, las fuentes de contexto allí son el tipo de música y los artistas que quieres escuchar. Los modelos que tenemos son LLMs. Los modelos que las personas tenían para las recomendaciones eran modelos de clasificación, modelos de recomendación. La evaluación es similar a los problemas en los que estamos pensando y a los problemas para los que se pensaron las recomendaciones. Entonces, el punto es que los problemas a los que nos enfrentamos en las aplicaciones de LLMs en este momento, el aprendizaje automático aplicado, esto no es nuevo. Lo hemos estado haciendo durante los últimos 15-20 años en búsqueda, en recomendaciones, y ahora estamos tratando de verlo en este nuevo dominio de aplicación.

Entonces hablemos primero sobre el contexto. La parte sobre el contexto, especialmente en una herramienta de code AI, es que todos enfrentamos este problema de código extenso. Y lo que significa código extenso es imagina que eres un desarrollador en un banco Fortune 500 en los EE. UU., ¿verdad? Tienes 20,000 desarrolladores en la empresa, tienes como 15,000 repositorios, millones y millones de líneas de code. Algunas de ellas fueron escritas hace 20 años. Entonces, ¿cómo haces una búsqueda y cómo sabes qué es relevante y qué no lo es?

Ese es el problema del código extenso. Es diferente cuando digo, `oye, escríbeme una búsqueda binaria en Rust`, entonces no hay necesidad de comprender el contexto del repositorio. Pero si soy un desarrollador en una gran empresa, necesito comprender lo que está disponible, qué tipo de APIs uso, qué tipo de pautas de estilo guidelines uso, y eso requiere mucha búsqueda de code. Entonces, aquí es donde entramos, como, `dada una consulta, una consulta puede ser una consulta de chat, una consulta de autocompletado, estoy tratando de hacer algo, ¿verdad? Si estoy tratando de hacer algo, entonces encuentra los fragmentos de code relevantes en el universo para mí, ¿verdad? Entonces, los desarrolladores, miran lo que estoy haciendo en mi IDE, miran los repositorios actuales, miran todos los repositorios en mi organización, y si creen que es necesario, miran todo el code que se haya escrito al que tienen acceso. No me importa. Solo quiero que me ayuden a hacer este trabajo mejor, ¿verdad?

Así que solo encuentra cualquier fragmento de code útil y relevante, úsalo, envíalo al LLM y obtén una respuesta correcta. La pregunta aquí es qué es relevante. Ahora, este es uno de los problemas más difíciles a los que todos los que trabajan en la industria de LLM se enfrentan en este momento. Esto es lo que te ayuda a reducir las alucinaciones. Si obtienes el contexto correcto, el LLM dará la respuesta correcta, pero luego no sabes cuál es el contexto correcto. Así que aquí te daré un ejemplo, ¿verdad? La pregunta aquí es, `oye, ¿cómo agregas algunas etiquetas en el conjunto de datos de completado que estoy creando?` Entonces estoy en un repositorio, inicio cody, hago esta pregunta. Dice, `según esto, aquí está lo que creo que es la respuesta correcta`. Si te acercas, entonces seleccionó ocho de estos elementos de contexto, ¿verdad? Y este es el contexto que estamos obteniendo. Hablaré sobre qué son y de dónde vienen. Pero el punto es que obtienes este elemento de contexto, el LLM lo utiliza. Ahora, ¿cómo sé si cada uno de estos ocho es correcto o no? Ese es un buen problema. Creo que aquí es donde la industria va a pasar los próximos tres o cuatro años resolviendo este problema, independientemente del dominio en el que estés trabajando, ya sea que tengas un conjunto de documentos, un conjunto de repositorios, un conjunto de videos, lo que sea en los dominios en los que estés trabajando. Contexto, recuperación, generación aumentada significa traer contexto relevante. Traes contexto relevante pero no sé si es correcto o no. ¿Por qué? Porque, sí, tal vez sea útil para esta consulta, tal vez no sea útil, tal vez agregue ruido, tal vez el LLM se distraiga o tal vez esto tenga la respuesta exacta que el LLM necesita para generar correctamente para ti. Pero esto es difícil de hacer en la práctica. Retrocedamos un paso.

Mi punto es que ya hemos hecho esto antes en recommendations. Pero no puedo reutilizar eso. En recomendaciones, si miras Spotify, ¿cuántos de ustedes usan Spotify? Genial. Por supuesto. Entonces, en Spotify, te recomendaría music ¿verdad? Podría incluir músicos locales, si estás en Ámsterdam, podría mencionar algunos artistas holandeses, podría mencionar música popular, de nicho, todas estas cosas, ¿verdad? Cada una de ellas son fuentes de contexto, cada una de ellas me proporciona un conjunto de artistas que potencialmente puedo recomendarte. Si elijo a un artista, te lo muestro, tú puedes saltar la canción, te gusta la canción, tú guardas la canción. Esa es la retroalimentación que obtengo. Luego puedo decir, hey, elegiste a este artista, el usuario guardó esa canción en la lista de reproducción y la reprodujo más tarde. Genial. Buen trabajo. Obtienes un punto positivo. Así que tenemos el bucle de retroalimentación en el sistema de búsqueda y recomendación. ¿Por qué? Porque tomamos el elemento, se lo mostramos al usuario, al usuario le gusta, no le gusta, interactúa, salta, y puedo entrenar mi modelo. Como ingeniero de ML, estoy contento. Aquí el problema es que nunca muestro estos elementos al usuario. Simplemente los envío al LLM. Así que nunca obtengo el bucle de retroalimentación. Este es el mayor problema al que se enfrenta la industria del contexto en este momento. ¿Por qué? Porque básicamente haces una pregunta, traes algunos fragmentos de code, nunca los muestras al usuario. Los envías al LLM, el LLM simplemente genera una respuesta y eso es todo. Así que nunca obtenemos esta etiqueta y por eso no puedo entrenar un modelo y no puedo evaluar cómo están funcionando mis fuentes de contexto. Y este es un problema al que se enfrentan los asistentes de codificación, cualquier aplicación basada en LLM en este momento. Y el problema aquí es cómo desarrollo modelos que puedan incorporar contexto. Y la propuesta aquí es que es un proceso de múltiples etapas. Tienes muchas, muchas fuentes de contexto, ¿verdad? Imagina Spotify y Netflix. Si miras TikTok, mostrará videos cortos sobre alguna tendencia a la baja que está sucediendo en los Países Bajos en este momento, algún evento popular que está sucediendo. Sé que sigues a estos creadores, así que voy a mostrar algunos videos de esos creadores. Va a traer muchas, muchas fuentes de contexto y luego va a seleccionar las cinco más útiles para ti y luego mostrarlas. Ahora, este es un proceso de dos pasos. Traes algunos elementos, donde estás optimizando para el recall. Recall significa que si hay algo útil, ¿lo estoy trayendo o no? Ahora tienes tres o cuatro fuentes candidatas, estás trayendo muchos, muchos elementos y asegurándote de no perder ninguna información relevante.

El segundo paso del clasificador, el clasificador dice que, genial, ustedes han traído suficientes elementos, permítanme seleccionar los mejores y elegir los cinco mejores y enviarlos al LLM. Así que ese es el proceso de dos pasos. Tienes muchas, muchas fuentes candidatas que van a traer elementos, están optimizados para el recall y luego el clasificador entra, selecciona los mejores y luego los envía al LLM. Ese es el proceso de dos pasos.

Ahora, ¿qué significa exactamente eso en el mundo de la code AI, verdad? Y esto es lo que significa. Quiero decir, haces una búsqueda básica de palabras clave como BM25 o indexación de Zook o cualquier otra búsqueda de palabras clave que tengas. Así que eso es como una coincidencia exacta, ¿verdad? O coincidencia de palabras clave o reformulación de consultas y todo eso. Puedes hacer incrustaciones de vectores. Puedes incrustar el code, puedes incrustar la documentación del code, puedes incrustar un montón de cosas diferentes. Y luego incrustas la consulta. Y luego tienes la consulta, tienes el code incrustado y luego puedes hacer una similitud y traer algunos elementos relevantes. También puedes mirar los archivos locales del editor, ¿qué tipo de archivos estabas editando recientemente? Así que hay muchas y hay una larga lista de cosas en las que deberías estar buscando. Todas estas son piezas potencialmente relevantes de code que debería estar trayendo para ayudarte a responder esta pregunta. ¿Verdad?

Todas ellas traen algunos elementos. Pero la pregunta es cómo los clasifico. Porque puedes traer... Quiero decir, imagina que cada uno de ellos trae 50 o 100 elementos. Algunos de ellos se superpondrán, otros no. Tengo 150, 250 de cada uno de ellos. ¿Cómo elijo los 10 mejores y llego al LLM? Ese es el problema de clasificación. Y una vez que haces esta clasificación, luego puedes crear toda esta hermosa indicación y enviarla al LLM. Ahora, esta es exactamente la diferencia entre usar GPT, ChatGPT o cualquiera de los copilotos. Porque en ChatGPT, no sabe sobre el contexto de tu code, por lo que no puede traer los fragmentos de código relevantes. No puede darte la respuesta correcta porque simplemente no conoce el contexto. Y aquí la esperanza es que hayas desarrollado estos sistemas que realmente pueden entender el contexto. Ahora, este es el principal problema que mencioné. Que no sé. Como, quiero decir, en music, en videos cortos, y si abres Netflix, o ves el episodio, sigues adelante. Aquí hay data etiquetada. Puedo entrenar modelos. Aquí, no tengo data etiquetada.

Entonces, dependemos de señales de supervisión débil. Hay todo un campo de aprendizaje automático que se centra en cómo... No tengo etiquetas. Creemos etiquetas. Obtengamos datos sintéticos. Estas son señales de supervisión débil. No son exactamente correctas, pero casi correctas. Entrenemos con ellas. Eso es uno.

El otro problema es que no solo tengo que clasificar código. Porque en un mundo de... Si estás en una empresa, no solo estás mirando código. Estás mirando problemas de Jira, documentación, mensajes de LAC, problemas lineales y todas las demás hojas de ruta que has creado, ¿verdad? Entonces, ahora mi clasificador no solo tiene que clasificar código. También tiene que clasificar contenido heterogéneo. Nuevamente, hemos visto este problema antes.

Si miras TikTok, si miras WeChat en China, WeChat clasifica aplicaciones y videos cortos e imágenes y videos largos y noticias, todo en el mismo feed. Tu página de Instagram, ¿verdad? Vas a Instagram, Instagram tiene una mezcla de imágenes, videos cortos, videos largos, todo combinado. Vas a Spotify, clasifica podcasts, música, todo junto. En la industria, hemos abordado la clasificación heterogénea antes. Simplemente no lo hemos hecho para los LLM, ¿verdad? Entonces hay muchas similitudes que podemos llevar a cabo. Lo que significa es que ahora puedo comenzar a desarrollar funciones relevantes y clasificar módulos para otras fuentes de contexto también. Entonces, aquí es donde comienzas a traer código no digital, pero también un montón de otras fuentes de contexto, todo para tener suficiente información para responder mejor tu pregunta. Y la pregunta puede no estar formulada, podría ser escribir un mejor caso de uso para ti, prueba unitaria para ti, explicar tu código mejor o incluso completar tu código mejor, ¿verdad? Entonces, de eso se trata el contexto, ¿verdad?

Pasando rápidamente a los modelos. Ahora tenemos muchos modelos de ML, ¿verdad? Disponibles hasta ahora. Y Kodi también te ofrece una opción. Y esta es una de las diferencias entre algunos de los otros sistemas de codificación en comparación con Kodi. Puedes elegir qué LLM quieres según tu elección, según la latencia y todos los otros requisitos. El punto es que cada una de estas características exige diferentes compensaciones de latencia. Cuando estás completando código, no vas a esperar dos segundos. Lo necesitas en 300, 400 milisegundos.

Entonces, ahí es donde tengo que recurrir a modelos pequeños. No estoy esperando un code llama 3, que tiene 70 mil millones de parámetros, eso llevará mucho tiempo. Pero si estoy trabajando en un agente o chat, puedo esperar tal vez 800 milisegundos, tal vez 1.2 segundos, porque quiero hacerlo bien. Tómate tu tiempo. Tómate toda la noche, pero escribe el code correcto. Entonces, hay un... Mi punto es que estos números son ficticios. Pero entiendes la idea de este compromiso. Que, hey, para algunos casos de uso, necesito modelos más rápidos. Para otros, necesito mejores modelos. Tómate tu tiempo.

Y eso significa que hay algunos LLM pequeños que son... Hay algunos LLM más grandes que se prefieren. Pero también hay una curva interesante entre el performance y las latencias, ¿verdad? Comienzas a ver que, hey, algunos de estos modelos más pequeños funcionan mucho mejor en cuanto a latencias. No es solo, como, hey, ¿cuál es la mejor métrica en general en cuanto a calidad? No, tengo que hacer este compromiso en consecuencia. Y la pregunta entonces es... ¿Puedo tomar este modelo pequeño y mejorarlos? Y eso es lo que hicimos. Tomamos algunos de estos modelos más pequeños, los ajustamos finamente y los hicimos más eficientes.

Y para hacer eso, no es solo, hey, ajustar finamente todo. Es un ajuste fino específico de la tarea. Lo que quiero decir con eso es que si estás trabajando en code, no solo se trata de completar de izquierda a derecha. Tienes que hacerlo con prefijos y sufijos. Esto es rellenar en el medio. Porque si estás escribiendo este code, ¿verdad, tienes información arriba del code, debajo del code, tienes que usar todo eso, y luego ajustar finamente en este conjunto de datos. Esto se llama entrenamiento de rellenar en el medio. Y esto simplemente mejora mucho la completación de código. Quiero decir, vimos mejoras significativas que estamos implementando para los usuarios de code en este momento.

Finalmente, también vemos diferencias entre los lenguajes. Quiero decir, en el eje Y, tienes algunas métricas de code. En el eje X, tienes los lenguajes.

¿Qué hacemos? Tal vez podamos hacer un ajuste fino específico del lenguaje. Y eso es lo que hicimos. Dijimos que, hey, quiero mejorar un modelo para Rust. No es que los modelos predeterminados no sean lo suficientemente buenos en Rust. Ajustémoslos finamente. Y vimos una mejora de más del 20% en el rendimiento una vez que comenzamos a ajustar finamente solo para Rust. Y escribimos una publicación en el blog, la publicamos hace un par de días sobre esto. Entonces, nuevamente, el punto es, en el mundo de los modelos, puedes comenzar a considerar el ajuste fino de modelos para tareas, para diferentes requisitos de latencia y casos de uso.

Finalmente, la evaluación, ¿verdad? Voy a pasar rápidamente por esto. Pero en términos de evaluación, estás mirando las evaluaciones específicas de componentes y de extremo a extremo, ¿verdad? Nuevamente, esta es toda la pila para la mayoría de las aplicaciones de LLM que existen. No solo asistente de código. Tienes la consulta del usuario, estás haciendo algún procesamiento, estás obteniendo contexto, estás clasificando contexto, enviándolo al LLM, obteniéndolo, haciendo algún preprocesamiento y postprocesamiento y mostrándolo al usuario. Ahora, puedo hacer una evaluación específica de componentes. ¿Qué tan bien funciona mi contexto específico? Oh, ¿qué tan bien estoy clasificando? Tal vez las indicaciones del LLM no son buenas. Tal vez hagamos alguna optimización y lo hagamos. Evaluación específica de componentes. Y luego puedo ver el rendimiento general. ¿Cómo está funcionando mi motor de contexto? Esta es una evaluación general de extremo a extremo del motor de contexto. O ¿qué tan bien está funcionando Kodi en general? ¿Te está ayudando mejor? ¿No lo está haciendo? Entonces, mi punto es que hay muchas evaluaciones específicas de componentes y de extremo a extremo que tienes que hacer. Ahora, las necesidades de evaluación son diversas, ¿verdad? Necesito entender si estás trayendo el contexto correcto, si estás recuperando los elementos correctos, si tienes un conocimiento general de los LLM, del conocimiento. Tal vez haya una biblioteca de datos a gran escala. Y cuando se entrenó algún modelo, ni siquiera estaba al tanto de esta biblioteca. Entonces no tienes conocimiento general. Entonces eso es una evaluación. Hay muchas evaluaciones que tengo que hacer, ¿verdad? El punto clave es que tengo que hacerlo tanto en la evaluación fuera de línea como en línea.

Con la evaluación fuera de línea, me refiero a si tengo un nuevo modelo, nueva indicación, nuevo contexto, necesito saber, antes de enviarlo a los usuarios en una prueba A-B, ¿es mejor? ¿Vale la pena el esfuerzo de producción o no? Eso es la evaluación fuera de línea. Fuera de línea, lo implemento en una prueba A-B, ¿fue útil para mis usuarios o no? Tasa de aceptación de completado. Te mostré un completado, ¿lo aceptaste? Si lo aceptaste, ¿lo eliminaste cinco minutos después o persistió también?

La pregunta entonces es, en términos de iteración fuera de línea, si no tengo una evaluación fuera de línea, todo tiene que ser probado A-B. Solo vas a hacer F de ellos, como cinco de ellos en un mes. Si tienes una evaluación fuera de línea, puedes hacer 10X, 100X más. Ese es el valor de la evaluación fuera de línea. Pero para eso, necesitas asegurarte de tener una correlación entre la evaluación fuera de línea y en línea. Nuevamente, esto no es nuevo. Toda la industria de recomendaciones y búsqueda en Google, YouTube, Netflix, Spotify, tienen un ejército de investigadores de evaluación que se enfocan en la correlación entre la evaluación fuera de línea y en línea. ¿Por qué? Porque si tu evaluación fuera de línea dice que el modelo B es mejor que el modelo A en un 5%, lo pruebas en línea y resulta que no, el modelo A es mejor que el modelo B. Tu evaluación fuera de línea es mala, deberías desecharla. No puedo confiar en ella. Tiene que ser correcta en términos de dirección. Si dices que este modelo es mejor, lo pruebo en una prueba en línea, tiene que ser mejor. Y tiene que ser sensible. Si dice un movimiento del 5%, debería obtener un movimiento del 4% al 6%. Si dice que va a mejorar en un 5%, en línea solo mejora en un 0.1%, entonces también es inútil. Ese es el punto completo de la correlación entre la evaluación fuera de línea y en línea.

En el último minuto, quiero enfocarme en hacia dónde nos dirigimos. Esto es lo que está sucediendo en este momento. Estoy bastante seguro de que esto no se aplica solo a los asistentes de código. No se trata solo de Git o Cody o Sourcegraph. Creo que estos son problemas comunes en una serie de aplicaciones basadas en LLM en este momento. Porque todos tienen que iterar en el contexto, la evaluación, la clasificación, el ajuste fino de LLM, todo esto. Pero, ¿hacia dónde nos dirigimos? En términos de IA de código, Quinn, nuestro CEO, escribió una publicación de blog muy interesante, que se encuentra aquí, que divide la IA de código en tres categorías. Una es iniciada por humanos, que cruzamos hace aproximadamente un año, donde nos dirigimos a la creación de código y asistentes de código, y luego iniciada por IA. Ahora estamos comenzando a ver cómo se establecen estos marcos con agentes. En los que puedes hacer que el modelo de ML intente hacer algo por ti. Intervienes, dices que no es correcto, haces una iteración y luego lo haces. Y finalmente, liderada por IA, que es la autonomía total.

Probablemente estamos lejos de eso. Así que en este momento, estamos en algún punto entre tres y cuatro, según el tipo de función y el producto con el que trabajas.

El último punto es lo que más me gusta. Mi tema de doctorado fue una tarea compleja. Entonces, aquí es donde creo que, nuevamente, si tienes que adoptar un enfoque agente para algunos de estos code y escenarios no relacionados con el código, debes tener la capacidad de descomponer tareas complejas en planificación, sub tareas, intentar algunas tareas, ver si funciona o no, obtener ese ciclo de retroalimentación y luego unirlo todo.

Entonces, esto es una forma muy general de decir que necesitamos aprendizaje por refuerzo, planificación y descomposición de tareas, intentar cada una de estas sub tareas, obtener ese ciclo de retroalimentación en su lugar y luego entrenarlo de principio a fin. Ahora, aquí es donde, nuevamente, soy un ingeniero de machine learning que no pertenece al dominio del code en los últimos diez años, pero no tengo un ciclo de retroalimentación.

Hay muy pocos sistemas de compilación que puedo usar para obtener una retroalimentación de si este code funciona mejor o no. Imagina si estás en alguno de los grandes bancos, ¿verdad? Quiero decir, tu repositorio es enorme, millones de líneas de code. No puedo compilarlo. Si genero una unit test, me lleva horas compilarlo y probablemente algunos desarrolladores de tu empresa no pueden compilarlo en unos pocos minutos. El punto es que generas estas cosas, falta el ciclo de retroalimentación. Así que creo que esa es mi llamada completa, que, mira, una vez que podamos obtener ese ciclo de retroalimentación en su lugar, entonces podemos comenzar a automatizar algunas de estas tareas, paso a paso. Ahí es donde estamos.

Terminaré. Mirando la asistencia de codificación, especialmente Cody. Te ayuda a ser un mejor desarrollador. Mirando algunos problemas en el contexto, modelos, evaluación, algunos de los logros que has obtenido al ajustar finamente algunas de estas cosas, y pensando en hacia dónde nos dirigimos en términos del flujo de trabajo agente, que es cómo abordamos tareas complejas y cómo comenzamos a automatizarlas una tarea a la vez. Sí. Eso es todo. Muy bien. Muy bien.

Entonces alguien preguntó, los sistemas Rack tienen problemas para crear una burbuja de información. Entonces, ¿cómo te aseguras de evitarlo en la asistencia de code para que no se fijen demasiado en ciertas fuentes? Sí. Esa es una buena pregunta. Creo que la pregunta es, los sistemas de recomendación son una burbuja de filtro. Las cámaras de eco, si te gusta algo, seguiré mostrándote cosas similares. La diferencia entre las aplicaciones de LLM y los sistemas de recomendación es que las recomendaciones son muy proactivas. Son como, hey, vienes al feed, vienes a la página de inicio, no tienes que hacer una consulta, te mostraré lo que quieres, ¿verdad? Pero luego en los LLM, la mayoría de las aplicaciones están impulsadas por tareas. No vas a chat GPT y te da un feed. No, ese feed no existe. Tienes que tener una tarea en la que el LLM intente ayudarte.

Entonces, debido a que hay una tarea, la cantidad de influencia que un LLM puede tener es limitada. Al menos por ahora, ¿verdad? Quiero decir, en este momento, alrededor de los LLM no hay un feed. Y un feed es algo en lo que puedo ser perezoso. Puedo abrir TikTok y obtendré un flujo, simplemente pasear, con poco esfuerzo y estar en mi burbuja de filtro. Ahora mismo, al menos la configuración no es que los copilotos te hagan eso. Ellos, como, hey, ¿qué estás tratando de hacer? Te ayudaré a hacerlo mejor. Así que creo que la diferenciación de tareas y esa proactividad, la falta de asistencia proactiva es lo que no hace que estos LLM sean como burbujas de filtro.

De acuerdo, veamos qué tenemos a continuación. De acuerdo, ¿alguna vez querrías un lenguaje de programación diseñado para una mayor previsibilidad con asistencia de code? Esa es una gran pregunta. Nunca pensé en si necesitamos, como, un lenguaje de programación. Creo que podemos hablar de abstracciones, ¿verdad? Mira, para abordar una tarea compleja, lo que necesito son pasos de alto nivel, ¿verdad? Estos son una secuencia de pasos que seguiría. Ahora, en este momento, los lenguajes de programación son, como, sí, quiero decir, están escribiendo sintaxis para detalles de bajo nivel, ¿verdad? Hemos abstraído desde los compiladores a los lenguajes. Pero creo que es un gran punto, que tal vez haya cosas, especialmente a medida que comenzamos a mirar el bucle externo de las cosas, ¿verdad? Un paso más allá, dos pasos por encima. Estos son, como, subpasos de lo que se necesita para abordar una tarea. En este momento, no hay un protocolo para definir eso, ¿verdad? No hay una sintaxis o forma de definir o crear este conjunto de datos. ¿Se parece a un lenguaje? ¿Se parece a un protocolo? ¿Se parece a una secuencia de pasos? Creo que el veredicto aún está pendiente, pero creo que es un gran pensamiento. Algo a nivel de abstracción más alto debe existir para intentar al menos, como, planificación de RL sobre estas tareas complejas. De acuerdo, sí, eso tiene mucho sentido. Entonces, la próxima persona aquí, en la siguiente pregunta votada es... Déjame verlo aquí. ¿Entiendo correctamente que Kodi considera el contexto del repositorio para dar predicciones de code? Sí, considera el contexto de tu repositorio, de muchos otros, como, el contexto abierto es algo un protocolo que el equipo está desarrollando, que es, nuevamente, para responder a tu code, no necesito solo confiar en los repositorios de code. Puedo mirar tu documentation, tu hoja de ruta, tal vez las conversaciones de Slack, así que no es solo sobre mirar el contexto de tu repositorio de code, sino en todas partes donde puedo obtener información que te ayude a resolver la tarea. Y nuevamente, no es solo tu repositorio. Imagina que estás en una enterprise, 20,000 desarrolladores, 15,000 repositorios, millones de líneas de code. Ese mundo de múltiples repositorios es donde esto va a ser realmente, realmente útil. ¿Por qué? Porque esa búsqueda es más difícil. Dentro de un repositorio, es posible que sepas que solo hay unos pocos archivos, los conoces, pero en ese mundo de 15,000 repositorios, o en ese mundo de cinco repositorios, esa búsqueda de múltiples repositorios, eso no es trivial.

Dentro de un repositorio, es posible que sepas que solo hay unos pocos archivos, los conoces, pero en ese mundo de 15,000 repositorios, o en ese mundo de cinco repositorios, esa búsqueda de múltiples repositorios, eso no es trivial. De acuerdo. ¿Y qué tareas comunes de desarrollo consideras más adecuadas para que los agentes de IA automatizen? Buena pregunta. Yo... Sí, creo que no tengo una respuesta específica sobre qué tareas se pueden automatizar de inmediato, pero creo que, nuevamente, esta no es una respuesta de un experto en dominio de código, sino una respuesta de un experto en dominio de ML, es cualquiera de los conjuntos de datos que puedo crear primero, ese es el modelo que puedo construir primero. ¿Verdad? Si hay un conjunto de datos que dice, hey, así es como haces algo de programación de React en este módulo, ¿verdad? Entonces puedo entrenar un modelo con eso y puedo decir, hey, estamos haciendo muy bien en eso. Así que creo que si puedo generar... La razón por la que Python tiene un rendimiento tan alto en estos lenguajes es porque es el lenguaje más poblado en todos estos conjuntos de datos de preentrenamiento. ¿Qué significa eso? Eso significa que si has visto un conjunto de data antes, mucho de él, entonces puedes hacer bien en esa tarea. Esa es exactamente la razón por la que estamos obteniendo mejoras en la sintonización fina de Rust. Recopilamos lenguajes de Rust, recopilamos algunos ejemplos donde no funcionaba bien, le dimos al LLM suficiente de esos data, y luego comenzó a funcionar mejor. Así que creo que el lado opuesto de esa respuesta es qué tipo de tarea agente puedo crear conjuntos de datos alrededor, evaluaciones alrededor, y luego aplicar ML a eso, ¿verdad? Creo que aquí es donde probablemente se centrará la mayor parte de nuestro trabajo. Nuevamente, quiero decir, la mayoría de estos sistemas de ML son lo suficientemente bajos en code como para que puedas hacer clic en un botón y hacer que la sintonización fina funcione, o crear un conjunto de datos.

Se trata más de lo que hay en ese conjunto de datos. Si eres un gran programador de Rust, entonces conoces las fallas actuales. Conoces las complejidades de Rust. Y eso es probablemente tu contribución, es decir, descubrir los casos de falla y lograr que estos modelos funcionen muy bien en ellos.

De acuerdo. ¿Y los modelos con ventanas de contenido grandes, como más de 1 millón de tokens, con un buen rendimiento de búsqueda de aguja en el pajar, resolverían en gran medida el problema de contexto simplemente enviando todo? Sí, creo que eso es un gran punto. Quiero decir, nuevamente, la pregunta es, hey, estamos pensando en la clasificación del contexto. No se trata solo de code aquí. Todos están pensando en el contexto. Y los modelos Gemini tienen alrededor de 1 millón de tokens. Nuevamente, vimos ese compromiso entre la latencia y el rendimiento. Entonces, incluso si incluyes un millón de elementos de contexto, llevará mucho tiempo para que ocurra la inferencia. Te costará 100 veces más. Será una latencia mucho mayor. Entonces, nuevamente, si puedes ayudar al LLM a enfocar la atención correcta, muchas de las tareas se vuelven más fáciles. Entonces, sí, los tamaños de contexto más grandes son útiles, pero no son prácticos en los casos de uso con los que la mayoría de estas empresas están lidiando en este momento. De acuerdo. Y todavía tenemos tiempo para una última pregunta. Pregunta rápida. Veamos qué tenemos aquí. De acuerdo. Vamos con esta. Dado que la latencia de edición de texto es uno de los cuellos de botella, ¿experimentan con enfoques de aplicación rápida para ediciones de archivos completos? Perdón, ¿cuál es la pregunta... Entonces, la pregunta es, dado que la latencia de edición de texto es uno de los cuellos de botella, ¿experimentan con enfoques de aplicación rápida para ediciones de archivos completos? Sí, creo que la pregunta... De acuerdo, entonces, si la latencia de autocompletado es un cuello de botella, ¿deberíamos hacer la edición de todo el archivo, la edición de todo el repositorio? Entonces, creo que no se trata de esto versus aquello. Estos son casos de uso diferentes, ¿verdad? Si eres un desarrollador profesional, estás escribiendo code, necesitamos intervenir y ayudarte a hacer eso. Esa es esa función. La edición de todo el code es otra función por completo, ¿verdad? Ahí es donde puedo ayudarte a escribir la versión inicial del módulo y proporcionar una vista de agente para ayudarte a escribir code. Entonces, nuevamente, lo tratamos como una función separada, y no es que hagamos esto a costa de aquello. Deberíamos hacer esto aquí, y deberíamos hacer esto aquí. Mira los compromisos aquí, elige una lente más pequeña, ajústala, hazla consciente de la latencia. Aquí, puedo ajustar modelos más grandes y hacerlos más grandes, porque la latencia no es un cuello de botella. Entonces, creo que juegas con diferentes compromisos en los tamaños de los modelos allí. De acuerdo. Y se nos acabó el tiempo, Rishabh. Muchas gracias por acompañarnos.