WEBVTT

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

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

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.719 --> 00:00:17.279
So quickly about mixread and what we're doing before I jump into the interesting things.

s3
00:00:17.279 --> 00:00:24.000
So mixread started as a research lab around retrieval since we were really sad about the state how the space was evolving.

s4
00:00:24.000 --> 00:00:36.480
So we have been doing research for the two and a half years over how we can make retrieval really really good and we come ended up with a product where you can ingest any kind of data and make it searchable for agents meaning PDF,

s5
00:00:36.480 --> 00:00:40.160
spreadsheets, images, video, audio in over 100 languages.

s6
00:00:40.160 --> 00:00:45.440
So it's a true multimodel multilingual search where we are owning the models.

s7
00:00:45.440 --> 00:00:48.000
So we built the models from scratch specifically for search.

s8
00:00:48.000 --> 00:01:05.519
We build our own database so we can provide zero data retention and all the privacy privacy requirements you need and also we build injection pipeline so you don't have to hustle to managing injection managing OCR and knowing what to do and instead you just dump your data into it rely on our models working good enough

s9
00:01:05.519 --> 00:01:17.280
and you know so you can build really really powerful agents and I'm really happy that over the last three months like we're live since 5 months but over the last three months we onboarded banks and hedge funds into mixread

s10
00:01:17.280 --> 00:01:26.400
and alive with it with billions of documents and the main reason is we are so ISO compliant and we have this bring your own bucket mode meaning that we can really

s11
00:01:26.400 --> 00:01:36.799
offer all the security requirements you need with zero data retention so when we talk about evidence layer or using really really powerful agents right it mostly comes down to

s12
00:01:36.799 --> 00:01:46.560
working on your data so if you have like oh sorry um how to move this forward so assume that you're building an agent or you have an equity analyst

s13
00:01:46.560 --> 00:01:51.759
this is just like an example query because Intel yesterday released their new GPU cards, right?

s14
00:01:51.759 --> 00:01:58.799
Like the D270 and somehow it has a really weird design that it's using a lot of LPDDR5 memory.

s15
00:01:58.799 --> 00:02:02.719
So, you know, like you're an analyst sitting there and what the Why is Intel publishing this, right?

s16
00:02:02.719 --> 00:02:05.759
Why why does it have so much LPDDR5 and not HBM memory?

s17
00:02:05.759 --> 00:02:12.720
So, it would ask your system a question like, hey, why does the new Intel D270 use LDR5 memory?

s18
00:02:12.720 --> 00:02:17.599
And since you guys probably as you're working in finance, you have a lot of data brokers and data providers.

s19
00:02:17.599 --> 00:02:23.680
They send you the podcast, they send you interviews, they send you materials, research uh stuff and so on and so forth.

s20
00:02:23.680 --> 00:02:27.760
So you have this huge knowledge base and now your analyst is asking this question, right?

s21
00:02:27.760 --> 00:02:39.040
So when you use cloud code or cloud cowwork, what it normally does when you have your ingest data locally, it uses the terminal and basically uh lexical search like grab

s22
00:02:39.040 --> 00:02:50.959
to figure out, hey, where do we find terms like ADDPR5 or Intel and GPUs to just figure out, hey, what documents can be the closest and the most relevant ones?

s23
00:02:50.959 --> 00:03:00.560
And as you have a lot of PDFs and a lot of documents and interviews, you will get a lot of hits and you have no relevancy and you don't know where to look into.

s24
00:03:00.560 --> 00:03:12.720
So what the model will end up doing is reading every document and like this, you know, like your token cost will just go up and up and up and the more documents you have, you will end up with per query costing 10 or $20

s25
00:03:12.720 --> 00:03:14.959
to just ask a really basic question.

s26
00:03:14.959 --> 00:03:26.640
And the second downside of that is also that most PDFs sadly are not really grapable because you know like there are binary formats sometimes there are scans in there images in there so you can't really exploit this multimodel

