Fine-tuning de un LLM para escribir tu documentación

Fine-tunear un LLM para documentación es agarrar un modelo base, como Llama 3.1 8B o Qwen 2.5 7B, y reentrenarlo con un corpus de manuales técnicos para que escriba con ese estilo. En passo.uno lo probaron en junio de 2026, fine-tuneando un modelo instruct con manuales de Microsoft de los 90 sacados de Bitsavers: 37 millones de palabras de docs entre 1977 y 2005.

El experimento es medio nostálgico y medio serio. La idea de fondo no es revivir el estilo de los manuales viejos por capricho, sino probar si un equipo chico puede tener su propio modelo de documentación corriendo en local, sin depender de una API que cobra por token y que ve todo lo que le mandás. Vamos por partes.

El fine-tuning de un LLM para documentación es el proceso de tomar un modelo de lenguaje preentrenado y ajustarlo con un dataset propio de textos técnicos, para que aprenda un estilo, una terminología y una estructura específicas. A diferencia de un modelo general, uno especializado replica convenciones concretas: secciones tipo “Synopsis”, estructura de man-page, vocabulario de la época o del producto. Corre en local y se entrena con técnicas livianas como QLoRA.

¿Para qué especializar un LLM en escribir documentación?

Ponele que tenés que documentar una API interna y le pedís a un modelo general que te arme la referencia. Te devuelve algo correcto, pero con ese tono de blog de marketing: entusiasta, lleno de “potente” e “intuitivo”, y con una estructura que cambia en cada respuesta. Un modelo fine-tuneado con documentación real escribe distinto. Aprende la forma, no solo el contenido.

Las ventajas concretas de un modelo especializado, frente a uno general conectado a una API: Te puede servir nuestra cobertura de cómo funcionan los modelos de lenguaje.

• Control total del estilo: el modelo replica tu guía de estilo y tus convenciones sin que se lo recuerdes en cada prompt.
• Privacidad de los datos internos: si entrenás y corrés en local, tu documentación confidencial no sale de tu máquina ni alimenta a un proveedor externo.
• Costo amortizado: a volumen alto, evitás pagar por token. Entrenás una vez y generás todo lo que quieras sin tarifa variable.
• Latencia baja: un 7B cuantizado responde rápido en hardware modesto, sin viaje de red.

Eso sí: el propio autor de passo.uno reconoce que todavía no llegamos al “local first”. Los modelos frontier conectados siguen siendo bastante más potentes, y eso pesa. El experimento es exploración, no producción.

¿Qué corpus se necesita para entrenar un modelo de documentación?

Acá está el cuello de botella real. Para fine-tunear bien hace falta muchísimo texto del estilo objetivo, y eso no abunda. El autor lo dice claro: si quisiera entrenar un modelo para escribir como él, su blog no alcanzaría, porque tiene apenas unas 100.000 palabras. Para un entrenamiento sólido necesitás muchas más muestras, y producirlas a mano es carísimo.

La salida rápida es usar un corpus que ya exista. En este caso fue Bitsavers, un sitio que escanea y junta manuales y folletos viejos de computación. Es un archivo histórico enorme: más de 37 millones de palabras de documentación descatalogada, entre 1977 y 2005, cubriendo sistemas y SDKs antiguos. El autor bajó los archivos de texto pasados por OCR y los limpió.

¿De dónde más podés sacar corpus? Documentación interna de tu propia empresa (la opción más valiosa y la más sensible), archivos técnicos públicos, repos de manuales abiertos. La clave no es solo el volumen, es la consistencia: si mezclás cinco estilos distintos, el modelo aprende un promedio borroso de todos.

¿Cómo se prepara el corpus antes de entrenar?

El OCR de manuales escaneados de los 90 viene sucio. Caracteres mal reconocidos, saltos de página en el medio de una oración, encabezados repetidos, tablas convertidas en sopa de texto. Antes de entrenar, todo eso hay que limpiarlo, o el modelo aprende la basura junto con el estilo. Más contexto en fine-tuning de modelos gpt.

El flujo típico de preparación incluye varias pasadas: eliminar duplicados, normalizar el encoding y el espaciado, filtrar fragmentos corruptos y armar el dataset final en formato JSONL, que es el estándar para fine-tuning. Es la parte menos glamorosa y la que más tiempo come. Cualquiera que haya armado un dataset sabe que la limpieza es el 80% del trabajo (y el otro 80% es darte cuenta de que limpiaste mal).

QLoRA y LoRA: ¿cómo se entrena sin reventar la GPU?

