The release of PoolParty 10.2 is a strategic step in our transition toward the future Graphwise Platform. While we are busy building a more integrated ecosystem, this release addresses two critical needs for the modern global enterprise: the ability to process knowledge in any language and the precision to find specific data points in an ocean of information.

A unified identity under the Graphwise brand

Following the merger of Ontotext and Semantic Web Company, we are officially bringing the Graphwise identity to our core products. It is more than just a fresh coat of paint; it is about providing a professional, integrated experience as you move between tools.

In this first phase of the rollout, you will notice a refreshed look for the log-in page, the Linked Data (LD) frontend, and the core Graph Modeling component (formerly known simply as the PoolParty suite). While the “PoolParty” name remains for this version, these visual updates prepare the groundwork for our evolution into the unified Graphwise Platform.

Your knowledge graph, now fluent in over forty languages

For years, many enterprise systems were “English-first,” requiring custom, high-maintenance workarounds for scripts like Japanese or Chinese. That ends with PoolParty 10.2. We have re-implemented our concept tagging engine using a native Lucene-based architecture.

• Native multilingual support: Graphwise now supports over 40 languages natively, including Japanese, Chinese, Russian, and most European languages. No need for external “word form” files.
• Zero-touch indexing: Previously, users had to manually “Refresh the Extraction Model” whenever a taxonomy changed. Now, the extraction model is automatically rebuilt on the first request. It simply works in the background.
• Reduced complexity: By leveraging Finite State Transducers (FSTs), we have removed the dependency on external services for lookup logic. This means high-speed tagging with significantly less infrastructure overhead.

Whether you are managing technical manuals in German or news snippets in Japanese, your taxonomy is now a global asset that detects and links concepts with native-level fluency.

Precision when it matters: find the needle in the haystack

In research-heavy sectors like Pharmaceuticals, a search for a project code like “TAK-123” shouldn’t return every document containing the number “123.” Standard search engines often return broad, noisy results for queries.

The new Exact Phrase Matching in GraphSearch makes the life of data analysts a lot easier:

• Pinpoint accuracy: You can now toggle exact matching via the API, ensuring that multi-word queries are treated as a contiguous phrase rather than a collection of individual words.
• Flexible ranking: Choose between a “Mandatory” filter (only show exact matches) or a “Ranking Boost” that pushes exact matches to the top while still showing related content.
• Alphanumeric intelligence: We’ve optimized the system to handle complex identifiers and technical terms that involve hyphens or special characters, ensuring they aren’t fragmented during analysis.

Simpler workflows for developers and admins

We’ve also cleaned up the “plumbing” to make life easier for the teams running PoolParty:

• Unified Tagger API: We have consolidated several legacy endpoints into a single, high-performance /api/tag endpoint.
• Efficient multi-document handling: Whether you are uploading a ZIP file for aggregate analysis or sending multiple files for individual results, the process is now streamlined and more predictable.

What this means for you

PoolParty 10.2 is about making your semantic operations more robust and easier to use on a global scale. It removes the friction of manual indexing, eliminates the “noise” in your search results, and provides a clear, unified interface that reflects our shared future as Graphwise.

Originally published at https://graphwise.ai.

Data privacy has shifted from a checkbox exercise to a board-level risk.

Global regulations such as the EU General Data Protection Regulation (GDPR) require organizations to maintain detailed Records of Processing Activities (RoPA) (Article 30) and to perform Data Protection Impact Assessments (DPIAs) for high-risk processing (Article 35).

In parallel, frameworks such as the NIST Privacy Framework 1.1 help organizations treat privacy risk at the same level as cybersecurity and enterprise risk.

Yet most privacy teams still live in spreadsheets, manual questionnaires, and disconnected tools. That makes it hard to answer basic questions quickly and confidently:

• Where is our most sensitive data actually flowing?
• Which third parties are the riskiest — and why?
• If a new law or contract clause changes, what’s impacted?

This is exactly where Knowledge Graphs, LLMs, NLP, GenAI, and ML fit together into a modern Data Privacy Intelligence stack.

In this post, we’ll walk through the role of each technology, how they interlock, and how Zenia Graph, together with Graphwise, helps organizations operationalize data privacy, manage legal and regulatory risk, and gain a competitive edge.

Knowledge Graphs: The Privacy Control Plane

A knowledge graph is a connected map of everything that matters to privacy and AI governance: people, systems, data, vendors, regulations, risk, compliance and controls. Instead of scattered spreadsheets and rigid forms, you have a living, queryable model — a privacy control plane.

What a privacy knowledge graph models

Typical entities and relationships include:

• Systems & applications — CRM, HR, marketing, data warehouses, SaaS tools
• Data assets — tables, fields, documents, logs, events
• Data subjects & categories — customers, employees, minors, special categories
• Processing activities — purposes, lawful bases, retention, jurisdictions
• Vendors & third parties — roles, locations, data flows, contracts, sub-processors
• Controls & obligations — DPIAs, RoPAs, DPAs, SCCs, DSAR workflows, retention rules
• Risk Factors — Threats (Ransomware, Phishing), Vulnerabilities (CVEs), Likelihood vs. Severity scores
• Legal Frameworks — Regulations (GDPR, AI Act), Specific Articles, Lawful Bases, Consent versions
• Mitigations — Encryption levels, Pseudo-anonymization, Access controls, Residual risk status
• Incidents — Breach events, Notification deadlines, Root cause paths, Remediation steps

With this in place, you can ask questions like:

• “Show me all processing involving biometric data in the EU with no DPIA.”
• “Which vendors receive EU personal data and lack updated SCCs?”
• “For this new feature, which datasets, systems, vendors, and risks are connected?”
• “If we patch the SQL vulnerability in ‘Legacy Payments’, how much does our global Risk Score drop?”
• “Which data transfers to non-EU countries rely on SCCs but are missing a Transfer Impact Assessment (TIA)?”
• “Show me all ‘High Severity’ risks affecting ‘Special Category Data’ that remain unmitigated for > 30 days.”

Why graphs beat rigid lists and forms

Most legacy platforms sit on relational or proprietary databases with fixed schemas. That works when:

• Data flows are simple
• Schemas rarely change
• Only one region or regulation matters

It breaks down when:

• The same attribute (e.g., “email address”) flows through dozens of systems and vendors
• New regulations (like the EU AI Act) or AI use cases appear faster than the schema can be updated
• You must understand not just what data exists, but how it moves and why it is allowed

Graphs are:

• Flexible — adding new node types (e.g., “AI model,” “training dataset,” “data residency zone”, “new risk”) and relationships doesn’t require redesigning every form.
• Relationship-first — flows, dependencies, and cross-border paths are modeled naturally.
• Contextual — ideal as the context layer on top of existing scanners, catalogs, and logs.

Scanners and relational lists tell you what you have. The graph explains how it fits together and what it means for risk and compliance.

Data sovereignty and localization

For global companies, data sovereignty and localization are now core requirements. Because regions, legal entities, and data stores are first-class graph nodes, you can:

• Visualize cross-border data flows between cloud regions, vendors, and subsidiaries
• Answer: “Which EU data flows to US-based systems?” or “Where do we process data for Brazilian customers?”
• Support localization policies, such as keeping HR data for specific countries within certain regions

List-based tools show you columns filtered by “country.” A graph shows the network of flows — something executives, auditors, and regulators understand immediately.

LLMs and Graph RAG: Conversational Access to Compliance

Once your privacy landscape is modeled as a knowledge graph, LLMs turn it into an interactive assistant.

Instead of learning SPARQL or hunting through dashboards, privacy, legal, or business stakeholders can ask:

• “Which vendors are high-risk in Europe and why?”
• “What personal data do we store about candidates in Germany, and where does it go?”

Graph-aware LLMs (Graph RAG)

Standard RAG pulls text chunks from documents. Graph RAG retrieves structured facts and relationships from the graph and passes them to the LLM as context.

Example prompts:

• “Summarize all high-risk processing involving biometric data in France and list missing DPIAs.”
• “Explain why Vendor X is marked high-risk and recommend remediation steps.”
• “If we add a new AI model trained on dataset Y, what privacy and transfer risks arise?”

Because answers are grounded in the graph, they are:

• Traceable — linked back to concrete systems, vendors, and documents
• Consistent — aligned with a single source of truth
• Explainable — supported by explicit graph paths and attributes

LLMs become a privacy copilot that:

• Lets users “Talk to Your Graph” in natural language (via Graphwise)
• Provides just-in-time guidance inside workflows (e.g., suggesting lawful bases or flagging high-risk use cases)
• Generates short, audience-specific summaries of RoPAs, DPIAs, and audit findings

NLP: From Documents and Policies to Structured Signal

Most privacy-relevant information starts as unstructured text:

• Data Processing Agreements and terms of service
• Vendor security questionnaires
• Privacy notices and internal policies
• Incident and logging reports
• DSAR/complaint tickets

NLP turns this unstructured content into structured graph entries.

Core capabilities include:

• PII & data category detection — spotting personal and sensitive data in schemas, samples, or documentation
• Contract & policy understanding — extracting roles (controller/processor), purposes, retention, locations, and safeguards
• Entity & relationship extraction — mapping systems, vendors, datasets, and obligations into the graph
• Classification & tagging — labeling documents as DPIAs, DPAs, policies, retention schedules, etc., and linking them to processing activities

Scanner tools like BigID or Securiti do a great job finding sensitive data. Zenia Graph ingests those outputs and adds business context: who owns the system, which purpose the data serves, what contracts apply, and which legal regimes matter.

