I’m surprised at the current sentiment in the comments. Pangram is amazing and has really interesting engineering too. I would have guessed that reliably identifying LLM generated text was not possible without watermarks.
> I would have guessed that reliably identifying LLM generated text was not possible
It depends what you mean by "reliably." If you mean, "we should be comfortable relying on this kind of tool at scale to identify and punish students, professionals, and writers who may have used AI," absolutely not.
If you take "reliably" to mean "1 in 200 false positive rate" as they disclose on their front page, absolutely that is possible (they are doing it today!). If you think there are more than 200 assignments turned in over a given year at university, you probably do not consider a tool like this fit for purpose. It's an open question whether those procuring said tool are aware of this
Unfortunately their marketing is really insisting on the former, and trying to push it into the zeitgeist that detection of AI-generated or edited text is reliable-type-1 now and long-term. They fail to make it clear that this is merely a tool that strongly suggests text follows patterns known to us at the present time of known LLMs. However, that fingerprint will drift over time, as LLMs get better, human writing style evolves, and the line between human and "smart autocorrect" becomes even blurrier (does speech-to-text push the model into "AI assisted" mode, because it tidied up your punctuation, for example?)
> If you take "reliably" to mean "1 in 200 false positive rate" as they disclose on their front page
Pangram claims a 1 in 10,000 false positive rate (rate at which human-authored texts are incorrectly classified as AI-generated). 1 in 200 sounds like the false negative rate (rate at which AI-generated texts are classified as human-authored), or perhaps a rate for a specific category of text.
Good point of precision, I read their site too quickly. I don't think my argument materially changes with that number instead however. There were over 40,000 students enrolled in my university alone. Generously assuming they only turn in one assignment per year, having 4 of them go through the "computer says you cheated, and as you can see, it's 99.9% accurate" gauntlet is not a price we should be willing to pay for... the marginal benefit of this tool over more classical ways to proctor and assess pupils
they also publish great tech reports. their founder is so confident in their model that he's regularly on social media offering bounties for false positives
I’m very excited to see the great work ERSC has/will do. When thinking about where Git lags today, I’ve come up with three categories: UX features and custom data not natively understood by the Git CLI, a stock git-http-backend that doesn’t scale well to moderate monorepo size in server compute / storage, and a wire protocol that isn’t as flexible as it could be for special requests.
But there are so many hooks into the Git workflow today, and I’m struggling to find a “user story” that would not be met by custom Git tooling. UX could be added to Git objects à la Gerrit with custom CLIs, custom Gitoxide ODB and (eventually) ref storage backends can help the server scale, and things like promisor remotes and partial clones can keep things smaller on the client side.
I’m curious what ERSC is able to share publicly about where the scaling fails with the Git specification? Is it the wire format, or the relative speed of upstreaming new things to Git? Or is the side-channel approach for storing rich data in Git objects insufficient in some way?
P.S. I wrote a blog post[1] about this a bit ago. I’m sure I’m missing something. Since I wrote it, I’ve wondered if the lack of deferred conflicts in-tree would be a scaling limiter.
Yes, it's important to realize that git is multiple things: the on-disk repo format, the CLI, and the wire protocol. Each has their own challenges, just like any project, but they can be tackled independently. But at the end of the day, there just are fundamental limits to the way that git does things that make total sense in the context Linus developed git for, but just do not in other ones. Some of those are performance related, but some of those are things like how the kernel is an open source project, and so per-directory ACLs are something that git wouldn't ever bother supporting, but are valuable for companies. We'll be talking about these things in the future, so I'm just going to be hand-wavy about it right now. But we do think that git is a really great system that has served us all well for 20 years, but just like how git displaced systems before it due to significantly re-thinking the details, for some users, making meaningful improvements over git will also require a similar significant re-think. That's just the way of technological development.
I haven’t dug into why, but for unknown-linux builds on x86, Rust binaries have been substantially smaller on musl than standard dynamic linking to glibc, for me. No idea if I’m doing something wrong or if the handful of cases I tried were all special in some way.
Do we know that Claude’s quirks are related to watermarking? The article said Gemini’s web console is apparently watermarked, and it has different quirks / a different sound.
I feel like Zed, rustup, and a lot of other applications (with CLIs) moved in that direction. (Hope someone corrects me if that’s wrong, unsure those projects are fully static, but they do self update.)
As a user that surprised me at first, but I’ve grown to really like it!
reply