adit_a

We're releasing an open dataset for challenging structured extraction tasks as a starting point for people to do any comparisons soon!

vikp and the Datalab team have done great work in the space, but their structured extraction product is closer to our baseline /extract api since both of those are single pass extractions.

Deep Extract is more accurate than any structured extraction product we've tried, but the approach comes with a very clear cost/latency tradeoff over a single pass extraction. We have free credits if you'd like to do a side by side

This might be our coolest case study yet. Thanks for the mention!

Hahaha, a while ago (even before choosing this idea space) we said we would build "magical tools for developers" and Reducto was the name we landed on out of a long list of magic adjacent things

Yes in the sense that we have features that will create persisted share links, and by default you can revisit results in your free account until you decide to delete them.

If helpful, we also offer free trial accounts with zero data retention if that's important for your use case

Code!

Appreciate the thoughtful note and want to wish you guys the best as well!

Thanks! We have a lot of respect for the work VikP and his team did on Surya but we haven't benchmarked his newer pipeline so I don't want to make a 1:1 claim.

If you want to do a side by side with your use case we'd be happy to set you up with free trial access.

Yeah, we're extremely excited about the potential of building a flywheel for each individual customer's pipeline.

We have a default DPA we're willing to sign on all tiers -- the note in the pricing page is meant to refer to custom/redlined DPAs that become complex to manage over time

We'll edit that to make it more clear

Ah yeah I remember! Great to hear from you and thanks :)

Would love to help if you end up having any use cases in the future!

Hey, we've never used or even attempted to use your platform. Respectfully I think you know that, and that you also know that your team has tried to get access to ours using personal gmail accounts dating back to 2024.

A schema builder with nested array fields has been part of our playground (and nearly every structured extraction solution) for a very long time and is just not something that we even view as a defining part of the platform.

Thank you!

To clarify, our API was already fully launched and in prod with customers when we raised our series A. This launch is specifically for the platform we're building around the API :)

Thank you! What's the error you're seeing on mobile?

Thanks! To clarify, we launched our document processing APIs a while ago. This launch is specifically for a new platform we're building around our API based on all of the things our customers previously had to build internally to support their use of Reducto (eval tools, monitoring etc).

Generally speaking, my view on the space is that this was crowded well before LLMs. We've met a lot of the folks that worked on things like drivers for printers to print PDFs in the 1990s, IDP players from the last few decades, and more recent cloud offerings.

The context today is clearly very different than it was in the IDP era though (human process with semi-structured content -> LLMs are going to reason over most human data), and so is the solution space (VLMs are an incredible new tool to help address the problem).

Given that I don't think it's surprising that companies inside and outside of YC have pivoted into offering document processing APIs over the past year. Generally speaking we don't see differentiation in the sense of just feature set since that'll converge over time, and instead primarily focus on accuracy, reliability, and scalability, all 3 of which have a very substantive impact from last mile improvements. I think the best testament I have to that is that the customers we've onboarded are very technical, and as a result are very thorough when choosing the right solution for them. That includes a company wide roll out at one of the 4 biggest tech companies, one of the 3 biggest trading firms, and a big set of AI product teams like Harvey, Rogo, ScaleAI etc.

At the end of the day I don't see VLM improvements as antagonistic to what we're doing. We already use them a lot for things like an agentic OCR (correcting mistakes from our traditional CV pipeline). On some level our customers aren't just choosing us for PDF->markdown, they're onboarding with us because they want to spend more of their time on the things that are downstream from having accurate data, and I expect that there'll be room for us to make that even more true as models improve.

Let us know if you have any feedback!

The direct loom link isn't working for you? Are you seeing the same redirects error?

Thank you! We worked with Airfoil for the website :)

Fixed! Sorry about that

happy to add examples to future iterations of this dataset if you want to send examples!

Part of the goal with releasing the dataset is to highlight how hard PDF parsing can be. Reducto models are SOTA, but they aren't perfect.

We constantly see alternatives show one ideal table to claim they're accurate. Being able to parse some tables is not hard.

What happens when it has merged cells, dense text, rotations, or no gridlines? Will your table outputs be the same when a user uploads a document twice?

Our team is relentlessly focused on solving for the true range of scenarios so our customers don't have to. Excited to share more about our next gen models soon.

This is interesting. I’m far from being an infra engineer so if this actually makes managing kubernetes easier I would pay for a hosted option