This continuous ingestion keeps the graph — and therefore your privacy posture — up to date, instead of relying on annual surveys and stale forms.

Generative AI: Drafts, Explanations, and “What-If” Analysis

Generative AI sits on top of the graph and NLP layer to remove manual drafting work.

Typical workflows:

• Drafting DPIAs & risk assessments — using graph data about systems, data categories, risks, and controls to pre-fill DPIA assessments, streamlining the mandatory Human-in-the-Loop (HITL) review process.
• RoPA generation and updates — automatically creating and updating RoPA entries as systems, vendors, and purposes change
• DSAR support — assembling first-draft responses by pulling together where an individual’s data lives, why it is processed, and how long it is kept
• “What-if” scenarios — answering questions like: “If we move this workload from the US to the EU, or swap Vendor A for Vendor B, how does that impact risk, transfers, and required controls?”

Generative AI doesn’t replace the privacy officer or in-house counsel. It removes repetitive copy-and-paste tasks so experts can focus on decisions, negotiation, and strategy.

ML and GNNs: Real-Time Risk Scoring

Machine learning (ML) and graph neural networks (GNNs) turn your graph into a real-time risk engine.

ML for context-aware risk

With graph features available, ML can:

• Score vendor and data-sharing risk using attributes like data sensitivity, jurisdiction, certifications, incident history, and control coverage
• Detect anomalies in access patterns (for example, a sudden spike of HR data moving into an unusual SaaS tool)
• Predict missing controls — highlighting where lack of encryption, retention limits, or DPAs is likely to cause problems

Instead of flat checklists, you get risk scores that understand context.

GNNs with PyG: learning risk from relationships

In privacy, risk is rarely about a single node; it’s about how nodes are connected. That’s where GNNs and PyTorch Geometric (PyG) come in:

Steps:

1. Build a learning graph

• Nodes: vendors, systems, datasets, jurisdictions, products
• Edges: data flows, contracts, processing relations, regulatory links
• Features: sensitivity, locations, certifications, incidents, missing controls

1. Train a GNN to predict risk

• Use historical incidents, audit findings, and red flags as training labels
• Let the model learn patterns like “vendors with this neighborhood and these gaps tend to be high risk”

1. Score nodes and relationships

• Every vendor, system, or flow receives a graph-aware risk score
• Scores can be refreshed when reality changes (new vendor, new flow, expired certification, new AI model)

1. Drive real-time heat maps

• Privacy, legal, and security teams see live risk dashboards instead of static annual reports
• They can justify priorities to the board and regulators with clear evidence and reasoning

AI Governance and the EU AI Act

The EU AI Act and similar initiatives mean organizations must govern not just data, but AI models:

• Which models exist and who owns them
• Which datasets (and personal data categories) trained them
• What decisions they influence
• What risks and controls apply

A knowledge graph is a natural backbone for AI governance:

• Models become first-class nodes linked to training data, business owners, and risk assessments
• Data lineage captures which personal data feeds which models, under what lawful basis
• Policies, monitoring controls, and impact assessments attach directly to AI models, just like to systems and vendors

Vendors like Securiti are pivoting hard to “AI governance.” Zenia’s advantage is that the same graph-based infrastructure that powers data privacy compliance can govern data + models + obligations in one consistent view.

A Unified Data Privacy Intelligence Stack

Put together, the stack looks like this:

1. Ingest & Discover — Connectors + NLP

• Bring in schemas, logs, scanner outputs, contracts, policies, and regulations
• Extract entities, relationships, and privacy semantics

1. Model & Govern — Knowledge graph

• Maintain a shared model for RoPAs, DPIAs, vendors, AI models, and cross-border flows

1. Analyze & Quantify — Analytics + ML + GNNs

• Compute and update risk scores, detect anomalies, cluster similar activities and vendors

1. Interact & Assist — LLMs + Generative AI

• “Talk to Your Privacy Graph” via Graphwise
• Draft DPIAs, RoPAs, DSAR responses, AI model registers, and remediation plans

1. Orchestrate & Execute — Agentic Automation

• Move beyond conversation: empower AI agents to interact with API hooks, autonomously suspending vendor access or triggering security protocols when risk thresholds are breached

1. Act & Learn — Workflows + feedback

• Trigger tasks, capture decisions, and feed results back into the graph for continuous improvement

The result: continuous, graph-driven intelligence, not static compliance snapshots.

How Zenia Graph and Graphwise Compete — and Win

Zenia Graph specializes in data privacy, AI governance, and third-party risk using knowledge graphs and AI. Graphwise delivers the conversational interface that lets users talk to that graph and RDF graph database.

What Zenia Graph provides

• Privacy & AI Governance Graph — a domain-specific model for processing activities, data, systems, vendors, contracts, AI models, and controls
• Connectors for multi-cloud and hybrid — ingesting from AWS, Azure, GCP, Snowflake, Databricks, on-prem, and existing compliance and discovery tools
• Graph-native risk analytics — ML and GNN-based scoring, risk heat maps by line of business, region, product, and vendor
• “Talk to Your Privacy Graph” assistant (via Graphwise) — natural-language Q&A with traceable, graph-backed answers
• Generative content workflows — DPIAs, RoPAs, DSAR responses, AI model registers, and internal briefings, all grounded in the graph

Positioning vs. incumbents

• Vs. OneTrust / TrustArc (rigid form-based platforms)
• They focus on static forms and checklists.
• Zenia delivers a dynamic, graph-based model that evolves as systems, vendors, AI models, and laws change.
• Vs. BigID / Securiti (scanner-first tools)
• They are excellent at discovering PII and sensitive data.
• Zenia is the context layer: understanding why that data is there, who owns it, what contract governs it, and which obligations apply.
• Vs. Microsoft Purview (ecosystem-centric)
• Purview shines in Microsoft-heavy stacks.
• Zenia is intentionally ecosystem-agnostic, unifying multi-cloud and hybrid environments where most real enterprises live.

Conclusion: From Static Compliance to Living Intelligence

Organizations that can see, explain, and prove how they use personal data — and how they govern their AI models — will win the trust of regulators, customers, and boards.

By combining:

• Knowledge graphs as the privacy and AI governance control plane
• Our Graph Schema aligns with international standards like W3C DPV, ensuring interoperability.
• LLMs as an intelligent, conversational interface
• NLP to bring unstructured evidence into the graph
• Generative AI to draft and explain privacy and AI artifacts
• Agentic workflows to autonomously orchestrate remediation, enforce controls, and execute response protocols
• Machine learning and GNNs to quantify and detect risk in real time

…you can transform privacy from a fragmented, manual burden into a connected, intelligent competitive advantage.

Zenia Graph, together with Graphwise, helps organizations make that shift — turning rigid, form-based compliance into a living Data Privacy Intelligence Platform that keeps pace with regulation, technology, and business change.

Originally published at https://graphwise.ai.

Our understanding of disease evolves constantly, and with it, our ability to treat patients effectively. A century ago, cancer was considered a single disease. Then we refined our understanding of cancers of specific organs — cancer of the lung, for instance. Later, we distinguished between different cell types, like non-small cell lung cancer. Today, we examine individual mutational profiles of cancers and develop medicines targeting specific subpopulations.

This evolution creates a fundamental challenge: as our understanding grows more precise, we need to understand patients participating in clinical studies in increasingly defined ways. We need to identify the patient and the exact subpopulation they represent within a disease. This precision enables more targeted treatment and better success rates.

But there’s a problem — our data has always been captured in verticals supporting specific processes. What precision medicine requires is horizontal analysis across those silos. That’s why we turned to knowledge graph technology.

Building Scientific Intelligence: a use case-driven approach

At AstraZeneca, we built a tool called Scientific Intelligence to address this challenge. Our approach from the start has been to remain use case-driven. With the enormous volume of data available both internally and publicly, trying to “boil the ocean” simply doesn’t work. We recognized early that science evolves, questions evolve, and everything must be modeled on what is being asked and what the data shows us — not what we could theoretically model.

Scientists ask complex questions: “Find me subjects who participated in studies where the indication was non-small cell lung cancer, where the drug was Tagrisso, where they had adverse event X, with CT scans of their lung, but with a genetic profile of Y.” These queries span many different data modalities.

Our strategy leverages AstraZeneca’s data mesh architecture, where platforms aggregate and manage data around specific disciplines. We have clinical data in STDM format, omics data including gene expression and RNA levels, imaging data covering both medical images like CT scans and digital pathology slides, and critically, sample information about specimens from trial subjects. In principle, we serialize all of this into what we call a “knowledge map” — we use that term with our customers because we are driving navigation of the space. We then surface this knowledge graph through a front end, enabling relatively easy exploration.

The goal is simple: help people find patients or samples matching their profile, then submit compliant requests for data access. Since we work with some of the most ethically and privacy-sensitive data the company holds, we operate in a very compliant fashion. We generally show information about what happened and observations made, rather than the actual observations themselves.

From studies to individual observations

The knowledge graph centers on a few major nodes: the clinical study with everything we can say about it, the subjects who participated, the samples taken from those subjects, and the observations made on those samples or subjects.

We provide summary statistics around studies by indication and drug. For individual studies, we offer a 360-degree view including the title, drug, indication, status, number of patients recruited, milestones completed, and links to critical documents like the clinical study protocol. Moving to the subject level, we have connections radiating outward. We can provide summary views showing the number of adverse events or total lab tests performed, but also drill into individual subject demographics, adverse events, and lab tests. This is where researchers really start mining subpopulations and specifying the exact group they want to examine.

