I Built Two RAG Systems for DJs — Presskits and Set Analysis

Most RAG demos die in notebooks. These did not. Inside PK Studio, a long-running product context where I work with DJs and music-industry teams, I built and operate two production retrieval-augmented generation systems:

1. Presskit RAG — helps create artist presskits and public-facing narrative material from grounded artist context.
2. Set Analysis RAG — helps analyze DJ sets, set history, musical criteria, and operational context.

Together, these systems support around 10 real clients. They are related, but they are not the same product. They have different users, different retrieval needs, different failure modes, and different definitions of “good answer”.

This post is the public, privacy-safe version of that story. It is meant to be useful to a hiring manager evaluating my work in AI QA Automation, test platform engineering, and production AI systems — and useful to any engineer shipping RAG in a domain that is not generic web search.

I will not name individual clients, quote private prompts, or leak source material that was not already public. Everything below describes the product shape, architecture, and lessons — not the private data.

The problem: two workflows, one domain

PK Studio work sits in a dense music-industry domain. The vocabulary is not standard, and the important context is spread across artist material, notes, sets, post-event reports, public press, and internal working knowledge.

But the two RAG systems solve different jobs:

• Presskit creation needs artist positioning, biography, selected milestones, tone, public facts, and narrative structure. A good answer is coherent, useful for communication, and safe to publish.
• Set analysis needs set notes, transitions, BPM/key context, room/night context, track usage, and operational memory. A good answer is specific, traceable, and useful to a working DJ or team reviewing material.

Standard search handles neither workflow well. The same artist may appear under multiple names. “Set” can mean a live recording, a planned sequence, a time slot, or a broader performance context. The useful answer is usually a small piece of text plus a strong pointer back to the original source.

That is exactly the kind of domain where RAG is useful: small corpus, dense vocabulary, inspectable retrieval, grounded generation, and explicit refusal when the context is not enough.

System 1: Presskit RAG

The Presskit RAG is built to support artist narrative and presskit creation. Its job is not to “write marketing copy from vibes”. Its job is to retrieve grounded artist context and help turn it into a usable presskit draft or supporting material.

The system optimizes for:

1. Artist context retrieval. Pull relevant public and internal artist material without mixing people, aliases, events, or outdated details.
2. Narrative structure. Help organize biographical notes, positioning, milestones, style, and context into a coherent presskit shape.
3. Safety for public material. Avoid inventing claims, exaggerating credentials, or leaking private context into public-facing copy.
4. Reviewability. Make it clear what source material supported the draft so a human can review before publishing.

A typical Presskit RAG question is not “what song is this?” It is closer to: “Build a concise artist bio from the available material”, “What public milestones should this presskit mention?”, or “Rewrite this presskit section using only grounded context.”

System 2: Set Analysis RAG

The Set Analysis RAG is a different workflow. It is built for reasoning over DJ sets and operational music context.

A working DJ or team may need to ask questions like:

• “Which sets used this edit?”
• “Find the set that opened with a long ambient build.”
• “What changed in the technical rider for this run of shows?”
• “Pull the notes around this transition and the room context.”

Those are real production-style questions, paraphrased. The system answers with short, grounded responses and pointers back to source material so the user can verify and move on.

This RAG optimizes for:

1. Set-specific retrieval. Notes, sequences, transitions, versions, and context need to stay attached to the right set.
2. Domain vocabulary. DJ/music terms need to be treated as first-class retrieval signals, not generic English words.
3. Traceability. The system must point back to the material it used.
4. Refusal. If the source material does not support the answer, the system should say so instead of inventing a confident story.

Shared architecture

The two systems share engineering principles, but not all of their retrieval logic or product behavior.

The common pipeline is intentionally boring:

1. Ingestion. Heterogeneous material is normalized into retrieval-friendly chunks with stable IDs and provenance metadata.
2. Retrieval. Query-aware retrieval ranks chunks using inspectable signals tuned to the workflow.
3. Generation. A strict grounded prompt tells the model to answer only from retrieved context, refuse when context is insufficient, and point back to sources.
4. Operational tooling. Internal surfaces let the team inspect what was retrieved, replay queries, flag bad answers, and roll back ingestion changes.

I did not start by adding the most complex vector stack I could find. The corpora are small and domain-heavy, so inspectable lexical/tag-based retrieval is often more valuable than opaque embedding similarity. When retrieval fails, I want to see why and fix the ingestion or scoring, not guess what the vector space did.

Why the distinction matters

Calling this “one RAG system for DJs” hides the most important engineering lesson: RAG quality is product-specific.

The Presskit RAG and Set Analysis RAG both use retrieval and grounded generation, but they fail differently:

• A bad presskit answer can overstate an artist, use the wrong tone, or include context that should not be public.
• A bad set-analysis answer can attach a note to the wrong set, misread a transition, or confidently claim a pattern that is not supported by the material.

That means the evaluation sets, refusal behavior, source metadata, and review UX have to be different. The architecture can share primitives, but the product contract cannot be generic.

The four production lessons I would teach a new LLM engineer

1. Retrieval is the product. If the system retrieves the wrong material, no prompt will save the answer. Spend the time on ingestion and retrieval before clever generation tricks.
2. One domain can contain multiple RAG products. Presskit creation and set analysis live in the same music ecosystem, but they need different source contracts and answer behavior.
3. Refusal is a feature. A system that says “I do not have enough context” is more useful than one that invents. This matters even more when public-facing press material is involved.
4. Inspect everything. If you cannot explain why the system returned what it returned, you cannot safely operate it. Boring choices — stable IDs, provenance, lexical signals, versioned prompts — are what make the system reliable.

What is next

Two directions I am actively exploring:

• Evaluation per workflow. Presskit questions and set-analysis questions should not share the same eval rubric. Each system needs a small set of real questions with expected source pointers.
• Tighter ingest contracts. The biggest source of bad answers is upstream data quality. I am tightening the contract between ingestion and the teams that produce source material.

Why this matters for AI QA Automation and platform roles

This is the kind of AI work I bring into QA and platform engineering: grounded systems for real users, on small but high-stakes corpora, with the discipline of a senior SDET / test platform engineer.

The PK Studio work is strong evidence because it is not a toy chatbot. It is two grounded systems inside a real product context: one for creating artist presskits, one for analyzing DJ sets. The static portfolio on this site describes my SDET and platform background; this case study shows that I can also ship production AI systems.

Reach me at juancruzmunozalbelo@gmail.com or on LinkedIn.

← All posts