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

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. 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. 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: Señal Qué indica Acción Sin Model Card Falta de transparencia mínima Pedir documentación antes de continuar Tokenizer idéntico a modelo conocido Probable derivado No es bloqueante, pero exigí confirmación de licencia Comportamientos "de marca" del base Merge o fine-tune sin instrucción de sistema suficiente Evaluar con prompts de borde antes de integrar Licencia no declarada Riesgo legal real Bloqueante hasta aclaración Sin checkpoint público No reproducible Dependencia de proveedor sin fallback 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. 1. "Si anda bien en el demo, es suficiente." 2. "La licencia es problema del proveedor." ai.meta.com/llama/license —leela antes de integrar, no después. 3. "Es open source, así que es libre." 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. 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. 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. ¿Qué es exactamente un "merge" de modelo LLM? ¿Un modelo mergeado es necesariamente de menor calidad? ¿Cómo puedo verificar localmente si un modelo es derivado de otro? ¿Esto afecta a proyectos que usan modelos locales con Ollama? ¿Qué pasa si el modelo base es Apache 2.0 y el derivado se presenta como "propio"? ¿Necesito saber todo esto para usar un LLM en un proyecto pequeño? 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