At the sample level, we display inventory information — what’s still available to order, what type of sample was taken (plasma, blood, biopsy), where in the body it originated. Finally, at the individual observation level, we can detail the number and types of images available, tumor types observed, and stains performed. We can get remarkably granular, starting at the clinical study and drilling down through subject, sample, and omics data.

The user interface presents dashboards for clinical studies showing where trials run globally and facets for filtering — by therapeutic area, indication, disease, drugs used, and development phase. Clicking facets builds queries with constraints. A researcher might specify: “Show me only oncology studies where non-small cell lung cancer was the indication, which are phase three.” This continuously narrows the result set. The interface includes an abstraction of the graph where circles represent nodes connected to clinical studies, allowing navigation across the graph to other dashboards covering subjects, samples, and observations.

Unlocking unknown knowns

But the real value becomes clear only through examples. A data scientist recently approached us wanting to build a predictive model for recovery in chemotherapy patients. Some patients experience white blood cell count drops requiring them to stop chemotherapy. Predicting this allows putting them on recovery therapy so they can take additional rounds — a massive impact on cancer survival chances.

The data scientists worked with a particular drug product team and knew of two or three studies likely holding relevant subjects, but they worried about not having enough subjects in the subpopulation to train their machine learning model. Using Scientific Intelligence, we identified five additional studies they weren’t aware of that contained the right population. This gave them confidence to request access to those studies, knowing the number of subjects would be sufficient for their model.

“This was hugely enabling because it [the complex search process] has previously been a very manual process and it could take weeks to do. We went from weeks to minutes.” — Ben Gardner, R&D lead for Data Mesh and Semantic Infrastructure at AstraZeneca

For study design, researchers often need to know variance in liver tests or blood pressure for particular subpopulations — analysis that used to take weeks now takes hours. We can provide the data, though they still complete the final statistical analysis.

Landscape reviews represent another powerful application. These enable therapeutic areas to understand what data and samples they have available based on different subpopulations. This has proven transformative in oncology, changing how teams prosecute their drug programs.

These reviews used to take months to build and immediately went out of date as new data came in — a continuous “Forth Bridge painting” exercise. Now we build queries that update in real time. Every time new data becomes available, they get automatic updates.

Teaching people to think differently

An interesting challenge emerged with our scientists. Most aren’t experienced querying knowledge graphs. When we said, “We’ve pulled these data sources together into a graph and you can ask really interesting questions,” their first response was: “I don’t know what I can ask or what I should ask, because I’ve never been able to ask this sort of question before.”

This created a chicken-and-egg scenario where because they knew they couldn’t ask these questions previously, they never bothered thinking about them. So now we are doing extensive education to help people think differently and recognize new possibilities.

Another problem is that the questions that generate efficiency savings aren’t asked daily by each group. That data scientist asking about the predictive model for white blood cell drops in chemotherapy treatments might ask that question once every six months. By the time they need it again, they’ve forgotten how to use the system. We need better ways of enabling people to interact with and query the data.

We can build beautiful, complicated data structures, but the challenge is making them navigable and consumable for complex questions. I firmly believe we need a return of librarians. When I did my PhD, librarians helped me navigate a large building full of information with a non-intuitive indexing strategy. We need the equivalent for these complicated knowledge graphs we are building.

Scaling through pragmatism

Managing over 20 different data sources and modalities to create that unified picture is no small task. Initially, we handled everything from data capture through cleanup and curation, serializing into data types, integrating into the graph, and exposing through Scientific Intelligence. We could do it, but we burned out. The team size needed to continue evolving and handling this diversity far exceeded our funding capacity.

We asked three simple questions:

• How can we maximize our engineering skills to focus semantic engineers on what’s important while getting others to do standardization?
• How do we better manage the graph ecosystem — updating infrastructure, orchestrating the smorgasbord of tooling, evolving from virtualization to physical?
• How do we democratize the graph to people, making it useful not just through the Scientific Intelligence UI but through other data forms?

The smart answer was to accept that classic SQL-type data cleanup using DBT and Snowflake with SQL-trained data engineers could accomplish significant work. We push the model into that data flow upfront — minting URIs, applying controlled vocabularies, flattening data — all in SQL. This becomes a data product we can serialize into the knowledge graph.

We chose Corporate Memory by eccenca, backed by GraphDB as the quad store, because it allowed a single vendor to manage the whole stack and suite of tooling. Now we just deploy images rather than patching and maintaining many different pieces. Our semantic engineers can focus on semantics, not infrastructure maintenance. It also provided nice integration opportunities with the established ecosystem of data consumption tools. Our Scientific Intelligence interface is built with Discover from OntoForce.

Putting the graph into the data

We initially thought we needed to transform all data and build it into a graph — essentially creating a graph across the entire enterprise. What we learned from our experience with virtualization upfront, serialization into the graph, and using controlled vocabularies changed our perspective fundamentally.

We now materialize controlled vocabularies and make them available not just to our data pipeline but to everyone else’s. We drive common patterns from the reference model and URI patterns we establish. What we realized is that we have pivoted. While we still put data into our knowledge graph for Scientific Intelligence, from an enterprise perspective, we are really putting the graph through artifacts like controlled vocabularies into the data.

This lets us scale differently. We provide controlled vocabularies — built as taxonomies — then flatten them into Snowflake tables for easy consumption by data pipelines. This means data products being produced already have the URIs we want to use in our graph, making them easy to consume. This represents our major learning and pivot.

Key takeaways

Evolving science has driven us to understand diseases with greater and greater granularity, creating new data demands and resulting in complicated data graphs. But we must help people navigate these complex spaces. Focus on generating common patterns. Look for opportunities to help others do hard work for you, enabling you to focus limited skills on truly important process elements.

There’s no shame in using traditional approaches where they make sense. Most importantly, invest in data interoperability. That means building taxonomies, flattening them, and making them available as simple flat lists for SQL engineers to consume — it makes a huge difference. Put editorial governance in place and hide the semantics, because most of the world doesn’t need the semantics but needs the artifacts we create to make their data FAIR.

On ROI, you can calculate time saved and multiply across multiple people and use cases. We looked at frameworks for the increasing value of data as you join together different modalities. With about 350 studies and 750,000 subjects, as we add genetic sequencing information, samples, and imaging data, you get multipliers — ten times as you bring two together, a hundred times with another, 300 times with the next. The potential value becomes enormous. It’s about use cases that enable drawing down against that potential value.

The question about hiding semantics isn’t about toxicity — it’s about avoiding confusion. It’s not a religious war of SQL versus semantics. It’s about blending tools together. At AstraZeneca, 95% of the IT organization knows nothing about graphs or semantics. There’s no point teaching 95% of the organization to work with SPARQL, SKOS, and the RDF stack. We have a specialist group working with this technology stack, and we work out how to enable the artifacts to be consumed by the rest of the organization in data forms they’re familiar with, using skills they already have.

Originally published at https://graphwise.ai.

The latest GraphDB release introduces safer data management, cutting-edge Model Context Protocol (MCP) support, and a new Python client for easier administration and integration.

The transition from “experimental AI” to “enterprise-grade AI” requires more than just a large language model; it requires a data foundation that is both indestructible and highly accessible. With the release of GraphDB 11.3, we are doubling down on these requirements by introducing smarter backup safeguards, expanded Model Context Protocol (MCP) support, a new Python client built into RDFLib, and a refreshed interface that aligns with our new identity as Graphwise.

Here is a closer look at how GraphDB 11.3 helps DevOps teams and AI developers move faster and with greater confidence.

Bulletproof data operations: smarter backups

For DevOps engineers managing large-scale knowledge graphs, a backup is only as good as its ability to be restored. Traditionally, verifying the success of a backup in a distributed or cloud environment (like S3) could be a “fingers-crossed” moment.

GraphDB 11.3 introduces a success checksum system to eliminate this uncertainty.

• Automated validation: Upon completion, GraphDB now tags backups with a checksum and generates a .success file. This provides an immediate, machine-readable confirmation that the backup is healthy.
• Corruption guardrails: The engine now includes “guard code” that prevents the system from even attempting to apply a corrupt or incomplete backup.

By automating the work of the guard code, GraphDB 11.3 removes the manual overhead of validating data integrity, ensuring that your recovery point objective (RPO) is backed by reality, not just a log entry.

Building the future of AI with enhanced MCP support

As the industry moves toward agentic AI, MCP has emerged as the standard for connecting AI models to data sources. GraphDB 11.3 significantly expands its MCP capabilities, making it easier for developers to use GraphDB as a robust knowledge backend for AI agents.

• Latest protocol support: This release adds support for multiple MCP versions, including the latest 2025–11–25 standard.
• Flexible transport modes: Developers can now choose between legacy SSE and the new Streamable HTTP transport. This flexibility allows you to optimize for high-concurrency environments and gracefully handle resource exhaustion.
• Rich metadata: With support for prompt and tool metadata via spring-ai-mcp, developers gain better tooling, easier debugging, and more granular analytics for their AI-driven applications.

Whether you are building a simple retrieval system or a complex autonomous agent, GraphDB 11.3 provides the stable, high-performance bridge needed to feed your models the right context.

Faster automation with the new GraphDB Python client

For many DevOps engineers and developers, Python is the default way to script, automate, and integrate data systems. With GraphDB 11.3, working with GraphDB from Python becomes easier and more robust thanks to the new GraphDB Python client, contributed to the RDFLib library.

Instead of writing custom wrappers around the REST API, you can now rely on an officially supported, industry-standard library to:

