AI for organisers.
Where AI helps an organiser and where it does not. Retrieval and grounding, evaluation, human review, natural language querying, model cost, governance and failure modes.
21 articles · AI for organisers
- When AI generated event reports invent a number nobody measuredai generated event reportsAI generated event reports fail when the model summarises a dashboard rather than a query result. How to ground, source and review post-show narrative properly.
- Natural language querying of event data and what it actually gets rightnatural language querying event dataWhat natural language querying of event data gets right on a registration schema, why enterprise warehouses break it, and what a semantic model has to carry.
- What text to SQL accuracy benchmarks tell an event data teamtext to sql accuracy benchmarksHow to read text to SQL accuracy benchmarks like BIRD and Spider, what the human baseline means, and how to map the published gap onto your own show week.
- Verifying an AI generated query before anyone quotes the answerverifying an ai generated queryVerifying an AI generated query means showing the SQL, the row count and the filter set beside it, because a query that runs can return the wrong rows.
- Grounding AI summaries in aggregates the reader can check themselvesgrounding ai summaries in aggregatesGrounding AI summaries in aggregates means every sentence traces to a row the reader can open, scored in two stages: did it answer, is each claim supported.
- Building provenance for AI generated numbers into every report lineprovenance for ai generated numbersProvenance for AI generated numbers means a figure carries its query, source tables, filter set and run timestamp, so a disputed number settles in a minute.
- Writing an AI summary of show metrics that survives a line by line checkai summary of show metricsHow to build an AI summary of show metrics from precomputed aggregates, forbid the model any arithmetic, and match every figure back by string comparison.
- How hallucinated metrics get into AI reports and who notices lasthallucinated metrics in ai reportsHallucinated metrics in AI reports arrive by four routes, only one of which involves a model, and the person best placed to catch one has the least authority.
- Hallucination rate measurement for an assistant that answers with numbershallucination rate measurementHallucination rate measurement needs a stated unit, a frozen sample and a confidence interval, because a rate graded off thirty answers resolves almost nothing.
- Numeric consistency checks that catch a wrong figure before publicationnumeric consistency checksNumeric consistency checks parse every figure out of generated text, recompute it from the same aggregate, and fail the response when the two disagree.
- Building an evaluation set for an event assistant from real questionsevaluation set for event assistantAn evaluation set for an event assistant is harvested from questions your team already asks, then graded against the SQL that produces the true answer.
- How far to trust LLM as judge reliability when grading your assistantllm as judge reliabilityLLM as judge reliability is high enough to be useful and biased enough to mislead, so grade the grader with a human sample large enough to mean something.
- Regression testing AI features when the model underneath keeps changingregression testing ai featuresRegression testing AI features means pinning a question set and diffing result sets across versions, because a model upgrade is a code change with no diff.
- Offline evaluation versus live monitoring for an assistant in daily useoffline evaluation versus live monitoringOffline evaluation versus live monitoring is a coverage argument: an eval set grades the questions you thought of, and the log holds the ones people ask.
- Retrieval augmented generation for organisers working from their own documentsretrieval augmented generation for organisersRetrieval augmented generation for organisers means indexing post-show reports and board packs nobody rereads, then making each answer name its file and page.
- Picking a chunking strategy for documents an event team actually keepschunking strategy for documentsA chunking strategy for documents has to suit both a post-show report that splits at headings and a contract whose defined terms sit twelve clauses away.
- Why hybrid keyword and vector search beats embeddings alone on event documentshybrid keyword and vector searchHybrid keyword and vector search wins on event documents because stand numbers, hall codes and product references are exactly what an embedding blurs away.
- Measuring retrieval quality separately from the answer the model writesmeasuring retrieval qualityMeasuring retrieval quality on its own sets a ceiling on the answer, because if the correct passage never reaches the prompt no amount of prompting recovers it.
- When rules beat a model for questions an event team asks dailywhen rules beat a modelWhen rules beat a model comes down to counting repeats: a few dozen stock questions cover a show week, and a stored query answers each one exactly, for free.
- Why models get arithmetic wrong and what to compute in SQL insteadwhy models get arithmetic wrongWhy models get arithmetic wrong matters for event reporting, because a percentage the model computed looks identical to one the warehouse computed.
- Deciding where AI is the wrong tool for an event data problemwhere ai is the wrong toolWhere AI is the wrong tool comes down to three questions about rule stability, input structure and what an error costs, scored before anyone writes a prompt.