Nadie puede saber todo de una disciplina, y mucho menos en profundidad. Pero entonces, ¿cómo guían los líderes técnicos si no saben qué caminos hay disponibles?
Una forma efectiva—y que me resulta particularmente útil—es el enfoque de technical breadth que Mark Richards y Neal Ford describen en «Fundamentals of Software Architecture: An Engineering Approach«.
En esta línea, me pareció que podía ser interesante compartir qué contenido estuve consumiendo tratando de incorporar el avance vertiginoso en LLMs y así mantener un mapa actualizado de herramientas y alternativas tecnológicas.
¿Qué es el technical breadth?
Los autores plantean que el technical breadth es la amplitud de temas sobre los cuales sabemos algo, pero que no conocemos en profundidad. Al comienzo de la carrera, el foco suele estar en el technical depth, es decir, en aprender a fondo una tecnología específica. En ese proceso, muchas veces se amplía también el breadth casi como un efecto secundario.
Sin embargo, al transicionar a un rol de liderazgo, se vuelve fundamental cambiar el enfoque y expandir la amplitud más que la profundidad. Se trata entonces de descubrir herramientas, tecnologías y procesos que permitan tener un abanico de opciones para tomar mejores decisiones.
¿Qué incorporar?
No creo que esto se pueda forzar con una intención rígida tipo «hoy voy a descubrir algo nuevo». Más bien, hay un componente clave en mantener la curiosidad abierta. Dicho eso, sí creo que hay formas de estructurar el proceso, al menos en términos de dedicación e intensidad, según alguna heurística personal.
Siempre trato de entender cuales son los puntos claves de distintas herramientas y su fundamento. Si capto la base conceptual, puedo conectar esa información con conocimientos previos y absorber nuevas piezas más rápido.
La profundidad es algo variable por tema y adaptable en el tiempo. Con algunas herramientas o tecnologías, fui súper a fondo – otras no. De vez en cuando, vale la pena hacerse la pregunta: ¿Debería profundizar más en esto o ya tengo lo suficiente por ahora?
¿Cómo lo estoy haciendo con LLMs?
Es un rabbit hole por momentos difícil de recapitular, pero traté de armar un recorrido con algunos puntos de partida que me resultaron valiosos.
El primero es un largo artículo de Stephen Wolfram donde explica varios conceptos centrales de la teoría detrás de los LLMs, con referencias para seguir explorando.
Sobre aspectos más de la implementación, creo que de lo mejor que he visto es el muy reciente Deep Dive sobre LLMs que hizo Andrej Karpathy. También tiene una entrevista en el Podcast con Lex Fridman que es muy interesante.
Además, sigo de cerca las novedades de los principales proveedores (usualmente porque explotan en Hacker News) y experimento ocasionalmente con la API de OpenAI, donde (por ahora) tengo cuenta.
¿Cómo se valida esto?
Una preocupación razonable puede ser cómo saber si lo que estás aprendiendo sirve de algo o no, entender si estás siendo efectivo en ampliar el breadth.
Un mecanismo soft recurrente que utilizo para entender dónde estoy parado es escuchar presentaciones técnicas o entrevistas. Son una herramienta amigable para recorrer temas y validar si podés seguir el hilo sin perderte demasiado, además de que suele traer nuevas fuentes de información y puntos de curiosidad.
Un buen test reciente fue el episodio de podcast de Lex Fridman con Dylan Patel y Nathan Lambert. No aspiro a ser un experto en LLMs, pero pude seguir una conversación relevante sin sentir que me hablan en otro idioma.
¡Ideas se aceptan!
Sin ánimo de hacer un Call-To-Action cliché, realmente me encanta descubrir nuevos temas y contenido. Así que si estás en la misma, me encantaría que compartas qué te ha servido o qué te ha atrapado últimamente.
Hay conocimientos que quizás otras personas pueden llegar a listar como importantes para entender algunas partes de estos temas (e.g. GPUs) que no los incluí. Quizás porque ya estuve expuesto en el pasado, o quizás porque no lo sé aún! ¡Sugerencias se aceptan!
Juan Saavedra 