• Monitor and administer GraphDB instances and clusters
• Manage repositories, access control, authentication, and security
• Import data and integrate GraphDB tasks into your existing Python tooling and CI/CD pipelines

Because the client is part of RDFLib, it fits naturally into existing Python data and semantic workflows. You can standardize on a single library for RDF handling and GraphDB administration, reducing custom code and making your operational scripts more portable and maintainable. Future releases will extend coverage to even more administrative endpoints, but 11.3 already delivers a fast, resilient way to get real work done with GraphDB using the skills and tools your team already has.

A Fresh look: Graphwise Workbench

You may have noticed things look a bit different. Following our rebranding to Graphwise, the GraphDB Workbench has been updated with our new brand colors and design guidelines.

While the powerful functionality you rely on remains the same, the updated look and feel represents our commitment to a unified, modern ecosystem. It’s a cleaner, more intuitive environment designed to help you focus on what matters: the data.

Notable performance improvements

In addition to the headline features, GraphDB 11.3 includes several requested enhancements:

• Advanced vector search: You can now create vector fields out of nested object fields, allowing for more nuanced and complex similarity searches within your knowledge graph.
• GraphDB-Ontop integration: We’ve added support for all Ontop configuration keys, giving you total control over how you virtualize relational databases as RDF.

Ready to explore GraphDB?

GraphDB 11.3 is designed to make your knowledge graph operations more resilient and your AI integrations more powerful.

Originally published at https://graphwise.ai.

PoolParty 10 strengthened the Graphwise platform foundation for enterprise semantic AI. With PoolParty 10.1, the focus shifts from infrastructure to accelerating knowledge graph building itself.

This aligns directly with the Graphwise strategy: activating knowledge, governing AI, and driving ROI. As enterprises push GenAI beyond pilots, one challenge keeps resurfacing: building high-quality semantic context is still perceived as complex, costly, and expert-heavy. PoolParty 10.1 is designed to lower that barrier.

Taxonomy Builder: from blank page to working taxonomy (with AI in the loop)

Building a good taxonomy has long been a significant bottleneck for knowledge graph initiatives. It often requires scarce specialists, long workshops, and extensive manual curation, which slows pilots and increases costs.

The Taxonomy Builder in PoolParty 10.1 is the first step in changing this.

Instead of creating concepts one by one, users can now:

• Generate a hierarchical taxonomy skeleton with a top-down, LLM-powered approach
• Generate a structured hierarchy of concepts using GenAI to create the initial framework from a domain description.
• Generate labels and definitions with AI to improve clarity and discoverability

In practice:

• Taxonomists can describe a domain, generate structure, and refine suggestions
• Everyone stays in control through review and acceptance workflows

This isn’t a “magic one-click graph creation.” It’s human-in-the-loop AI that accelerates expert work, reduces time-to-value, and helps more teams contribute to building the semantic backbone.

For Graphwise customers, this is a meaningful step toward making semantic backbone systems easier to start, faster to iterate, and stronger as a foundation for reliable AI.

Enterprise-ready improvements around the core

PoolParty 10.1 also brings targeted enhancements that improve day-to-day experience and set the stage for future automation:

Custom roles

Many large organizations need access models that go beyond rigid default roles. PoolParty 10.1 introduces the groundwork for capability-driven, more granular role management, supporting enterprise governance without sacrificing usability.

Improved GraphSearch ranking

Search is only valuable when results are prioritized meaningfully. PoolParty 10.1 improves ranking logic, allowing users to surface more useful results faster.

Extractor API cleanup

To simplify integrations and prepare for future improvements, the Extractor API has been restructured to reduce complexity, clarify parameter behavior, and align with cleaner API design principles.

What this means for the Graphwise platform

PoolParty 10.1 is a clear expression of Graphwise direction:

• Lower the cost and complexity of building semantic backbones
• Pair GenAI acceleration with governance and quality control
• Prepare the path toward broader AI-assisted knowledge modeling beyond taxonomies

Taxonomies are the first step. As Graphwise continues to expand automation across knowledge creation and governance, PoolParty 10.1 helps ensure that semantic context is no longer a bottleneck, but a scalable advantage for enterprise AI.

Originally published at https://graphwise.ai.

Retrieval Augmented Generation (RAG) has become the standard for grounding large language models (LLMs) in proprietary data. However, as we push RAG systems into more complex domains, we also see the limitations of such solutions.

Standard RAG relies heavily on vector similarity search. While efficient, it suffers from a fundamental “tunnel vision”: it retrieves chunks based on semantic proximity to the query, but often fails to “connect the dots” across disjointed pieces of information. It struggles with multi-hop reasoning, where the answer lies in the relationship between two distant documents, not in the documents most similar to the initial question.

Enter GraphRAG, and specifically HippoRAG 2 (Hippocampal Retrieval-Augmented Generation). These systems attempt to solve this challenge by structuring data as a graph, allowing retrieval based on relationships rather than just surface-level similarity. HippoRAG takes this a step further by mimicking the neurobiological processes of human long-term memory to create additional associative links. The latter is the major difference to most of the popular GraphRAG implementations, which derive schemaless knowledge graphs from documents.

However, even HippoRAG has a limitation: it typically builds its graph based on simple co-occurrence or open information extraction. It lacks a true “world view”. It also still relies on semantic similarity to manage to traverse the relations it has found in the data properly.

In this post, we explore how to supercharge the graph-based retrieval process by injecting a semantic backbone. We will demonstrate how replacing generic graph construction with strict ontologies and structured knowledge graphs transforms HippoRAG from an associative engine into a reasoning engine.

How does HippoRAG work

To understand how we improved the system, we first need to understand the unique architecture of HippoRAG.

Unlike standard GraphRAG approaches that might simply traverse a knowledge graph, HippoRAG is inspired by the Hippocampal Indexing Theory of human memory. In the human brain, the Neocortex stores actual memories (analogous to LLM parameters and a document corpus), while the Hippocampus acts as a dynamic index, storing the pointers and associative relationships between those memories.

HippoRAG replicates this duality to enable faster, multi-hop retrieval. It operates in two distinct phases:

1. Offline indexing (the associative graph)

In the standard implementation, HippoRAG processes the document corpus to create a schemaless graph.

• Extraction: It uses an LLM (or OpenIE) to identify key noun phrases and entities within the documents.
• Graph construction: It builds a knowledge graph where nodes are these extracted entities. Edges are created based on co-occurrence (two entities appearing in the same passage) or strong semantic similarity.
• Result: A massive associative map where Document A is linked to Document B because they share the entity “Python,” even if the documents never explicitly reference each other.

2. Online retrieval (the neurobiological pattern)

When a user asks a query, HippoRAG doesn’t just look for keywords; it simulates a neural activation process.

• Vector search on triples: The system does a vector search based on the query to find the triples with the biggest vector similarity to the query.
• Node activation: These entities are located in the graph and are selected as the starting point for Personalized PageRank.
• Personalized PageRank: This is the core mathematical engine. The system uses the Personalized PageRank algorithm to spread this activation across the graph, in a manner similar to the priming in the human brain. By using the nodes with the highest vector similarity, it traverses the graph to find the most relevant documents.
• Ranking: The system identifies which documents are most strongly connected to the highly activated nodes in the graph and retrieves them.

Because the activation spreads through the graph, HippoRAG can find a document that contains none of the query words, provided it is strongly linked to the query through a chain of intermediate entities. This is the essence of multi-hop retrieval.

However, the “Vanilla” HippoRAG relies on the LLM to hallucinate the connections or extract them loosely. By replacing this loose association with a rigorous ontology and a knowledge graph, we provide the PageRank algorithm with a much cleaner, noise-free highway to travel on.

Extending HippoRAG with an ontology and a knowledge graph

To transform HippoRAG from an associative engine into a reasoning one, we extended the pipeline by injecting a structured “spine”: an automatically generated ontology and a knowledge graph. This moves us away from loose, probability-based connections to explicit, logic-based relationships.

1. Ontology creation

The first step is moving from chaos to order. Instead of ingesting raw triples immediately, we iterate over the relations initially extracted by HippoRAG. We employ an LLM agent that acts as a schema architect. At each step, this agent reviews a batch of extracted relations alongside the ontology built so far. Guided by a user-defined goal, the agent infers necessary classes and relations, deciding iteratively how the world should be structured. This ensures the ontology isn’t just a list of words, but a coherent framework tailored to the specific domain.

2. Knowledge graph creation

Once the ontology provides the scaffolding, we populate the building. A second LLM agent iterates over the documents to extract a strict knowledge graph that conforms to our new ontology. To ensure data integrity, a dedicated “repair agent” follows behind, fixing syntax errors, and ensuring compliance.

Crucially, we also build an Inverted Index. In standard graph systems, you might know that “John knows Jane,” but you lose the context of how. The inverted index links every entity and triple in the knowledge graph back to the exact source text.

• Without the index: The graph knows(John, knows, Jane).
• With the index: The system can trace the knows relation back to the paragraph describing “John met Jane at a jazz bar in Chicago.” This turns the knowledge graph from a simple fact store into a navigational map that points back to the rich nuance of the original documents.

3. Inference

We split the inference process into two synergistic retrieval steps:

1. Associative Retrieval: We utilize HippoRAG’s Personalized PageRank to identify documents based on network proximity and activation.
2. Structured Retrieval: Simultaneously, we perform SPARQL queries against the knowledge graph. To jumpstart this, we provide the model with a list of relevant triples, helping it anchor its search within the graph.

The outputs from both streams — the document context from HippoRAG and the structured facts from the knowledge graph — are fed into a final synthesis agent. This agent combines the “associative” and the “logical” to answer the user’s query. A visualization of the inference pipeline can be explored in Figure 2.

