Rio de Janeiro’s “own” LLM questioned as possibly derived from an existing model

Rio de Janeiro's "Own LLM" Looks Like a Merge: What to Read Between the Lines

Rio de Janeiro's "Own LLM" Looks Like a Merge: What to Read Between the Lines Back in 2015, when I was just starting to wrap my head around Docker, something similar happened to me — smaller scale, but same flavor: someone in a forum showed off "their microservices stack" and it turned out to be the official Spring example repository with the package names swapped out. Nothing illegal, but definitely not "theirs." I think about that moment every single time an institutional tech announcement shows up with the phrase "developed in-house" and the seams are clearly showing. The news spread fast: Rio de Janeiro presented an LLM they called "their own" or locally produced, and the technical read from the community is that it could be a merge — or a fine-tune on top of — an already existing base model. I'm not going to speculate about intentions or politics. What I care about is the technical question underneath: how do you tell the difference between a model actually trained from scratch and a derived one, and why does that distinction matter when deciding whether to use something like this in production? My thesis: the real problem isn't that a municipality oversold something in a press release. The problem is that most technical teams don't have a minimum protocol for validating what a vendor — government or private — claims about a model they're about to integrate. And that has concrete consequences around licensing, privacy, reproducibility, and long-term support. What "a model merge" Actually Means Technically A merge in the LLM context isn't just copying weights. There are documented techniques — SLERP, TIES, DARE, among others — that combine the weights of two or more models to get blended capabilities. Tools like mergekit (open source, verifiable) make this reproducible on commodity GPU. The core point: a merged model inherits the license of its base model. If the base is LLaMA 3 (Meta), the LLaMA Community License applies. If it's Mistral under Apache 2.0, you have more freedom but there are still conditions. Presenting the result as "our model" without disclosing the lineage doesn't automatically violate anything, but it can create legal and technical commitments that the team integrating it never anticipated. What the technical community detected — based on the public discussion available — are signatures that merged models tend to leave behind: patterns in the weights, responses with identifiable characteristics of the base model, tokenization behaviors that don't match a from-scratch training run. It's not definitive forensic evidence, but it's enough signal to demand more information before integrating. The Checklist I Use Before Integrating Any External Model I use Ollama for local testing and Claude Code for architecture assistance. When I'm evaluating whether a model is worth the integration time — whether it comes from a vendor, a municipality, or an arXiv paper — I run through this checklist before writing a single line of code: # 1. Check the model card: is there a public Model Card with training data? # If there's no Model Card, the model has no documented technical contract. # 2. Test with Ollama locally before depending on an external API ollama pull model-name # 3. Diagnostic query: ask the model to describe its base architecture # (merged models often "know" where they came from if not instructed otherwise) ollama run model-name "What base model were you trained or fine-tuned on?" # 4. Check tokenizer config: an identical tokenizer to a known model is a strong signal # On Hugging Face: tokenizer_config.json → "tokenizer_class" and vocabulary cat ~/.ollama/models/.../tokenizer_config.json | grep tokenizer_class # 5. Search for the model on Hugging Face with the declared architecture # If weights match a public hash, there's traceable lineage Clear cut-off criteria: Signal What it indicates Action No Model Card Minimum transparency missing Request documentation before continuing Tokenizer identical to known model Likely derived Not a blocker, but demand license confirmation "Brand" behaviors from base model Merge or fine-tune without sufficient system instruction Evaluate with edge prompts before integrating License not declared Real legal risk Blocker until clarified No public checkpoint Not reproducible Vendor dependency with no fallback This checklist isn't original to me — it comes from standard model evaluation practice that any team working with LLMs should have documented. Where People Get It Wrong: Three Common Patterns 1. "If it works well in the demo, that's enough." The demo shows the happy path. A merged model can perform well on tasks from the fine-tuning domain and collapse on adjacent tasks because the blended weights have interference zones. Test it with edge cases specific to your domain before trusting it. 2. "The license is the vendor's problem." No. If you integrate a model with a LLaMA license into production without reviewing the terms, the responsibility is shared. This applies equally to a municipality's API and a startup's wrapper. The public source for the LLaMA license is at ai.meta.com/llama/license — read it before integrating, not after. 3. "It's open source, so it's free." Open weights ≠ open source ≠ free license. These three concepts have concrete legal differences. Mistral 7B v0.1 under Apache 2.0 is genuinely quite free. LLaMA 3 has commercial use restrictions for large organizations. A merge inherits the strictest restriction from its components. The architecture mistake here is the same one I see in other technical decision contexts: choosing based on the vendor's name instead of the documented technical contract. If you want to see how I think through that kind of layered decision, the post on decision trees for authentication tokens follows the same logic: explicit criteria before choosing the tool. Decision Matrix: When It's Worth Investigating an Institutional Model Not every institutional model is suspicious. There are legitimate and useful cases. The question is when the validation effort is worth it versus when it's better to walk away: Dig deep if: The model handles sensitive user or citizen data The integration implies dependency on an API with no public SLA The model will make automated decisions (classification, moderation, scoring) No accessible technical documentation exists before integration Use with caution but no hard block if: It's for non-critical internal assistance (drafting documents, summaries) You have a local fallback with Ollama or access to an alternative model The Model Card exists even if it's basic and the license is declared Walk away immediately if: No Model Card, no declared license, no publicly verifiable checkpoint The vendor can't answer what base model they used What this Rio de Janeiro case illuminates is that third scenario: announcement with no accessible technical documentation. It's not necessarily malicious — there can be legitimate restrictions — but from an integration standpoint, a model with no documented lineage is a black box with hidden costs. This connects to something I already wrote about schema validation: when data comes in without an explicit contract, errors show up at runtime at the worst possible moment. Models are the same: the missing documentation doesn't bite you in the demo, it bites you in production three months later. What Can't Be Concluded Yet I want to be clear about the limits of this analysis: There's no publicly verifiable evidence that Rio de Janeiro's model violates any specific license. The technical discussion points to similarities, not proven infractions. I don't know whether the municipality has private agreements with the base model's provider that permit the use and the way they presented it. A merge can be technically legitimate and valuable: many production models are fine-tunes or merges of base models. The problem isn't the technique — it's the lack of transparency about it. Model signatures aren't forensics: the patterns the community identifies are signals, not proof. An expert at the original provider with access to the weights could say much more. What can be concluded: if a technical team integrates this model — or any similar institutional model — without a public Model Card, they're taking on technical and legal risk without sufficient information. That's an architecture decision, not a moral judgment. For a deeper look at how I structure external dependency decisions in general, the post on Prisma and when to go below the ORM uses the same framework: knowing when the abstraction is enough and when you need to look underneath. FAQ: Concrete Questions About Institutional LLMs and Merges What exactly is an LLM "merge"? It's a technique that combines the weights of two or more trained models to produce a resulting model with blended capabilities. It's not fine-tuning (which adjusts weights on new data) or RAG (which retrieves external information). It's a mathematical operation on the model's tensors. Tools like mergekit on GitHub document it with technical detail. Is a merged model necessarily lower quality? Not necessarily. There are merges that outperform their components on specific benchmarks. The problem isn't technical quality — it's transparency: if the vendor says "trained from scratch" and it's a merge, that information gap has real consequences for licensing and support. How can I verify locally whether a model is derived from another? The most accessible way is to compare the tokenizer_config.json with that of the suspected base model. If the vocabulary and tokenizer class are identical, there's lineage. You can also run both models with the same edge prompts and compare response patterns. It's not definitive, but it's enough to know whether it's worth requesting more information. Does this affect projects using local models with Ollama? Directly, no — Ollama works with Hugging Face models and public registries where lineage is usually documented. The alert applies when you're integrating a model provided by a third party — government, corporate, or startup — that hasn't published its technical spec. What happens if the base model is Apache 2.0 and the derivative is presented as "theirs"? Apache 2.0 doesn't require the derivative to use the same name or declare the relationship, but it does require that the original copyright notice be included if distributed. If the municipality distributes the model or uses it as a service without including that notice, there could be non-compliance. If it's pure internal use, the conditions are different. Do I need to know all of this to use an LLM in a small project? For a personal project or technical exploration, no. For production integration with third-party data, yes. The minimum threshold is: do I have a declared license? Do I know what base model it uses? Is there accessible technical documentation? If all three answers are no, the risk isn't worth the convenience. My Take and the Concrete Next Step I don't think the Rio de Janeiro case is unique or especially egregious compared to other institutional tech announcements. What I do think is that it exposes a real gap: most technical teams integrating LLMs don't have a lineage validation protocol. They improvise it or skip it entirely. My practical recommendation is simple: before integrating any external model — from any source — run through the five-point checklist I described above. It won't take you more than an hour. What can take weeks is discovering that the model you put in production has a license restriction you never saw coming. The Rio de Janeiro case is a good early warning that institutional hype around LLMs is going to produce more situations like this. It's worth having the protocol ready before it lands on your doorstep. If you want to see how I apply the same "what's under the abstraction" criterion in other parts of the stack, the post on MCP and portable tools across models hits exactly that problem: not depending on a single vendor without understanding the technical contract you're signing. This article was originally published on juanchi.dev

3 hours ago

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. 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: 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. 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

3 hours ago