Activating Alpha Generation With Multi Agent AI for Fund Screening

Summary

LSEG leverages the Databricks Data and AI platform to orchestrate multi-agent AI over the Lipper fund dataset of more than 350,000 investments across 80 countries and 40 years of history, enabling natural language fund screening that reduces analyst research time from hours to minutes.
The architecture uses a multi-agent supervisor to route complex queries to specialized Genie Spaces — Fund Universe, Performance and Risk, and Flows — rather than a single space, because different query types require different data contexts and semantics.
A key insight from building this system is that AI quality on complex financial data depends less on prompt engineering and more on how well the data semantics and orchestration are structured, with Delta Sharing used to deliver AI-ready Lipper data to customer Databricks accounts.

Activating Alpha Generation With Multi Agent AI for Fund Screening

Investment professionals currently spend 12 hours weekly on manual fund screening, leading to operational inefficiencies and lost alpha opportunities. LSEG is leveraging Databricks to orchestrate Genie Spaces across the Lipper fund dataset of 350,000+ investments. Our solution enables users to perform complex fund screening using natural language. By employing a multi-agent supervisor to coordinate specialized Genie Spaces—such as Fund Universe, Performance & Risk, and Flows—users can execute queries like “UK equity funds with 3-year annualized return, 8% and AUM, 500m” against Lipper APIs and tables. This architecture streamlines the workflow sequence from report generation to portfolio optimization, allowing portfolio managers and analysts to identify investment strategies in minutes rather than hours. By leveraging Databricks Multi Agent Supervisor and LSEG’s trusted AI-ready data, firms can significantly reduce operational costs and improve decision-making efficiency.
Talk By: Adam Towne, Director of Product, LSEG ;

Chapters

FAQs

What is LSEG Lipper and why is it well suited for AI-powered querying?

Lipper is LSEG's global fund intelligence platform covering mutual funds and ETFs across more than 80 countries with over 40 years of performance history. Its scale and complexity — hundreds of thousands of funds with rich analytical time-series data — make it well suited for AI-powered natural language querying, though the complexity also demands careful data structuring and semantic alignment rather than simple prompting.

Why did LSEG use multiple Genie Spaces instead of a single one?

A single Genie Space cannot handle all fund query types effectively because different queries — such as universe filtering, performance analysis, and fund flows — each require specialized data contexts and semantics. A multi-agent supervisor routes each incoming query to the most appropriate specialized Genie Space, allowing each space to remain focused and reliable.

How does Delta Sharing connect Lipper data to customer Databricks accounts?

LSEG standardizes Lipper data on Databricks and uses Delta Sharing as a zero-copy mechanism to deliver analytics-ready fund data directly into customer Databricks environments. This eliminates the need for customers to build custom ingestion pipelines or recreate data plumbing, and advances the product from a raw data feed to an AI-ready data offering.

What did LSEG learn about building reliable AI on complex financial data?

The team found that AI quality depends far more on how data semantics and orchestration are structured than on clever prompting — tuning the data rather than the model proved to be the more effective lever. They also used MLflow to evaluate and continuously improve agent quality, and found that iterating on Genie Space design was essential to handling the variety of financial queries their users submitted.

Full transcript