Evaluation and results

To test the efficacy of this semantic backbone, we turn to MuSiQue, widely considered the most complex multi-hop reasoning dataset available. MuSiQue requires a system to successfully navigate 2 to 4 distinct “hops” of information to arrive at an answer. For example, a 3-hop question could look something like “In which country was the director of the film ‘The Great Gatsby’ born?”

We avoided standard “exact match” metrics, which often penalize correct but verbose answers. Instead, we employed an LLM-as-a-judge evaluation protocol that assesses whether the answer is accurate and contains the necessary information, regardless of phrasing.

The majority of questions in MuSiQue are 2-hop. For that reason, we separated evaluations into one evaluation on 2-hop only questions and one evaluation on equal parts 2, 3 and 4 hop questions. For each evaluation, we took a random subset of 100 MuSiQue questions. Manual examination of the questions, however, revealed significant issues with the question spanning from incorrect answers to impossible connections. To filter out these unanswerable questions, we ran a system with exact context three times on each question and if it never produced the expected response the question was removed. The results presented below are based on the accuracy over the remaining answerable questions.

Performance on 2-hop questions

As seen in the results below, adding an ontology-based knowledge graph yields immediate dividends. Semantic GraphRAG manages to answer about 95% of answerable questions, creating a clear separation from standard HippoRAG (86%) and a massive improvement over traditional Vector RAG (79%). The “LLM w/o RAG” category (71%) is also included to demonstrate the ability of LLMs to answer these questions with general world knowledge- something only possible because MuSiQue is a public dataset and therefore part of their training corpora.

In this experiment our approach answered, on average, 69 of the 73 answerable questions correctly giving it a consistent advantage over HippoRAG.

Performance on multi-hop questions

When testing across the full spectrum of available question complexity, the distinction between approaches grows clearer and Semantic GraphRAG demonstrates superior resilience. While Vector RAG and HippoRAG plateau near 75%, Semantic GraphRAG increases its dominant lead to 86%. This suggests that as reasoning chains get longer, the structured “highway” provided by the knowledge graph becomes increasingly critical for maintaining the trail of evidence.

People don’t have time to browse, interpret, or reconcile conflicting sources. They need to pull answers, not documents, and they need to be able to set the context themselves. That said, content operations are to be centred around designing content for retrieval, not publication. They also need to be done with a view to capturing meaning in an explicit way before worrying about format. Last but not least we should be treating definitions and other cornerstone content chunks as first-class content assets.

In practice of the 69 answerable questions here, Vector RAG and HippoRAG answer 51–52 questions on average while Semantic GraphRAG averages 59.

Insights

Our deep dive into the MuSiQue dataset revealed a significant noise floor: many questions in the benchmark itself are flawed or ambiguous. In fact, across a variety of question samples, we established that about a third of the questions are not answerable — usually the expected answers are wrong or impossible to derive. An example of the latter is: “What is the administrative territorial entity that contains the location of Eric Marcus?”. The expected answer in the dataset is: “KUAT-TV 6”, which is a TV station, not an administrative territorial entity. An example of the former is: “In which country was the tournament held?”, which makes no sense without specifying which tournament the question is about.

However, benchmarks like MuSiQue fail to capture the true “power” of Semantic GraphRAG implemented via natural language querying (NLQ), — Aggregation. Standard RAG and GraphRAG systems are retrieval engines, not calculation engines. If you ask, “How many genes are associated with ALS?” or “Which gene is linked to the highest number of Alzheimer’s symptoms?“, standard systems fail. They attempt to retrieve text chunks and rely on the LLM to count. LLMs are notoriously poor at counting and the required context often exceeds token limits.

Semantic GraphRAG solves this deterministically. It doesn’t ask the LLM to count. It generates a SPARQL query (for example, SELECT COUNT(?gene)...). The result is a single, perfectly accurate number returned instantly. This ability to switch between “reading” (RAG) and “calculating” (SPARQL) is a paradigm shift for complex data analysis. This capability is referred to as NLQ, where natural language queries are converted to queries to a database engine.

Further improvements

We have some ideas for further improvements that can go in the following directions:

• The Q&A pairs of MuSiQue are designed to be answered via document chunks, without NLQ. We are developing a new benchmark designed specifically to test these capabilities. We aim to move beyond simple retrieval metrics and demonstrate what is possible when you treat your data as a true knowledge graph.
• Semantic GraphRAG can be improved further, using more advanced ontology and entity linking techniques. One direction would be to experiment using an existing ontology, for example, Schema.ORG or the ontology of Wikidata. This will save processing time (no need to generate an ontology). It will also make text-to-SPARQL generation faster and cheaper, because there will be no need to pass the ontology in the prompt — all major LLMs do know these popular ontologies.
• Personalized PageRank can be implemented directly in Graphwise GraphDB, which will void the need for a separate associative graph, stored in a separate engine.

Conclusion

By fusing the neurobiological inspiration of HippoRAG with the rigid structure of ontologies and semantic knowledge graphs, we have created a system that offers the best of both worlds. We retain the associative, “human-like” memory retrieval of HippoRAG, while injecting the logical precision required for multi-hop reasoning and complex aggregations.

The results are clear: structure matters. When you give an LLM a map (the ontology) and structured data (the knowledge graph) rather than just a pile of documents, it doesn’t just retrieve better — it reasons better.

Originally published at https://graphwise.ai.

You may have invested heavily in chatbots, virtual agents, and knowledge portals, but still see deflection rates and satisfaction flat or falling. That frustration is rising on the customer side as well, with Gartner finding that nearly 64% of customers do not want AI involved in their support experience.

The problem is not AI itself but its lack of structured context. LLM-powered bots sometimes hallucinate (confidently generate wrong or made‑up information) when they lack the necessary domain knowledge. And the result is a poor support experience: vague or wrong answers frustrate users and can even erode trust in your brand

GraphRAG addresses this problem by grounding AI assistants in enterprise knowledge graphs. So every answer is rooted in a consistent semantic model of your business, your content, and your users. When support AI can truly understand how everything is connected, self-service becomes reliable and explainable, and it provides a good return on investment.

In this article, you will go over how GraphRAG delivers measurable ROI for both customer and employee support.

The problem with today’s AI-powered self-service

Most AI-powered support tools today are built on thin large language models (LLMs) or basic retrieval-augmented generation (RAG) systems. They split content into pieces (chunks), turn them into vectors, and store them. When someone asks a question, the system finds similar chunks and prompts an LLM to assemble an answer.

This pipeline largely ignores the domain’s deep structure, such as product hierarchies, configuration options, regional rules, entitlements, service levels, and more.​

Since there’s no clear way to represent these relationships, the system often treats all similar content as interchangeable. For example, it might show a troubleshooting guide for Version A to a customer using Version B, apply policies from one region to another, or suggest a workaround for an outdated feature to a new customer.

The system is technically retrieving similar text, but it doesn’t understand the relevant context. The problem worsens when information is scattered across different systems, such as product docs, policies, ticket histories, and community content, all stored separately.

A study of knowledge workers found organizations use only about 38% of their available expertise, with much of the rest trapped in isolated systems. Without a unified semantic layer, the AI misses the relationships between customer data, product details, and corporate policies.

What is GraphRAG and why it changes self-service

GraphRAG is based on the same idea as traditional retrieval-augmented generation, but adds the missing piece: an explicit knowledge graph of your domain. The graph supplies explicit semantics — a domain model — that an LLM alone lacks.

Every user query triggers a semantic search of the graph, gathering contextual facts that precisely match the query. The LLM then generates an answer grounded in those facts. GraphRAG added several key benefits for support:

• Contextual retrieval — The system issues semantic graph queries that incorporate the user’s context. The AI fetches information that exactly matches the query, not just text that looks similar.
• Precise scoping — Answers are automatically narrowed to the user’s situation. Recorded metadata — product type, version, subscription tier, region, and entitlements — all serve as filters for the query.
• Trustworthy answers — Output is grounded in curated graph data, so hallucinations drop considerably. In benchmarks, graph-based RAG models have achieved higher accuracy than traditional vector-based RAG models, greatly reducing the number of wrong answers.

The ROI story: From frustrating bots to measurable outcomes

Many organizations experience the same trajectory with first-generation chatbots and RAG assistants. After their launch, they often see a modest initial increase in deflection and self-service usage, as these systems handle the simplest FAQs.

But as soon as users bring more context-dependent questions, the limitations become obvious: answers feel generic, inconsistent, or hedged, and escalations continue to flow to human agents. Support teams end up spending more time reworking AI-generated answers, validating outputs in regulated scenarios, and manually updating content to patch retrieval failures.​

GraphRAG breaks through that barrier and solves far more queries correctly on first contact, which directly cuts support costs by up to 30%.

There are two main ROI levers in play:

• Search efficiency — Using graph-powered retrieval can reduce the search time by half, and productivity increases by approximately 10–15% when results are tailored to the user’s context.
• Operational gains — In customer and employee support scenarios, GraphRAG deployments often deliver double‑digit efficiency gains. Organizations report approximately 15–20% improvement in case resolution, driven by higher first‑contact resolution, fewer escalations to higher levels, and less time spent validating AI answers.

Smarter self-service for customers

To see what this looks like in practice, consider a typical customer journey with a GraphRAG-powered assistant. A user logs in to the support portal and describes their issue in natural language, such as a billing discrepancy or an eligibility question for an upgrade.

