ReaderLM v2: Modelo de Lenguaje Pequeño de Vanguardia para HTML a Markdown y JSON

jinaai/ReaderLM-v2 · Hugging Face

Estamos en un viaje para avanzar y democratizar la inteligencia artificial a través del código abierto y la ciencia abierta.

En abril de 2024, lanzamos Jina Reader, una API que transforma cualquier página web en markdown compatible con LLM simplemente añadiendo r.jina.ai como prefijo de URL. En septiembre de 2024, lanzamos dos modelos de lenguaje pequeños, reader-lm-0.5b y reader-lm-1.5b, específicamente diseñados para convertir HTML sin procesar en markdown limpio. Hoy, nos complace presentar la segunda generación de ReaderLM, un modelo de lenguaje de 1.5B parámetros que convierte HTML sin procesar en markdown o JSON bellamente formateado con superior precisión y mejor manejo de contextos más largos. ReaderLM-v2 maneja hasta 512K tokens combinados de longitud de entrada y salida. El modelo ofrece soporte multilingüe en 29 idiomas, incluyendo inglés, chino, japonés, coreano, francés, español, portugués, alemán, italiano, ruso, vietnamita, tailandés, árabe y más.

Gracias a su nuevo paradigma de entrenamiento y datos de entrenamiento de mayor calidad, ReaderLM-v2 representa un salto significativo respecto a su predecesor, particularmente en el manejo de contenido extenso y la generación de sintaxis markdown. Mientras que la primera generación abordaba la conversión de HTML a markdown como una tarea de "copia selectiva", v2 lo trata como un verdadero proceso de traducción. Este cambio permite que el modelo aproveche magistralmente la sintaxis markdown, destacando en la generación de elementos complejos como bloques de código, listas anidadas, tablas y ecuaciones LaTex.

Un desafío importante en nuestra primera versión fue la degeneración después de generar secuencias largas, particularmente en forma de repetición y bucles. El modelo comenzaba a repetir el mismo token o se quedaba atascado en un bucle, ciclando a través de una secuencia corta de tokens hasta alcanzar la longitud máxima de salida. ReaderLM-v2 alivia en gran medida este problema al añadir pérdida contrastiva durante el entrenamiento—su rendimiento se mantiene consistente independientemente de la longitud del contexto o la cantidad de tokens ya generados.

Más allá de la conversión a markdown, ReaderLM-v2 introduce la generación directa de HTML a JSON, permitiendo a los usuarios extraer información específica del HTML sin procesar siguiendo un esquema JSON dado. Este enfoque de extremo a extremo elimina la necesidad de conversión intermedia a markdown, un requisito común en muchos pipelines de limpieza y extracción de datos potenciados por LLM.

Tanto en evaluaciones cuantitativas como cualitativas, ReaderLM-v2 supera a modelos mucho más grandes como Qwen2.5-32B-Instruct, Gemini2-flash-expr, y GPT-4o-2024-08-06 en tareas de conversión de HTML a Markdown mientras muestra un rendimiento comparable en tareas de extracción de HTML a JSON, todo esto utilizando significativamente menos parámetros.

Estos resultados establecen que un modelo bien diseñado de 1.5B parámetros puede no solo igualar sino a menudo superar el rendimiento de modelos mucho más grandes en tareas de extracción de datos estructurados. Las mejoras progresivas de ReaderLM-v2 a ReaderLM-v2-pro demuestran la efectividad de nuestra nueva estrategia de entrenamiento para mejorar el rendimiento del modelo mientras se mantiene la eficiencia computacional.

tagComenzar

tagA través de Reader API

Reader API

Lee URLs y busca en la web para mejorar el fundamento de LLMs.

ReaderLM-v2 está ahora integrado con nuestra Reader API. Para usarlo, simplemente especifica x-engine: readerlm-v2 en los encabezados de tu solicitud y habilita el streaming de respuesta con -H 'Accept: text/event-stream':

curl https://r.jina.ai/https://news.ycombinator.com/ -H 'x-engine: readerlm-v2' -H 'Accept: text/event-stream'
Copiar

Puedes probarlo sin una clave API con un límite de velocidad más bajo. Para límites de velocidad más altos, puedes comprar una clave API. Ten en cuenta que las solicitudes de ReaderLM-v2 consumen 3 veces el conteo normal de tokens de tu clave API. Esta función está actualmente en beta mientras colaboramos con el equipo de GCP para optimizar la eficiencia de la GPU y aumentar la disponibilidad del modelo.

