WhyHow.AI

WhyHow.AI’s platform helps devs and non-technical domain experts build Agentic and RAG-native knowledge graphs

Out of Beta: WhyHow.AI Enterprise Cloud Hosted Platform

--

We are proud to announce that WhyHow’s Knowledge Graph Studio now has an enterprise cloud-hosted solution, alongside the backend we open-sourced previously. In this article, we cover key benefits, pricing, and how to think about competing differences.

The key benefits of the WhyHow Studio are:

  • JSON-based data ingestion for Knowledge Graph creation
  • Python-based APIs for easy interaction with LLM pipelines
  • Modular, multi-graph infrastructure
  • Multiplayer graph management and orchestration
  • Public case-studies with open-source code across a range of different implementation patterns

For enterprises who are interested in deploying the platform into their environment, the backend code is available here: https://github.com/whyhow-ai/knowledge-graph-studio.

We are focused on providing services and processes to help enterprises ensure they have the data assets needed to build deterministic and reliable LLM systems. Contact us for support deploying the frontend and backend into your environment, and LLM architecture/Knowledge Graph construction support.

Understanding competing differences in approach

Taking a step back, RAG and KG RAG are about 3 things:

A. Structuring your data in a particular way

B. Creating a retrieval engine that works with a specific logic

C. Fitting the structure & retrieval process to a Q&A business use-case

This is a holistic process, and no different from Vector RAG from a process perspective. If you structure your data in a specific way, you need to make sure your retrieval engine and logic is suitable to your data structure.

For example, if you are choosing to create a document hierarchy graph that creates a hierarchy of documents that must first be traversed before going to retrieve from separate graphs of each selected document, you are employing a specific data structure that requires specific retrieval logic.

If you structure your data and retrieval engine in a specific way, you want to make sure the business needs fits the type of output it can deliver.

For example, if you are choosing to use a one-click graph solution that generates the schemas on the fly through the LLM, the business trade-off is that these graphs would have an arbitrary structure. This makes it difficult if you want to ensure complete answers, and where the business use-case is about completely retrieving key specific information about multiple documents. An example is this case study about completeness metrics for tracking and retrieving a list of lawsuits disclosed in financial 10-K reports by a public company.

Given the arbitrariness of the schema of one-click graph solutions as opposed to a deliberate approach to data structuring, it would be difficult for a human or an LLM to be able to reference the data structure to completely retrieve all required information in a structured way, ending up with incomplete answers.

Within the WhyHow.AI platform, based on the work we have done with clients and design partners, we chose to use a technique that is about combining structured and unstructured search together through simplified ontologies. This data structure is tied to our retrieval technique, that is focused on retrieving embedded triples, with the ability to pull in chunks tied to the triples. We believe this data structure gives the most flexibility and have multiple case-studies across multiple industries (and open-source case study code).

Healthcare: https://medium.com/enterprise-rag/case-study-turning-doctor-transcripts-into-temporal-medical-record-knowledge-graphs-cf624d4927eb

Finance: https://medium.com/enterprise-rag/knowledge-graphs-completeness-multi-document-retrieval-benchmark-6304905a0a6c

Legal: https://medium.com/enterprise-rag/legal-document-rag-multi-graph-multi-agent-recursive-retrieval-through-legal-clauses-c90e073e0052

In a case study we ran, we found that our approach was able to beat not just other techniques out there, but due to our retrieval process compared against Text2Cypher, was able to beat the performance of retrieving against the exact same graph.

WhyHow’s querying engine was able to outperform on the retrieval process despite using the same graph, probably due to the structural issues that natural language queries to structured querying language has faced. Text2SQL has had similar struggles with accuracy (with this post claiming Text2SQL had an only 20% accuracy rate out of the box), so this is not a Cypher only issue.

Pricing

  • Professional: $500/month
  • Enterprise: Contact us

WhyHow.AI provides tools, services and processes for Structured Knowledge, Knowledge Graphs and deterministic Agentic RAG solutions. If you are interested in exploring any of our open-source tools (KG Studio, Knowledge Table) and consulting & development services, feel free to chat with us here.

If you’re thinking about, in the process of, or have already incorporated knowledge graphs in RAG for accuracy, memory and determinism, follow our newsletter at WhyHow.AI or join our discussions about rules, determinism and knowledge graphs in RAG on our Discord.

--

--

WhyHow.AI
WhyHow.AI

Published in WhyHow.AI

WhyHow.AI’s platform helps devs and non-technical domain experts build Agentic and RAG-native knowledge graphs

No responses yet