Behind the scenes, the assistant enriches the query with semantic context from the knowledge graph: which products the customer has, which plan and region they are in, and whether there are known issues or policies related to similar patterns.​

Instead of a generic reply, the assistant pulls the specific policies, troubleshooting flows, and examples relevant to this customer’s exact situation. The response the user sees is a step-by-step answer that references their product, plan, and constraints.

Where appropriate, the assistant surfaces links to supporting documentation so the user can verify details without wading through irrelevant content.

Compared to a generic bot, the user does not need to rephrase the question multiple times, navigate between different channels, or repeat context when they escalate to a person. The assistant “remembers” the entities and relationships at play and uses them consistently throughout the conversation. This reduces friction, lowers effort, and builds trust.

Over time, organizations see higher self-service success rates, better CSAT for digital channels, and a healthier balance between automated and person-assisted support.

Smarter self-service for employees (internal support)

IT, HR, finance, and compliance teams frequently deal with complex employee inquiries. They face challenges when information is scattered, and policies are hard to access.

Internal helpdesks often rely on manual triage and informal knowledge, leading to lengthy email threads as employees struggle to find consistent answers aligned with company policies.

GraphRAG applies a knowledge-graph approach to internal support, connecting policies, documentation, catalogs, asset inventories, and historical tickets into a semantic layer. It lets employees use natural language to get answers reflecting actual enterprise operations.

Since every answer can be linked to specific documents, services, and policy artifacts in the graph, internal teams gain both confidence and auditability. New hires ramp up faster because they can self-serve answers instead of relying on a small group of experts. Expert teams see fewer repetitive questions and can focus on genuinely novel or high-risk issues.

Across departments, policy interpretation becomes more consistent, and sensitive areas like tax or financial reporting can be supported by AI without sacrificing control or traceability.

How Graphwise delivers measurable ROI in support

Graphwise’s Graph AI Suite makes GraphRAG work at scale. It combines a semantic graph database (GraphDB), ontology modeling tools (Graph Modeling), data integration (Graph Automation), and the GraphRAG engine into one solution.

It lets teams import content, build taxonomies, and deploy the assistant without stitching together multiple vendors. You get graph modeling, automated tagging, and RAG all in a unified workbench, which speeds rollout and reduces costs.

Moreover, Graphwise embeds a built-in AI Flywheel — every user interaction is a learning opportunity. The system logs the graph entities and documents used to answer questions and flags frequently accessed content for refinement and quickly identifies knowledge gaps.

Over time, the graph’s ontology and metadata improve automatically. In effect, the assistant gets smarter as it’s used and reduces the need for constant manual updates. Support teams see this as recurring questions are answered instantly, while rare edge cases are added to the knowledge graph.

Real-world deployments show how Graphwise GraphRAG moves from theory to measurable support outcomes:

• Avalara, a tax-technology provider, used GraphRAG to overcome a “Precision Paradox” in its initial RAG chatbot. Graphwise converted their DITA documentation schema into an RDF ontology, enabling 100% precise content mapping. The resulting DOM GraphRAG assistant delivers deterministic, fact-based responses, leading to higher customer satisfaction and faster time-to-value.
• Similarly, Healthdirect Australia runs a national telehealth advisory service that aggregates medical content from over 280 partner organizations. Their information was scattered across dozens of websites, systems, and databases. Using GraphRAG, Healthdirect built a unified health knowledge graph. Graphwise helped import and semantically tag all partner content, creating a single ontology for medical conditions, providers, services, and regions. This enhanced self-service has significantly “reduced pressure on call centres” and cut routine inquiries.

Conclusion

Self-service does not fail because users dislike automation or because generative AI is inherently unreliable. It fails when assistants are forced to operate without the context and structure they need to reason about real-world products, policies, and situations. Traditional chatbots and basic RAG systems, built on top of fragmented knowledge and shallow similarity search, inevitably run into this wall.

GraphRAG, grounded in enterprise knowledge graphs, offers a way through. It enables AI assistants to deliver precise, explainable, and policy-aware answers to both customers and employees at scale.

Originally published at https://graphwise.ai.

It’s 2026. The Web has grown into 1.2 billion websites and counting. Not only that but the architectonics of how people interact with content is being widely reshaped. The rise in AI tool adoption and the new discovery channels like AI-powered search and chatbots have changed how audiences access online information.

In that landscape, one thing has become impossible to ignore: users don’t need more content. They need better access to relevant knowledge as well as platforms that allow for meaningful, trustworthy, and traceable interaction with information sources. They need actionable results from searches across systems, retrieved quickly and accurately, in the moment of their need, tailored to their specific context.

Content for action, not consumption

In my case, as a Knowledge Steward at Graphwise, the users I work for are our Sales team people. In my role, my goal is very specific: to create content that enables them to do their job better and faster, and to be confident that the information they get is up-to-date, trustworthy, and value-oriented.

Such a job is not easy as the test for content is immediate — it either helps move the conversation forward, or it doesn’t. Case in point: when a sales rep is on a call, they don’t have time for browsing and berry-picking information. They need specific answers for a specific context, and not documents, blog posts, or webinar summaries.

That challenges our Sales Enablement team to create and maintain relevant content that can be retrieved faster, be trustworthy, and accessible in a conversational way. It also calls for a change in the mindset of ideating, planning, and publishing content. What was before a theoretical exploration of how organizational communication is increasingly moving from organization-controlled model stakeholder-centric and less message-controlling participatory communication is now a practical requirement we cannot afford to ignore.

And so we did not.

Walking the AI-ready content talk with the Graphwise Knowledge Hub

We, at the Graphwise Sales Enablement team, shifted the way we look at content ideation, creation and distribution. We stopped thinking about content as artifacts and started thinking about content from the perspective of knowledge management, knowledge graph building, and enterprise-wide coherence in communication.

It has now been almost a year since we started building the Graphwise Knowledge Hub, using Graphwise technologies, and strategically walking our own knowledge graph talk. Along the way, we learned a lot. And as I see more and more organizations trying to build their own “knowledge hub” or “single source of truth,” I want to share some of the key lessons we learned building our Graphwise Knowledge Hub.

Spoiler alert: These are three things people working in content already know but often don’t have the technology, mandate, or change-management support to truly enact.

Graphwise Knowledge Hub (At a Glance)

The Graphwise Knowledge Hub is an application on top of the Graphwise Knowledge Graph and is built using Graphwise Platform. It is currently powering several internal applications including a GraphRAG application, several Sales Agents and a semantic search over our technical documentation. The Graphwise Knowledge Hub is a constantly evolving infrastructure and with time will power more applications and agents e.g. a Marketing Assistant on our website, an interactive conversational application with facet filter, a Market Research Agent and more.

Lesson 1: The push-to-pull shift is real and calls for a change

You don’t need me to point you to the endless references about conversational content and the need to “talk with” audiences rather than “talk at” them. What is worth repeating though is the role that content grounded in knowledge graphs can play in making that talk a real walk along the alley of user-centric content.

In our case, building a Knowledge Hub for sales enablement meant creating content in a way that allowed sales teams to pull information and to talk to the content we had. To do that, we needed to not only create content in a way that allowed it to be composed ad hoc. We also needed to do it using agreed-upon concepts shared across systems and departments for enterprise-wide coherence in our communication.

This inevitably led to cross-department alignment around terms that organically grew into a messaging work: we needed to figure out not only the terms, but also the business logic through which they relate to each other. For example, how Graphwise GraphDB serves a given use case and what are the capabilities it has that move a specific business needle.

Only after such diligent work on knowledge management, led by Helmut Nagy (VP Sales Enablement at Graphwise), were we able to start working with and creating content that is truly pullable, modular, and composable.

Lesson 2: Good content is about building knowledge management scaffolding

This is a lesson I have come across in my theoretical explorations and writing work for years as a content person, but only truly learned it in practice from Helmut Nagy: How important it is to bring people together, talk, discuss concepts, agree upon terms, messaging, operational synergies, etc.

Over the past year, the Graphwise Knowledge Hub was built as an AI-driven platform bringing together CRM data, marketing materials, product documentation, website content, market research, and more. But the real transformation happened when it evolved into a shared, knowledge graph-driven platform where people could find what they need based on tags, interests, topics.

What we learned along the way is building a knowledge hub that serves reliable answers and trustworthy content meant doing some grunt work in the first place. Case in point: first we went through the processes of defining core concepts clearly and aligning and mapping terminology across teams. Next, we put a substantial amount of effort into understanding well and modelling the relationships between products, industries, and use cases. Finally, we built feedback loops so that the knowledge we added in the Graphwise Knowledge Hub would be relevant and well-tied to the ecosystem of knowledge that was growing in the organization.

This work alone brought us to creating workflows in which we ideate and write content at the level of concepts, not pages. We also work in a way that allows us to further assemble content into multiple narratives (for example, for sales, for marketing, for SEO).

Lesson 3: AI is only as good as the knowledge you feed it

AI is often presented as the solution to enterprise knowledge problems, but we know from customer projects and from experience that the real story isn’t in the AI itself. The differentiator is the actionable content and contextual knowledge an organization manages to provide to the AI system.

What we didn’t know was that the Knowledge Hub would become also a focal point not only for people, but also for AI agents, as it was by default a hub for aligned meaning in the first place.

For me, from a content perspective, this not only means that content is to be used to “feed” our AI systems. It also means that it is to be created in a way that allows it to be assembled, and not simply authored. That said, what we now know is that instead of creating static assets, we can create conceptual building blocks anchored in the knowledge graph.

