WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=HGfsfKaVuGY

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/HGfsfKaVuGY.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:12.880 --> 00:00:14.719
Hi everyone, my name is Ple.

s2
00:00:14.719 --> 00:00:17.520
I lead developer redu relations at Reductto.

s3
00:00:17.520 --> 00:00:22.720
Um, and before we dive into Jmail, I'd love to give you a little background on what we do.

s4
00:00:22.720 --> 00:00:32.000
Uh we're an agent document platform which basically means we help teams turn messy unstructured documents into data that AI can actually use accurately.

s5
00:00:32.000 --> 00:00:47.039
Um to give you some context in the last three years we've raised 108 million from investors like ACCNC benchmark and more and processed over two billion documents across customers like Harvey Scale and a top five global hedge fund.

s6
00:00:47.039 --> 00:00:53.600
Um, and operating at that scale means that we've basically dealt with every document you can possibly think of.

s7
00:00:53.600 --> 00:00:58.079
Um, and we've iterated reductive product to handle anything.

s8
00:00:58.079 --> 00:01:09.760
Um, now getting to AI to work on a clean PDF with a frontier model is not that hard, but the truth is that most of enterprise documents are unstructured.

s9
00:01:09.760 --> 00:01:13.600
That means like scan documents, rotated documents, charts.

s10
00:01:13.600 --> 00:01:16.159
Um, and that's when things get really complex.

s11
00:01:16.159 --> 00:01:19.200
Reductto is the layer that sits right before your model.

s12
00:01:19.200 --> 00:01:27.840
Um we handle complex layouts but also um as well as post-processing so you can focus on building your actual product.

s13
00:01:27.840 --> 00:01:37.680
Um the reason this works is that we take a rasterizationbased approach that means we look at your document like a human would look at the document instead of the underlying embedding.

s14
00:01:37.680 --> 00:01:50.479
Um everything is powered by our agentic OCR framework where rather than making a single pass and committing to an answer the model flags things that it's uncertain about corrects them and then moves on to the next step.

s15
00:01:50.479 --> 00:01:52.720
Uh we'll give you access to our studio.

s16
00:01:52.720 --> 00:01:55.680
Um we've made it self-s served just for this session.

s17
00:01:55.680 --> 00:01:58.799
Uh but in total we have five core capabilities.

s18
00:01:58.799 --> 00:02:02.640
Parse, split, extract, edit, and classify.

s19
00:02:02.640 --> 00:02:04.719
Um now a quick show of hands.

s20
00:02:04.719 --> 00:02:09.599
Who here has heard of Jmail or looked through Jmail before?

s21
00:02:09.599 --> 00:02:09.840
Okay.

s22
00:02:09.840 --> 00:02:12.319
Wow, that's a that's a good chunk of people.

s23
00:02:12.319 --> 00:02:15.280
Um, but I'll I'll give a quick rundown in case you haven't.

s24
00:02:15.280 --> 00:02:21.040
So, Jmail was originally built by Riley Walls and Luke in five hours last November.

s25
00:02:21.040 --> 00:02:22.959
That's when the Epstein files were released.

s26
00:02:22.959 --> 00:02:30.959
Uh, the concept is basically Gmail forked and you can log into the inbox like your Epstein and then that grew into a full suite.

s27
00:02:30.959 --> 00:02:35.760
So you can think of like J drive, JFlight, J, Amazon, J photos and so much more.

s28
00:02:35.760 --> 00:02:43.120
Um by February there were over 450 million visits and 18 million users that had access Jmail.

s29
00:02:43.120 --> 00:02:47.440
And we're really proud to share that Reduct was behind parsing all of the documents.

s30
00:02:47.440 --> 00:02:48.720
And that's not a small number.

s31
00:02:48.720 --> 00:02:55.200
It's over three million pages of redacted PDFs, scanned documents, and messy government files as well.

s32
00:02:55.200 --> 00:03:04.319
And to give you an idea, like this ranged from anything like really complex forms and tables to like messy handwriting of like so many different people.

s33
00:03:04.319 --> 00:03:11.040
Um, now I'm going to hand it over to Omar, who's one of our founding engineers and worked very closely with the Jail team back in November.

s34
00:03:11.040 --> 00:03:14.959
Um, and he'll give you a technical rundown and more.

s35
00:03:14.959 --> 00:03:18.000
Alrighty, who's ready to talk about some documents.

s36
00:03:18.000 --> 00:03:20.000
Yippee.

s37
00:03:20.000 --> 00:03:20.480
All right.

s38
00:03:20.480 --> 00:03:23.200
So, um, yeah.

s39
00:03:23.200 --> 00:03:27.120
So, uh, walking us back to, you know, a very fateful night in November, right?

s40
00:03:27.120 --> 00:03:35.840
Um, I was talking with the founding team and we were trying to figure out, you know, what would be a great way to use Reduct with this kind of