tagEn Google Colab

Google Colab

La forma más sencilla de probar ReaderLM-v2 en un entorno alojado es a través de nuestro notebook de Colab, que demuestra la conversión de HTML a markdown, extracción JSON y seguimiento de instrucciones usando la página principal de HackerNews como ejemplo. El notebook está optimizado para el nivel gratuito de GPU T4 de Colab y requiere vllm y triton para aceleración y ejecución. Siéntete libre de probarlo con cualquier sitio web.

Conversión de HTML a Markdown

Puedes usar la función auxiliar create_prompt para crear fácilmente un prompt para convertir HTML a Markdown:

prompt = create_prompt(html)
result = llm.generate(prompt, sampling_params=sampling_params)[0].outputs[0].text.strip()
Copiar

result será una cadena envuelta en comillas invertidas de Markdown como una valla de código. También puedes anular la configuración predeterminada para explorar diferentes salidas, por ejemplo:

prompt = create_prompt(html, instruction="Extract the first three news and put into in the makdown list")
result = llm.generate(prompt, sampling_params=sampling_params)[0].outputs[0].text.strip()
Copiar

Sin embargo, dado que nuestros datos de entrenamiento pueden no cubrir todos los tipos de instrucciones, particularmente tareas que requieren razonamiento en múltiples pasos, los resultados más confiables provienen de la conversión de HTML a Markdown. Para la extracción de información más efectiva, recomendamos usar el esquema JSON como se muestra a continuación:

Extracción de HTML a JSON con esquema JSON

import json

schema = {
    "type": "object",
    "properties": {
        "title": {"type": "string", "description": "News thread title"},
        "url": {"type": "string", "description": "Thread URL"},
        "summary": {"type": "string", "description": "Article summary"},
        "keywords": {"type": "list", "description": "Descriptive keywords"},
        "author": {"type": "string", "description": "Thread author"},
        "comments": {"type": "integer", "description": "Comment count"}
    },
    "required": ["title", "url", "date", "points", "author", "comments"]
}

prompt = create_prompt(html, schema=json.dumps(schema, indent=2))
result = llm.generate(prompt, sampling_params=sampling_params)[0].outputs[0].text.strip()
Copiar

result será una cadena envuelta en comillas invertidas con formato JSON, no un objeto JSON/dict real. Puedes usar Python para analizar la cadena en un diccionario o objeto JSON adecuado para su posterior procesamiento.

tagEn Producción: Disponible en CSP

ReaderLM-v2 está disponible en AWS SageMaker, Azure y GCP marketplace. Si necesitas usar estos modelos más allá de esas plataformas o en las instalaciones de tu empresa, ten en cuenta que este modelo y ReaderLM-v2-pro están licenciados bajo CC BY-NC 4.0. Para consultas sobre uso comercial o acceso a ReaderLM-v2-pro, no dudes en contactarnos.

AWS Marketplace: Reader-LM v2

tagEvaluación Cuantitativa

Evaluamos ReaderLM-v2 en tres tareas de extracción de datos estructurados frente a modelos de última generación: GPT-4o-2024-08-06, Gemini2-flash-expr y Qwen2.5-32B-Instruct. Nuestro marco de evaluación combina métricas que miden tanto la precisión del contenido como la fidelidad estructural. ReaderLM-v2 es la versión públicamente disponible con pesos abiertos, mientras que ReaderLM-v2-pro es un checkpoint premium exclusivo reservado para nuestros clientes empresariales, que cuenta con entrenamiento y optimizaciones adicionales. Tenga en cuenta que nuestra primera generación reader-lm-1.5b solo se evalúa en la tarea principal de extracción de contenido, ya que no admite capacidades de extracción por instrucciones o JSON.

tagMétricas de Evaluación

Para las tareas de HTML a Markdown, empleamos siete métricas complementarias. Nota: ↑ indica que mayor es mejor, ↓ indica que menor es mejor