s27
00:03:26.640 --> 00:03:30.319
data relying in there to work for you.

s28
00:03:30.319 --> 00:03:42.640
So these are like the key bottlenecks and then you think okay what are people doing and what people have done previously in the spade space who's familiar with the term rack retrie augmented generation just hands up really quickly.

s29
00:03:42.640 --> 00:03:48.159
So I think most people so uh I think you will it will resonate what I'm going to say now.

s30
00:03:48.159 --> 00:03:55.120
So then we were like okay good let's let's build a sophisticated pipeline where can make all this data really really usable for us.

s31
00:03:55.120 --> 00:03:58.239
So we have this billions of PDFs podcast whatsoever.

s32
00:03:58.239 --> 00:04:00.480
So first thing we do is we do parsing right.

s33
00:04:00.480 --> 00:04:10.159
So if you have um audio we do transcription um if you have PDF we do OCR and what every of the step does it introduces noise.

s34
00:04:10.159 --> 00:04:21.120
So if you can if you don't process tables properly, if you don't pass diagrams properly, what will happen is that you will just lose information and then you do the chunking.

s35
00:04:21.120 --> 00:04:27.120
So you already lost information because your table is not passed properly or characters are not processed properly, then you do some chunking, right?

s36
00:04:27.120 --> 00:04:31.040
So if you have figures, table, pages, where's really the chunk boundary?

s37
00:04:31.040 --> 00:04:40.960
So you're introducing more noise and then you're giving it to a pure embedding model which you know like takes this information and then tries to guess a point in the space

s38
00:04:40.960 --> 00:04:55.680
to you know like what this information represents and since it already lost so much information you are losing then having this point right and this is then a super lossy process from going from this really rich information to hey here's just a point

s39
00:04:55.680 --> 00:04:59.600
and then you put it into a vector database do some retrieval and rerank.

s40
00:04:59.600 --> 00:05:08.320
So since every step is lossy and you have to add a vendor for every process, you will end up hey what is the best OCR?

s41
00:05:08.320 --> 00:05:09.680
What is the best chunking strategy?

s42
00:05:09.680 --> 00:05:11.360
What is the best embedding model?

s43
00:05:11.360 --> 00:05:12.960
Uh what is the best vector database?

s44
00:05:12.960 --> 00:05:14.000
What is the best ranking?

s45
00:05:14.000 --> 00:05:31.120
So you will just evaluate it for six or eight months different vendors run through security to just go live and you have to allocate four to five people to that to just build something from my perspective super basic which won't work in the end because there's some inherent limits of how this

s46
00:05:31.120 --> 00:05:42.800
things are done and we internally call it the Frankenstein stack and there like some proofs why you know like the single vector models or like just putting all this information into

s47
00:05:42.800 --> 00:05:59.840
embedding model and one point actually doesn't really work and we can discuss it later if you guys are interested why and I can go on a rant and explain it a bit more in depth but this is actually right now the state-of-the-art what people use and this is also the reason like all the bottlenecks I described right

s48
00:05:59.840 --> 00:06:13.199
now why rack actually never worked so you know like I think you all remember this promise of hey here's spine cone or here's any vector database just put it in and it will just work but it never really worked out and it comes down to that

s49
00:06:13.199 --> 00:06:26.240
every step is super lossy and that also the models we have the embedding models with the technologies they're using at the moment are not good enough so you you can't really use this information properly

s50
00:06:26.240 --> 00:06:42.560
and the downside when I talk about this embedding models is you have to imagine like how this embedding model work right you have an information like I love bread you put it into a model and then it just takes this sentence and puts it somewhere in the space and later if you ask hey who loves bread

s51
00:06:42.560 --> 00:06:47.680
we'll put also into the model and we'll put it somewhere into space as well and then just search around the query.

s52
00:06:47.680 --> 00:06:54.880
Hey, where's the similar point to basically describe that but now let's think about a financial report like a sec filling.

