COLMAN MADDEN: Hi, everyone.
My name is Colman Madden, and I'm
an engineer with Google Cloud in New York focused
on asset management in the hedge fund industry.
Prior to Google, I spent around 10 years working
in the data engineering space.
I'm also here with David Li from BlackRock,
whom I've been collaborating with since early 2019.
David, over to you.
DAVID LI: Thank you, Colman.
Hi, my name is David.
I work in the financial modeling group at BlackRock.
The group consists of a team of engineers, modelers,
and researchers working together to develop best
in class analytics to clients.
Today's agenda is as follows.
I'll first introduce what we do at BlackRock,
then present two use cases of how
we generate signals using natural language
processing on Google Cloud.
First, I'll talk a little bit about how
we train against returns to construct a bespoke dictionary
to analyze sentiment for single issuers
in the structured credit space.
Second, I'll talk about knowledge graphs and entity
linking, and about how we trained an entity linking model
to build a foundation for constructing knowledge graphs.
In addition, I'll talk about some use
cases for these concepts.
Colman will then conclude with forward-looking views
of how to conduct investment research on Google
Cloud in the future.
I lead a team inside FMG called advanced data analytics.
Our responsibilities span engineering,
financial modeling, and natural language processing.
For data engineering, we process data
sets that are terabytes in size to extract insight
by leveraging big data technologies such as Spark.
Some of our work have been previously presented
at Spark Summit East.
We also leverage managed services
provided by public clouds.
Our goal is to efficiently deliver data driven solutions
to our clients.
As a team, we have a wide range of skills
and provide flexible, end to end solutions to streamline
future engineering, the building of financial models,
and productionization.
Our approach to natural language processing is a little bit more
focused on research.
We pay a lot of attention to recent developments
in the applications of text classification,
information extraction, and entity linking in an NLP space.
The first use case is classifying text
in a structured credit market.
In the past decade or so, the leveraged loans market size
has been increasing.
Also, due to private nature of these investments, publicly
available structured data sets may be common, but sparse.
Taking a bottoms-up approach, we analyze credit
at the issuer level.
We aim to tackle the problem with future engineering
to add more insight to the model, which
is to look at issuer defaults and measure probability
of default from an issuer.
At the beginning of the year, the US leveraged loans market
was around $1.2 trillion.
More than half of that is the US collateralized loan obligations
market, which is close to $700 billion.
In the past two years, we've seen
record issuances of close to $120 billion per year
in 2018 and 2019.
This increased market size, coupled
with companies assuming more debt,
give rise to additional risk in the market.
At the same time, risks are becoming increasingly difficult
to capture.
For example, environmental changes such as COVID
had significant impacts to the competitive landscape
in multiple sectors such as retail.
As the political landscape and regulatory oversight changes
over time, companies are exposed to increased uncertainty.
Additionally, they're also held to higher standards.
Companies are now facing mounting pressure
on environmental, social, and governance.
In order to address these issues and capture
additional information from alternative data sets,
we turn to natural language processing.
We analyze large volumes of textual news via NLP
to classify text into sentiment scores
as well as other metrics such as news volume and emotions
in these articles.
Some of the challenges in predicting issuer probability
of default, or PD, over some time horizon are,
first, it's typically difficult to find structured data
on issuers due to their private nature.
In these instances of where data is actually available,
it can still be subject to sparcity,
such as pricing data, due to these instruments lacking
in liquidity.
Trying to apply NLP to this problem,
available news corpora are typically
at least terabytes in size, and can easily exceed petabytes
across multiple periods.
Given these, we need both persistence and compute
resources to be flexible, whereas they typically
are constrained in a fixed computation farm.
Thus we need a flexible environment
to iterate and test our ideas so we can extract and classify
text for predicting probability of default.
Let's take a look at the modeling process here.
First, we start off with loading the data.
Then we apply transformations such as tokenization stemming,
named entity recognition, and sometimes even
applying language models to reason
about text in the embedding space.
Then we align unstructured text with structured data sets
such as returns or spreads.
This step has to be done carefully
to match market open and close times as well
as time zones, and ways to deduplicate articles that
discuss the exact same thing.
Once this is done, we query the data stored and train
and evaluate our ideas by tuning our hyperparameters
and finding thresholds to construct
an optimal bespoke sentiment dictionary.
Then we intuitively roll this dictionary
across time for inference.
This process has proven to be quite straightforward on Google
Cloud.
We start off by persisting various stages of our data
to Cloud Storage, which is a highly available distributed
store that gives us plenty of scratch areas
to test our ideas.
Then we provision Dataproc clusters with GCloud
in Cloud Console.
This provides us with an ephemeral Hadoop Spark compute
cluster across our large data sets.
An auto-scaling policy and preemptible machines
are your best friend when managing these clusters.
Recent metrics demonstrate that Spark 3 performance
on Kubernetes is catching up to YARN.
This is good news as we could then potentially
switch to Spark operators in the future.
After that, we leverage BigQuery to run analytical workloads
and extract and filter relevant information.
BigQuery has similar functions as Hive,
storing metadata on [INAUDIBLE] Compute Engine.
However for BigQuery, there's no tuning or configuration
involved.
It automagically handles your workloads
and produces results quickly.
Finally, we use AI notebooks and Cloud Storage
as a combination to iterate over our training and evaluation
cycle.
These managed notebooks give us the flexibility
to scale our resources up and down through configuration
changes.
Usually operating on premise, we need
to be very careful about resource consumption as well
as capacity planning due to the multi-tenancy nature
of our shared compute clusters.
Typically, a single ETF job that we've previously done
can take up to about an hour when we have thousands
of these jobs running.
On Google Cloud, after carefully configuring our setup,
we're able to compact that time per iteration
down to two hours for the entire data set.
Armed with scalability and flexibility
to change the cluster size as well as the type of cluster,
we can iterate on multiple tests and focus
more of our time on ideation and modeling
as opposed to worrying about whether we're consuming
too much compute resources.
Some lessons we learned during this exercise--
Spark, the de facto open source big data processing tool,
is great for ETL on disk I/O intensive jobs.
For large-scale optimization calculations--
not so much.
We turn to distributed compute frameworks such as Dask and Ray
for parallelizing these optimization tasks
to optimize our runtime--
or to minimize our runtime.
Let's switch gears to our second topic.
This one is more exploratory in nature
and has received increased attention in the past few years
in the research community.
We explore the applications of entity linking and knowledge
graphs in the equity space.
We want to extract information from the correct securities.
Moreover, we want to track and identify
relationships between entities.
So we need entity linking to map text
to an entity in some knowledge base.
Some examples of applications are extracting and analyzing
supply chain impacts to companies, revenues,
and expenses.
Think of Foxconn manufacturing iPhones.
Additionally, Samsung is a supplier of screens for Apple.
Therefore, understanding correlation
of performance between companies due to their sheer dependencies
on the same suppliers help us better
build equity risk models.
Similarly, we can analyze corporate structure
such as ownership in subsidiaries.
And here we define ownership kind of loosely.
We analyze this to gain insight how performance of one company
affects another.
Lastly, we were talking about ESG before.
Creating models and measuring corporate governance can
be aided with calculating the diversity of boards, experience
and expertise of board members, and how a member's track
record may affect the company performance that they sit on.
On the right-hand side, you can see a snapshot
of a personal knowledge graph.
It shows the ownership relations of BlackRock as well as Google.
And the two companies are connected
through Alphabet, which is the parent company of Google,
and in which BlackRock owns shares.
To construct a knowledge graph, a fundamental step
is to look at the problem of entity linking or EL.
Here's a simple example given a sentence,
"Larry, whom we as the chairman and CEO of BlackRock,
said, at the beginning of the year,
that BlackRock would place sustainability
at the center of the investment approach at the firm."
In this example, it's relatively easy for humans
to understand that "Larry" refers to Laurence T. Fink, who
is the CEO of BlackRock.
And BlackRock is the investment management company.
For a model, the difficulty lies in training a system that
can correctly link text bands to entities
that live in some knowledge base such as Wikipedia.
The objective of ELs is as following.
Give it a piece of text recognized as [INAUDIBLE]
and link entities to an entry defined in some knowledge base.
We use BERT as our language model--
BERT was developed by Google AI in 2018--
and a knowledge base that's a mix of Wikipedia other sources.
In this case, we use Iago.
Our task is to detect mentions and disambiguate entities.
Looking at this problem, we need to provision resources
that can scale with our workload,
namely, deliver us GPUs for training
of large neural networks.
The productionization process of these models
have typically been complex.
And we show how we can use Google Cloud to achieve this.
Looking at the following high-level architecture,
we can see that connecting BlackRock and Google
networks through interconnect and keeping
the traffic between the data centers is a good way to start.
With a remote interpreter on a virtual machine instance
on Compute Engine, we're able to test
different types of configurations of GPUs and TPUs
and tune them for training.
We then set up a request server to run
evaluation on a local machine, and then forward the port.
Lastly, we deploy our models through TensorFlow serving
to expose the entity linking model to clients through an API
through cloud endpoints.
This end to end approach allowed us
to quickly iterate, and train our models,
and minimize the deployment time of our models to production.
Next, I'll hand it over to Colman
to give a forward-looking view of investment research
at Google Cloud.
COLMAN MADDEN: Thanks, David.
So David covered two great use cases
where his team has been leveraging GCP at BlackRock.
And I wanted to talk a little bit more
broadly on how the investment industry is
partnering with Google Cloud.
I don't think it's any secret that the buy side is becoming
increasingly dependent on data and AI
to power investment decisions.
And you'll see that by looking at some of the statistics
here on the right-hand side of the slide.
At Google Cloud, we believe this aligns
really well with our powerful analytics platform and the AI
research coming out of Google Brain,
which we provide to our customers
through our Cloud platform.
Why don't we start by looking at a typical investment decision
flow for a buy side firm.
So firstly, formulate an investment idea.
Source data to prove out that hypothesis.
Generate signals from the data.
Construct the portfolio.
Backtest the portfolio.
Present the findings.
And determine a capital allocation
from an investment committee before moving into production.
The blue box highlights the stages of process
we feel are a great fit for Google Cloud.
So why run investment research on Google Cloud?
Firstly, to provide the ability for investing teams to spin up
projects quickly and react to events
in the market in an agile fashion.
Two, streamline the onboarding of new data sets
from commercial data vendors, such as Refinitiv and CME Group
through our data marketplace.
Three, burst compute workloads into the cloud,
and eliminate resource contention
from on-prem compute firms.
Four, get access to the latest AI research through our APIs
and managed services.
And five, orchestrate your ML workflows with state-of-the-art
DevOps and MLOps platform.
So how do we do all this on Google Cloud?
Here's the high-level architecture
of how firms are running an investment research on GCP.
We start off by looking at the blue box.
This is our data acquisition project
where the data engineering teams onboard
various data sets such as market, portfolio,
news data, et cetera.
And if we look at the green and yellow boxes below,
this is where the research teams are using their tools
to access the data sets above.
We understand there's often a wall
between different investment teams.
And we can implement this using our identity and access
management tools while still allowing access
to shared resources such as ticket stream.
So let's dive into the GCP products
that sit behind these boxes.
In the data acquisition project, we
can ingest streaming data via our PubSub message queue,
or land files in Google Cloud Storage,
trigger load jobs into BigQuery or NoOps data warehouse.
Dataflow and Dataproc are available for ETL.
We're also seeing a lot of customers moving to an ELT
architecture where they load the data as quickly as possible
and then use the power of BigQuery to actually do
that transformation using AntiSQL.
The data marketplace allows data publishers,
aggregators to share their data sets with financial firms
without the need for any ETL.
This is extremely valuable, as data sets are often
in the petabytes.
You may have seen we just announced BigQuery Omni, which
will enable firms to query the data on AWS or Azure
from a single interface without any cross-cloud movement
of our copies of data.
We push the compute to the data.
In the research projects, quantitative researchers
can run simulations on HPC clusters
with hundreds of thousands of cores, custom VMs
that perfect the ratio of cores to memory.
If your workflow can handle preemptions and needs
to run for less than 24 hours, preemptible VMs
allow you to do this at an 80% discount.
We just launched confidential VMs,
which allow you to encrypt data during processing,
and even when it's in memory.
So moving to the right, our Cloud AI platform
allows quantitative researchers to create AI notebooks
with the latest TensorFlow, PyTorch,
and scikit-learn images on CPUs, GPUs, or TPUs,
and pull this data-- these data sets straight
into Pandas DataFrames.
AutoML allows you to create machine learning models
for natural language, structured data translation without having
to write any code.
These models can be trained to understand
terminology that is specific to the financial services
industry.
Our Document AI solutions enable you
to process complex financial filings and earnings
reports with cutting-edge NLP and transfer
learning technologies.
AI pipelines is built on top of Kubeflow and TFX
and provides an MLOps solution to evaluate, train, and deploy
machine learning models to production.
These models can be shared with other research teams
through AI Hub.
One really important thing to note
here is that this is all deployed by infrastructure
as code using something like deployment manager or terraform
scripts.
So how do you get started?
So step one, you want to get the cloud foundations in place.
Understand your requirements around networking, security,
access management.
Wrap these up in infrastructure as code.
And feed these into your project creation pipeline.
Secondly, you want to understand the process for onboarding
new data sets and build a data acquisition
pipeline to automate this.
Thirdly, understand what tools your researchers need,
and automate the deployment of these tools,
along with the connectivity they need
to access the data required to run their experiments.
We want to make life easier for everyone.
Thank you for coming along to our talk today.
Please add any questions to Dory.
Or feel free to reach out to me or David directly.