s41
00:03:35.840 --> 00:03:43.200
transformational cultural event that was, you know, going to be unveiled to the public, right?

s42
00:03:43.200 --> 00:03:54.879
Um it just so happened that um you know we're very close to Luke uh who is a founder at Kino and is working downstairs and we were all just kind of talking about you know what would be cool to build what would be funny.

s43
00:03:54.879 --> 00:03:56.080
Haha.

s44
00:03:56.080 --> 00:04:06.640
Um and then uh it kind of snowballed into this idea of like what if you could um you know sign into your email as if you were Jeffrey Epstein

s45
00:04:06.640 --> 00:04:10.720
and view um you know your email as if you were him.

s46
00:04:10.720 --> 00:04:22.560
And so um you know it was a really really cool concept as a product but there was one really hard problem to solve that you know was basically a barrier between us and the productized

s47
00:04:22.560 --> 00:04:23.759
solution.

s48
00:04:23.759 --> 00:04:26.000
um and you're looking at part of it, right?

s49
00:04:26.000 --> 00:04:41.600
So, it's really really like I I would urge you if you haven't done this before to send this like uh you know uh cover sheet to Chad GPT and try to get some results out of it that and and just see how accurate it is, right?

s50
00:04:41.600 --> 00:04:47.440
It's a very very complex problem where you know layouts are um pretty hard to understand.

s51
00:04:47.440 --> 00:04:51.759
The reading order of this is also somewhat subjective, right?

s52
00:04:51.759 --> 00:05:02.000
Um, and so we needed something to basically solve this bottleneck so that we could work on all of these cool uh little, you know, products downstream.

s53
00:05:02.000 --> 00:05:04.400
And so this is where Redto came in.

s54
00:05:04.400 --> 00:05:10.800
So I'm actually going to show you guys um what we had used for a couple of our products, right?

s55
00:05:10.800 --> 00:05:15.759
So Oh yes, let me do this real quick.

s56
00:05:22.160 --> 00:05:24.000
Alrighty.

s57
00:05:24.000 --> 00:05:25.440
Whoops.

s58
00:05:25.440 --> 00:05:27.919
Gonna bring this over.

s59
00:05:27.919 --> 00:05:28.479
All righty.

s60
00:05:28.479 --> 00:05:31.039
So, here you see a cool product, right?

s61
00:05:31.039 --> 00:05:32.240
JF flights.

s62
00:05:32.240 --> 00:05:37.039
Basically, all of Jeffrey Abstein and his affiliates flight history, right?

s63
00:05:37.039 --> 00:05:38.560
This guy was flying people out.

s64
00:05:38.560 --> 00:05:39.919
He was flying diplomats out.

s65
00:05:39.919 --> 00:05:44.320
He himself was flying many places to and from his island, right?

s66
00:05:44.320 --> 00:05:53.840
Um what was basically the barrier between us and finding out finding all these flights were these pretty shoddy handwritten documents, right?

s67
00:05:53.840 --> 00:05:59.360
Um again, if you were, you know, if you thought that cover sheet was a little bit rough, think about handwriting, right?

s68
00:05:59.360 --> 00:06:14.160
So we can see here a pipeline that I had actually set up way back when uh when we were trying to build a good config to basically make our parsing really really good, right?

s69
00:06:14.160 --> 00:06:26.720
And so in this case uh we had for the for the flights use case, you know, an idea had flown out that like what if we um you know spin this off as a completely separate product where you could just see all of his flights.

s70
00:06:26.720 --> 00:06:34.960
Um and so what that meant is taking all of his flight documentation and then applying a separate you know extraction config for it.

s71
00:06:34.960 --> 00:06:40.080
And so what you'll see here is um kind of a little tour as to how Reduct works, right?

s72
00:06:40.080 --> 00:06:45.280
So Reduct uh within the document extraction use case first parses the document, right?

s73
00:06:45.280 --> 00:06:51.440
And so this kind of shows you, you know, you could stick any document that you would like here and you could just click run, right?

s74
00:06:51.440 --> 00:06:56.160
Configure any of our bells and whistles and see real-time results, right?

s75
00:06:56.160 --> 00:07:06.479
So this was sort of the canvas for myself that I was playing around with to kind of understand before I start, you know, scaling this up to a million different documents and run up a quick check on Reduct's,

s76
00:07:06.479 --> 00:07:17.039
you know, on Reduct's uh um you know, uh receipts, let me make sure that our um extraction accuracy is what I would expect it to be.

s77
00:07:17.039 --> 00:07:20.639
And so here is kind of what we ended up with.

s78
00:07:20.639 --> 00:07:26.160
Um you could see here for a couple of these different documents, you know, some redactions that we had to deal with.

