I was talking with a client the other day who wanted a weather dashboard for his high-traffic travel site. The numbers alone were not enough for him. He wanted to tell his users what to wear before they headed out the door. “Just write a bunch of if-statements for the temperature,” he said. Sure. Try maintaining that once you have 50 weather codes plus humidity and wind chill in the mix.
Rather than hardcode logic that breaks the moment a new weather condition shows up, I built a proper AI-powered weather pipeline. Databricks does the heavy lifting and GPT-4o-mini supplies the common sense, which is what turns raw JSON into advice somebody can act on. It uses the same fast AI prototyping approach I have leaned on for other enterprise projects.
Building the AI-powered weather pipeline
My first instinct was to fetch the data and run it through a local script. That falls apart quickly. Anything that has to survive in production needs orchestration behind it. We pulled the raw data from the OpenWeatherMap API and stored it in the Databricks Unity Catalog. A structured Silver Layer is what keeps the project manageable as it grows. Skip it and you end up with stale, inconsistent data, which is one of the faster ways to make your AI features break user trust.
Here is the extraction phase, wrapped in a Python class. I prefix my helper functions so nothing collides in a shared notebook.
class bbioon_Weather_Service:
def __init__(self, api_key):
self.api_key = api_key
def bbioon_fetch_current_weather(self, city, country):
url = f"https://api.openweathermap.org/data/2.5/weather?q={city},{country}&APPID={self.api_key}&units=imperial"
response = requests.get(url)
if response.status_code != 200:
raise Exception(f"API Error: {response.status_code}")
return response.json()The transformation layer: GPT-4o-mini integration
The transformation step is the reason this AI-powered weather pipeline exists at all. Rather than parse the “Clouds” or “Rain” string ourselves, we hand the temperature and conditions to GPT-4o-mini. It is cheap, it is fast, and it reads the nuance of dressing for the weather better than any regex I have written. One detail worth copying: the raw JSON goes into the Unity Catalog as our source of truth before the AI touches it.
# Calling the LLM for dressing suggestions
def bbioon_get_ai_suggestion(weather_desc, temp):
client = OpenAI(api_key=dbutils.widgets.get('OPENAI_API_KEY'))
prompt = f"The weather is {weather_desc} at {temp}F. Suggest what to wear in one short sentence."
response = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content": prompt}]
)
return response.choices[0].message.contentOrchestration and the “lakehouse” way
This does not run once by hand. Databricks Jobs triggers the notebook every hour, so the dashboard never goes stale. The cleaned data lands in a Delta Table in append mode, which gives us an audit trail. If the LLM ever hallucinates and tells somebody to wear a parka in 90-degree heat, we can go back and see exactly what the API returned at that timestamp.
This gets complicated fast. Juggling Databricks Unity Catalog and LLM token costs takes some practice. If you would rather not spend your week debugging somebody else’s pipeline, send me a note. I have probably run into it already.
So, what’s the point?
- Raw numbers are cold. People want to know what to do with them.
- GPT-4o-mini handles the messy conditional logic that would be miserable to hardcode.
- Save every raw API response to a Silver layer like Delta Tables so you can audit it later.
- If it is not scheduled, it is not a pipeline. It is a script you have to remember to run.