• ROUGE-L (↑): Mide la subsecuencia común más larga entre el texto generado y de referencia, captando la preservación del contenido y la similitud estructural. Rango: 0-1, valores más altos indican mejor coincidencia de secuencias.
• WER (Tasa de Error de Palabras) (↓): Cuantifica el número mínimo de ediciones a nivel de palabra requeridas para transformar el texto generado en la referencia. Valores más bajos indican menos correcciones necesarias.
• SUB (Sustituciones) (↓): Cuenta el número de sustituciones de palabras necesarias. Valores más bajos sugieren mejor precisión a nivel de palabra.
• INS (Inserciones) (↓): Mide el número de palabras que necesitan ser insertadas para coincidir con la referencia. Valores más bajos indican mejor completitud.
• Distancia Levenshtein (↓): Calcula el número mínimo de ediciones de caracteres individuales requeridas. Valores más bajos sugieren mejor precisión a nivel de carácter.
• Distancia Damerau-Levenshtein (↓): Similar a Levenshtein pero también considera transposiciones de caracteres. Valores más bajos indican mejor coincidencia a nivel de carácter.
• Similitud Jaro-Winkler (↑): Enfatiza la coincidencia de caracteres al inicio de las cadenas, particularmente útil para evaluar la preservación de la estructura del documento. Rango: 0-1, valores más altos indican mejor similitud.

Para las tareas de HTML a JSON, lo consideramos como una tarea de recuperación y adoptamos cuatro métricas de recuperación de información:

• Puntuación F1 (↑): Media armónica de precisión y exhaustividad, proporcionando precisión general. Rango: 0-1.
• Precisión (↑): Proporción de información correctamente extraída entre todas las extracciones. Rango: 0-1.
• Exhaustividad (↑): Proporción de información correctamente extraída de toda la información disponible. Rango: 0-1.
• Tasa de Aciertos (↑): Proporción de salidas que son JSON válido y cumplen con el esquema. Rango: 0-1.

tagTarea Principal de HTML a Markdown

tagTarea de HTML a Markdown por Instrucciones

tagTarea de HTML a JSON Basada en Esquema

ReaderLM-v2 representa un avance significativo en todas las tareas. Para la extracción de contenido principal, ReaderLM-v2-pro logra el mejor rendimiento en cinco de siete métricas, con puntuaciones superiores en ROUGE-L (0.86), WER (0.39), Levenshtein (0.20), Damerau (928.15) y Jaro-Winkler (0.83). Estos resultados demuestran mejoras integrales tanto en la preservación del contenido como en la precisión estructural en comparación con su versión base y modelos más grandes.

En la extracción por instrucciones, ReaderLM-v2 y ReaderLM-v2-pro lideran en ROUGE-L (0.72), tasa de sustitución (70.16), distancia Levenshtein (0.37) y similitud Jaro-Winkler (0.75, empatado con la versión base). Si bien GPT-4o muestra ventajas en WER y distancia Damerau, ReaderLM-v2-pro mantiene mejor estructura general del contenido y precisión. En la extracción de JSON, el modelo tiene un rendimiento competitivo, manteniéndose dentro de 0.01-0.02 puntos F1 de los modelos más grandes mientras logra altas tasas de acierto (0.99).

tagEvaluación Cualitativa

Durante nuestro análisis dereader-lm-1.5b, observamos que las métricas cuantitativas por sí solas pueden no capturar completamente el rendimiento del modelo. Las evaluaciones numéricas a veces fallaban en reflejar la calidad perceptual—casos donde puntuaciones métricas bajas producían markdown visualmente satisfactorio, o puntuaciones altas generaban resultados subóptimos. Para abordar esta discrepancia, realizamos evaluaciones cualitativas sistemáticas en 10 fuentes HTML diversas, incluyendo artículos de noticias, publicaciones de blog, páginas de productos, sitios de comercio electrónico y documentos legales en inglés, japonés y chino. El corpus de prueba enfatizó elementos de formato desafiantes como tablas de múltiples filas, diseños dinámicos, fórmulas LaTeX, tablas vinculadas y listas anidadas, proporcionando una visión más completa de las capacidades del modelo en el mundo real.

tagMétricas de Evaluación

Nuestra evaluación humana se centró en tres dimensiones clave, con resultados calificados en una escala de 1-5:

Integridad del Contenido - Evalúa la preservación de información semántica durante la conversión de HTML a markdown, incluyendo:

• Precisión y completitud del contenido de texto
• Preservación de enlaces, imágenes, bloques de código, fórmulas y citas
• Retención del formato de texto y URLs de enlaces/imágenes

Precisión Estructural - Evalúa la conversión precisa de elementos estructurales HTML a Markdown:

• Preservación de la jerarquía de encabezados
• Precisión en el anidamiento de listas
• Fidelidad en la estructura de tablas
• Formato de bloques de código y citas

Cumplimiento del Formato - Mide la adherencia a los estándares de sintaxis Markdown:

• Uso apropiado de sintaxis para encabezados (#), listas (*, +, -), tablas, bloques de código (```)
• Formato limpio sin espacios en blanco excesivos o sintaxis no estándar
• Resultado renderizado consistente y legible

Al evaluar manualmente más de 10 páginas HTML, cada criterio de evaluación tiene una puntuación máxima de 50 puntos. ReaderLM-v2 demostró un fuerte rendimiento en todas las dimensiones:

En cuanto a la completitud del contenido, sobresalió en el reconocimiento de elementos complejos, particularmente fórmulas LaTeX, listas anidadas y bloques de código. El modelo mantuvo alta fidelidad al manejar estructuras de contenido complejas mientras que los modelos competidores a menudo omitían encabezados H1 (reader-lm-1.5b), truncaban contenido (Claude 3.5), o retenían etiquetas HTML sin procesar (Gemini-2.0-flash).

En precisión estructural, ReaderLM-v2 mostró optimización para estructuras web comunes. Por ejemplo, en casos de Hacker News, reconstruyó exitosamente enlaces completos y optimizó la presentación de listas. El modelo manejó estructuras HTML complejas no blog que desafiaban a ReaderLM-v1.

En cumplimiento de formato, ReaderLM-v2 demostró particular fortaleza al manejar contenido como Hacker News, blogs y artículos de WeChat. Mientras que otros modelos de lenguaje grandes funcionaron bien con fuentes similares a markdown, tuvieron dificultades con sitios web tradicionales que requieren más interpretación y reformateo.

Nuestro análisis reveló que gpt-4o sobresale en el procesamiento de sitios web más cortos, demostrando una comprensión superior de la estructura y el formato del sitio en comparación con otros modelos. Sin embargo, al manejar contenido más largo, gpt-4o tiene dificultades con la completitud, a menudo omitiendo partes del principio y final del texto. Hemos incluido un análisis comparativo de las salidas de gpt-4o, ReaderLM-v2 y ReaderLM-v2-pro usando el sitio web de Zillow como ejemplo.

Para ciertos casos desafiantes como páginas de aterrizaje de productos y documentos gubernamentales, el rendimiento de ReaderLM-v2 y ReaderLM-v2-pro se mantuvo robusto pero aún tiene margen de mejora. Las fórmulas matemáticas complejas y el código en las publicaciones de ICLR representaron desafíos para la mayoría de los modelos, aunque ReaderLM-v2 manejó estos casos mejor que el Reader API básico.

tagCómo Entrenamos ReaderLM v2

ReaderLM-v2 está construido sobre Qwen2.5-1.5B-Instruction, un modelo base compacto conocido por su eficiencia en tareas de seguimiento de instrucciones y contexto largo. En esta sección, describimos cómo entrenamos el ReaderLM-v2, enfocándonos en la preparación de datos, métodos de entrenamiento y los desafíos que encontramos.

tagPreparación de Datos

El éxito de ReaderLM-v2 dependió en gran medida de la calidad de sus datos de entrenamiento. Creamos el conjunto de datos html-markdown-1m, que incluía un millón de documentos HTML recopilados de internet. En promedio, cada documento contenía 56,000 tokens, reflejando la longitud y complejidad de los datos web del mundo real. Para preparar este conjunto de datos, limpiamos los archivos HTML eliminando elementos innecesarios como JavaScript y CSS, mientras preservábamos elementos estructurales y semánticos clave. Después de la limpieza, usamos Jina Reader para convertir archivos HTML a Markdown usando patrones regex y heurísticas.

Si bien esto creó un conjunto de datos base funcional, resaltó una limitación crítica: los modelos entrenados únicamente en estas conversiones directas esencialmente solo aprenderían a imitar los patrones regex y heurísticas utilizados por Jina Reader. Esto se hizo evidente con reader-lm-0.5b/1.5b, cuyo límite de rendimiento estaba restringido por la calidad de estas conversiones basadas en reglas.

Para abordar estas limitaciones, desarrollamos un proceso de tres pasos que se basó en el modelo Qwen2.5-32B-Instruction, que es esencial para crear un conjunto de datos sintético de alta calidad.

1. Borrador: Generamos salidas iniciales en Markdown y JSON basadas en instrucciones proporcionadas al modelo. Estas salidas, aunque diversas, a menudo eran ruidosas o inconsistentes.
2. Refinamiento: Los borradores generados fueron mejorados eliminando contenido redundante, reforzando la consistencia estructural y alineando con los formatos deseados. Este paso aseguró que los datos estuvieran limpios y alineados con los requisitos de la tarea.
3. Crítica: Las salidas refinadas fueron evaluadas contra las instrucciones originales. Solo los datos que pasaron esta evaluación fueron incluidos en el conjunto de datos final. Este enfoque iterativo aseguró que los datos de entrenamiento cumplieran con los estándares de calidad necesarios para la extracción de datos estructurados.

tagProceso de Entrenamiento

Nuestro proceso de entrenamiento involucró múltiples etapas adaptadas a los desafíos de procesar documentos de contexto largo.

Comenzamos con el pre-entrenamiento de contexto largo, usando el conjunto de datos html-markdown-1m. Se utilizaron técnicas como la atención ring-zag y la codificación posicional rotatoria (RoPE) para expandir progresivamente la longitud de contexto del modelo de 32,768 tokens a 256,000 tokens. Para mantener la estabilidad y eficiencia, adoptamos un enfoque de entrenamiento gradual, comenzando con secuencias más cortas e incrementando gradualmente la longitud del contexto.

Después del pre-entrenamiento, pasamos al ajuste fino supervisado (SFT). Esta etapa utilizó los conjuntos de datos refinados generados en el proceso de preparación de datos. Estos conjuntos de datos incluían instrucciones detalladas para tareas de extracción de Markdown y JSON, junto con ejemplos para refinar borradores. Cada conjunto de datos fue cuidadosamente diseñado para ayudar al modelo a aprender tareas específicas, como identificar contenido principal o adherirse a estructuras JSON basadas en esquemas.

Luego aplicamos la optimización directa de preferencias (DPO) para alinear las salidas del modelo con resultados de alta calidad. En esta fase, el modelo fue entrenado en pares de respuestas borrador y refinadas. Al aprender a priorizar las salidas refinadas, el modelo internalizó las distinciones sutiles que definen resultados pulidos y específicos para cada tarea.

Finalmente, implementamos el ajuste de refuerzo por auto-juego, un proceso iterativo donde el modelo genera, refina y evalúa sus propias salidas. Este ciclo permitió que el modelo mejorara continuamente sin requerir supervisión externa adicional. Al aprovechar sus propias críticas y refinamientos, el modelo mejoró gradualmente su capacidad para producir salidas precisas y estructuradas.

tagConclusión

En abril de 2024, Jina Reader se convirtió en la primera API de markdown compatible con LLM. Estableció una nueva tendencia, ganó una amplia adopción en la comunidad y, lo más importante, nos inspiró a construir modelos de lenguaje pequeños para limpieza y extracción de datos. Hoy, estamos elevando el listón nuevamente con ReaderLM-v2, cumpliendo las promesas que hicimos el septiembre pasado: mejor manejo de contexto largo, soporte para instrucciones de entrada y la capacidad de extraer contenido específico de páginas web en formato markdown. Una vez más, hemos demostrado que con un entrenamiento y calibración cuidadosos, los modelos de lenguaje pequeños pueden lograr un rendimiento de vanguardia que supera a los modelos más grandes.

Durante el proceso de entrenamiento de ReaderLM-v2, identificamos dos ideas clave. Una estrategia efectiva fue entrenar modelos especializados en conjuntos de datos separados adaptados a tareas específicas. Estos modelos específicos para tareas fueron posteriormente fusionados usando interpolación lineal de parámetros. Si bien este enfoque requirió esfuerzo adicional, ayudó a preservar las fortalezas únicas de cada modelo especializado en el sistema unificado final.

El proceso iterativo de síntesis de datos resultó crucial para el éxito de nuestro modelo. A través del refinamiento y evaluación repetida de datos sintéticos, mejoramos significativamente el rendimiento del modelo más allá de los enfoques simples basados en reglas. Esta estrategia iterativa, aunque presentó desafíos para mantener evaluaciones consistentes de críticas y gestionar costos computacionales, fue esencial para trascender las limitaciones del uso de datos de entrenamiento basados en regex y heurísticas de Jina Reader. Esto se demuestra claramente por la brecha de rendimiento entre reader-lm-1.5b, que depende en gran medida de las conversiones basadas en reglas de Jina Reader, y ReaderLM-v2 que se beneficia de este proceso de refinamiento iterativo.

Nos entusiasma recibir sus comentarios sobre cómo ReaderLM-v2 mejora la calidad de sus datos. De cara al futuro, planeamos expandirnos hacia capacidades multimodales, particularmente para documentos escaneados, y optimizar aún más la velocidad de generación. Si está interesado en una versión personalizada de ReaderLM adaptada a su dominio específico, no dude en contactarnos.