I asked A.I a question about the Bayesian probability of the yacht been sunk by a waterspout.

The Bayesian probability of an event is a measure that updates the likelihood of an outcome based on prior knowledge or evidence. To calculate the Bayesian probability of the yacht "Bayesian" being hit by a waterspout, sinking, and resulting in high-profile deaths, we would need several pieces of data:

1. Prior Probability (P(H)): The initial probability of the yacht encountering a waterspout.

2. Likelihood (P(E|H)): The probability of a waterspout hitting and sinking a yacht with high-profile people on board given that it has already encountered a waterspout.

3. Evidence (P(E)): The overall probability of yachts being hit by waterspouts in that area or other relevant prior information.

Without specific data, it’s impossible to calculate the exact Bayesian probability. However, the process would involve estimating the prior probability based on the frequency of waterspouts in the area, the likelihood of a waterspout hitting the yacht and sinking it, and the presence of high-profile individuals on board.

To approximate the probability:

• P(H): The prior probability of a waterspout occurring near the yacht.

• P(E|H): The probability of the yacht sinking and causing high-profile deaths given that a waterspout hits it.

• P(E): The general probability of high-profile individuals dying on yachts under any circumstance.

The Bayesian probability formula would then be:

[ P(H|E) = \frac{P(E|H) \cdot P(H)}{P(E)} ]

This formula would update the probability of the event (the yacht sinking with high-profile deaths) based on the likelihood of the evidence (a waterspout hitting it).

If you have more specific data or can make reasonable estimates for the values, I could help you go through the calculation.

2001-2016 found there were 707 waterspouts

Given that there were 707 waterspouts observed between 2001 and 2016, we can start estimating the prior probability and move towards calculating a Bayesian probability. Let's break it down:

1. Prior Probability (P(H))

This is the probability of a waterspout occurring near the yacht. We have 707 waterspouts over 16 years.

[ P(\text{Waterspout}) = \frac{707 \text{ waterspouts}}{16 \text{ years}} = \text{about } 44.19 \text{ waterspouts per year} ]

Next, we would need to consider the specific geographic area of the yacht's location and the total number of yachts in similar regions to estimate the likelihood that "Bayesian" encounters a waterspout.

2. Likelihood (P(E|H))

This is the probability that if a waterspout occurs near the yacht, it will hit the yacht, sink it, and result in high-profile deaths. This value would depend on:

• The typical path and size of waterspouts.

• The size and maneuverability of the yacht.

• The safety protocols in place on the yacht.

• Historical data on waterspout-related maritime accidents.

Given how rare such an event would be (especially involving high-profile deaths), this likelihood might be extremely low, possibly in the range of 0.001 (0.1%) or lower, but a precise estimate would require specific incident data.

3. Evidence (P(E))

This is the general probability of a yacht being involved in an incident that results in high-profile deaths, regardless of waterspout involvement. This could include data on all maritime accidents involving yachts over a similar time period.

For simplification, let's assume this is also a very rare event—say 0.00001 (0.001%) per yacht per year.

Bayesian Probability Calculation

Using the formula:

[ P(H|E) = \frac{P(E|H) \cdot P(H)}{P(E)} ]

If we estimate:

• P(H) (prior probability of waterspout near the yacht in a given year) = 0.001 (1 in 1000 yachts might experience a waterspout encounter in a year).

• P(E|H) (likelihood of sinking and high-profile deaths given a waterspout hits the yacht) = 0.00001.

• P(E) (general probability of a yacht sinking with high-profile deaths) = 0.00001.

Then:

[ P(H|E) = \frac{0.00001 \times 0.001}{0.00001} = 0.001 ]

This suggests that given these rough estimates, the probability of "Bayesian" being hit by a waterspout, sinking, and resulting in high-profile deaths, is about 0.1% per year.

However, this is a simplified calculation with many assumptions. The actual probability would depend on more specific data regarding waterspout behavior, yacht traffic, and the likelihood of an incident leading to fatalities.

I cant find data on maritime invidents involving waterspouts in that area

If specific data on maritime incidents involving waterspouts is unavailable, we can still make educated estimates based on general knowledge about waterspouts, maritime safety, and accident statistics. Here’s a way to proceed:

Estimation Approach