s53
00:06:54.880 --> 00:07:03.280
If you have like complex tables with all this different information like net income, revenue yada yada yada what does this point actually represent?

s54
00:07:03.280 --> 00:07:04.000
Right?

s55
00:07:04.000 --> 00:07:07.120
So maybe it uh represents information about Nvidia.

s56
00:07:07.120 --> 00:07:09.039
So it's Nvidia's earnings report, right?

s57
00:07:09.039 --> 00:07:15.680
But if you have the earnings report from 1996 or 2000 and 2026 the points will look really really similar.

s58
00:07:15.680 --> 00:07:24.639
That's why when you have a lot of information which look very similar rack and all this vector database approaches don't work and we see with a lot of customers

s59
00:07:24.639 --> 00:07:33.520
in their classic approach if you have just few documents let's say tens of hundreds of documents the quality is pretty good but as you start scaling and going into production

s60
00:07:33.520 --> 00:07:46.000
the answer quality will just degrade significantly because this type of vector search and this type of technology is not able to really distinguish between this fine grained information and the issue is you have a pure

s61
00:07:46.000 --> 00:07:48.160
a poor agent, right, who wants to really help you.

s62
00:07:48.160 --> 00:07:52.000
He he will do everything his to serve you and do everything for you.

s63
00:07:52.000 --> 00:07:53.599
So what will this agent start doing?

s64
00:07:53.599 --> 00:07:55.120
It will just query aggressively.

s65
00:07:55.120 --> 00:07:57.520
It will spin up tens of sub agents.

s66
00:07:57.520 --> 00:07:59.840
Um we'll do more and more queries.

s67
00:07:59.840 --> 00:08:05.680
So you know it will just fill up the context window and every query will become expensive.

s68
00:08:05.680 --> 00:08:08.800
You can answer it like this by just putting a lot of agents on that.

s69
00:08:08.800 --> 00:08:12.560
But the question is hey is it really the way you want to go into production?

s70
00:08:12.560 --> 00:08:20.960
If you also imagine at one point that maybe your fund or your VC will be mostly run by agents and the volume of agent traffic will just increase.

s71
00:08:20.960 --> 00:08:25.680
So the cost of running the systems will just skyrocket.

s72
00:08:26.639 --> 00:08:39.919
So this is why we came to the conclusion pretty early when we're working with our customers that intelligence is there but the real real bottleneck is actually access to your data and to your knowledge

s73
00:08:39.919 --> 00:08:50.720
and we believe that we will see a unbundling of intelligence and data where you have intelligence where you can choose between different intelligence models but you need to have the right access for this intelligence

s74
00:08:50.720 --> 00:08:57.360
for your data so you can make the most of that and for this we built um mix bread.

s75
00:08:57.360 --> 00:09:04.320
So as I mentioned mixread started as a research lab and this is a really interesting graphic and this is a preview of what's coming next week.

s76
00:09:04.320 --> 00:09:14.160
Um is that retrieval how it changed like over the last from 1994 to now it's like what 32 years I think my if my mental math is not wrong.

s77
00:09:14.160 --> 00:09:15.680
So we started with BM25.

s78
00:09:15.680 --> 00:09:21.519
This is what elastic search is doing like simple keyword matching and then we just started coming up with smarter method.

s79
00:09:21.519 --> 00:09:25.440
So the first really good embedding models were published in 2022.

s80
00:09:25.440 --> 00:09:31.920
So it took the space 27 years to come something up for text search better than BM25.

s81
00:09:31.920 --> 00:09:36.080
But since then we have more like a linear um like improvement.

s82
00:09:36.080 --> 00:09:44.080
And this is also what we meant with rack not working because there was never a step function change like we saw with chatbt and so and so forth and

s83
00:09:44.080 --> 00:09:56.480
we published our first model by beginning uh we finished the training at end of last year published it beginning of this year it was pretty solid but the thing we're publishing next week and we already live with a lot of our customers

