The midterm shows the project has moved from planning to validated technical work: a refined definition, real data, a working baseline, and initial measurable results.
By the midterm, the team should have:
refined the project definition
completed a meaningful review of previous work
obtained or created the main dataset
performed exploratory data analysis
implemented a baseline
produced initial measurable results
identified errors and technical risks
prepared a realistic completion plan
Show evidence of progress, not only plans.
What the midterm must show
Six parts, each with what to present, the requirements, and what to avoid.
1
Project Review and Refinement
What to present
Briefly review:
the motivating use case
the formal project task
the planned inputs and outputs
the main contribution
the evaluation criteria
Then explain how the project changed since the proposal: narrower scope, a revised research question, a different dataset or model, added constraints, a removed unrealistic component, or improved evaluation.
Requirements
Changes are expected and should be explained honestly. A good project evolves as the team learns more about the problem, the data, previous work, model limitations, and available resources.
Avoid
repeating the proposal with no updates
hiding major changes
keeping an unrealistic scope just because it was in the proposal
changing the project without explaining why
2
Previous Work
What to present
Review at least three relevant scientific papers, chosen for being recent, influential, or directly related. Organize them in a comparison table with:
title and year
research task
models or methods
datasets
evaluation metrics
main results
limitations
relationship to your project
Requirements
The review should shape project decisions. Explain:
which methods you may reuse
which baselines to implement
which datasets or metrics are standard
what limitation your project addresses
Use scientific databases and citation indexes to find strong work.
Avoid
summarizing papers in isolation without comparing them
picking papers only because they are easy
citing blog posts instead of scientific work
listing papers that do not affect the design
claiming novelty without showing how you differ
3
Dataset and Exploratory Data Analysis
What to present
Describe the dataset you collected, created, labeled, or generated:
number of samples
data sources
labels
class distributions
input lengths or dimensions
missing values
duplicate records
representative examples
training, validation, and test splits
Required EDA
Run analysis relevant to the project, such as:
class-frequency graphs
text-length distributions
image-size distributions
feature distributions
label co-occurrence
temporal distributions
missing-data analysis
correlations
examples of difficult or ambiguous samples
Requirements
Say what you learned and how it changes the solution, for example:
class imbalance requires weighted loss
long inputs require truncation or chunking
noisy labels require manual verification
leakage requires a different split
limited data requires augmentation or transfer learning
Avoid
showing graphs with no interpretation
presenting only averages
ignoring unusual or difficult samples
modifying data without documenting it
using the test set during development
4
Baseline Solution
What to present
Implement and evaluate at least one baseline, a simple and credible reference point. Options:
majority-class prediction
rules or heuristics
linear or tree-based models
a pretrained model without fine-tuning
an established method from prior work
a simple prompt-based solution
an existing library or API
Requirements
Describe the baseline's architecture or logic, training configuration, preprocessing, evaluation dataset, metrics, and results.
The baseline must be strong enough to make later improvements meaningful.
A prompt-only or pretrained model is fine as a baseline, but your final solution must include a trained or fine-tuned model, not only zero-shot or few-shot prompting.
Avoid
deliberately weak baselines
comparing only against random prediction
calling your final proposed model a baseline
reporting results without the configuration
comparing methods on different data splits
5
Initial Results and Error Analysis
What to present
Show measurable results in clean tables and graphs:
baseline results
results of initial alternatives
per-class or per-group performance
representative successes
representative failures
Error analysis
Inspect wrong or poor outputs and group them into meaningful categories, such as:
ambiguous input
missing context
poor labels
rare classes
model hallucination
incorrect retrieval
preprocessing failure
domain terminology
long or complex input
distribution shift
Requirements
For each important error category, explain why it happens, how frequent it is, how it affects the user, and what change might fix it.
Avoid
showing only average metrics
hiding failed experiments
reporting cherry-picked examples
calling errors random without investigating
proposing improvements unrelated to the observed failures
6
Completion Plan
What to present
Give a table with, for each remaining task: the technical scope, the responsible team member, the due date, the expected output, the risk, and a fallback solution.
The last item should be preparing the final presentation and repository submission.
Requirements
Base the plan on current evidence, not the proposal. Prioritize:
resolving data problems
implementing comparison models
running controlled experiments
performing error analysis
improving the system
preparing reproducible results
Avoid
plans with only vague activities like "improve model"
too many experiments with no priorities
leaving evaluation to the last week
polishing the interface while core results are weak
Show it, don't just claim it
By the midterm the strongest evidence is visual: real datapoints with labels, what your preprocessing changed, and a baseline you can already measure. Include figures like these, not just bullet points.
Dataset sample with labelsBefore / after preprocessingBaseline vs current (intermediate result)
Show concrete examples of your data and model
Make it concrete with real examples: sample data (images or text), how the data is generated or preprocessed, the model steps, real model inputs and outputs, and several real error cases.
Sample data (images or text)
Image, chest X-ray 224×224 · label: pneumonia
"App crashes when I upload a PDF over 10 MB."
Text, support ticket → label: bug
How the data is generated or transformed
"Great pizza, fast delivery."→"gr8 pizza, delivery was not fast"
raw input→preprocess→tokenize / embed→model→post-process→output
Model input and output
"The wifi keeps dropping every few minutes."→{ label: network, conf: 0.92 }
"Summarize this clinical note: ..."→"Intermittent chest pain over two days ..."
input image→2 boxes: car 0.94, pedestrian 0.81
Model errors, with the likely cause
Predicted spam, true not spam: the model over-weighted a marketing phrase inside a quoted reply.
Detected 1 car, missed 1 in heavy rain: low SNR washed out the edges.
Generated a dosage not in the source note: retrieval returned an irrelevant passage.
Submission checklist
This is a quick final check, not a replacement for the full guide. Read the complete requirements above first, then use these ten items to confirm the major pieces are in place before you submit.
The project definition is refined, and changes since the proposal are explained.
At least three relevant papers are reviewed in a comparison table.
The dataset is obtained or created, with sizes, labels, and splits.
Exploratory data analysis is done and interpreted, not just plotted.
At least one credible baseline is implemented and evaluated.
Initial measurable results are shown in clean tables and graphs.
Errors are analyzed and grouped by cause, not just averaged.
A trained or fine-tuned model is planned or under way, not only prompting.
Concrete examples of data, model input/output, and errors are shown.
A realistic completion plan with owners and dates is given.
