By Convequity in PLTR — Mar 31, 2024

Updates: PLTR – The LLM Enabler For Enterprise (Pt.2)

Summary

AIP is PLTR's catalyst to roaring success, though in reality this was a low bar innovation by them.
AIP takes the limelight, but as we have been saying since January 2021, it is the ontology that is the key to successful LLM implementation.
We also compare PLTR to SNOW, MNDY, and next-gen GenAI startups, to further highlight PLTR's differentiation.
To illuminate PLTR's depth and breadth, we provide a full open-source data stack alternative to using PLTR, and discuss the benefits of each.
We discuss the success of AIP to date, in large part, thanks to the innovative bootcamps GTM. Lastly, we provide a valuation with commentary.

PLTR’s Core Competitive Advantage

Last August we published Updates: PLTR 2Q23 - The LLM Enabler For Enterprises, which we have retrospectively named as Part 1. The title sums it up very concisely, which is why we’ve used it again for this PLTR update. In essence, LLMs are great but for them to deliver a competitive edge to an enterprise, they need to be connected to the enterprise’s entire estate of data. ChatGPT and Claude etc., are great for queries that can be answered from information in the public domain, as they have been trained on publicly available datasets and the Internet at large. Though, to use such closed-source (e.g., ChatGPT, Claude), or open-source (e.g., Llama, Mistral), LLMs to query and retrieve information specific to the enterprise, they need to be connected to, and trained on, the enterprise’s data.

It is this plumbing that is currently the most challenging aspect of making a LLM effective for an enterprise. Though, it’s not as easy as simply connecting the LLM to the enterprise’s data. The first obstacle is that, typically, an enterprise’s data estate is segmented into numerous data siloes, in which it is impossible to train an LLM upon.

But assuming an enterprise does have the engineering talent to migrate all of its data into a centralized data lake or data warehouse – which is a big assumption – the respective datasets will retain their unique vocabulary, limiting the interoperability across datasets. Thus, it makes it challenging for a LLM to learn effectively.

As we shared in the retrospectively named Part 1, this is equivalent to an 18-year-old, after having graduated from high school (thereby having acquired broad, general knowledge, akin to a LLM like ChatGPT), begins work life as an apprentice for an electrical contractor (thereby now aiming to develop domain-specific knowledge, akin to a LLM implemented in an enterprise). However, he/she has three mentors, each of which refer to the tools, methods, and concepts of the trade with different terminologies (vocabularies), drastically confusing and slowing down his/her learning progress. To continue the analogy for a moment longer, now imagine the same 18-year-old joining an electrical contractor where each mentor uses the exact same terminology for describing things – the apprentice’s learning progress would be far greater and they would be far more effective at the job.

Hence, a LLM will be orders of magnitude more effective if it is trained on data that shares a common vocabulary – even better, the language of the business – and in technical terms this is referred to as an ontology.

The success of LLMs like ChatGPT is derived from the Internet’s own ontologies. Ontologies, such as RDF, OWL, GoodRelations, and FOAF, have been instrumental in making the Internet what it is today. Without these ontologies, we wouldn’t be able to access the full Internet nor access certain web pages on a website, or we would be able to access certain web pages but see illegible/scrambled content. Though, thankfully, the Internet is built on such ontologies that makes user access seamless.

But it’s not just great user experiences that the Internet ontologies have cultivated. If we circle back to the apprentice example for a moment again, ChatGPT has achieved such a high level of intelligence thanks to the ontologies underlying the Internet in which has been trained on (as well as initiatives like the Common Crawl project). Just like the three mentors in the apprentice example, each communicating with the apprentice with the same vocabulary/terminology, led to the apprentice gaining more knowledge and effectiveness, ChatGPT has become more knowledgeable thanks to the common language of the Internet provided by the ontologies.

So why can’t enterprises migrate all their data into a central location and build an ontology on that centralized data? Because it is extremely difficult. It requires a level of abstraction that is hard to do. Big tech giants like Meta and Google, have developed the Open Graph and Schema.org ontologies, respectively, leading to great user experience as users seek and retrieve information from their platforms. Though, most other ontologies have been created by a consortium of not-for-profit entities, presumably because they take a lot longer to create than investors are willing to wait, making such endeavours not ideal for public tech firms.

So, if there are few companies able to create ontologies for themselves, there are even fewer that can create ontologies for customers. In fact, to our knowledge, PLTR is the only company able to create custom-made ontologies for enterprise customers. This has been the case for a long while, though we think investors and customers are gradually recognizing this unique ability of PLTR thanks to the immense success of PLTR's AIP (Artificial Intelligence Platform). AIP essentially encapsulates all we discussed thus far, that is, it enables enterprises to implement and operationalize LLMs on their own data. However, PLTR would not have been able to create AIP if it wasn't for their ontology creating capabilities. In essence, it has required an GenAI focused product - that has been really easy for PLTR to develop and release - for everyone to begin to understand the importance of the ontology.

The key to PLTR’s capability in creating customized ontologies is their SDDI (Software Defined Data Integration), running in their HyperAuto solution. HyperAuto uses SDDI to connect to any data source and heavily leverages the metadata in order to understand the format and structure of the data. After ingesting the metadata, it decides how to connect with the data and build the data pipeline, how to transform the data, and how to design the ontology. Equally important, HyperAuto decides how to write back to the data source systems, to keep them in sync with the same data that is flowing into Foundry.

This is a truly unique ability that enables PLTR to normalize disparate data sources into highly curated datasets that become the language, i.e., the ontology, of the customer’s business. This enables LLMs within AIP to quickly learn and build up knowledge about the business and powers everything else. In essence, this is the plumbing that only PLTR can do in a secure and highly effective way.

Here is a very simple and incomplete example of an ontology for a single concept, which is wine. An instance will be a list of values within the classes and properties that describe a specific bottle of wine, e.g., Concept: Wine, Class: Red, Subclass: Pinot Noir, Name of wine: Evenstad Reserve Pinot Noir, Body: Light, Flavour: Red cherry, orange zest, Meal type: Good with red meat, and so on. PLTR uses different terminology in replace of concept, class, subclass, etc., but apply a similar structure.