Reentrenar un modelo entero (full fine-tuning) requiere muchísima memoria y plata. Por eso casi nadie lo hace para estos casos. La alternativa son los adaptadores de bajo rango.

• LoRA (Low-Rank Adaptation): en vez de mover todos los pesos del modelo, entrena un puñado de matrices chiquitas que se “enchufan” al modelo base. Muchísimos menos parámetros que tocar.
• QLoRA: la versión cuantizada de LoRA. Carga el modelo base en 4 bits y entrena los adaptadores encima. Es lo que te permite fine-tunear un 7B en una GPU de consumo.
• El rango importa: un rango más bajo (ponele 8) mete menos parámetros y aprende un compromiso más suave; uno más alto (16 o más) se compromete más con el estilo, pero arriesga overfitting.

Técnica	VRAM aprox.	Velocidad	Cuándo conviene
Full fine-tuning	Decenas de GB	Lenta y cara	Solo con presupuesto y cluster propio
LoRA	Media-alta	Media	Estilo marcado, GPU con holgura
QLoRA (4 bits)	4-5 GB	Rápida	El caso típico: GPU de 8 GB en casa

¿Qué modelo base y qué hardware necesito?

Para este tipo de tarea, los modelos de 7B y 8B son el punto dulce. Pesan poco, corren en hardware modesto y aprenden estilo sin problema. Los más probados:

• Llama 3.1 8B: base sólida y muy soportada por la comunidad.
• Qwen 2.5 7B: fuerte en seguir instrucciones, buena opción para documentación estructurada.
• Mistral 7B: liviano y eficiente, clásico para fine-tuning casero.

El hardware mínimo viable es una GPU con 8 GB de VRAM. Con cuantización de 4 bits, el modelo base ocupa 4-5 GB y te queda margen para los adaptadores. Para correrlo después, Ollama y LM Studio te dejan servir el modelo en local sin pelearte con dependencias. Si no tenés GPU propia, podés alquilar una por hora en proveedores cloud de cómputo. Cubrimos ese tema en detalle en las capacidades de claude.

El tema es que esto último te devuelve al punto de partida: si terminás alquilando GPU y subiendo tus datos a un tercero, parte de la ventaja de privacidad se diluye. Si vas a montar infraestructura propia para servir el modelo de forma permanente, conviene pensar dónde lo alojás. Para hosting y servidores en Argentina, donweb.com es una opción local.

Ejemplos: de los manuales de los 90 a documentación de hoy

Caso 1: el estilo vintage de Microsoft. El experimento de passo.uno tomó la colección de manuales de Microsoft de Bitsavers y fine-tuneó un modelo instruct para que escribiera con esa voz: estructura de man-page, secciones tipo “Synopsis”, vocabulario de la época. El resultado es documentación que suena salida de un manual impreso de 1994. Curioso como prueba de concepto, y revelador de cuánto estilo absorbe un modelo con el corpus correcto.

Caso 2: documentación interna corporativa. El mismo método aplica a un equipo que quiere un modelo que escriba sus release notes o su referencia de API con su guía de estilo propia. Acá el corpus es tu documentación histórica, no manuales viejos. La gran diferencia: estos datos son privados, y por eso el entrenamiento local tiene sentido real, no solo nostálgico.

¿Qué NO puede hacer un LLM fine-tuneado para docs?

Acá viene la parte que los entusiastas del “local first” prefieren saltear. Un modelo especializado en estilo no reemplaza a un technical writer humano. Le falta el juicio editorial, el contexto profundo del producto y, sobre todo, la capacidad de validar que lo que escribe es cierto.

• No valida nada técnico: puede describir un comando que no existe con total seguridad. Aprende a sonar como documentación, no a ser correcta.
• Alucina con confianza: los modelos chicos fine-tuneados son propensos a inventar parámetros, flags o secciones plausibles pero falsas.
• Flojea en código funcional y precisión matemática: generar snippets que compilen o definiciones exactas no es su fuerte.

La forma sana de pensarlo: es augmentation, no replacement. Acelera el borrador, te saca la página en blanco, mantiene el tono. La revisión humana sigue siendo obligatoria. Si publicás lo que escupe sin revisar, vas a publicar errores con un estilo impecable. Relacionado: gemini para generación de contenido.

¿Conviene entrenar en local o usar APIs en la nube?

No hay respuesta única. Depende de tu volumen, de cuán sensibles sean tus datos y de tu presupuesto. La decisión rápida:

• Fine-tuning local: ganás privacidad, control del estilo, costo amortizado a volumen alto y latencia baja. Pagás con tiempo de setup, limpieza de corpus y mantenimiento.
• APIs en la nube: accedés a modelos frontier sin GPU propia y arrancás en minutos. Pagás por token y mandás tus datos afuera.