s79
00:07:26.160 --> 00:07:28.800
Um Woody Allen, I know that guy.

s80
00:07:28.800 --> 00:07:39.680
Um but yeah, just like a lot of different um you know, use cases that we had to handle through one extraction schema um for the flights use case, right?

s81
00:07:39.680 --> 00:07:43.520
And so we parsed all the documents uh very quickly.

s82
00:07:43.520 --> 00:07:48.639
And actually a fun story about this um is Alvin in the room?

s83
00:07:48.639 --> 00:07:49.759
Alvin is in the room.

s84
00:07:49.759 --> 00:08:02.080
So, um, back when the, uh, the, uh, first, uh, drop came out, I was paging Alvin maybe like, you know, a couple times a night, uh, he was, he just happened to be on call,

s85
00:08:02.080 --> 00:08:04.240
uh, the night that I was parsing all these documents.

s86
00:08:04.240 --> 00:08:06.720
And we were trying to parse them very, very quickly.

s87
00:08:06.720 --> 00:08:11.280
And so, we put a, you know, a decent amount of stress on our infra.

s88
00:08:11.280 --> 00:08:16.080
And so, Alvin was sending me a lot of fun messages late at night like, "Hey, bro, can you slow down?"

s89
00:08:16.080 --> 00:08:17.840
Um, but yeah, we got through them.

s90
00:08:17.840 --> 00:08:18.960
We got through them in time.

s91
00:08:18.960 --> 00:08:31.440
And then um once we had this kind of corpus of documents that we were able to um you know um kind of take as a ground truth, we then spun off a a billion different products, right?

s92
00:08:31.440 --> 00:08:39.200
And so Paula kind of touched on this a little bit, but I'm going to go back to Gmail.

s93
00:08:40.000 --> 00:08:46.320
So, you know, we we spun up any anything from Jazm to Jlights to Gemini, right?

s94
00:08:46.320 --> 00:08:48.160
Um yeah.

s95
00:08:48.160 --> 00:08:49.839
So, and I and also JCAL.

s96
00:08:49.839 --> 00:08:54.240
This was actually a product that I um worked on myself.

s97
00:08:54.240 --> 00:08:56.480
So, some fun stuff there.

s98
00:08:56.480 --> 00:08:57.600
Um cool.

s99
00:08:57.600 --> 00:09:13.279
And so, I guess you know if you could kind of take uh anything out of this, I do want to say actually um yeah, so if you could take anything out of this, right, like the simplicity from this is really like

s100
00:09:13.279 --> 00:09:15.600
you know getting a schema, right?

s101
00:09:15.600 --> 00:09:21.279
looking at these results, making sure that the results look like what I would expect, and then just deploying.

s102
00:09:21.279 --> 00:09:21.680
Right?

s103
00:09:21.680 --> 00:09:27.236
So, if I was to deploy this code snippet, I'll just redeploy here for our use case,

s104
00:09:27.236 --> 00:09:28.000
[snorts]

s105
00:09:28.000 --> 00:09:35.360
and I can get either a direct API call or just a pipeline code snippet that I can invoke very quickly, right?

s106
00:09:35.360 --> 00:09:47.519
Um so the name of name of the game here is like stick your documents in this platform and then immediately start um you know visualizing your data and you could immediately also productionize it uh afterwards.

s107
00:09:47.519 --> 00:09:49.519
So I'm going to stop here real quick.

s108
00:09:49.519 --> 00:10:02.320
Um do we want does anybody have any questions thus far about um Jmail or Reduct in general before we can kind of start uh working on a little interactive exercise?

s109
00:10:02.320 --> 00:10:04.320
Yeah.

s110
00:10:05.200 --> 00:10:07.200
Yeah,

s111
00:10:11.040 --> 00:10:12.000
great question.

s112
00:10:12.000 --> 00:10:14.079
So, we can actually come up with this for you, right?

s113
00:10:14.079 --> 00:10:22.480
Um, you know, my uh my fun analogy here is that like your extract schema is sort of like the paintbrush on your reductto canvas, right?

s114
00:10:22.480 --> 00:10:28.160
So, it definitely drives everything that you um you know, you get out of the schema.

s115
00:10:28.160 --> 00:10:32.240
So, for example, right, I could create a new pipeline here, right?

s116
00:10:32.240 --> 00:10:44.959
and create a new extract pipeline and just call this I don't know let me make a resume schema because I want to parse some résumés right

s117
00:10:45.279 --> 00:11:04.800
oh whoops sorry about that actually I'm going to do this real quick so anyway I I'll do this again because it's very simple so I'll create a new extract pipeline here by the way we could do a lot of things with documents par split extract, edit, even classify.

s118
00:11:04.800 --> 00:11:12.320
Um, and so what I'm going to do here is create a resume schema.

s119
00:11:12.320 --> 00:11:14.320
Oops.

