Buckets:
| # Cómo pedir ayuda en los foros[[asking-for-help-on-the-forums]] | |
| Los [foros de Hugging Face](https://discuss.huggingface.co) son un sitio excelente para pedir ayuda al equipo de open source y a la comunidad más amplia de Hugging Face. Así se ve la página principal en un día cualquiera: | |
| En el lado izquierdo puedes ver todas las categorías en las que se agrupan los distintos temas, mientras que el lado derecho muestra los temas más recientes. Un tema es una publicación que contiene un título, una categoría y una descripción; se parece bastante al formato de las incidencias (issues) de GitHub que vimos al crear nuestro propio conjunto de datos en el [Capítulo 5](/course/chapter5). Como sugiere el nombre, la categoría [Beginners](https://discuss.huggingface.co/c/beginners/5) está pensada principalmente para la gente que recién empieza con las librerías y el ecosistema de Hugging Face. Ahí son bienvenidas preguntas sobre cualquiera de las librerías, ya sea para depurar código o para pedir ayuda sobre cómo hacer algo. Dicho eso, si tu pregunta trata sobre una librería en particular, probablemente te convenga ir a la categoría correspondiente en el foro. | |
| De forma parecida, las categorías [Intermediate](https://discuss.huggingface.co/c/intermediate/6) y [Research](https://discuss.huggingface.co/c/research/7) son para preguntas más avanzadas, por ejemplo sobre las librerías o sobre alguna investigación nueva e interesante de PLN (procesamiento de lenguaje natural) que quieras comentar. | |
| Y, naturalmente, también tenemos que mencionar la categoría [Course](https://discuss.huggingface.co/c/course/20), donde puedes hacer cualquier pregunta relacionada con el curso de Hugging Face. | |
| Una vez que hayas elegido una categoría, estarás listo para escribir tu primer tema. En el foro puedes encontrar algunas [guías](https://discuss.huggingface.co/t/how-to-request-support/3128) sobre cómo hacerlo, y en esta sección veremos algunas características que forman parte de un buen tema. | |
| ## Escribir una buena publicación en el foro[[writing-a-good-forum-post]] | |
| Como ejemplo, supongamos que estamos intentando generar embeddings a partir de artículos de Wikipedia para crear un motor de búsqueda personalizado. Como siempre, cargamos el tokenizador y el modelo así: | |
| ```python | |
| from transformers import AutoTokenizer, AutoModel | |
| model_checkpoint = "distilbert-base-uncased" | |
| tokenizer = AutoTokenizer.from_pretrained(model_checkpoint) | |
| model = AutoModel.from_pretrained(model_checkpoint) | |
| ``` | |
| Ahora supongamos que intentamos obtener embeddings de toda una sección del [artículo de Wikipedia](https://en.wikipedia.org/wiki/Transformers) sobre Transformers, la franquicia, no la librería: | |
| ```python | |
| text = """ | |
| Generation One is a retroactive term for the Transformers characters that | |
| appeared between 1984 and 1993. The Transformers began with the 1980s Japanese | |
| toy lines Micro Change and Diaclone. They presented robots able to transform | |
| into everyday vehicles, electronic items or weapons. Hasbro bought the Micro | |
| Change and Diaclone toys, and partnered with Takara. Marvel Comics was hired by | |
| Hasbro to create the backstory; editor-in-chief Jim Shooter wrote an overall | |
| story, and gave the task of creating the characthers to writer Dennis O'Neil. | |
| Unhappy with O'Neil's work (although O'Neil created the name "Optimus Prime"), | |
| Shooter chose Bob Budiansky to create the characters. | |
| The Transformers mecha were largely designed by Shōji Kawamori, the creator of | |
| the Japanese mecha anime franchise Macross (which was adapted into the Robotech | |
| franchise in North America). Kawamori came up with the idea of transforming | |
| mechs while working on the Diaclone and Macross franchises in the early 1980s | |
| (such as the VF-1 Valkyrie in Macross and Robotech), with his Diaclone mechs | |
| later providing the basis for Transformers. | |
| The primary concept of Generation One is that the heroic Optimus Prime, the | |
| villainous Megatron, and their finest soldiers crash land on pre-historic Earth | |
| in the Ark and the Nemesis before awakening in 1985, Cybertron hurtling through | |
| the Neutral zone as an effect of the war. The Marvel comic was originally part | |
| of the main Marvel Universe, with appearances from Spider-Man and Nick Fury, | |
| plus some cameos, as well as a visit to the Savage Land. | |
| The Transformers TV series began around the same time. Produced by Sunbow | |
| Productions and Marvel Productions, later Hasbro Productions, from the start it | |
| contradicted Budiansky's backstories. The TV series shows the Autobots looking | |
| for new energy sources, and crash landing as the Decepticons attack. Marvel | |
| interpreted the Autobots as destroying a rogue asteroid approaching Cybertron. | |
| Shockwave is loyal to Megatron in the TV series, keeping Cybertron in a | |
| stalemate during his absence, but in the comic book he attempts to take command | |
| of the Decepticons. The TV series would also differ wildly from the origins | |
| Budiansky had created for the Dinobots, the Decepticon turned Autobot Jetfire | |
| (known as Skyfire on TV), the Constructicons (who combine to form | |
| Devastator),[19][20] and Omega Supreme. The Marvel comic establishes early on | |
| that Prime wields the Creation Matrix, which gives life to machines. In the | |
| second season, the two-part episode The Key to Vector Sigma introduced the | |
| ancient Vector Sigma computer, which served the same original purpose as the | |
| Creation Matrix (giving life to Transformers), and its guardian Alpha Trion. | |
| """ | |
| inputs = tokenizer(text, return_tensors="pt") | |
| logits = model(**inputs).logits | |
| ``` | |
| ```python output | |
| IndexError: index out of range in self | |
| ``` | |
| Uy, aquí tenemos un problema. Y el mensaje de error es bastante más críptico que los que vimos en la [sección 2](/course/chapter8/section2). No conseguimos entender el traceback completo, así que decidimos acudir a los foros de Hugging Face para pedir ayuda. ¿Cómo podríamos redactar el tema? | |
| Para empezar, tenemos que hacer clic en el botón "New Topic" en la esquina superior derecha. Ten en cuenta que para crear un tema necesitamos haber iniciado sesión: | |
| Esto abre una interfaz de escritura donde podemos introducir el título del tema, elegir una categoría y redactar el contenido: | |
| Como el error parece estar relacionado exclusivamente con 🤗 Transformers, vamos a elegir esa categoría. Nuestro primer intento de explicar el problema podría verse así: | |
| Aunque este tema contiene el mensaje de error sobre el que necesitamos ayuda, tiene varios problemas en la forma en que está escrito: | |
| 1. El título no es muy descriptivo, así que cualquiera que navegue por el foro no podrá saber de qué trata el tema sin leer también el cuerpo. | |
| 2. El cuerpo no da suficiente información sobre dónde se produce el error ni cómo reproducirlo. | |
| 3. El tema etiqueta directamente a varias personas con un tono algo exigente. | |
| No es probable que temas como este reciban una respuesta rápida, si es que reciben alguna, así que veamos cómo mejorarlo. Vamos a empezar por el primer problema: elegir un buen título. | |
| ### Elegir un título descriptivo[[choosing-a-descriptive-title]] | |
| Si estás intentando pedir ayuda por un bug en tu código, una buena regla general es incluir suficiente información en el título para que otras personas puedan decidir rápido si creen que pueden responder tu pregunta o no. En nuestro ejemplo, sabemos el nombre de la excepción que se lanza y tenemos algunas pistas de que se activa en la pasada hacia delante (forward pass) del modelo, donde llamamos a `model(**inputs)`. Para comunicarlo, un posible título podría ser: | |
| > Source of IndexError in the AutoModel forward pass? | |
| Este título le dice a quien lo lea de dónde crees que viene el bug, y si ya se encontró antes con un `IndexError`, es bastante probable que sepa cómo depurarlo. Por supuesto, el título puede ser lo que quieras, y otras variantes como: | |
| > Why does my model produce an IndexError? | |
| también podrían estar bien. Ahora que ya tenemos un título descriptivo, vamos a mejorar el cuerpo. | |
| ### Dar formato a tus fragmentos de código[[formatting-your-code-snippets]] | |
| Leer código fuente ya es bastante difícil dentro de un IDE, pero todavía más cuando el código se copia y pega como texto plano. Por suerte, los foros de Hugging Face permiten usar Markdown, así que deberías encerrar siempre tus bloques de código entre tres comillas invertidas (```) para que se lean mejor. Hagamos eso para que el mensaje de error se vea mejor. Y ya que estamos, vamos a hacer que el cuerpo suene un poco más amable que nuestra versión original: | |
| Como puedes ver en la captura, encerrar los bloques de código entre comillas invertidas convierte el texto en bruto en código formateado, con colores incluidos. Fíjate también en que una sola comilla invertida sirve para dar formato a variables en línea, como hemos hecho con `distilbert-base-uncased`. Este tema ya pinta mucho mejor, y con un poco de suerte quizá alguien de la comunidad pueda adivinar de qué va el error. Pero en vez de depender de la suerte, vamos a ponérselo más fácil incluyendo el traceback completo, con todos sus detalles. | |
| ### Incluir el traceback completo[[including-the-full-traceback]] | |
| Como la última línea del traceback muchas veces basta para depurar tu propio código, puede ser tentador poner solo esa parte en tu tema para "ahorrar espacio". Aunque la intención sea buena, en realidad eso hace más difícil que otras personas depuren el problema, porque la información que aparece más arriba en el traceback también puede ser muy útil. Así que una buena práctica es copiar y pegar todo el traceback, asegurándote de que esté bien formateado. Como estos tracebacks pueden ser bastante largos, algunas personas prefieren mostrarlos después de haber explicado el código fuente. Hagamos eso. Ahora nuestro tema en el foro se ve así: | |
| Esto es mucho más informativo, y una persona atenta podría señalar que el problema parece venir de pasar un input demasiado largo, por esta línea del traceback: | |
| > Token indices sequence length is longer than the specified maximum sequence length for this model (583 > 512). | |
| Aun así, podemos ponérselo todavía más fácil si damos el código exacto que desencadena el error. Vamos con eso. | |
| ### Dar un ejemplo reproducible[[providing-a-reproducible-example]] | |
| Si alguna vez has intentado depurar el código de otra persona, probablemente lo primero que hiciste fue intentar reproducir el problema que describía para poder seguir el traceback y encontrar el error. En los foros pasa exactamente lo mismo tanto al pedir ayuda como al darla, así que ayuda muchísimo si puedes compartir un ejemplo pequeño que reproduzca el error. La mitad de las veces, simplemente hacer este ejercicio ya te ayuda a descubrir qué está pasando. En cualquier caso, la pieza que le falta a nuestro ejemplo es mostrar los inputs que le dimos al modelo. Si hacemos eso, obtenemos algo como la siguiente versión completa: | |
| Este tema ahora contiene bastante información, y está escrito de una forma que tiene muchas más probabilidades de llamar la atención de la comunidad y recibir una respuesta útil. Con estas pautas básicas, ya puedes crear muy buenos temas para encontrar respuesta a tus preguntas sobre 🤗 Transformers. | |
Xet Storage Details
- Size:
- 11.3 kB
- Xet hash:
- 8ec16ebc93ec4af0c092f8f0aad333e72391317e0664055b77399d428a54232d
·
Xet efficiently stores files, intelligently splitting them into unique chunks and accelerating uploads and downloads. More info.