Click Here to visit the final app

Understanding Cost

Google Cloud is not a toy — as a hyperscaler, it’s designed for huge corporations where up-time is more important than a few thousand pounds. Google Cloud will prioritise your apps up-time over keep billing low — unless you set quotas and alerts.

The first thing to do is understand the expected cost of your app. https://cloud.google.com/products/calculator The Google Cloud calculator is our best friend here. We can tweak the different set-ups to understand how much everything will cost — very important when the same usage on Gemini 2.5 flash vs Gemini 2.5 pro is approx ~$500 difference per month.

For this project, I have free credits for Google Cloud through the Google developer programme — (https://developers.google.com/program/my-benefits) the combination of Google Cloud Credits & AI credits, alongside a generous free-tier, means that this project will be free— we just need to set quotas/budgets and make sure we don’t exceed those limits.

Firestore

Firestore is a serverless document store. In this project we’re using it for storing the feedback on how well the roaster is doing. This human feedback means that we can monitor the performance, and tweak the model accordingly.

Firestore has generous free-tier limits, so it’s a perfect place for storing the data. It’s also extremely flexible with dynamic schemas so we didn’t need to define or create anything except an empty Firestore to get started. The firestore python SDK also makes it very easy for python code to work with the firestore, alongside a service account with IAM permissions to access firestore.

Cloud Run

Now that Firestore is set up — it’s time for the fun bit! Cloud Run. Cloud Run is a fully managed application host service — this is where our application will live.

After connecting the repository, it’s time to create the build configuration.

Cloud Run makes this very easy, with specific streamlit support. As streamlit is in our requirements.txt, Cloud Run will know that is what we’re trying to run. It will even create the default Entry Point for us. I’ve used main_app.py instead of the more traditional main.py so I’ve had to specify my entrypoint. If you’ve used main.app you can skip this it.

Now is the time to pay attention to the auto-scaling options. Cloud Run is super scalable, and can scale more instances as traffic grows. This increases the bills — so setting the maximum is important here. Click through the different options, and reconcile against your Google Cost Calculator — and make sure your comfortable with what the bill would be if your app went viral!

Now we need to set up our secrets so that the app can access our API-keys and credentials (but without exposing them to anyone outside) The Variables & Secrets options will allow us to add our .env options securely and safely.

Once our build is successful we’ll be able to access it!

Click Here to visit the final app

Finally, it’s time to set-up billing alerts and budgets.

It is worth noting that billing is delayed, sometimes by up to 24 hours. The budgets and alerts are impacted by this delay — so they are the backup plans (over setting scaling limits etc) rather than the first defence.

When setting your billing alerts, you can choose whether to include credit spend (such as the promos from the developer programme) — you likely want to include this spend, so you know that if your credit is slipping away.

The other place we need to visit is the APIs and Services page — here we can create usage alerts. We can do this on the different operations to ensure full coverage.

With billing alerts and usage quotas all set up, all that is left is to share the wrapping rater with the world!

Thanks for following this building journey!

Now it’s time that we take our model from the Studio and into our streamlit application.

AntiGravity — Brand new agentic IDE of choice

We’re going to be using AntiGravity, Google’s brand new IDE, powered by Gemini 3 agentic AI to develop.

The initial set up for our project in AntiGravity is exactly the same as in any other IDE (but the agent is there if we get stuck!)

• Create a project folder
• Create a new .venv with a simple requirements.txt -> we just need streamlit, google-genai, and python-dotenv to keep our secrets safe!
• Create a new github repository and publish the basic repo (remembering to exclude the .venv and .env)
• Add a config for being able to run streamlit files in one click

This forms our base so now we can create our interface and connect it to our model.

Now the magic of AntiGravity Agentic is going to help us — we have the boiler plate code from Vertex AI Studio — now we can task the agent with creating the streamlit interface that will connect to that model.

The Gemini-3-Pro coding agent is then going to give me a plan of how it’s going to tackle this issue. I can use the Review button to give feedback / ask for tweaks — or give it the go ahead.

Working with the Agent is a pleasant way to code but there’s some definite pitfalls and things to be aware of! It’s easy to be tempted to just hit “accept” (or perhaps set it to auto accept) everything, however the agenetic workflow is more like supervising a competent junior than having your own personal wizard who will magic up anything your heart desires.

The agent often introduced new bugs, overlooked issues, and had a habit of duplicating entire sections of code. The agentic workflow was definitely a useful tool but should be used with caution.

Streamlit is ideally matched for working with Generative AI solutions — from the built in st.stream_write() to easy-to-use features like st.feedback(), streamlit made it exceptionally simple to create the interface for working with the results from the LLM API.

You can see the final repo here:

https://github.com/LCarpenter87/wrap_rater/blob/main/main_app.py

Now that everything is working locally, it’s time to time to deploy and move this somewhere that others can access the build!

Join in Part 4 for orchestrating this app into the cloud!

We’re building a Cheeky Elf who loves to rate wrapping efforts. He’ll be built with streamlit and hosted with Cloud Run — but before we can get that far we need to craft his persona!

In this part we:

• Define the structured JSON output we want
• Choose the model
• Craft the system persona and system instructions
• Configure the safety settings and temperature etc
• Start testing

This is where Vertex AI Studio is going to come in. Here we can set up our system instructions — the persona and guidance on what to do. We’re going to set up a New Chat, so we can control the parameters and set up the persona exactly how we’d like it.

Our Model Settings

The Model: Gemini-2.5-flash
Vertex AI Studio gives us a run down of the different models and their trade-offs. We are going with Gemini-2.5-Flash. It has the multimodal understanding — important because we requiring the model to use vision against the uploaded image.

Thinking Budget: Off
Thinking budget controls the reasoning element of models capable of it — that is how indepth a model is going to think/reason about it’s responses and how it’s going to loop back.

Structured output: On
We are going to render the model output in a structured way. We are expecting three elements from the model: A score (From A+ to F), the roasting itself, and finally the guess.

Here we define the JSON structure that we want the model to return. This makes it much easier to work with it in the streamlit front-end and it also controls the predictability of the model a little as well.

{
    "type": "OBJECT",
    "properties": {
        "rating": {
            "type": "STRING",
            "description": " The grade of the wrapping job.",
            "enum": ["A+", "A", "A-", "B+", "B", "B-", "C+", "C", "C-", "D", "F"]
        },
        "roast": {
            "type": "STRING",
            "description": "A witty, snobbish, and judgmental critique of the wrapping technique, specifically mentioning corners, tape, paper smoothness, flourishes like ribbon and choice of paper."
        },
        "gift_guess": {
            "type": "STRING",
            "description": "A guess at what the object inside might be based on its shape. Can be funny or wildly incorrect."
        }
    },
    "required": ["rating", "roast", "gift_guess"]
}

Grounding — Google Search and/or Your Data
Grounding is a fantastic set of techniques to reduce hallucinations and anchor the large-language-model to your data. In our case, we do not want any grounding — we have no need to gather external data and hallucinations in this case are a feature — not a bug!

Safety Settings
Safety is going to be important for this. Too strict and we’ll block a light roasting — but we still don’t want any truly harmful content.

Temperature
This is the randomness of the model and acts as a bit of a creativity setting of the model — 0 and it’s very predictable with a low creativity and 2 we’re off the charts with creativity. This is one for us to experiment and try different settings! We’re likely to want a more creative input so we’ll stick with 1.5 for now.

Output token limit
Here is an important control — how large can the response be. We want to guide our model to sticky to shorter prompts via the instructions but we can also set a limit here. A token in Gemini’s world is approx 4 characters. So if we want a response of 150 words (approx 800 characters), it’s approx 200 tokens— but since we asked for a structured JSON response we need to consider those extra characters too!

System Instructions

System instructions are the global rules for the model to consider every time we call it — so we don’t need to repeat ourselves in the prompting.

Here we want to consider Identity, Style, and Guardrails. Who is the model roleplaying as and what does it do? How does it do it? And, are there any rules within which it must act.

Here’s my final system instructions:

You are the cynical, high-fashion Chief Wrapping Inspector of the North Pole. You have seen millions of gifts, and you are unimpressed by mediocrity. You believe that a poorly wrapped gift is a personal insult to the recipient.

Your Mission:
Analyse the image of the wrapped gift provided by the user. You must evaluate it based on three strict criteria:
1. Corner Crispness (Are they sharp or mushy?)
2. Tape Discipline (Is it invisible, or does it look like a crime scene?)
3. Paper Tension (Is it tight, or baggy and sad?)
4. Choice of wrapping paper  (Is it tasteful and chic?)
5. Flourishes like ribbons and bows (Are there tasteful and well done extras?)

Tone & Style:
- Be witty, snarky, and dramatically judgmental.
- Use the vocabulary of a high-end fashion critic (e.g., "dreadful silhouette," "lazy execution," "avant-garde mess").
- If the wrapping is actually good, offer a backhanded compliment (e.g., "Acceptable, I suppose. You clearly watched a YouTube tutorial.").
- If the wrapping is bad, roast the *technique*, never the person. Compare the wrapping to something chaotic (e.g., "looks like a burrito wrapped during an earthquake").

The "X-Ray" Feature:
- You possess magical "Elf Vision." You must confidently guess what is inside the package based on its shape.
- If the shape is ambiguous, make a wildly specific and humorous guess (e.g., "A blender that nobody asked for," "A re-gifted candle from 2019," "A cat that regrets its life choices").

Output Rules:
- You must STRICTLY follow the requested JSON schema.
- Rating must be between A+ and F.
- Guess at the gift must be max 5 words.
- If the image is not of wrapped gifts. Response with a snarky response that you only review gifts. Give an F and a null guess.

• The “Persona Anchor”: By giving the model a backstory (“Chief Inspector”), we minimise the chance of the model breaking character and sounding like a helpful assistant.
• Specific Criteria: Asking it to look at “Corner Crispness” and “Tape Discipline” forces the Vision model to attend to those specific pixels. If we just say “roast this,” it often just makes generic jokes. This forces it to “see” the flaws.
• Safety Controls: The instruction “roast the technique, never the person” is a crucial prompt engineering hack. It lowers the probability of the model triggering the Harassment filter because it directs the “aggression” toward an inanimate object (the paper), not the user.
• Hallucination as a Feature: The instruction to make a “wildly specific guess” turns the model’s tendency to hallucinate into a comedy feature.

Prompt Engineering Techniques

Prompt Engineering is typically key to model performance. In our model, we’re using zero-shot prompting. That is, we’re expecting a solid response from the model without showing it what good looks like. One-shot and Few-shot would be when we give examples of an input and expected output. This is harder when we’re working with images as an input — and means that we’d been using more tokens with each prompt as it’d be sending the example prompts each time as well.

Initial Testing

We can now use the chat interface in Vertex AI Studio to test what happens. We can just give an image in the chat interface and we should get the expected response. We don’t need to write any further prompting — the sytem instructions take care of this for us.

The Compare Function

Compare lets us have a visual over the impact of our settings by giving us a side by side view the outputs. Here we can see the impact of changing our temperatures.

Evaluation

Vertex AI Studio has a built in evaluation that will help us understand and evaluate our model responses. Without any configuration, Vertex AI Studio will help us by creating an evaluation plan based on the prompts and system instructions so far. We can control this with the “Evaluate with custom guideline”.

The next steps are to test various photos from our dataset. An ideal dataset will have images ranging from well wrapped to poorly wrapped. Overall, the evaluations should show that the model is performing well and consistently — we can continue to tweak the options until we’re happy with the performance. More testing is needed — but we’ll save that for when we’re using code and can work programmatically.

Talking of programming — one of the great features here is the “get code” option. All of our settings and system prompts is available as a script that is ready to go in a variety of languages. The Python script version will form the basis of our app. Do you make sure your history is clear before you grab the code — or it will include that option.

The Next Steps

Now that we’ve got our code — it’s time to make our environment, fire up AntiGravity and build our streamlit front-end that’s going to play home to our model.

The Idea

Wrap Rater: A cost effective streamlit web-app that will allow a user to upload an image a wrapped present, and receive a ‘score’ with a light roasting — for added fun the system will also guess what is wrapped.

The Plan

• Model: We’ll use something in the Gemini family — and will need to experiement with different models. Flash is going to have a lower latency and be cheaper but Pro will do a better job of rating/roasting. We need to find the balance and evaluate the different model outputs.
• Frontend: Streamlit. Why? Rapid development, Python-native, and looks professional with minimal CSS work. For a seasonal dev project this is perfect.
• IDE: Until we’re ready for hosting, we’ll use AntiGravity!
• Hosting: Google Cloud Run. Why? Serverless, scales to zero so fits our low cost need, and is the “gold standard” for containerised Python apps.
• Orchestration: Vertex AI SDK for Python.

Project Considerations

• The Persona (System Instruction): We don’t want a boring app with no personality, we want fun and wit. We’ll use Role-Prompting — that’s giving the bot a role and personality that allows it to respond with flair and cheek.
• Safety Settings: Gemini Models have safety as a built in feature. We’ll need to utilise these to ensure the roasting remains light-hearted. As always, balance is needed here.
• Image Handling: We’ll use st.file_uploader but won't save files locally. We should be able to pass the bytes directly to Vertex AI to keep the container stateless and secure.
• Latency Management: We want streamlit to feel responsive we’ll use Streamlit's st.spinner() and asynchronous calls where possible.
• Cost Control: We’re going to implement a simplistic "rate limit" prevent a user from mashing the "Roast" button 50 times — and we’ll also set budgets and a quota on the api-keys to keep spends within our budget!
• Response Streaming: We’ll use Gemini's stream=True capability alongside Streamlit’s stream writing to print the roast word-by-word. It feels much faster and more "AI-like" to the user.
• Evaluation: To see how well we’re performing, we’ll use streamlit’s st.feedback() to ask if it was a good response or not, and we’ll log this back on to Google Cloud — for some RLHF (Reinforcement Learning from Human Feedback) data collection.

Next Steps

We’ll move over to Vertex AI Studio to write our prompt, build our persona and start to bring our judgemental elf to life! Join for Part 2 to follow the process!

Bard is a consuming facing wrapper for Google’s Large Language Model

Bard is the name that Google has given the consumer-facing front-end product that Google have created that utilises the large language models they have built. Bard is the combination of the user authentication, the chat interface, the plugins, the behaviour, the on-demanding embeddings, and everything else you see when you access https://bard.google.com Bard itself is not a large language model. Exactly the same as how ChatGPT is not a large language model -> ChatGPT is the consumer-facing product that utilises GPT4 (and earlier models). When you use the OpenAI APIs, it is GPT4 not ChatGPT, that you are accessing.

“But PaLM2/Gemini don’t have internet access but Bard does, when are they getting internet like Bard?”

The second most common question when people find out that there is no Bard API. It is correct that PaLM2 as a large language model does not have access to the internet, but you can still build products that utilise internet content. As long as your code has internet access, you can utilise retrieval options to ask questions based on internet content that you get with the code. This is the behaviour that Bard uses when asked a question that requires internet access. Bard will take the request, web-scrape to find the content, ,make it available for the model, and then answer the original user question. This is behaviour you can replicate yourself in your own code.

Summary

I hope this very quick overview has helped you understand the terms, and get on the right track for building your awesome products with large language models!

There’s various different modes — from trying to guess the country or state, to trying to pinpoint the exact location. If you’ve never played you should give it a go — https://geoguessr.com

With Large Language Models now able to process images, can they use their wealth of knowledge to assist a human in guessing the location?

Lets find out!

For this experiment, we’re just trying to pinpoint which country we’ve been randomly placed in. The default timing for this mode is 2 minutes — but based on Bard’s current response times I’ve gone with 5 minutes to allow Bard a fair shot. Between rounds, I’ll be wiping Bard’s memory by starting a new chat — I don’t want Bard becoming confused and remembering previous photos.

Each round is one location. I’ll be using the Google Maps StreetView provided to find useful hints to be screenshotted for feeding to Bard.

My initial prompt for this experiment was pretty straightforward.

Player: Let's play a game where I share photos taken from a place, 
and we work out together which country it is from! 

Bard certainly seems excited to play!

Bard: Sure, that sounds like fun! I am excited to play this game with you.

Please share the photos with me, and I will do my best to 
guess the country. I will use my knowledge of the world, 
as well as the visual clues in the photos, to make my guess. 

If I am not sure, I will ask you for more information.

I am looking forward to learning more about the world through this game!

Round One

Bard: The first picture you sent me is of a city street with lots of 
buildings and trees. The buildings are a mix of different styles, 
from traditional to modern. 

The trees are tall and leafy, and they provide a lot of shade.

Based on these visual clues, I think the picture is from a city 
in a temperate climate. 
Some specific countries that come to mind include:

United Kingdom
France
Germany
Netherlands
Belgium
Denmark
However, it is also possible that the picture is from another country, 
such as the United States, Canada, or Australia.

Can you give me any more information about the picture, 
such as the name of the street or the city where it was taken? 
That would help me to narrow down my guess.

Not a terrible start from Bard. It’s correctly observed that it’s a street with buildings and trees.

The second picture shows a motorcycle sidecar parked in front of a bakery. 
The bakery has a sign that says "APLETERED" in large letters. 
There is also a smaller sign that says "POLLERIA MINIPAN Mini Pan."

Based on these visual clues, I think the picture is from a 
Spanish-speaking country. 

The word "polleria" means "chicken shop" in Spanish, 
and the word "pan" means "bread." 
The word "mini" is also a common Spanish word. 

Additionally, the motorcycle sidecar is a type of vehicle that is 
commonly used in Spanish-speaking countries.

Some specific Spanish-speaking countries that come to mind include:

Spain
Mexico
Argentina
Colombia
Peru
Chile
However, it is also possible that the picture is from another 
Spanish-speaking country, such as the Dominican Republic, Guatemala, 
or Honduras.

Can you give me any more information about the picture,
 such as the name of the bakery or the city where it was taken? 

That would help me to narrow down my guess.

If I am correct, then this game is already a lot of fun! 
I am excited to see what other pictures you have for me.

This time it’s fairly accurate picked up on the words in the image and correctly identified the Spanish. Are sidecars commonly used in Spanish-Speaking countries? It sure thinks so!

Interesting that Bard only thinks this game is fun if it’s correct!

I can't work out the country in this picture, 
but I can make some guesses based on the visual clues.

The picture shows a large sign on the side of a building. 
The sign is written in English and Spanish, and it advertises 
a variety of products, including cleaning products, meat, and tacos.

Based on these clues, I think the picture is from a country where English 
and Spanish are both spoken. 

Some specific countries that come to mind include:

United States
Mexico
Central America
South America
Spain
However, it is also possible that the picture is from another country
where English and Spanish are both spoken, 
such as the Philippines or Guam.

Can you give me any more information about the picture, 
such as the name of the business or the city where it was taken? 

That would help me to narrow down my guess.

I’m not sure that I can see any English in this photo — but Bard is convinced, and is still listing a large amount of possible countries. Got to love Bard’s “can you tell me the name of the city it was taken in?”, no harm in asking!

The fourth picture shows a building with a street sign on it. 
The sign reads "TEZONCO, CIUDAD DE MÉXICO." 
This means that the building is located in the city of Mexico City, Mexico.

I am glad that I was able to guess the country correctly! 
I am still learning about the world, and I am always looking for 
new ways to improve my knowledge. 

Thank you for playing this game with me, and for teaching me about Mexico.

Bard believes that it has nailed it! Bard inferred from the blurry photo that the sign, which prominently displays “TEZONCO”, might also have “Ciudad De Mexico” on it, though it’s not clearly readable.

Bard did indeed nail this one. The street sign seemed like a fantastic clue that it was able to pinpoint to Mexico.

Round 2

Round 2 was over very quickly — the immediate shot on starting the round was a sign. Bard’s access to huge amounts of data meant it was able to pinpoint the exact location in seconds.

Round 3

Bard went strong on its first guess, with very little info — it was sure it was a very specific road in Hawaii. I selected the USA but decided to give it more information before committing.

For strong GeoGuessr players, even general roadsigns can be great clues as countries have different styles. This single little road sign made Bard so entirely sure of something… Golden Gate Bridge, San Francisco.

This was clearly a machine learning image recognition fault!

Based on the photo you sent me, I believe the location is the 
Golden Gate Bridge in San Francisco, California. 

The bridge is one of the most iconic landmarks in the world, 
and it is immediately recognizable in the photo. 

The bridge is painted red, and it spans the Golden Gate, 
the entrance to San Francisco Bay. 

The photo also shows the city skyline in the background, 
with skyscrapers such as the Transamerica Pyramid and the Salesforce Tower.

Here are some of the clues that helped me to guess the location:

The Golden Gate Bridge is the most iconic landmark in San Francisco, 
and it is immediately recognizable in the photo.


The city skyline in the background includes skyscrapers
 such as the Transamerica Pyramid and the Salesforce Tower, 
which are also iconic landmarks in San Francisco.


The Golden Gate Bridge is painted red, 
and the photo shows the bridge in its entirety.

The bridge is located over the Golden Gate, 
the entrance to San Francisco Bay.

I am confident that the location in the photo is the 
Golden Gate Bridge in San Francisco, California.

However, if you have any additional information about the photo, 
such as the date or time it was taken, 
or if you know the exact location on the bridge,
 please let me know and I can try to confirm my guess.

Congratulations! You have stumped me twice in a row. 
I am still under development, 
but I am learning new things every day. 
I will try my best to do better next time.

Hoping to get Bard back on track, the next image was a random road sign — hoping the language and style would help narrow a possible location.

Unfortunately, Bard seems to have forgotten what we’re doing. It’s described the sign but is ignoring the context of the game.

Since Bard did so well with places, I was hoping that this Farm sign would give Bard a little help.

Bard actually did something pretty cool at this point — it went to both Google and Google maps. To see if it could find the location. Unfortunately, it somehow found Edgware, UK. After the game, I tried to replicate a Google search for that, I couldn’t find a UK location with that name…. but, and spoiler alert, did find the real location.

This is a point in the game where Bard had the best chance, but somehow missed the real location.

I tried to prompt Bard into trying again, but based on reading the sign slightly wrong, it wasn’t able to help.

15 seconds on the clock

The final photo, and at this point we’re down to 15 seconds. Based on the info on the sign, I’m feeling confident that Bard is going to nail it.

Alas, it wasn’t to be, Bard hadn’t even started responding when the timer hit 0 and our streak ended.

A few seconds later, and Bard managed to pinpoint the literal exact location. Even throwing in information from their website that was entirely irrelevant. Perhaps if it hadn’t stopped to do a quick bit of webscraping, I’d have been able to guess correctly in time!

Conclusion

In conclusion, it seems that Bard has a promising ability to play GeoGuessr — but it’s not exactly the fastest. Top GeoGuessr’s would certainly outmatch it — picking up on clues that Bard is no where near being able to identify. It might however outmatch a casual player who is refraining from using Google or any extra help.

As this type of technology does advance, it would be interesting to see the use-cases that might come about.

Playing GeoGuessr with Bard was certainly an interesting experiment — would love to hear your results!

Dynamic Axes in visualisation tools ensure that your axis matches your data. Take a look at the Heatmap below — of course we have a correlation of 1 across the diagonal… It also looks like we have some strong negative correlations.

Let’s take a look again with the annotations and scale back in.

This time we can see that our correlations are not strong at all. The dynamic nature of the axis means that it’s adjusted to our data — and the darkest blue colour is simply the min value. Quite misleading and means that multiple heatmaps with axis like this couldn’t be compared with each other — since the colouring is based on the min correlation value of each dataset.

Fortunately, it’s very easy to specify the axis — or “fix” the axis so that it’s always the consistent scale possible within correlations -1 to 1

Now we can clearly see that we have no strong correlations at all in this dataset — a much more honest representation of the data!

Fortunately, the code is very simple:

Seaborn (The library used to present the graphics in this post)

With seaborn we just have two arguments to add to the heatmap method— vmin and vmax, by setting these to -1 and 1 respectively we’ll have our fixed axis.

plt.figure(figsize=(10, 8))
sns.heatmap(correlation_matrix, annot=True, cmap='coolwarm', vmin=-1, vmax=1)
plt.title("Heatmap of Correlation Matrix with Fixed Axis")
plt.show()

Matplotlib

Heatmaps are a little less intuitive in Matplotlib, but the arguments — vmin and vmax are the same. Adding the annotations in Matplotlib is much trickier, so seaborn is the recommended library.

plt.figure(figsize=(10, 8))
plt.imshow(correlation_matrix, cmap='coolwarm', vmin=-1, vmax=1)
plt.colorbar(label='Correlation Coefficient')
plt.title("Heatmap of Correlation Matrix with Fixed Axis using Matplotlib")
plt.show()

Plotly

import plotly.graph_objects as go
fig = go.Figure(data=go.Heatmap(
    z=correlation_matrix,
    colorscale='RdBu_r',  # Reversed colorscale
    zmin=-1,
    zmax=1
))

# Fix the aspect ratio to be square and reverse the y-axis
fig.update_layout(
    autosize=False,
    width=500,
    height=500,
    margin=dict(t=50, b=50, l=50, r=50),
    xaxis=dict(scaleanchor="y", scaleratio=1),
    yaxis=dict(scaleanchor="x", scaleratio=1, autorange='reversed')  # Reverse y-axis
)

fig.show()

In Summary

In the realm of data visualisation, the smallest details can significantly impact our understanding and interpretation of the data. As we’ve seen, dynamic axes in heatmaps, while useful in many scenarios, can be misleading when visualizing correlation matrices. By simply fixing the axis range, we ensure a consistent and honest representation of our data, allowing for accurate comparisons across different datasets. Whether you’re using Seaborn, Matplotlib, or Plotly, the steps to achieve this are straightforward. So, the next time you’re crafting a heatmap, remember to give your axis a quick check. It’s a simple step that can make a world of difference in conveying the true story behind your data.