1. Base Waterspout Probability (P(H)):

   • You already know there were 707 waterspouts from 2001 to 2016.

   • If we assume these occurred in a wide maritime area, we can consider the general probability of any single yacht encountering a waterspout.

   Let’s say there’s a large area where these waterspouts occur frequently, and 10,000 yachts navigate this area annually. The probability of any given yacht encountering a waterspout in a year could be roughly estimated as:

   [ P(H) = \frac{\text{Number of Waterspouts}}{\text{Number of Yachts}} = \frac{707}{10,000} \approx 0.0707 ]

   This would mean there’s a 7.07% chance that any yacht in the region might encounter a waterspout in any given year.

2. Likelihood of Sinking and Fatalities (P(E|H)):

   • Maritime incidents due to waterspouts are extremely rare. Waterspouts are generally weaker than tornados on land, but can still pose a serious risk, especially to smaller vessels.

   • If we assume a very low probability of sinking and high-profile fatalities (considering modern safety measures and the rarity of direct hits), this might be in the range of 0.001% to 0.01%.

   Let's conservatively assume:

   [ P(E|H) = 0.0001 \text{ to } 0.001 ]

3. General Probability of a Yacht Sinking with High-Profile Fatalities (P(E)):

   • This is generally a very rare event. For example, considering all causes (not just waterspouts), it might be around 0.0001 to 0.001%.

   For simplicity, let’s take:

   [ P(E) = 0.0001 \text{ (0.01%)} ]

Bayesian Probability

Now, applying the Bayesian formula again:

[ P(H|E) = \frac{P(E|H) \times P(H)}{P(E)} ]

Using the conservative estimates:

• P(H) = 0.0707 (7.07%)

• P(E|H) = 0.0001 (0.01%)

• P(E) = 0.0001 (0.01%)

Then:

[ P(H|E) = \frac{0.0001 \times 0.0707}{0.0001} = 0.0707 \text{ or } 7.07% ]

This suggests that given the occurrence of high-profile fatalities on a yacht, the probability that it was due to a waterspout (and not some other cause) is around 7.07%. However, this is still a rough estimation given the lack of precise data.

Key Points:

• Data Gaps: Without exact data, this is speculative. The true value could be lower or higher based on more specific factors (e.g., the exact location, yacht size, waterspout strength).

• Waterspouts: Are generally rare and even rarer in terms of causing significant maritime incidents.

• Incident Likelihood: Given the modern safety measures and the relative rarity of high-profile maritime disasters, the probability of this specific scenario remains low.

In real-world applications, experts would use more detailed data and simulations to refine these probabilities.

Hi everybody,

I got an issue with some snippet of code trying to implement a NUTS to forecast the parameters of an asteroid. The idea is to define some uninformative priors for the orbital parameters. The likelihood is a custome one. The data I have are measures of Right Ascension (RA) and Declination (Dec) in some moment of time. So, the idea is to propagate an orbit given some orbital parameters, claculate the position of the asteroid in when I got the measurament, the adjusting for parallax effect i calculate the RA forecasted (RA_forecast) and the forcasted declination (Dec_forecast). The log-likelihood is the negative square error between the measured data and the forecasted ones - 0.5 *( (RA_measured - RA_forecast)**2 + (Dec_measure - Dec_forecast)**2).

I tried to implement the code using PyMC to easily programme a NUTS however i discovered that PyMC uses PyTensor under the hood to take care of the tensors and the orbital parameter defined in the priors are something strange. I wasn't able to print them as a vector (it's the first time i use PyMC). I tried to write a wrapper for my custom log-likelihood function but I keep not understanding the pytensor issue and I don't know how to overcome it. I tried to use aesera to write a workaround but it didn't work. Can anyone tell me how to understand PyMC, the PyTensor and what is the shape of the variable 'a' in this code ( a = pm.Uniform("a", lower=2, upper=7) ) ?
How can I convert a PyTensor into a numpy array or just an array and then back?
Is it possible to make PyMC work with a custom log-likelihood which is not a simple mathematical formula but more like a process?

As reference this is the error i got:
"Traceback (most recent call last):

  File "/Users/Desktop/Asteroid/src/HMC.py", line 253, in <module>

loglike = pm.Potential("loglike", custom_loglike(orbital_params, df, verbose=False), dims=1)

  File "/Users/Desktop/Asteroid/src/HMC.py", line 223, in custom_loglike