s120
00:11:15.440 --> 00:11:19.519
Uh, my Wi-Fi is not being helpful with me today.

s121
00:11:19.519 --> 00:11:21.440
There we go.

s122
00:11:21.440 --> 00:11:23.040
All righty.

s123
00:11:23.040 --> 00:11:24.480
So, I got a fun schema here.

s124
00:11:24.480 --> 00:11:29.600
And now it's up to me to basically decide whether or not this schema is like satisfactory or not.

s125
00:11:29.600 --> 00:11:30.079
Right.

s126
00:11:30.079 --> 00:11:40.000
it it's really given it's going to give me exactly what I'm asking for and you know once I plug a document in here I might realize like ah this is actually not what I want right so

s127
00:11:40.000 --> 00:11:58.240
I have a bunch of handy dandy resumes I'm going to stick them in here upload and then just run this so yeah um I hope that answered your question

s128
00:11:58.560 --> 00:12:02.079
any other questions while We wait for this.

s129
00:12:09.680 --> 00:12:12.240
How do you validate?

s130
00:12:15.279 --> 00:12:17.040
You're talking about the loading state.

s131
00:12:17.040 --> 00:12:19.600
Uh that's just like a fun loading state at the end of the day, right?

s132
00:12:19.600 --> 00:12:26.160
Like our product is like a really, you know, it's a suite of different models uh and different VLMs that we deploy, right?

s133
00:12:26.160 --> 00:12:27.360
Um I'm I'm

s134
00:12:27.360 --> 00:12:32.240
sorry, it's not the I was following what you were saying.

s135
00:12:34.720 --> 00:12:36.720
Yeah.

s136
00:12:38.320 --> 00:12:39.760
Oh, that's a great question.

s137
00:12:39.760 --> 00:12:43.839
So, if I'm understanding correctly right, what you're saying here?

s138
00:12:44.000 --> 00:12:44.160
Yeah.

s139
00:12:44.160 --> 00:12:44.480
Yeah.

s140
00:12:44.480 --> 00:12:57.600
So, this specific um this specific like schema generation that I had just used is really out of the box and it's just kind of like a a quick LLM call that describe like builds a JSON schema exactly for what I asked for.

s141
00:12:57.600 --> 00:13:01.200
However, we do have an enhanced schema generation, right?

s142
00:13:01.200 --> 00:13:11.279
And so what this will do is let's say I've parsed my documents, it will then take the output of like what's in the documents and tailor a schema description directly for them.

s143
00:13:11.279 --> 00:13:21.760
So like if you're looking for example for, you know, something just really quick to just get up on the screen and just see some results, I would recommend regular, you know, uh schema generation.

s144
00:13:21.760 --> 00:13:29.440
But if you are a lot more interested in like nuance, uh I definitely suggest parsing the documents first and then kind of passing them in.

s145
00:13:29.440 --> 00:13:31.920
All you would have to do is just click enhance schema generation.

s146
00:13:31.920 --> 00:13:41.279
And what we will be able to do is um you know run the documents first, try to get an understanding of what's in the in the documents so that we can tailor these schema descriptions

s147
00:13:41.279 --> 00:13:43.360
directly for that.

s148
00:13:43.360 --> 00:13:44.880
Make sense?

s149
00:13:44.880 --> 00:13:45.279
Cool.

s150
00:13:45.279 --> 00:13:45.519
Cool.

s151
00:13:45.519 --> 00:13:45.760
Cool.

s152
00:13:45.760 --> 00:13:47.760
Cool.

s153
00:13:48.560 --> 00:13:51.120
you had some reduction.

s154
00:13:51.120 --> 00:13:53.120
Yeah.

s155
00:13:54.479 --> 00:13:54.720
[clears throat]

s156
00:13:54.720 --> 00:13:55.680
Correct.

s157
00:13:55.680 --> 00:13:56.320
Yes.

s158
00:13:56.320 --> 00:13:59.120
So I mean yeah like at the end of the like this is a great question.

s159
00:13:59.120 --> 00:13:59.279
Right.

s160
00:13:59.279 --> 00:14:03.120
So reductto actually parses PDF metadata as well right.

s161
00:14:03.120 --> 00:14:10.720
So some like sometimes uh and this is honestly testament to like uh who was doing the redaction, right?

s162
00:14:10.720 --> 00:14:13.040
Sometimes the redaction was actually not that great, right?

s163
00:14:13.040 --> 00:14:21.040
And so what that ended up being or the responsibility ended up being on us as the JML team to then have to do a bunch of redaction, right?

s164
00:14:21.040 --> 00:14:26.240
Because you can't just stick a box on a PDF and then expect it to actually be fully redacted, right?

s165
00:14:26.240 --> 00:14:33.279
Um yeah, seems like there was some uh a lack of understanding when whoever who whoever was cooking up that redaction.