Si querés profundizar en el lado del entrenamiento desde cero, lo cubrimos en esta guía sobre entrenar un LLM. La regla práctica: si generás poca documentación y no es confidencial, una API te zafa. Si tu volumen es alto o tus datos no pueden salir de tu red, el camino local empieza a cerrar números.

Qué está confirmado y qué no

• Confirmado: el experimento de passo.uno se publicó el 1 de junio de 2026 y usó manuales de Microsoft de Bitsavers (más de 37 millones de palabras, 1977-2005).
• Confirmado: el autor bajó los archivos OCR y los limpió antes de entrenar.
• Confirmado: reconoce que el “local first” todavía no llegó, porque los modelos frontier conectados siguen siendo más potentes.
• Pendiente: no hay benchmark independiente que mida qué tan “bien” escribe el modelo resultante. Es un experimento personal, tomalo con pinzas.
• Pendiente: el costo exacto y los hiperparámetros finales varían según el modelo base y tu hardware. Los números de VRAM acá son referencias generales de QLoRA, no del experimento puntual.

Errores comunes al fine-tunear un modelo de documentación

• Entrenar con corpus sucio: meter el OCR sin limpiar es el error número uno. El modelo aprende los artefactos del escaneo. Limpiá duplicados, encoding y fragmentos corruptos antes de tocar nada.
• Corpus demasiado chico: 100.000 palabras no alcanzan para un estilo sólido, como reconoce el propio autor sobre su blog. Si no tenés volumen, el resultado va a ser inconsistente.
• Confundir estilo con verdad: que escriba como documentación no significa que diga la verdad. No publiques sin revisión técnica humana.
• Rango de LoRA mal elegido: un rango muy alto sobre un corpus chico te lleva al overfitting, y el modelo repite frases enteras del dataset en vez de generalizar.

Preguntas Frecuentes

¿Qué es fine-tuning de un LLM para documentación?

Es el proceso de tomar un modelo preentrenado, como Llama 3.1 8B, y reentrenarlo con un corpus de textos técnicos para que escriba con un estilo y una estructura específicos. El modelo aprende convenciones de documentación, no conocimiento nuevo verificado.

¿Cuánto corpus necesito para entrenar el modelo?

Mucho más de lo que pensás. El autor de passo.uno señala que su blog de 100.000 palabras no alcanzaba, y por eso recurrió a Bitsavers, con más de 37 millones de palabras. Para un estilo consistente necesitás un corpus grande y homogéneo.

¿Qué hardware hace falta para fine-tunear un modelo de 7B?

Con QLoRA y cuantización de 4 bits, una GPU de 8 GB de VRAM alcanza para modelos de 7B y 8B. El modelo base cuantizado ocupa 4-5 GB y deja margen para los adaptadores de bajo rango.

¿Es más barato entrenar en local que usar una API?

Depende del volumen. A volumen alto, el costo de entrenar una vez y generar sin pagar por token se amortiza. A volumen bajo, una API en la nube sale más barata y no requiere setup ni mantenimiento de GPU.

¿Un LLM fine-tuneado reemplaza a un technical writer?

No. Es augmentation, no replacement. Acelera borradores y mantiene el tono, pero no valida información técnica y alucina con confianza. La revisión humana sigue siendo obligatoria antes de publicar.

Conclusión

El experimento de passo.uno no demuestra que el futuro de la documentación sea un modelo local escribiendo como un manual de 1994. Demuestra otra cosa, más útil: con un corpus bueno y QLoRA, un equipo chico puede fine-tunear un modelo de 7B en hardware de consumo y obtener un asistente que escribe con su estilo. La parte difícil no es entrenar, es conseguir y limpiar el corpus.

Si tenés documentación interna confidencial y volumen alto, vale la pena probarlo. Empezá con un corpus propio bien limpio, elegí un base como Llama 3.1 8B o Qwen 2.5 7B, fine-tuneá con QLoRA y, sobre todo, revisá todo lo que genere. El modelo aprende a sonar como documentación. Que diga la verdad, todavía es tarea tuya.

Fuentes

• passo.uno – Fine-tuning an LLM to write docs like it’s 1995 (1 de junio de 2026)
• blog.donweb.com – Cómo entrenar un LLM desde cero
• dev.to – Fine-tuning de LLMs: guía completa para personalizar modelos
• prodad-software.es – Guía práctica para afinar modelos LLM locales
• eldoc.online – Despliegue de LLM local para documentos