Lagotto Meter: model transparency, architecture inversion, and what changes from July 22, 2026

7/22/2026 / 8 minutes to read / Tags: lagotto-meter, ai-readiness, gemini, groq, architettura

The problem: two analyses, two different scores

On July 22, a user ran two analyses of google.com in quick succession on Lagotto Meter. The results were:

• First analysis: 40/100 — semantic consistency 30/30
• Second analysis: 18/100 — semantic consistency 8/30

Delta of 22 points. Same URL, same day, same hour.

The technical scores were identical in both analyses — llms.txt, JSON-LD, robots.txt, sitemap do not change from one request to another. All the variance was concentrated in the 30 points of semantic consistency, the only component calculated by a language model.

The cause was simple: the two analyses had intercepted two different models. The first Groq (Llama 3.3 70B), the second Gemini 2.5 Flash — or vice versa. The user didn’t know it because the result did not declare it.

The architecture before the fix: Groq primary, Gemini fallback

Until July 22, Lagotto Meter worked like this:

Groq Llama 3.3 70B  →  PRIMARY  (free, answers 95% of requests)
         │ if error/quota →
         ▼
Gemini 2.5 Flash    →  FALLBACK  (paid, intervened rarely)

The logic was economic: Groq has a generous free tier and handled almost all the load. Gemini only came in when Groq exhausted its daily tokens.

The problem was twofold.

First: the two models are not equivalent on semantic consistency. Llama 3.3 70B and Gemini 2.5 Flash have different architectures, different training data, and different alignment philosophies. On a semantic evaluation task, the variance between the two can reach ±15 points out of the available 30. The technical scores are deterministic — calculated by Python code, not the model. But semantic consistency is generative, and here the models diverge.

Second: there was a bug in the code. The payload sent to Gemini was the reduced one meant for Groq (about 12,000 tokens), not the full one. Gemini has a context window of 1 million tokens and can receive entire files — but user_content_gemini was built but never used. The Gemini fallback was working with less information than it could have.

The fix: architecture inversion

The correction inverted the hierarchy and resolved the payload bug:

Gemini 2.5 Flash    →  PRIMARY  (temp 0.3, receives full files ~125k char)
         │ if error/quota →
         ▼
Groq Llama 3.3 70B  →  FALLBACK  (temp 0.3, receives reduced payload ~12k tokens)

Gemini 2.5 Flash is now the model that responds to every analysis under normal conditions. Groq becomes the safety net when Gemini exhausts its daily quota.

The temperatures are identical for both: 0.3. We did not change them — we only declared them.

Transparency: what the user sees now

The original problem was not just technical — it was communicative. The user receiving two different scores had no way of understanding why.

We added three levels of transparency.

In the result and in the email, the model line is now explicit:

When Gemini responds (normal case):

Model: gemini-2.5-flash (primary) | temperature: 0.3 — lake8.dev Lagotto Meter v1.0

When Groq responds (fallback):

Model: llama-3.3-70b-versatile via Groq (fallback) | temperature: 0.3 — lake8.dev Lagotto Meter v1.0

In case of Groq fallback, an explicit warning block appears between the model line and the technical scores:

--- MODEL NOTE ---
⚠ Analysis performed in fallback mode (Groq — token Gemini exhausted).
  The 30 points of semantic consistency can diverge up to ±15 points
  compared to a Gemini 2.5 Flash analysis (primary model).
  Technical scores are deterministic and unchanged regardless
  of the model. For maximum reliability on the semantic score, repeat
  the analysis when the primary service is available.

In the Lagotto Meter page, the methodology section explicitly describes the two models, the temperatures, and what changes between primary and fallback. The frontend always shows the model line visible and an orange warning box only when Groq responds.

Why the models diverge on semantic consistency

It is worth explaining, as it is not a bug — it is an intrinsic feature of any system using LLM for evaluation.

Semantic consistency measures how much the message perceived by the agent corresponds to the message declared by the site. It is a generative task: the model reads the site’s files, builds a representation of the “perceived message”, and evaluates the distance from the “declared message”.

Two different models will build different representations of the same text. Not because one is wrong and the other right — but because they have learned to read the world with different weights. Llama 3.3 70B and Gemini 2.5 Flash were trained on different corpora, with different architectures, and optimized for partially different objectives.

The technical scores do not have this problem: llms.txt exists or does not exist, robots.txt has or does not have AI directives, JSON-LD is valid or not. They are binary verifications or counts, executed by Python code, independent of the language model.

Semantic consistency is different. It is the only component where the model expresses an interpretative judgment. It is also the most informative component — but it requires that the model used is declared explicitly, for…

Sources

Author: Giantommaso Fogli
Publication Date: 2026-07-22

Rights and Attribution

Images, logos, and photographs are the property of their respective owners. Used for commentary purposes.