s166
00:14:37.600 --> 00:14:53.199
um I will say it's like for the files that came out and myself looking through them that's not the case right some files were actually redacted correctly um but there was some files where we were just able to see who was like you know who the redaction was behind and

s167
00:14:53.199 --> 00:15:04.160
um so it became a really really serious you know situation right because we're dealing with you know people's data that like um you our data is redacted for a reason, right?

s168
00:15:04.160 --> 00:15:10.959
And uh you want to really make sure that you're not the one that like ends up getting sued at the end of the day because of this.

s169
00:15:10.959 --> 00:15:20.399
Um and so yeah, there was a you know a a heavy kind of level of responsibility on our shoulders to make sure that whatever was intended to be redacted was actually redacted.

s170
00:15:20.399 --> 00:15:24.480
Our our our tool was working a little too well.

s171
00:15:24.959 --> 00:15:25.360
Cool.

s172
00:15:25.360 --> 00:15:25.600
Yeah.

s173
00:15:25.600 --> 00:15:28.639
at the front and then I'll after you

s174
00:15:28.639 --> 00:15:37.839
questions or thousands of different things.

s175
00:15:38.720 --> 00:15:38.959
Yeah.

s176
00:15:38.959 --> 00:15:39.120
Yeah.

s177
00:15:39.120 --> 00:15:39.360
Yeah.

s178
00:15:39.360 --> 00:15:40.639
Uh it's a great question.

s179
00:15:40.639 --> 00:15:45.279
Um I'll give you some like you know an example, right?

s180
00:15:45.279 --> 00:15:51.680
There was there was a schema that I was looking at maybe on Friday uh that had like 156 fields, right?

s181
00:15:51.680 --> 00:15:57.680
um and all of these different fields, you know, need like they were requesting something completely different, right?

s182
00:15:57.680 --> 00:16:02.639
Uh and so I urge you to kind of put our schema to the test.

s183
00:16:02.639 --> 00:16:10.240
I think like our um the like nesting uh limits to our schema or maybe like four or five layers.

s184
00:16:10.240 --> 00:16:17.920
Uh but in if you want to, you know, ask for everything in the world, you can still technically be able to fit it in in a schema.

s185
00:16:19.120 --> 00:16:23.120
Do you have any capabil resolution

s186
00:16:23.120 --> 00:16:24.240
entity resolution.

s187
00:16:24.240 --> 00:16:26.720
Can you give me an example?

s188
00:16:30.639 --> 00:16:32.800
So this is a good question.

s189
00:16:32.800 --> 00:16:36.720
Um there is a lot of post proc postprocessing that we end up doing, right?

s190
00:16:36.720 --> 00:16:38.720
Let's say like on the extraction side.

s191
00:16:38.720 --> 00:16:43.279
Um I'm personally a little bit farther abstracted away from like the ML side of things.

s192
00:16:43.279 --> 00:16:49.680
Uh but I can tell you that we are doing a decent amount of post-processing to basically link um you know entities together.

s193
00:16:49.680 --> 00:16:52.240
For example, we have like a citation model, right?

s194
00:16:52.240 --> 00:16:57.360
Where we know we have, you know, one model that could be responsible for extraction, right?

s195
00:16:57.360 --> 00:17:05.199
But then there might be another model that's also responsible for once this data is extracted, where is each piece kind of extracted from, right?

s196
00:17:05.199 --> 00:17:11.839
Uh Nvidia actually did a cool um paper on this uh that they that I just found out about like yesterday.

s197
00:17:11.839 --> 00:17:14.799
I think it's called like find everything or something like that.

s198
00:17:14.799 --> 00:17:25.391
um where they try to address the bottleneck of like you know citation uh determination and like the speed at which you could find a citation for something that's in a document.

s199
00:17:25.391 --> 00:17:25.760
[snorts]

s200
00:17:25.760 --> 00:17:32.240
If you're interested about these things, we are hiring and so uh come speak to us after.

s201
00:17:32.240 --> 00:17:33.120
Sorry.

s202
00:17:33.120 --> 00:17:35.120
Questions.

s203
00:17:41.919 --> 00:17:43.039
Yeah, absolutely.

s204
00:17:43.039 --> 00:17:50.160
So, let me try to see if one of the résumés I uploaded has an image in it.

s205
00:17:50.160 --> 00:17:51.120
So, let's see here.

s206
00:17:51.120 --> 00:17:51.600
Right.

s207
00:17:51.600 --> 00:17:54.640
So, um we have some figure models, right?

s208
00:17:54.640 --> 00:17:56.080
that are basically determining.

s209
00:17:56.080 --> 00:18:01.440
Let me actually also rerun this real quick so that it can return figures.

s210
00:18:18.880 --> 00:18:20.480
Ah, that's a great question.

