kianN

Happy to chat more in depth if more details would be helpful. I think my contact info is accessible from my HN profile.

To clarify, I wasn't criticizing your approach or product, more responding to the people dismissing the problem you are solving.

Regarding my experience, I have done a fair amount of work in the contact center space with long calls. I used statistical Bayesian approaches which I found to be much more resilient especially on long documents than embeddings/transformers. It also provided a joint modeling foundation for classification with much lower label requirements than BERT or traditional ML.

I see a fair number of comments here advocating for either codex to hand-roll this themselves, or to simply punt to SQL. I do want to advocate for the difficulty of the problem, even if I can't speak to the company itself.

At the scale of a few hundred to a few thousand documents, especially short documents, there are a few out of the box methods that can yield reasonable results, whether it be embedding clustering or leveraging LLMs for tagging.

However as your (1) datasets gets larger (2) documents expand from tweets and text messages to 30+ minute conversations and (3) you build downstream analytics on top of the learned semantic units, you really start to feel the limitations of LLMs and embedding for reliable annotation. That doesn't even get into the nuances associated with taxonomy management, seasonality, and model drift.

TLDR; this problem solved effectively has a lot of value and is a lot harder than it seems.

The author really extracted the core tenants of exactly how my former research mentor and I ended up building our business.

We started with the second two points: our core technology was a sampler that enables arbitrary hierarchical Bayesian graph models for sparse data, our constraint was cpu bound tractable compute. The piece that took us the longest to discover was the fact that our end products need to be separate from our underlying technology.

We were given that advice in various words from many people even before we started but some lessons need to be lived to be learned.

Roughtime is a really cool protocol we came across when we were hardening a license server. It provides a distributed mechanism for cryptographically verifiable time via chained requests. It’s not as precise as NTP (hence rough) but in practice it’s more than precise enough. It also has some nice additional properties: for example, NTP servers are often used as DDOS amplifiers, whereas roughtime servers return a smaller payload than the request.

The ecosystem is currently very young. Each additional deployment meaningfully strengthens the ecosystem (ours is only the fifth server) and each additional implementation helps harden the spec (which is soon approaching 1.0).

We wrote a bit more about it in a separate article: https://blog.sturdystatistics.com/posts/roughtime/

Official protocol document: https://datatracker.ietf.org/doc/html/draft-ietf-ntp-roughti...

Haha that’s true, but the timezone is left as an exercise for the reader for now

We are going to publish that publicly next time we have a free day, though its publication will likely render the analysis redundant :)

Yeah Show HN has a pretty interesting distribution compared to standard posts due to the long-term visibility on the Show page. The odds of a Show HN post breaking 10 points is significantly higher than an average post, but of the posts that clear 10 points, I recall the likelihood of breaking 100 points to be similar to a regular post.

As a sidenote: That clock is so cool: I was just mesmerized for multiple minutes!

The code provided is to reproduce the analytical results from the annotated data; my impression is that you're more interested in the details of the annotation process than running into an issue with that code?

My company's core technology extends topic models to enable arbitrary hierarchical graphs, with additional branches beyond the topic and word branch. We expose those annotations in a SQL interface. It's an alternative/complementary approach to embeddings/LLMs for working with text data. In this case, the hierarchy broke submissions down into paragraphs added a layer to pool them into submissions, and added one more layer to pool them by year (on the topic branch).

Our word branch is a bit more complicated, but we have some extended documentation on our website if you are interested in digging a bit deeper. Always happy to chat more about the technical details of our topic models if you have any questions!

Overview of Our Technology: https://blog.sturdystatistics.com/posts/technology/

Technical Docs: https://docs.sturdystatistics.com

I totally agree that the metric is imperfect for a long term analysis. I was initially leaning toward a quantile based approach to really focus in on topic trends over time, but when I was initially exploring the data, the relative challenge of having a Show HN become popular in 2025 compared to previous years caught my curiosity, and for this decade I felt a static cutoff provided a simple and easy to understand threshold.

I do think as a metric for total reach, a static cutoff actually works reasonably well. I think some form of square root normalization over total users is probably the best balance.

Thank you! I currently don’t have much insight to this current trend. At the time of this analysis I hadn’t even heard of Clawd but that would definitely be worth my revisiting.

I was planning on doing this yearly but the Clawd excitement is definitely worth diving into.

Code gets simpler because it has to, and architecture becomes explicit.

The real goal isn’t to write C once for a one-off project. It’s to write it for decades. To build up a personal ecosystem of practices, libraries, conventions, and tooling that compound over time. Each project gets easier not because I've memorized more tricks, but because you’ve invested in myself and my tools.

I deeply appreciate this in the C code bases I work in (scientific computing, small team)

I just sent an email. Thank you for the push!

I did not conduct a deep dive into the specific examples: this was my takeaway from a slope plot comparing which topics clear a 10 point threshold (eg escape the new page) vs which topics clear a 100 point threshold.

Nearly every AI related topic does worse once it clears the 10 point threshold than any other category. This means that either the people looking through the New and Show sections are disproportionately interested in AI. This is very possible, but from my interaction with this crowd from my posts, these users tend to be more technically minded (think DIY hardware, rather than landing-page builders).