Thus, we can get more reliable output from an AI system, depending on who is asking, in what context, and for what purpose. To do that, we approached any AI agent or system as a consumer of structured knowledge and as an addition to our knowledge and content work, not a replacement or automatization.

Instead of an epilogue: Join us for our webinar

As a Knowledge Steward, my role is not to create more content, nor to police language. Neither is the work of my colleagues who are part of the Sales Enablement team. Our work is to design and maintain the scaffolding that allows knowledge to accumulate, connect, and stay usable over time.

And when we learn our lessons and follow sustainable practices for connecting knowledge, sales enablement accelerates, communication improves, onboarding becomes easier, and content creation becomes faster.

I really hope that our approach will help you on your own knowledge graph journey towards AI-ready content and enterprise insights.

If you liked this sneak peek into the content kitchen of the Graphwise Knowledge Hub, come to see our Graphwise Knowledge Hub in action and to hear about the ecosystemic rationale and impact of the Graphwise Knowledge Hub.

In our on-demand webinar: From Silos to Shared Intelligence: Inside the Graphwise Knowledge Hub, Helmut Nagy and I share:

• What we built and why
• The lessons learned from real internal use
• How we evaluated whether the Hub truly accelerates enablement, communication, and content creation
• A live demo of the Knowledge Hub so you can explore it yourself

Because the future isn’t about creating more content. It’s about creating systems that make knowledge actionable — on demand.

Originally published at https://graphwise.ai.

Generative AI promises speed, but in legal and compliance, hallucinations create unacceptable risks and costly rework. This article explains how GraphRAG bases AI on verifiable facts to ensure accuracy, audit trails, and faster regulatory responses for measurable ROI.

Legal and compliance teams are under pressure to keep up with constant regulatory changes while maintaining absolute accuracy. Meanwhile, growing volumes of fragmented data increase the risk of errors, and one mistake can cost millions.

Financial institutions like Citigroup face penalties of up to $136 million for data management failures. Similarly, the Securities and Exchange Commission (SEC) recently charged nine investment advisers and three broker-dealers $4 million to $12 million in penalties for recordkeeping failures.

Many organizations have turned to artificial intelligence (AI) as a solution. Although 79% of law firms have adopted AI tools, only a fraction have genuinely transformed their operations. The reason is a lack of trust in AI outputs, since traditional large language models (LLMs) made up information up to 45% of the time in legal contexts.

LLMs create compliance risks and make teams spend excessive time verifying AI-generated insights, rather than using them with confidence.

This article explores how graph retrieval-augmented generation (GraphRAG) addresses these challenges through semantic grounding. It discusses how it delivers measurable ROI through transforming legal and compliance teams’ approach to data.

Understanding the hallucination crisis in legal AI

We must first assess the scale of the hallucination problem to understand why compliance teams hesitate to fully embrace generative AI. In high-stakes environments, “mostly accurate” is never accurate enough.

The scale of the problem

The error rates in specialized fields remain dangerously high despite the hype surrounding generative AI. Even the best-performing legal AI products hallucinate in about one out of six instances. When answering very specific legal queries, the hallucination rates for language models can range from 69% to 88%.

AI is also being used in healthcare, so hallucinations are here, too. GPT-4 hallucination rates are 28.6% in medical systematic reviews, with precision as low as 13.4%. The weakness of standard LLMs is their probabilistic nature, which predicts the next likely word rather than verifying the facts.

We are already seeing real consequences of AI-generated fabricated case law appearing in legal briefs and judicial opinions. For example, Deloitte was supposed to repay the Albanese government after using generative AI to produce a $440,000 report on the welfare system. The report was riddled with errors, false references, and incorrect footnotes.

This incident highlights that even major consultancies are not immune to the risks of ungrounded AI. When an organization relies on a system that makes up facts, they pay twice, once for the technology and again for the cleanup.

Why are hallucinations especially dangerous in compliance

Hallucination may be a quirky error in creative writing or marketing. But it’s a liability in compliance because it requires factual accuracy — errors can lead to legal issues. Also, professional liability turns personal, and the Model Rules of Professional Conduct place responsibility on legal professionals to supervise AI-generated work.

Failing to put proper verification processes in place can trigger disciplinary action, sanctions, and loss of licensure, plus long-term reputational damage​.

The manual verification burden

The manual verification burden exacerbates the problem. Legal professionals spend 60–80% of their time verifying AI outputs, rather than focusing on strategic analysis. Document review processes that might take days or weeks with traditional manual approaches remain time-consuming even with AI assistance because every output must be checked for accuracy.

This inflates expenses in an hourly billing model — what should be efficient becomes a costly loop of checks and corrections. Furthermore, AI amplifies rather than alleviates the workload without better grounding.

What makes GraphRAG different: The semantic grounding advantage

The solution to the hallucination is in changing how AI retrieves and processes information. This is where GraphRAG distinguishes itself from standard retrieval methods. GraphRAG works on knowledge graphs. These are structured representations where entities, regulations, policies, and clauses are explicitly connected through defined relationships.

From probabilistic guessing to structured knowledge

Standard RAG systems use vector-based retrieval that breaks documents into text chunks. An LLM receives retrieved text chunks as context to synthesize information, then generates a coherent output.

Yet this process relies entirely on the model’s learned patterns about what language should look like — probability. If the model has learned patterns that associate certain phrases or concepts, it may generate outputs that match those patterns even if no explicit connection exists in the source documents.

GraphRAG transitions from plain text chunks to structured entity information. It includes a graph database, Graphwise GraphDB, as a source of contextual information sent to the LLM. An LLM generates the final text, but the verified graph structure constrains its generation. The model cannot hallucinate relationships that do not exist in the graph structure. It can only conclude explicitly mapped connections.

Consider a compliance scenario, a legal professional queries whether a specific data processing practice violates GDPR requirements. The LLM in a traditional RAG system retrieves GDPR documentation and information about the data processing practice. It then produces an answer based on patterns it has learned from legal reasoning.

The response may sound authoritative and even cite the retrieved documents. However, the real reasoning still happens inside the model’s probabilistic inference process. In GraphRAG, the system traverses the knowledge graph from the data processing practice node to related policy, regulation, and enforcement precedent nodes.

The relationships between these entities are clearly defined, capturing whether a practice falls under a specific GDPR article, has prompted enforcement actions, and which safeguards meet the requirements. The answer comes from these defined connections rather than from general linguistic patterns.

Explainability and audit trails

GraphRAG brings trust in compliance through auditability. Every answer traces back through knowledge graph relationships and provides transparent reasoning. Compliance professionals can see exactly which regulations, precedents, and policies supported a particular conclusion.

When auditors ask how the organization reached a compliance determination, the answer includes source citations and the explicit relationship path from the query through the graph to supporting evidence.

This transparency addresses professional liability concerns. Compliance professionals can point to a documented, verifiable reasoning chain — here’s the regulation, here’s our control — and satisfy the Model Rules of Professional Conduct requirement to supervise AI-generated work.

The accuracy improvement

The impact of semantic grounding is measurable, as it reduces hallucinations to single-digit percentages, compared to the 45% baseline for ungrounded LLMs. In enterprise implementations, organizations report moving from 60% accuracy in traditional RAG deployments to over 90% accuracy with GraphRAG.

The ROI case: Measurable impact across compliance workflows

The improved accuracy and explainability with GraphRAG yield ROI across time efficiency, cost reduction, risk mitigation, increased speed, and improved decision quality.

Dramatic time savings

The one immediate ROI comes from reclaiming lost hours. AI-powered legal document review, when grounded by GraphRAG, reduces processing time by 60–80%. Legal teams can handle vastly larger volumes of data without increasing headcount.

Policy interpretation and management also accelerate dramatically. Manual compliance work requires teams to collect relevant documents, process physical and digital files by converting them to searchable formats, and conduct reviews for relevance and regulatory requirements.

GraphRAG-powered policy management eliminates these time-consuming manual processes. It redirects resources to strategic analysis of compliance gaps and control optimization. Furthermore, document automation saves up to 90% of time on legal document creation.

Cost reduction through reduced manual review

The reduction in manual review effort through semantic grounding and accurate AI outputs considerably lowers operational expenses. Firms stop paying high-value professionals to act as spellcheckers for their AI by eliminating the expensive iterative verification cycles caused by hallucinated content.

Also, there are lower audit preparation costs. Automated systems effortlessly maintain detailed compliance records and remove the costly “audit scramble” common in compliance departments.

Risk mitigation and audit cost savings

Beyond cost reduction, GraphRAG lowers professional liability exposure by providing accurate, explainable outputs that reduce malpractice risk. It also drives regulatory compliance improvements. Real-time monitoring, rather than quarterly reviews, prevents violations before they occur.

Shifting from reactive to proactive management reduces penalties, as firms can identify compliance gaps before audits rather than discovering them during reactive audits.

Faster compliance cycles

Speed is a competitive advantage in regulatory adherence, and GraphRAG lets you match that speed without sacrificing accuracy. You can integrate regulatory updates into the knowledge graphs in real time within hours to ensure the AI always checks the latest requirements — far faster than traditional, manual update processes.

At the same time, continuous assurance and monitoring replace time-consuming quarterly reviews. They automatically surface compliance gaps as soon as they arise and reduce the risk of surprises during audits.

You can use knowledge graphs to analyze the impact before rolling out policy changes, preventing regressions and ensuring controls remain effective. This integrated approach accelerates regulatory response and turns agility into a source of confidence and reduced audit risk.

Improved decision quality

GraphRAG delivers substantially improved decision quality by enabling context-rich insights from knowledge graphs that provide a complete view of the regulatory space. It also allows gap detection and early identification of requirements, even when controls are not mapped or evidence is missing.