s211
00:18:20.480 --> 00:18:22.799
Um, Alvin, did you hear that?

s212
00:18:22.799 --> 00:18:24.320
No, no. So, I I'll explain.

s213
00:18:24.320 --> 00:18:29.840
The reason why um I I asked Alvin is because Alvin worked on our hybrid OCR model, right?

s214
00:18:29.840 --> 00:18:39.679
Um and so we have a specific OCR uh like you know configuration that you can enable here that will pri figure out kind of intelligently what to prioritize, right?

s215
00:18:39.679 --> 00:18:48.240
Um so in some cases we will actually pick out like just you know strict OCR data or we might pick out like um you know metadata from the PDF.

s216
00:18:48.240 --> 00:18:50.799
Um yeah we've done a lot of work here.

s217
00:18:50.799 --> 00:18:54.799
Uh and it's it's not a simple sol like it's not a simple answer.

s218
00:18:54.799 --> 00:18:59.200
Um this is something we could do an entire different talk on.

s219
00:18:59.200 --> 00:19:01.200
Yeah.

s220
00:19:23.600 --> 00:19:27.280
So I'll be frank with you like this is actually exactly what this pipeline is doing, right?

s221
00:19:27.280 --> 00:19:35.360
So like we first parse the like the Hold on, let me turn return figures.

s222
00:19:35.360 --> 00:19:36.000
Cool.

s223
00:19:36.000 --> 00:19:42.400
So, um, while I rerun this, what we're doing here, let me pick a different example.

s224
00:19:42.400 --> 00:19:44.400
Ah, actually, we're gonna have to wait now.

s225
00:19:44.400 --> 00:19:53.440
But what we're actually doing in like extraction is taking the parse results and then feeding them into, you know, some extraction pipeline downstream.

s226
00:19:53.440 --> 00:20:00.640
So, like parse is kind of like the um, you know, it it is it is what made reductto reductive in the first place, right?

s227
00:20:00.640 --> 00:20:04.400
And then we can do a lot of cool things, you know, downstream of reductto.

s228
00:20:04.400 --> 00:20:18.000
So uh you know once we have that parse content for example right we could split you know the document into different regions and figure out like if I'm parsing some you know a math textbook I want to understand like where exactly

s229
00:20:18.000 --> 00:20:28.720
every chapter you know starts and ends and then for each chapter I might want to do like an extraction based on that right and uh get you know the chapter summary or something like that right

s230
00:20:28.720 --> 00:20:39.440
uh so parse is really the kind of foundation for all of these other agentic um document processing u features.

s231
00:20:43.840 --> 00:20:47.789
Man, if I answer that question, I might lose my job tomorrow.

s232
00:20:47.789 --> 00:20:48.159
[laughter]

s233
00:20:48.159 --> 00:20:52.320
So, um I mean it's a Yeah, continue.

s234
00:20:52.320 --> 00:20:58.000
I think it depends on like what pro data we collect um as well.

s235
00:20:58.000 --> 00:21:02.559
So we specifically um train on like certain types of data.

s236
00:21:02.559 --> 00:21:06.080
If we find that it's doing poorly on certain types of data.

s237
00:21:06.080 --> 00:21:09.280
So we see that like long context recall is not great.

s238
00:21:09.280 --> 00:21:11.280
Then we got to like try and fix that.

s239
00:21:11.280 --> 00:21:16.640
Specifically for extract um it's it's not really like Neil in a haststack.

s240
00:21:16.640 --> 00:21:19.360
It's like all the needles in a haststack if you think about it.

s241
00:21:19.360 --> 00:21:26.559
So that's like a really um challenging like research problem that our MLES are like somehow able to figure out pretty well.

s242
00:21:26.559 --> 00:21:29.600
But yeah, happy to chat more later.

s243
00:21:30.240 --> 00:21:31.039
Yeah.

s244
00:21:31.039 --> 00:21:32.320
Oh, we've been neglecting you guys.

s245
00:21:32.320 --> 00:21:32.559
Yeah.

s246
00:21:32.559 --> 00:21:33.200
What's up?

s247
00:21:33.200 --> 00:21:40.640
You you you'll be Yeah, you should you should stay tapped into our uh like our our socials and you'll find out about this very soon.

s248
00:21:40.640 --> 00:21:52.559
I think like benchmarking is you know always a topic of discussion and something that we want to really stay on top of especially because you know somebody who is testing who wants to do document extraction

s249
00:21:52.559 --> 00:21:58.080
might not you know know where to go or who's better right without actually testing themselves.

s250
00:21:58.080 --> 00:22:07.039
Uh so that's why benchmarking is like something that's you know we're we're prioritizing a lot uh especially in the coming months to to try to show people like how well we are doing.