Last visual in the following section: https://blog.sturdystatistics.com/posts/show_hn/#digging-int...

It's good to know that this would be helpful. My tendency would be to dig in a bit more into the individual examples that fall into this more suspicious bucket before presenting this evidence formally, but curious if you think these high level results are sufficiently helpful?

I actually conducted a similar analysis back in December. I was more focused on discovering the topics that most resonated with the community but ended up digging into this phenomenon as well (specifically focusing on the probability of getting over 100 upvotes)

The really interesting thing is that the number of posts were growing exponentially by year, but it was only in 2025 that the probability of landing on the front page dropped meaningfully. I attributed this to macroeconomic climate, and found some (shaky) evidence of voting rings based on the topics that had a unusually high likelihood of gaining 10 points and an unusually low likelihood of reaching 100 points given that they reached 10.

Analysis here if anyone is interested: https://blog.sturdystatistics.com/posts/show_hn/

When I was in high school, I got hit head on by a car while walking. It wasn’t going fast but I got thrown 1-2 feet in the air and landed hard on my backpack.

Both my Thinkpad and I (thanks to my Thinkpad) were totally fine, and I continued to use it for 4 more years.

I don’t love these “X is Bayesian” analogies because they tend to ignore the most critical part of Bayesian modeling: sampling with detailed with detailed balance.

This article goes into the implicit prior/posterior updating during LLM inference; you can even go a step further and directly implement hierarchical relationships between layers with H-Nets. However, even under an explicit Bayesian framework, there’s a stark difference in robustness between these H-Nets and the equivalent Bayesian model with the only variable being the parameter estimation process. [1]

[1] https://blog.sturdystatistics.com/posts/hnet_part_II/

I do the exact same thing and this was my first thought. To be fair, I would probably not be able to format tables in a single cope/paste

An aside that I do want to mention here because it is a really unique way for many people to interface with LLMs: many commenters mention the model over indexing on a few comments they made that do not necessarily reflect of the broader themes of their writing. This is not any issue in the author’s engineering but an inherent issue in LLMs. The reason it is so noticeable in this case is because the subject matter is extremely familiar to the user: themselves.

LLMs consistently misrepresent information in this exact same way in, more critical applications. Because they are often employed on datasets that engineers and potentially end users are not deeply familiar with, the results often seem exceptional.

Disclaimer via my HN wrapped: “The Anti LLM Manifesto You will write a 5,000-word blog post on why a single Bayesian prior is more 'sentient' than GPT-6, and it will be ignored because the summary was generated by a 3B parameter model.”

How does our imagination shrink when we consider our options of what we create with code to be choosing between the outputs of the LLM rather than starting from the blank slate of our imagination?

This has been my biggest hesitancy with adopting these technologies. All of the things of which I’m most proud of building were built from a foundation of deep understanding of several domains, not from the solutions of a series of one offs problems, but from the process of solving them.

This resonated a lot with me. Thank you for your articulate writing.

This approach has really helped me out in my work. I do something very similar using DuckDB to slurp output files anytime I write a custom hierarchical model. The single sql queryable file simplified my storage and analytics pipeline. I imagine SQLite would be especially ideal where long term data preservation is critical.

We are in the separate ACL/encryption key bucket. We provide a Bayesian data analytics platform/api for other companies. Each company can have hundreds to thousands of datasets ("indices") each of which has a separate encryption key, and those keys are also stored encrypted with an organizational level key that is rotated daily.

I'm more amazed that they released this as part of their open-source offering (not clear from my above comment). Encryption is a standard lever for open-source projects to monetize.

I run a small company and needed to budget solid amount of chunk of time for next year to dig into improving this component of our system. I respect your perspective around holding high standards, but I do think it's worth getting excited about and celebrating reliable performant software that demonstrates consistent competence.

I’m just continually amazed by the DuckDB team. We had built out a naive solution with OpenSSL to encrypt duckdb files, but that lead to a 2x runtime cost for first time queries and used up a lot of ram because we were encrypting/decrypting the entire file all at once. It seems like because DuckDB is encrypting at the page level and leveraging modern processors native AES operations, they are able to perform read/writes at practically no cost.

https://archive.ph/7Y5wV

I agree with this. I have no problem with a technical discussion comparing the features and discussing Jupyter’s shortcomings. But the Jupyter job postings and contribution graph screenshots felt both ill-spirited and not particularly relevant.

There was interesting stuff here: the human readable format, auto publication. But the tone and framing bashing a reliable open source project really turned me off.

Awesome thank you for the info!

Haven’t dug the repo too much yet but looks like a super cool project. I’ have a few questions:

1. To what does 71% accuracy refers? I assume picking which team will win in any given matchup?

2. How does 70% compare to say, picking the team with the better record to win, or some simple time weighted rolling average of SRS record (metric that factors in opponent difficulty)? Because a solid percentage of games are between teams of extremely different talent levels, especially as tanking becomes more prominent later in the season.

I think there is so much value and room to grow by leveraging a statistical foundation. We’re still iterating really quickly on the low level C code on a variety of applications (pharma, scRNA, text) so it might be a while before we release it standalone.

We do offer an api layer (the website is a light layer above this) over the low level statistics code focused on making it super easy to apply to language data if you are interested in playing around with it: https://docs.sturdystatistics.com