I just finished Simmer’s AI for Technical Marketers certificate. I learned a lot. I went in wanting to build an AI business use case relevant to advertising, and the later modules are the ones I will actually reuse. This post is about those practice habits, not a week-by-week report.
The course (taught live by Juliana Jackson, Krasimir Bambalov and Simo Ahava) keeps putting evaluation next to generation: how well the model performed, and when AI is the wrong tool. That framing stuck more than any single notebook trick.
Synthetic data for advertising needs a structure
Week 5 on synthetic data for advertising changed how I think about generation. Before the course I tended to call an LLM and ask it to invent rows. The course teaches a structured path instead: define the purpose, train a generative model on statistical patterns (tools in the notebooks included TVAE and CTGAN with careful preprocessing), then evaluate the new table for that job.
Synthetic data is useful only when it fits a defined purpose. Orgs often hold first-party data they cannot share with the people or tools that could analyse it. Fidelity, utility and privacy pull apart. In the course work we trained a 90-day repurchase model on generated rows and still had to evaluate it on real held-out customers. Utility on the task is not a privacy proof. Calling a table synthetic does not make it safe to share by itself. Quality is not one score either: sanity checks, statistical fidelity, task utility, detectability and privacy each need a call based on intended use, evidence and remaining risk.
Office hours made a practical limit hard to miss. Accuracy on an imbalanced repurchase problem (~99% non-purchasers) misleads; precision, recall and F1 matter more. Synthetic-trained F1 in the demo was about three times lower than the real-data baseline. Synthetic may help for PoCs, platform tests without exposing real records (with governance), or bounded handoffs after validation. It is not a way to invent population evidence when real history already exists.
Before I ask for synthetic rows now, I write down what decision the data is for, what would make a fake row dangerous, and what still needs a real sample. That is a long way from “just prompt the LLM.”
Data privacy as a reference, not a HK rulebook
The privacy lessons in the course do not map one-to-one onto Hong Kong rules. I still keep them as a reference: purpose limits, cumulative risk, governance before you share, and the reminder that a synthetic label is not a privacy guarantee. When I apply anything from the notebooks here, I treat local requirements as the bar and the course material as orientation, not as a substitute.
Knowledge graphs, then Graph RAG
Week 6 on knowledge graphs and Graph RAG repeated the same discipline in a different stack. A knowledge graph makes relationships explicit so retrieval can follow connected facts. Extraction, entity matching, query reliability and evidence still need checking. Documentation comes first. AI on unclear or outdated processes just reproduces the confusion. The graph organises what is already documented; it cannot invent the missing SOP.
Graph RAG can combine graph structure with vector search. In the live demos it helped on a retry and still got things wrong. Text-to-Cypher could emit invalid or wrong queries. An empty result is not proof that a fact is missing from the corpus. Groundedness is not correctness. Entity resolution is another place to slow down: similarity is not identity, and a false merge contaminates everything downstream.
I will keep treating retrieval failures as a prompt to check the docs, the schema and the chunking, not as a clean “not found” I can hand to someone else. Choose graph vs Markdown, JSON, SQL or vector search by the questions you need answered, data quality and ops cost, not by fashion.
Content gap analysis with agents that propose and people who check
The final live session and notebooks on content gap analysis (search intent clustering plus agentic briefs) are the piece I expect to reuse most. The shape is simple: group searches by meaning, compare each cluster to existing pages, flag a gap when the closest page is a weak match or the wrong kind of page, then let an agent propose an editorial action from read-only tools. Cluster labels, gap flags, briefs and evaluators all need independent checks.
The worked examples used a fictional shop and simulated Search Console data. Nothing in a run was a finding about a real website, which is part of the point. Intent mismatch matters as much as similarity: a guidance-style query matched to a /products/ URL is still a problem even when the score looks fine. A shipping cluster at ~0.64 similarity to a shipping-and-returns page is an editorial question, not an automatic new URL.
Agent tools stayed read-only (list gaps, get cluster detail, get page content as metadata). The brief had to quote only returned evidence. A guardrail refused generation when the row was never flagged as a gap. Brief evaluation mixed recomputable checks (queries, intent, links, best-match page) with a human outline review. A fluent recommendation still needs a person to check it against the transcript.
The habit I am keeping is cluster → agent draft brief → human check → only then write. Skipping the human step is where thin or mismatched pages get worse.
What I am doing next
I am turning those habits into portfolio practice: small, visible builds where purpose, documentation and review are part of the work, not afterthoughts. The certificate is done. The practice is the point.
