Construir un dataset de entrenamiento para Drupal: una guía práctica

La mayoría de los artículos sobre cómo construir datasets de instrucciones para fine-tuning de LLMs o para RAG asumen que ya se cuenta con material fuente limpio y estructurado. Los proyectos reales casi nunca lo tienen — y justo en esa brecha aparece la ingeniería interesante. Este artículo recorre el pipeline que construimos para convertir contenido técnico disperso de Drupal en un dataset de instrucciones estructurado y verificado, y comparte las cifras de una corrida de producción real.

Por qué: el problema real que esto resuelve

Drupal 7 quedó fuera de soporte oficial hace tiempo, pero todavía corre en una porción grande de sitios en producción. Migrar esos sitios a la línea moderna Drupal 9/10/11 es un trabajo técnico lento, caro: la superficie de la API cambió sustancialmente, y buena parte de lo que necesita un ingeniero de migración está disperso en documentación de referencia que no está escrita como guía, y en años de preguntas y respuestas de la comunidad de calidad despareja, a veces referida a la versión equivocada. El objetivo de este dataset no es la ingeniería de datasets por sí misma: es construir la base de conocimiento que permita a un sistema de IA asistir de verdad en leer código legacy de Drupal 7, explicar qué hace, y proponer el equivalente moderno — el cuello de botella específico y caro en la mayoría de las migraciones de Drupal.

Por qué Drupal en particular es un objetivo difícil y que vale la pena

Dos propiedades de Drupal hacen este ejercicio exigente y útil a la vez:

1. Fragmentación de versiones. Drupal 7 y la línea moderna Drupal 9/10/11 son lo bastante parecidas en nombre como para confundirse, y lo bastante distintas en su superficie de API como para que el contenido escrito para una necesite un tratamiento cuidadoso y consciente de la versión antes de aplicarse a la otra. Resolver esto bien es una condición necesaria para que el dataset sirva para trabajo de migración en absoluto.
2. La documentación de referencia no es Q&A. La documentación oficial de la API describe clases, métodos y hooks — no viene empaquetada como "un desarrollador pregunta X, esta es la respuesta". El contenido de preguntas y respuestas de la comunidad se parece más a cómo los desarrolladores realmente formulan sus problemas. Convertir ambas en pares de instrucción consistentes es la transformación central que hace este pipeline.

El pipeline

A grandes rasgos, el pipeline tiene tres fases por tipo de fuente:

1. Extracción — se toman páginas/hilos crudos, se etiquetan por versión de Drupal, y se elimina el ruido evidente (navegación, listados de enlaces entre versiones, contadores de referencias de las páginas de documentación de API). Esta limpieza por sí sola mejoró de forma notable la calidad del resto del pipeline una vez que medimos cuánto importaba.
2. Generación — un modelo local, chico y rápido, convierte cada fuente ya limpia en un triple candidato (instruction, context, response).
3. Verificación — un segundo modelo, más fuerte, chequea el candidato contra la fuente y el contrato de generación, detectando cualquier cosa que invente contenido, no coincida con la versión de Drupal declarada, o viole el esquema de salida. Si falla, el siguiente modelo en la cadena regenera desde cero. Solo lo que sobrevive a la verificación se escribe en el dataset.

Esta estructura de generar-y-verificar (una cascada, que tiene su propio artículo) es lo que permitió que un modelo chico y barato cargara con la mayor parte del trabajo sin sacrificar la confianza en un dataset donde lo que importa, para la tarea final, es la corrección — no solo la fluidez.

Convertir los logs de rechazo en una hoja de ruta

Un pipeline ingenuo trata "el modelo devolvió un JSON válido" como éxito. Nosotros fuimos más lejos: cada rechazo se registró y categorizó, convirtiendo la etapa de verificación en una herramienta de diagnóstico y no solo en un filtro. A lo largo de la vida del proyecto esto produjo 1.251 rechazos categorizados de primera ronda, y tenerlos desglosados por causa fue lo que hizo posible una mejora sistemática:

Motivo de rechazo — Porcentaje

• Respuesta vaga o incompleta: 29,9%
• Contenido inventado que no está en la fuente: 23,3%
• JSON mal formado / forma de salida incorrecta: 19,3%
• Fuera de tema o símbolo equivocado: 13,6%
• Versión de Drupal incorrecta: 7,0%
• Falta un campo de explicación obligatorio: 3,9%
• Respuesta vacía: 2,7%

Cada categoría recibió un arreglo específico en vez de un ajuste genérico de prompt "para que se esfuerce más", y cada arreglo achicó su categoría de forma medible.

Fidelidad de versión: el arreglo con el impacto de volumen más claro

Una de las lecciones más contraintuitivas vino de cuestionar una salvaguarda existente en vez de agregar una nueva. Una versión temprana del pipeline usaba un filtro previo estricto que descartaba cualquier pregunta de Drupal que no declarara explícitamente su versión, bajo la teoría de que un etiquetado ambiguo de versión contaminaría el dataset. Al mirarlo de cerca, la mayoría de los desarrolladores simplemente no escriben "Drupal 7" cuando es obvio por el contexto — el filtro estaba descartando buen contenido a montones mientras apenas tocaba el problema real: contenido que contradice activamente la versión declarada.

Reemplazar "descartar cualquier cosa ambigua" por "descartar solo contradicciones genuinas, verificadas contra el contenido técnico real" produjo dos mejoras separadas, que vale la pena distinguir, en el pipeline de preguntas y respuestas de la comunidad:

• El volumen total de salida aceptada aproximadamente se triplicó corrida tras corrida, porque muchos menos candidatos buenos se estaban descartando antes incluso de llegar a la generación.
• La tasa de aceptación de primera ronda del propio modelo de generación subió de 0% a 26,4% en la ventana de medición equivalente, porque los candidatos que ahora sí llegaban eran, en promedio, menos ambiguos y más fáciles de acertar.

Son dos métricas distintas que cuentan dos partes distintas de la misma historia — una es sobre cuánto material fuente bueno llega siquiera al pipeline, la otra es sobre qué tan bien rinde el modelo una vez que le llega — y vale la pena mantenerlas separadas en vez de tratar una cifra como si fuera la otra.

Resultados de una corrida real

Después de las mejoras descritas arriba, una corrida de 7 horas sin supervisión produjo:

• 176 pares verificados del pipeline de documentación de referencia, con una tasa de aceptación de primera ronda del 46,0% para el modelo de generación chico — igualando la mejor tasa registrada históricamente para este pipeline.
• 53 pares verificados del pipeline de preguntas y respuestas de la comunidad, con la tasa de primera ronda del 26,4% mencionada arriba.

Ambos pipelines siguen mejorando, y un pipeline bien instrumentado convierte "el modelo se equivocó" de un callejón sin salida en el próximo paso concreto por resolver — con el objetivo final, siempre, de un dataset lo bastante preciso y completo como para acelerar de verdad el trabajo real de migración de Drupal 7 a Drupal 9/10/11, no una cifra de benchmark por sí misma.

Conclusiones

• Categorizá los rechazos antes de intentar arreglarlos — un desglose preciso convierte "a veces falla" en una lista priorizada y manejable.
• Cuestioná tus salvaguardas existentes, no solo tus ideas nuevas. Nuestra mayor victoria de rendimiento vino de aflojar un filtro demasiado cauteloso, no de endurecer uno.
• Mantené "cuánto material llega a tu modelo" y "qué tan bien rinde tu modelo con lo que le llega" como cifras separadas y reportadas por separado. Combinarlas hace que una mejora real suene como una mejora distinta y más grande de lo que fue.