s84
00:09:56.480 --> 00:10:12.800
we think is a step function change which overcomes most of the challenges I described before just in short what this model does is it's a late interaction model Meaning instead of having just one embedding, you have multiple embeddings for your documents and you have multiple embeddings for your queries like this.

s85
00:10:12.800 --> 00:10:15.600
You can really describe fine grained information on a page.

s86
00:10:15.600 --> 00:10:20.160
So going back to the SEC filling for Nvidia for different years, right?

s87
00:10:20.160 --> 00:10:29.360
So you would have the model would figure out an embedding for net income for net revenue etc etc but since it's like creating it in one pass it also know it's about Nvidia.

s88
00:10:29.360 --> 00:10:40.880
So every embedding is contextualized and with the information which are relevant to you and all this technique and scaling up the model and better data gives us significant jump in quality

s89
00:10:40.880 --> 00:10:51.440
uh which allows to do some cool things which allows to actually build this product uh mix where you just upload your data mix takes care of indexing it for you like every page

s90
00:10:51.440 --> 00:11:04.560
as it looks because it's multimodel I will show what it means and you then just can give it agent access to mixread and the agent does the querying the reading the grabbing everything for you and you can just focus on on what's fun actually building the real application

s91
00:11:04.560 --> 00:11:18.000
and actually building real RARI right so um let me show you what it means so this is mixre and what I did here is I uploaded some um Intel

s92
00:11:18.000 --> 00:11:30.240
um wait hold on where is it exactly so I uploaded some Intel reports here for example the Intel earning stack so what you do in mix is just upload the uh page.

s93
00:11:30.240 --> 00:11:31.600
The internet is pretty slow.

s94
00:11:31.600 --> 00:11:31.687
I

s95
00:11:31.687 --> 00:11:31.839
[snorts]

s96
00:11:31.839 --> 00:11:34.560
hope it will be fine.

s97
00:11:34.959 --> 00:11:37.600
So, it's it's failed to load because the internet is slow here.

s98
00:11:37.600 --> 00:11:39.040
I'm so sorry about that.

s99
00:11:39.040 --> 00:11:40.800
Um I should have recorded a video.

s100
00:11:40.800 --> 00:11:45.600
Um so, let's do this.

s101
00:11:45.600 --> 00:11:46.399
Cool.

s102
00:11:46.399 --> 00:11:49.279
So, what it does here is so we have a slide.

s103
00:11:49.279 --> 00:11:50.160
Come on, dude.

s104
00:11:50.160 --> 00:11:53.760
So, you see there's a uh is there's a figure, right?

s105
00:11:53.760 --> 00:12:07.519
So normally if you would just do OCR and the figure and you want to know the actually the revenue of Intel in Q2 2025 if you just would do OCR you would just all lose all information it would never really able to match the page because you need to understand

s106
00:12:07.519 --> 00:12:19.680
what's going on there but if you create the embedding on the visual perspection like looking let the model look at the page the screenshot and create the embedding based on that you are getting rid of all this useless stuff I was talking before

s107
00:12:19.680 --> 00:12:33.600
but since not all LM are multimodel mixread still provides stuff like layout information and OCR for your downstream thing where you can decide to put in the screenshot or the text yourself to do the right thing and let's just try it out together.

s108
00:12:33.600 --> 00:12:41.360
So let's say we want to know hey what was in Intel's foundry segment operation mar mar mar mar mar mar mar mar mar mar mar mar mar mar mar mar mar mar mar mar margin in Q2 2025

s109
00:12:41.360 --> 00:12:54.959
it goes out I hope it will work now normally it's like sub 200 milliseconds but you saw the thing before um so we see hey it finds somehow this page here which is talking about in Foundry

s110
00:12:54.959 --> 00:13:09.279
and down here come on you can do it here you go it's talking about Q2 to 2025 and it understands also hey it's somehow about segment revenue and can really pass all this information

