Project Ideas

A strong ML-for-systems project starts with an important systems or networking problem, not simply a desire to apply a fashionable model. It asks a focused, testable question about whether “learning” can improve how a system or network is designed, configured, diagnosed, or operated — and and under what conditions it fails.

For this course, “learning” broadly includes predictive and generative methods, online and sequential decision-making methods, data-driven or learning-augmented optimization, and hybrid methods that combine ML with heuristics.

On this page, we include some AI-generated project ideas as starting points. You are welcome to use AI to refine these ideas or brainstorm new ones that fit the scope of the course.

Potential research directions

The following research directions were suggested by GPT-5.6 Sol:

1. Learn a systems decision or control policy. Explore scheduling, placement, caching, prefetching, autoscaling, congestion control, traffic engineering, or video bitrate adaptation. Ask whether the learned policy improves end-to-end performance over strong heuristics after accounting for inference and retraining costs.
2. Predict a condition so the system can act proactively. Predict workload demand, job duration, stragglers, failures, resource usage, query cost, or network performance. Evaluate whether prediction errors still lead to a useful operational decision; predictive accuracy alone is usually not enough.
3. Diagnose or explain system behavior. Use logs, metrics, traces, configurations, or execution histories for anomaly detection, root-cause analysis, performance debugging, or failure localization. Include realistic class imbalance, noisy data, and the operational cost of false alarms and missed incidents.
4. Build a generative or agentic operations tool. Investigate configuration generation, troubleshooting, documentation retrieval, or incident response. Focus on grounding, tool use, verification, and safe fallback behavior — not just prompt engineering. Projects that depend on a proprietary API or large model must identify an access plan and a viable fallback.
5. Study robustness, generalization, or safety. Stress-test an existing learned system under workload shifts, topology changes, failures, adversarial inputs, delayed feedback, or bad predictions. Develop a detector, guardrail, uncertainty estimate, or fallback mechanism and quantify when it helps.
6. Create a measurement study, dataset, or benchmark. Characterize an important ML-for-systems problem, expose a weakness in current evaluation practice, or make competing approaches easier to compare. The artifact should support a substantive research conclusion; data collection alone is not enough.
7. Reproduce and meaningfully extend prior work. Reproduce a central result from a course paper or another relevant publication, then add a new baseline, workload, system environment, failure mode, or design improvement. Reproduction alone is valuable practice but is not sufficient novelty for the final project.

The project should connect ML to a real systems or networking problem and be scoped around a claim that an experiment could prove or disprove. For example:

• Instead of “use reinforcement learning for cache replacement,” ask: “Under which workload shifts can a lightweight learned policy beat LRU on hit rate and tail latency, and when should the system fall back to LRU?”
• Instead of “use an LLM to debug failures,” ask: “Can retrieval-grounded diagnosis localize faults from logs and configurations better than search and classification baselines, and can a verifier prevent unsafe remediation suggestions?”
• Instead of “predict cluster load,” ask: “Does uncertainty-aware demand forecasting reduce SLO violations and overprovisioning relative to reactive autoscaling under bursty and changing workloads?”

A convincing evaluation typically includes strong non-ML and ML baselines, end-to-end system metrics, measurements of the learned component’s overhead, and an analysis of behavior beyond the training distribution.

Where to look for a concrete idea

Read beyond paper titles and abstracts. Useful project ideas often emerge from an untested assumption, missing baseline, workload shift, failure case, or missing artifact.

• Browse recent programs, workshops, posters, and award papers across the systems, networking, and AI/ML venues relevant to your interests.
• Use workshops to discover early-stage ideas and provocative positions, while recognizing that workshop papers may be more exploratory than mature conference papers.
• Compare papers that make conflicting claims or evaluate on different workloads, and design an experiment that explains the difference.
• Start from a real pain point in an open-source system, public issue tracker, or system you already understand, then ask whether ML is the right tool for it.
• Discuss a rough idea with the course staff early. It is much easier to sharpen, rescope, or redirect a project before implementation begins.

Check feasibility before committing

A project does not need a large model or many GPUs to be ambitious. Classical models, compact neural models, trace-driven simulation, emulation, and carefully designed measurement can also support strong research. Before committing to an idea, make sure your team can answer the following:

• What precise claim or hypothesis will you test?
• What are the strongest relevant baselines?
• Which end-to-end system metrics and ML metrics will you report?
• Do you already have a legal, usable dataset, workload, or way to generate one?
• Can the minimum viable experiment run with the resources your team has confirmed?
• What result can you obtain early, and what is your fallback if the model, data, or system integration does not work?