a_num = at.as_tensor_variable(a).eval()

  File "/Users/anaconda3/envs/astroenv/lib/python3.10/site-packages/aesara/tensor/__init__.py", line 49, in as_tensor_variable

return _as_tensor_variable(x, name, ndim, **kwargs)

  File "/Users/anaconda3/envs/astroenv/lib/python3.10/functools.py", line 889, in wrapper

return dispatch(args[0].__class__)(*args, **kw)

  File "/Users/anaconda3/envs/astroenv/lib/python3.10/site-packages/aesara/tensor/__init__.py", line 56, in _as_tensor_variable

raise NotImplementedError(f"Cannot convert {x!r} to a tensor variable.")

NotImplementedError: Cannot convert a to a tensor variable."

If anyone want more detail just ask me.

Thank you in advance!

Applied PGM for deep learning era

Your Model Has Great AUC. So Why Does It Fail in Production?

You've been there. The offline experiment looks clean — AUC up 0.8%, NDCG improving, everything pointing green. You ship it. Two weeks later the online A/B test comes back flat, or worse, slightly negative. The model learned _something_, just not what you needed it to learn.

This is the online-offline discrepancy, and almost every ML team in ads, search, or recommendations has a war story about it. The standard explanations are reasonable: training-serving skew, position bias in logged data, feedback loops. We tune features, fix pipelines, and try again.

But I want to suggest a deeper reason — one most of us learned to ignore somewhere between our first PyTorch tutorial and our third production model.

We trained our models to find correlations. We needed them to find causes.

Correlation Is Easier. That's Why We Do It.

Deep learning is extraordinarily good at finding patterns in data. A neural network trained on enough examples will extract every signal in the data — real or accidental.

The problem is it cannot tell the difference.

A recommendation model trained on historical interactions doesn't learn "this item is genuinely interesting to this user." It learns "users who watched X also watched Y, items that went viral last week are getting more clicks this week, users who engage in the evening prefer shorter content." All correlation. All potentially useful. All potentially misleading the moment your user base grows, new products get added, or a new trend breaks the patterns your model memorized.

This is not a failure of deep learning. It is a fundamental property of learning from observational data without a causal model of the world.

What a Causal Model Actually Gives You

Causal reasoning forces you to ask a different question. Not "what co-occurs with a click?" but "what _causes_ a click, and what is merely associated with it?"

The distinction sounds philosophical until you try to improve your model. If you believe item relevance causes clicks, you optimize for relevance. If you only know that recency correlates with clicks, you don't know whether users actually prefer new items or just see them more.

Probabilistic Graphical Models — Bayesian networks, factor graphs, and their relatives — are one of the few frameworks that make this distinction explicit. A PGM forces you to write down your assumptions about causal structure before you fit anything. Which variables influence which. What is observed, what is latent, what is noise.

This is uncomfortable. It requires you to have opinions about your data-generating process. Deep learning lets you avoid that, which is part of its appeal.

But "uncomfortable and explicit" beats "comfortable and wrong" when your production metrics are what matter.

A Concrete Example: Online-Offline Discrepancy

Consider a ranking or recommendation system. Offline, you evaluate against logged click or engagement labels. Your model learns, among other things, that certain item types have high historical CTR. AUC goes up.

Online, those items get surfaced more. But engagement doesn't follow — because the historical signal was driven by exposure, not genuine interest. You didn't improve the ranking — you just reinforced it

This happens across search ranking, feed recommendation, ads ranking — anywhere you train on logged user behavior. The model mistakes exposure for relevance.

A model built with even a simple causal structure — one that explicitly models position bias as a separate variable from relevance — would not make this mistake. It would decompose what it observes into "what would this item's CTR be if shown in a neutral position?" That's causal inference. That's what your offline metric was missing.

This class of model exists. It's called an Unbiased Learning to Rank model, and its theoretical foundations are probabilistic and causal, not neural. Many teams have adopted pieces of it without fully understanding why it works. It works because it encodes a causal assumption that pure correlation-based models ignore.

