Shreya
Shankar

Shreya Shankar is not building the next chatbot. She is building the infrastructure that lets everyone else's AI systems stop lying to them. Her work sits at the uncomfortable intersection of data systems research and human-computer interaction - a combination unusual enough that she publishes top-tier papers in both VLDB and CHI in the same calendar year.

The core insight behind everything she does: production machine learning breaks in ways that are invisible, expensive, and preventable. Bad data does not announce itself. LLM outputs cannot be trusted at face value. Pipelines that worked last Tuesday silently drift by Thursday. Most engineering teams discover these failures when customers complain. Shreya's work makes the breakage visible before that happens.

Her flagship open-source project, DocETL, processes unstructured text at scale using LLMs and has been deployed in 4,100+ pipelines across more than 30 S&P 500 companies. It has also been adopted by public defenders in two California counties - which means research born in a Berkeley PhD program is now helping people keep their freedom. That is a fairly short trip from dissertation to courtroom.

Before any of this, she spent time as an ML engineer at Google Brain and Meta. Those jobs gave her a detailed education in what actually goes wrong in production - and a specific kind of frustration. The data quality problems she kept running into had no good tools. The evaluation workflows were ad hoc. The observability was thin. She went back to school not to escape industry problems but to attack them with more serious weapons.

At UC Berkeley's EPIC Lab, advised by Aditya Parameswaran, she has built a research program that is genuinely hard to classify. It is not pure database theory. It is not traditional ML. It sits in the space where data systems meet the humans who build and use them - a space that turns out to be very large and very full of unsolved problems.

Her paper "Operationalizing Machine Learning: An Interview Study" documented eighteen ML engineers talking honestly about what makes production ML succeed or fail. The answer, after all those interviews, was unglamorous: velocity, validation, and versioning. The fundamentals. The same things software engineers figured out decades ago, still being reinvented by ML teams who thought their field was different.

She did the standard top-tier CS path: Stanford for undergrad and master's, concentrating in systems and artificial intelligence. While there, she helped run SHE++, Stanford's nonprofit for underrepresented minorities in tech - a sign of something that shows up consistently in her work, a concern for who gets access and who gets left out.

After Stanford, she went to industry. Google Brain. Meta. The jobs that CS graduates want. She was good at them. She was also watching, up close, how production ML actually fails. The data pipelines that quietly corrupt. The models that degrade on schedules nobody tracks. The evaluation workflows that amount to vibes and hope.

This is where a lot of people write blog posts about problems and move on. Shreya went back to school. She started her PhD at UC Berkeley in 2020 and began treating those industry frustrations as research questions.

The NDSEG Fellowship followed in 2022. So did papers. A lot of papers, published at venues that do not usually appear together on a CV. The combination - deep systems work plus HCI methods, interviews and observational studies alongside formal database research - is unusual. It is also, in retrospect, exactly right for the problem space. You cannot fix production ML without understanding both the technical systems and the humans operating them.

DocETL is the culmination of this approach so far. It is not just a processing system. It is a rethinking of how humans and LLMs collaborate to extract meaning from large unstructured document collections. The companion IDE, DocWrangler, puts that capability directly in researchers' and analysts' hands. The public defenders who picked it up were not thinking about system architecture. They needed something that worked.