campos escritos para extraer de una pila de documentos reales: montos, fechas, límites de cobertura, un valor estructurado por campo. El reflejo predeterminado es enviar cada campo a una API alojada de clase GPT-4. Funciona y la factura es la partida más grande del costo de funcionamiento del oleoducto. La mayoría de esos campos son búsquedas simples, un modelo mucho más pequeño se maneja bien y usted está pagando precios emblemáticos por todos ellos.
La reacción obvia es cambiar por un modelo pequeño y embolsarse los ahorros. Si se hace a ciegas, resulta contraproducente. Un modelo demasiado débil para el trabajo devuelve resultados escritos incorrectos o falla en una transformación y, si nadie lo verifica, se envía el valor incorrecto. Entonces la respuesta no es “usar el modelo grande” ni “usar el modelo pequeño”. Se trata de elegir el modelo de la misma manera que los ladrillos anteriores eligen un método: por criterios, luego verificar y escalar sólo cuando la verificación falla.
Este artículo complementa Enterprise Document Intelligence, la serie cuya filosofía se establece en Amplify the Expert, la serie que construye RAG empresarial a partir de cuatro ladrillos: análisis de documentos, análisis de preguntas, recuperación y generación. Desarrolla una decisión dentro del bloque generacional: ¿qué modelo ejecuta la llamada y qué sucede cuando el más barato no es lo suficientemente bueno? Se apoya en el Artículo 6C (despacho), que ya lee un modelo sugerido de nivel de la pregunta analizada, el Artículo 8C (validación), la señal que desencadena una escalada, y el Artículo 10 (análisis adaptativo), la misma forma de inicio-barato-escalada-bajo-demanda aplicada al analizador.
Todo lo que aparece a continuación está respaldado por un punto de referencia real: una tarea de extracción de campos de unos cientos de campos escritos en docenas de documentos, además de un barrido enfocado de veinte modelos locales contra un buque insignia alojado, todo a temperatura 0 con salida JSON. Los números son agregados. Aquí no aparece ningún documento, etiqueta de campo o figura de ese punto de referencia.
📓 El cuaderno ejecutable para este artículo está en GitHub: doc-intel/notebooks-vol1. Ejecuta el mismo campo a través de la cascada, imprime el costo por campo y el veredicto de validación en cada escalón, y muestra la escalada activando solo en los campos en los que el modelo local barato se equivoca.
1. Dos ángulos: el coste y el bucle
Hay dos razones para preocuparse por la selección del modelo y se refuerzan mutuamente.
El ángulo del costo es directo. Los modelos emblemáticos cuestan un orden de magnitud más por llamada que uno local pequeño. En un trabajo de extracción con miles de llamadas a nivel de campo, o un asistente de corpus que responde miles de preguntas al día, el proyecto de ley modelo domina el costo de funcionamiento. La mayoría de esas llamadas no necesitan un buque insignia. Dirigir los más simples a un modelo más barato es dinero que queda sobre la mesa hasta que lo hagas.
El ángulo del bucle tiene que ver con la corrección bajo esa restricción. No se pueden reducir costos suponiendo que un modelo pequeño funcionará. Se comienza con un modelo, se comprueba si su respuesta se cumple y se escala a uno más sólido sólo cuando la comprobación falla. El bucle es lo que hace que el ahorro de costos sea seguro: el modelo barato es el intento predeterminado, no una apuesta, porque un intento fallido se detecta y se vuelve a intentar en un modelo más grande en lugar de enviarse.
El costo te empuja hacia abajo en la escala del modelo. El bucle evita que te caigas. Esta forma de escalamiento en caso de falla, de primero barato, tiene un nombre en la literatura: una cascada LLM.
2. Lo que dicen los números
El diseño de la Sección 3 se basa en dos hechos medidos. Tómelos primero, porque son la razón por la que la cascada tiene la forma que tiene.
2.1 El barrido: más grande no es mejor
Mire lo que hicieron veinte modelos locales en la tarea única sin procesar: leer el fragmento recuperado y devolver el valor escrito. Mismo mensaje, mismos campos, temperatura 0.
Tres conclusiones surgen directamente de ese gráfico, y cada una da forma al diseño.
Más grande no es mejor. Un modelo 4B (qwen3:4b) y un 7B (mistral:7b) encabezan el campo local. Un 12B y un 14B (gemma3:12b, phi4:14b) se encuentran debajo de ellos. Dos modelos de la misma familia, uno el doble de tamaño que el otro, empatan. El recuento de parámetros es un mal predictor. La familia modelo y cómo se entrenó importa más. Esta es exactamente la razón por la que el bucle no debe subir una escalera de tamaño ciego: el siguiente peldaño a menudo no es el siguiente tamaño.
Hay un piso. Los modelos sub-2B caen por un precipicio (qwen2.5:1.5b al 12%, llama3.2:1b al 6%), y un modelo 0.5B que probamos devolvió JSON vacío en la mayoría de los campos: no es una respuesta incorrecta, no hay ninguna respuesta. Comenzar allí quema una iteración de bucle en un peldaño que nunca iba a mantenerse. Existen criterios para empezar por encima del suelo, no en él.
El costo no es velocidad. El buque insignia alojado respondió en aproximadamente 1,4 segundos por campo, más rápido que la mayoría de los modelos locales de 7B a 14B (aproximadamente de 2,6 a 7,6 segundos cada uno en una sola GPU de consumo). El pequeño local compra billetes más bajos y documentos que nunca salen de la máquina. No compra latencia. Si la velocidad es la limitación, el modelo local barato suele ser el predeterminado equivocado, y eso pertenece al criterio del despachador.
Un número más que da que pensar. El mejor modelo local pequeño, ejecutado por sí solo en la tarea primaria, acertó aproximadamente un tercio de los campos. Rápido (unos pocos segundos por campo) y no lo suficientemente bueno para enviar. Un modelo local pequeño es viable sólo cuando el bucle lo respalda: un fragmento de recuperación preciso, el contenido del mensaje correcto, validación en cada campo y código que realiza el formateo estricto. Las siguientes tres secciones son ese respaldo.
2.2 La palanca más importante es el contenido rápido, no el tamaño del modelo.
Antes de gastar un modelo más grande, gaste el aviso. El mayor salto en todo el índice de referencia no provino de más parámetros. Surgió de poner el vocabulario empresarial de la tarea, el glosario que asumen los campos, en el mensaje.
Ambos modelos saltan. El modelo local pequeño pasa del 38% al 62% de acierto. El buque insignia pasa del 62% al 100%. El buque insignia tampoco es mágico sin el glosario. Necesitaba las definiciones para terminar el trabajo.
El fallo concreto que esto soluciona es el vocabulario que el modelo no comparte con el documento. Un campo etiquetado como deducible por reclamo en un documento es retención en otro y un número simple en un tercero; una aseguradora denomina una prima de una manera y la otra de otra distinta. Un modelo pequeño muestra las conjeturas de los fragmentos sin procesar. Entréguele la definición del campo que está llenando, los sinónimos, las unidades y la suposición se convierte en una lectura. Este es el mismo vocabulario del ladrillo 2 que eleva la recuperación, se reutiliza en el momento de la generación y es más barato que cualquier actualización de modelo porque ayuda a todos los peldaños a la vez.
3. La cascada: criterios, bucle y división
He aquí el mecanismo al que apuntan los dos hechos. Elija un peldaño inicial según criterios, valide su resultado y escale solo en caso de falla, y divida la tarea en lugar de escalar cuando la falla sea una transformación difícil. Tres movimientos, en ese orden.
3.1 Elija el modelo inicial por criterios
El modelo inicial no es el más pequeño que tienes. Tres criterios establecen un mínimo sensato, por lo que el bucle comienza en el peldaño derecho y no en el inferior.
Confidencialidad. No se puede enviar un documento confidencial a una API alojada en absoluto. Eso obliga a adoptar un modelo local independientemente de lo que sería más barato o más potente en la nube, y la elección inicial se convierte en el mejor modelo local que se adapta a la máquina. (Detectar y etiquetar un documento como confidencial es una preocupación que se abordará más adelante; este artículo supone que la etiqueta llega como entrada).
Fiabilidad de la salida escrita. La respuesta de la serie es siempre un objeto escrito. El contrato de extracción del punto de referencia es pequeño y estricto: un número puro, su moneda, el calificador de precisión mantenido por separado y un valor booleano para determinar si el campo estaba allí.
clase ValorExtraído(ModeloBase): valor: flotante | Ninguna moneda: str | Ninguna precisión: str | No se encontró ninguno: booleano
Los modelos fuertes lo emiten limpiamente. Los más débiles y más pequeños lo emiten de manera menos confiable, eliminando la moneda, incorporando "por evento" al número o inventando un valor cuando deberían haber establecido encontrado = Falso. Por lo tanto, un modelo inicial pequeño es viable sólo cuando se combina con la validación: no se confía en su resultado escrito, se verifica (Artículo 8C) y se deja que el error impulse la escalada.
Complejidad de la transformación. Algunos trabajos esconden una dura transformación de una sola vez que hace tropezar a los modelos pequeños incluso cuando la recuperación fue perfecta. Ese es el tercer criterio y tiene su propia solución en el §3.3.
El despachador que lee estos tres es pequeño.
clase GenerationPlan(BaseModel): modelo: str necesidades_validación: bool necesidades_paso_split: bool max_escalations: int = 2 def plan_generación(doc, forma): if doc.confidential: devolver plan_local(forma) devolver plan_nivel(forma)
local_plan fija el mejor modelo local y establece need_validation=True, porque la salida escrita de un modelo pequeño siempre se verifica. tier_plan comienza desde el nivel sugerido por el Artículo 6C y solo solicita validación cuando ese nivel es pequeño. Ambos leen need_step_split off de la forma de respuesta, el tercer criterio, desarrollado en §3.3.
3.2 Validar y luego escalar solo en caso de falla
Con un modelo inicial elegido, la generación se convierte en un ciclo acotado corto, no en una sola llamada.
def generate_with_escalation(pregunta, contexto, plan, escalera): para el modelo en ladder.from_(plan.model, up_to=plan.max_escalations): respuesta = generar(pregunta, contexto, modelo=modelo) if validar(respuesta, contexto): # Artículo 8C devolver respuesta devolver NotAnswered()
Ejecute el modelo elegido. Valide el resultado con las comprobaciones del Artículo 8C: si la forma escrita es correcta, si existen los intervalos citados, si el texto citado realmente aparece en la fuente. Si se aprueba la validación, se envía y el modelo económico simplemente hace el trabajo de un buque insignia por una fracción del costo. Si falla, escale: vuelva a ejecutar el mismo campo en el siguiente modelo y valide nuevamente. El bucle está limitado, por lo que un campo patológico no puede girar indefinidamente; escala al modelo más fuerte y, si incluso eso falla, devuelve un valor escrito sin respuesta en lugar de un valor incorrecto.
Este es el eco generacional del Artículo 10. Allí, una página comienza en el analizador barato y sólo escala a una más pesada cuando una verificación barata dice que el análisis no es lo suficientemente bueno. Aquí, un campo comienza en el modelo barato y solo aumenta cuando la validación dice que la respuesta no es lo suficientemente buena. La misma forma de ingeniería de bucles: pagar por la costosa herramienta sólo en los casos que la necesitan, y dejar que una verificación determinista, no una suposición, decida cuáles son esos casos.
3.3 Divide la tarea y mide el coste de la confidencialidad
Pasar a un modelo más grande no es la única solución para uno que falla, y no siempre es la correcta. Algunas fallas son una transformación compleja, no un modelo débil, y la cura es descomponer el paso en lugar de pagar por más capacidad.
El ejemplo resuelto es una cantidad monetaria en un formato numérico limpio. Como se muestra en 3M, es posible que un modelo pequeño no devuelva de manera confiable 3000000, un tres seguido de seis ceros; tropieza al hacer el reconocimiento y la escala de una sola vez. Un modelo más grande lo cubre, pero también lo hace dividir la transformación: deje que el modelo solo apunte a la línea fuente y deje que el código determinista convierta 3M en 3000000. Cada mitad es fácil. El modelo lee, el código calcula y el formato duro nunca depende en absoluto de la capacidad del modelo.
Esa división tiene una segunda recompensa: el documento en bruto puede permanecer enteramente local. El modelo elige una línea, el código la formatea y solo los fragmentos anónimos son elegibles para dejarlos a un formateador alojado en sentido descendente. Pero la división no es un almuerzo gratis, y el punto de referencia es contundente al respecto. La ejecución de la arquitectura totalmente local de “puntos de modelo, formatos de código” redujo la precisión en los mismos campos en comparación con permitir que un modelo capaz extraiga y formatee de una sola vez. La razón es simple: apuntar a la línea correcta es en sí mismo difícil, y una línea incorrecta condena el campo antes de que se ejecute el código.
Así pues, la división es una herramienta real con un coste real. Consúltelo cuando el fracaso sea una transformación difícil que el modelo sigue omitiendo, o cuando la confidencialidad obligue al documento a permanecer local. Mida la precisión que intercambia por ello. No asuma que la descomposición es siempre una victoria; en una tarea en la que un modelo capaz puede extraer y formatear limpiamente en una sola pasada, una pasada gana.
Por lo tanto, el bucle tiene dos vías de escape cuando falla la validación, no una: escalar el modelo o dividir la tarea en pasos que el modelo actual pueda manejar. El indicador need_step_split del despachador registra cuál obtiene este campo.
4. Conciliar con el envío y la validación del lado de las preguntas
Esta selección no es una idea nueva. Cierra un bucle que la serie ya había abierto.
El artículo 6C (despacho) lee un nivel de modelo sugerido a partir de la pregunta analizada: una simple búsqueda de hechos y una síntesis de múltiples saltos llevan diferentes niveles antes de que se ejecute la generación. Ésa es la señal del lado de la pregunta. Este artículo agrega la señal del lado del documento y la respuesta (confidencialidad, confiabilidad de la salida escrita, complejidad de la transformación) y, fundamentalmente, la retroalimentación: el 6C propone un nivel inicial, la generación lo ejecuta y la validación del Artículo 8C confirma que el nivel fue suficiente o desencadena la escalada. Los tres encajan: 6C sugiere, la generación intenta, 8C juzga, el bucle se intensifica.
5. Conclusión
La elección del modelo es una decisión fundamental, no una constante. El modelo barato es el predeterminado correcto cuando un despachador basado en criterios elige un peldaño inicial sensato, la validación protege la salida y un bucle acotado escala solo los casos que fallan, dividiendo la tarea cuando la falla es una transformación difícil en lugar de un modelo débil. El barrido es la razón para confiar en la forma y desconfiar de los atajos: el tamaño no ordena la precisión, un modelo local pequeño por sí solo obtiene un tercio de los campos, y la palanca más importante es el vocabulario que ingresa en el mensaje, no el recuento de parámetros por el que paga. El costo baja porque la mayoría de los campos nunca abandonan el peldaño barato. La corrección se mantiene porque los que necesitan más la obtienen, basándose en evidencia, no en una corazonada.
6. Lecturas adicionales y fuentes
Los artículos de la serie entre los que se encuentra esta cascada, ya publicados:
En la idea del modelo en cascada, los anclajes externos:
Chen, Zaharia & Zou, FrugalGPT: Cómo utilizar modelos de lenguaje grandes mientras se reducen los costos y se mejora el rendimiento (arXiv 2305.05176, 2023). La canónica cascada LLM de barato a caro con un anotador entre los peldaños. Madaan et al., AutoMix: Mezcla automática de modelos de lenguaje (arXiv 2310.12963, 2023). La autoverificación de la respuesta del modelo pequeño decide si se debe enrutar: el mismo bucle de verificación y luego escalamiento que construye este artículo. Ong et al., RouteLLM: Aprender a enrutar LLM con datos de preferencia (arXiv 2406.18665, 2024). Un enrutador aprendido entre un modelo fuerte y uno débil, el primo basado en datos del despachador de criterios aquí.