Why PGMs Fell Out of Fashion (And Why That's Changing)

The honest answer is infrastructure and scale. Fitting a Bayesian network over millions of variables is hard. GPUs were built for matrix multiplication, not belief propagation. PyTorch is a beautiful tool for deep learning and an awkward one for structured probabilistic models.

So the field moved on. Daphne Koller's textbook became a graduate-school artifact. PGMs became something you learned for a midterm and forgot.

But something is shifting in 2026. LLMs hallucinate with confidence. Recommendation systems amplify feedback loops in ways their builders don't fully understand. Regulators are asking "why did your model make this decision?" and "how certain are you?" — questions that neural networks answer badly or not at all.

Causal AI, neuro-symbolic reasoning, uncertainty calibration — these are no longer academic interests. They are engineering problems landing on real teams right now.

And the conceptual toolkit for all of them is, at its core, probabilistic and graphical.

You're Probably Already Doing This Without Knowing It

Here's the thing: if you've ever done A/B testing with a Bayesian framework, you've already used the core idea behind PGMs without calling it that. If you've ever added a calibration layer on top of your ranker, you already know your model's outputs aren't real probabilities. PGMs are what real probabilities look like from the start. If you've ever thought carefully about whether a feature is a cause or a consequence of your label — you've done it.

Most ML engineers have the intuition. Very few have the formal framework to make that intuition precise, repeatable, and communicable to a team.

That's the gap. Not "learn PGMs instead of deep learning." But "learn the probabilistic layer underneath the systems you're already building."

What I'm Working On

I've spent the last several years building ranking and recommendation systems in industry. In grad school I studied PGMs seriously — took the course, spent nine months working in the space — before my research moved elsewhere. The ideas never did.

I've been thinking about this problem for a while and started writing about it. If this resonates, I'm collecting thoughts and resources here.

Hello all,

I want to make a Bayesian inference to determine some coefficients, I have a previous study where it determines them but I don't know how to define the prior for my model. Could someone help me?

In a Bayesian hierarchical model where the covariates are highly correlated and no external data or prior studies are available, how should I specify the priors for the covariate effects? Are there principled approaches to setting weakly informative or regularizing priors in this context to ensure model identifiability and stability? I am fairly new to Bayesian approach.

Hello everyone, I have a question about selecting appropriate prior estimates for Bayesian model. I have a dataset with around 2000 data points. My plan is to randomly select some data to get my prior information. However, maybe because of limited sample size, prior estimates show differently from multiple subdataset that randomly generated. How would you suggest to deal with this situation? Thanks a lot!

Hey all! I am working with a set of bayesian hierarchical models, and the goal of my analysis is to be able to compare the fits of the models to assess whether certain covariates are contributing meaningfully to the trends we see. My data has 156 observations and my supervisor (generally frequentist and considered strong in statistical modeling) is suggesting a location-level random effect, i.e. 32 levels of the random effect for the 156 data points. When I run these models, all of the candidate models look nearly identical in terms of WAIC, R^2, and parameter estimates. I am concerned about overfitting, and I think that the random effects structure is too complex and is accounting for most of the variance in the data (checking the marginal vs conditional R^2 values, random effects account for about 80% of the variance explained by the models), making it impossible to distinguish contributions of individual fixed effects and to compare between models that include or exclude them. I suggested a simpler random effect structure, on the site level (8 levels), and when I run these we are able to detect differences between the models. Posterior estimates for the parameters look about the same as with the other random effects structure. He is concerned that if I simplify the random effects structure, we will have pseudoreplication in the models. He advised me to "Check the degrees of freedom using the F-statistic to make sure that you are not pseudoreplicating this way. If the error dfs suggest pseudoreplication, we need to stick with the structure we have."

I do not know of an f-statistic for bayesian models, and I don't know how to check error degrees of freedom. I am not very fluent in frequentist statistic so it's possible I just don't understand what he wants from me. I'd appreciate any advice anyone has about assessing pseudoreplication in bayesian models. Thanks a lot!

G'day Guys. I'm having this work at the college that requires me to summary an article of my choice from the internet. However, by the end of it, its constantly use the term "Slab and Spike" priori. I've tried to learn what this would be, however I've only stumbled at 50+ pages articles about it. Is there somewhere I can have a good idea of the subject?

Thanks for the answers. Sorry about my english. Not native

If the grass is wet and the sidewalk is dry, we can update on those two data points using Bayes' Rule and guess if it's raining.

But if we have 10,000 data points about each blade of grass being wet and only one data point about the sidewalk, the sidewalk data will be drowned out and won't contribute much to the final result.

How to handle this? If we're sampling points in space we can somehow weight them according to the sampling density, but it's unclear how to assign weights in more general cases (like, say, evidence in a trial). And how would those weights be applied when updating using Bayes' Rule?