GraphRAG also supports shared control optimization to help teams identify controls that satisfy multiple frameworks in parallel — ISO 27001, SOC 2, PCI DSS, and GDPR.

Build trust and ROI with Graphwise

Building AI systems in legal and compliance that deliver trustworthy, accurate, and explainable results requires expertise and capital, too. This is where Graphwise stands apart: its purpose-built Graph AI platform offers a robust suite of capabilities tailored for trust and efficiency.

Key features of the Graphwise platform include:

GraphDB

GraphDB is Graphwise’s scalable and highly reliable semantic graph database stores and manages your compliance knowledge in a structured, interconnected format. GraphDB forms the single source of truth to enable semantic grounding that dramatically reduces hallucinations and supports precise fact-based reasoning.

GraphDB introduces streamlined integration with leading large language models (LLMs) and supports natural language search (Talk to Your Graph) for fast, precise AI-driven decision-making.

Knowledge graph

Graphwise helps organizations convert vast legal texts, regulatory documents, and internal policies into rich, semantically linked knowledge graphs. These graphs capture entities and regulations, define relationships and context, and enable LLMs to perform multi-hop reasoning for complex compliance queries.

Graph AI Suite

The Graph AI Suite brings modeling tools, knowledge graph management, advanced connectors, and a model context protocol (MCP) server under one roof for smooth integration with third-party AI solutions. It lowers complexity and eases end-user adoption for building customized AI applications.

Moreover, the suite models and maps raw documents into structured knowledge graphs, automates taxonomy creation, and enriches metadata through semantic analysis. It also delivers GraphRAG, which uses semantic graphs to boost LLM accuracy in legal and compliance workflows.

Through these and many other tools, Graphwise helps enterprises reduce risk and rework, resulting in strong business returns. For instance, the Avalara vector-based RAG model lacked the accuracy needed for mission-critical tax applications. This resulted in a “Precision Paradox” in which improved accuracy led to user dissatisfaction due to errors.

Avalara implemented a DOM GraphRAG proof-of-concept model using Graphwise’s Graph AI Suite to leverage their existing DITA-structured content. They built a reliable knowledge graph base for trustworthy AI solutions.

Similarly, Healthdirect’s fragmented content from hundreds of partners and siloed data systems made it difficult to deliver unified, user-friendly health services at scale. To address this, they used Graphwise’s Graph AI Suite to build a semantic knowledge graph that automated content classification, enabled dynamic content generation, and powered smart search.

Wrapping up

GraphRAG resolves AI’s legal pitfalls, grounding outputs for reliability and ROI. It helps teams save time, reduce costs, lower risk, and make better decisions.

With Graphwise, you gain a proven partner. The company has helped global financial institutions, pharmaceutical companies, and professional services firms transform scattered regulations and policies into a single, trustworthy source of truth.

Teams finally spend their time on strategy rather than second-guessing AI, auditors receive transparent trails on demand, and organizations stay ahead of regulatory change rather than react to it.

Originally published at https://graphwise.ai.

For many organizations, the biggest barrier to generative AI isn’t the model, it’s trust. Teams struggle to justify AI-driven decisions when they can’t see where an answer came from, how it was produced, or whether it respects internal policies and regulations.

With GraphRAG, we’re introducing the intelligence layer of the Graphwise platform: a governed, graph-powered retrieval-augmented generation engine designed specifically for enterprises that need explainability, compliance, and scale.

GraphRAG combines Large Language Models (LLMs) with a Semantic Layer built on knowledge graphs to deliver context-rich, verifiable, and audit-ready answers. It’s where your institutional knowledge, graph data, and AI workflows meet.

What is GraphRAG?

GraphRAG is the core GenAI engine in the Graphwise platform. It goes beyond traditional vector-only RAG by unifying:

• Semantic reasoning over your knowledge graph
• Hybrid retrieval across graph, vector, and full-text search
• Multi-hop question answering for complex, relational queries

Where standard RAG stops at similarity search, GraphRAG understands entities, relationships, and semantics. It transforms fragmented documents, taxonomies, and domain models into actionable answers that can be traced, explained, and audited.

Our vision is simple:
To be the enterprise-standard engine for trusted generative AI, turning complex institutional knowledge into reliable, multi-hop answers for mission-critical decisions.

Why enterprises need a trusted GenAI layer

Most enterprise AI teams face the same challenges:

• Opaque pipelines — It is hard to see how an answer was produced or which sources were used
• Hallucinations and inconsistency — Models improvise when context is missing or ambiguous
• Regulatory pressure — This applies especially in finance, healthcare, ESG, and the public sector
• Siloed knowledge — Structured and unstructured data live in different systems with no shared semantic layer

GraphRAG addresses these challenges by design:

• Transparent retrieval and reasoning — Each step of the pipeline can be inspected
• Source-level provenance — Answers are backed by explicit documents and graph entities
• Semantic grounding — The knowledge graph acts as a source of truth, reducing hallucinations
• Regulatory-friendly traceability — It is built for environments where you must justify why an answer is correct, not just what it is

What makes GraphRAG different

GraphRAG builds on years of experience with GraphDB, PoolParty, and semantic technologies in regulated industries. At its core, the product is shaped around three pillars.

Trust and explainability

GraphRAG turns the traditional “black-box” RAG pipeline into a transparent, auditable system:

• Explainable answers — Users can see what was retrieved and why it was used
• Source citations and provenance — Answers are linked back to specific documents and graph entities
• “Explain this answer” views — This breaks down how the system interpreted the question, expanded concepts, and selected context
• Regulatory-ready traceability — Retrieval, reasoning, and guardrails can be inspected for audits and reviews

This is essential for teams working under strict oversight, where AI output must withstand internal and external scrutiny.

Hybrid retrieval and knowledge-graph grounding

GraphRAG isn’t tied to a single retrieval method. It combines:

• Graph-based retrieval via the knowledge graph (GraphDB and ontologies)
• Vector search in your chosen vector store
• Full-text search (FTS) for keyword-driven discovery

On top of that, GraphRAG uses knowledge-model-driven input processing to understand user intent. This means that it:

• Detects and enriches concepts from your taxonomy/ontology
• Expands queries with related entities and terms
• Builds a graph representation of the question to resolve ambiguity

This makes a big difference for real-world questions that are short, vague, or rely heavily on domain-specific language.

Because the system retrieves from a graph of entities and relationships — not just isolated chunks — GraphRAG is particularly strong on multi-hop questions (“how does X impact Y across Z?”) and complex context.

Enterprise flexibility and vendor-agnostic design

GraphRAG is engineered to fit into existing enterprise stacks instead of locking you into one vendor:

• Any major LLM — OpenAI, Claude, Azure AI, Amazon Bedrock, or your own hosted models
• Any vector store — OpenSearch, Elastic, and other enterprise-grade vector backends
• Any enterprise IdP — Integration with standard identity providers via OAuth2/OIDC

Embedding models and vector stores are abstracted behind clear interfaces, so you can switch providers, update models, or scale infrastructure without rewriting your application.

GraphRAG core capabilities

Version 1.0 focuses on delivering a solid foundation for trusted conversational experiences over your knowledge graph and content.

• Secure, authenticated access
• Keycloak-based authentication and authorization
• Separation of users, services, and GraphRAG pipelines
• Conversational experience with short-term memory
• Multi-turn chat with context preserved within each conversation
• AI-generated follow-up questions to help users go deeper
• Concept descriptions based on your SKOS-style taxonomies
• Explainability and provenance out of the box
• A dedicated explainability panel that shows what tools were called and what they returned
• Document panel with source URL, title, and description
• Basic provenance listing which sources contributed to the answer
• Hybrid retrieval foundation
• Integration with GraphDB and external vector stores like Elastic/OpenSearch
• Support for combining structured graph context with unstructured documents
• Enterprise-grade guardrails
• Input and output guardrailing integrated in the workflow
• Safety and policy checks wired directly into the agent orchestration
• Modern APIs and streaming
• Synchronous and asynchronous querying
• Server-sent events (SSE) for streaming answers, explainability messages, sources, follow-ups, concepts, and guardrail signals

In short: GraphRAG v1 gives you a governed, explainable conversational layer over your knowledge graph and content, ready to be embedded into applications, portals, and internal tools.

Tested on real-world, high-stakes scenarios

To shape GraphRAG, we evaluated the product on a diverse set of demanding scenarios, including:

• Financial regulation and monetary policy — Policy documents, regulatory texts, interconnected financial concepts
• Healthcare and clinical knowledge — Clinical pathways, medical guidelines, interactions, and care protocols
• International development and ESG — Project documents, sustainability reports, regulatory frameworks, and impact narratives
• Semantic technology and internal knowledge hubs — Deeply structured ontologies and knowledge graphs connected to technical documentation

These use cases push the system across multiple dimensions: precision, reasoning depth, traceability, and robustness in domain-specific language. They’re exactly the environments where “just another chatbot” isn’t enough.

Getting started with GraphRAG

GraphRAG is available as a core component of the Graphwise platform and integrates natively with:

• GraphDB for semantic graph storage and reasoning
• PoolParty and your knowledge models (taxonomies, ontologies)
• Your existing vector infrastructure and LLM providers

If you’re building or scaling enterprise AI initiatives and need answers that are explainable, compliant, and grounded in your knowledge graph, GraphRAG is designed for you.

We’d be happy to walk you through the first release, discuss your data landscape, and explore how GraphRAG can become the trust layer for your generative AI applications.

Originally published at http://graphwise.ai.