[00:08] Thank you. All right, so the normal forward-looking disclosure disclosure slide. Uh go beyond that. Also, please complete your surveys at the end of the talk. Um
[00:20] they're available inside your Databricks app. So, my name's Adam Town uh from LSEG. I lead Lipper, our global fund intelligence platform, as well as cloud distribution for the analytics business.
[00:34] Today, I want to talk about what it takes to make AI work on complex financial data. The important part of the story is not just we put an LLM on top of financial data, right? Everybody's doing that. The important part is what we had to change
[00:47] underneath the model to make the experience reliable. It's actually a lot of the same things you've been hearing about for the past couple days. We didn't have the pleasure of using Genie ontology or some of those other structures, but we did make heavy use of Genie spaces to segment the data
[01:00] and make it easier for us to build reliable agents. You know, for complex financial data, the quality of the AI depends a lot less on clever prompting and more on how well the data, semantics, and the orchestration are
[01:13] structured. So, first a little context. Lipper is LSEG's global fund intelligence platform. It covers both mutual funds and ETFs with fund classifications, ratings, performance data, benchmarks, and a long
[01:26] historical time series. The reason this matters for AI is the scale and complexity. We're not talking about a small demo's data set or a toy problem. We're talking about hundreds of thousands of funds and
[01:38] share classes across more than 80 countries with more than 40 years of performance history. This creates a very rich analytical surface, but it also creates a challenge. A user asks a simple question in natural
[01:51] language. There may be a lot of financial meaning hidden inside that question. So, our product has evolved in three stages. The original model, which we've had for 30 semi years, is the data feed.
[02:05] Right, clients had maximum flexibility, but they had to build the pipelines, the schemas, and the tooling themselves. Uh last year, we put our content onto Databricks and started with the data warehouse model. Um
[02:17] that's where Databricks becomes important, and we use Delta Sharing as a mechanism to get this content to our customers. We standardized the data and made it analytics ready. So, customers can get the value of the data without having to recreate all the
[02:30] plumbing. And the third stage, and where we're at now, is AI-ready data. It's not just tables, right? It's the semantic definitions, identifier resolutions, AI-optimized views, and data structures designed so that natural
[02:43] language systems can reason over them easily. So, Lipper data, it turned out, was actually pretty well structured for AI uh from the beginning.
[02:55] Um there's really four key reasons. So, the first is that in financial data, we uh resolving the same fund or share class across identifiers is one of the toughest challenges, and Lipper has robust identifiers across every market
[03:09] in which we operate. Second is a taxonomy. So, Lipper has a very specific taxonomy. We don't just say equity fund, um but we have asset class, geography, strategy, style, and hierarchy. A really rich taxonomy for
[03:22] the model to work with. Third, history. The model has decades of performance context, which means when you're talking about things like similarity, it can go across lots of different regimes to understand why might something be similar to something
[03:35] else. And fourth, the entities are modeled in a structured way. Fund share classes, benchmarks, and currencies are modeled the way that financial professionals think about them.
[03:51] So, even though it was easy to start with, we did run into three major failure modes. Once we started testing natural language queries, some of it fell down. The first was the performance at scale. The model had access to too many tables.
[04:05] Latency and reliability degraded. It wasn't just that you might get back a bad answer. Very often you did not get back an answer at all. And so what we did was to create purpose-built views that were optimized
[04:19] to minimize joins in places where they weren't needed, so the agent had less area to worry about. The second was query routing. Uh different questions required different data domains.
[04:32] A profile question, a performance question, classification question, right, should not all be handled the same way. And the solution there was to use segmented genie spaces by data domain.
[04:44] And the third was the gap between metadata and semantics. So we thought we had some really great semantics. What we had was a great data dictionary, right? It told you what a column meant, but it did not necessarily tell you how a financial professional interpreted that column in
[04:58] context. I think that's been a lot of what we've been talking about over the past couple days, right? How do you im- put put that context into practice that you can take advantage of it?
[05:14] So, this is what we built fundamentally. We're at the very simplified version of the architecture. So the user asks a natural language question. We route that question to the right genie space. Each genie space owns a specific domain, just a profile or
[05:28] performance. And underneath that, Unity Catalog has its governance, lineage, access controls, column level and column level metadata. And the semantic layer has the financial interpretation, taxonomy, standardized answers, joins, business logic, right,
[05:42] all those things you need to produce consistent responses. Internally today we use this for our own natural language fund screening, for cross fund performance comparison, and we are experimenting with AI generated
[05:54] fact sheets based on the types of comparisons users need to do. Bind them together. So, I'm going to do a quick demo. Uh this demo is going to be a video.
[06:06] The reason it's a video is because right now this process takes up 4 minutes to run. I'm not going to make you sit here for 4 minutes, although this will take about a minute. This is still five times faster than what analysts are doing today to build this content.
[06:20] So, when you watch it, just think about three things. Right, first the user's not writing in SQL, which is pretty much table stakes at this point. Second, the question is routed the right analytical domains. And third, the answer is dependent on
[06:32] the structured financial meeting. Right, the question I ask is very simple, but has quite a lot underneath it. So, in this case I'm actually running in cloud.
[06:44] I'm using a hosted MCP on Databricks. Right. And so, this means you can run this anywhere. Right, Databricks is the MCP server and I'm just in cloud. Now, I'm investing in a State Street S&P 500 ETF.
[06:57] And I want higher performance and lower fees. Right, who doesn't want those things? Um and this is going to give me back a table with the expense ratio and then one, three, and five year returns. Right, so what we believe you should look at,
[07:10] right, when you are trying to evaluate this question. Claude will also give me back some friendly advice. Right, or friendly doesn't call it advice. Friendly things that you should know. Things like tax
[07:22] implications, things like you may not have access to certain funds depending on your brokerage account. Right, information that it has gleaned from the internet and that it combines with our structured data to give you a meaningful answer.
[07:35] Right, so as I said before, this would have ordinarily taken 4 minutes. Right, but still five times faster than the 20 minutes that people are working on this today. And with things like AI, right, that's
[07:47] the slowest it's ever going to be. Right, as the foundation models get better, as Genie spaces get faster, right, all these things will come together to make this an instantaneous process. Customers will be able to save hundreds of hours a month at their firms and make
[08:00] better decisions in a controlled, governed, and repeatable way. So now I'm going to get into some of the details and actually show you the anatomy of this query in ML flow.
[08:13] Right, so this is the anatomy of the query. Uh it's the same query we looked at just now in the demo. And here I'm in ML flow in the Databricks platform. So in blue are the LM calls and then in red are the tool calls for those of you
[08:26] unfamiliar with ML flow. Right, so the first LM call actually creates the plan. And the system evaluate executes evaluates executes again and continues until it has enough information to
[08:38] answer the question. And in fact, it goes a little further than the the slide here. We it's it goes on for a little bit of time. And you can see, right, that it goes to Genie spaces and it may return to those same Genie spaces again. Right, it's not
[08:50] one shotting it. It's really thinking and saying, "Okay, I need to actually come back and get more information because I am dissatisfied with the answer in the set." And there's two things I want to highlight.
[09:02] So actually a lot of this agent is orchestration, right? We home built the orchestration on top of Databricks. We start with Agent Bricks. We decided that we wanted to do a little more fine-tuning than was available at the time. And so we built our own orchestrator on top, which is quite easy
[09:14] to do and run. And second, the system actually identifies its own blind spots. So places where it's uncertain or it's had to make compromises in generating the answer. And that feeds it back to us. Right, so
[09:26] it says, "Okay, we don't have a five-year return for these two things. I'm going to let inform you, right, that I'm making a compromise decision. Is that okay with you or not?" And it feeds it to us and it also feeds it back to the customer within Cloudera
[09:40] other uh clients. So, we really learned three things from this process, right? The first was that LLM architecture is really still an open
[09:52] design space, right? I think before LLMs, a lot of architecture was relatively well understood. You had established patterns. Uh and with agents, the coupling decisions are a lot less clear and still
[10:04] rapidly evolving, right? I think it's a lot more fun, but it's a lot more challenging to find where the right place to end up is in the middle. At one extreme, you can have one giant genie space or one mega prompt or one
[10:16] model trying to do everything, right? Your classic monolithic architecture. At the other extreme, you can segment by domain or use routing logic or use different models or prompts
[10:28] for different steps. It's much more loosely coupled. You get more control, but you need to handle that with more orchestration. Right? So, our answer was of course somewhere in the middle as most things
[10:40] are in life, right? So, we didn't make everything modular for its own sake. We really invested in robust routing architecture and the segmentation of the genie spaces to make this possible.
[10:53] The other thing is that I think a lot of people think a bit in pipelines, right? We're data engineers, we love DAGs. Unfortunately, life is not a DAG, right? So, you know, you may ask a question, the model queries, model answers, but that's not all it's doing.
[11:05] Right? When you're doing real research, when you're really thinking, you don't work that way, right? You're researching a fund. You don't go in a straight line. You ask a question. You get back the answer. You reassess. You want to ask the question again in a different way or if you're satisfied
[11:18] with the content. And we're doing the same thing inside the orchestrator. It's evaluating the results and determining if it's satisfied, if it's created a high-caliber answer that a fund manager would actually want to read and see.
[11:33] And this only really works because the spaces are constrained, right? If you have to keep going back to these super wide spaces, the system just falls down, right? You you have to constrain the space in which you're working and give it really targeted ways of thinking about the problems across those spaces.
[11:50] And finally, and I think you probably heard this a lot, but you know, I made this before the the the presentations, you know, the past couple days, but tune the data not the model. Um the instinct with AI is very often to
[12:02] tune the prompt or tune the model. Uh but most of the failure modes were not actually model problems. They were data problems in disguise. And very often, right, the field definitions needed to be more descriptive. The joins didn't really understand why
[12:15] they needed to be joined that way. And I talk about them like they're people cuz they're kind of people, right? You're starting to think, does it understand why it's doing what it's doing? If it doesn't, it's not going to work. Business logic wasn't really explicit enough in certain cases.
[12:28] Um the sample queries might be missing, right, for trickier questions. And so we'd see, okay, it would fail there. We'd make a new sample query, and it'll find patterns from those samples. Very often, the views were too broad or
[12:40] sometimes too constrained. And so we really moved that effort into the data layer. Uh we improved the semantic definitions. Uh we uh the column descriptions, the
[12:52] joins, right, the filters, we built purpose-built views, and we built lightweight genie space instructions that are much smaller than what you'd see in a traditional like Uber prompt.
[13:04] Right, it made the system better without fine-tuning. Uh and the the model results improved because the data improved. You know, what we found was that as we were inputting more into the prompts, we
[13:16] were not solving problems, we're just creating new problems, right? It's very fragile and brittle. Uh so, you know, focusing on the context really did pay off for us.
[13:31] So, there's really three takeaways, right? So, first, you know, the iteration mattered. Um we did not design the perfect architecture up front. We in fact started with a single monolithic Genie space, then we started to realize the places where that failed, then we separated things, we tried agent bricks,
[13:44] we tried routing, we tried all manner of different things before we settled on the architecture that works for this class of problem. Right, we tested these real queries. We found where they were failing, and we updated everything in response to
[13:56] that. The second was that Genie spaces made the routing a viable strategy. Um they really were easy to use. If you have not tried it, I encourage you to do so. It is an incredibly simple place to start,
[14:09] and you don't even really need to be an engineer to start using them. It's really you can really set it up and just try it out for yourself. You'll see those performance improvements.
[14:22] And finally, right, tune the data, not the model. Semantic modeling much mattered much more for this use case than uh than the actual uh prompting did. The last thing is really the right the frontier labs are spending a tremendous
[14:36] amount of money improving their models. They're spending zero dollars improving your data for you, right? So, if you just got to think long term, right? They will get better. The context windows will increase. All these things will improve over time.
[14:49] So, you need to make the investment in the place that's going to have the highest leverage for you, right? Which is your data foundation, and take advantage of the secular trends that are fixing other parts of the process.
[15:04] So, last slide. Um So, I'd be doing my job poorly if I didn't include a small uh pitch for Lipper. Um So, Lipper has excellent data and ratings. Uh we have people here who would love to
[15:16] talk to you about Lipper or the broader LSEG offering. Many of them are located in booth 155, Some are in the front row. Um you know, and I think importantly, you know, by building an AI fund screener, we didn't
[15:28] actually end up building just one product. We built two products, right? So, you can get the fund screener via MCP, but you also can just get the data, right? AI-ready, cleaned up, intelligent, you know, designed for
[15:41] Genie spaces. And so, you can combine that with your own content in your own Databricks account, right? And take advantage of it. And I think that if you talk to a lot of providers over the course of, you know, these 3 days,
[15:53] you'll find that we're they're probably all learning the same things. That as you improve the data for your own usage, you are able to improve it for your customers as well, and you cannot do one without the other. Thank you.
[16:06] >>

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.