Final Project Guidelines: "Classroom" Track [Traditional CS221 Project]

General Project Guidelines · "Impact" Track · "Classroom" Track

Overview

This is the traditional CS221 project.

In this project track, you will design, implement, and evaluate an AI system to solve a well-defined task. Which task you choose is completely open-ended, but the AI methods you use should draw on the ones from the course. You will build your system from the ground up, following good research practices along the way: designing and collecting a dataset, selecting good evaluation metrics and baselines, implementing models and algorithms taught in the class, and carefully analyzing your results.

This track is more scientific and method-focused than the "Impact" Track. As such, the scope of your project is expected to be smaller and AI use for coding is limited (see AI Policy below).

AI Policy

tl;dr: AI coding tools are limited in this track. Your core contribution must be implemented by you. AI-generated code counts as an outside source, not as your contribution. In both tracks, you will not be allowed to use AI to write your proposal or reports.

AI-Use Disclosure Statement

Every writeup (proposal, progress report, and final report) must include an AI-Use Disclosure Statement, modeled on the ICLR policy on the use of large language models. In this section, you must describe, in roughly a paragraph or two, the precise role of any generative AI tools in that stage of the work, including ideation, writing, code, collecting or labeling data, running experiments, and analyzing results. As at ICLR, this section may appear in the appendix and does not count toward the page limit, and AI tools are not eligible for authorship. The statement will not be graded on its own, but omitting it or failing to disclose significant AI use may lead to substantial grade deductions.

Milestones

  1. Proposal (2 pages max). The proposal is due Oct 23. It should include the following items.
    You should have the majority of the infrastructure (e.g., building a simulator, cleaning data) completed to do something interesting by now. For machine learning tasks, setting up the infrastructure involves collecting data (either by scraping, using crowdsourcing, or hand labeling). For game-based tasks, this involves building the game engine/simulator. While infrastructure is necessary, try not to spend too much time on it. You can sometimes take existing datasets or modify existing simulators to save time, but if you want to solve a task you care about, this is not always an option. Note that if you download existing datasets which are already preprocessed (e.g., Hugging Face, Kaggle), then you will be expected to do more with the project.

    Note that you can still adjust your project topic after submitting the proposal, but your progress report (described next) should be on the same topic as your final report.

  2. Progress report (4 pages max). The progress report is due on Nov 20. It should include the following items.

  3. Progress check-in with CA mentor (15-minute meeting). The check-in should be completed by Fri Nov 20. To provide more mentorship for the final project, we introduce a progress check-in between project groups and their assigned mentor. You will have a 15-minute meeting with your mentor to discuss the progress of your project, clear any confusion, and get advice. Your assigned CA mentor will reach out to give information on how to schedule the meeting for check-in.

  4. Final Video (5 minutes): The final video is due on Dec 4. The final video is a 5 minute video presentation of your project. In the video, you should briefly describe the motivation, problem definition, challenges, approaches, results, and analysis. You should include diagrams, figures and charts to illustrate the highlights of your work. If possible, try to come up with creative visualizations of your project. These could include system diagrams, more detailed examples of data that do not fit in the space of your report, or live demonstrations for end-to-end systems. The goal of the video is to convey the important high-level ideas and give intuition rather than be a super-detailed specification of everything you did. Use lots of diagrams and concrete examples, and avoid slides that are too wordy or have extremely complex equations.

  5. Final Report (5-10 pages max): The final report is due on Dec 4. Your final report should be a comprehensive account of your project. This final report structure is very similar to the progress report, except we would like to see some new results, experimentation and/or analysis, and a Future Works section. Below is a full description of what you should include in your project final report.

    Note: you can have an appendix beyond the maximum number of allowed pages with any figures, plots, or examples that you need. References do not count for the page limit.

Rubric

We will give feedback on the following dimensions:

Of course, the experiments may not always be successful. Getting negative results is normal, and as long as you make a reasonably well-motivated attempt and you explained why the results came out negative, you will get credit.

An example strategy

This is a suggestion of how to approach the final project with an example.

Datasets

You are free to use existing datasets, but these might not necessarily be the best match for your problem, in which case you are probably better off making your own dataset.

Libraries

You are free to use existing tools for parts of your project as long as you're clear what you used. When you use existing tools (e.g. existing models or datasets), the expectation is that you will do more on other dimensions.

Some project ideas

You can also get inspiration from previous years' CS221 projects (student access only).

Frequently asked questions for this track

For questions that apply to both tracks (using the same project for another class, choosing partners, and writing the ethical considerations statement), see the general project page.

How do you choose a good baseline and oracle?
Baselines are simple algorithms, which might include using a small set of hand-crafted rules, training a simple classifier, etc. (Note that baselines are extremely simple, but you might be surprised at how effective they are.) While a predictor that guesses randomly provides a lower bound (and can be reported in the paper), it is too simple and doesn't give you much information. Predicting the majority label is a slightly less trivial baseline, and whether it's acceptable depends on how insightful it is. For classification, if the different labels have very different proportions, then it could be useful; otherwise it won't be. You are encouraged to have multiple baselines. Please note that we expect an implementation of the baseline for the project progress report (not project proposal).

Oracles are algorithms that "cheat" and look at the correct answer or involve humans. For human-like classification problems (e.g., sentiment classification), you can have each member of your project team try to annotate ~50 examples and measuring the agreement rate. Note that some tasks are subjective, so even though humans are providing ground truth labels, human accuracy will not be 100%. When the classification problem is not human-like, you can try to use the training error of an expressive classifier (e.g., nearest neighbors) as a proxy for oracle error. The idea is that if you can't even fit the training data using a very expressive classifier, there is probably a lot of noise in your dataset, and you have a slim chance of building any classifier that does well on test. While returning 100% is an upper bound, it is not a valid oracle since it is vacuously an upper bound. Sometimes, oracles might be difficult to come by. If you think that no good oracles exist, explain why. Please note that we do not expect an implementation of the oracle at any point during your final project. However if the implementation is very easy, you are free to implement the oracle.

Both baselines and oracles should be simple and not take much time. The point is not to do something fancy, but to work with the data / problem that you have in a substantive way and learn something from it. Here are some examples of baselines:

Guessing completely at random is technically a baseline, but is a really bad one because it doesn't really tell you much about how easy the problem is.
Here are some examples of oracles: Always guessing the correct label is technically an oracle, but it's a really bad one, because you'd always get 100% and you don't learn from it.
Overall, the main point of baselines and oracles is to get you to look at the problem carefully and think about what's possible. The accuracies of state-of-the-art systems on the dataset could be either a baseline or an oracle. Sometimes, there are data points that are neither baselines nor oracles: for example, in a two component system, you use an oracle for one and a baseline for another.