I worked in the tracing and tracking all the thousands of data sets that got tweaked and permuted and changed hands between thousands of researchers and data engineers at a major lab. The data that goes into training runs is permuted so much from the OG data that tracing the lineage is not trivial (dramatic understatement).
And the difficulty is harder than just the extreme scale of text searching. but also explodes with organizational difficulty since there are so many people tweaking/shifting data independently upstream of the actual training run, and no they will not all add the telemetry you wish they did.
In the ideal, should it be this hard? Well, no, but that's org wrangling for you.
It feels convenient to not spend time on engineering around tooling that could be used to answer a question like “did you violate copyright by training on X?”
Don't attribute to malice what is better explained by coordination headwinds in extremely large companies.
The engineering around tooling wasn't remotely the issue. It's getting all the (thousands?) data researchers mostly iterating on fine tuning datasets that would get bristly if they couldn't work outside version control in a python notebook iteratively tweaking their dataset that processed and reprocessed a few datasets until a threshold was reached.
The only _guaranteed_ chains of custody are down at the compute job and file read level. Which in a massively distributed computing job is... [redacted] nodes reading [redacted] fanouts of "datasets" that is just an abstraction over [redacted] individual files.
There's no malice here. Just way way way more complex than you'd first think.
The malice would be in not prioritizing the provenance tool at the start as a requirement of the rest of the product. Ethics would tell you that if you can't make the product in an ethical way, then you probably shouldn't make it.
It definitely is solvable though. Data versioning is a thing and it can work quite transparently to the mutations done on the data.
To not know who made and who approved a set of mutations on data can easily become equally as mind-blowingly stupid as not knowing who made mutations to code. Code is a subset of data after all and search over (provenance of) data can be implemented as DAG traversal.
Not tracking data changesets like code changesets is certainly a choice, not really a constraint anymore. A similar choice I feel is implied by "extreme scale of text searching".
> no they will not all add the telemetry you wish they did
...is just a failure of the corporate policy surrounding data handling. Is git-for-data already considered telemetry?
Of course the truth is provenance of data is something best institutionally forgotten as quickly as possible. The only thing that matters is it's there, that the data has no history, and that's why it can be used in whatever way deemed necessary.
All of your points are valid, and believe me I was trying to make them. The problem is one of culture. Most of the people doing this kind of work didn't like version control, and their work was really just running notebooks (like iPython or Google Colab) until a number was good enough and they'd submit the file for inclusion into training runs.
You can call it a policy failure, but these people were in very high talent demand and so top down dictates would risk "X people leaving lab Y for lab Z" headlines and morale hits.
I am not saying this is good. I am telling you that on the ground it is so much messier than it should be.
The appearance of heroic efforts to get authoritative lists of what datasets went into which major model versions prevented actual data laundering (up to intent and mistakes). But don't attribute malice to that which is far far easier to explain with coordination headwinds: https://komoroske.com/slime-mold/
Malice is not required, which is precisely why I added, "in effect". If the effect is the same as data laundering, that is reason enough to encourage the practice, regardless of the original motives (and I'm sure there are plenty of legitimate ones).
One model I've seen is moving the review stage to the designs, not the code itself.
I.e. have a `planning/designs/unbuilt/...` folder that contains markdown descriptions of features/changes that would have gotten a PR. Now do the review at the design level.
in 2020 we lived through the extreme left's remedial lesson in public safety. Now we're living through the MAGA right's remedial lesson in trade policy.
(Most MAGA right know this, don't care, see tariffs as a hammer. But they are hitting all of us)
I see the value here. The problem isn't just the search; it's the trust. The biggest hurdle for Zenode won't be the tech, but convincing an engineer that your AI's summary of a footnote is accurate enough to risk a $10,000 board spin. That's a high bar.
I'd argue the core value isn't just a better search or a faster reader. It's about providing a verified, reliable source of truth. This brings up a key tension: you say the AI isn't yet at your co-founder's level of accuracy, but is that precisely the level of confidence required to replace an engineer's manual check? How do you close that gap? You've got the data, but the trust factor is a different threshold?
I.e. maybe you've built the tool to make the problem faster, but the real win would be a tool that makes the problem safer? The killer feature might not be more speed, but rather a confidence score on every AI-generated fact, with a clear path to the source document so an engineer can verify it. It’s not about avoiding the document entirely; it’s about having a better starting point and knowing exactly what to double-check.
Agreed - trust is the key! That's why we've built in sources with links to the exact location in the datasheet and part documents where the AI found an answer. We're working hard to make sure you can trust its answers, but we know most engineers 'trust but verify'. A (transparent) confidence score is a great idea to improve trust in the answer and sources.
To close the gap, we've built our own Q/A datasets and are training custom AIs how to search and read a datasheet (like a new engineer needs to learn early on). We're concentrating on teaching the AI how to identify key information vs noise as it relates to electrical engineering (differences like 'Voltage' in the Absolute Max vs Recommended section) and where information is likely to be found in a datasheet or app note.
Searched for "innovator's dilemma" in the article, didn't find it.
The crux is not whether the extremely rich incumbent (google) will have better infrastructure, but whether that is the field of competition that matters.
They do. But there’s a line between arbitrary and fair. One of the things players want most is for outcomes to not be random/arbitrary and for skill to be judged fairly. That good shots are rewarded and bad shots penalized. The game already has a lot of that baked in so no need to make it more so.
TPC Sawgrass is the closest to a perfect pro course (PGA National second I guess) since it was designed specifically for it. I think a course perfectly optimized for pro play would be very different from what most people would expect.
And the difficulty is harder than just the extreme scale of text searching. but also explodes with organizational difficulty since there are so many people tweaking/shifting data independently upstream of the actual training run, and no they will not all add the telemetry you wish they did.
In the ideal, should it be this hard? Well, no, but that's org wrangling for you.
reply