s251
00:22:07.039 --> 00:22:13.919
you know, we try we're we're very confident in our models and us being like, you know, the premier document extraction solution on the market.

s252
00:22:13.919 --> 00:22:24.240
Uh but there need to be uh more, you know, um data points that we can rest on and that the, you know, entire industry can kind of see at face value

s253
00:22:24.240 --> 00:22:34.960
uh without having to go test themselves or pass in the all entire ARC AGI data set to you know try to understand uh you know how well reducto is doing against another solution.

s254
00:22:34.960 --> 00:22:35.200
Yeah.

s255
00:22:35.200 --> 00:22:37.760
So we're going to release some benchmarks soon.

s256
00:22:37.760 --> 00:22:43.120
But the real deeper answer here is you typically have to make your own benchmarks unfortunately.

s257
00:22:43.120 --> 00:22:46.559
So every single one of our customers typically have some benchmark.

s258
00:22:46.559 --> 00:22:49.200
They're like, "Oh, we're evaluating document providers.

s259
00:22:49.200 --> 00:23:00.000
Uh we're going to run some head-to-heads uh of like reducto versus like all these other like use cases and you know sometimes they don't use like maybe our APIs really well because they use the wrong config.

s260
00:23:00.000 --> 00:23:11.919
So we work closely with them like hey turn this on turn this on you get this trade-off and then uh we let them decide um and then like we often like win these headto-heads in like performance.

s261
00:23:11.919 --> 00:23:26.559
So as with most projects you know gather a simple data set you can do some like vibe eval just look look in studio see if the outputs make sense and then like as you want to scale it out then get like 100 documents a thousand documents do something more systematic

s262
00:23:26.559 --> 00:23:34.240
and you can also work with our team where we have a lot of people to you know work with customers to help you do your emails but yeah

s263
00:23:34.240 --> 00:23:52.400
cooly um any more questions yeah sure well yeah absolutely right um I I think so I'll answer this uh pretty honestly right I think when I was working on this solution right or I was working on this problem I was trying to figure out like what is a good productized

s264
00:23:52.400 --> 00:24:02.799
way to you know surface our reducts parsing right um and to be frank with you right like I came up with something that was pretty shoddy in the beginning

s265
00:24:02.799 --> 00:24:11.840
um like basically a you know rag chatbot application where you can ask anything about the emails right and it might be something that would be really really useful for like a journal journalist, right?

s266
00:24:11.840 --> 00:24:24.240
However, um I think it's testament to the hundreds of millions of people that you know were, you know, using Gmail and and the tens of million that still, you know, log on uh from week to week nowadays.

s267
00:24:24.240 --> 00:24:35.200
Um it's it's testament to the fact that a nice product on top of a really really nice novel, you know, uh document extraction solution is what is going to kind of be a onetwo punch here.

s268
00:24:35.200 --> 00:24:35.520
Yeah.

s269
00:24:35.520 --> 00:24:39.279
Like would you read three million like scan documents?

s270
00:24:39.279 --> 00:24:44.000
Honestly, no. And honestly, when I saw the drop, I was like, "This is like way too much work for me."

s271
00:24:44.000 --> 00:24:50.240
But once Omar built it, I just like logged on and like started searching like random like famous people for fun.

s272
00:24:50.240 --> 00:24:52.000
And so that's the beauty of it, right?

s273
00:24:52.000 --> 00:24:55.279
Like I think like unstructured data is like everywhere.

s274
00:24:55.279 --> 00:25:01.120
And sometimes all you need to take all you need to do is like to extract it and then like do whatever you want with it.

s275
00:25:01.120 --> 00:25:05.200
It's basically what all our customers like do um conceptually.

s276
00:25:05.200 --> 00:25:11.760
So I think Gmail is a pretty fun example but it's actually very u it's exactly what happens in the industry.

s277
00:25:11.760 --> 00:25:12.559
Yeah.

s278
00:25:12.559 --> 00:25:13.360
You seen that?

s279
00:25:13.360 --> 00:25:14.960
Come here.

s280
00:25:14.960 --> 00:25:16.720
It's it's just hard work, right?

s281
00:25:16.720 --> 00:25:19.360
Like you know we we have a data labeling team, right?

s282
00:25:19.360 --> 00:25:25.360
We have to go like par you know like we have to sift through a lot of documents if we're going to train a new model on top of it.

s283
00:25:25.360 --> 00:25:31.279
Um and be very very certain in the outcomes of you know or or the the sanctity of that data, right?

s284
00:25:31.279 --> 00:25:34.027
Um and so the short answer for you is just

s285
00:25:34.027 --> 00:25:34.080
[snorts]

s286
00:25:34.080 --> 00:25:38.000
like it's a lot of hard menial annoying work, right?

s287
00:25:38.000 --> 00:25:43.039
Uh but that's really what comes into like the beauty of a machine learning model at the end of the day, right?

