It's going to be stochastic in some sense whether you want it to be or not, human error never reaches zero percent. I would bet you a penny you'd get better results doing one two-second automated pass + your usual PII redaction than your PII redaction alone.
The advantage of computers was that they didn't make human errors; they did things repeatedly, quickly, and predictably. If I'm going to accept human error, I'd like it to come from a human.
OTOH, if you're willing to accept human-level error rates... why would you not do so at a burst-scalable task per minute and 1/1000th the cost?
I've built large human data entry operations. Variable throughput, monotony, hiring and perf management and firing, management, quality management. All of these things are large investments of human effort and money.
If I can achieve the same quality level (or in some use cases, even slightly degraded output) with software scaling characteristics and costs... I see zero reasons outside regulatory compliance reasons to have people do it.
I think the problem is most secrets arn't stochastic; they're determinant. When the user types in the wrong password, it should be blocked. Using a probabilistic model suggests an attacker only now needs to be really close, but not correct.
Sure, there's some math that says being really close and exact arn't a big deal; but then you're also saying your secrets don't need to be exact when decoding them and they absolutely do atm.
Sure looks like a weird privacy veil that sorta might work for some things, like frosted glass, but think of a toilet stall with all frosted glass, are you still comfortable going to the bathroom in there?
I dunno what use case you're thinking this is for.
The use case for this is that many enterprise customers want SaaS products to strip PII from ingested content, and there's no non-model way to do it.
Think, ingesting call transcripts where those calls may include credit card numbers or private data. The call transcripts are very useful for various things, but for obvious reasons we don't want to ingest the PII.
> Think, ingesting call transcripts where those calls may include credit card numbers or private data. The call transcripts are very useful for various things, but for obvious reasons we don't want to ingest the PII.
Credit card numbers are deterministic. A five year old could write a script to strip out credit card numbers.
As for other PII ? You're seriously expecting an LLM to find every instance of every random piece of PII ? Worldwide ? In multiple languages ? I've got an igloo I'd like to sell you ...
I think this is a bit dramatic of a comment. Credit card numbers relayed over the phone are not deterministic...
"four three uh let's see sorry my vision is bad six eight..."
Easy versions of problems are easy. But reality is messy.
And no, neither I nor anybody else is expecting a 50B parameter model to find every instance. But finding 90% or 95% or 99% is pretty good, and sufficiently good for many use cases.
> Credit card numbers relayed over the phone are not deterministic...
I don't know the last time you relayed card details over the phone, but the last 100 times I did it, the agent did one of two things:
(a) Said "Please wait while I turn off recording"; or
(b) Transferred the call to an automated system that read the card details via the phone keypad input and then took back control of the call afterwards.
Relaying card details over the phone is a problem that has been comprehensively solved. You don't need an LLM for it !
> But finding 90% or 95% or 99% is pretty good
I would humbly suggest that you are over-estimating the capabilities of an LLM. ;)
