Laks V.S. Lakshmanan
Professor, Department of Computer Science, The University of British Columbia
Professor, Department of Computer Science, The University of British Columbia
A graduate seminar on model management for complex AI workloads over heterogeneous, enterprise-style datasets — tables, messages, documents, spreadsheets, images, videos, and beyond — asking what it takes to build a Data and Model Management System (DMMS) for the AI era.
CPSC 534L will emphasize research in efficient model management for processing complex AI workloads over heterogeneous datasets — particularly enterprise datasets such as tables, messages, documents, spreadsheets, images, videos, and more. The course is driven by three overarching questions:
What would it take to develop a DMMS that allows declarative specification of complex tasks, splits a complex task into simpler subtasks, assigns efficient models and/or data access methods to each subtask, possibly with RAG and tool call, and combines the solutions into a high-quality solution for the original task?
Within this framework, how do you navigate the trade-off between cost and accuracy? And what is "cost" anyway?
What abstractions and techniques does a DMMS need to accelerate the development of AI-powered applications over structured and unstructured data — much as database technology (DBMS) turbo-charged the development of applications driven by structured data?
All online discussion, submissions, announcements, and class resources are managed through Piazza — sign up here.
Course overview: models come with different functionalities, capabilities, sizes, and costs. An AI-powered application may call for multiple agents to be pressed into service and be orchestrated carefully in order to solve complex tasks. Why can't an agentic workflow solve the problem? What is a DMMS anyway and how is it different from an agentic workflow?
...
Example Systems.
Case Studies.
...
Course projects are typically completed in teams of 2–3.
A paper presentation is driven by three parties: the presenter, the discussion leader (DL), and everyone else, acting as audience. Everyone will present paper(s) and lead discussion on paper(s) presented by someone else — so your role changes from paper to paper.
As the name suggests, the presenter presents the paper while the discussion leader manages and steers the discussion, including Q&A. The presenter should:
See Guidelines for Speakers & Discussion Leaders below for how to prepare for and lead the discussion itself.
One of the key goals in presenting papers is to make the presentation as analytically evaluative and critical as possible.
Giving good technical talks is an art that takes time and practice. A collection of general tips is available from Stephen Scott's presentation-tips resource, which also links to a few other resources — including tips on good technical writing, useful for your project report later. Whatever tips you pick up, make sure to adapt them to this specific context: tips for job talks, for instance, shouldn't be applied as-is to presenting someone else's paper, and should be adjusted appropriately.
Evaluation criteria for talks are split between the presenter and the discussion leader.
Think of this as your opportunity to show off what is exciting, non-trivial, and cool about your project. The talk should:
Not all talks will follow this sequence exactly — some projects place more emphasis on experimental analysis, others on analytical results, and some strike a middle ground. Whichever template your project falls into, an "Organization" slide up front helps keep the audience informed of what to expect and where you are in the talk.
After the technical sections, discuss any difficulties or issues faced — limitations of the work are just as worth hearing about as accomplishments. Clearly label unfinished pieces as "work in progress," and discuss any far-flung objectives worth pursuing later under future work. Close with a clear "Conclusions" segment.
Slides should be submitted by the time your talk is scheduled. Questions about any of this are welcome — just ask.
In some project talks, a demo may be an integral component of the presentation.
The report can essentially follow the structure of your talk, with one important difference: the talk only has time to motivate the project and sketch key ideas, while the report must close the loop — providing the details necessary to complete the argument, description, proof, or analysis.
You may not have time to present every aspect of your project in 30 minutes. For example, if your project developed algorithms for detecting topic-wise influential bloggers on Twitter, it might have sections on topic discovery, behavior analysis for detecting influence, and verification of the influence patterns found — more than you can cover in one talk. The trick: advertise all your contributions in the talk, but say you'll focus on one or two of them in depth. The report, however, needs to fill in the details for all sections.
Your report will contain most of the standard sections:
Emphasis should be on discussing and critiquing prior art and establishing the novelty and advantages of whatever ideas, algorithms, or results you propose — in other words, position your work properly in the context of prior art. Work in progress is fine, but clearly identify which parts are settled and solid, which parts you're stuck on, what ideas you have for solving those, and so on. Use your imagination and creativity in structuring this part.