s111
00:13:09.279 --> 00:13:25.760
and since we have this visual layout stuff we can actually reference this with bounding boxes and when your analyst or your agent is deriving to a decision you can actually backtrack and site where it is coming from and we're providing all the APIs and all the primitives for you to build this experience yourself

s112
00:13:25.760 --> 00:13:40.000
and if you have like really really complex queries for example you want to know like something more qualitative Hey uh is Intel's foundry uh prof uh profitably improving and what is driving it?

s113
00:13:40.000 --> 00:13:51.519
So if you just query it for example our system realize hey this is a more complex query let's do a genetic search a genetic search is a model we trained toast one it's like a

s114
00:13:51.519 --> 00:14:02.079
agent which does multiple queries for you multihop reasoning and it's as good as Astra and fable while being 40 times faster and cheaper which then goes out and does like multiple queries

s115
00:14:02.079 --> 00:14:14.000
um and can really decompose everything and come back with the right data and uh this data can then fed into an LLM to actually explain what what what is happening there and we just also expose it as a primitive.

s116
00:14:14.000 --> 00:14:25.199
This is just a demo, a playground to show you what's possible, but you can just use it, give it to an agent and let the agent decide if you want to use grab, normal search or the agentic search depending on the complexity.

s117
00:14:25.199 --> 00:14:26.880
Exactly.

s118
00:14:26.880 --> 00:14:33.040
And yeah, um so this is uh was as a backup if it wouldn't have worked.

s119
00:14:33.040 --> 00:14:34.720
Um so the agent can do everything.

s120
00:14:34.720 --> 00:14:38.480
And here a small case study which we will publish also in two weeks from now.

s121
00:14:38.480 --> 00:14:39.760
It's like a really big hedge fund.

s122
00:14:39.760 --> 00:14:42.800
We on boarded within like one and a half weeks.

s123
00:14:42.800 --> 00:14:52.720
um because they have like over 1 billion documents right now and they are building a lot of internal agent platform for the analyst and for their fund managers to derive qualitative

s124
00:14:52.720 --> 00:15:04.560
uh analysis and also come up with should we is it a good decision or not and before they have built what I described before this chunking betting OCR some random embedding model some vector database

s125
00:15:04.560 --> 00:15:14.399
and they had a answer accuracy like how often the agent is right of 36% where the human experts knew the answer and graded And once they move to mix spread

s126
00:15:14.399 --> 00:15:24.320
the answer accuracy moved to 98% because the again the issue is not intelligence it's again getting the right data and just by providing way better search to your agents

s127
00:15:24.320 --> 00:15:39.519
you can first make it really good um here's a breakdown on multimodality and text questions and as you can see multimodality is just bumps it quite significantly but second is you use also wafier tokens so the LM spend is going down by 3x

s128
00:15:39.519 --> 00:15:44.000
because again most of the tokens are used to find, pass, and read information.

s129
00:15:44.000 --> 00:15:53.199
And as you just fit in really good context, you know, like you just need way less LLM cost and the LM can just focus on what's relevant.

s130
00:15:53.199 --> 00:15:54.240
Um, exactly.

s131
00:15:54.240 --> 00:15:57.519
So, this is my talk in a nutshell.

s132
00:15:57.519 --> 00:16:05.680
Um, if you want to try out MixPread, uh, this we have toast, uh, flyers downstairs, so if you want to take them, I think they're pretty funny.

s133
00:16:05.680 --> 00:16:06.720
Um, and you can sign up.

s134
00:16:06.720 --> 00:16:07.920
We have free credits.

s135
00:16:07.920 --> 00:16:11.040
Uh, if you are concerned about security, you can just write us.

s136
00:16:11.040 --> 00:16:21.759
We activate bring on bucket within 5 minutes for all of our customers and then you can just start trying it and if you have like really large corpuses we provide a lot of free credits so you can benchmark it before

s137
00:16:21.759 --> 00:16:24.720
really onboarding it.