s288
00:25:43.039 --> 00:25:59.200
There's nothing that you know really beats that like really really hard, you know, just wrote classification work uh that then compounds into uh model training and then you know then you can kind of figure out like how to stagger your data and like how to train you know on on top of your training set.

s289
00:25:59.200 --> 00:26:03.919
At the end of day, at the end of the day, you still have to label that data.

s290
00:26:03.919 --> 00:26:04.240
Cool.

s291
00:26:04.240 --> 00:26:08.559
I think we'll take Yeah, we could take one more, but um Yeah.

s292
00:26:08.559 --> 00:26:08.799
Yeah.

s293
00:26:08.799 --> 00:26:12.559
So, to repeat the question uh and let me know, you know, how how accurate it was, right?

s294
00:26:12.559 --> 00:26:21.200
But, uh it seems like, you know, like there are cases in which uh you need to really customize your logic on top of different documents.

s295
00:26:21.200 --> 00:26:24.240
Uh whether it be corresponding to specific models, right?

s296
00:26:24.240 --> 00:26:34.480
Sometimes there might be metadata set up in specific ways um in specific documents and you want to really like uh condition um for these specific use cases, right?

s297
00:26:34.480 --> 00:26:37.279
Um this is a fantastic question, right?

s298
00:26:37.279 --> 00:26:41.760
And so this is where our agentic um section really comes in, right?

s299
00:26:41.760 --> 00:26:54.720
So you can actually apply all of these different, you know, uh, configs and apply like, uh, system prompts on top of separate models that will do specific processing that's tailored directly to what you're asking for.

s300
00:26:54.720 --> 00:27:05.360
So for example, right, if uh you want to do some complex figure extraction, let's say I have a bunch of logos and I want to try to determine like you know what differentiates

s301
00:27:05.360 --> 00:27:13.679
like I don't know uh some you know uh Lincoln Financial from like Google and like how to separate those kinds of logos, right?

s302
00:27:13.679 --> 00:27:24.480
I could add some additional color here within our uh you know prompts uh in this config to custom kind of tailor u the outputs that I'm looking for.

s303
00:27:24.480 --> 00:27:34.720
So if you wanted some specific metadata here, let's say like uh you know some layout might be like really really hard to read in uh I don't know like a construction blueprint, right?

s304
00:27:34.720 --> 00:27:46.159
I would spend a lot of time in the uh layout prompt kind of tailoring to try to understand uh how well you know uh my current extraction solution is mapping across all of my different

s305
00:27:46.159 --> 00:27:50.080
um you know construction blueprints I guess right cool.

s306
00:27:50.080 --> 00:27:52.320
Um does that answer your question?

s307
00:27:52.320 --> 00:27:53.200
Fantastic.

s308
00:27:53.200 --> 00:27:53.679
All right.

s309
00:27:53.679 --> 00:28:02.159
So now we want to kind of um spin this off um into an interactive exercise.

s310
00:28:02.159 --> 00:28:02.799
Right.

s311
00:28:02.799 --> 00:28:09.840
So, um, if you guys would like, we're going to basically give you guys, you know, um, however much time you would like.

s312
00:28:09.840 --> 00:28:11.679
I think we have about 30 minutes left.

s313
00:28:11.679 --> 00:28:20.480
Um, and you could sign up today at, uh, at studio and essentially, uh, just get started, uh, on some document extraction solution, right?

s314
00:28:20.480 --> 00:28:28.960
So, what what you'll see here in a QR code is something that you could basically paste directly into a cloud code or a codeex or whatever, and something you could just get started

s315
00:28:28.960 --> 00:28:31.919
uh, on uh, document extraction with immediately.

s316
00:28:31.919 --> 00:28:45.520
Uh so we're going to give you guys about 30 minutes and by you know maybe around like five minutes uh like at the five minute remaining mark we'd love to kind of see what you guys have cook uh cooked up and we have a bunch of cool swag and a couple of cool prizes for you guys

s317
00:28:45.520 --> 00:28:49.279
uh to just kind of show us what you got um with respect to document extraction.

s318
00:28:49.279 --> 00:28:57.440
Um it could totally be just like an idea um and like a singleshot prompt but uh feel free to just kind of uh give it a whirl.

s319
00:28:57.440 --> 00:28:58.159
Sound good?

s320
00:28:58.159 --> 00:29:03.039
Also, we'll be kind of like circling around if you guys have any questions as to how to use Redto.

s321
00:29:03.039 --> 00:29:08.000
Uh, I want to come work for you guys, you know, I want to hear about your models, how you guys train, whatever.

s322
00:29:08.000 --> 00:29:10.640
Um, we are happy to answer.

s323
00:29:10.640 --> 00:29:12.960
Sound good?

s324
00:29:26.555 --> 00:29:28.555
[music]