From keyword search
to knowledge graphs.
Stagwell Marketing Cloud rebuilt its media intelligence on a Dataworkz GraphRAG pipeline. One million articles a day, on-premise, with relationships, not keywords, as the data model.
What Stagwell Marketing Cloud built on Dataworkz.
- Customer
- Stagwell Marketing Cloud (SMC)
- Industry
- Media intelligence · marketing technology
- Use cases
- Brand intelligence · competitive monitoring · earned-media analytics · journalist affinity graphs · early crisis detection
- Scale
- 1M+ articles/day ingested · 800K articles per extraction run
- Pipeline
- 4-stage GraphRAG: ingest → extract → normalize & store → hybrid retrieval
- Deployment
- On-premise · no third-party LLM dependencies
- Connected tech
- Pub/SubSparkDatabricksvLLMLlama 3.2-3BNeo4jpgvectorMongoDB AtlasElasticsearchModal
- Status
- Live
Media organizations today need fast, responsive, and narrative intelligence to make decisions so that they can tackle crisis comms, PR announcements, and market shifts with speed, accuracy, and information at their fingertips from multiple data sets. AI platforms like Dataworkz get them there with the right infrastructure.
Keyword search couldn't see the relationships its clients needed.
Articles stored as opaque text blobs.
The system could count brand mentions; it couldn't answer "which journalists consistently cover us alongside a competitor" or "how has the tone of coverage shifted since launch."
"Apple," "Apple Inc.," and "Apple Computer" lived as three separate records.
Every aggregation, every share-of-voice metric, every co-mention report ran on broken data, and there was no way to fix it after the writes.
Negative coverage clusters surfaced after they had already trended.
By the time the platform flagged a story, the news cycle was past the window where a PR response could meaningfully change the outcome.
Third-party LLM APIs introduced exposure no major brand could accept.
A 270M-parameter model SMC tried first failed in production, Spanish-language responses regardless of input, hallucinated entities, high variance. Small + fast was not a free lunch.
Four stages. One coherent system. Relationships as first-class citizens.
The pipeline has two halves, a generation side that turns raw articles into a knowledge graph, and a retrieval side that routes natural-language questions to the right index. They share a single schema, which is what keeps the architecture coherent at scale.
Ingest
Filtered, typed article dataset ready for extraction. Batch aggregation keeps GPU utilization high and avoids hundreds of small, inefficient compute jobs.
Extract
Validated entity and relationship JSON. Domain fine-tuning outperforms general-purpose LLMs on boundary detection, classification, and output-schema compliance.
Normalize & store
One real-world entity = one graph node. The precondition for accurate aggregation and meaningful relationship traversal at scale.
Hybrid retrieve
Relationship queries → graph. Semantic → vector. Exact → lexical. Each layer compensates for the others' weaknesses.
Domain-fine-tuned small models. Hybrid retrieval. Brute-force optimization where it mattered.
Two engineering bets define this pipeline. Pick the smallest model that meets the accuracy bar. Then squeeze the extraction stage from a 21.5-hour run into a 9-hour run without sacrificing quality.
| Model | Params | VRAM (infer) | Best hardware | Recommendation |
|---|---|---|---|---|
| Llama 3.2-3B (fine-tuned) | 3.2B | 8 GB | H100 / H200 | Primary · accuracy |
| Gemma 3-1B (fine-tuned) | 1B | 3 GB | L4 / H100 | High-throughput |
| Llama 3.1-8B (fine-tuned) | 6.7B | 14 GB | H100 | Legacy / research |
| Gemma 3-270M | 270M | 1 GB | Any | Failed in production |
| Configuration | Time | Cost (run) | Key changes |
|---|---|---|---|
| Baseline: bf16, H100 | 21.5 hrs | ~$325 | None |
| FP8 quantization + larger batches, H100 | ~16 hrs | , | FP8 · 128K tokens/batch |
| FP8 + H200 migration | ~12 hrs | , | H200 · 256K tokens/batch |
| FP8 + H200 + Spark scaling | ~9 hrs ↓ 12.5h | significantly lower | 256 threads · 20K-article batches |
Stagwell's clients moved from "what was written" to "who said what about whom, and in what context."
Faster client answers
Relationship queries that used to require hours of manual analyst work return sourced answers in seconds via graph traversal. Self-serve replaces report turnaround.
Early crisis detection
Emerging negative coverage clusters surface hours before they trend. The 3–4 hour early warning gives PR teams a real response window, one well-managed intervention shortens a negative news cycle materially.
Accurate aggregation
Entity normalization resolves variants into single graph nodes before writes. Every share-of-voice, co-mention report, and trend chart runs on clean data.
Data sovereignty
No third-party LLM APIs. Client data never leaves the perimeter. Per-document cost is predictable and fixed, it doesn't move with vendor pricing changes or model deprecations.
This is what production GraphRAG looks like at media scale.
If you're another media intelligence or marketing-tech platform running keyword-based search at scale, three things matter from this deployment.
Relationships beat keywords once volume passes a threshold.
Below 100K documents, keyword search is fine. Above 1M/day, the only architecture that lets clients ask the questions they actually want to ask is a graph.
Domain fine-tuning beats prompting bigger models.
A 3B model fine-tuned on 100K domain samples consistently outperformed prompting larger general-purpose APIs on boundary detection, relationship classification, and schema compliance. Smaller, faster, cheaper, more private.
Hybrid retrieval is not over-engineering.
Graph + vector + lexical isn't redundancy. It's the only way to cover the range of question types a real client base produces. Intent-routed execution makes it work without forcing the user to pick an index.
Dataworkz builds and operates production-grade GraphRAG pipelines for media intelligence platforms.
If your team is running keyword-based search at scale and wants to understand what a knowledge graph transition would look like, technically and commercially, we'll walk through it.