AI Engineer World's Fair 2025
How BlackRock Builds Custom Knowledge Apps at Scale
Read the talk
How BlackRock Builds Custom Knowledge Apps at Scale
BlackRock’s sandbox and app factory turn domain expertise into configurable extraction workflows, then package those workflows as applications that reach downstream systems.
From a talk by Vaibhav Page and Infant Vasanth
Before you start: Familiarity with LLM prompting, structured data extraction, and application deployment will help; no financial-instrument expertise is required.
Turning information into operational work
How do you build custom applications quickly when every step from incoming information to a completed trade requires specialized knowledge? At BlackRock, portfolio managers and analysts synthesize information, develop investment strategies, rebalance portfolios, and initiate trades. Investment operations supports that process: acquiring data, executing trades, handling compliance, and completing post-trade activities. Each domain needs internal tools, often with substantial complexity.
Infant Vasanth and Vaibhav Page organize these applications into four categories. Each offers opportunities to augment existing systems with LLMs:
| Application category | Work it supports |
|---|---|
| Document extraction | Extract entities from documents |
| Automation and workflows | Run multiple steps and integrate downstream |
| Knowledge search and Q&A | Answer questions through chat interfaces |
| Agentic systems | Coordinate actions using models and tools |
The shared challenge is getting these domain-specific applications into users’ hands quickly.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A prospectus must become a configured security
A request from the new issue operations team, received three to four months before the talk, makes the problem concrete. When a company goes public or a stock splits, the team must set up the security in BlackRock’s internal systems before portfolio managers or traders can act on it. Reading the source document is only the beginning.
The simplified workflow has several handoffs:
- Ingest a prospectus or term sheet into a processing pipeline.
- Work with domain experts, including equity and ETF teams, to define what the complex instrument requires.
- Produce structured output.
- Have engineering implement transformation logic and integrate that output with downstream applications.
Extraction alone does not deliver an operational application. The output still has to become something the receiving systems can use.
Introducing model providers and trying new processing strategies adds iteration to an already lengthy process. Vasanth says the team tried agentic systems, but they did not work adequately for this use case at the time: too much instrument-specific knowledge remained in the experts’ heads. That experience motivates a framework that makes expert participation easier rather than assuming it can be removed.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Prompts and extraction strategies evolve together
The first bottleneck is expressing domain knowledge precisely enough for extraction. In one simple case, a prompt began as a couple of sentences and expanded to three paragraphs as the team described the financial instrument. Once prompts become substantial specifications, operators need to iterate, version them, compare alternatives, and evaluate performance against a dataset. Prompt editing without those surrounding capabilities leaves the team unable to tell whether a change helped.
The second bottleneck is choosing how to present the task and its evidence to the model. The options discussed include retrieval-augmented generation, chain-of-thought approaches, and direct in-context extraction. A vanilla corporate bond with a short source document may be simple enough to pass directly to a model. Documents thousands of pages long—and, in Vasanth’s examples, as long as ten thousand pages—create a different context-management problem.
Vasanth raises the question of sending more than a million tokens to OpenAI models. That is a model-specific capacity concern, not a universal current limit: GPT-4.1 had already been announced with up to one million context tokens before the talk. Capacity alone does not establish extraction reliability. The practical task remains to vary prompts and strategies together while accounting for context limits, model capabilities, and provider differences.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Deployment choices belong in the workflow
Experimentation can stretch into months, after which deployment introduces another set of decisions. The application still needs distribution, access control, and a way to reach its users. AI workloads also require a choice of execution environment.
Vasanth illustrates the compute decision with an equity team asking to analyze 500 research reports overnight; he proposes a GPU inference cluster for that request. This is a workload example, not a measured throughput result. For new issue setup, he instead describes using a burstable cluster.
These choices should be defined well enough that application deployment approaches a CI/CD process. Cost controls belong alongside the deployment configuration: a workflow that is easy to prototype can still be expensive to operate. The GPU and burstable-cluster examples illustrate workload-dependent choices, rather than requirements for every extraction application.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Separate expert iteration from application production
Vasanth reports that the framework reduced development time for a complex application from three to eight months to a couple of days. The talk does not specify measurement boundaries or a controlled comparison, so this is the team’s reported experience rather than a benchmark. The architectural change centers on two components: a sandbox and an app factory.
Shared platform components handle the surrounding data lifecycle. The data platform ingests data, and an orchestration layer transforms it into forms that can be distributed through applications or reports. Above those foundations, the framework exposes the pieces that repeatedly slow application development: extraction templates, LLM strategies, extraction plans, transformers, and executors.
The sandbox puts those modular pieces in the domain experts’ hands. Experts can iterate on their extraction logic and configuration, then pass the resulting definition to the app factory. Vasanth describes the factory as a cloud-native operator that accepts a definition and produces an application. The division gives experts a place to refine the work while giving deployment a repeatable input.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Encode dependencies, not just prompts
Page begins the demonstration with a reduced version of the internal tool. The sandbox lets operators build and refine extraction templates, run them against documents, and compare the results. Familiar prompt-template features provide a starting point: fields have prompts, expected output types, and associated metadata.
Operators also need QC checks, validations, constraints, and inter-field dependencies. A callable bond supplies the concrete example: if the security is callable, its call date and call price must have values. Independently extracting three correctly typed fields is insufficient if their combination violates that rule.
The example template contains issuer, callable, call price, and call date. When adding a field, an operator specifies its name, expected type, and whether its source is extracted or derived. A derived field can be populated by a downstream transformation instead of another model extraction. Required status, dependencies, and validations complete the configuration.
The callable-bond dependency can be expressed concretely with JSON Schema. This schema fragment captures the conditional validation rule; it is not the sandbox’s configuration format:
json
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"type": "object",
"properties": {
"issuer": { "type": "string" },
"callable": { "type": "boolean" },
"call_price": { "type": "number" },
"call_date": { "type": "string", "minLength": 1 }
},
"required": ["callable"],
"if": {
"properties": { "callable": { "const": true } },
"required": ["callable"]
},
"then": {
"required": ["call_price", "call_date"]
}
}
When callable is true, omitting either dependent field fails this rule. Validation detects the missing values; it does not invent them or establish that a supplied price or date is factually correct.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Carry extraction results into downstream systems
Document management supplies the other input to an extraction run. Documents arrive from the data platform, receive business-category tags and labels, and are embedded. The UI exposes these capabilities alongside the framework’s modular components so domain experts can assemble their applications.
After a demo interruption, Page continues the workflow verbally. Operators run extraction using the configured templates and document sets, then inspect the returned values. In tools they had previously used, the next steps remained manual: download CSV or JSON, apply an ad hoc transformation, and push the result to a downstream process.
Page describes a low-code/no-code framework that lets operators build transformation and execution workflows into the same pipeline. This capability was described rather than demonstrated. Its role is consequential: the operator’s configuration must cover not only what to extract, but also how those results become usable inputs to the next system.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Design for expertise, economics, and human review
Making the sandbox available does not eliminate the need to develop skills. Vasanth recommends investing in domain experts’ prompt engineering because financial documents are difficult to describe precisely. Teams also need to understand what different LLM strategies do and how the available components fit their particular use case.
Prototype success is only one part of the production decision. The team must evaluate ROI and compare the custom AI application with an off-the-shelf product that might deliver the same job faster or at lower cost. A framework that reduces development effort does not automatically make every proposed application worthwhile.
Design for human review first in highly regulated environments. Vasanth ties that recommendation to compliance, regulation, and four-eyes checks. Human participation is therefore an explicit workflow requirement, even when a fully agentic process looks attractive.
Page then returns to the app factory, which was also explained rather than demonstrated. It combines the extraction templates, transformers, and executors refined in the sandbox into custom applications exposed through BlackRock’s application ecosystem. End users do not have to configure templates or work out downstream integration. They upload documents, run extraction, and start the complete pipeline. The expert’s configuration becomes the user’s application.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Where the framework’s scope ends
The first audience question extends the workflow from IPO processing and ETL toward executive analytics. It asks how instrument-level features such as term, maturity, and duration could become higher-level asset-and-liability information, with decentralized data in mind. The suggestion that a CEO would be the main user is the questioner’s premise, not a deployment described by the presenters.
Vasanth narrows the scope: the framework targets investment operations domain experts who are building applications. An executive memo or an asset-and-liability analysis would be a different initiative, which might or might not use this framework. Components can be reused, but the answer does not specify an architecture for aggregating instrument features into executive analytics.
The final question comes from an insurance practitioner facing similar document-processing problems. How should extraction evaluations account for failures that begin with OCR, or for models that misunderstand domain terminology despite prompting? This asks about correctness across the processing chain, not simply whether a result satisfies its output schema.
Vasanth’s response addresses information security and boundaries: controls and policies apply at the infrastructure, platform, application, and user layers within the organization’s network. Those controls address security concerns, but they do not establish whether an extracted field matches its source document.
Page adds that the team selects among multiple providers, strategies, and engineering adjustments according to the use case, rather than applying one RAG recipe everywhere. The closing answer does not provide a concrete evaluation dataset, OCR test, extraction metric, or accuracy result. The framework makes expert iteration and application delivery more repeatable; the question of how to measure extraction correctness remains open in this account.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
Further reading
April 2025 announcement documenting one-million-token context windows and the model family's long-context capabilities.
Original RAG research combining language generation with retrieved passages from a dense document index.
Conference abstract from the same speakers covering context construction, evaluation, and financial AI applications.
Read the complete timestamped transcript
- 0:00
[on-hold music] Hi, everyone.
- 0:15
Thank you for having us. I'm Infant, Director of Engineering at BlackRock. This is my colleague, Vaibhav, Principal Engineer, and we both work for the data teams at BlackRock. And today, we are gonna talk about how we can scale building custom applications in BlackRock.
- 0:28
Specifically, we are talking about, like, AI applications and knowledge apps at BlackRock. Right. So just to level set before I get into the, uh, details. So BlackRock is an asset management firm, the world's largest asset manager.
- 0:39
What we do is our portfolio managers, analysts get a torrent of information on a daily basis. They synthesize this information, they develop an investment strategy, and then they rebalance their portfolios, uh, which ultimately results in a particular trade.
- 0:53
Now, the investment operations teams, you can think of that as the teams that are the backbone or the engine that make sure that all of the activities that the investment managers actually perform on a day-to-day basis, like, runs smoothly, right?
- 1:06
So these teams are kind of responsible for, like, a-acquiring the data that you kind of need, right, uh, to actually executing a trade, running through compliance, all the way to, like, all of the post-trading activities, right?
- 1:17
So all of these teams actually have to build these internal tools that are actually fairly complex for each of their domains, right? So building apps and pushing out these apps, uh, relatively quickly is, like, uh, of utmost important to us, right?
- 1:31
So if you move on to the next slide. Again, if you actually classify what kind of apps we are talking about, what you'll see is it kind of falls into, like, four different buckets, right?
- 1:39
One is everything to do with document extraction. So I have an app, I kind of want to, like, extract entities out of it in that bucket. Second has to do everything with, like, "Hey, I kind of want to define a complex, uh, workflow or an automation."
- 1:51
So I could have a case where I kind of want to run through X number of steps and then integrate to my downstream systems. And then you have the normal, like, Q&A-s type systems that you look at, like, this is your chat interfaces, and finally, like, the, the agentic systems, right?
- 2:05
So in each of these domains, what we see is, um, we have this, like, big opportunity to leverage your models and LLMs to either augment our existing systems, uh, or like, uh, kind of like supercharge those, right?
- 2:19
So that, that is, like, the domain we are speaking about. So I'll move quickly to one particular use case. So this, this is a use case that came to us, like, about, like, three to four months back, right?
- 2:30
And we have a team within the investment operations space. It's known as the new issue operations team, right? So this team is kind of responsible for setting up securities, uh, whenever there is, like, a market event, right?
- 2:41
So a company goes IPO or, like, there is, like, a stock split for a particular organization, right? The team actually has to take the security, and they have to set it up in our internal systems before our portfolio managers or traders can actually action upon it, right?
- 2:55
So we kind of have to build this tool for the investment operations team, right, to set up a particular security. This is like-- Actually, honestly, this is, like, a super simplified version of what happens.
- 3:05
But at super high level, we have to build an app that is able to, like, ingest your prospectus or a term sheet. It pushes it through a particular pipeline, right?
- 3:14
Uh, then you talk to your domain experts, and these are, like, your, uh, business teams, your equity teams, ETF teams, et cetera. They actually n-know how to set up these complex instruments.
- 3:23
You get some kind of structured output. And now that team works with the engineering teams to actually build this transformation logic and the like, and then integrate it with our downstream applications.
- 3:33
So you can see that this process actually takes a long time, right? So building an app, and then you're introducing new model providers, you're trying to put in, like, new strategies.
- 3:42
The-- lot of challenges to get a single app out, right? We tried this with agentic systems. Doesn't quite work right now because of the complexity and the, the domain knowledge that's imbued in the human head, right? [laughs]
- 3:56
So the big challenges with scale are, again, these three categories, right? One is we are spending a lot of time with our domain experts prompt engineering, right? So in the first phase where we have to extract these documents, right,
- 4:11
they're very complex, right? Your prompt itself, uh, in our simplest case, like, started with, like, a couple of sentences. Before you knew it, you're trying to describe this financial instrument, and it is, like, three paragraphs long, right?
- 4:22
Uh, so it, it-- There's this challenge of, like, "Hey, I have to iterate over these prompts. I have to version and compare these prompts. How do I manage that effectively?"
- 4:29
And I think even the previous speaker had mentioned you kind of need to eval and have this data set. How, how good is your prompt performing? So that's the first set of challenges in creating, like, AI apps itself, right?
- 4:38
How are you gonna manage this? In what direction? Second set of challenges is around, like, LLM strategies, right? What I mean by this is, like, when you're building an, uh, um, AI app, so to speak, you have to choose what strategy.
- 4:52
Uh, am I gonna use, like, a RAG-based approach, right? Or am I going to use a chain of thought based approach? Even for a simple task of, like, data extraction.
- 4:59
Depending on what your instrument is, this actually varies, uh, very highly, right? If you take, like, an investment corporate bond, like, the vanilla one, it's fairly simple. I can do this with, like, in context, pass it to model.
- 5:11
I'm able to get my stuff back if the document size is small, right? Some documents are, like, thousands of pages long, ten thousand pages long. Now suddenly you're like, "Oh, okay.
- 5:19
I don't know if I can pass, uh, more than a million tokens into, say, uh, the OpenAI models. What do I do then?" Right? Then okay, I need to choose a different strategy.
- 5:28
And often what we do is we have to choose different strategies and kind of mix them with your prompts to kind of build this iterative process where, like, I have to play around with my prompts.
- 5:38
I have to play around with the different LLM strategies, and we kind of ma- want to make that process as quickly as possible. That's a challenge, right? Then you have obviously the context limitations, model limitations, different vendors, and you're trying and testing, uh, things, uh, uh, for quite a while.
- 5:52
And this g- kind of goes into the month, right? Then the biggest challenge is, like, okay, fine, I've kind of built this app. Now what? How do I get this to deployment?
- 6:00
And it's this whole other set of challenges, right? You have your traditional challenges which just has to do with distribution, access control. How am I going to federate the app to the users?
- 6:09
But then in the AI space, it's like you have this new challenge of, like, what type of cluster am I going to deploy this to, right? So our equity team would come and say something like, "Hey, I need to analyze, you know, five hundred research reports, like, o- overnight.
- 6:22
Can you help me do this?" Right? So, okay, if you're going to do that, I probably have to have, like, a GPU-based inference cluster that I can kind of spin up, right?
- 6:30
This is the use case that I kind of described with this, the new issue setup. In that case, what we do is, okay, I don't really want to use my GPU inference cluster, et cetera.
- 6:38
What I do instead is I use, like, a burstable cluster, right? So all those have to be kind of, like, uh, defined so that our app deployment phase is, like, as close to, like, a CI/CD pipeline as possible.
- 6:51
Then you have, like, cost controls. So these are-- Again, it's not an exhaustive list. I think I'm-- what I'm trying to highlight is the challenges with kind of building AI apps, right?
- 7:00
So what we did at BlackRock is-- What I'm gonna do is I'll kind of give you a high-level architecture, uh, and then maybe Vaibhav, you can dive into the details and mechanics of how this works and how we are able to build apps relatively quickly, right?
- 7:14
We're able to-- We took this, uh, an app took us close to, like, eight months to-- somewhere between three to eight months to build a single app for a complex use case, and we're able to compress time, bring it down to, like, a couple of days, right?
- 7:25
We achieved that by building out this framework. Uh, what I kind of want to focus on is on the top two boxes that you see, which is your sandbox and your app factory, right?
- 7:34
So to the, uh, the data platform and the developer platform, it's, like, the name suggests, hey, platform is for someone for ingesting data, et cetera, right? You have an orchestration layer that has a pipeline that kind of, like, transforms it, brings it into some, uh, new format, and then you kind of distribute that as a app or
- 7:50
a report. What kind of accelerates at app development is, like, if you're able to federate out those pain points or those bottlenecks, which is, like, prompt creation or extraction templates, choosing an LLM strategy, right, having extraction plans or, like, and then building out these logic pieces which are calling transformer and executors.
- 8:11
If you can get that sandbox out into the hands of the domain experts, then your iteration speed becomes really fast, right? So you're kind of saying that, "Hey, I have this modular component.
- 8:20
Can I move across the situation really quickly and then pass it along to an app factory?" Which is like our cloud-native operator which takes a definition and spits out an app, right?
- 8:28
So that's super high level. With that, quick demo. [chuckles]
- 8:33
Perfect. All right. Cool. So what I'm gonna show you guys is pretty slimmed down version of the actual tool we used internally. Um, so to start with, uh, when the operat-- So we have, like, two different, uh, concore components.
- 8:50
One is the sandbox, another one is the factory. So think of sandbox as a playground for the operators to sort of, like, quickly build and refine the extraction templates, uh, sort of run extraction on the set of documents, and then compare and contrast the results of these extractions.
- 9:05
Um, [clears throat] so it's sort of like to get started with the extraction template itself, uh, you might have seen in the other tools, both closed and open source, they have similar concept like prompt template management.
- 9:16
Where you have certain fields that you want to extract out of the documents and you have their corresponding prompts and some metadata that you can associate with them, such as the data type that you expect of the, the final result values.
- 9:27
But when these operators sort of, like, trying to run extractions on these documents, they need far more sort of, like, greater configuration capabilities than just, like, configuring prompts and configuring the data types that they expect for the end result.
- 9:40
So they need like, "Hey, I need to have multiple QC checks on the result values. I need to have a lot of validations and constraints on the fields." And there might be, like, inter-field dependencies, uh, what, what the fields that are getting extracted.
- 9:54
So as Infant mentioned with the new se- security operation, um, issuance basically onboarding that stuff, there could be a case where, uh, the security or the bond is callable and you have other fields such as call date and call price which now needs to have a value.
- 10:10
So there is like this inter sort of like field dependencies that operators sort of like, uh, need to... They, they need to take that into consideration, be able to configure that.
- 10:18
So here is like what a, like a sample, uh, extraction template looks like.
- 10:24
So here is how a-- Again, this is a, a example template where we have like issuer, callable, call price, and call date, these fields set up. And to sort of like add new fields, we will define the field name, uh, define the data type that is expected out of that, uh, define the source, whether it's extracted or
- 10:41
derived. Not every time you wanna sort of like run an extraction for a field. There might be a derived field that operator expect which is sort of like, uh, populated through some transformation downstream.
- 10:52
Um, and once, uh, again, uh, whether the field is required and the field dependencies. Here is where you define what sort of like dependencies this field have and sort of validations, right?
- 11:02
So this is how they set up the extraction. The next thing is the document management itself. So this is where the documents are ingested, uh, from the, uh, the data platform.
- 11:12
They are tagged according to the business category, uh, and they are labeled, they are embedded, all of that stuff.
- 11:19
Okay. While-- I think while, uh, Vaibhav kind of brings it up. So I think, uh, what-- in essence, what we are saying is we have kind of built this tool which has like a UI component and like a framework that actually lets you take these different pieces and these modular components and give it to the hands of
- 11:33
like the domain expert to build out their app really quickly, right?
- 11:38
Look, uh, I think something-
- 11:40
Yeah
- 11:40
... happened it just saying. So let me just sort of walk you guys the-- what happens next. Um, so like once you have set up the extraction templates and document set management, the operators basically run the extractions.
- 11:50
That's where they basically see the values that they expect from these documents and sort of like review them. Uh, the thing with-- we have seen with these operators trying to use other tools, uh...
- 12:02
No, this is the same. Um- Yeah, I do. Uh, the thing we have seen, uh, with these operators is that most of the tools, tools that they have used in past, uh, these tools basically does extraction.
- 12:14
Uh, they, they, they do a particular job at extraction. But when it comes to like, uh, "Hey, I need to now use this result that has been, uh, sh- presented to me and pass it to the downstream processes," the process right now is very manual, where they have to like download a CSV or a JSON file, do--
- 12:29
run manual or ad hoc transformation, and then push it to the downstream process. So what we have done, and again I can show you, but what we have done is like build this sort of like lo- low-code, no-code framework where the operators can basically essentially, uh, run the, uh, sort of build this transformation and execution workflows and,
- 12:50
uh, sort of like have this end-to-end, uh, pipeline running. Uh, and-
- 12:55
I, I think, yeah. So I think we'll conclude by saying that our key takeaways of this, right? I would say there are like three key takeaways. Invest heavily on your like prompt engineering skills for your domain experts, especially in like the financial space and world.
- 13:07
Uh, defining and describing these documents is really hard, right? Uh, second is like educating the firm and the company on what an LLM strategy means, uh, and how to actually fix these different pieces for your particular use case.
- 13:19
And I think the third one I would say is, hey, uh, the key takeaway that we had is all of this is great in experimentation and prototyping mode, but if you kind of want to bring this, you have to really evaluate what your ROI is.
- 13:30
And as-- Is it gonna be like more expensive actually spinning up an AI app versus just having like an off-the-shelf, uh, product that does it quicker and faster, right?
- 13:38
So those are the three key takeaways in terms of like, uh, building apps at scale. And what we realized was like, hey, uh, this notion of like human in the loop.
- 13:48
And the one more thing I'll add is human in the loop, super important, right? We all are like really tempted, like let's go all agentic with this. Uh, but in the financial space with compliance, with regulations, you kind of need those four eyes check, and you kind of need the human in the loop.
- 14:01
So design for human in the loop first, uh, if you're in a highly regulated environment.
- 14:05
Yeah. And as Infant said, one thing we couldn't show is the whole app factory sort of like, uh, component, which is all the things that operators do through this iteration cycle of through the sandbox.
- 14:16
They take all that knowledge, the extraction templates, the transform it-- transformers, and executors to build through this workflow pipeline. And through our app, uh, ecosystem within, uh, BlackRock, they sort of like build this, uh, custom applications that are then exposed to the users, where users of this app don't have to worry about how to configure templates or
- 14:36
how to basically figure out how to integrate the result values into final downstream processes. They are presented with this whole end-to-end app, where they can just go and like sort of like-
- 14:45
Yeah
- 14:45
... upload documents and run extraction and sort of, uh, get the whole pipeline set, uh, running.
- 14:51
Yeah. With that, we'll open up for questions. I think we have like a minute or two left.
- 14:55
Yeah.
- 14:55
Yeah. Um, so I have a question which may directly be related to...
- 15:08
Good morning.
- 15:09
Morning.
- 15:10
I have a question which may directly be related to the, uh, architecture that you developed.
- 15:17
Okay.
- 15:18
You can tell me, I can discuss later. But the question is going to be,
- 15:23
y- you have developed, uh, um, the key takeaways. One of those key takeaways had been in invest heavily on prompt engineering. So you have essentially automated the process from the leaf level.
- 15:41
For example, a company's coming to an IPO from that level all the way to cataloging through ETL processes, and then to finally to the data analytics. So now your CEO, who looks at the balance sheet assets and liability, will be using your AI the most.
- 16:05
And for C-- uh, your CEO, now what are the features involved here at the lowest level? For example, term, maturity, duration.
- 16:16
Yeah.
- 16:16
There are so many metrics at the leaf level. How are you transforming those features from the lowest level to highest level? I'm looking for an answer in reference to decentralized data-
- 16:30
Yeah
- 16:30
... or-
- 16:31
I mean, I, I can give you a quick answer, and then we can discuss, uh, in detail like, uh, offline. I think, uh, real quickly, like the, the framework that we built was specifically targeting like the investment operation domain experts who are trying to build applications.
- 16:43
To your question of like, "Hey, what does the CEO care about? Can I construct a memo that gives me my asset liabilities XYZ?" Uh, those would be like different initiatives which may or may not use our particular framework.
- 16:54
Thank you.
- 16:54
Um, but, uh, yes, there are many reusable components in here that people can use. Yeah.
- 17:00
So I kind of wonder, you know, for something similar for each problem.
- 17:11
Yeah. So I do like a lot of document processing for insurance company, pretty much same problems as you guys run into. So I wonder, how do you build a walls around your information extraction from the documents, right?
- 17:22
Because there are so many things that can go wrong, starting from a CR.
- 17:26
Yeah.
- 17:26
Like LLM doesn't understand what all these terms actually mean, no matter how you prompt it, right? All this stuff.
- 17:32
And I think-
- 17:33
So that's kind of what's-
- 17:34
Yeah
- 17:34
... what the reason.
- 17:34
Again, I mean, we had all of that that we wanted to show, but yeah. So it's, uh-
- 17:39
I mean, I think a short answer-
- 17:40
But I can... Yeah
- 17:40
... short answer to your question is in terms of like information security and what are the boundaries, uh, that we are putting in terms of like, hey, we are not having data leakage or errors or understanding of...
- 17:50
Like, in terms of security, you can think of it as different layers, all the way from like your infra, platform, application, right, and the user levels. There are different controls and policies in place, uh, and it's also within your SD network.
- 18:03
Like, I think there are policies across the stack that we can get into in detail later that kind of, uh, addresses your, um, concerns. Yeah.
- 18:10
And also, also to your point, um, I think we have like different sort of like, uh, strategies that we use based on, uh, the sort of like the use case at hand.
- 18:20
Uh, so it's not just like, hey, one RAG versus this. There are multiple model providers that we use, uh, multiple different strategies, et cetera, uh, different like, like engineering sort of tweaks.
- 18:31
Uh, so it's a quite complex sort of, yeah, process.
- 18:35
All right, very cool.
- 18:36
Awesome.
- 18:36
Thank you. All right. [audience applauding] [outro music]