Glance's Gemini Knowledge Graph on Google Cloud

TL;DR: The Glance Gemini powered knowledge graph on Google Cloud uses Gemini models to pull entities and relationships out of raw news, then stores them in a Neo4j graph to drive search and recommendations for 300 million users. After launch, Glance reported recommendation coverage climbing from under 60% to over 85% and Cards per Session up 24% (Google Cloud, 2025). The setup points to an emerging default: put LLM reasoning on top of a graph backbone instead of running either one alone.

Glance delivers content to phone lock screens for more than 300 million users across 450 million devices (Google Cloud, 2025). At that size, the hard part is not collecting articles. It is connecting them: knowing that two stories are about the same person, the same event, or the same rising trend, and serving the right one to the right reader in real time.

This post walks through how Glance solved that with a knowledge graph plus Gemini, and why the architecture is becoming a common template for AI over large, messy content.

What is a Gemini-powered knowledge graph?

A knowledge graph is a network of entities (people, organizations, places, events, brands) connected by typed relationships. Instead of a pile of documents, you get a map of how things relate.

A Gemini-powered knowledge graph uses Google’s Gemini models to build and read that map. Glance’s version, which the company calls a Content Knowledge Graph (CKG), ingests news, entertainment, sports, gaming, shopping, and lifestyle content, then turns it into “a dynamic network of interconnected entities and relationships” (Google Cloud, 2025).

The division of labor is the interesting part. The language model does the reading and reasoning. The graph stores the structure. Neither does the other’s job.

How does Glance’s content pipeline work?

Glance built the CKG with Google Cloud Consulting, using Gemini, BigQuery, Vertex AI, and Neo4j (Google Cloud, 2025). The flow runs in stages:

1. Ingestion. Content from many sources lands in BigQuery for scalable processing.
2. Entity extraction. Gemini reads each article and pulls out the people, organizations, locations, events, and brands, plus the relationships between them.
3. Standardization and linking. Gemini normalizes those entities and links them to authoritative sources like Wikipedia, so the same person is not stored five different ways.
4. Classification. Gemini tags each piece of content against the IAB content taxonomy and flags sentiment, urgency, and relevance.
5. Summarization. Gemini writes short headlines and contextual tags that feed the recommendation engine.
6. Graph construction. All of this gets written into a Neo4j graph database as connected entities, topics, and user-interaction patterns.

Step 3 is where a lot of value hides. Entity resolution (deciding that “the same thing” mentioned in two articles really is the same node) is one of the oldest, most tedious problems in data. Using an LLM to normalize and link entities is exactly the kind of fuzzy text work models are good at, and it is what makes the downstream graph trustworthy.

Why pair an LLM with a graph backbone?

This is the pattern worth noticing. You could try to answer “what’s related to this story?” with a language model alone, stuffing context into a prompt. Or you could run a pure graph with hand-built rules. Glance did neither. It used Gemini for the parts that need reading comprehension, and a graph for the parts that need structure and speed.

That split has a name in the broader field: GraphRAG, where retrieval runs over a knowledge graph rather than a flat vector index, so an AI system can follow relationships instead of just matching similar text (Microsoft Research, 2024). The graph answers “how is A connected to B” in a way a bag of embeddings cannot.

The payoff is concrete. After the team optimized Neo4j with indexing and query tuning, graph query times dropped “from seconds to milliseconds” (Google Cloud, 2025). You cannot serve real-time recommendations to hundreds of millions of users on second-long lookups. The graph is what makes the reasoning fast enough to ship.

Engineering for scale: 50,000 articles a day

A graph is only useful if it keeps up with the firehose. Glance scaled the CKG to handle more than 50,000 daily articles across content categories (Google Cloud, 2025). Getting there took several engineering moves:

• Event-driven architecture. Moving to a Kafka-based event-driven design with retries and async operations gave a 4x throughput improvement (Google Cloud, 2025).
• Graph tuning. Neo4j indexing cut query latency from seconds to milliseconds.
• Managed Kubernetes. Auto-scaling on Google Kubernetes Engine improved reliability and resource use.
• Caching and targeted optimization. Redis caching plus Cloud Spanner for critical data, applied with an 80-20 focus on high-impact work, cut processing latency by 80% and lifted recommendation coverage from under 60% to over 85% (Google Cloud, 2025).

That coverage jump is the quiet headline. Going from under 60% to over 85% means the system can now confidently recommend related content for the large majority of what it sees, instead of leaving a third of the catalog as dead ends.

What were the business results?

Glance reported measurable gains after the CKG went live (Google Cloud, 2025):

• Cards per Session up 24%, a direct read on engagement and stickiness.
• A 5% increase in swiping sessions, concentrated in the related-content sections the graph powers.
• Faster trend detection across news, entertainment, sports, and lifestyle than the previous system.

These are content-platform metrics, but the mechanism underneath is general. Better connections between pieces of knowledge produced better answers, which produced more engagement.

A closer look: the same pattern inside a company

Glance applies the LLM-on-a-graph pattern to public content. The same shape fits private, internal knowledge.

Picture Vantage Health, a mid-size insurer. Its underwriting policies live in a wiki, claims decisions sit in a ticketing tool, regulatory updates arrive by email, and the reasoning behind last quarter’s pricing change is buried in a deck someone shared once. When an underwriter asks “have we handled a case like this before?”, the answer technically exists. It is just scattered across five systems that do not talk to each other.

A knowledge graph for that company would do what Glance’s CKG does for news: extract the entities (policies, clients, claims, regulations, people), resolve duplicates, and connect them into one queryable network. An AI layer on top reads the messy source documents and reasons over the graph to answer the question directly, with the trail of connected records behind it.

This is the problem SemanticOS is built for: a knowledge graph plus AI search that connects fragmented enterprise tools into one semantic layer, so people and AI agents can find and reason over institutional knowledge instead of re-searching it. Glance’s results are a useful proof point that the architecture holds up at scale.

Key takeaways

• The Glance Gemini powered knowledge graph on Google Cloud splits the work cleanly: Gemini reads and reasons over text, Neo4j stores and serves the connections.
• Entity extraction, resolution, and linking are the bridge that turns unstructured articles into a structured, trustworthy graph.
• Performance work mattered as much as the AI: Kafka, GKE, Redis, and graph tuning cut latency 80% and pushed recommendation coverage past 85% (Google Cloud, 2025).
• The results were business-level: Cards per Session rose 24% for a platform serving over 300 million users.
• The LLM-on-a-graph backbone is becoming a default pattern, and it transfers directly from public content discovery to private enterprise knowledge.