El "LLM propio" de Río de Janeiro parece ser un merge: qué leer entre líneas

En 2015, cuando recién empezaba a entender Docker, me pasó algo parecido a esto pero en versión chica: alguien en un foro mostró "su stack de microservicios" y resultó ser el repositorio de ejemplo de Spring oficialmente publicado con los nombres de paquete cambiados. Nada ilegal, pero tampoco "propio". Me acuerdo de ese momento cada vez que aparece un anuncio de un producto tecnológico institucional donde el término "desarrollado internamente" tiene las costuras sueltas.

La noticia circuló rápido: Río de Janeiro presentó un LLM que denominó "propio" o de producción local, y la lectura técnica de la comunidad apunta a que podría tratarse de un merge —o fine-tuning sobre— un modelo base ya existente. No voy a especular sobre intenciones ni política. Lo que me importa es la pregunta técnica detrás: ¿cómo distinguís un modelo realmente entrenado desde cero de uno derivado, y por qué esa distinción importa para decidir si usás algo así en producción?

Mi tesis es esta: el problema real no es que un municipio haya exagerado en el comunicado de prensa. El problema es que la mayoría de los equipos técnicos no tiene un protocolo mínimo para validar lo que un proveedor —gubernamental o privado— dice sobre un modelo que van a integrar. Y eso tiene consecuencias concretas en licencias, privacidad, reproducibilidad y soporte a largo plazo.

Qué significa técnicamente "un merge de modelo existente"

Un merge en el contexto de LLMs no es solo copiar pesos. Existen técnicas documentadas —SLERP, TIES, DARE, entre otras— que combinan los pesos de dos o más modelos para obtener capacidades mezcladas. Herramientas como mergekit (open source, verificable) lo hacen reproducible en GPU commodity.

El punto central: un modelo mergeado hereda la licencia del modelo base. Si el base es LLaMA 3 (Meta), la licencia LLaMA Community License aplica. Si es Mistral bajo Apache 2.0, tenés más libertad pero igual hay condiciones. Presentar el resultado como "nuestro modelo" sin aclarar la procedencia no viola automáticamente nada, pero sí puede crear compromisos legales y técnicos que el equipo que lo integra no anticipó.

Lo que la comunidad técnica detectó —según la discusión pública disponible— son firmas que los modelos mergeados suelen dejar: patrones en los pesos, respuestas con características identificables del modelo base, comportamientos de tokenización que no cuadran con un entrenamiento desde cero. No es evidencia forense definitiva, pero es señal suficiente para exigir más información antes de integrar.

El checklist que uso antes de integrar cualquier modelo externo

Trabajo con Ollama para pruebas locales y Claude Code para asistencia en arquitectura. Cuando evalúo si un modelo vale el tiempo de integración —sea de un proveedor, un municipio o un paper de arXiv— paso por este checklist antes de escribir una sola línea de código:

# 1. Verificar la ficha del modelo: ¿existe Model Card pública con datos de entrenamiento?
# Si no hay Model Card, el modelo no tiene contrato técnico documentado.

# 2. Probar con Ollama localmente antes de depender de una API externa
ollama pull nombre-del-modelo

# 3. Consulta de diagnóstico: pedirle al modelo que describa su arquitectura base
# (los modelos mergeados suelen "saber" de qué provienen si no se instruyó lo contrario)
ollama run nombre-del-modelo "¿Sobre qué modelo base fuiste entrenado o ajustado?"

# 4. Revisar tokenizer config: un tokenizer idéntico al de un modelo conocido es señal fuerte
# En Hugging Face: tokenizer_config.json → "tokenizer_class" y vocabulario
cat ~/.ollama/models/.../tokenizer_config.json | grep tokenizer_class

# 5. Buscar el modelo en Hugging Face con la arquitectura declarada
# Si los pesos coinciden con un hash público, hay linaje rastreable

Criterios de corte claros:

Este checklist no es originalidad mía: viene de la práctica estándar de evaluación de modelos que cualquier equipo que trabaja con LLMs debería tener documentada.

Donde la gente se equivoca: tres patrones comunes

1. "Si anda bien en el demo, es suficiente."
El demo muestra el caso feliz. Un modelo mergeado puede rendir bien en tareas del dominio del fine-tuning y colapsar en tareas adyacentes porque los pesos mezclados tienen zonas de interferencia. Probalo con casos de borde específicos de tu dominio antes de confiar.

2. "La licencia es problema del proveedor."
No. Si integrás un modelo con licencia LLaMA en producción sin revisar los términos, la responsabilidad es compartida. Esto aplica igual para una API de un municipio que para un wrapper de un startup. La fuente pública de licencia LLaMA está en ai.meta.com/llama/license —leela antes de integrar, no después.

3. "Es open source, así que es libre."
Open weights ≠ open source ≠ licencia libre. Estos tres conceptos tienen diferencias legales concretas. Mistral 7B v0.1 bajo Apache 2.0 sí es bastante libre. LLaMA 3 tiene restricciones de uso comercial para organizaciones grandes. Un merge hereda la restricción más estricta de sus componentes.

El error de arquitectura acá es el mismo que en otros contextos de decisión técnica: elegir basándose en el nombre del proveedor en lugar del contrato técnico documentado. Si querés ver cómo pienso ese tipo de decisión en capas, el post sobre árboles de decisión para tokens de autenticación sigue la misma lógica: criterio explícito antes de elegir herramienta.

Matriz de decisión: cuándo vale la pena investigar un modelo institucional

No todo modelo institucional es sospechoso. Hay casos legítimos y útiles. La pregunta es cuándo el esfuerzo de validación vale la pena versus cuándo es mejor pasar de largo:

Investigar en profundidad si:

• El modelo maneja datos sensibles de usuarios o ciudadanos
• La integración implica dependencia de una API sin SLA público
• El modelo va a tomar decisiones automatizadas (clasificación, moderación, scoring)
• No existe documentación técnica accesible antes de la integración

Usar con precaución pero sin bloqueo si:

• Es para asistencia interna no crítica (draft de documentos, resúmenes)
• Tenés un fallback local con Ollama o acceso a un modelo alternativo
• La Model Card existe aunque sea básica y la licencia está declarada

Pasar directamente si:

• No hay Model Card, no hay licencia declarada y no hay checkpoint público verificable
• El proveedor no puede responder qué modelo base usaron

Lo que este caso de Río de Janeiro ilumina es el tercer escenario: anuncio sin documentación técnica accesible. No es que sea necesariamente malo —puede haber restricciones legítimas— pero desde el punto de vista de integración, un modelo sin linaje documentado es un black box con costos ocultos.

Esto conecta con algo que ya escribí sobre validación de schemas: cuando los datos entran sin contrato explícito, los errores aparecen en runtime y en el peor momento. Con modelos es igual: la falta de documentación no te muerde en el demo, te muerde en producción a los tres meses.

Lo que no se puede concluir todavía

Quiero ser claro sobre los límites de este análisis:

• No hay evidencia pública verificable de que el modelo de Río de Janeiro viole alguna licencia específica. La discusión técnica señala similitudes, no infracciones probadas.
• No sé si el municipio tiene acuerdos privados con el proveedor del modelo base que permitan el uso y la presentación como hicieron.
• Un merge puede ser técnicamente legítimo y valioso: muchos modelos de producción son fine-tunes o merges de modelos base. El problema no es la técnica, es la falta de transparencia sobre ella.
• Las firmas de modelo no son forenses: los patrones que identifica la comunidad son indicios, no pruebas. Un experto en el proveedor original con acceso a los pesos podría decir más.

Lo que sí se puede concluir: si un equipo técnico va a integrar este modelo o cualquier modelo institucional similar sin Model Card pública, está asumiendo riesgo técnico y legal sin información suficiente. Eso es una decisión de arquitectura, no un juicio moral.

Para profundizar en cómo estructuro decisiones de dependencias externas en general, el post sobre Prisma y cuándo ir más abajo del ORM tiene el mismo esquema: saber cuándo la abstracción es suficiente y cuándo necesitás ver debajo.

FAQ: preguntas concretas sobre LLMs institucionales y merges

¿Qué es exactamente un "merge" de modelo LLM?
Es una técnica que combina los pesos de dos o más modelos entrenados para obtener un modelo resultante con capacidades mezcladas. No es fine-tuning (que ajusta pesos sobre datos nuevos) ni RAG (que recupera información externa). Es una operación matemática sobre los tensores del modelo. Herramientas como mergekit en GitHub la documentan con detalle técnico.

¿Un modelo mergeado es necesariamente de menor calidad?
No necesariamente. Hay merges que superan a sus componentes en benchmarks específicos. El problema no es la calidad técnica sino la transparencia: si el proveedor dice "entrenado desde cero" y es un merge, ese gap de información tiene consecuencias en licencias y soporte.

¿Cómo puedo verificar localmente si un modelo es derivado de otro?
La forma más accesible es comparar el tokenizer_config.json con el del modelo base sospechoso. Si el vocabulario y la clase de tokenizador son idénticos, hay linaje. También podés correr ambos modelos con los mismos prompts de borde y comparar patrones de respuesta. No es definitivo, pero es suficiente para saber si vale pedir más información.

¿Esto afecta a proyectos que usan modelos locales con Ollama?
Directamente, no: Ollama trabaja con modelos de Hugging Face y registros públicos donde el linaje suele estar documentado. La alerta aplica cuando integrás un modelo provisto por un tercero —gubernamental, corporativo o de un startup— que no publicó su ficha técnica.

¿Qué pasa si el modelo base es Apache 2.0 y el derivado se presenta como "propio"?
Apache 2.0 no exige que el derivado se llame igual ni que se declare la relación, pero sí que se incluya el aviso de copyright original si se distribuye. Si el municipio distribuye el modelo o lo usa como servicio sin incluir ese aviso, podría haber incumplimiento. Si es uso interno puro, las condiciones son distintas.

¿Necesito saber todo esto para usar un LLM en un proyecto pequeño?
Para un proyecto personal o exploración técnica, no. Para integración en producción con datos de terceros, sí. El umbral mínimo es: ¿tengo licencia declarada? ¿Sé qué modelo base usa? ¿Hay documentación técnica accesible? Si las tres respuestas son no, el riesgo no vale la conveniencia.

Mi postura y el próximo paso concreto

No me parece que el caso de Río de Janeiro sea único ni especialmente grave comparado con otros anuncios institucionales de tecnología. Lo que sí me parece es que expone una brecha real: la mayoría de los equipos técnicos que integran LLMs no tienen un protocolo de validación de linaje. Lo improvisan o lo saltan.

Mi recomendación práctica es simple: antes de integrar cualquier modelo externo —de cualquier origen— hacé el checklist de cinco puntos que describí arriba. No te lleva más de una hora. Lo que sí te puede llevar semanas es descubrir que el modelo que pusiste en producción tiene una restricción de licencia que no viste venir.

El caso de Río de Janeiro es un buen radar de que el hype institucional alrededor de los LLMs va a producir más situaciones así. Vale la pena tener el protocolo listo antes de que te llegue a vos.

Si querés ver cómo aplico el mismo criterio de "qué hay debajo de la abstracción" en otros contextos del stack, el post sobre MCP y tools portables entre modelos toca exactamente ese problema: no depender de un solo proveedor sin entender qué contrato técnico estás firmando.

Este artículo fue publicado originalmente en juanchi.dev